Em 1975, Frederick P. Brooks escreveu o revolucionário The Mythical Man-Month. Quarenta anos depois, esta série de artigos pretende revisar as afirmações e os argumentos do autor. Quanto o ofício da Engenharia de Software evoluiu desde então?

Capítulo 10: The Documentary Hypothesis

Neste curto capítulo, Brooks aborda a questão da documentação em projetos de software. Será que os princípios abordados pelo autor são compatíveis com os enxutos modelos ágeis ou com verbosos modelos "tradicionais"? Vamos verificar!

A hipótese: no meio de uma enxurrada de papéis, um pequeno número de documentos se torna o ponto crítico ao redor do qual todo o gerenciamento de projetos acontece. São as principais ferramentas pessoais do gerente.

Interessantemente, o autor não especifica um documento ou conjunto de documentos afirmando serem referência para o gerente.

Seguindo um raciocínio mais geral e abrangente, ele afirma que todo projeto eventualmente possui alguns poucos documentos que são as ferramentas do gerente para tomar decisões.

Na prática, mesmo quem trabalha com metodologias ágeis acaba usando alguns “documentos” como referência, ainda que tais “documentos” sejam planilhas simples do Google docs com as histórias de usuário ou um board no Trello com as tarefas do Kanban.

Em processos mais "tradicionais", onde diversos documentos são utilizados, os membros da equipe e gerentes inevitavelmente voltarão suas atenções para alguns documentos com as informações mais relevantes naquele momento, que podem variar em cada fase do projeto.

Minha experiência mostra que, em ambos os casos, o importante é que a pessoa ou grupo de pessoas que toma as decisões tenha em mãos as informações corretas e relevantes naquele momento. Informação demais desvia o foco. Informações faltando levam a decisões incorretas. Portanto, independente do processo, um gerente com experiência e senso crítico apurado é a melhor “ferramenta” que um projeto pode ter.

Contudo, o sucesso ainda depende de pessoal competente para munir o gerente com informações verdadeiras, pois infelizmente já testemunhei casos onde o gerente tomou a melhor decisão possível com o que tinha em mãos, mas os resultados foram negativos porque as premissas estavam incorretas, pois os desenvolvedores não fizeram a análise apropriada do problema.

Para um projeto de desenvolvimento de um computador, os documentos críticos são os objetivos, manual, cronograma, orçamento, organograma organizacional, alocação das pessoas no espaço e as estimativas, previsões e preços da máquina em si.

Para um projeto de software, as necessidades são as mesmas […].

Aqui Brooks propõe alguns documentos ou informações críticos. Não me aprofundarei em cada um, pois não é o objetivo do artigo, mas eis algumas razões da importância deles:

  • O objetivo do software é extremamente importante para não se perder o foco e entregar o que o cliente precisa.
  • O manual em muitos casos de sistemas pequenos pode ser substituído por componentes auto-explicativos e algumas dicas inline, mas algum tipo de página de ajuda sempre acaba sendo necessário. Até mesmo a busca do Google tem algumas páginas de ajuda explicando seu funcionamento.
  • O cronograma também é algo que pode ser substituído, no modelo ágil, por algum tipo de estimação que envolva os sprints, velocidade de desenvolvimento, etc. Independente do formato, é extremanente raro equipes não precisarem estimar tempo e escopo, por mais que sejam negociáveis.
  • Orçamento: todo projeto precisa considerar se o ganho cobre o gasto, mesmo que o ganho seja um investimento a ser colhido futuramente.
  • Organograma: seja uma empresa com hierarquia rígida ou outra com times e projetos multifuncionais e flexíveis, planejar quais habilidades são necessárias para a entrega do projeto, por quanto tempo e quem responde a quem faz parte de qualquer projeto de sucesso.
  • A alocação do espaço é muitas vezes ignorada, mas dispor os membros de uma equipe de forma a melhorar a comunicação é algo que faz muita diferença. Existem livros inteiros sobre isso, mas digamos que ajuda muitíssimo ter as pessoas que você precisa para resolver um problema à distância de um tapinha nas costas.
  • O último item, sobre estimativas e previsões de preço, é algo que se tornou muito mais complicado hoje, na era das startups onde há intensa concorrência de aplicativos "gratuitos". Muitos começam sem pensar muito sobre monetização, mas é inevitável que qualquer empreendedor tenha que estimar o valor do produto em desenvolvimento e assim determinar se o investimento vai compensar no final.

Mesmo em um projeto pequeno o gerente precisa formalizar tal conjunto de documentos.

Com exceção de projetos triviais ou isolados, a grande maioria dos projetos, ainda que pequenos, são executados num contexto onde, cedo ou tarde, vão interagir com outros pequenos projetos, seja utilizando o produto de outro projeto, ou tendo seu produto utilizado em projetos futuros. Eventualmente, alguém irá questionar o motivo de algo ter sido feito do jeito que é.

