- Muitos fatores afetam a produtividade dos desenvolvedores
- Alguns são claros e fáceis de medir, mas outros são difíceis de medir e por isso tendem a ser ignorados
Saber o que construir (Knowing what to build)
- Construir a coisa errada rapidamente não é nada produtivo
- É preciso saber o que o cliente quer,
- saber o que é aceitável para outras equipes (quantos índices são possíveis em uma tabela do banco de dados, é legalmente permitido compartilhar certas informações?),
- e saber o que já foi tentado antes e não funcionou
Fazer menos trabalho
- Terminar o trabalho rapidamente é bom, mas é ainda melhor quando algo simplesmente não precisa ser feito
- Os processos da empresa podem adicionar “trabalho de ocupação” que reduz a produtividade
- Às vezes há uma forma simples de ajustar o processo para entregar o mesmo valor com muito menos trabalho
- Pode ser necessário algum esforço para “manter as luzes acesas (Keep the lights on, KTLO)”
- Isso inclui tarefas que precisam ser feitas continuamente (por exemplo, responder tickets de suporte), mas que não fazem o projeto avançar
- Esse tipo de trabalho pode parecer produtivo em várias métricas (número de tickets concluídos, número de commits mesclados), mas não torna a empresa um lugar melhor
Ferramentas com resposta rápida
- Os desenvolvedores usam ferramentas o tempo todo: editor, git, sistema de build
- O tempo extra que essas ferramentas adicionam pode gerar um custo considerável dependendo da frequência de uso
- Não é apenas o custo por hora, isso também quebra a concentração do desenvolvedor
O conhecimento na cabeça do desenvolvedor
- É difícil de medir
- Se todo o resto for igual, o desenvolvedor com mais conhecimento relevante é mais produtivo
- Porque sabe como o código funciona e não precisa investigar tudo a fundo,
- sabe como usar as ferramentas e conhece as armadilhas a evitar
- faz as perguntas certas
- Desenvolvedores 10x existem, e eles são “pessoas que conhecem bem a base de código”
- Isso significa que uma equipe não deve possuir, coletivamente, mais coisas do que consegue manter na cabeça. (Idealmente, o bus factor deve ser maior que 1: teoria do Bus Factor)
- Isso também significa que é vantajoso minimizar a frequência com que a propriedade muda
- Ninguém sabe mais sobre algo do que a pessoa que o criou
- Idealmente, pessoas que estão usando um sistema pela primeira vez deveriam trabalhar e aprender com quem já o conhece
- É preciso haver limites claros entre sistemas
- Interfaces limpas com semântica simples significam que é possível pensar nas propriedades da interface sem precisar conhecer todo o sistema por trás dela
- A documentação é uma boa forma de transmitir conhecimento
- Isso é especialmente importante quando um desenvolvedor precisa executar uma tarefa específica com a qual não está familiarizado
- Se a documentação estiver faltando, o desenvolvedor pode ter que pesquisar por conta própria como fazer a tarefa, cometer erros e refazê-la, ou esperar até que outra equipe responda às perguntas, o que pode atrasar o trabalho
- Isso pode transformar rapidamente uma tarefa de 1 hora em uma tarefa de 2 dias
- Se 100 desenvolvedores tiverem que fazer isso, o custo de uma página de documentação ausente pode equivaler ao salário anual de um desenvolvedor
- Isso também significa que a especialização deve aumentar
- Exigir que todo desenvolvedor execute uma ampla variedade de tarefas é improdutivo
- Uma hora gasta em um processo para escrever algum sistema de segurança ou planejamento de capacidade é diferente de uma hora gasta para entender o domínio a fim de resolver um problema
Infraestrutura útil
- A infraestrutura deve ajudar, não atrapalhar
- Ela deve estar razoavelmente alinhada com todo o trabalho que precisa ser feito
- Cada parte da infraestrutura é projetada com um caso de uso específico em mente, mas em projetos às vezes surgem situações fora desses casos de uso
- Nesses momentos, é frustrante ouvir “você só pode usar nossa infraestrutura” ou “não conseguimos fazer esse tipo de coisa com nossa infraestrutura”
- Isso obriga a contornar a infraestrutura ou desperdiçar tempo em reuniões tentando convencer os responsáveis pela infraestrutura dos requisitos
Pouca dívida técnica
- O código existente nunca se encaixa perfeitamente no trabalho que você quer fazer
- Quem escreveu o código originalmente não tinha uma “bola de cristal” para ver que mudanças você faria
- Mas alguns códigos são muito mais fáceis de modificar do que outros
- A resposta para “como podemos fazer X?” não deveria ser “precisamos redesenhar tudo isso”
- Se houver muita dívida técnica, até uma pequena mudança de funcionalidade exigirá mudanças maiores no sistema
- Reduzir a dívida técnica ajuda a minimizar a área exposta que precisa ser (a) entendida e (b) alterada
- Projetos para pagar a dívida técnica precisam ser concluídos
- Se forem abandonados no meio ou perderem prioridade, o sistema pode acabar pior do que estava no início
Baixa taxa de falhas
- Se houver falha na execução de ferramentas, falha de build, falha de deploy ou regressão causada por erro em produção, isso é tempo desperdiçado
- Reduzir a probabilidade dessas falhas aumenta a produtividade
- Além do engenheiro que sofre a falha, isso também tende a desperdiçar o tempo da equipe que é dona do sistema que falhou (porque precisam analisar e corrigir o problema juntos)
Práticas produtivas são práticas (Productive practices are practical)
- A melhor forma de aprender a resolver um problema específico é criar um protótipo
- Se o ambiente atrapalha a prototipagem, até a abordagem mais produtiva pode ser prejudicada
- Se for difícil usar ferramentas de monitoramento, os desenvolvedores criarão menos dashboards, medirão menos coisas, e as decisões serão menos orientadas por dados
- Por outro lado, se grandes mudanças forem divididas em revisões de código menores, fica mais fácil revisar e fazer deploy do código
O quanto o engenheiro consegue se concentrar
- O engenheiro precisa trabalhar de acordo com o cronograma e conseguir se concentrar
- Esse foco pode ser roubado por reuniões e interrupções
- Interrupções também incluem comandos de CLI lentos, testes lentos e tarefas que exigem investigação porque a pessoa não sabe como executá-las
- Pensar em coisas demais em uma mesma semana também prejudica a capacidade de foco
- Prazos se aproximando ou perguntas sem resposta do gestor ocupam RAM mental mesmo quando a pessoa tenta se concentrar em outra coisa
Concluir o trabalho
- Construir 50% não significa 50% de produtividade, e sim 0%
- Não existe nada menos produtivo do que trabalho que acaba sendo descartado
- Às vezes abandonar um projeto no meio é a decisão certa
- Lutar contra a falácia do custo afundado às vezes é a coisa certa a fazer
- Mas não pode haver um padrão consistente de mudar prioridades antes que os projetos sejam concluídos
- Nesse caso, a produtividade da equipe pode cair para 0
Encerrando
- Nem sempre é possível construir dashboards para medir todos esses fatores, mas é possível entender como eles afetam a produtividade
- Resolver esses problemas pode aumentar bastante a quantidade de trabalho realizada
- Alguns problemas podem ser surpreendentemente fáceis de corrigir
- Gastar algumas horas escrevendo documentação pode economizar milhares de horas na empresa
- Quando for preciso cortar madeira rapidamente, comece afiando a lâmina da serra
7 comentários
E é um texto com muita conclusão.
"Se faltar documentação, o desenvolvedor pode acabar tendo que pesquisar por conta própria como executar a tarefa, cometer erros e refazer o trabalho, ou esperar até que outra equipe responda às perguntas, o que pode desacelerar o ritmo do trabalho"
Não é documentação de desenvolvimento, mas quando pedi às pessoas que passaram pelo onboarding da empresa para atualizarem o documento de onboarding uma semana depois, ele acabou melhorando. Afinal, quando alguém entra na empresa sem nenhuma informação, são justamente essas pessoas que melhor sabem, naquele momento, do que precisam.
Também acho que muitos
Readme.mdde projetos open source no GitHub costumam ser relativamente bem escritos porque muitos primeiros usuários chegam e dão feedback.Ultimamente tem entrado trabalho demais e eu tô ficando sem cabeça pra lidar com tudo T_T
A infraestrutura deve ajudar, não ser um obstáculo --> mas, atualmente, as empresas na Coreia alegam segurança como desculpa, então isso definitivamente não se aplica.
Entendo como você se sente, mas este texto foi escrito em inglês. Parece que a situação também é parecida nas empresas de países de língua inglesa.
Parece mais uma tradução do que um resumo... obrigado pela organização detalhada.