Profissionais TI - Pra quem respira informação

Dando continuidade a série de reflexões iniciadas semana passada, sobre os 4 valores do Manifesto Ágil, hoje falarei sobre Software Funcional mais que Documentação Abrangente.

Muitas empresas exigem que qualquer processo de desenvolvimento só pode começar após a área de negócios preencher documentos como Scope Statement, Business Requirement, Change Request, Use Case, fora outras documentações de governança exigidas. Até aí, problema algum! O problema surge quando estes documentos se tornam o principal canal de comunicação entre a área de negócios e o time de desenvolvimento.

Já vi absurdos de alguns times de desenvolvimento exigirem que o documento de especificação tenha no mínimo 50 páginas para passar clareza! Ora, como vimos no artigo anterior, por que não usar e abusar da comunicação verbal para passar clareza?

Outra situação delicada ocorre com empresas que implementam escritórios de PMO da forma mais “engessada” e burocrática possível (lembrando que não são as boas práticas do PMBOK que “engessam” os processos e sim as pessoas que aplicam as boas práticas de forma burocrática). Estes escritórios costumam exigir diversas documentações para atender ao processo de governança.

Mas pergunto: “E a qualidade do meu software? Qual a garantia que todas estas documentações vão gerar um software de qualidade?”. Já vi casos de documentações tecnicamente perfeitas, atendendo a todos os processos de governança, e o software ser uma bela porcaria. Pergunto: “Valeu a pena?”.

Se a interatividade entre business e developers é um dos fatores-chave para o sucesso de um projeto, o canal de comunicação entre eles deve ser “leve”. Utilizem artefatos leves como Kanban, planilha Excel, postites, cartões, usem e abusem de técnicas ágeis como user stories.

Aí você pode me perguntar: “Mas Vitor, isto soa muito anárquico! E se um diretor da minha empresa pedir a documentação do meu projeto? Vou mostrar para ele um monte de postites pendurados na parede?” Minha resposta é: Não. Você deve continuar gerando a documentação “pesada” do seu projeto se necessário, mas esta documentação não deve ser o canal de comunicação com seu Dev. Team e sim a formalização do processo para ser arquivado dentro da empresa. Inclusive recomendo que esta documentação seja elaborada no final de cada Sprint ou mesmo ao final de cada Release, onde já se conhece no detalhe tudo o que está sendo entregue.

Lembrem-se sempre que o projeto deve entregar um produto de qualidade e não somente uma documentação de qualidade. Um exemplo prático: Você lê um longo artigo numa revista dizendo sobre um determinado restaurante. O artigo está bem escrito, dá bastante detalhes dos tipos de comidas servidas, carta de vinhos e preços. Você se interessa e vai ao restaurante, mas quando chega lá encontra garçons mal-educados e comida não tão boa assim. Você voltaria?

Agora faça esse comparativo com um projeto de software, reflita e tire suas conclusões.

Abraços e até semana que vem !