Onde trabalho, na Atlassian, cada produto possui diversas equipes pequenas e especializadas, cada qual define seus objetivos a cada trimestre, incluindo uma métrica objetiva para atestar o sucesso. Damos preferência a projetos curtos, mas mesmo quando há necessidade de projetos mais longos, os mesmos são subdivididos para facilitar o rastreamento do processo e a organização geral. Algo que frequentemente é enfatizado, é que todos os projetos precisam ter, de uma forma ou de outra, as decisões formalizadas, ainda que sejam sintetizadas numa sentença e baseadas em algum número obtido via análise. Uma das piores coisas que pode ocorrer é pessoas tomando decisões contrárias ao que foi decidido anteriormente por não ter o mesmo contexto ou gastando tempo refazendo análises, tomando as decisões novamente ou correndo atrás de alguém que tenha a informação necessário.

Ao mesmo tempo, não é desejável prejudicar o desempenho das equipes para documentar o que não é necessário. Equilíbrio é importante. Omitir informações básicas, mesmo quando elas não parecem tão importantes no momento, poderá prejudicar o futuro de um projeto em diversas ocasiões: mudanças na equipe ou no comando do projeto, mudança no escopo, imprevistos técnicos, etc. Sem contar um futuro projeto que se utilize dos resultados obtidos. Por outro lado, excesso de informações leva, como já disse, à perda do foco no que é importante.

Manter os documentos críticos possibilita vigilância do estado e um mecanismo de alertas.

Este é um desafio em qualquer projeto. Como saber se as coisas estão indo bem? Se alguém perguntar para você agora se o projeto atual está indo bem ou mal, o que você responderia? Ok, você pode dizer o que acha, mas o que diria se a próxima pergunta fosse: qual o grau de confiança de sua análise do projeto, considerando que isso vai impactar na decisão de investir alguns milhões nele em detrimento de outros projetos promissores?

Uma boa prática para cada projeto é ter um único local com as informações críticas e o estado atual do projeto, atualizado pelo menos semanalmente. Como dito acima, pode ser algo muito sucinto, mas com informações corretas, relevantes e diretas.

Se a empresa utiliza um sistema web como JIRA ou Confluence, é interessante manter um issue ou página central que represente um índice dos tais "documentos críticos", resumindo o estado do projeto e listando as referências para os detalhes importantes.

Em empresas onde várias equipes trabalham em conjunto, combinando seus esforços de algum modo para entregar funcionalidades para os clientes, tal visibilidade é essencial. Pode não parecer, poi com sorte é possível passar meses ou até anos sem que isto se torne um problema, contornando a questão da visibilidade em conversas informais. Bem, isso pode funcionar até que problemas de verdade comecem a ocorrer e clientes sejam prejudicados porque as entregas estão atrasando e ninguém consegue determinar o motivo ou a equipe responsável.

Enquanto escrevia este tópico, me peguei pensando em como esse papo de criar e manter documentação sobre o projeto pode parecer algo absurdo, ainda mais para quem prefere uma abordagem ágil e não gosta nem de escrever comentários no código. Por outro lado, em minhas várias experiências, percebi que a falta de informações claras sobre o que as equipes estão fazendo leva a um grande prejuízo.

Preciso contextualizar e exemplificar minhas afirmações acima. Estou assumindo que há constante interações entre as equipes. Agora vamos a uma pequena estória.

Imagine que você faz parte de uma equipe com três desenvolvedores e cria uma pequena biblioteca com uma API para converter data em texto e vice-versa. Num primeiro momento, parece algo muito trivial, então sua equipe decide não se preocupar em documentar a API, treinar outras equipes, criar exemplos de casos de uso, etc. Muito tempo depois, quando talvez a equipe já mudou e você nem se lembra mais dos detalhes de implementação da tal API, problemas começam a aparecer com relação ao uso e tratamento de dadas no sistema. Você gasta dois dias analisando o problema e descobre que, das outras equipes, 20% adotaram corretamente sua API, o restante usou de forma indevida, mas que por pouco funcionou, ou utilizou-se de bibliotecas alternativas que já conheciam para não terem o trabalho de aprender a utilizar sua API. A partir daí, sua equipe precisa coordenar um projeto para padronizar o tratamento de datas em todos os sistemas da empresa, travando diversos outros projetos e desviando o foco de muitas pessoas. Quando o projeto começa, sua equipe fica atolada com questões das outras equipes sobre a API, muitas delas repetidas exaustivamente. Finalmente, talvez sua equipe chegue à conclusão de que ter investido uma semana em criar uma boa documentação, feito uma sessão de treinamento de uma ou duas horas com alguns desenvolvedores e possivelmente criado uma regra de commit para detectar padrões incorretos de uso do código teria evitado diversos problemas e economizado várias semanas de trabalho.

