Para esta sequência precisamos recuperar duas citações do artigo anterior:

• A conversão de dados em informação requer conhecimento. (Peter Drucker)
• Conhecimento é a capacidade de agir. (Karl-Erik Sveiby)

De carona nas afirmações acima conclui que “requisito é conhecimento produzido por conhecimento”. Estamos falando de aprendizagem – aprendizagem organizacional. Como uma organização aprende? Como ela gera (produz) e dissemina conhecimentos¹?

A resposta exige que saibamos que existem apenas dois tipos de conhecimentos²:

• Tácito: pessoal, específico de um contexto, difícil de comunicar. Existe em duas dimensões:
  • Técnica: comumente identificado como know-how (saber como fazer);
  • Cognitiva: crenças, valores, ideais, percepções, emoções e modelos mentais.
• Explícito: codificado, transmitido de maneira formal e sistemática.

O conhecimento tácito reside nos corações e mentes das pessoas. É aquele que vai embora da empresa todo dia lá pelas cinco ou seis da tarde³. O explícito fica – persistido em documentos, sistemas, bancos de dados, pôsteres, mensagens em correios eletrônicos e redes sociais etc.

A aprendizagem organizacional – a geração e disseminação de conhecimentos – se dá nas conversões de conhecimentos ilustradas no diagrama ao lado.

Na socialização – de conhecimento tácito para tácito – a troca se dá através de conversas e da observação ou experiência direta, tête-à-tête. É como se inicia um processo de aprendizado. Aqui temos razoável largura de banda – quantidade de informações transmitidas. Por outro lado, temos também um problema de escalabilidade. Pense em uma reunião com dezenas ou centenas de pessoas. A eficácia do aprendizado via socialização é inversamente proporcional ao número de participantes.

Ao sintetizar conhecimento tácito em explícito temos a externalização. Quando critico as verborrágicas especificações funcionais estou apontando para este quadrante. São notórias nossas dificuldades neste tipo de conversão de conhecimento. Mas não são novas. Diderot também penou bastante para transcrever naquela que seria nossa primeira enciclopédia um conhecimento que até então (circa 1750) era exclusivamente tácito. Ele queria explicar pelo menos o básico sobre todos os trabalhos artesanais da época. Descobriu que a observação ativa (para aprender) e as imagens (para explicar) eram as ferramentas mais eficazes. Hoje, no trabalho com requisitos, Diderot ainda tem muito a nos ensinar.

A conversão de conhecimento explícito em outro formato explícito é o que acontece na combinação. É o que faz um desenvolvedor, por exemplo, quando parte de modelos e especificações para criar código. É importante entender que combinação é síntese – criação de um novo todo a partir de partes distintas – e não uma mera tradução de formatos (ou o fatídico e dispendioso passar a limpo). Na combinação não há conhecimento novo sendo gerado. Por isso cada conversão deste tipo deve ser avaliada com carinho. O produto da conversão deve ter inequívoco valor para alguém ou para a organização. Um modelo ou documento que só existe porque “a metodologia exige” é grana que escorreu pelo ralo.

Por fim, temos a internalização – a conversão de conhecimento explícito em tácito. É o aprendizado que se dá a partir do que está escrito, desenhado ou registrado de alguma forma. Ao contrário da socialização, aqui temos grande potencial de escala (de atingir grande número de pessoas). Por outro lado, a banda não é tão larga – a quantidade de informações passíveis de transmissão é consideravelmente menor.

Essas conversões não ocorrem de maneira isolada ou única. A sequência descrita acima acontece infinitas vezes dentro de uma organização, formando uma espiral. Pois é, a aprendizagem organizacional é naturalmente iterativa (iterar = repetir) e incremental (construída a partir dos produtos das etapas anteriores). Dá pra imaginar o espanto e desalento dos papas dessa matéria quando apresentados aos cansativos debates sobre processos plan-driven versus change-driven. Porque essa divisão não existe!

O modelo SECI, nome do diagrama acima, não é uma proposta de processo ou método. É a conclusão de uma pesquisa²: é assim que as organizações aprendem, intencionalmente ou não. Reconhecer o modelo é o primeiro passo para uma conversa séria sobre aprendizagem organizacional e gestão do conhecimento.

