AquárioDuBagrão

 Algum tempo atrás, participei de um treinamento sobre metodologias ágeis para gestão e desenvolvimento de software. Mais especificamente, o curso abordava questões teóricas e práticas do SCRUM.

Durante a apresentação de um dos tópicos, o instrutor comentou sobre um projeto gigante (tipo, daqueles que vão criar um foguete) onde o CAOS imperava soberano. Custos e prazos estourados, equipe desmotivada e fatigada. A única constante era: todo dia, toda hora, uma nova mudança surgia. Pouco antes de receber o desafio de assumir o projeto, nosso instrutor descreveu as últimas frases do atual gerente: “Fique tranquilo, temos “zilhões” de pilhas de documentação, confeccionadas segundo o mais rígido padrão de mercado. É tudo seu!”

Seguindo o roteiro do curso, o instrutor foi apresentando sua estratégia de ataque e como utilizou alguns princípios ágeis para recuperar o projeto. Sem muita demora, surgiu um burburinho entre alguns alunos que se precipitaram a deduzir que a “nova moda ágil” seguramente seria muito mais legal pois não exigiria das equipes de desenvolvimento de software nada além de código, código e mais código.

“Chega de produzir documentação sem sentido!”

Tsc, tsc, tsc…

Antes de esclarecer a confusão entre metodologias ágeis e documentação, abro um parênteses para a questão: Existe relação entre documentação e sucesso dos projetos de software?

De acordo com pesquisas do The Standish Group, não é possível traçar uma sólida relação entre o sucesso de um projeto e a quantidade de documentação produzida. Na verdade, um dos relatórios apontados pelo grupo encontrou evidências de que “é mais provável que quanto mais documentação você escreve, maior a chance do projeto falhar“. É bem provável que você já tenha participado de um projeto de desenvolvimento de software, durante o qual foi elaborada uma extensa e meticulosa documentação, obteve aprovação dos stakeholders (envolvidos) para, no final, perceber que os desenvolvedores entregaram um produto/serviço completamente diferente do que foi especificado.

Em projetos cuja prioridade foi gerar toda a documentação antes de iniciar o desenvolvimento “propriamente dito”, os números a respeito da porcentagem de funcionalidades de um produto (ver figura abaixo) que foram realmente utilizadas nos sugerem um panorama não muito promissor quando consideramos o retorno sobre o investimento das atividades relacionadas à documentação.

De novo, o que o gráfico acima “nos conta” é que, em média, 45% das funcionalidades de um produto NUNCA são utilizadas, ainda que 100% dessas funcionalidades tenham sido muito bem documentadas, sim senhor!

Indo por um caminho oposto, muita gente se anima a utilizar as metodologias ágeis, pois entende que não será necessário gerar nenhuma documentação. Não precisamos procurar muito até encontrar uma multidão de seguidores dos princípios ágeis que, ao ler no manifesto que “Software funcionando é mais importante do que documentação completa e detalhada“, agendam 5 semanas de “happy-hour” para comemorar o fim da “papelada”.

O manifesto ágil, entretanto, não descarta, não proíbe, não “demoniza” a documentação num projeto de software. Na realidade, se um projeto segue os princípios ágeis, as pessoas envolvidas não vão priorizar a documentação em detrimento da produção e entrega de software funcionando.

Buscando esclarecer essa questão e ser mais específico, qual seria, então, o papel apropriado da documentação num projeto de software?

Primeiro: Qual o propósito da documentação no meu projeto? Embora não seja a única “solução”, está claro que produzimos documentos para comunicar informação. Utilizar este tipo de solução como a principal estratégia de comunicação para nossos projetos é muito arriscado quando se considera a incontrolável habilidade que um “leitor” possui para interpretar erroneamente a real intenção do “escritor”. O valor de um documento reside na sua persistência. Um documento pode ser lido e relido durante anos e as palavras permanecerão imutáveis. Isso não quer dizer que leitores diferentes interpretarão essas palavras da mesma forma. Entendemos que existem dois propósitos que justificam a produção de documentos num projeto:

1. Preparar com antecedência o fornecimento de informações para uma interação humana.
2. Registrar os resultados de uma interação humana.

Segundo: Com o propósito em mente, qual o público-alvo? Se o propósito de um documento é prover informação, é necessário considerar “quem estará consumindo essa informação”. Nenhum documento pode comunicar tudo para todo mundo. O responsável pela elaboração de um documento deve considerar tópicos sobre a experiência e conhecimento do leitor, sobre quanto tempo o leitor poderá investir na leitura do documento e sobre como o leitor utilizará a informação disponibilizada no documento. Tais considerações afetarão não somente o conteúdo, mas também a maneira pela qual a documentação será organizada, agrupada e apresentada. Enfim, para garantir que um documento satisfaça seu propósito, é vital identificar seu público-alvo e suas respectivas necessidades de informação.

Terceiro: Antes de gerar a documentação, que resultado obtenho da relação (VALOR x CUSTO)? Se o valor agregado ao projeto é menor do que o custo exigido para gerar a documentação, pense antes de gastar tanto papel. Nenhum método ágil prega a eliminação de todo tipo de documentação. Na verdade, devemos buscar a todo custo evitar qualquer desperdício de tempo e esforço na produção de documentação abrangente. Você estará desperdiçando tempo e esforço do seu projeto quando a documentação:

• Não tem um propósito claro
• Não tem um público-alvo definido
• É muito complexa (ou muito superficial) para atender as necessidades do seu público-alvo e para atingir seu propósito
• É mantida além de sua “vida útil” (sim, os documentos perdem a utilidade)

Por exemplo, você já parou para pensar sobre o propósito e sobre quem é o público-alvo da “Especificação de Requisitos” que produziu em todos os seus projetos? Dentre as possíveis respostas:

• Quero definir um contrato com o cliente sobre o que, exatamente, o projeto estará desenvolvendo. Neste caso, visto que o cliente é o público-alvo, o documento não deveria ser redigido para satisfazer as necessidades dos designers e dos desenvolvedores.
• Quero detalhar as solicitações do cliente para que os designers e desenvolvedores implementem os requisitos. O documento deve, então, satisfazer as necessidades do público-alvo: designers e desenvolvedores.
• Quero fornecer informação “histórica” para os responsáveis pela futura manutenção do sistema após a entrega do mesmo. Neste caso, a vida útil do documento começa assim que o projeto de desenvolvimento termina.

Quarto: Como evitar o desperdício? Os custos de elaboração e manutenção dos documentos de um projeto são consideráveis. Logo, seria prudente aplicar um teste simples antes de “investir” esforços escrevendo ou atualizando a documentação:

• Qual o propósito do documento?
  • Se não existe um propósito claro, produzí-lo pode significar desperdício.
• Quem é o público-alvo?
  • Se inúmeros papéis vão consumir o documento, avalie se o mesmo poderá satisfazer as necessidades de todos. Se não existe um público-alvo definido, ou se este é muito diverso para que o documento satisfaça a todos, produzí-lo pode significar desperdício.
• O documento registra o resultado de (ou preparativos para) interações humanas?
• O documento ainda é útil?
  • Manter um documento além do tempo em que seu público-alvo o utiliza (propósito) é desperdício.
• Qual é o esforço mínimo necessário para garantir que o documento alcançará seu propósito (público-alvo e vida útil)?
  • Complexo demais é desperdício. Superficial demais também é desperdício.

Antes de me despedir, lembre-se: Você pode ter um projeto muito bem documentado, e ao mesmo tempo deixar passar despercebido que “ele” já foi ou está indo “pro buraco”.

Share on Facebook