A EPBE (Eriksson-Penker Business Extensions), como o nome indica, foi desenvolvida por Hans-Erik Eriksson e Magnus Penker. Foi apresentada no ano 2000, no livro “Business Modeling with UML – Business Patterns at Work“. Como o título indica, o livro tem objetivos bem maiores. Mas a compreensão da EPBE está em seu núcleo. Mas o que é, afinal, a EPBE?

A EPBE é uma extensão da UML (Unified Modeling Language). Foi desenhada para possibilitar o uso da UML na modelagem de negócios. A UML é extensível, e várias outras especializações existem: sistemas Web, modelagem de bases de dados, sistemas embarcados etc. Estendemos a UML através de três elementos: estereótipos (stereotypes), valores nomeados (tagged values) e restrições (constraints). Quando uma organização ou equipe faz um uso maduro da UML, ela cria suas próprias extensões. Evita-se a “reinvenção da roda” quando se parte de uma extensão existente, como a EPBE, por exemplo.

Mas a EPBE “reinventou a roda”, não? Afinal, no ano 2000, já existiam diversos padrões de notação para a modelagem de negócios. A justificativa para sua criação é exatamente essa: existiam diversos padrões – o que é o mesmo que dizer que não existia padrão nenhum. A mesma razão, em outro domínio, motivou Grady Booch, Ivar Jacobson e James Rumbaugh a criarem a UML. E por que utilizar a UML como base para a modelagem de negócios?

Segundo os criadores da EPBE, a primeira motivação são os “conceitos similares: um negócio pode ser descrito em termos de processos que satisfazem objetivos através da colaboração de diferentes tipos de recursos. Regras definem condições e restrições sobre como os processos e recursos devem se relacionar e como devem se comportar. Tudo isso pode ser mapeado em objetos, relacionamentos e interações entre objetos” .

Outras razões apontadas por Eriksson e Penker são: i) a maturidade da UML (e da orientação a objetos); ii) a notação padrão (de facto); iii) o aprendizado rápido; e, iv) a nova e fácil maneira de ver a organização e o negócio. Vale reforçar a motivação descrita no parágrafo anterior com outra leitura: negócio e TI teriam uma mesma linguagem padrão de modelagem. Os benefícios são óbvios.

Do mesmo parágrafo podemos extrair os 4 elementos fundamentais que utilizamos para descrever qualquer negócio:

• Recursos: é tudo o que a empresa utiliza, consome ou produz. São as pessoas, materiais, informações e produtos. Recursos são manipulados através de processos, ou os manipulam e gerenciam. E são classificados como: físicos, abstratos e de informação.
  Para ficar um pouco mais claro: uma nota fiscal é um recurso abstrato, assim como uma ordem de compra ou um “bilhete azul”. Quando uma nota fiscal é registrada em uma base de dados, por exemplo, torna-se um recurso de informação.
• Processos: são as atividades realizadas pelo negócio. Eles descrevem como o trabalho é executado na empresa, e são delimitados por regras.
• Regras: são as definições ou restrições de algum aspecto do negócio. Regras determinam como um negócio deve ser gerenciado ou como os recursos devem ser estruturados e utilizados. Elas podem ser criadas pela própria empresa ou são impostas por entidades externas (governo, associações, sindicatos etc).
• Objetivos: representam a razão da empresa, ou os resultados que o negócio espera atingir. Objetivos podem ser divididos e distribuídos entre os diversos processos da empresa. Objetivos expressam o estado desejado de determinados recursos (caixa, estoque, market share – por exemplo), e são atingidos através dos processos. O conjunto dos objetivos de alto nível forma a estratégia da empresa.

A lista acima pode ser resumida da seguinte forma: Os objetivos do negócio são atingidos através da execução de processos que usam, transformam e geram recursos, sempre respeitando e seguindo um conjunto de regras. O diagrama ao lado representa esta lógica.

Para entender e aceitar a EPBE, além de compreender os elementos fundamentais descritos acima, é necessário entender o que é a Modelagem de Negócios e para que ela serve. Modelamos um negócio com o objetivo de simplificá-lo. Criamos abstrações ou analogias de uma forma que facilite a compreensão, a documentação e a comunicação de todos os aspectos principais de um negócio. Nós modelamos um negócio para:

• Fornecer uma base que apóie a criação de sistemas de informação;
• Criar um ponto de partida para iniciativas de melhoria da estrutura e dos processos de negócio;
• Experimentar novos conceitos e desenhos;
• Identificar oportunidades de outsourcing; e
• Facilitar a integração com entidades externas.

Tratando especificamente de projetos de sistemas de informação, podemos dizer que a modelagem de negócios também serve para :

• Entender a estrutura e a dinâmica da organização;
• Compreender os problemas da organização e identificar oportunidades de melhoria;
• Garantir que clientes, usuários e desenvolvedores compartilham uma mesma visão do negócio; e
• Extrair requisitos do sistema.

Do que consiste um modelo de negócio? Ele é formado por três partes principais:

• Visões: é impossível descrever completamente um negócio sob um único ponto de vista. Existem quatro categorias de visões: Visão do Negócio, Visão dos Processos, Visão da Estrutura e Visão do Comportamento.
  Obs.: nas próximas partes desta série as visões serão apresentadas de forma mais detalhada.
• Diagramas: toda visão é representada por um ou mais diagramas, que representam partes específicas da estrutura ou da dinâmica do negócio. Diagramas são compostos por objetos e processos.
• Objetos e Processos: Objetos representam todos os recursos, enquanto os processos representam qualquer atividade ou função executada no negócio.

A mensagem mais importante até aqui é a seguinte: Modelar é Simplificar. Modelamos um negócio para facilitar sua compreensão, entender seus problemas correntes e identificar oportunidades de melhoria. Em projetos de sistemas de informação, a modelagem de negócio é lançada para municiar da melhor forma possível a equipe que criará a solução. A EPBE é “só” um padrão de notação. É diferente de outras propostas porque: i) Usa o mesmo padrão dos sistemas, a UML; e, ii) É completa.

A EPBE não é um processo ou metodologia nem pretende sê-lo; O uso da EPBE não implica necessariamente em BDUF (big design up front) ou na utilização de processos “waterfall”; A EPBE não concorre com BPMN e afins – na realidade estes podem ser utilizados como um sub-conjunto da EPBE.

No próximo artigo veremos como a EPBE descreve a Estrutura de um negócio. E no seguinte, como ela é utilizada para modelar Processos de negócio.

Bibliografia:

1. Business Modeling with UML – Business Patterns at Work
   Hans-Erik Eriksson e Magnus Penker. Wiley (2000).
2. The Rational Unified Process – An Introduction (2nd Edition)
   Philippe Kruchten. Addison-Wesley (2000).

Observação:

* – Para não cometer uma total injustiça: o livro “UML 2.0 – Do Requisito à Solução“, de Adilson da Silva Lima, tem um capítulo inteiro dedicado à EPBE. Pelo que sei, é o único em língua portuguesa que toca no assunto. Se tudo der certo, ele perderá o monopólio em março de 2008, quando meu livro deve chegar em algumas prateleiras. Eu disse lá em cima que o livro de Eriksson e Penker é o único porque o Adilson limita-se, como eu aqui nesta série de artigos, a dar um overview da EPBE. Ou seja: EPBE na íntegra, só no original.

Mas, mais do que criar polêmica (essa cansa), eu queria descrever com mais detalhes os 7 princípios que compõem o DEVAGAR:

D)emonstrar Valor de maneira Iterativa
Deveria ser, Iterativa & Incremental. Parece frescura, mas faz diferença. Iterare, no latim, significa repetir. Aqui indicamos que repetimos diversos passos (no processo de desenvolvimento), mas a cada repetição nós agregamos real valor. Numa leitura “ágil”, é o mesmo que dizer “entregamos software rodando” em cada ciclo (ou iteração). Não curto o radicalismo: nas primeiras iterações, ou exclusivamente na 1ª iteração, software rodando pode ser menos importante que uma boa compreensão do negócio. Da mesma forma que ele pode ser muito importante para a equalização de visão entre todos os stakeholders. Mais do que um processo, o que determina o Real Valor a ser entregue em uma iteração é o projeto. E cada projeto é único. Mensagem mais importante (para o negócio e seus usuários): se uma iteração se encerra e você não consegue perceber o Valor, algo errado aconteceu. E é verdade: software rodando tem muito mais valor que uma série de modelos UML ou afins.

E)ntender (e Melhorar) o Negócio
É difícil aceitar que um projeto seja tocado sem que boa parte da equipe tenha uma mínima compreensão sobre o negócio que está sendo automatizado. É difícil entender a razão para tal alienação ser tão comum em nossa área. Mas o princípio aqui vai além: além de uma boa compreensão do negócio e dos projetos afetados pelo projeto, um processo ‘business-centric’ incentiva a busca por melhorias.

