“Para o observador casual, definições do problema podem parecer desperdício. É tempo gasto longe do teclado e a educação ocidental nos ensina que estamos enrolando ou sendo improdutivos quando estamos ‘só conversando’. Mas o Lean é cheio de paradoxos como esse.”

“Muito do Lean é baseado no Pensamento Sistêmico e uma definição de problema bem colocada pode levar o time para além de suas preocupações com a solução – para uma compreensão mais ampla do contexto.”

“O Lean nos pede para reduzir tensões e inconsistências no sistema. A definição do problema articula um objetivo consistente. São comuns os projetos que sofrem porque seus participantes não estão resolvendo o mesmo problema. Uma definição de problema bem escrita oferece uma visão consistente de direção. Como tal, ela pode ser uma poderosa ferramenta para o time e para a gestão.”

“Uma boa definição do problema pode funcionar como um catalisador para a auto-organização.”

“Em uma verdadeira organização Ágil aqueles que são responsáveis pela solução do problema participam da definição do problema. Essa definição deve ajudar a canalizar a energia da organização na direção correta.”

Lean Architecture | James Coplien e Gertrud Bjørnvig
Wiley, 2010 – Págs. 68~74

Eu sabia que não estava sendo original quando escrevi que Histórias – de Valor ou de Usuários – são catalisadoras. Só não lembrava a origem.“Antes de iniciar um sprint de criação-de-valor-para-o-cliente precisamos de um backlog inicial do produto. E para gerar esse backlog nós precisamos da visão do produto. Muitas organizações também acham útil a criação de um roadmap preliminar, definindo uma série de releases incrementais. Chamo as atividades que criam esses artefatos de envisioning ou product-level planning.”

“O envisioning não deve ser confundido com um pesado e cerimonioso processo de planejamento. No Scrum, nós não acreditamos que podemos (ou devemos) conhecer todos os detalhes de um produto antes de começarmos. Entretanto, nós entendemos que o financiamento de um produto não pode começar sem uma visão; sem um entendimento adequado acerca dos clientes, das features e da solução em alto nível; nem sem uma ideia de quanto o produto vai custar.”

“Não gastamos muito tempo ou esforço no envisioning porque queremos rapidamente passar do estágio do achismo – quando a gente pensa que conhece as necessidades dos clientes – para as etapas de feedback rápido – para os sprints de criação de valor.”

Essential Scrum | Kenneth Rubin
Addison-Wesley, 2013 – Pág. 287

“O primeiro passo no Scrum é a elaboração da Visão do Produto pelo Product Owner.”

Scaling Lean & Agile Development | Craig Larman e Bas Vodde
Cap. 12 – Scrum Primer, por Pete Deemer & Gabrielle Benefield
Addison-Wesley, 2009 – Pág. 311

1. Uma VISÃO projeta um futuro onde determinado problema deixa de existir. Uma VISÃO assume o entendimento prévio desse problema.
2. Ignorar a definição do problema e tratar o envisioning como o “estágio do achismo” (guessing, no original) é frágil e perigoso.
3. Entender que a elaboração da VISÃO é responsabilidade exclusiva de um PO é detonar, logo de cara, uma boa oportunidade de formar um time de verdade.

“A diretriz fundamental de qualquer sistema verdadeiramente enxuto consiste em estabelecer e entregar valor definido pelo cliente”.

“ não devemos gastar esforços ou recursos antes de termos um profundo entendimento do valor definido pelo cliente.”

Sistema Toyota de Desenvolvimento de Produto | James Morgan e Jeffrey Liker
Bookman, 2008 – Págs. 45~46

“A característica organizacional definidora do modelo do Spotify é o conceito de squads com ‘baixo acoplamento e alto alinhamento’. A tese central aqui é que ‘alinhamento permite autonomia – e quanto maior o alinhamento, mais autonomia é possível dar’. É por isso que a empresa passa tanto tempo alinhando todos com objetivos e metas antes de iniciar um trabalho.”

Tempo Talento Energia | Michael Mankins e Eric Garton
figurati, 2017 – Pág. 163

1. A distância que separa a Toyota do Spotify é a mesma que separa o Japão da Suécia. Mas uma coisa elas parecem ter em comum: tempo pra pensar.
2. Não é curioso que esse tempo para pensar não seja considerado trabalho? Repare na frase destacada no último parágrafo acima. Coplien e Bjørnvig, citados lá no início, já haviam alertado para essa característica bem ocidental de não relacionar esse tipo de conversa com trabalho.

“Quando você dispara qualquer coisa nova, há forças te puxando para todas as direções. Há coisas que você pode fazer, coisas que você gostaria de fazer e coisas que você precisa fazer. Comece pelo que precisa ser feito. Comece pelo epicentro.”

Rework | Jason Fried & David Hansson
Crown Business, 2010 – Pág. 72

“Tome uma grande decisão sobre sua Visão de forma antecipada e todas as futuras pequenas decisões se tornarão bem mais fáceis.”

Getting Real | 37signals
37signals, 2006 – Pág. 43

“Todo o trabalho com requisitos é precedido por algum tipo de processo de iniciação: alguém tem uma ideia de que algo deve ser desenhado e construído.”

“Se não formos cuidadosos, a ideia inicial vai colocar todo o processo em um caminho improdutivo do qual nunca vamos nos recuperar. Se os participantes não começarem pensando em conjunto, vamos perdê-los antes de ganhá-los.”

“Como podemos sintetizar a grande variedade de pontos de partida potenciais em uma plataforma única e sólida para a exploração de requisitos? Uma solução possível é entender cada projeto como uma tentativa de resolver algum problema e então reduzir cada ponto inicial a uma forma comum de descrição do problema.

“Um problema pode ser definido como: A diferença entre as coisas conforme são percebidas e as coisas conforme são desejadas.”

Exploring Requirements: Quality Before Design | Donald Gause e Gerald Weinberg
Dorset House, 1989 – Pág. 49

“A palavra problema sempre significa algo ruim, como em ‘Houston, temos um problema’ Mas as inovações bem sucedidas sempre envolvem mais atenção ao problema do que às soluções. Einstein um dia disse, “Se eu tiver 20 dias para resolver um problema, gastarei 19 para defini-lo”.

The Myths of Innovation | Scott Berkun
O’Reilly, 2007 – Pág. 127

“O problema não é o problema. O problema é a sua atitude em relação ao problema.”

– Capitão Jack Sparrow

1. Pois é, terceirizei a argumentação. Parti dos originais e a tradução é livre, provavelmente enviesada e eventualmente desastrada. Por  favor, não morda o meu dedo.
2. Se você não entendeu minha motivação, por favor, veja o artigo anterior.
3. Se tem o que acrescentar, por favor, comente!
4. Aquela foto bem sacada de dentro do buraco é da Alexandra Brovco.

Em tempos de big data pra cá e muito ruído e contação de histórias vazias pra lá, é sempre bom relembrar o básico, (porque talvez ele já não seja assim tão) óbvio e intuitivo. Do começo: o que é informação? Difícil ser mais direto e eficaz que Bateson: “informação é a diferença que faz diferença“. A fórmula ao lado¹ nos diz a mesma coisa, de um jeito diferente.

Na prática: o previsível, o corriqueiro, o redundante e o repetitivo não nos ensinam (informam) nada ou praticamente nada. (Esta frase  parece querer confirmar o que ensina.) E o valor daquilo que pouco informa é irrisório ou nulo. Particularmente em projetos, porque informação é sua principal matéria-prima.