Sintetizando: Nós conversamos sobre necessidades e restrições com nossos usuários e clientes (socialização); Durante e depois das conversas nós transcrevemos parte daquele aprendizado – estruturando requisitos, redigindo especificações de casos de uso, rabiscando modelos etc. (externalização); Criamos outras derivações dos requisitos – como mockups, storyboards, protótipos ou versões alpha e beta – de forma a confirmar que todos os envolvidos compartilham o mesmo entendimento (combinação); o confronto com esse conhecimento explicitado na forma de modelos ou versões de um sistema (internalização) nos dá novas certezas e dúvidas – novas necessidades e restrições – sobre as quais vamos conversar, o que nos remete ao início deste parágrafo.

Desta vez ficou fácil cravar o tema da próxima parte. Será sobre canais de comunicação e ferramentas sociais.
Porque tudo começa na socialização. Até lá!

Notas

1. Conhecimento é uma das cinco dimensões de um sistema sociocultural (de uma empresa, por exemplo). Quando apresentei o tema na série anterior, Pensando Negócios, escrevi que são dois verbos – duas preocupações – que caracterizam a forma como uma organização trata cada dimensão. Os verbos são Gerar e Disseminar. Neste novo contexto eles podem ser trocados por apenas um: Aprender. Se o tema lhe interessa, recomendo a leitura das partes V e VI daquela série.
2. Os pais do modelo aqui apresentado são Hirotaka Takeuchi e Ikujiro Nonaka. Recomendo dois trabalhos: Gestão do Conhecimento (Bookman, 2008) e Knowledge Management – Classic and Contemporary Works, coletânea de artigos compilada por Daryl Morey, Mark Maybury e Bhavani Thuraisingham (MIT Press, 2000). Os artigos clássicos de Takeuchi e Nonaka são de 1995/96. Um deles está neste último livro. Outro deu origem ao método conhecido como Scrum.
3. Tenho quase certeza de que o autor original desta brincadeira foi Thomas Stewart, autor de outro livro fundamental sobre aprendizagem organizacional: Capital Intelectual (Campus, 1998).

Neste artigo vou tratar especificamente das formas como coletamos, descobrimos, inventamos e entendemos requisitos. Karl Wiegers, em “More About Software Requirements” , faz um importante alerta sobre a forma como chamamos esta atividade em um projeto de software. O termo coletar, segundo Wiegers, é enganoso. Nos leva a entender que os requisitos estão lá, estáticos, esperando a hora da colheita. Por isso falei que “coletamos, descobrimos, inventamos e entendemos”. Espero ter passado a correta amplitude do trabalho.

No post de ontem falei que temos dois grandes grupos de técnicas de aprendizado: a Socialização (interação pessoal) e a Internalização (interação com documentos dos mais diversos tipos). Vamos estruturar as técnicas de levantamento (e descoberta, invenção…) de requisitos nestes dois grupos. Veja o gráfico abaixo :

As técnicas de socialização, ou seja, aquelas que empregamos para a absorção e troca de conhecimento tácito, são as seguintes: Workshops / JAD, Entrevistas, Observações e Brainstorming. Coloquei o “Fone” ali só para fins ilustrativos (e para possibilitar outro nível de comparação). Cabe uma breve descrição sobre cada técnica:

• Workshops / JAD: reunião com um número relativamente grande de participantes. É um evento estruturado, possui agenda, duração e temas pré-definidos.
  Um Analista de Negócios (AN) pode ser alocado para planejar e organizar o evento, além de funcionar como um facilitador durante a sua execução. Neste caso é importante que exista outra pessoa (outro AN), registrando as discussões e decisões.
• Entrevistas: igualmente estruturado (ou seja, com agenda e pauta pré-determinados), é executado com um número menor de pessoas. Sua vantagem em relação aos workshops é uma certa facilidade em se manter o foco das discussões. Mas a falta de pontos de vista divergentes pode ser um fator negativo.
  Novamente o cenário ideal exige a presença de dois AN’s, um conduzindo a reunião e outro registrando os achados.