V)alorizar os Ativos de Software
Está aqui um princípio que, salvo engano, não vi formalizado em nenhuma proposta de processo. Ele deveria ter dois efeitos:

1. Garantir a qualidade do software que está sendo produzido. Se bem empacotada (documentada e difundida), a aplicação ganha sobrevida. Vale apelar para um velho chavão: ativos de software, ao contrário dos ativos físicos, ganham mais valor quanto mais são utilizados. Todo software (de negócio) deveria ser construído para durar… muito.
2. Dar sobrevida aos ativos existentes (também conhecidos como sistemas legados). Trata-se de um dos principais alvos das iniciativas SOA. Mas, hoje em dia, serão raros os projetos que não estabeleçam um mínimo relacionamento com software existente. Combater a síndrome NIH (Not Invented Here) e dar valor para aplicações (conhecimentos!) existentes é uma boa prática.

A)daptar o Processo
Taí um princípio que, se adotado pela (IBM) Rational desde o início (do RUP), teria evitado uma série de problemas. Se todo projeto é único, como acreditar em um único processo? Toda organização possui e vive seus valores e costumes. Algumas sobrevivem a eles (hehe.. brincadeirinha). Essa base, mais um conjunto de princípios (ou boas práticas, como as descritas aqui), dá forma à um meta-processo. Um framework que seria posteriormente adaptado para cada tipo de projeto e também para cada projeto.

No nível mais baixo (um projeto), quatro variáveis principais afetam a configuração de um processo: O Negócio (sua estratégia, processos, departamentos e pessoas afetados); o Tipo de Aplicação (Transacional, Analítica ou Utilitária); a Tecnologia e o perfil da Equipe. Claro, várias outras questões (regulatórias, SOX, Bacen, Basiléia… por exemplo) também podem gerar considerável impacto no desenho dos processos de desenvolvimento e gerenciamento do projeto.

G)erenciar Requisitos (e Mudanças)
Vira e mexe, há tempos, o dado pipoca por aí: requisitos (e mudanças) estão de alguma forma relacionados com 80% dos problemas dos projetos que fracassam. Como eles (os projetos fracassados) não são poucos, é inaceitável que este princípio não conste de um processo para desenvolvimento de software. Pode parecer chatice (de certa forma o é), mas “balancear prioridades dos stakeholders” não é o termo adequado. Parece até “forçada de barra” para arrumar uma letra B (e assim compor o perfeito ABCDEF). E por falar nisso, gerenciar requisitos não significa lotar paredes com post-its coloridos.

A)tacar os Riscos
Assim como os requisitos, o mau gerenciamento de riscos também está entre as principais causas das falhas em projetos de software. Como Grady Booch já falava em 96 , “se você não atacar os riscos, eles o atacarão”. O verbo é este mesmo: Atacar (a redação de um princípio deve ser clara e direta). E é equivacada a impressão de que riscos são questões exclusivas de arquitetura. Um bom entendimento do negócio (princípio #2 acima), significa também a descoberta de riscos e até uma possível antecipação de mudanças. Aliás, os riscos de negócio são mais perigosos que os riscos de arquitetura (por mais que algumas péssimas aplicações tentem nos provar o contrário).

R)espeitar os Usuários
É chato que algo assim tenha que aparecer numa lista de princípios. Mas, infelizmente, se fez necessário. É bom que seja o item de fechamento da lista. Força a revisão de muitos fatores que podem ter ficado implícitos. Por exemplo: vamos ouvir e gerenciar todas as expectativas dos usuários. Mas não fugiremos da responsabilidade de sugerir melhorias, ou de alertá-los sobre riscos em potencial. Respeitaremos a inteligência e o tempo dos usuários estudando seu negócio, falando sua língua. E, mais importante, nos comprometendo com seus objetivos de negócio.

Por tudo isso eu gostei do DEVAGAR. “DEVAGAR & SEMPRE”, como naquela fábula da tartaruga. Taí, já arrumei até mascote para o ‘business-centric’…

.:.

Notas:

1. Os princípios desenham o perfil de um processo. Quanto mais genéricos forem, mais maleável é o processo. Por isso é preciso ter muito cuidado com processos que se apresentam como de uso geral, mas apresentam princípios que, de certa forma, são ‘intrusivos’. Reparem: trata-se de uma crítica que se aplica à listinha DEVAGAR acima. Com certeza ela não atenderá qualquer tipo de negócio. O que dizer então de projetos?
   O mais importante é ter um bom ponto de partida. E ninguém pode ensiná-lo melhor do que seu próprio negócio.
2. Object Solutions – Managing the Object-Oriented Project
   Grady Booch. Addison-Wesley (1996).

.:.

O reuso de ativos de software é uma daquelas várias promessas da área de TI que parecem gerar mais decepções do que resultados concretos. Antes da onda SOA, as propostas que colocaram a reusabilidade como uma de suas maiores vantagens foram a Orientação a Objetos (OO) e o Desenvolvimento Baseado em Componentes (CBD – Component-Based Development). Ambas as propostas tinham o reuso como uma conseqüência natural. Ou seja, não se preocuparam em fazer do reuso uma prática sistemática, planejada. Autores como Grady Booch transferiam para os programadores a responsabilidade de reutilizar ativos de software: “durante a implementação, procure agressivamente por partes que possam ser reutilizadas” . Hoje é dito que “oportunidades para o reuso são como os bugs, quanto antes elas forem encontradas melhor” .

O reuso não planejado, chamado por Steve McConnell de “reuso oportunista”, careceria de “alguma sorte” para a sua realização . Sendo casual, ele dependeria muito da equipe do projeto e do conhecimento que esse time tem sobre os ativos existentes e projetos anteriores da organização. Hoje pode-se afirmar que os benefícios gerados pelo reuso de ativos de software não podem ser plenamente realizados se dependerem exclusivamente da casualidade – o encontro de coincidências entre dois ou mais projetos – e do conhecimento de uma equipe de projeto.

O reuso sistemático ou planejado de ativos de software significa :

• Compreensão de como o reuso contribui para a realização dos objetivos do negócio como um todo;
• Definição de estratégias técnicas e gerenciais para que se alcance o máximo valor com o reuso;
• Integração do reuso em todo o processo de software e também no programa de melhoria do processo;
• Garantia de que toda a equipe possui as competências e motivação necessárias;
• Estabelecimento do adequado suporte organizacional, técnico e orçamentário; e
• Uso de métricas apropriadas para controle da performance do reuso.

Ao contrário do que se imaginava, o reuso depende muito pouco de tecnologia. Pesquisa realizada com 71 organizações de desenvolvimento mediu o impacto de uma série de fatores na adoção do reuso e concluiu que, das 6 dimensões medidas, a tecnologia é a menos relevante. No reuso sistemático, os fatores mais críticos para o sucesso seriam :

• Planejamento e Melhoria Contínua do Processo;
• Existência de um Processo Formalizado;
• Apoio da Alta Gerência;
• Similaridade entre Projetos; e
• Arquitetura Comum.

Posteriormente esta série de artigos tratará de cada uma das dimensões apresentadas na lista acima. Neste ponto o importante é a constatação de que “a introdução do reuso sistemático é muito mais do que uma mudança tecnológica: ele deve ser compreendido e gerenciado como um grande conjunto de mudanças no processo de software” . As três primeiras dimensões apresentadas acima, do tipo organizacional, aparecem apenas quando o processo de reuso é sistemático e formalizado perante toda a organização.

É importante lembrar que, como foi colocado no primeiro artigo da série, dois dos principais modelos para melhoria dos processos de software, o CMMI e o MPS.br, não contemplam o reuso. Apesar de indicarem que se trata de um nítido sinal de maturidade do processo de uma organização . Algumas propostas sugerem a adaptação dos grupos de reuso da ISO/IEC 15504-5 para as áreas de processo do CMMI . Há ainda a possibilidade do MPS.br incorporar processos de reuso em versão a ser liberada no primeiro semestre de 2007. Organizações interessadas em adotar o reuso sistemático poderiam optar por incorporá-lo ao seu programa de Melhoria de Processos de Software (MPS) ou tratá-lo como uma iniciativa independente.

No entanto, na implementação de uma SOA, o reuso está no núcleo dos trabalhos. O reuso sistemático não é mais uma opção, mas uma condição crítica para o sucesso de uma iniciativa dessa natureza. Pode-se dizer então que a introdução de uma SOA forçará a adoção de práticas sistemáticas de reutilização de ativos de software. Organizações poderão aproveitar a oportunidade e tornar o reuso um componente fixo de seu programa MPS.

