Série “De Brooks a Berkun” – 3ª Parte
Em 1986 Fred Brooks publicou o artigo “No Silver Bullet”, que aparece como o capítulo 16 da edição que comemorou os 20 anos de “The Mythical Man-Month”. Para Brooks, “ainda cometemos erros de sintaxe, com certeza, mas eles não são nada quando comparados aos erros conceituais da maioria dos sistemas”. Scott Berkun cita Brooks na abertura do capítulo “How to figure out what to do”, o terceiro de “The Art of Project Management”:
“A parte mais difícil da construção de software é decidir o que construir. Nenhuma outra etapa do trabalho conceitual é tão difícil quanto a fixação dos requisitos técnicos detalhados, incluindo todas as interfaces com usuários finais, com máquinas e outros sistemas. Nenhuma outra etapa compromete tanto o projeto se executada erroneamente. Portanto, a função mais importante que o construtor de software executa para seu cliente é a extração iterativa e o refinamento dos requisitos do produto”.
Para Brooks, trata-se de uma função que deveria ser executada por uma pessoa ou um grupo pequeno de pessoas. Seria, para ele, uma forma de garantir a ‘Integridade Conceitual’ de uma solução. A separação desta etapa, quando decidimos ‘o que deve ser construído’, da etapa de implementação, quando decidimos ‘como construir’, seria outra forma poderosa de buscar tal integridade.
Berkun chama de ‘insanamente simples’ a forma como ele vê a etapa de planejamento de um projeto. Ela é representada no gráfico abaixo:
E, seguindo em sua ‘insanidade’, Berkun justifica a necessidade de Planos. Segundo ele, os planos “funcionam como um remédio contra todo tipo de estupidez porque forçam que questões importantes sejam resolvidas enquanto há tempo para considerar outras opções”.
Apesar de uma (sutil) diferença, ambos os autores concordam com a separação das fases de Domínio do Problema (ou ‘o que’, coleta de Requisitos, Definição etc) e de Domínio da Solução (ou ‘como’, design/especificação etc). Uma distinção óbvia, simples, mas deveras negligenciada. Quantas e quantas vezes testemunhamos ‘analistas’ (assim, entre aspas mesmo) discutindo ‘comos’ em dias iniciais de um projeto?
Brooks radicaliza ao propor que o principal artefato gerado pelo Arquiteto de uma solução é o Manual, uma especificação de toda a parte externa de um sistema. É o manual do usuário mesmo, nas fases iniciais de um projeto! Um documento que não deveria se preocupar em explicar os ‘comos’.
As Visões e o Documento de Visão
Berkun é um pouco mais metódico e indica a necessidade de 4 documentos principais. Antes, porém, ele alerta para a criticidade do balanceamento de três perpectivas:
- Negócio: “… quando equipes de engenharia ignoram como seu negócio funciona, muitas decisões da gerência parecerão ilógicas ou estúpidas”;
- Tecnologia: “…é o mindset de construção e materiais. Tem o foco em ‘como’ as coisas devem ser feitas”;
- Cliente: “A mais importante das três perspectivas… Mas, infelizmente, a mais fraca em muitas organizações.”
Segundo Berkun, as três perpectivas sempre se sobrepõem. “Cada consideração ‘de negócio’ tem implicações Técnicas e para o Cliente (e assim por diante)”. E cada decisão pode favorecer determinado ponto de vista, em detrimento de outro. “Ao investir tempo explorando cada uma das perspectivas”, diz Berkun, “é possível ver oportunidades para melhores decisões estratégicas”.
Para Berkun, a fase de planejamento de um projeto só se encerra quando os 4 documentos propostos por ele estão prontos. Ou, em suas palavras: quando “as decisões que eles contêm estão tomadas”. Os documentos são:
- Marketing Requirements Document (MRD)
Trata-se da ‘Visão do Mundo’ apresentada pelo negócio ou sua equipe de marketing. Apresenta os objetivos do negócio e ajuda a definir “o que” o projeto deve contruir visando sua satisfação;
- Documento de Visão (Escopo)
Define os objetivos do projeto, explica sua lógica e apresenta características (em alto nível), requisitos e datas. Definem diretamente “o que” o projeto deve realizar;
- Especificações
Define o “como” de um projeto, com uma perspectiva de design e engenharia;
- Work Breakdown Structure (WBS)
Mostra como o time trabalhará para realizar o projeto.
Berkun também parece cair na ‘armadilha’ waterfall quando propõe que a fase de planejamento de um projeto só se encerra com a entrega (definitiva) destes 4 documentos. Apesar de indicar os aspectos iterativos e incrementais de sua elaboração. Não deveriam ser apenas os ‘acidentes’ (também conhecidos como ‘mudanças’) que nos forçam a voltar a tais documentos (tal fase).
Se o MRD (que pode ser um RFP – Request for Proposal, por que não?) é (ou pelo menos deveria ser) elaborado pelo Cliente, temos que o primeiro documento confeccionado pelo time do projeto é o Documento de Visão. Segundo Berkun, além de apresentar e explicar todas as características (features) do produto a ser gerado, como no Manual sugerido por Brooks, o documento deve:
- Explicar o projeto em apenas uma sentença (uma ‘declaração de visão’);
- Mostrar como o projeto contribuirá para a satisfação dos objetivos do negócio;
- Apresentar as características/cenários essenciais para os Clientes (prioridade 1);
- Mostrar as características/cenários considerados ‘desejáveis’ mas não essenciais (prioridade 2);
- Apresentar os clientes e os problemas que o projeto deve solucionar para eles;
- Bem como apresentar os atores (stakeholders);
- Explicar por que os clientes comprariam (ou alugariam) o produto do projeto;
- Apresentar os concorrentes e uma comparação de seus produtos com aquele que o projeto deve gerar;
- Explicitar o que está “fora do escopo” do projeto;
- Mostrar quais os riscos do projeto;
- Suas dependências externas (sub-contratados e afins);
- Em alto nível, como o trabalho será organizado; e
- Apresentar todas as suposições e dependências.
Ou seja, o Documento de Visão, como proposto por Berkun, compila todas as informações e decisões elaboradas no planejamento inicial de um projeto. Esta compilação, escrita de forma a ser acessível/legível para todos os atores de um projeto, se torna um dos principais meios de comunicação/negociação com os clientes. Não entendo porque Berkun não sugere a inserção de um cronograma. Outra alteração que eu faria é a criação de uma ‘prioridade 3’, com a lista de todas as características/cenários classificados como ‘perfumaria’ ou supérfluos.
Berkun sugere que 5 iterações seriam suficientes até a geração de uma versão final do Documento de Visão. Acho arriscado fixar assim o número de ‘versões’. Cada projeto pode determinar um ritmo/ciclo bastante particular. Mas creio que um mínimo de 3 iterações sejam necessárias. O trabalho nas Especificações e na WBS gerará, sem dúvidas, alterações na Visão.
Por fim, Berkun destaca as 5 qualidades de uma “Boa Visão”:
- Efeito “Simplificador”;
- Apresenta de 3 a 5 objetivos de alto nível;
- Consolidada;
- Inspiradora; e
- Memorável.
O fato do autor, no caso Scott Berkun, manter um blog faz com que seu livro seja constantemente atualizado. Recentemente Berkun publicou um pequeno artigo chamado “Why vision documents stink“. Isso mesmo, ‘cheiram mal’. Ele comenta que em levantamentos informais, em suas palestras por exemplo, constatou que a grande maioria dos Documentos de Visão são muito ruins. Ele tem três teorias para o problema:
- A falta de um ‘autor-líder’ que, no meu ponto de vista, deveria ser o próprio Arquiteto;
- Os documentos não seriam escritos para servir ao leitor, denotando falta de compreensão e de interação com o cliente; e
- A confusão entre ‘hype’ e realidade, que geraria documentos meio ‘marketeiros’ e pouco objetivos.
