PAULO FERNANDO VASCONCELLOS NOGUEIRA

Blog

  • Liderando a Equipe Criativa

    5ª Parte da Série “Gerenciando o Trabalho Criativo“

    “The real leader has no need to lead — he is content to point the way.”
    – Henry Miller

    Apesar dos requisitos de liberdade e da capacidade de auto-gerenciamento, o senso de hierarquia é uma característica dos grupos criativos . Existe a necessidade de uma liderança que seja democrática e colaborativa . Peter Drucker questiona se ela seria uma posição ou uma atribuição . Mas o fato é que uma liderança é necessária para a condução do trabalho criativo.

    Algumas experiências (cinema, por exemplo) e processos de gerenciamento (Scrum) sugerem a existência de mais de um líder em equipes criativas. “Pensadores são raros; Executores são raros; Pensadores-Executores são raríssimos” . Enquanto um líder (o diretor de um filme; o Product-Owner do Scrum; o Arquiteto – como prefere o Finito) se ocupa da criação propriamente dita, da concepção do produto ou serviço, o outro (o produtor de um filme; o Scrum Master do Scrum; o Gerente do Projeto – na linha do Finito) cuida da condução do projeto, de todos os seus aspectos burocráticos e por isso se torna a principal interface entre a equipe criativa e o mundo externo. O gerente de projeto funciona como uma barreira que isola a equipe de tudo que pode desviá-la de seu trabalho principal. Enquanto o arquiteto e a equipe representam a porção “fantasia” da criatividade, o gerente do projeto busca sua “concretude”.

    A sabedoria popular ensina que “cachorro com dois donos morre de fome”. Mas a divisão sugerida acima já é utilizada há tempos e com comprovado sucesso na indústria do cinema, por exemplo. Quem recebe o Oscar de melhor filme é o produtor (o Gerente do Projeto). Mas há também a premiação para o melhor diretor (o Arquiteto). É relativamente normal que a relação entre os dois seja conflituosa. O próprio cinema é rico em histórias de brigas e desavenças entre produtores e diretores. Parece que o choque entre “fantasia” e “concretude”, tanto quanto sua soma, é uma característica natural e indissociável do trabalho criativo. Talvez o mais notável e freqüente tipo de “Tensão Criativa”.

    ===

    A sugestão acima já está ficando repetitiva aqui no Finito. Ela apareceu no trabalho sobre SOA (Arquiteturas Orientadas a Serviços) e também na série “De Brooks a Berkun“, no capítulo chamado “Os Dois donos do Projeto“. Acredito tanto na idéia que a converti em uma das práticas sugeridas em meus serviços. A maior barreira para sua adoção é a atual cultura “PM” – “o osso (o projeto) é meu e ninguém tasca!”.

    Em boa parte dos projetos em que trabalhei eu ostentei os dois bonés, de Coordenador e Arquiteto. Pior: atuava na linha de frente no pré-venda e depois seguia respondendo pelo projeto. Ou seja, era o cara do “tudo pode” que, do dia para noite (com a assinatura do contrato), se convertia no cara do “de jeito nenhum!”. Desconheço ‘pior prática’ mais nociva para um projeto. Mas ela é bastante comum. Quase tanto quanto a ilusão de que o único líder que um projeto precisa é o seu Coordenador.

    Quando apresento a sugestão a primeira pergunta que ouço é: “Mas quem manda?”. Ou seja, “Quem tem a palavra final?”. Ou então, no popular: “Qual tá na reta?”.

    Eu não tenho dúvidas de que o verdadeiro ‘dono’ do projeto é o Arquiteto (ou Diretor de cinema ou Product Owner). Principalmente quando se trata de trabalho criativo. A razão de existir do projeto é o produto que ele gera. Me parece natural que o seu ‘dono’ tenha a última palavra. O que não significa que o gerente do projeto seja uma ‘rainha da Inglaterra’. Ele tem muito a fazer pela equipe. Se ele se preocupar em apoiar a equipe, ao invés de controlar, terá entendido o papel do executor no trabalho criativo.

    ===

    Esta série recebeu um breve desvio para meu outro blog, o Graffiti. Explico: quis falar mais sobre Equipes Criativas, particularmente sobre o processo de contratação de gente criativa. Mas não quis mexer na programação original da série. Portanto publiquei lá longe um artigo chamado “Contratando Gente Criativa“. Tá tão grande que tá quase virando uma série também, hehe.

    ===

    Referências:

    1. DE MASI, Domenico.
      Criatividade e Grupos Criativos. Editora Sextante – 2002.
    2. KING, N., N. Anderson
      “Innovation in Working Group”, Publicado em
      Innovation and Creativity at Work. Wiley – 1990.
    3. DRUCKER, Peter.
      “O Advento da Nova Organização”, publicado em
      Gestão do Conhecimento – Harvard Business Review. Campus – 2001
    4. SCHWABER, Ken.
      Agile Project Management with Scrum. Microsoft Press – 2004.
    5. BROOKS, Fred.
      The Mythical Man-Month. Addison-Wesley – 1995.

    A foto acima é da Jackie “Octoberdog”, e foi obtida via Flickr.

  • A Equipe Criativa

    4ª Parte da Série “Gerenciando o Trabalho Criativo“

    “Criatividade vem dos indivíduos e não das estruturas e processos.”
    – Fred Brooks

    Mas no primeiro capítulo desta série não tinha uma citação do Peter Drucker dizendo que criatividade (ou inovação) é “uma disciplina sistemática, organizada e rigorosa”? Essa afirmação não bate de frente com a afirmação do Fred Brooks? Não. Elas são complementares. Quem cria é a equipe, os indivíduos que a compõem. Processos e estruturas devem ser desenhados com a clara intenção de facilitar a execução e o gerenciamento do trabalho criativo. Neste capítulo trataremos especificamente da formação e estruturação de uma equipe criativa. Nas duas últimas partes desta série trataremos especificamente dos processos. Encerramos o capítulo anterior perguntando como uma organização pode dar à luz uma equipe criativa.

    Projetos desafiadores, aqueles que implicitamente exigem altas doses de criatividade, costumam funcionar como ‘imãs’ para os melhores profissionais. No cenário ideal, pouco plausível no contexto das organizações tradicionais, uma equipe criativa é totalmente formada por profissionais que se alocam de forma espontânea e voluntária. Essa é a realidade na grande maioria dos projetos de Software Livre (open source) e iniciativas similares, como a enciclopédia livre Wikipédia, por exemplo.

    Em uma organização que já adote a estruturação por projetos, mesmo que parcialmente, é mais factível tentar a formação de uma equipe de voluntários. Para tal, ela deve tornar público o projeto, seus objetivos e eventuais restrições. O comitê que preparou o ante-projeto pode ser destacado para avaliar os candidatos. Estes deveriam apresentar suas motivações para participar daquele projeto e as habilidades que eles possuem e julgam ser importantes no contexto do empreendimento. Parece ser um bom indicador que pelo menos a metade de uma equipe criativa seja formada por voluntários. Eles desenvolvem um tipo de relacionamento com o projeto, um comprometimento ou até mesmo um sentimento de propriedade, que é muito salutar.

    No entanto, ainda é mais comum que as equipes sejam formadas de forma arbitrária. Ou, colocando de outra forma, seus integrantes são indicados ou selecionados por um comitê ou pelo responsável pelo projeto. Neste cenário é desejável que a organização reserve um tempo para que os integrantes se conheçam e compartilhem suas visões acerca do projeto. O entrosamento, o conhecimento mútuo entre todos os integrantes, é uma característica das equipes criativas. Mas é algo que demanda considerável tempo para ser conseguido. Por outro lado, isto não significa que uma equipe de ‘desconhecidos’ não tenha condições de desenvolver um trabalho criativo. Ela tem, mas será mais lenta que uma equipe entrosada e também oferecerá maiores riscos de conflitos entre seus integrantes.

    Uma alternativa intermediária para a formação de equipes criativas, que fica entre a alocação voluntária e a arbitrária, é a auto-seleção. A empresa seleciona um representante de cada especialidade requerida no projeto e nomeia-o líder. Cada líder pode optar por indicar ou contratar os outros integrantes de sua célula de trabalho, ou disparar uma convocação por voluntários. A estratégia dependerá do quanto ele conhece os outros profissionais disponíveis que compartilham a mesma área de especialização.

    Um componente que pode facilitar o processo de formação de equipes, tanto para a organização quanto para o líder citado acima, são as chamadas Comunidades de Prática (CP). Apesar de seu aspecto informal, é sabido que uma organização pode incentivar e promover sua existência . Uma CP reúne pessoas que trocam experiências, compartilham interesses e conhecimentos. Para um líder, a participação em uma CP pode dar mais subsídios para a convocação ou não de uma pessoa (também participante da CP), além daqueles obtidos através da convivência em um departamento ou em uma série de projetos.

    É importante lembrar que a importância das CP’s para uma organização em busca de aprendizado contínuo e criatividade vai muito além da facilitação de um processo de formação de equipes. Enquanto os projetos são finitos e relativamente esporádicos, uma CP é uma entidade e um processo de caráter permanente. A interação de uma equipe de projeto com as diversas CP’s que debatem temas correlatos, mesmo que informalmente e desprovida de compromissos, pode enriquecer o trabalho criativo.

    Após a formação da equipe criativa, a organização deve influir muito pouco em sua estrutura. Isto porque se trata de uma estrutura orgânica, que deve se adaptar dependendo do momento do projeto. Uma equipe criativa deve se auto-definir, e saber se adaptar com agilidade. Trata-se de uma característica comum e fundamental das equipes criativas. Um aspecto complementado pelo auto-gerenciamento. Que não descarta a presença de líderes na equipe, muito pelo contrário. E qual é o perfil dos líderes de uma equipe criativa?

    ===

    Próximo capítulo: “Liderando a Equipe Criativa“

    Referências:

    1. VASCONCELLOS, Paulo.
      Aprendizado Inter-Projetos. Finito – 2004.

    A foto que ilustra este capítulo é de Nesster e foi obtida via FlickR.
    É Creative Commons, aliás como tudo por aqui.

  • A Organização

    3ª Parte da Série “Gerenciando o Trabalho Criativo“

    Título alternativo:

    O Caos Criativo em uma Anarquia Organizada

    “Tudo na sociedade pós-industrial concorre para valorizar a atividade criativa, pelo menos até o quanto foi valorizado, na sociedade industrial, o esforço executivo.”
    – Domenico de Masi

    As maiores interessadas na criação de produtos ou serviços inovadores são as organizações, as empresas por exemplo. No entanto, por incrível que pareça, são as organizações que representam os maiores obstáculos para que eles surjam. “O problema, a essa altura, é como incentivar (ou, pelo menos, como não obstar) a criatividade dos indivíduos e dos grupos por meio de uma organização adequada” . Parece embutido na ‘alma’ das empresas, mesmo daquelas mais novas, um exagerado apego por rotinas e pelo pleno controle destas. Trabalho criativo e rotina são antagônicos por natureza. Por isso uma organização precisa criar ‘zonas livres’ se ela realmente deseja promover criatividade e inovação.

    Organizações bem sucedidas com sua criatividade já foram analisadas sob os mais diversos prismas. Domenico de Masi, sociólogo italiano, diz que uma organização criativa:

    • Fornece todos os recursos necessários;
    • Não condena os erros e sempre incentiva novas tentativas;
    • Não impõe prazos;
    • Incentiva o intercâmbio com outros grupos criativos; e
    • Disponibiliza instrumentos para a divulgação das idéias produzidas.

    Teresa Amabile, especialista em criatividade da Universidade de Harvard, também destaca o papel da organização como principal patrocinadora do trabalho criativo. Suas pesquisas mostram outras características das organizações criativas:

    • Liberdade;
    • Bom gerenciamento de projetos;
    • Encorajamento; e
    • Reconhecimento.

    Takeuchi e Nonaka, especialistas japoneses em aprendizagem organizacional e inovação, destacam que o compromentimento da organização é o fator primordial para a promoção do trabalho criativo. E usam o termo “caos criativo” para qualificar esse tipo de trabalho . De Masi fala em “anarquia organizada”. Como uma organização pode se comprometer com uma iniciativa que busque o ‘caos’ fazendo uso de uma ‘anarquia’?

    Muitas organizações que institucionalizaram (ou tentaram intitucionalizar) a inovação como um processo perene o fizeram através da criação de um departamento de Pesquisa e Desenvolvimento (P&D). Praticantes de abordagens consideradas mais modernas distribuíram a busca por inovação em praticamente toda a organização. Um dos casos mais debatidos nos últimos tempos, apesar da baixa visibilidade, é o da empresa Google. Lá, segundo alguns relatos, os funcionários podem dedicar 20% de seu tempo na exploração de novas idéias. No quesito reconhecimento e compensação a Google parece ser ainda mais radical: chega a comprar por US$ 10 milhões os melhores projetos de seus funcionários. Segundo um de seus fundadores, seria uma forma de evitar a fuga dos melhores cérebros. E também o surgimento de novos e ágeis concorrentes .

    Mas é importante frisar que a remuneração financeira não é o único motivador de criatividade. Reconhecimento, notoriedade, privilégios e um ambiente estimulante também compõem o ‘pacote de benefícios’.

    As áreas destacadas para a execução do trabalho criativo merecem um tratamento diferente daquele dispensado para o restante da empresa. Isso não significa que elas estarão isentas do rigor dos orçamentos e da contabilidade. Mas, ao que tudo indica, quanto mais distante a equipe destacada para o trabalho criativo estiver de normas e procedimentos, melhor. Por isso pode ser desejável que essa área esteja fisicamente separada das demais. Seria uma forma sadia de evitar ou reduzir os inevitáveis conflitos com as outras áreas da organização. Os possíveis efeitos colaterais provenientes de tal distanciamento seriam a alienação e a perda de foco em relação aos objetivos da empresa. Efeitos que podem ser combatidos através de um sistema de acompanhamento que seja pouco intrusivo e bastante objetivo.

    Segundo Peter Drucker, “as equipes têm de ser organizadas para o desempenho, e esse é um dos motivos pelos quais é tão crucial e importante que cada equipe defina claramente que resultados está buscando” . Ou seja, só justificamos o ‘caos’ e a ‘anarquia’ com a fixação de “objetivos nítidos, simples e comuns que se traduzem em ações específicas” .

    Mesmo que melhoria contínua e inovação sejam componentes da cultura da organização – disseminados e efetivamente praticados em todas as suas áreas – ainda assim ela deve disparar projetos que tenham objetivos mais específicos, demandando a formação de equipes temporárias. Tais iniciativas podem ser fruto do empreendorismo criativo ou, como é mais comum, de demandas e desafios externos. Novas tecnologias, concorrência e clientes são as principais fontes externas.

    Se, como foi colocado anteriormente, a equipe responsabilizada por desenvolver um trabalho criativo deve ter ampla liberdade, inclusive para se definir e gerenciar, como pode uma organização dar à luz uma equipe criativa?

    ===

    Próximo capítulo: “A Equipe Criativa“

    Notas levemente acopladas:

    • Este trabalho não foi selecionado para o VI Seminário do PMI-SP. Eu também não tinha gostado muito da versão original. Mas duas coisas me entristecem: Primeiro, não recebi nenhuma crítica ou sugestão dos avaliadores do PMI. Sem feedback fica praticamente impossível melhorar alguma coisa, né? Minha sugestão já foi enviada. Vamos ver.
    • Segunda tristeza: “criatividade e inovação” seguem fora do vocabulário do PMI. Nenhum dos trabalhos selecionados trata o tema de forma direta. Que pena.
    • Se vc chegou até aqui, então este graffiare merece uma lida.

    Referências:

    1. DE MASI, Domenico.
      Criatividade e Grupos Criativos. Editora Sextante – 2002.
    2. AMABILE, Teresa
      The Social Psychology of Creativity. Springer-Verlag – 1983.
    3. NONAKA, I., Takeuchi, H.
      “Theory of Organizational Knowledge Creation”, Publicado em
      Knowledge Management – Classic and Contemporary Works.
      MIT Press – 2000.
    4. BATTELLE, John.
      A Busca. Elsevier Editora – 2006.
    5. DRUCKER, Peter.
      A Administração na Próxima Sociedade. Editora Nobel – 2002.
    6. DRUCKER, Peter.
      “O Advento da Nova Organização”, publicado em
      Gestão do Conhecimento – Harvard Business Review. Campus – 2001.

  • O Trabalho Criativo

    2ª Parte da Série “Gerenciando o Trabalho Criativo“

    “Aquilo que é criativo deve criar a si mesmo.”
    – John Keats


    Domenico de Masi entende que criatividade e inovação são duas coisas distintas. Enquanto criatividade indicaria “rápidos saltos qualitativos”, inovação significaria “lentas transformações quantitativas e progressivos ajustamentos” . No entanto, parece que em livros de negócios e no entendimento disseminado os dois termos se completam: “criatividade é a semente da inovação”. A confusão existe e deve permanecer por um bom tempo. Na Wikipédia, enquanto esta parte do artigo estava sendo redigida, o termo “criatividade” estava marcado para revisão. O que as organizações buscam, na grande maioria das vezes, é o que De Masi chamou de inovação. O mecanismo de busca do Google, o iPod da Apple e o RJ145 da Embraer são exemplos de inovações. Releituras de idéias que já existiam.

    No conceito utilizado neste trabalho, o trabalho criativo, o ato de criar algo, pode gerar tanto uma revolução (um rápido salto qualitativo) quanto uma evolução (uma transformação quantitativa ou ajustamento). E o foco aqui são os projetos, “esforços temporários empreendidos para criar um produto ou serviço único” . Se todo projeto é único e gera produtos ou serviços únicos, podemos dizer que em todos projetos há trabalho criativo. Obviamente que a dose de criatividade requerida por um projeto pode ser muito pequena ou, no outro pólo, imensa – a própria razão de sua existência.

    Este trabalho mira aqueles empreendimentos que requerem mais criatividade. Mas que não se propõem necessariamente a gerar uma revolução – eles são raríssimos. Porém, os métodos e práticas aqui sugeridos podem ser úteis em projetos de qualquer natureza e porte. É importante notar que nossa capacidade criativa não é direcionada exclusivamente para o desenho do produto ou serviço que o projeto deve gerar. “Aquilo que é criativo deve criar a si mesmo”. Ou seja, a própria estrutura da equipe e a definição dos processos que devem guiar os trabalhos também são passíveis de criação. Aliás, chegam a ser consideradas atividades ou características naturais de um grupo criativo.

    Isso torna ainda mais complexo o gerenciamento do trabalho criativo. Afinal, de alguma forma, a organização deve permitir que um sub-conjunto de sua estrutura se defina e institua seus próprios métodos e processos. Flexibilidade e autonomia sem muitos precedentes no mundo corporativo. Sendo assim, qual deve ser o papel da organização quando ela pede que uma equipe desenvolva um trabalho criativo?

    ===

    Na próxima semana: “A Organização“

    Referências:

    1. DE MASI, Domenico.
      Criatividade e Grupos Criativos. Editora Sextante – 2002.
    2. Project Management Institute (PMI)
      A Guide to the Project Management Body of Knowledge – 3ª edição.
      PMI Publications – 2004.

  • Gerenciando o Trabalho Criativo

    Prólogo

    Como prometido no Graffiti, vou transcrever aqui o artigo que enviei para avaliação do comitê que está organizando o VI Seminário Internacional do PMI-SP. Mas, para respeitar o ‘padrão editorial’ do finito, vou reescrevê-lo. Artigos muito formais não combinam com o espírito deste espaço. Outra alteração: vou publicá-lo em partes, uma por semana. Vou me aprofundar um pouco mais em cada ponto do trabalho, o que não foi possível dado o (curioso) limite de 8 páginas imposto pelos organizadores daquele evento. Aliás, pode ser que meu trabalho seja recusado. Nunca se sabe. De qualquer forma, uma palestra e um workshop sobre o tema já estão prontos. Quem quiser saber mais detalhes pode me contactar por email.

    O artigo está estruturado em 8 capítulos:

    1. Introdução
    2. O Trabalho Criativo
    3. A Organização
    4. A Equipe Criativa
    5. Liderando a Equipe Criativa
    6. Criatividade em Projetos
    7. O Processo de Criação
    8. O Processo de Gerenciamento

    Espero dar dicas e fazer provocações que sejam úteis na execução e, principalmente, no gerenciamento do Trabalho Criativo. Desnecessário dizer que o seu feedback, na forma de críticas e sugestões, pode tornar este trabalho ainda mais interessante.

    Introdução

    “A Inovação é mais filha do trabalho do que do lampejo de um gênio.“
    – Peter Drucker

    As palavras inovação e criatividade estão cada vez mais presentes nas agendas de empresas e países. Em um mundo de hiper-competitividade e quase isento de fronteiras, a capacidade de criar e inovar é o que pode determinar o sucesso ou o fracasso de um empreendimento. Mas o que torna uma organização criativa?

    Entendemos hoje que raramente a criação de um produto ou serviço é fruto de uma única mente genial. Ao contrário, boa parte dos casos de sucesso documentada mostra que a inovação nasce de um trabalho de equipe. Segundo Peter Drucker, inovação é “uma disciplina sistemática, organizada e rigorosa”. No entanto, apesar do apelo e da ampla difusão do tema, ainda carecemos de referências básicas que nos auxiliam na execução e no gerenciamento do trabalho criativo.

    Por exemplo, o bom gerenciamento de projetos aparece em algumas pesquisas como a segunda característica de um ambiente que promove a criatividade . Mas o termo criatividade só é citado três vezes no PMBoK , como: i) uma habilidade desejável da equipe de gerenciamento; ii) um possível resultado de conflitos bem gerenciados; e, iii) esperado fruto da técnica brainstorming. Um detalhe ainda mais surpreendente: a palavra Inovação não aparece em nenhum momento no texto!

    A ênfase em uma filosofia de ‘comando e controle’, em detrimento do foco em inovação e aprendizado, não é uma exclusividade do PMBoK e de todos os seus derivados que norteiam a formação de gerentes de projetos. Ela caracteriza a cultura de um grande número de empresas. Seria uma conseqüência natural de um século de aplicação dos pensamentos fordista e taylorista. Para Domenico de Masi, trata-se de um cultural gap, um fenômeno que “constrangeu os atuais knowledge workers, os trabalhadores do conhecimento, a se organizarem segundo os velhos princípios industriais” . Acontece que o excesso de ‘comando e controle’, comumente traduzido na forma de procedimentos e regras, inibe e até mesmo obstrui o trabalho criativo. Liberdade é a principal característica de uma organização criativa .

    O que não significa que o trabalho criativo não possa ser gerenciado. Muito pelo contrário. Criatividade não é só a idéia. É também a capacidade de realizá-la. Uma “síntese de fantasia e concretude” . O que nos leva à questão: como conciliar liberdade com uma capacidade de realização que atenda e respeite os propósitos e restrições de uma organização? Afinal, como gerenciar o trabalho criativo?

    ===

    Semana que vem a gente começa a responder.
    Próximo capítulo: “O Trabalho Criativo“.

    Referências:

    1. DRUCKER, Peter F.
      A Administração na Próxima Sociedade. Nobel/Exame – 2002.
    2. AMABILE, Teresa.
      The Social Psychology of Creativity. Springer-Verlag – 1983.
    3. Project Management Institute (PMI)
      A Guide to the Project Management Body of Knowledge – 3ª edição.
      PMI Publications – 2004.
    4. DE MASI, Domenico.
      Criatividade e Grupos Criativos. Editora Sextante – 2002.

  • Apagando Incêndios

    Deixei a poeira baixar para não cometer julgamentos equivocados. Estou falando do ‘caos e pânico’ que assustou São Paulo há 10 dias. Minhas opiniões sobre o tema eu já deixei no BlueNoir. Aqui eu quero tratar especificamente da parte que pode ser útil em projetos. Vou falar sobre Gerenciamento de Crises e Riscos e Aprendizagem Organizacional.

    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”

  • A Receita e o Bolo de Fubá

    Série “De Brooks a Berkun” – 5ª e última parte.

    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?

  • … E a inevitabilidade das Marés

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

    ===

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

  • Vai entender o que o Cliente quer

    Série “De Brooks a Berkun” – Continuação da 3ª Parte.

    Scott Berkun dedica várias páginas de seu livro para tratar da tal ‘Engenharia de Requisitos’ (termo que ele não utiliza) e do ‘Design’ (termo que ele usa insistentemente) de uma solução. Capítulos como “How to figure out what to do“, “Where Ideas come from” e “What to do with ideas once you have them” dão o merecido tratamento aos temas.

    Para Berkun, a Perspectiva do Cliente pode ser obtida de duas formas: Requisitos e Pesquisas. E sugere que para cuidar das funções relacionadas à esses tipos de levantamentos deveríamos alocar dois tipos de experts: Engenheiros de Usabilidade e Designers de Produtos. Mas Berkun observa: “Mesmo que na última década muito progresso tenha sido feito no refinamento de métodos de pesquisa e compreensão de clientes, grande parte dele não foi assimilado pelo corpo gerencial – ou em organizações centradas na engenharia. Ainda é incomum que times de projetos tenham um expert em pesquisa de cliente, design de interfaces e usabilidade disponibilizado para os tomadores de decisão”. Na sugestão que apresentei na 2ª parte desta série, o Desenvolvedor de Interfaces realiza tais funções. Trabalhando bem próximo do Analista de Negócios.

    Muito se fala, e eu não tenho dúvidas, de que o tema ‘requisitos’ responde por mais de 50% dos problemas em nossos projetos. Berkun nos apresenta 5 dicas para a obtenção do que ele chama de “Requisitos de Alta Qualidade”:

    • Planeje as negociações de requisitos e as iterações
      Identificados nossos clientes e demais atores do projeto, torna-se factível a elaboração de uma Agenda para a Coleta de Requisitos. No pior cenário, uma RFP deve dar pistas suficientes para o rascunho de um plano inicial.
    • Elimine as Suposições Erradas
      Como identificá-las? Só perguntando. Como diz o Berkun, “se você é o coordenador do projeto … religiosamente faça perguntas esclarecedoras, como ‘por que precisamos disso?’, ‘que problema isso resolve?’”, e assim por diante. Só não permita que seu time assuma como verdadeiras solicitações que podem nem mesmo ter partido do cliente, ou dos verdadeiros usuários.
    • Busque as Informações que Faltam
      “Os mais notáveis erros em requisitos são erros de omissão”. A coleta e análise bem realizadas devem tornar bem visíveis todas as peças que faltam no tabuleiro do projeto.
    • Defina Prioridades Relativas para todos os Requisitos
      Costumo solicitar, ainda na coleta, que o cliente/usuário defina se aquela solicitação é Fundamental, Importante ou Opcional. Uma classificação clara e simples assim ajuda muito em diversas tomadas de decisão.
    • Refina ou Elimine a Linguagem Ambígua não-Intencional
      “Palavras como rápido, grande, pequeno, bonito e usável requerem métricas relativas para serem entendidas. Em alguns casos, pode ser do interesse de todos que elas permaneçam ‘em aberto’ até momentos posteriores do projeto”. Mas, a princípio, devemos eliminar toda redação que não permita um entendimento único de um requisito.

    Cabe aqui outra intromissão minha. Ainda há muito trabalho a ser realizado antes do Analista de Negócios repassar os requisitos para o time de Arquitetura da Solução. As dicas do Berkun listadas acima são úteis mas não suficientes. No meu ponto de vista, todos os requisitos coletados devem ser estruturados, formando uma ‘base de conhecimentos’. Existem algumas ferramentas desenhadas especificamente para isso. Mas o mais importante é o modelo da base. Nesta palestra, já meio velhinha (apresentada em 2003 em evento da SUCESU/PMI), apresento uma sugestão de um modelo ‘mínimo’. Em “Requirements-Led Project Management”, de Suzanne Robertson e James Robertson, há um modelo um pouco diferente, que eles chamam de ‘Requirements Knowledge Model‘. Uma base persistida em um gerenciador de bancos de dados, ao invés de documentos textuais ou planilhas eletrônicas, é mais gerenciável. Fica mais fácil manter a tal rastreabilidade bi-direcional dos requisitos e também seu relacionamento com todos os demais artefatos produzidos no projeto.

    Uma vez gravado, um requisito nunca mais pode ser deletado. Parece boba, mas se trata de uma regra fundamental. Cada mínima alteração na redação do requisito ou em algum de seus atributos significa a inserção de um novo requisito, que substitui o anterior mas mantém um vínculo. Assim conseguimos rastrear todas as mudanças que ocorreram desde os instantes iniciais de um projeto. Portanto a ‘base de conhecimentos’ acaba se tornando um dos, senão o principal subsídio para o Gerenciamento de Mudanças (tema da próxima semana).

    Perdidos no Espaço (entre os Requisitos e a Solução)

    Constatação inquietante de Berkun: “Por razões que não consigo explicar totalmente, muitas pessoas têm dificuldade com o planejamento do trabalho criativo. Na maioria dos livros que li sobre gestão de projetos e desenvolvimento de software, há pouca cobertura sobre como sair de uma lista de requisitos do que deve ser implementado para um bom design. Cronogramas apresentam uma data para quando os requisitos supostamente estarão finalizados, e outra data para quando as especificações supostamente estarão prontas, mas poucas instruções são fornecidades para a execução daquilo que está entre essas duas datas”.

    Para Berkun, tão logo estejamos com os requisitos ‘no lugar’, “os designers podem explorar o território desenhado pelos requisitos. Há um largo espaço, chamado ‘Espaço do Problema’, de maneiras potenciais para resolver o problema colocado. Dependendo dos requisitos, este espaço pode ser bem grande; por exemplo, há um infinito número de possibilidades para se desenhar uma casa, um sistema de contabilidade, um web site ou seja lá o que for que esteja lhe pagando. Portanto, até que você tenha alguma noção das possibilidades que existem, não é muito esperto se comprometer com qualquer coisa descoberta nos momentos iniciais”.

    É a fase em que temos só uma folha ou um quadro branco. Brancos e vazios. É a fase das Idéias – apaixonante para alguns e apavorante para outros. As idéias vêm das pessoas, lembra Berkun: “nenhuma idéia na história da humanidade brotou de uma pilha de pedras, … , de livros de auto-ajuda, de seminários de criatividade ou de sessões de brainstorming“. Por que então a fase de design (Arquitetura da Solução) seria tão negligenciada? Para Berkun, “talvez seja porque as pessoas temem a exploração , especialmente quando estão sendo observadas”.

    Berkun diz ter “evidências irrefutáveis de que há um número infinito de idéias prejudiciais, horríveis, inúteis, comicamente estúpidas e embaraçosamente ruins”. Ele solta essa pérola ao questionar a máxima (segundo ele oriunda de comerciais de TV e de sessões de brainstorming – ou de comerciais de TV vendendo sessões de brainstorming) que diz que “não existem más idéias”. Lógico que elas existem. Aos borbotões. Dentre outras coisas, ele sugere algo muito simples: “Boas perguntas atraem boas idéias!”

    Para Berkun existem dois tipos de perguntas ‘Boas’ e um tipo de pergunta ‘Ruim’ quando estamos envolvidos em um trabalho criativo:

    • Perguntas Direcionadoras (Boas)
      “Chamam a atenção do time para algo importante, útil ou mesmo central para o trabalho em execução”. Tipo: Como o usuário saberá que deve clicar neste botão para ir para a próxima tela?
    • Perguntas Criativas (Boas)
      Ao contrário das questões direcionadoras, estas devem “levar o time para territórios ainda não explorados do problema em questão”. Algo como: Haverão outros meios para o cliente chegar na próxima tela?
    • Perguntas Retóricas (Ruins)
      “Gêmeas das questões criativas, diferenciam-se pelo fato de serem insinceras, perguntadas sem a intenção de se obter uma resposta”. Por exemplo: Aí ‘cai a ficha’ e o cliente de repente descobre que tem que ir para outra tela, certo?

    Mas, independente da qualidade (e da inteligência) de nossas perguntas, devemos esperar diversas idéias ‘ruins, comicamente estúpidas, hilariantes’ etc. Triste é o ambiente pouco tolerante a elas, porque, além de sisudo e monótono, inibe a participação de todos os membros da equipe, mina o espírito de colaboração que deveria existir durante todo o projeto. Além de desperdiçar boas piadas, né?

    Seguindo com Berkun: “É melhor que a gente suje as mãos e cometa vários erros nesta fase. Quanto antes isso acontecer, mais rápido a gente chega às boas idéias.”

    “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

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

    Berkun também detona outro ‘mantra’, comum em certos círculos por aí, o tal (sorry, mas só o vejo sendo usada em inglês): “think outside the box”. “Não é a eliminação das ‘caixas’ a parte mais difícil – é exatamente saber quais ‘caixas’ utilizar e quando. Restrições estarão sempre presentes”. E completa: “faça o que você quiser com a caixa. Pense dentro da caixa, fora da caixa, debaixo da caixa, corte-a e faça fogo com ela, qualquer coisa, desde que você gerencie para resolver os problemas identificados como críticos para o projeto”.

    O Problema do Tamanho do ‘Espaço do Problema’

    “Idéias fogem do controle”, diz o título de um sub-capítulo do livro de Berkun. Por isso, “se é difícil encontrar boas idéias, é muito mais complicado gerenciá-las”. Berkun diz que um erro muito comum é tratar o processo de design como se fosse um grande ‘interruptor’. Para ilustrar melhor a questão Berkun apresenta o gráfico abaixo:

    A partir de uma sólida base de (bons) requisitos, começamos a explorar alternativas de solução. Com o passar do tempo a tendência é que o número de alternativas (cenários) aumente. Aumentamos assim o tamanho do ‘Espaço do Problema’. Um dos riscos, segundo Berkun, é não saber o momento de parar com a geração de idéias e começar a filtrá-las. Para tal Berkun sugere a fixação de alguns pontos de checagem. Como ilustra o gráfico abaixo, são 6 os grandes check-points que deveriam nos guiar no processo de arquitetura da solução:

    1. Visão e Prova de Conceito
      Nosso ponto de partida deveria ser um documento de visão e uma prova de conceito. Traduzindo para Pindorama: será a tal ‘proposta técnica’ para muitos corajosos colegas.
    2. Agrupamentos de Idéias
      Depois de um certo tempo jogando conversa fora, digo, idéias ‘para fora’, é conveniente que elas sejam agrupadas e analisadas.
    3. Três Alternativas
      Naquele que deve ser identificado como ‘meio do caminho’ desta etapa do projeto, é indicado que a lista de alternativas seja filtrada, gerando de 3 a 5 alternativas mais viáveis.
    4. Duas Alternativas
      Pouco tempo depois deveríamos ser capazes de escolher apenas 2 alternativas de implementação.
    5. Um Design
      E então apenas um design (ou Arquitetura da Solução).
    6. Especificações
      Então, com a Arquitetura definida, geramos a especificação técnica da solução.

    Concordo com o que o Berkun disse em um dos trechos de nossa viagem pelos “Castelos de Areia”. Não é comum ver este tipo informação em livros de gerência de projetos e desenvolvimento de sistemas. Mas as “marés (mudanças) são inevitáveis”, não? Semana que vem conversamos sobre elas.

    ===

    1. Suzanne Robertson e James Robertson, “Requirements-Led Project Management“, Addison-Wesley (2005).

  • Castelos de Areia…

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

    Em 1986 Fred Brooks publicou o artigo “No Silver Bullet”, que aparece como o capítulo 16 da edição que comemorou os 20 anos de “The Mythical Man-Month”. Para Brooks, “ainda cometemos erros de sintaxe, com certeza, mas eles não são nada quando comparados aos erros conceituais da maioria dos sistemas”. Scott Berkun cita Brooks na abertura do capítulo “How to figure out what to do”, o terceiro de “The Art of Project Management”:

    “A parte mais difícil da construção de software é decidir o que construir. Nenhuma outra etapa do trabalho conceitual é tão difícil quanto a fixação dos requisitos técnicos detalhados, incluindo todas as interfaces com usuários finais, com máquinas e outros sistemas. Nenhuma outra etapa compromete tanto o projeto se executada erroneamente. Portanto, a função mais importante que o construtor de software executa para seu cliente é a extração iterativa e o refinamento dos requisitos do produto”.

    Para Brooks, trata-se de uma função que deveria ser executada por uma pessoa ou um grupo pequeno de pessoas. Seria, para ele, uma forma de garantir a ‘Integridade Conceitual’ de uma solução. A separação desta etapa, quando decidimos ‘o que deve ser construído’, da etapa de implementação, quando decidimos ‘como construir’, seria outra forma poderosa de buscar tal integridade.

    Berkun chama de ‘insanamente simples’ a forma como ele vê a etapa de planejamento de um projeto. Ela é representada no gráfico abaixo:

    E, seguindo em sua ‘insanidade’, Berkun justifica a necessidade de Planos. Segundo ele, os planos “funcionam como um remédio contra todo tipo de estupidez porque forçam que questões importantes sejam resolvidas enquanto há tempo para considerar outras opções”.

    Apesar de uma (sutil) diferença, ambos os autores concordam com a separação das fases de Domínio do Problema (ou ‘o que’, coleta de Requisitos, Definição etc) e de Domínio da Solução (ou ‘como’, design/especificação etc). Uma distinção óbvia, simples, mas deveras negligenciada. Quantas e quantas vezes testemunhamos ‘analistas’ (assim, entre aspas mesmo) discutindo ‘comos’ em dias iniciais de um projeto?

    Brooks radicaliza ao propor que o principal artefato gerado pelo Arquiteto de uma solução é o Manual, uma especificação de toda a parte externa de um sistema. É o manual do usuário mesmo, nas fases iniciais de um projeto! Um documento que não deveria se preocupar em explicar os ‘comos’.

    As Visões e o Documento de Visão

    Berkun é um pouco mais metódico e indica a necessidade de 4 documentos principais. Antes, porém, ele alerta para a criticidade do balanceamento de três perpectivas:

    • Negócio: “… quando equipes de engenharia ignoram como seu negócio funciona, muitas decisões da gerência parecerão ilógicas ou estúpidas”;
    • Tecnologia: “…é o mindset de construção e materiais. Tem o foco em ‘como’ as coisas devem ser feitas”;
    • Cliente: “A mais importante das três perspectivas… Mas, infelizmente, a mais fraca em muitas organizações.”

    Segundo Berkun, as três perpectivas sempre se sobrepõem. “Cada consideração ‘de negócio’ tem implicações Técnicas e para o Cliente (e assim por diante)”. E cada decisão pode favorecer determinado ponto de vista, em detrimento de outro. “Ao investir tempo explorando cada uma das perspectivas”, diz Berkun, “é possível ver oportunidades para melhores decisões estratégicas”.

    Para Berkun, a fase de planejamento de um projeto só se encerra quando os 4 documentos propostos por ele estão prontos. Ou, em suas palavras: quando “as decisões que eles contêm estão tomadas”. Os documentos são:

    • Marketing Requirements Document (MRD)
      Trata-se da ‘Visão do Mundo’ apresentada pelo negócio ou sua equipe de marketing. Apresenta os objetivos do negócio e ajuda a definir “o que” o projeto deve contruir visando sua satisfação;
    • Documento de Visão (Escopo)
      Define os objetivos do projeto, explica sua lógica e apresenta características (em alto nível), requisitos e datas. Definem diretamente “o que” o projeto deve realizar;
    • Especificações
      Define o “como” de um projeto, com uma perspectiva de design e engenharia;
    • Work Breakdown Structure (WBS)
      Mostra como o time trabalhará para realizar o projeto.

    Berkun também parece cair na ‘armadilha’ waterfall quando propõe que a fase de planejamento de um projeto só se encerra com a entrega (definitiva) destes 4 documentos. Apesar de indicar os aspectos iterativos e incrementais de sua elaboração. Não deveriam ser apenas os ‘acidentes’ (também conhecidos como ‘mudanças’) que nos forçam a voltar a tais documentos (tal fase).

    Se o MRD (que pode ser um RFP – Request for Proposal, por que não?) é (ou pelo menos deveria ser) elaborado pelo Cliente, temos que o primeiro documento confeccionado pelo time do projeto é o Documento de Visão. Segundo Berkun, além de apresentar e explicar todas as características (features) do produto a ser gerado, como no Manual sugerido por Brooks, o documento deve:

    • Explicar o projeto em apenas uma sentença (uma ‘declaração de visão’);
    • Mostrar como o projeto contribuirá para a satisfação dos objetivos do negócio;
    • Apresentar as características/cenários essenciais para os Clientes (prioridade 1);
    • Mostrar as características/cenários considerados ‘desejáveis’ mas não essenciais (prioridade 2);
    • Apresentar os clientes e os problemas que o projeto deve solucionar para eles;
    • Bem como apresentar os atores (stakeholders);
    • Explicar por que os clientes comprariam (ou alugariam) o produto do projeto;
    • Apresentar os concorrentes e uma comparação de seus produtos com aquele que o projeto deve gerar;
    • Explicitar o que está “fora do escopo” do projeto;
    • Mostrar quais os riscos do projeto;
    • Suas dependências externas (sub-contratados e afins);
    • Em alto nível, como o trabalho será organizado; e
    • Apresentar todas as suposições e dependências.

    Ou seja, o Documento de Visão, como proposto por Berkun, compila todas as informações e decisões elaboradas no planejamento inicial de um projeto. Esta compilação, escrita de forma a ser acessível/legível para todos os atores de um projeto, se torna um dos principais meios de comunicação/negociação com os clientes. Não entendo porque Berkun não sugere a inserção de um cronograma. Outra alteração que eu faria é a criação de uma ‘prioridade 3’, com a lista de todas as características/cenários classificados como ‘perfumaria’ ou supérfluos.

    Berkun sugere que 5 iterações seriam suficientes até a geração de uma versão final do Documento de Visão. Acho arriscado fixar assim o número de ‘versões’. Cada projeto pode determinar um ritmo/ciclo bastante particular. Mas creio que um mínimo de 3 iterações sejam necessárias. O trabalho nas Especificações e na WBS gerará, sem dúvidas, alterações na Visão.

    Por fim, Berkun destaca as 5 qualidades de uma “Boa Visão”:

    • Efeito “Simplificador”;
    • Apresenta de 3 a 5 objetivos de alto nível;
    • Consolidada;
    • Inspiradora; e
    • Memorável.

    O fato do autor, no caso Scott Berkun, manter um blog faz com que seu livro seja constantemente atualizado. Recentemente Berkun publicou um pequeno artigo chamado “Why vision documents stink“. Isso mesmo, ‘cheiram mal’. Ele comenta que em levantamentos informais, em suas palestras por exemplo, constatou que a grande maioria dos Documentos de Visão são muito ruins. Ele tem três teorias para o problema:

    • A falta de um ‘autor-líder’ que, no meu ponto de vista, deveria ser o próprio Arquiteto;
    • Os documentos não seriam escritos para servir ao leitor, denotando falta de compreensão e de interação com o cliente; e
    • A confusão entre ‘hype’ e realidade, que geraria documentos meio ‘marketeiros’ e pouco objetivos.

    continua…