Death March: manual de sobrevivência do engenheiro de software
Este ano assisti pela primeira vez um show ao vivo no festival Osheaga em Montreal, e eu não poderia ter escolhido um artista melhor para começar: Two Feet. O músico estadunidense faz uma mistura de rock, blues e música eletrônica que foi descrita pela Wonderland Magazine como “electro-soul”. A guitarra melancólica e as batidas sintetizadas do Two Feet embalaram incontáveis dias e noites em que trabalhei como desenvolvedor, e sempre me fazem lembrar de projetos que foram desafiadores para mim.
Aprendi muito em todos os projetos em que participei, seja como desenvolvedor ou coordenador. Levantar requisitos junto ao cliente, fazer brainstormings para decidir como criar os componentes e continuamente criá-los, desenvolvê-los e melhorá-los junto com um time motivado é algo extremamente gratificante.
Mas muitas vezes esse privilégio vem em uma terrível embalagem: um projeto “death march”. Esse tipo de projeto, imortalizado pelo livro homônimo de Edward Yourdon, é bem conhecido no mundo da Engenharia de Software e descrito no livro da seguinte forma:
Um projeto death march é aquele no qual os parâmetros de projeto excedem a norma em pelo menos 50%. Na maioria dos casos, isso significa que uma ou mais das seguintes limitações foram impostas ao projeto:
- O cronograma foi comprimido a menos da metade do tempo estimado por um processo racional.
- O time foi reduzido a menos da metade do número que seria normalmente alocado para um projeto desse tamanho e escopo.
- O orçamento e recursos associados foram cortados pela metade.
- As funcionalidades e requisitos são duas vezes maiores do que em circunstâncias normais.
Resumindo: em um projeto death march, você e seu time estão encarregados de um trabalho colossal, mas têm pouquíssimo tempo e recursos para realizá-lo. Isso resulta, é claro, em noites de insônia e muita dor de cabeça para todos os envolvidos. O que fazer nesses casos? Yourdon dá algumas dicas de “sobrevivência” em seu livro que acho extremamente valiosas, e que eu gostaria de ter descoberto ainda em meus primeiros anos como desenvolvedor. Neste post, compartilho algumas dessas dicas, focando principalmente nas que podem ser mais úteis para quem está encarando um projeto caótico pela primeira vez.
1. Organize-se
Yourdon escreveu “Death March” do ponto de vista de um gestor de projeto. Se você é um desenvolvedor iniciante, essa pessoa provavelmente é sua chefe. Se você é um pouco mais experiente, talvez já esteja colaborando mais de perto com o seu gestor ou até gerenciando um pequeno time. Independente de qual seja sua situação, é importante ter em mente que ser organizado é tão importante quanto ter conhecimento técnico. Sendo assim, mantenha sua lista de tarefas pendentes e concluídas sempre na ponta do lápis, e não esqueça de parar para respirar fundo e revisar o seu progresso de vez em quando. Como explica Yourdon:
Gestores também podem ensinar seu time a fazer um planejamento semanal de antemão. (…) Podemos até encorajar os membros do time a agendarem um horário para colocar os pés em cima da mesa e pensar sobre o que estão fazendo.
Ferramentas de gerenciamento de tarefas como Jira, Trello e Notion são algumas das mais badaladas segundo o Stack Overflow Developer Survey 2023. Além de facilitarem o controle de grandes volumes de tarefas e manterem todos os membros do time em sintonia, a utilização dessas ferramentas ajuda a evitar as horas extras “invisíveis”, que são, por exemplo, pequenos bugfixes ou reuniões fora de horário que acabam não sendo registrados:
Mesmo supondo que todos os membros do time pudessem trabalhar 18 horas diárias para sempre, sem nunca se cansarem, é crucial que o gestor mantenha controle de quantas horas extras invisíveis estão ocorrendo ao longo do projeto; só assim o gestor poderá medir a produtividade do time de forma precisa e a probabilidade de completar cada mini-entrega ao longo do projeto.
2. Seja visual
Quando estou tentando entender um processo complexo, sempre gosto de desenhá-lo, seja no papel, em um quadro ou usando uma ferramenta simples como a diagrams.net. Como seres humanos somos criaturas extremamente visuais, e portanto conseguimos expressar e visualizar mais claramente a relação entre as partes de um sistema através de uma representação visual. Isso ajuda também a resolver eventuais ambiguidades que surgem quando representamos informação em outros formatos, como textos ou tabelas:
Se a dinâmica de um processo de software é importante, como podemos estudá-la? (…) Planilhas não são adequadas para esse fim, pois não ilustram as interdependências e ciclos (loops) entre componentes de um processo. Em contraste, modelos visuais são geralmente melhores para ilustrarem a natureza “holística” de um processo; estes modelos servem como um convite à discussões, comentários e debates do tipo “sim… mas…”
Eu sei que muita gente não gosta de UML, por ser formal demais ou não representar bem certos aspectos. Porém, em minha opinião, os diagramas de atividades e classes são muito úteis para documentar processos e relações de forma simples, rápida e que pode ser entendida tanto por desenvolvedores quanto por membros de outros times que não são da área de tecnologia. Na dúvida, escolha um padrão para descrever e documentar os processos e componentes do seu sistema e e utilize-o. O importante é comunicar as informações de projeto de maneira consistente.
3. Escolha suas batalhas
Toda equipe segue um processo de trabalho, e como parte dessa equipe é sua missão seguir o processo. Por exemplo, se sua empresa trabalha com metodologias ágeis, é fundamental que você participe das “cerimônias” como dailies e restrospectivas. Parece óbvio dizer isso, mas a verdade é que é fácil se “desgarrar” de um processo de trabalho por conta de interrupções e outros problemas do dia-a-dia. Se o processo for novo e você ainda não estiver acostumado com ele, o risco de desviar dele é maior ainda. É importante também ser proativo e conversar regularmente com seu gestor para se assegurar de que você está focando seus esforços nas tarefas certas. Como explica Yourdon:
Mantenha [o processo] simples — e se o time puder lembrar apenas uma palavra, essa palavra é: triagem.
Enquanto muitos gestores preferem repetir o mantra de que “tudo é prioridade”, bons gestores fazem uma triagem constante das tarefas, fazendo realocações e mudanças de prioridade quando necessário. Às vezes é preciso também remover tarefas, seja transferindo-as para o backlog para análise posterior ou riscando-as definitivamente do mapa. Como o tempo é um recurso escasso, o gestor precisa garantir que as funcionalidades que agregarão maior valor ao projeto são as que irão receber mais atenção:
(…) Em um projeto death march você não tem tempo para fazer tudo que seus usuários estão pedindo. Se você construir seus processos guiado por esse fato solene, você tem chances de êxito.
O único problema de entregar menos funcionalidade do que o cliente está esperando é que, naturalmente, ele não vai ficar satisfeito. Nesses casos a solução é sentar com o cliente e negociar a prioridade e escopo de cada funcionalidade. Se você é desenvolvedor, não se preocupe: esse é o trabalho do seu gestor. Se você é gestor, boa sorte:
Se você é o gestor de um projeto death march, é muito fácil prever o resultado de suas negociações sobre orçamento, cronograma e recursos: você perde.
Considerações finais
Para quem se identificou com as situações descritas neste post, recomendo a leitura do livro “Death March”. Infelizmente a obra nunca foi publicada em português, mas espero que as citações que traduzi e incluí ao longo do post sirvam de motivação para quem está a fim de uma leitura mais técnica — mas com insights extremamente práticos — sobre gerenciamento de projetos de software. Ouvir I See You do Two Feet pode ser também um ótimo acompanhamento para a leitura.
Se tem uma coisa que adoro sobre “Death March” é que ele nos lembra que, embora software seja desenvolvido em equipe, é importante que o gerenciamento seja feito com um olhar humano, voltado para o indivíduo e suas necessidades. Em um projeto onde cada segundo e cada decisão conta, é preciso que cada um trabalhe para manter o delicado equilíbrio entre estar de bem consigo mesmo e encarar as duras realidades de um projeto problemático. Como conclui Yourdon:
Levar um projeto death march a uma conclusão bem-sucedida é obviamente importante, e espero que este livro tenha fornecido conselhos práticos sobre como fazer isso; mas sobreviver é ainda mais importante! No melhor dos casos, nossos projetos death march entregarão resultados gloriosos aos usuários, cronogramas e orçamentos que vão impressionar a alta diretoria, e tudo isso mantendo nossa saúde, mente, família e senso de humor firmemente intactos.
Fontes:
