Uma jornada pela produtividade: Como melhoramos os resultados do time de desenvolvimento em 270%

Há pouco menos de um ano, aceitei o desafio de liderar o time de tecnologia e estratégia de negócios da Guiando – empresa líder no desenvolvimento de soluções para gestão de contas faturadas que atende algumas das maiores empresas do país. Principal meta: melhorar a produtividade do time de Desenvolvimento!

Considero minha posição na Guiando como excelente oportunidade para demonstrar a efetividade de práticas que tenho recomendado em minhas consultorias.

Nesse post, compartilho algumas das ações que adotamos que nos permitiram um crescimento de 270% em nossa produtividade.

1. Definimos claramente o que precisa ser feito (primeiro)

A rotina nos cobra agilidade em responder ao mercado. Entretanto, para sermos ágeis, precisamos definir prioridades. Precisamos que todos utilizem os mesmos critérios aderentes a estratégia geral.

Estratégia implica em um padrão coerente para a tomada de decisões.

Uma das primeiras medidas adotadas na Guiando, para garantir que as prioridades fossem respeitadas, foi o estabelecimento de uma “esteira” única de solicitações.

Sempre que uma nova solicitação de atualização tecnológica é feita, cabe a alguém de negócios definir a importância relativa dessa solicitação e a posicionar adequadamente na esteira.

Na Guiando, seguimos um modelo “puxado” de desenvolvimento e sempre priorizamos o que é mais importante.

A esteira única garante que todos vejam o que é mais importante sempre. Objetivos e expectativas estão sempre alinhados.

2. Acordamos expectativas de entrega que precisa ser feito

Todo novo item da esteira precisa ser claramente especificado.

  • Cabe ao time de negócios estabelecer claramente os critérios de aceitação para qualquer item na esteira
  • Cabe ao time de desenvolvimento assegurar entendimento dos critérios de aceitação e pedir clarificação sempre que for necessário

O time de desenvolvimento estabelece uma estimativa de esforço a partir dos critérios de aceitação de toda solicitação na esteira.

Não fazemos “puxadinhos” (a menos que seja absolutamente urgente). Isso significa que evitamos ao máximo fazer “improvisos tecnológicos” para atender clientes gerando dívidas técnicas difíceis de pagar.

Na foto, Eduardo Camargo (responsável pela Visão de Negócio), eu, e Fernando Paiva (responsável pelo setor de Desenvolvimento).

3. Entendemos os “porquês” de cada solicitação

Trabalhamos muito para melhorar a comunicação entre negócio e tecnologia.

O time de negócios tem se esforçado para expliciar para tecnologia as motiviações de cada nova solicitação. Usamos “business model canvas” para deixar tudo sempre claro e fácil de comunicar e  entender.

Não é fácil, mas entendo que esta é uma etapa crítica. Quanto mais “alinhada” a área de tecnologia com negócios, melhores as perspectivas de empatia e colaboração.

4. Acordamos o esforço para o atendimento de toda solicitação

O time de desenvolvimento, conhecendo os critérios de aceitação, estabelece uma estimativa de

esforço (baseada em story points) para o atendimento.

Aqui, uma “sacada” que fez toda a diferença: Estabelecemos um “tamanho máximo” para uma atividade. Qualquer solicitação cuja complexidade exceda um limite acordado deve ser “quebrada” até respeitar o limite.

Vamos a ideia motivadora: Como desenvolvedor, tenho dificuldades para definir quanto esforço será necessário para executar uma tarefa. Quanto mais complexa ela for, maior a dificuldade. Se eu precisar de mais de uma semana (em minhas projeções) para completar um trabalho, tenho enormes chances de estar dando um “palpite” e não uma estimativa. Quanto mais complexa a tarefa, maiores as chances de eu “exagerar” no prazo e, devido a síndrome do estudante, acabar consumindo todo o tempo solicitado embora esse não fosse necessário.

5. Blindamos o time desenvolvimento

Lembra da esteria? Ela tem mudanças bloqueadas em até D+30, Ou seja, o que precisa ser feito nos próximos 30 dias está definido e esta lista é praticamente imutável. Para isso, separamos um time de sustentação para atender as correções de bugs (não podem esperar)

Toda a empresa está informada e entende os benefícios dessa medida. O time de desenvolvimento não perde (nem pode perder) o foco!

6. Estabelecemos uma disciplina de acompanhamento

Temos uma meta diária de entrega. Todos os dias respondemos as questões: 1) O que foi feito? 2) O que será feito? e 3) O que está “pegando”?. Realmente trabalhamos em um nível saudável de cooperação e cobrança (sim!) mútua.

Sempre há algo que pode ser feito para melhorar e tentamos adotar essas medidas ASAP.

7. Começamos pela interface (e o que é mais importante)

Antes de escrever qualquer código, pensamos primeiro na interface com o usuário. Fazemos com que o pessoal de negócio ateste o benefício antes de entregarmos o benefício. Assim garantimos assertividade.

8. Optamos por comunicação transparente

Queremos explicar o negócio: usamos um painel com o Business Model Canvas.

Queremos mostrar nossa performance: temos um painel Kanban, também mostramos nosso burndown.

Tudo explícito para quem precisar ver.

No geral, optamos por gravuras fixadas na parede em lugar de ferramentas tecnológicas. A ideia é reduzir bloqueios.

O que está por vir?

Atingir boa performance é bem diferente de manter boa performance. Nesse momento, essa é minha principal preocupação.

Estamos, consistentemente, entregando mais valor. Mas, precisamos trabalhar para que continuemos assim.

Sabemos que temos muito o que melhorar. Sabemos que muito do que fizemos é pura execução do bom senso. Entretanto, é exatamente no bom senso que tenho visto muitos projetos fracassarem.

Go Guiando!

Compartilhe este insight:

2 respostas

  1. Excelente post Elemar! Não tenho dúvidas de que o bom senso faz com que muitas vezes o projeto não ande! Por isso é tão importante que tudo sempre esteja o mais claro possível! E o D+30 é sensacional! Parabéns e sucesso!!

  2. Parabéns Elemar pela produtividade alcançada, tenho certeza que manter a boa perfomance será desafio.. Uma duvida, quando vc fala toda solicitação é toda mesmo que é avalida ou somente demandas de negocio maiores? As reuniões de planejamento para os trinta dias e para fazer as estimativas é gasto quanto tempo? Na hora do planejamento voces dessem a nivel de tarefa ou param nas user stories?

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

Implementing synchronization for multiple threads in .NET is easy. There are a lot of options for doing that – for...
A ausência de padrões leves para externar (seja para documentação ou na elaboração) a arquitetura de um software sempre é...
Não são raros os casos onde a distância entre um “desejo” e a “realização” é a “tentativa”. Ou seja, partindo...
Em contextos extremos, é bom lembrar que é importante dedicarmos esforço para aquilo que, de alguma forma, influenciamos. Se um...
In this post, let’s solve the “Euler Knight’s Tour” using F#. Disclaimer Sometimes life imposes a pause on us. I’m...
As professionals, we should focus on developing great technical solutions. But, these solutions need to solve real problems. At the...
× Precisa de ajuda?