Choque de realidade: talvez você já tenha visto por aí um catatau com dezenas ou centenas de páginas chamado “especificação funcional” (sic) ou algo parecido. Aplique a fórmula ou regrinha acima para ter uma rápida noção do valor, da quantidade de informação de verdade que aquele documento carrega. Lembre-se das redundâncias, ambiguidades, contradições e encheção de linguiça ali persistida. Agora considere quanto aquele entregável (sic 10x) custou: as horas gastas em entrevistas, reuniões, revisões do documento etc. O quão economicamente útil é um documento assim?

Vale dizer, o problema nem é necessariamente o formato. Tem muito quadro kanban por aí que mal vale uma nota de três reais, apesar da sua belezura e pseudo-modernidade. Antes da forma, deveríamos nos preocupar com o conteúdo.

+ Comunicação

O Houaiss nos ensina que comunicação é a “transmissão de uma mensagem”. A crença na eficácia desta comunicação de uma via tem causado sérios problemas. Até no frio relacionamento entre computadores há a preocupação com a recepção – com a garantia da entrega de uma mensagem. Na comunicação entre pessoas a questão é um tanto mais complexa.

Existem diversos modelos² que ilustram todo o processo de comunicação entre pessoas. Vou apelar para um básico³:

• Transmitida: a informação foi enviada;
• Recebida: a pessoa na outra ponta recebeu a informação;
• Entendida: o receptor entendeu a mensagem. Se não, é provável que o processo se reinicie com a transmissão da informação de forma diferente. Este ciclo pode se repetir diversas vezes, até que haja o entendimento;
• Aceita: o receptor concorda com o que foi informado. Se o ciclo anterior era para compreensão, agora pode existir um ciclo de negociação. Que também pode requerer um reinício – um retorno ao primeiro estado;
• Convertida em Ação: o receptor faz algo a respeito da informação que recebeu, entendeu e aceitou.

Em nosso dia a dia, em todo tipo de comunicação, o processo pode ser interrompido em qualquer ponto acima. Você pode, por exemplo, entender o que está escrito aqui e não aceitar e consequentemente não fazer nada a respeito. No trabalho com requisitos é importante que o analista busque o quinto estado – a conversão em ação – de toda informação de fato relevante para o projeto.

Quando trabalhamos em projetos, particularmente com requisitos, deveríamos ver comunicação da seguinte maneira⁴:

Comunicação = Informação * Relacionamentos * Feedback

A informação vale por si só, por ser “a diferença que faz diferença”. Mas sua simples transmissão não tem valor nenhum. A fórmula acima sugere que a comunicação vai de fato ocorrer se existir um bom relacionamento entre os interlocutores. Mas não basta. Mesmo no mais harmonioso dos ambientes, a comunicação exige mecanismos de feedback que garantam que a mensagem transmitida seja recebida, entendida, aceita e, de alguma maneira, convertida em ação.

O alcance da definição acima ultrapassa e muito o escopo desta série. Tentarei mostrar apenas a relevância daquela fórmula nos trabalhos de desenvolvimento e análise de requisitos.

Para tanto, que tal outra fórmula⁵?

Resposta = Informação + Confirmação + Ruído

A confirmação verbal do entendimento é a melhor depois da telepatia. -Jurgen AppeloA confirmação é o tal mecanismo de feedback da fórmula anterior. Precisamos dela, mas nem sempre a conseguimos na primeira resposta. Independentemente da qualidade da pergunta. Por isso consideramos que uma resposta sem confirmação está incompleta. E formulamos a questão seguinte com o único propósito de obtê-la.

Entre informações e confirmações, invariavelmente recebemos ruídos. Merece este nome – ruído –  aquela palavra, gesto, olhar, sussurro ou tic nervoso que não conseguimos decifrar em um primeiro momento. Pode não ser nada. Mas pode ser uma informação ou mesmo uma confirmação carente de atenção. Decifrar ruídos no sentido de obter boas respostas e excelentes requisitos é uma das artes (secretas?) dos bons analistas.

Esta série ainda merecerá um ou mais capítulos específicos sobre conversas, perguntas , respostas e ruídos. O básico do básico sobre informação e comunicação foi colocado. No próximo artigo conversaremos especificamente sobre informações em requisitos. Te espero lá.

Notas

1. Surrupiada do fundamental Managing the Design Factory, de Donald Reinertsen (Free Press, 1997). Ainda devo a entrada deste em nossa biblioteca.
2. Um dos modelos de comunicação mais referenciados foi criado por Virginia Satir e publicado em The Satir Model: Family Therapy and Beyond (Science and Behaviour Books, 1991). Você entendeu bem: terapia de família! Gerald Weinberg utiliza o Modelo Satir em diversos livros.
3. Scott Berkun também cita o Modelo Satir em A Arte do Gerenciamento de Projetos (Bookman, 2008). É dele o modelo básico utilizado neste artigo.
4. Esta fórmula veio de Management 3.0, livro de Jurgen Appelo bastante citado por aqui e em outros lugares.
5. A última fórmula foi retirada de Redefinindo a Análise e o Projeto de Sistemas, de Gerald Weinberg (McGraw-Hill, 1990) – um livro que todo analista de negócios deveria conhecer. Para não ter o mesmo destino dos analistas de sistemas…

Relembrando e reforçando as duas provocações que apresentei:

• Não devemos seguir espalhando por aí que “o importante é que a Análise de Negócios seja realizada, não importa por quem”. Esta colocação, por bem intencionada que seja, gera dois efeitos muito negativos: i) parece diminuir a importância e simplificar (no mal sentido) a Análise de Negócios; e ii) deprecia todos que escolheram a Análise de Negócios como profissão. Pergunta (retórica): na ausência de analistas de negócios, como podem a profissão e respectivo corpo de conhecimentos evoluir?
• Apesar de dever seu ressurgimento à TI, está chegando a hora da Análise de Negócios decretar sua independência. Por definição, analistas de negócios ajudam uma organização a descobrir e desenvolver soluções para problemas de negócios. Qualquer tipo de problema! Mas…

Definições Destroem

A definição destrói Não há nada definitivo neste mundo. – Bob DylanNão precisamos ser radicais como Dylan, mas é sempre saudável alguma reflexão sobre definições e nomes. Pense um pouco sobre o termo “Análise de Negócios”. Talvez você perceba, como eu (depois de monte de gente¹), que ele é ruim pra chuchu. Veja o que diz o Houaiss:

• análise s.f. 1 estudo das diversas partes de um todo 2 investigação; exame
• negócio s.m. 1 transação comercial 2 local onde se realiza essa transação 3 algo que não se sabe ou não se lembra o nome; qualquer coisa; trem (em mineirês e fora do Houaiss)

Pegando apenas o que nos diz respeito, podemos concluir que Análise de Negócios é “o estudo das diversas partes de um local onde se realizam transações comerciais”. O estudo por si só? Não faz sentido. Ou faz tanto quanto propor “a investigação de um trem“.

Reforço a definição que sugeri no início do artigo: “analistas de negócios apoiam a descoberta e o desenvolvimento de soluções para problemas de negócios”. Os analistas apoiam – o que significa que suas atividades nunca são um fim em si mesmas. Eles apoiam dois tipos de atividades: de descoberta e  desenvolvimento (de soluções para problemas de negócios). Veja o diagrama abaixo:

O losango já foi utilizado por vários autores para ilustrar o caminho para a solução de problemas, dentre eles Scott Berkun² e Tim Brown³. Berkun o chamou de “espaço do problema”. A figura indica que nós aumentamos esse espaço – cogitando e validando alternativas de solução – antes de selecionar, desenhar e construir a mais adequada. Brown nomeia as pontas do losango de maneira um pouco diferente. A primeiro seria de divergência – quando criamos escolhas, a segunda de convergência – quando fazemos escolhas. Quase escondo a provocação nas palavras entre parênteses: a análise – o estudo das diversas partes de um todo – é só parte do trabalho! Ela não tem sentido nenhum sem sua cara metade, a síntese. Houaiss:

• síntese s.f. 1 reunião de elementos diferentes num todo coerente 2 operação intelectual que apreende o todo partindo dos elementos que o constituem 3 exposição abreviada e genérica; resumo

Se a análise é o estudo das partes, a síntese as combina na elaboração de um todo. Não há processo ou método para solução de problemas que não obedeça essa ordem. Exatamente por isso o termo “análise” é tão ruim¹. Não se trata de chatice de dublê de filólogo. Nomes e definições podem ser perigosos ou até mesmo destrutivos. Se não, como explicar que muitas empresas utilizem analistas de negócios apenas em 1/5 das funções sugeridas no diagrama acima?

Ainda não cheguei ao cúmulo de sugerir a troca do nome da disciplina ou da profissão. Não sou louco o suficiente. Apenas insisto para que a Análise de Negócios seja vista de forma mais ampla. Reparem, ela nem se limita ao losango no modelo acima. Existem outras três áreas, não limitadas aos projetos, que merecem o apoio dos analistas de negócios. São elas:

• Gestão de Relacionamentos: se os analistas de negócios funcionam como uma ligação entre todas as partes interessadas de um projeto, é natural que se espere deles uma considerável contribuição na gestão de relacionamentos: gerenciamento de expectativas; resolução de conflitos; averiguação da satisfação de clientes e usuários etc
• Gestão do Conhecimento: uma responsabilidade muito maior do que a danosa e usual percepção de que os analistas devem “documentar tudo”. Existem documentos – existe a necessidade deles, mas há algo muito maior sendo gerado a cada projeto, por menor que ele seja. É conhecimento novo. Algo que, se não for corretamente gerenciado, será desperdiçado.
• Manutenção da Qualidade: algo que deve ser incorporado em toda e qualquer função. Os analistas de negócios têm condições de zelar não apenas pelo que desenvolvem, mas também pela qualidade de todo o trabalho executado em um projeto e fora dele.

Para Pensar e Repensar

Você pode estar perguntando, com razão, o que esse papo tem a ver com as duas provocações que abriram este artigo. Tudo:

• Cabe um mundo inteiro na distância entre analistas de negócios e tiradores de pedidos. A Análise de Negócios lida com domínios cognitivos de maior dificuldade: Solução de Problemas, Análise e Síntese; Pensamento Criativo; Pensamento Sistêmico; Complexidade etc. Entender ou pretender que qualquer outro profissional possa executá-la, mesmo em projetos aparentemente mais simples, é ingênuo e perigoso.
• Mais importante é entender que a Análise de Negócios não existe sem os analistas. A disciplina definhará se não houver quem a defenda e estude  como uma especialização.
• Ao propor o modelo acima forço um distanciamento de TI. Até então utilizava disciplinas da Engenharia de Software – Modelagem de Negócios e Requisitos – para mostrar o que os analistas de negócios podem fazer. Elas seguem existindo e continuam importantes para os analistas. Mas devem ser percebidas como itens de uma caixa de ferramentas que precisa ser consideravelmente maior e mais diversificada. Todas as empresas estão carentes de bons solucionadores de problemas. Um time especialista em solução de problemas, qualquer tipo de problema, seria uma cartada e tanto. Você não acha?

Notas

1.  Esse papo de Análise + Síntese é quase tão velho quanto andar pra frente. Só foi requentado neste artigo porque parece esquecido ou ignorado quando o assunto é a Análise de Negócios. Gerald M. Weinberg, falando para analistas de sistemas em “Redefinindo A Análise e o Projeto de Sistemas” (McGraw-Hill, 1990), já tinha feito o mesmo. Pelo que sei, Weinberg foi o primeiro a destacar o quão ruim é o termo “Análise” e a propor um tal Sintetista. Desta leitura derivei outra provocação: o analista de sistemas falando para o analista de negócios, “eu sou você amanhã”.
   Weinberg teve vários títulos publicados no Brasil mas, salvo engano, estão todos esgotados. Analistas de negócios deveriam ler todos que encontrar nos sebos da vida.
2. Em “A Arte do Gerenciamento de Projetos“, Bookman (2008).
3. Em “Design Thinking – Uma Metodologia Poderosa para”, Campus (2010). A editora deu uma bela barbeirada no título, tanto que temo pela  tradução. Se puder, opte pelo original: “Change by Design” (Harper Business, 2009).
4. A Extensão Ágil do BABoK®, em fase de revisão pública, é muito feliz ao sugerir uma divisão muito parecida com aquela ilustrada pelo losango acima. Só há um termo diferente: Delivery (entrega) ao invés de Desenvolvimento.

O mundo mudou. E não me lembro qual foi a última vez que utilizei um título tão “fraquinho”. Como o antecipei nas duas partes anteriores, seguirei com ele.

O mundo muda todo dia. Em negócios e TI a impressão que temos e deixamos é de uma dinâmica quase caótica. Uma volatilidade que, segundo experts, gera uma população repleta de pessoas inseguras, ansiosas e desconfiadas. Não raro, exageramos os possíveis impactos de determinado acontecimento. Outras tantas vezes subestimamos tendências. Como a imensa maioria das pessoas é desprovida de dons proféticos e bolas de cristal, é natural que seja assim. Como é normal que indivíduos apresentem reações muito diferentes quando defrontados com uma mesma mudança. Mas o papo aqui é ou deveria ser sobre projetos e seus gerentes.

Projeto é mudança. Talvez esta seja a verdade absoluta mais ignorada ou desprezada. Quando uma organização dispara um projeto ela está implementando uma mudança. Aqueles que foram selecionados para o trabalho devem estar preparados para lidar com todos os reflexos gerados por ela. Esses reflexos, com maior ou menor intensidade, fazem com que os projetos sejam naturalmente instáveis. Ainda bem que eles têm data para acabar, não é mesmo?

Porque é natural do ser humano o gosto ou necessidade de estabilidade. Mesmo aqueles viciados em adrenalina, como os praticantes de esportes radicais, valorizam muito os períodos de calmaria. O fato é que estabilidade perene apenas é possível em processos – em ações que repetimos ad infinitum. Projetos são únicos em seus objetivos e restrições. Eles sempre são inéditos de alguma maneira. Por isso é estranha uma certa obsessão por projetos estáveis. Surrupiando um dito de Michael Hammer¹, “projeto instável” é um oxímoro em vias de se tornar um pleonasmo. Por isso é equivocada a crença em planos. Ou, melhor dizendo, a crença na certeza dos planos. Mas, antes de “atacar” os planos (se é que vou fazê-lo), vamos falar sobre a crença. De onde ela vem? O que a alimenta?

Durante muito tempo jogamos praticamente todas as nossas fichas em padrões e metodologias que, de uma forma ou de outra, prometem estabilidade e previsibilidade. Apesar das promessas raramente cumpridas, particularmente em projetos de TI, essas propostas se espalharam como notícia ruim. As falhas, quando reconhecidas, raramente eram atribuídas aos padrões e metodologias adotados. Quase sempre a culpa é de quem os implementou. Mercados foram criados em torno dessas propostas. E elas se solidificaram. No mau sentido.