Ufa! Espero que esta estória, parcialmente baseada em casos reais, tenha conseguido ilustrar para o leitor que documentar as coisas importantes pode fazer toda a diferença.

O trabalho fundamental do gerente do projeto é manter todos indo na mesma direção.

A tarefa diária do gerente de projetos é comunicação, não tomada de decisões; os documentos comunicam os planos e decisões de toda a equipe.

Ao contrário de muitos que acham que gerente é o chefe da equipe, Brooks sugere que ele é apenas um instrumento para manter todos alinhados.

Em geral, há um analista de negócio ou gerente de produto que define onde o projeto precisa chegar, por exemplo com base em conversas com os clientes ou em análises estatísticas de uso do projeto. Então, o gerente do projeto deve ser o facilitador da comunicação entre as partes envolvidas de forma que todos produzam recebam as informações que precisam para fazer um bom trabalho.

Alguns podem argumentar que uma equipe ágil auto organizada e de alto nível não precisaria dessa função, mas a experiência mostra que, com exceção de sistemas triviais, a complexidade faz com que mesmo profissionais altamente capacitados precisem de alguma ajuda, caso contrário o fardo de gerenciar a informação acaba tirando o foco do desenvolvimento do produto em si.

Portanto, o gerente não deve escrever documentos como finalidade em si mesmos, nem escrever para si próprio, mas toda a informação documentada deve ter o objetivo de direcionar e facilitar o trabalho da equipe e dos interessados no projeto.

Apenas uma pequena parte do tempo de um gerente de projetos técnico – talvez 20% – é gasto em tarefas onde ele precisa de informações de fora da sua cabeça.

Este é um ponto controverso.

Por um lado, todos os bons gerentes que eu conheci até hoje tinham praticamente um banco de dados em suas cabeças. Eu sempre fico maravilhado em como alguns bons gerentes que conheço, que raramente têm tempo de olhar o código, conseguem lembrar de tantos detalhes sobre o funcionamento dos sistemas no qual trabalham.

Por outro lado, tais gerentes consultam os desenvolvedores todos os dias para entender como eles estão resolvendo os problemas, quais os desafios que eles estão enfrentando para implementar os requisitos e as decisões técnicas que foram tomadas, afinal é o gerente que vai precisar explicar tudo, de forma sucinta e em linguagem acessível, tanto para o escalão superior da empresa quanto para os clientes e outros interessados no projeto.

De qualquer forma, o objetivo do autor com a última afirmação citada, é de mostrar que o trabalho do gerente é mais do que ser um simples agregador de informações, como veremos na próxima afirmação.

Pela razão acima, o conceito de marketing de um “sistema de gerenciamento contendo toda a informação” para dar suporte aos executivos não é baseado em um modelo válido do comportamento executivo.

Um ponto bem interessante. É provável que você, assim como eu, já tenha trabalhado em algum projeto onde tentaram implantar um sistema de controle que chegava ao nível de planejar e justificar cada hora de trabalho. Ok, talvez não tanto assim, espero, mas pelo menos já tentaram vender alguma ferramenta que promete dar aos executivos completa transparência sobre tudo que ocorre no projeto.

Segundo Brooks, isso não funciona. O motivo é simples: informações muito detalhadas simplesmente não são relevantes, nem de interesse dos executivos.

Como comentei acima, os bons gerentes tem grande quantidade de informação sobre o projeto, comunicam-se diariamente e não precisam de uma ferramenta com cada detalhe do projeto.

Os executivos apenas precisam de um número confiável ou no máximo alguns poucos indicadores para tomar decisões e coordenar em alto nível as atividades da empresa. Um gerente que conheço o seu trabalho possui valor imensuravelmente maior do que um software que calcula a porcentagem de tarefas concluídas.

Assim, é ingenuidade pensar que catalogar tudo de um projeto num tipo de sistema ou banco de dados vai agregar algum valor. Pelo contrário, além de quase sempre não refletir a realidade, isto vai gerar um fardo de burocracia que provavelmente atrasará o projeto.

Considerações

Mais uma vez Brooks acerta em cheio em suas análises. Embora hoje usemos terminologias diferentes e algumas variações nas práticas e processos, os princípios permanecem intactos e relevantes.

Isso também demonstra a importância dos profissionais de projetos terem bom senso e bases sólidos dos princípios apresentados aqui, não importante por qual nome eles sejam chamados.

Se você é entusiasta de CMMI, ITIL, Six Sigma, RUP, PMBOK, Scrum, XP, Kanbam, CrystalClear ou qualquer outro processo, metodologia ou framework, tome grande cuidado para não seguir o processo pelo processo, não caindo na armadilha de se apoiar em técnicas, desviando-se então do foco principal do seu projeto.

Venho repetindo incessantemente: a ferramenta X ou a técnica Y não gera sucesso por si só, a não ser que entregue o que você precisa quando precisa, nem mais, nem menos.