Alto Custo

Edward Yourdon sugeriu uma regra que dizia que um “ativo reutilizável exigirá o dobro do esforço requerido por um ativo comum” . Fred Brooks estima que deve ser “o triplo” do número sugerido por Yourdon . Steve McConnell reconhece que o reuso planejado não é uma prática de curto prazo. “Um programa de reuso pode demorar 2 anos para começar a gerar componentes realmente reutilizáveis”. Mas cita que os ganhos de produtividade podem fazer com que a organização passe a realizar 35 pontos de função (PF) / pessoa / mês, contra uma média nacional que seria de 5 PF / pessoa / mês *.

Os autores de “Practical Software Reuse” colocam o tema de outra forma: “todos os custos com software são sempre considerados um overhead“. “Por isso”, eles continuam, “as avaliações do retorno sobre os investimentos (ROI) em iniciativas de melhorias (seja reuso ou um programa MPS) raramente estão disponíveis e raramente são críveis”. No entanto, “independente da forma como o contabilizemos, reuso é um investimento. E todo investimento envolve incertezas, riscos e ‘chutes'” .

Por tudo isso parece que, sem o envolvimento e o apoio da alta gerência, torna-se quase impossível a implantação de práticas sistemáticas de reuso. E, com certeza, está aqui uma das grandes razões para o fato do reuso nunca ter entregue um mínimo das promessas realizadas nas últimas décadas.

===

Referências:

1. Object Solutions
   Grady Booch
   Addison-Wesley (1996).
2. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
3. Rapid Development
   Steve McConnell
   Microsoft Press (1996).
4. Strategies for Software Reuse:
   A Principal Component Analysis of Reuse Practices
   (PDF – Requer registro e pagamento)
   Marcus A. Rothenberger et al
   IEEE Transactions on Software Engineering, Vol. 29, No 9, (Set/2003).
5. CMMI Performance Results
   Exemplo de um caso específico (Boeing).
   Carnegie Mellon / Software Engineering Institute (SEI).
6. Adaptação dos Processos do Grupo de Reuso do ISO/IEC 15504-5 para as Áreas de Processo do CMMI (PDF)
   Leandro de Paula Silva
   Monografia de graduação apresentada ao Departamento de Ciência da Computação da Universidade Federal de Lavras (2006).
7. Decline and Fall of the American Programmer
   Edward Yourdon
   Yourdon Press (1992).
8. The Mythical Man-Month – Anniversary Edition
   Fred Brooks
   Addison-Wesley (1995).
   

===

* Ah, como eu gostaria de conhecer, nem que fosse um pouquinho só, os números tupiniquins…

Todo projeto está sujeito a crises. E os sentimentos gerados por uma crise são muito ruins: Medo (de perder o emprego, por exemplo), angústia, insegurança. Sensação de que o final chegou, e não é nada feliz. O moral da equipe despenca, e o cliente pode estar raivoso ou simplesmente sem esperança alguma. No ápice de uma crise em um projeto é muito difícil dizer se ele, o projeto, sobreviverá. Acho que na maioria das vezes não. Mas uma virada é sempre possível. Há quem diga que é nessas horas que aparecem os verdadeiros líderes. Parece ser mesmo. Mas como lidar com crises em projetos?

O bom gerente de projetos aprende logo nos seus primeiros dias de coordenação que, “se ele não atacar diretamente os riscos, será atacado por eles”. Manter atualizada uma lista de riscos, diariamente, é uma boa prática inquestionável. Saber o momento de disparar ações que visam a eliminação de um risco, ou a minoração da probabilidade desse acontecer, é algo que se aprende com o tempo. Infelizmente, boa parte de nossas listas se limitam ao óbvio. Ao ‘top ten‘. E trasmitem a ilusão de que os riscos são isolados.

Raramente uma crise é produto de um único risco mal tratado. Na verdade, uma crise em um projeto é resultado de uma série de ações e omissões. Boa parte previsível através do correto e atento gerenciamento de riscos. Mas, para falar especificamente sobre Gerenciamento de Crises, vamos supor que um fato novo, externo, tenha ‘explodido’ e gerado uma crise. Que sua combinação com outros fatores levou o projeto para aquele altar que todos miram com pesar: “Que pena. Era um projeto tão bonitinho”. Mas o projeto não morreu. É só uma crise. Como debelá-la?