Temos hoje um imenso “sistema legado” de processos de gerenciamento e desenvolvimento. Usei o termo “sistema legado” exatamente porque ele nos remete aos nossos legados mais famosos – igualmente caros e não muito “simpáticos” a mudanças. O “sistema” que aqui trato é composto por treinamentos, certificações, ferramentas, corpos de conhecimento e, principalmente, cultura. Ou, para voltar ao termo utilizado anteriormente, crença.

Em determinado momento da história alguns componentes do “sistema” se iludiram com sua pretensa estabilidade. Algumas palavrinhas que guiam os tempos modernos, como inovação e criatividade, são simplesmente ignoradas pelo “sistema”. O próprio sentido de mudança e o entendimento de que não se trata de algo indesejável, mas necessário e inevitável, não encontra respaldo real em algumas das peças mais relevantes do “sistema legado” de processos de gerenciamento e desenvolvimento.

Seria então o caso de jogar todo o “sistema” no lixo? Claro que não. Sugestões assim são ingênuas (mas pouco inocentes). Ingênuas por não perceberem que o “legado” criado, assim como seus pares, é complexo e caro, mas não deixa de ter seu valor. Acredito que, de todos os seus componentes, o primeiro a ser questionado deveria ser a crença ou cultura. Questão de coerência: como um gerente de projetos – um profissional especializado na implementação de mudanças – pode resistir tanto em mudar?

Ao questionar a crença, ao adotar um perfil mais cético, o profissional tomará os outros componentes do sistema com outros olhos. Ele tenderá a ser mais cuidadoso e desconfiado. Mas será também mais curioso.

Não se iluda. Mudar cultura ou questionar a crença não é nada fácil. Também não é algo que possa ser implementado como um projeto. Mas é fácil apontar a trilha. Aliás, é até meio besta: 1) Aceitar que mudanças são inevitáveis; 2) Questionar certezas absolutas; e 3) Não ter medo do novo e muito menos de aprendê-lo.

O Argumento Derradeiro

Há poucos dias, Scott Berkun, autor de “A Arte do Gerenciamento de Projetos” (Bookman, 2008), retomou um tema que vou traduzir da seguinte maneira: Gerenciamento de projetos é chato? Berkun responde que “o gerenciamento de projetos é tão chato quanto a coisa que está sendo gerenciada”. Por favor, me desculpe a chatice, mas releia a frase negritada.

Em um artigo anterior Berkun já havia comentado sua impressão de que o Gerenciamento de Projetos não é muito respeitado. E, em outras palavras, não é uma função ou profissão sexy, atraente. Você não vê nenhuma criança ou adolescente dizendo: “Quando eu crescer quero ser gerente de projetos”. Mas Berkun argumenta que diretores de cinema, técnicos de futebol, produtores de discos e várias outras profissões são variações de gerentes de projetos. A diferença é que eles usam outros termos. Nomes que tornam explícita a coisa que gerenciam. E fazem daquela função algo mais atraente, com certeza.

Me lembro quando chegou a hora de definir minha profissão. Meu velho, como de costume, deu um conselho rápido e nada rasteiro: “Escolhe qualquer coisa, menos contabilidade”. Ele era contador. Dos bons, diga-se de passagem. Trabalhava 30 horas por semana e fazia de tudo para tornar sua rotina menos chata. Mas ele sabia que estava aprisionado em uma função que é, por natureza, 90% do tempo enfadonha.

Gerenciamento de projetos pode ser tudo, menos chato. Mas, por incrível que pareça, conseguimos torná-la uma profissão dura e carrancuda. Quadrada mesmo. E me parece claro que os ângulos retos de todos os componentes do nosso “sistema legado” são os maiores responsáveis por isso.

.:.

Nome aos Bois e Pingos nos ‘is’

Ao bom entendedor que por aqui navega ficou claro que dentre os componentes do “sistema legado” tratado acima figuram: PMBoK, CMMI, Prince2, MPS.br, ITIL, afins e derivados. Manada devidamente nomeada, resta agora esclarecer alguns pontos:

• PMBoK e BABoK não tratam de nenhum tipo específico de projeto. Então, pode parecer equivocada uma crítica que considere apenas projetos de TI. Não na minha opinião. Ainda avalio se vale a pena um artigo sobre “O Problema com os BoK’s”. Vale a pena ou a espada?
• Não estarei aqui para ver a aposentadoria do “sistema legado”. Ele resistirá e sobreviverá por um bom tempo. A torcida, de certa forma otimista, é para que ele encontre e beba de um tipo de fonte da juventude. O tipo de ‘service pack’ que o BABoK receberá, por exemplo², é uma de várias possibilidades de rejuvenescimento. Os únicos pré-requisitos são humildade e olhos e ouvidos abertos.
• Por ser longevo, o “sistema legado” não pode ser ignorado por nenhum profissional razoavelmente sério. Há muito conhecimento ali.
  Mas é um pecado iniciar a profissão pelo lado quadrado da força. Quem quer iniciar uma carreira em gerenciamento de projetos deveria, antes de qualquer coisa, estudar alguns documentos que ainda são meio “apócrifos”. Eu iniciaria por “A Arte do Gerenciamento de Projetos” (Scott Berkun. Bookman, 2008) e “Agile Project Management – Second Edition” (Jim Highsmith. Addison-Wesley, 2010). Necessariamente nesta ordem. Eu não tive essa sorte. Mas também não virei contador³.

.:.

Observações

1. Michael Hammer utilizou aquela frase para falar sobre mudanças corporativas. A original é: “Mudança corporativa é um oxímoro em vias de se tornar um pleonasmo“.
2. Em dezembro fiquei sabendo que o IIBA está preparando uma “Extensão Ágil” para o BABoK. Quem viu a “Leitura Crítica” que fiz já sabia que era uma correção mais que necessária. Apesar da tentativa da versão 2.0 em atender os mundos “Plan-Driven” e “Change-Driven”. Mais do que qualquer coisa, devemos elogiar a humildade e iniciativa do IIBA.
3. Por favor, prezados contadores, não me levem a mal. Além do meu velho, tenho vários outros parentes que assumiram e gostam desta honrosa profissão. Só não dá para discutir o fato dela ser  90% do tempo chatinha. Sabem o que meu velho fazia quando queria um pouco de diversão? Pegava a contabilidade de uma empresa pra lá de enrolada com fisco e afins. Ou então contratava o filho para desenvolver o sistema de contabilidade daquela empresa encrencada. Pois é, eu não estaria aqui se não fosse a contabilidade.
4. O desenho utilizado neste artigo, flikr0675, é do flikr.

Mas a frase do Willie não deve servir de desculpa para que a capa e toda a programação visual de um livro sejam relegados ao 2º plano. Estética, beleza – são preocupações que devemos ter em tudo o que fazemos. Não sou bom nisso, mas sei apreciar um trabalho bonito. E criticar a feiúra alheia…

Há tempos contatei uma empresa de design “maluca”, que participa do SP Fashion Week, decorou alguns dos principais restaurantes de Sampa e tem um espírito criativo sadiamente distante do nosso insípido e gelado mundinho de TI. Meu único requisito: não quero que meu livro se pareça com um livro de TI, particularmente os tupiniquins. Tem bobo aí que vai dizer que isso é papo de boiola e coisa e tal. Breve e única resposta para eles: a forma deve refletir e valorizar o conteúdo. Não é só uma questão de linhas e cores, mas de conceito, de integridade. Mas eu não quero falar só de programação visual, e sim de tudo que gira em torno do formato de um livro.