• Observações: técnica particularmente importante quando executamos a análise e modelagem do negócio e seus processos. Existem duas variações principais: i) Ativa, quando o AN executa as tarefas de um usuário; e ii) Passiva, quando o AN se limita a observar o trabalho do(s) usuário(s).
• Brainstorming: polêmica técnica que pode ser útil quando o projeto exigir criatividade, inovação. É complicada sua condução porque não há uma pauta pré-definida. O AN deve cuidar para que as idéias fluam sem nenhum tipo de interferência ou crítica. Sua eficácia depende muito do perfil e do humor dos participantes.

Todas as técnicas de socialização aparecem no quadrante de alta eficácia e riqueza. Os “agilistas” não erram quando dizem que nada substitui o “tête-à tête”. Um bom AN não se limita, em todos esses eventos, a registrar as conversas. Sinais, gestos e expressões podem ser muito relevantes também. O “mapeamento psicológico e sociológico” dos stakeholders também pode ser executado, de forma implícita e nada intrusiva. Para a execução e condução de todas as técnicas acima exige-se do AN grandes habilidades “sociais” (soft skills): comunicação, negociação, intermediação, e por aí vai.

Ao contrário das técnicas de internalização, que exigem habilidades bastante distintas. São elas: Código Fonte, Código Executável, Pesquisa e Documentação. O “Email” aparece no gráfico acima apenas para fins de ilustração. Vamos entender um pouco mais sobre cada uma delas:

• Engenharia Reversa: aparece na figura acima em três formatos, já que cada um deles possui uma classificação diferente.
  Código Fonte: sua análise é a mais rica de todas, já que permite um diagnóstico completo de um dado sistema. Também conhecida como “análise Caixa-Branca”. Dependendo da formação do AN, ele não terá condições de executar este tipo de análise. Dependerá de desenvolvedores.
  Código Executável: ou “análise Caixa-Preta”, mais factível de execução por um AN. Ele usa a aplicação e extrai idéias (casos de uso e requisitos).
  Documentação: deveria figurar em um lugar mais nobre no gráfico. Mas todos sabemos que muito raramente encontramos uma documentação boa (quando encontramos alguma documentação! Atualizada então…)
• Pesquisas: podem envolver algum tipo de socialização mas, neste caso, entrariam como uma variação dos “workshops” (acima). Estamos tratando aqui de pesquisas onde não há um contato pessoal. As pesquisas são muito úteis quando o usuário não é conhecido ou o número de usuários é grande demais. Existem dois grandes modelos:
  Questionários: pesquisas normais, onde uma população amostral é previamente selecionada. Os questionários podem ser abertos ou fechados (múltipla escolha). Podem nortear o desenvolvimento de um novo produto ou serviço.
  Versões de Testes: ou o “processo Google” de validação, com suas quase eternas versões “beta”. Um produto ou serviço, em versão de testes (ou protótipo), é disponibilizado para um grupo de pessoas pré-selecionado. Suas observações (na maioria voluntárias) são requisitos que devem ser coletados e analisados pela equipe.

Quero crer que assim ficou clara a diferença entre conhecimento tácito e explícito, e como ambos podem ser importantes em um projeto de software (ou de qualquer natureza). Como eu disse anteriormente, a ênfase no conhecimento tácito (conforme interpretada e proposta por alguns “agilistas”) gera um certo tipo de miopia no projeto.

Um AN “completo” desenvolve habilidades para selecionar e aplicar as melhores técnicas para cada tipo de projeto. Primeira habilidade obrigatória: humildade para reconhecer determinada limitação e pedir ajuda.

Notas:

1. More About Software Requirements
   Karl E. Wiegers. Microsoft Press (2006).
2. Gráfico foi inspirado neste, extraído de
   The Enterprise Unified Process: Extending the Rational Unified Process
   Scott Ambler, John Nalbone e Michael J. Vizdos. Prentice-Hall (2005).

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

“Especialização é para insetos!”. O romântico manifesto de Heinlein, em mãos erradas, pode causar um estrago e tanto. Vou surrupiar a réplica de alguém que não tem nada a ver com sci-fi, Peter Drucker :

