Minha abordagem para desenvolvimento de funcionalidades de produto

Se acomodar em apenas escrever código não é mais aceitável

Minha abordagem para desenvolvimento de funcionalidades de produto
Photo by Reproductive Health Supplies Coalition / Unsplash

Na posição de Engenheiro de Software, desenvolver novas funcionalidades é uma das partes mais básicas do trabalho. Para alguns, isso se resume em escrever código, pedir para alguém testar e depois enviar para produção. Mas, quando a empresa cresce em maturidade e você cresce em senioridade, as exigências vão além disso.

Se acomodar em apenas escrever código não é mais aceitável. É preciso saber se comunicar com a engenharia, gestão, PM, e várias outras pessoas de diferentes times com diferentes backgrounds. Planejar o trabalho e alinhar expectativas não é mais um trabalho exclusivo do PM ou da sua gestão.

Neste artigo, mostrarei os passos que sigo para colocar uma nova funcionalidade em produção, mantendo todos bem envolvidos no processo.

Comece com o porquê

Com que frequência você entrega uma nova funcionalidade sem saber de onde o PM surgiu com aquela ideia? O primeiro passo que dou é perguntar o porquê de ter que construir aquela funcionalidade. A resposta que espero deve me ajudar a entender pontos-chave que vão me ajudar a falar com qualquer pessoa sobre o projeto.

  • Qual é o problema que resolvo com essa funcionalidade?
  • Essa funcionalidade causará algum impacto financeiro na empresa? Quais são os números?
  • Quem será afetado (positivamente) por essa funcionalidade?

Se você não conseguir encontrar esses números, ou for muito difícil dizer qual o público alvo dessa funcionalidade, é muito provável que você esteja trabalhando em um “achismo” de alguém e é bem provável que este não deve ser o momento certo para seguir com essa ideia.

Essa é uma etapa muito importante de todo o processo, já que você precisa conseguir discursar sobre o projeto com qualquer pessoa na empresa. Quanto mais conhecimento você tem sobre o assunto, mais fácil fica de adaptar a sua fala para a sua audiência.

Uma coisa que percebi depois que comecei a perguntar o porquê, é que comecei a ficar mais motivado e engajado nos projetos sabendo o impacto do meu trabalho.

Documentação escrita é o seu super poder

A maioria das pessoas engenheiras de software cresceram na carreira ouvindo que no desenvolvimento ágil de software você não deve escrever documentação. Isso é uma das coisas que discordo completamente. O manifesto ágil, que data de 2001, nunca foi sobre go horse, mas sim sobre manter uma mente positiva com relação a mudanças e saber reagir rápido a elas.

Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
- Manifesto Ágil, 2001

Uma incorreta interpretação do manifesto resultou em muitos gestores com essa mesma mentalidade: acreditar que documentar o projeto e planejar, antes de começar a desenvolver, é "Waterfall" e não "Agile" (essa eu ouvi recentemente de um gestor em uma reunião).

Para mim, a documentação serve para entender o problema em um nível mais técnico, colher opiniões, e dar contexto aos meus colegas. Quando olho para projetos passados, que tiveram documentação adequada sendo revisados pelos meus pares, vejo muitas ocasiões em que erros e decisões de design duvidosas foram evitadas. Além disso, posso afirmar que todos os envolvidos na revisão do documento puderam adquirir contexto suficiente sobre o projeto para iniciá-lo ou para começar a ajudar na implementação em qualquer ponto.

Estrutura do documento

A estrutura básica que utilizo é composta por 3 seções. Contexto, Análise técnica, e Propostas.

Contexto

Nesta etapa, eu escrevo com minhas próprias palavras o que aprendi ao perguntar o porquê. É muito importante que o leitor entenda o problema, quem é afetado por ele, e qual o cronograma para começar o projeto.

Como o objetivo dessa seção é de que qualquer pessoa possa ter um contexto teórico sobre o projeto, eu sempre listo as métricas que serão impactadas e qual o comportamento esperado no caso de sucesso dessa iniciativa.

Análise técnica

Ao desenvolver uma nova funcionalidade, tento entender se há alguma coisa parecida já implementada. Havendo algo similar, o leitor precisa entender por que não resolve esse problema em particular.

Esse também é um bom lugar para listar os pontos de contato do projeto. Quais partes do sistema precisam mudar para que o usuário consiga interagir com essa nova funcionalidade? Há alguma ferramenta interna no meio do caminho? Quais são as dependências do projeto com outros times?

Se você tem uma clara visão dos requisitos funcionais, use-os para entender como o sistema deve se comportar para que, então, você consiga definir os requisitos técnicos.

Propostas

Agora que o problema está claro, todos os requisitos foram listados, e você tem uma visão melhor do problema, é a hora de trabalhar nas propostas. Gosto de oferecer duas opções diferentes (mas nem sempre é possível), para que o time tenha a chance de questionar minhas decisões e trazer uma terceira proposta (está geralmente relacionada a uma das duas propostas).

Quando mais de uma proposta resolve bem o problema (tecnicamente falando), cabe ao time tomar a decisão sobre qual caminho seguir, sempre tendo em conta o melhor balanço possível entre o time-to-market e qualidade técnica.

Ferramenta de gestão de projeto

Atualmente utilizo o Jira, mas essa etapa é relativamente igual independe da ferramenta (se livre do Excel se for o que você utiliza hoje 😅).

Como geralmente uma nova funcionalidade envolve mudanças em várias partes do sistema (às vezes em múltiplos sistemas), eu defino essa funcionalidade como um Épico no Jira. Na descrição, copio e colo o conteúdo da seção Contexto do documento, com um link para o arquivo.

Saber o que precisa mudar e quando é muito útil para ajudar a quebrar o trabalho em tarefas independentes. Tê-las listadas no Épico ajudará a gestão e PM a acompanhar o trabalho.

A quebra do trabalho em tarefas independentes não é trivial. É um exercício de prática, onde na primeira vez você provavelmente cometerá erros. Aprenda com os erros para que da próxima vez eles possam ser evitados. Não há uma fórmula mágica para isso, já que cada pessoa e time trabalham de maneira diferente.

O fluxo habitual de engenharia

Não há muito o que dizer sobre esse passo. Faça bom uso das revisões de código e dos testes. Pesquise sobre as boas práticas do mercado para atingir qualidade no seu trabalho. Pergunte e peça ajuda sempre que se sentir preso.