O livro impresso é uma das invenções mais longevas da humanidade – de Gutenberg pra cá já se foram 572 anos! A tecnologia de impressão mudou bastante, mas o produto final quase nada. E nenhuma edição digital conseguiu nos dar a manuseabilidade de um livro ‘normal’. Uma leitura de verdade se faz com um livro em mãos, passando suas páginas de uma forma que para outros olhos parece ser uma coisa aleatória e desprovida de lógica. Um livro ‘de verdade’ pode ser marcado, rabiscado, anotado. Um livro de fato lido fica gasto, meio manchado. E não raro tem memória: costuma abrir exatamente naquelas páginas mais necessárias em determinados momentos. Ok, meu papo soou um tanto romântico. Mas quem lê de verdade sabe do que estou falando. E apronta com seus livros algo parecido com o que faço com os meus. Meus livros não recebem o mesmo cuidado que os discos e DVDs. Mas sua valorização, por visitas e amigos, é realmente inversa. Os mais surrados são aqueles de maior valor. Meus amigos sabem. E os livros não me deixam mentir.

Durante o projeto do livro fui confrontado com duas questões que, a princípio, estavam totalmente fora do meu escopo. A primeira referia-se ao modelo do negócio, a forma como eu esperava comercializar e distribuir o livro. Dela brotou o projeto Rendiconti, cujo lançamento obedece ao mesmo cronograma do livro: lançamento em 25 de março do ano que vem.Sobre isso eu já falei em duas ocasiões:

• Rendiconti: O Negócio
• Rendiconti: O Projeto

Nos últimos meses, já prestes a entrar na última curva do projeto, outra questão passou a me incomodar: o formato do livro. Desde o início trato este projeto como se fosse um projeto de software. Aí, quando vislumbrei o produto final, algumas dúvidas surgiram como baldes d’água morna: como se atualiza um livro texto? Caso sejam necessárias as publicações de patches e service packs, como elas seriam? Daqui derivei outras dúvidas, e delas requisitos.

Todos os livros que tenho morrem em si: apesar da possiblidade de erratas e extensões mais modernas, como web sites, aquele produto é fechado. O leitor pode rabiscar e corrigir. Mas o autor não consegue fazer mais nada com sua própria obra. Normalmente os autores lançam novas edições. Scott Berkun, por exemplo, chegou a trocar até o título na última edição de “The Art of Project Management”. Agora sua obra-prima se chama “Making Things Happen“. Que baita service pack, não? Acontece que os dois volumes que tenho aqui comigo não podem ser atualizados…

Mergulhei nessas questões e fui aumentando o ‘espaço do problema’. Meu livro é de fato um guia, um guia de referência. Quero que ele esteja sempre à disposição do Analista de Negócios, para consultas pontuais. Daí imaginei que o AN queira fazer suas intervenções no próprio livro. Ao invés dos famigerados (e temporários) post-its, por que não um espaço para notas e observações? Melhor: e se o AN puder inserir páginas inteiras em seu livro texto (da mesma forma como ele pode customizar um bom software)? Se este requisito for atendido, ele facilita demais a realização de outro: a possiblidade de atualizar trechos do livro. Saca só o caso de uso: o chato autor aqui resolver atualizar o capítulo sobre Desenvolvimento de Requisitos. Ele publica a atualização (na loja Rendiconti. lógico) e a deixa disponível para todos que já adquiriram o livro. O cliente pode baixar a versão digital (gratuitamente) ou adquirir a versão impressa (daquele único capítulo). O próprio cliente encaderna o novo capítulo, substituindo a versão que ficou defasada. Jóia, não? Puxa, como eu gostaria de ter tal alternativa em meus livros. Mas… como realizar tal requisito?

É claro que a encadernação tinha que ser totamente diferente. Nova? Quem conhece a IOB sabe que isso tá resolvido há muito, muito tempo. Não consegui descobrir, mas acho que as “pastas Z” têm quase 100 anos. Mas, por favor, não pensem naquelas pastas antiquadas e feiosas que você vê no escritório do seu contador. Dê uma olhada na pastinha ao lado. Que tal?

E se ela for também a capa das apostilas? Assim, todos os participantes dos cursos e oficinas, caso se interessem, compram só o miolo do livro. E aquele espaço ali para um DVD… e se tiver uma edição com uma versão integral de uma palestra ou curso? E se… Ok, as possibilidades são várias.

Mas, é claro, tanta conveniência tem um preço. E eu não posso simplesmente ignorar aquele público que quer a opção de um livro “normal”. O jóia é que na loja virtual Rendiconti ele poderá escolher a encadernação que mais lhe agrade.

Entendem agora como um projeto atrasa tanto? Olha como o escopo mudou. Será que eu conseguiria pensar nisso tudo lá no início, quando estava só preocupado em escrever o livro? Não sei. Mas não me arrependo de nenhuma decisão. O atraso de (quase) um ano será compensado com um produto muito, muito melhor. Ops… bom, quem vai dizer isso são os leitores. Ops.. leitores não, Usuários do Livro.

A mais importante ferramenta do físico é sua cesta de lixo.
– Albert Einstein

As duas mais importantes ferramentas de um arquiteto são a borracha na sala de desenhos e a marreta na construção.
– Frank Lloyd Wright

Costumo dizer que, na iteração 0 (nos momentos iniciais do projeto, que antecedem o estudo de viabilidade e a elaboração de uma proposta), o principal trabalho do analista de negócios (AN) é ter uma visão do todo: “2 quilômetros de extensão e 2 centímetros de profundidade“. Para obter esse “instantâneo”, o AN lança mão de suas duas principais armas-disciplinas: A Análise e Modelagem do Negócio e a Engenharia de Requisitos .

Ao interpretar as dores e os objetivos do cliente, o AN começa a dar um certo “relevo” àquele “instantâneo”. Ele destaca os requisitos de usuários mais críticos – fundamentais para o negócio. Como mostrei na pequena série “Estruturando Requisitos” (link p/ parte 2), cada requisito devidamente *aprendido* pelo AN é – obrigatoriamente – acompanhado do atributo “Grau de Importância”: aquele requisito é Fundamental, Importante ou Opcional?

Com base nesta classificação o AN tem condições de selecionar os pontos que merecerão sua maior atenção. Sua atuação, agora, depende do tempo que ele tem para a elaboração da Proposta (ou Estudo de Viabilidade, ou Documento de Visão, ou Project Charter…). Seguindo a sugestão apresentada no artigo citado no parágrafo anterior, cada Requisito de Usuário selecionado é transformado em um Caso de Uso. O requisito “Emitir Nota Fiscal”, por exemplo, vira o caso de uso cujo título é “Emitir Nota Fiscal”.

Ao desenvolver o caso de uso em questão, o AN está “fazendo um zoom” naquele “instantâneo”. Por ser crítico para a solução do problema de negócio, aquele requisito (de usuário) será desdobrado em n requisitos funcionais. Mais que isso: no mesmo momento o AN também pode estar descobrindo ou aprendendo regras de negócio, definições de dados e também alguns requisitos não-funcionais. Informações que podem ser facilmente registradas em um bom modelo para especificações de casos de uso. Para cada requisito *aprendido* segue valendo a mesma questão: ele é Fundamental, Importante ou Opcional?