… conhecimento, por definição, é especializado. Com efeito, as pessoas realmente detentoras de conhecimentos tendem ao excesso de especialização, qualquer que seja seu campo de atuação, exatamente porque sempre se deparam com muito mais a aprender.

A organização baseada em informações exige, em geral, muito mais especialistas do que as empresas tradicionais do tipo comando e controle.

Mixando os dois autores podemos concluir que as empresas baseadas em informações são verdadeiras colméias ou formigueiros, certo? A analogia é interessante, mas não vou brincar com metáforas. Como eu disse em um rendiconti, meu problema é com os ‘especialistas generalistas’. Lá eu disse que um melhor termo seria ‘especialistas não-alienados’: i) Profissionais que reconhecem e respeitam as outras especializações; ii) estão comprometidos com os objetivos do negócio (do projeto); e iii) sabem trabalhar em equipe. Acho que isso não deveria ser um diferencial – em lugar nenhum. É pré-req em qualquer profissão, não?

Mas a tese de Mr Ambler vai um pouco além. Para ele, ‘reconhecer’ as outras especializações é conhecê-las de fato. Ele chega a sugerir a seguinte trilha de evolução (é só um exemplo fictício, ele diz):

Não tenho nada contra um profissional buscar outras áreas de conhecimento. Muito pelo contrário. Mas a evolução acima é possível? Se Java, .Net, tecnologias de bancos de dados, metodologias de gerenciamento de projetos e de modelagem fossem congeladas – parassem de mudar e de evoluir, talvez. Mas, definitivamente, não é esse o caso. Alguém que tenha parado de estudar Java há 3 anos seria considerado um especialista hoje? Algumas das áreas de conhecimento citadas por Ambler se entrelaçam. É natural que o especialista em uma delas seja também muito bom em outra. Java e modelagem, por exemplo. Aliás, dependendo da ferramenta, trata-se de uma tarefa só. Um melhor exemplo talvez seja Java e testes, ou Java e deployment. Btw, neste último quesito, muita gente fica devendo. Mas essa é outra história.

O maior problema com a tese, em minha opinião, é a forma como ela desconsidera a dinâmica que vivemos. Alguém que tenha aprendido Cobol lá nos anos 80 até que poderia se dar bem hoje, com um mínimo de esforço de atualização. Podemos dizer o mesmo em relação ao VB ou Java, por exemplo?

O fato é que, para ser um especialista hoje em dia, gasta-se muito tempo. As plataformas tecnológicas cresceram muito, para os lados e para cima. A complexidade dos ambientes aumentou exponencialmente. E, pior, ainda são relativamente imaturas. Ou seja, mesmo que o cara não durma e seja um mestre em ‘leitura dinâmica’, é difícil se manter um especialista. O que dizer então de um ‘especialista generalista’ conforme proposto por Ambler? Só se ele já estiver contemplando o uso de um plug como o do Neo em Matrix.

O post ficou longo e, como eu previa, receberá uma seqüência. Quero colocar a questão dos ‘especialistas generalistas’ no contexto dos projetos. Tirando o lado individual, que procurei destacar aqui, trata-se do maior risco. Equipes multi-disciplinares viraram, em alguns lugares, equipes de profissionais multi-disciplinares.

Sei que a maior parte dos colegas defensores da tese do Ambler são muito bem intencionados. Juan Bernabó, por exemplo, apresenta-a de uma forma muito legal. Mas, infelizmente, não consigo ignorar um tom meio ‘facista’ de alguns. Me desculpem o termo – mas é assim que interpreto. Quando falam de ‘super-desenvolvedores’ que sabem fazer tudo no projeto, e ainda se auto-gerenciam… Sei lá, parece que querem dizer: “o mundo é nosso”. Aliás, achar que dá para ser bom demais em tudo é uma baita falta de respeito com outros especialistas. Mas esse papo fica para a próxima semana.

1. O Advento da Nova Organização
   Peter F. Drucker. Artigo publicado originalmente na edição de jan-fev/88 da Harvard Business Review. Republicado no livro “Gestão do Conhecimento – HBR”, da Editora Campus (2001).

Título alternativo:

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

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.

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”