Não Entre em Pânico

A pior coisa que pode acontecer para um projeto em crise é seu líder entrar em pânico. É do líder que será cobrada a primeira opinião, ou melhor, a primeira justificativa. Se ele não tem a resposta, e normalmente ele não a tem nos primeiros momentos de uma crise, a melhor coisa a fazer é ser sincero e pedir um tempinho. Tentar dar respostas rápidas, tipo “está tudo sob controle”, no meio do caos que impera, só ajuda a aumentar a confusão e gera mais dúvidas sobre a liderança. É importante aparentar calma, mas não devemos nos esquecer que o excesso de calma, aquele jeitão zen-budista, pode parecer alienação. Algo do tipo “não estou nem aí”. E lembrar sempre que mentira tem ‘pernas curtas’. Em projetos vivendo um momento de crise as mentiras não tem perna nenhuma.

O líder sempre precisa de um tempo para avaliar todo o contexto. E para conversar com todos os envolvidos. E, depois, precisa de um generoso tempo para analisar e consolidar todas as informações obtidas. Só ou acompanhado de um grupo muito pequeno e realmente relevante. Este é o momento em que o Princípio Calvin deve ser lembrando constantemente: “Não há problema ruim o suficiente que não possa ser piorado com um pouco de culpa”. Infelizmente é muito comum que, em momentos de crise, tudo que algumas pessoas buscam são algumas bruxas para queimar. Essas pessoas devem ser evitadas neste momento de reflexão.

Os principais produtos dessa análise são duas pequenas listas: uma com os principais fatores que resultaram na crise; e a segunda com um pequeno plano emergencial, a lista das principais atitudes que serão tomadas no sentido de recolocar o projeto nos trilhos. O principal valor da primeira lista é mostrar para o cliente ou usuário o quão ‘dona’ da situação a liderança está. Caso o cliente não concorde com os itens da lista, qual a chance dele aceitar o plano emergencial? Tentar esconder algumas causas debaixo do tapete transparente de uma crise é perda de tempo. E mais um motivo para enraivecer ou desanimar o cliente.

E um plano emergencial não deveria ser disparado sem antes ser negociado com o cliente. É crucial que todos os envolvidos saibam quais ações serão disparadas. Se não for para se comprometer com elas, no minímo para não atrapalhar. É fundamental que o líder saiba com quem pode contar. Seja para a execução de algumas ‘horinhas extras’, seja para enfrentar uma sabatina com usuários alterados. Lá fora costumam chamar de SWAT as equipes montadas para atacar situações de crise. Normalmente, direcionam um pequeno e especializado exército para ‘construir e construir’, visando tirar atrasos de um cronograma. Uma crise quase sempre é muito mais que um milestone perdido. E o mero reforço no número de dedos codificadores bate de frente com a Lei de Brooks: “Adicionar pessoas a um projeto de software atrasado só adiará a sua entrega”. Ainda segundo Fred Brooks, “é como tentar apagar um incêndio com gasolina”.

No auge de uma crise as únicas pessoas ‘de fora’ que podem ser realmente úteis são aquelas que tiveram algum envolvimento prévio com o projeto, membros de um escritório de projetos, arquitetos ou gerentes de negócios. Podem representar a organização contratada. Mas de forma alguma eles devem sobrepor ou questionar alguma decisão do líder atual do projeto. Não em público. ‘Queimar’ um líder neste momento é fácil. De certa forma, até covarde. Em time de futebol pode até funcionar. Mas raramente é uma decisão que representa ganhos imediatos para um projeto. Muito pelo contrário.

Informação é Calmante

Quanto menos (boa) informação circular, pior será a sensação de crise. Boa informação não significa necessariamente uma Boa Notícia, e sim uma informação fidedigna, formal e oficial. Quando a liderança deixa de falar diretamente com todos os envolvidos, ela abre espaço para todo tipo de boatos e especulações. É vital para o projeto que desde o início da crise a liderança mantenha um fluxo constante e programado de interações com o cliente e com os usuários. E, lógico, com o seu time. Se antes da crise as reuniões eram semanais, agora elas devem ser diárias. Se eram diárias, é recomendável que agora elas ocorram duas, três ou quatro vezes ao dia. Tal programação deveria ser seguida até o projeto retomar seu curso e ritmo naturais.