Vamos supor que estamos tratando de um projeto com 10 casos de uso. O AN teve tempo suficiente para detalhar um pouco mais 4 deles. Claro, para o detalhamento ele lançou mão de entrevistas, observações, sessões JAD (ou workshops) – as técnicas mais indicadas para aquele projeto e/ou cliente. Respeitando o prazo (que quase sempre é imposto), ele desenhou o melhor retrato possível do problema do cliente. Este retrato é composto por um grande diagrama conceitual (ou mapa de processos), diagramas de processos ou de linhas de montagem (caso os processos de negócio em questão sejam complexos o suficiente para justificar a elaboração destes), a classificação de 10 casos de uso e a especificação (um pouco mais detalhada) de 4 deles. Esta “radiografia” é tudo que a equipe possui para definir qual a melhor solução.

Equipe? Sim, o desenho da solução deve ser um trabalho em equipe. Em um futuro artigo apresentarei o que chamo de “parlamento” – o formato desta equipe. Vale ressaltar que cada ponto de vista relevante deve estar representado neste momento. Desenvolvedores, especialistas em usabilidade, os “inimigos” da infra, os “chatos” dos DBA’s e, claro, o coordenador do projeto. O AN, óbvio, representa o cliente. Mas não como um “advogado do diabo”. Não agora, em que sua principal responsabilidade é *ensinar* para a equipe o problema que deve ser solucionado. O AN apresenta um conjunto de “Fatos”, o problema definido.

Começamos aqui a expandir aquilo que Scott Berkun chama de “Espaço do Problema” :

O início dos debates é marcado por um volume relativamente grande e heterogêneo de idéias. O “espaço do problema” aumenta, como ilustra a figura acima (surrupiada do Berkun). Em determinado momento (que variará bastante dependendo do tipo e complexidade do projeto), o time pára de gerar idéias e começa a agrupá-las. É sugerido que se chegue em 3 alternativas de solução: a mais cara, a mais barata e a coluna do meio, por exemplo. Sugestão: as idéias também são agrupadas em casos de uso.

Os debates, que a partir deste momento podem incluir o próprio cliente (formalmente, via proposta que contemple as 3 alternativas, ou informalmente, na mesa de discussões) visam a redução do número de opções. Gradativamente, por exclusão, ou com o cliente fazendo a escolha de uma das três alternativas apresentadas.

O problema com este enfoque é que, se por um lado está bem claro o que é fundamental ou importante para o negócio, por outro temos pouca visibilidade da complexidade e custo daquelas alternativas de solução. O “parlamento” foi reunido exatamente para suprir tal necessidade. Mas como isso é feito? O próximo artigo apresentará uma sugestão. Inté!

Notas:

1. Mais do que os objetivos ou os atores (e seus objetivos), acredito que o melhor “guia” para o desenvolvimento de requisitos são os próprios processos de negócio. Um dia, num clássico trabalho (The Object Advantage – Addison Wesley (1995)), Ivar Jacobson disse que o “caso de uso é o nosso constructo para um processo de negócio”. Entendo que a análise e modelagem do negócio é indissociável da engenharia de requisitos. Para minha sorte, não estou só.
2. “A Arte do Gerenciamento de Projetos“, de Scott Berkun – Artmed Editora (2008). Pois é, finalmente o grande livro do Berkun é lançado em pt-br. Para nosso azar o livro foi reeditado lá fora, com novo título (“Making Things Happen“) e conteúdo revisto. Quem mandou demorar?

Começando do começo, fixei alguns princípios:

• Liberdade total, tanto no conteúdo quanto no formato de distribuição, precificação etc. O livro sairá com uma variação da licença Creative Commons, algo que uma editora tradicional dificilmente entenderia. Principalmente porque haverá uma versão digital (eBook), mais fácil de ser copiada.
• O livro será um meio, não o fim. Será a principal peça de marketing do finito por um tempo. Ou seja, não tenho a ilusão de fazer grana com o livro. Se ele se pagar, já será um belo feito.
• Peça de marketing não pode significar um livro “marketeiro” (no mau sentido). O conteúdo do livro deve ser prático, útil, rico e bem fundamentado.
• O livro é um esforço “solo”. Mas deve ser amplo em experiências e pontos de vista. A bibliografia consultada até agora, mais de uma centena de livros, não é suficiente. A área (Análise de Negócios) é relativamente nova. O risco de lançar um livro “míope” (ou “caolho”) é muito grande.
• Apesar de conhecer a tendência, o livro não será do tipo “como passar na prova”. Se ele ajudar na obtenção de certificações, particularmente a CBAP do IIBA, tudo bem. Mas este, definitivamente, não é um objetivo do texto.

Na seqüência desenhei a extensão do livro, uma visão de “alto nível”. Para se ter uma idéia, ainda não sei se ele terá 9 ou 10 capítulos. A versão com 8 capítulos já é conhecida por umas 120 pessoas (114 participantes dos workshops e 6 “convidados”). No plano original, ainda seguido, espero que ele alcance um mínimo de 400 pessoas. Quanto mais heterogêneo for esse grupo, melhor (veja oferta abaixo).

Por isso os workshops que estou realizando com a Tempo Real Eventos são tão importantes. Não pelo contato de 1 dia, mas pelas conversas que acontecem depois. Por isso montei um grupo de discussão “fechado”. Ali posso receber críticas e sugestões. Ali nós trocamos idéias sobre o conteúdo, práticas, processos…

Pois é, adotei um processo Iterativo & Incremental para o desenvolvimento do livro. Sendo assim, posso dizer que nos encontramos na fase de construção, na 7ª iteração. O produto, o texto, já está na versão 0.6. Chegamos em uma fase em que as iterações precisam ser mais curtas. Mas o cronograma segue rigorosamente em dia.

O trabalho de escrita, com todas as revisões, se encerra em dezembro. Já divulguei até a data oficial de lançamento: 27/mar/2008 (quinta-feira) Um dia eu explico a data e o codinome do rebento, “É o Negócio, Beócio“.

Do mesmo conteúdo gerei uma palestra (1h30), o workshop (7hs) e um curso (80hs, dividido em dois módulos de 40hs: Modelagem de Negócios e Engenharia de Requisitos).

Segue aqui uma oferta para escolas, universidades e entidades sem fins lucrativos (de Sampa ou Varginha): quem quiser levar a palestra ou workshop para suas organizações (em outubro ou novembro), não terá custo nenhum. Demais localidades podem ser incluídas, dependendo da distância e das despesas de deslocamento. Todos os participantes receberão uma cópia (digital) do livro (que ainda é uma apostila) e outros artefatos. Se interessou? Então, fale comigo.

Berkun escreve de forma aberta. Há tempos ele escreveu em seu blog qual seria o tema do livro e passou a documentar a evolução. Usou o blog como fonte de pesquisas e para validação de seus achados. O novo livro é pequeno (192 págs) e o tema um tanto espinhoso. O melhor livro sobre inovação e criatividade que conheço é “Criatividade e Grupos Criativos”, de Domenico de Masi. Pelas breves descrições do novo Berkun já disponíveis, dá para perceber algumas coincidências:

• Why all innovation is a collaborative process
• How innovation depends on persuasion
• Why problems are more important than solutions
• How the good innovation is the enemy of the great
• Why the biggest challenge is knowing when it’s good enough

Sairá um “De De Masi a Berkun”? hehe.. Não creio. Não só porque o título seria horrível, mas porque tenho outras prioridades. Logo elas aparecerão por aqui. Mas, com certeza, o novo Berkun deve dar o empurrão definitivo para que eu encerre aquela série sobre o “Gerenciamento do Trabalho Criativo“.

Mas fica a tentação: De Masi, em “Criativade”, conta toda a história da humanidade e pára em meados do século XX. Berkun conta a história das inovações olhando tudo o que veio depois, TI, software etc. Deve ser um belo complemento.

