… E a inevitabilidade das Marés

Série “De Brooks a Berkun” – 4ª Parte

“O primeiro passo é aceitar as mudanças como um estilo de vida, e não como um desvio, uma exceção“. Assim, de forma simples e direta, Fred Brooks começa a tratar o tema “Mudanças”.

Mudanças ocorrerão em um projeto não só porque o trabalho inicial (coleta e análise de requisitos e arquitetura da solução) não foi bem feito. Segundo Brooks, “a entidade Software está sempre sujeita a pressões por mudanças. Claro, como prédios, carros e computadores. Mas coisas manufaturadas raramente mudam após sua produção”. Já o software sim, dada sua “infinita maleabilidade”. Não carecemos nem mesmo das borrachas e marretas de Frank Lloyd Wright.

“Longe de mim”, diz Brooks, “sugerir que todas as mudanças de objetivos do cliente podem ou devem ser incorporadas ao desenho da solução. Um delimitador deve ser estabelecido, e ele deve ficar mais restritivo na medida em que o desenvolvimento avança, ou o projeto nunca terminará”.

O delimitador parece óbvio na teoria, mas é peça rara na prática. Se a mudança solicitada for crucial para o pleno atendimento das necessidades de negócio, o que fazer? Ignorá-la? Dizer que ela será implementada na ‘2ª versão’? Toda solicitação de mudança deve ser analisada com carinho, independente do que esteja indicando o termômetro do projeto. Independente da fase do projeto e da fase da lua.

Para Scott Berkun toda solicitação de mudança deveria seguir o mesmo processo de negociação que guiou a fase inicial de coleta de requisitos. Creio que a assimilação do processo se torna mais simples se entendermos que toda solicitação de mudança nada mais é que um novo requisito. Ou, em muitos casos, uma ‘nova versão’ de um requisito. Quando executamos corretamente a Engenharia de Requisitos, avaliamos os impactos que cada nova solicitação pode causar naquelas previamente coletadas. Agora, recebendo um change request, executaríamos o mesmo tipo de análise. Dependendo do porte do projeto e do número de dependências (grau de ‘acoplamento’) dos requisitos, tal avaliação pode ser penosa e demorada. É inevitável? Berkun sugere um breve check-list para uma avaliação prévia dos requisitos que apareceram ‘fora de hora’:

• Qual problema estamos tentando resolver? Precisamos resolvê-lo para obtermos sucesso? Precisamos resolvê-lo na iteração atual? Podemos viver com o problema?
• Trata-se de um sintoma ou uma causa? É aceitável que tratemos apenas o sintoma?
• Temos noção do impacto desta mudança?
• O custo da mudança será compensado pelo benefício gerado?
• E os riscos de novos problemas são compensados pelo benefício da mudança?

A menos que a solicitação de mudança seja absurdamente ridícula, a execução do check-list acima não será rápida e muito menos trivial. Por isso cabem aqui dois alertas: i) O cliente, ou usuário ou o stakeholder-Zezinho que solicitou a mudança deve participar do processo acima. Ele precisa ter noção do ‘estrago que está prestes a causar’. E ser co-responsável por ele; e ii) O processo de desenvolvimento em uso (a metodologia) deve tentar programar o momento certo para a avaliação das mudanças solicitadas. Como foi apresentado na 1ª parte desta série, quanto maior a incerteza (a volatilidade dos requisitos), menor deve ser a duração de uma iteração. No mundo ideal, todas as solicitações de mudanças são analisadas no momento em que a equipe planeja a próxima iteração. Se uma triagem foi executada anteriormente pelo coordenador ou analista de negócios, em conjunto com o Zezinho, então não é o mundo ideal. É o paraíso mesmo.

Scott Berkun apresenta então uma forma muito simples de gestão de mudanças, que ele chama de “versão super-lean do processo de especificação”. Consiste do seguinte:

1. O Coordenador do Projeto (ou o Analista de Negócios – interferência minha), escreve um sumário da mudança solicitada, incluindo sua relação com os objetivos do projeto e com os requisitos previamente apresentados; justifica a necessidade da mudança; e apresenta o desenho da mudança a ser implementada. Berkun sugere que este documento tenha no máximo duas páginas;
2. O programador, o testador e todos significativamente impactados pela solicitação devem analisar o documento gerado e dar suas contribuições. As mais notáveis (e ansiosamente aguardadas por todos) são as estimativas de desenvolvimento e testes.
3. O documento finalmente é apresentado aos líderes do projeto (e, como sugeri anteriormente, ao cliente, usuários, zezinhos etc). Nessa breve reunião a mudança é aceita ou não. Se recusado, diz Berkun, “o documento deve rastejar até o canto mais próximo e, soluçando incontrolavelmente, desaparecer do universo do projeto”.

Insisto que a reunião citada no item 3 acima deveria ser programada e tratar de um pool de solicitações de mudanças. Se executada ad hoc e a granel, se transformará rapidamente no ‘inferninho’ do projeto.

Fred Brooks cita um estudo de Lehman e Belady que mostra que em cada nova versão o número de novos módulos cresce linearmente, mas o número de módulos afetados pelas mudanças aumenta exponencialmente. Todas as correções e alterações de rumo (em relação à arquitetura original) “tendem a destruir a estrutura, a aumentar a entropia e desordenar o sistema”.