E não tem ata ou memorando que substitua uma boa conversa ‘cara a cara’. O líder também deve evitar mandar ‘representantes’. Seria sinal de fraqueza. Assim como é um péssimo sinal a companhia de várias pessoas ‘de fora’, representantes da organização contratada. Confessam assim uma falta de confiança no líder destacado para o desenvolvimento do projeto.

Mas o que é debatido até quatro vezes por dia com o cliente e com o time? Oras, o andamento do plano emergencial: i) O que deveria ter sido feito?; ii) O que fizemos; iii) O que falta fazer; iv) Quando será feito?; v) Quem fará?. Coisas básicas assim, corriqueiras em qualquer projeto. O ciclo curto de interações visa exclusivamente a aumentar a confiança do cliente, reduzir a pressão e a audiência da ‘rádio-peão’. As reuniões devem ser breves e envolver um grupo pequeno de pessoas. Questões pontuais, técnicas por exemplo, devem ser debatidas em outro foro, específico. É crucial que não se desperdice o tempo de ninguém. Portanto, se uma pessoa não tem nada para contribuir em uma reunião, se ela ‘entra muda e sai calada’, é melhor que ela esteja fazendo outra coisa. Um cafezinho, por exemplo. Ou chá de camomila, mais indicado para momentos de crise.

O Jogo só é Duro quando a Gente é Mole

A frase aí é do ex-técnico do Corinthians, Ademar Braga, pouco antes de ser desclassificado na Libertadores. Independente de seu sucesso, a frase é certeira. Em momentos de crise quase tudo em um projeto passa a ser questionado. O líder, o escopo, a solução técnica, a qualidade dos desenvolvedores. Se tudo é realmente tão ruim, o cliente tem que aceitar que comprou mal pra caramba e fim de papo. Não é o caso na maioria das vezes. Mas, ainda assim, tudo ou quase tudo pode ser questionado. Nesse momento é de suma importância que o líder seja firme, que ele ‘fale grosso’. Se começar a aceitar alterações de escopo, na equipe e na solução, ele só estará piorando nossas estatísticas no Chaos Report: o projeto será cancelado.

Muitas vezes a solução de uma crise, ou a majoração da probabilidade de se alcançar os próximos milestones, passa exatamente pela redução do escopo. Para conseguir a aceitação do cliente é fundamental que o líder do projeto seja firme. E, claro, um excelente negociador.

Se uma das origens da crise é o time do projeto, então a Firmeza do líder será testada de forma diferente. A última solução de sua lista deveria ser ‘cortar a própria carne’. Quanto tempo um novo integrante levaria para se inteirar do projeto? Até que ponto a troca de seis por meia-dúzia adiantaria? É só (?) uma questão de convivência, de relacionamento? Muitas vezes nos esquecemos que aquilo ali é uma relação profissional. “Brigou no happy-hour e agora não quer mais trabalhar junto com Fulano”. Esse tipo de coisa deve ser combatida com veemência pelo líder. E se for uma questão de insuficiência técnica? Se não for algo contornável dentro do projeto, via treinamento ou ‘mentoring‘, aí sim deveria ser providenciada a troca daquele(s) membro(s). Mas o líder deve sempre se preocupar com a preservação do time. Que significa, diretamente, a conservação das experiências vividas até aquele momento. A manutenção do conhecimento adquirido.

Há melhor forma de aprendizado?

Ao término de uma crise, muita gente costuma falar só dos ‘traumas’. Realmente podem ser horríveis. Mas cada crise, assim como cada projeto, representa uma oportunidade única de aprendizado. Para todos os envolvidos. De certa forma parece que os traumas ajudam a tornar aquela experiência ainda mais rica. Colocando de outra forma: podemos ficar mais sensíveis aos riscos que levaram àquela situação. Portanto, as chances de ‘criarmos’ uma crise parecida em um projeto futuro são quase nulas. Isso é aprendizado de verdade.

E é por isso que, quando impedimos que alguém viva tal experiência, limando-o do projeto antes de seu término (ou, pelo menos, do término da crise), estamos abortando uma chance única de aprendizado. Isso afeta diretamente a pessoa, mas prejudica também a organização. Uma organização que, não raro, desloca o coitado do Fulano para outro projeto, outro cliente, (outro presídio?), até que outra crise comece. E começa tudo de novo, sem que ninguém esteja aprendendo nada de novo.

===

1. Grady Booch, em “Object Solutions”
   Addison-Wesley – 1996
2. Bill Waterson, em uma tirinha do “Calvin”