.

Quando pensei no título desta última parte da série busquei algo que fosse extremamente simples, uma receita culinária de um prato bem ‘default’. Mas que ao mesmo tempo parecesse único em cada ‘fornada’. O bolo de fubá foi uma lembrança imediata. Nunca vi dois iguais. Mais seco, mais molhado, dois ou quatro ovos, com queijo ou não… com vinagre!?! Pois é, achei mais de 30 mil ocorrências para “bolo de fubá” no Google. Minha família (mineira, obviamente) compartilha uma mesma receita. Mas o resultado é sempre diferente. Para algo que deveria ser incrivelmente simples: são só meia dúzia de ingredientes. Um mesmo processo. Um mesmo cronograma. Mas, surpreendente mesmo é a ilusão que todos nós que lidamos com desenvolvimento de sistemas já alimentamos pelo menos uma vez na vida: a ilusão de que existiria uma receita mágica, uma “bala de prata”, que nos ajudaria a entregar nossos projetos no prazo, dentro do orçamento e excedendo todas as expectativas de nossos clientes e usuários.

Se é quase impossível reproduzir com exatidão a simplicidade de um bolo de fubá, o que dizer de nossos projetos para desenvolvimento de software?

Em 1986 Fred Brooks publicou o artigo “No Silver Bullet”, que aparece como o capítulo 16 na edição de 20º aniversário de “The Mythical Man-Month”. No texto ele previa que em um horizonte de 10 anos não apareceria nenhuma evolução, nem tecnológica nem gerencial, que promoveria ganhos consideráveis de produtividade e confiabilidade. “Ceticismo não é pessimismo”, Brooks frisava. Nove anos depois, para a edição comemorativa, ele escreveu “‘No Silver Bullet’ Refired”, seu 17º capítulo. Responde algumas críticas e conclui que estava certo em sua avaliação.

Uma avaliação que pode ser resumida em uma frase apenas: “Construir software será sempre difícil“. Brooks fundamenta sua tese apresentando quatro propriedades (“irredutíveis”) da ‘entidade’ software:

• Complexidade: uma propriedade essencial, não acidental. Ou seja, software é uma entidade complexa por natureza, “talvez a mais complexa de todas as construções humanas”. De tal complexidade vem a dificuldade de comunicação entre os membros do time; dela deriva a impossibilidade de enumerar ou mesmo compreender todos os estados de um programa, e daí vem a falta de confiança. É da complexidade da estrutura que vem a dificuldade de se criar novas funcionalidades que não resultem em efeitos colaterais indesejados. Em suma e para usar um termo bem nosso, tupiniquim: Software é um “bicho de sete cabeças”. Ponto.
• Conformidade: “grande parte da complexidade que deve ser dominada pelo engenheiro de software é arbitrária, forçada sem rima ou razão pelas diversas instituições humanas e outros sistemas os quais suas interfaces devem conformar. Isso muda de interface para interface, de tempos em tempos, não apenas porque há uma necessidade, mas porque as interfaces são desenhadas por pessoas diferentes”.
• Instabilidade (de changeability): “A entidade software está constantemente sujeita a pressões por mudanças”. “Software pode ser alterado facilmente – ele é infinitamente maleável”.
• Invisibilidade: abstrações geométricas são muito úteis, mas não conseguem representar toda a complexidade de um software.

Brooks lista então uma série de avanços que podem ajudar a melhorar a qualidade de nossos projetos. Mas frisa que nenhum deles é uma “bala de prata”: Linguagens de alto nível (ele cita Ada – lembrem-se, o artigo é de 1986); Orientação a Objetos; Programação ‘Automática’; Programação ‘Gráfica’; etc. Na sequência ele lista alguns princípios que podem ‘atacar diretamente’ a essência dos problemas com software:

• Comprar ao invés de Construir: “a solução mais radical para os problemas com a construção de software é não construí-los”. De certa forma as ondas ERP e CRM livraram várias empresas de grande parte do peso da construção e manutenção de sistemas. Mas todas as organizações ainda demandam soluções específicas. Se não as constroem internamente, contratam serviços de desenvolvimento. Não acredito que um dia será possível comprar ‘pacotes’ (ou componentes ou serviços) para todo e qualquer tipo de problema de negócio.
• Refinamento dos Requisitos e Prototipação Rápida: “a parte mais difícil da construção de software é definir precisamente o que construir”. “Creio que é impossível para os clientes, mesmo aqueles que trabalham ao lado dos engenheiros, especificar completamente, precisamente e corretamente todos os requisitos do software antes de experimentar algumas versões”. Portanto, segue Brooks, “um dos mais promissores avanços é o desenvolvimento de métodos e ferramentas para a prototipação rápida de sistemas como parte do processo iterativo de especificação dos requisitos”.
• Desenvolvimento Incremental: ‘aumente’ (cresça) um software, não construa (no texto original, “grow, not build, software”). Para Brooks a metáfora da construção já deu o que tinha que dar. “Vamor olhar para a natureza e estudar a complexidade dos seres vivos ao invés dos trabalhos ‘mortos’ do homem”. Este princípio pode ser aplicado tanto no ciclo de vida do projeto quanto no ciclo de vida do próprio produto. Processos iterativos e incrementais já são comuns. Quase ‘carne de vaca’. O que é novo é a forma como o Google, por exemplo, ‘cresce’ e evolui seus serviços. Não se trata meramente de uma ‘manutenção’, e eu acredito que muitos de nossos produtos podem ganhar com esse novo enfoque. Independente do público e da tecnologia, diga-se de passagem.
• Grandes Designers: “Grandes projetos (designs) vêm de grandes arquitetos (designers). A construção de software é um processo criativo. Uma boa metodologia pode fortalecer e liberar uma mente criativa; mas não pode inflamá-la ou inspirá-la”. Brooks conclui: “a principal questão para a evolução da arte do software está centrada, como sempre esteve, nas Pessoas“. Não é por acaso que Brooks encerra seu livro recomendando a leitura de “Peopleware” , de Tom DeMarco.

Receitas, Metodologias, Processos…

E não parece ser uma mera coincidência que Scott Berkun inicie seu livro citando… “Peopleware”, de Tom DeMarco:

“A obsessão com metodologias é outra instância da ilusão high-tech. Deriva da crença de que o que realmente importa é a tecnologia…
Independente de qual seja o avanço tecnológico, ele cobrará seu preço com a deterioração da sociologia do time.”

Para Berkun, “a pior coisa é seguir cegamente um conjunto de regras e procedimentos só porque eles apareceram em um livro famoso ou porque são promovidos por um respeitado guru”. Berkun coloca que processos e metodologias são muito importantes, mas nunca serão ‘balas de prata’, entregadores de projetos bem sucedidos. E alerta para o perigo dos gerentes, em determinado momento de um projeto, “começarem a acreditar que o Processo é o Projeto”. Pode parecer absurdo, mas este ‘desvio’ é mais comum do que se imagina.

Um bom processo, segundo Berkun, apóia as pessoas e amplifica o seu valor. E seria o resultado da combinação de duas coisas: i) o que torna projetos e times bem sucedidos de uma maneira geral; e, ii) o que torna o projeto e o time atuais diferentes dos outros.