O divisor de águas, a separação entre marés (mudanças) ‘benéficas’ e tsunamis ‘detonantes’, deveria ser mais nítido. Mas a prática prova que não é. Está no discurso de todos os processos modernos que devemos ‘aceitar as mudanças’. Afinal, elas são inevitáveis. Mas sabemos que alguns change requests podem simplesmente inundar o projeto com efeitos colaterais mortais. O que permite sua distinção? Como avaliar corretamente o impacto e os riscos de uma mudança? Creio que é impossível sem uma clara visão da arquitetura do sistema. Um modelo detalhado, que exponha todas as interfaces entre todos os módulos, parece ser a melhor vacina contra mudanças maléficas. Mas um modelo só mede o impacto das mudanças na arquitetura do sistema. E os planos, cronogramas, agendas e finais de semana prolongados? Como ficam?

Planejar ou não Planejar? É uma questão?

Apesar de demonstrar uma certa simpatia por XP (eXtreme Programming) e suas breves iterações, Berkun reforça a utilidade dos planos de longo prazo: “mesmo quando eles são grosseiros, eles tornam as mudanças de curto ou médio prazos mais fáceis”. E justifica: “quando uma mudança nos objetivos, requisitos ou no design ocorre, raramente o plano original vai parar na lixeira”. O plano original talvez seja nossa melhor (senão única) base de comparação para uma correta avaliação das mudanças propostas. Berkun cita Dwight D. Eisenhower:

“Nenhuma batalha é vencida de acordo com um plano, mas nenhuma batalha é vencida sem um.”

Berkun (e mais um monte de gente) gosta de comparar Projeto com partidas de xadrez. Tanto que o capítulo de seu livro que trata de forma mais específica o tema mudanças chama-se “Middle-Game Strategy”. Cada decisão do gerente do projeto, assim como cada movimento de um enxadrista, só pode assumir uma de duas características possíveis:

• Conservadora: deixa-o com o maior número possível de ‘movimentos futuros’, de opções. Em um projeto pode significar uma desaceleração do ritmo. Mas, escreve Berkun, “este é o preço do seguro que você está comprando”.
• Agressiva: mostra total domínio e comprometimento com uma estratégia. O gerente confia em seu plano e em sua ‘força’.

A ausência de um plano não permite nem mesmo avaliar o perfil das decisões do gerente do projeto. E a maneira como elas são apresentadas pode ser um péssimo indicador. Lembra aquela piada do marido que diz sempre ter a última palavra em casa: ‘Sim senhora!’.

Para Scott Berkun o Gerente que tem total controle do projeto está sempre ‘um passo à frente’. Para tanto ele sugere a realização de dois check-lists para a verificação de nossa sanidade, digo, da sanidade do projeto. O primeiro é tático (diário), e apresenta as seguintes questões:

• Quais são nossos objetivos e compromissos? Eles ainda são válidos?
  No meio de tanto trabalho, diz Berkun, “é muito fácil perder os objetivos de vista”. Olhar para eles diariamente é uma forma de manter o foco e avaliar corretamente as prioridades.
• O que estamos realizando hoje contribui para a realização dos objetivos?
  É claro como os trabalhos em execução contribuirão para a satisfação dos objetivos e dos requisitos? Se não, diz Berkun, “o barco tá começando a ficar à deriva”.
• Os trabalhos estão sendo concluídos de forma a satisfazer os requisitos e cenários?
  “Há mil maneiras de completar uma unidade de trabalho que não satisfaz o espírito e a intenção do design“, lembra Berkun. Sabemos que a distância entre o “tá pronto” do programador e o “tá pronto” do usuário pode ser quilométrica.

O outro check-list é estratégico e, segundo Berkun, deveria ser executado semanalmente ou mensalmente, seja em reuniões de discussão do status do projeto ou mesmo individualmente. As questões são:

• Qual a probabilidade de atingirmos o próximo milestone com o apropriado nível de qualidade?
  Com certeza aconteceram mudanças desde o trabalho de estimativas. E mesmo que não, não custa nada perguntar ao time se o cronograma segue verdadeiro e exequível.
• Quais ajustes são necessários para aumentar tal probabilidade?
  Berkun diz que “é raro obter 100% de confiança na próxima data de qualquer um que seja honesto e são”. Portanto esta pergunta (quase) sempre será colocada.
• Como executar tais ajustes com cuidado e de forma isolada?
  “Um telefonema? Um email? Despedindo alguém?”. Berkun alerta que devemos pensar de forma ‘cirúrgica’, mas não devemos temer as ações e decisões que precisam ser executadas/tomadas.
• Quais são os maiores ou mais prováveis riscos que enfrentamos hoje, na próxima semana ou no próximo mês? E quais são as contingências?
  A simples identificação dos maiores ou mais prováveis riscos já é, de acordo com Berkun, um grande passo no sentido de prevení-los.
• O mundo mudou e eu não estou sabendo?
  Os patrocinadores ainda são os mesmos? E seus objetivos, mudaram? O time se preocupa com algo que eu não conheço? Nossas antenas e sentimentos devem estar atentos para mudanças que ocorram tanto no micro-universo quanto no macro-universo do projeto.

Na sequência do mesmo capítulo de “The Art of Project Management”, chamado “Middle-Game Strategy”, Scott Berkun apresenta várias outras ‘ferramentas’ para o (micro) gerenciamento (diário) do projeto. Brinquei com os parênteses para destacar a mensagem: gerenciar um projeto significa (tentar) cuidar de um número imenso de varíaveis, a maioria delas muito pequena e volúvel, durante todo o dia. Todos os dias.

===

1. Lehman, M. e Belady, L, “Programming System Dynamics”, ACM SIGOPS (1971).