Eu gosto de acrescentar uma terceira variável, tão importante quanto o projeto em si e o time, no momento da seleção/customização de um processo: o Cliente. Quando se trabalha na indústria, como é o caso de Berkun, raramente se dispara um projeto para um cliente específico. Daí sua omissão. Mas no mercado de prestação de serviços de desenvolvimento é altamente recomendado que o perfil (valores e a cultura) do cliente seja levado em consideração no momento da customização do processo. Em alguns casos o próprio cliente solicita a incorporação de alguns métodos e artefatos, quando não a adoção de um ciclo de vida específico.

Mas o importante aqui é entender que não existe e nem nunca existirá uma ‘metodologia mágica’, aplicável em vários projetos. Cada projeto exigirá um processo específico. Mas isso não significa que a organização sempre partirá ‘do zero’. Muito pelo contrário. A primeira variável colocada por Berkun acima é “o que torna nossos projetos e times bem sucedidos de uma maneira geral”. Trata-se de um corpo de conhecimentos único, exclusivo. E orgânico, já que o natural é que ele cresça e fique mais rico a cada projeto. Infelizmente, quando olhamos algumas particularidades do mercado brasileiro de prestação de serviços de desenvolvimento, percebemos que muitas empresas dão pouquíssimo valor para esse aprendizado, lançando mão de vínculos empregatícios muitos frágeis (PJs e afins), o que resulta em uma alta rotatividade de seus colaboradores. Há quem acredite que este tipo de conhecimento pode ser capturado e aprisionado em documentos e coisas do tipo. Não é o meu caso. A explicitação de conhecimentos, sua compilação em artefatos que podem ser recuperados a qualquer momento, é benéfica para todas as organizações. Mas não consegue representar nem um pequeno pedaço de toda a experiência adquirida por um time durante a execução de um projeto. Trata-se de outra ‘ilusão high-tech‘, para usar um termo do DeMarco, que tenta impedir que o peopleware tenha seu valor reconhecido.

Voltando ao Berkun. Logo no início de “The Art of Project Management” ele ensina três ‘lições-chave’ que guiam boa parte de seus métodos, guias e sugestões. São elas:

• Gerenciamento de Projetos e Desenvolvimento de Software não são artes sagradas: apesar do ar de ‘novidade’ que impera em nossa área, é crucial lembrar que existem ensinamentos que podem vir de outros lugares.
• Quanto mais simples for a sua visão do que você faz, mais poder e foco você terá em sua execução: estar sempre curioso e aberto à novas idéias é o que torna o crescimento possível. Uma visão simples de nosso trabalho pode facilitar sua comparação com outras coisas que existem ao nosso redor. Aumentamos assim a possibilidade de aprendizagem.
• Simples não é sinônimo de fácil: correr uma maratona é simples, certo? Basta começar a correr e não parar até alcançar o quadragésimo kilômetro. Você diria que é fácil? Liderança e gerenciamento também são difíceis, mas sua natureza – realizar coisas de determinada maneira atrás de um objetivo específico – é simples. Bolos de fubá e pães de queijo também são extremamente simples. Não consigo entender porque só aqui em Minas eles são realmente gostosos.

Epílogo

Encerro assim uma série de 5 partes (9 artigos separados) que iniciei com a intenção de homenagear Fred Brooks e sua obra prima, “The Mythical Man-Month”, e também para apresentar o ‘caçula dos gurus’ (ele detestaria o rótulo), Scott Berkun. Como eu disse lá no início da viagem, estes artigos não substituem de forma alguma o prazer de ler os dois livros. E, posso garantir, não cobrem nem 10% de seu conteúdo.

O retorno que eu recebi (infelizmente a maioria foi off-blog) compensou com sobras o trabalho. O próprio Scott Berkun deu uma olhada no trabalho. E comentou:

“I did read the tribute you wrote and was flattered by it. I wouldn’t compare myself to Brooks – maybe if in 25 years ‘the art of project management’ is even still in print can a few modest comparisons begin.”

Apesar de não concordar com minha comparação, Scott me presenteou com uma cópia autografada de seu livro. Ah, se ele soubesse como torço para que seu livro não permaneça atual daqui 25 anos. A longevidade do livro de Brooks indica, de certa forma, que não aprendemos muito. Ou que não aprendemos direito. Eu sinceramente gostaria que ambos se transformassem em relíquias, documentos de um tempo em que a gente estava brincando de aprender a desenvolver software e a gerenciar projetos.

O próximo passo, ensinou Brooks, é aceitar que “software é um dos mais complexos trabalhos manuais do homem. Tal complexidade demanda nosso contínuo aprendizado, a melhor utilização das novas ferramentas, uma melhor adaptação a métodos gerenciais, a aplicação do bom senso e, acima de tudo, humildade para reconhecer nossas falhas e limitações“.

===

1. Tom DeMarco e Timothy Lister, “Peopleware – Productive Projects and Teams”, 2ª edição – Dorset House (1999, 1987).

===

Créditos e Considerações Finais

As imagens utilizadas na abertura de cada capítulo da série são de Chema Madoz, fotógrafo espanhol que não faz nenhuma questão de esconder sua maior influência, o louco mestre Salvador Dali. Os puristas podem reclamar dos indevidos ‘mashups’ que fiz nas imagens. Entendam como sendo uma forma de forçá-los a visitar o belo site de Chema, onde as imagens podem ser vistas em seu formato original.

As demais imagens, diagramas rabiscados, foram surrupiados digitalmente de “The Art of Project Management”. Aliás, boa parte das fotos presentes no livro são do próprio Scott Berkun.
Que faz uma coisa que nunca vi em livros técnicos: lista os sons que ‘mantiveram sua sanidade’ durante as longas horas em frente ao micro. De Charles Mingus a Aimee Mann, passando por Beatles, Clash, Radiohead e Audioslave. O cara escuta de tudo. E tem bom gosto.

Jonas Fagundes, J. Werther, Roberto, Régis, José Papo, Ivo Michalick e outros amigos ‘ocultos’ deixaram sua contribuição, na forma de comentários neste blog ou no grupo de discussão CMM-Brasil. Muito obrigado a todos. Se você curte o tema e procura um bate-papo de alto nível, o grupo é uma grande pedida.

Guz Vasconcellos fará a revisão do texto antes de sua conversão para um arquivo PDF. O blog manterá a (bugada) versão original.

That’s all, Folks?

Claro que não. O finito seguirá com um artigo por semana, sempre girando em torno dos temas Engenharia de Software, Gerenciamento de Projetos, Arquitetura de Soluções, e tudo o mais que caiba neste ‘torto’ triângulo. Sugestões de temas? Quer trocar idéias? Levar palestras e workshops para sua escola ou empresa? Demorou!

Ops… err… Vc fez uma busca por ‘bolo de fubá’ e caiu aqui por engano? Ou então ficou morrendo de curiosidade? É o seguinte:

Ingredientes:
4 ovos
4 copos de leite
1 xícara e meia de açúcar
1 xícara e meia de fubá
2 colheres de sopa de manteiga
2 colheres de sopa de farinha de trigo
1 colher de sopa de fermento em pó
1 xícara de queijo (canastra ou parmesão) ralado
1 pitadinha de sal

Preparo:
Em uma vasilha misture os ovos, acrescente o leite e aos poucos coloque o fubá misturando bem. Coloque o açúcar, o sal, a manteiga e misture novamente. Junte a farinha de trigo e por último o fermento em pó. Leve ao liquidificador, batendo por alguns minutos. Volte com a massa para a vasilha e acrescente o queijo ralado.

Despeje numa fôrma untada e leve ao forno quente por mais ou menos trinta minutos.

Se vai ficar bom como o da minha Vó eu não posso garantir.
Não existe receita mágica, certo?

“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).