Hoje quero falar sobre o terceiro e último módulo daquela palestra, sobre o nosso “Museu de Grandes Novidades”. O primeiro módulo falava de pessoas e times e foi registrado aqui nos artigos “O Clube da Esquina Globalizada” e “O Cubículo Global“. O segundo tratou de tecnologias e arquitetura corporativa, tema que mereceu duas entradas: “(Pensando Alto sobre) Arquitetura Corporativa” e “Arquitetura do Negócio“. O prato quente é servido no final e o tal “Museu” foi a figura selecionada para puxar assunto sobre processos (metodologias) e projetos. Sim, eu esperava reações ruins entre as boas e indiferentes: “No size fits all!” Aliás, quem abre o tema com o slide abaixo não pode esperar coisa muito diferente, né?

O “outras relíquias” do título indica a existência de um slide anterior. Verdadeira jóia: a certidão de nascimento do modelo ‘Cascata’. Mas, peraí: queria eu requentar debate tão chato e batido? Não era a intenção. E tento aplacar ânimos dizendo se tratar de um ‘Museu’, não de uma lixeira. Guardamos em um museu coisas que merecem ser vistas, lembradas e estudadas. Mostramos em um museu peças que têm valor. Preciso reforçar a questão que repeti várias vezes na palestra e que rotulei como ‘retórica’ (só pra tentar provar o contrário): nossas teorias (sobre engenharia de software) resistem ao confronto com as pessoas e tecnologias de hoje? Quantas ou quais sobreviveriam de fato? Minha cara e meu caro, se eu tivesse a resposta não estaria aqui, gastando o seu e o meu tempo.

Também não se trata da elucubração isolada de um mineiro de Varginha que desfila lorotas nas horas vagas. O SEMAT (Software Engineering Method and Theory), que tem entre seus signatários algumas das pessoas que mais contribuíram com a área em todos os tempos, afirma com todas as letras em sua “chamada para a ação” que aquilo que conhecemos (conhecemos?) sobre engenharia de software encontra-se num perigoso e escuro mato sem cachorro porque:

• Está repleta de modas e tendências, coisa que não combina com *engenharia*;
• Está carente de uma base teórica forte e amplamente aceita;
• Está abarrotada de métodos e variações com diferenças pouco compreendidas e artificialmente aumentadas;
• Está pobre-pobre-pobre-de-marré-marré-marré em termos de avaliações e validações. Cada um fala que seu “método” funciona e pronto; e
• Há uma divisão entre práticas da indústria e pesquisas da academia.

Não consigo pensar em nenhuma outra área do conhecimento humano que tenha passado por algo semelhante. Repare bem: um grupo de pessoas que escreveu os livros e nos ensinou engenharia de software nos últimos 40 anos concordou com um diagnóstico nada favorável do nosso estágio atual. Repare também que entre os signatários existem representantes de todas as “escolas” relevantes, da extrema-direita até a extrema-esquerda. Hã.. ok. Alguns caras da extrema-esquerda que inicialmente concordaram com o diagnóstico tiraram o time de campo quando viram que o papo centro-direitista não os agradaria nem um pouco. Não importa. E também não creio que o SEMAT, pelo andar da carruagem, gere algum resultado. Mas o estrago está ou deveria estar feito. Ou alguém não concorda com o diagnóstico apresentado?

.:.

Definitivamente, minha intenção não é promover o bilionésimo papo besta sobre “cascateiros X agilistas”. Acontece que, tanto no evento aberto quanto em um fechado, teve gente que se sentiu pessoalmente atacada pelo conteúdo e, desconfio, pelo tom utilizado.

Uma pessoa que participou da edição fechada desta palestra no último dia 9/11 manifestou enorme descontentamento com o evento. Detalhe: ela registrou sua insatisfação na forma de um comentário no último artigo publicado. Outros detalhes: utilizando nome falso, insinuando uma insatisfação geral e, indevidamente, registrando um link para o site da empresa contratante. Empresa que solicitou a remoção do comentário ou, no mínimo, do link que a identificava. Nunca cogitei a censura ao comentário (blog que é blog não modera nem censura). Mas, claro, retirei a referência para a empresa. Pela atenção, pelo time e pela rapidez na resposta, a empresa não merecia ver seu nome associado a comportamento tão feio e desonesto.

Já fui atacado de quase tudo quanto é jeito pelas ideias que defendo e pelo que critico. Na grande maioria das vezes o ataque ou resposta, mesmo os mais agressivos, não é covarde. Não é anônimo. É o mínimo que se espera, certo?

.:.

Já escrevi por aqui que esta palestra é uma coletânea de temas que, por vários motivos, repousavam em minha gaveta. Pra ser sincero, não acreditava na viabilidade dos temas (em termos econômicos e políticos, hehe). Estouro champanhe quando erro assim. Além da apresentação para quase 100 profissionais de uma mesma empresa, ontem tive a chance de levar o mesmo papo para um território que parecia ser, no mínimo, inusitado. Ganhei um belíssimo presente da Profa. Renate Landshoff: a oportunidade de apresentar “O Futuro não é mais…”  para duas turmas do curso de graduação em Biblioteconomia da FESPSP (Fundação Escola de Sociologia e Política de São Paulo). Além da bela e antenada turma, contei com a enriquecedora presença de Sérgio Storch. Não vou tentar explicar agora o exótico mashup que se desenha. Mas algumas pistas você encontrará neste artigo da Profa. Renate (e respectivos comentários).

“Beans“, a foto utilizada neste artigo, é de autoria de Naomi Ibuki e foi obtida no Flickr.

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

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

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

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

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

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

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

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

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

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

O Argumento Derradeiro

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

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

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

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

.:.

Nome aos Bois e Pingos nos ‘is’

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

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

.:.

Observações

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

Em todas as turmas do FAN, quando mostrando como todos os requisitos devem derivar dos objetivos do negócio, sempre comentei o seguinte: meu currículo apresenta projetos que tiveram problemas com prazos e orçamentos. Alguns maiores, outros nem tanto. Só me sentiria envergonhado se apresentasse ali algum projeto que tivesse falhado na realização dos objetivos do negócio.

A comunidade de gerenciamento de projetos tem demonstrado maior preocupação com o Valor gerado para os negócios. Dentre vários artigos e outros trabalhos distingue-se, por exemplo, “Diferenciando os Alinhamentos Estratégicos de Projetos“, de Ana Helena Moreira e Fabio Medeiros, publicado na MundoPM de Abr/Mai de 2009. Eles demonstram como a Proposição de Valor de uma organização, da qual derivam as estratégias, deve direcionar “o foco e o conteúdo dos elementos do gerenciamento de projetos”. Aliás, o título do editorial da mesma edição, assinado por Zózimo, é “Valor“.

O PMBoK¹ não dá margens para dúvidas quando registra que “projetos são meios para a realização de metas ou objetivos da organização”. Nem quando afirma que o gerente “entrega projetos balanceando requisitos de escopo, prazos, qualidade e custos”. Ele falha, em minha opinião, quando não explicita que tal “balanceamento” deveria ser orientado pelos objetivos do negócio. Na realidade, o grande problema do PMBoK é não fazer refletir em seus processos a devida preocupação com a satisfação das metas e objetivos da organização.

Alinha-se ao PMBoK o Chaos Report, relatório publicado pelo Standish Group desde 1994. Alinha-se? Sim, ao considerar que um projeto *falha* quando atrasa e/ou estoura orçamento e/ou não entrega todo o escopo *planejado*. Ambos os trabalhos ainda apresentam em seu “espírito” uma preocupação exagerada com o plano. Contra desvios são recomendadas “ações corretivas”, o que deixa entender que o plano está sempre correto; Equivocada seria a execução.

Apesar da qualidade aparecer entre itens que precisam ser “balanceados”, tanto PMBoK quanto o Chaos Report nos remetem ao velho “Triângulo de Ferro” do gerenciamento de projetos: Escopo, Prazos e Custo. Esses três itens configuram as principais preocupações de um gerente de projetos. E elas estão explicitamente refletidas nas várias práticas e processos sugeridos não só nos dois trabalhos mas em vários outros que tratam o gerenciamento de projetos.

O primeiro dos 12 princípios do Manifesto Ágil diz que: “Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso”. Valioso no sentido de que o produto entregue realmente representa um meio eficaz para a busca dos objetivos do negócio. Vários métodos, frameworks e práticas derivados do Manifesto Ágil atestam tal preocupação. Mas alguns parecem limitar a percepção de valor à medição do ROI (Retorno sobre o Investimento). É suficiente?

O Novo Triângulo

Jim Highsmith, em “Agile Project Management – Second Edition²“, sugere a adoção de um “novo triângulo”, de algo que de fato represente as principais preocupações de um novo gerente ou líder de projetos. Para ele, as três pontas deste novo triângulo são: Valor, Qualidade e Restrições. Segue uma breve explicação sobre cada uma:

• Valor: representa diretamente a contribuição para a realização dos objetivos do negócio. Quando tratamos de um sistema para uso próprio, avaliamos e valorizamos a eficácia com a qual ele ajudará a empresa na busca pelos seus objetivos.
  Quando a principal saída de um projeto é um produto ou serviço para uso de terceiros, o Valor indica tanto a satisfação destes quanto a realização das estratégias comerciais.
  Aqui é importante destacar que o Valor também representa a Qualidade Extrínseca ou externa do produto ou serviço. Essa qualidade é imediatamente percebida pelo cliente e não é a mesma citada como segunda ponta do triângulo.
• Qualidade: esta é a Qualidade Intrínseca ou interna do produto, e refere-se principalmente à sua confiabilidade e capacidade de adaptação. Por exemplo: um produto pode ser muito bem recebido por um cliente no primeiro momento – seu Valor foi percebido pelo cliente. No entanto, quando mudanças são necessárias mas de difícil e cara implementação, consideramos que a qualidade do produto é baixa, sofrível ou inexistente.
• Restrições: e quem disse que o velho triângulo deveria ir para o lixo? Muito pelo contrário. É aqui, formando a terceira ponta do novo triângulo, que manifestamos nossa preocupação com Escopo, Prazos e Custos. Como reforça Jim, utilizando o mesmo padrão de apresentação dos valores do Manifesto Ágil, a colocação das restrições como apenas uma ponta do novo triângulo não significa dizer que elas não são importantes. Mas é considerável o impacto na crença de que a realização sem desvios do escopo, prazos e custos previstos seriam suficientes para determinar o sucesso de um projeto.
  E esta não é a única mudança. Além do livro de Jim, um outro trabalho a ser publicado em 2010, “Agile Product Management with Scrum³“, sugere um interessante tratamento das restrições. Das três – escopo, prazos e custos – uma é mais relevante para a realização dos objetivos do negócio. Apenas ela deveria ser fixada. As outras duas seriam tratadas com certa flexibilidade. Por exemplo: o prazo, o time-to-market, é considerado crucial para o sucesso de determinado produto. Sendo assim, tanto o escopo quanto os custos poderiam variar. É claro que não se trata de flexibilização total (e insana). Mas o cliente ou patrocinador aceitaria a flutuação dentro de uma faixa pré-estabelecida. Os custos ficariam entre $ 80 e $ 120, por exemplo. Também seria aceitável o possível corte de algumas funcionalidades opcionais (ou secundárias). Tudo para que o prazo, neste exemplo a restrição mais importante para o negócio, fosse atendido plenamente.

.:.

Me parece inevitável uma revisão da definição de fracasso pelo Standish Group. Assim como espero um PMBoK mais orientado para a adaptação do que para ações corretivas (que visam a colocação do trabalho nos “trilhos” de um plano). Como insiste Jim Highsmith em mais de um trecho do livro, “planos (e arquiteturas) devem funcionar como guias e não como camisas-de-força”.

Do outro lado, do Mundo Ágil, espero a compreensão de que o ROI (Retorno sobre o Investimento) não é a única unidade de medida ou preocupação que deve nortear um projeto ou mesmo indicar seu sucesso ou fracasso.

Mas… devo me segurar. Afinal, prometi uma série de artigos com provocações e questionamentos, não com conclusões. Portanto, deixo algumas questões: Como você mede o sucesso de seus projetos? E o fracasso? Você realmente acredita que um projeto cancelado significa um fracasso? Planos não realizados em sua plenitude são fracassos? Essas percepções são compartilhadas por todas as partes interessadas?

O papo seguirá. O próximo artigo será “O Mundo Mudou“. Inté!

.:.

Referências

1. Guide to the Project Management Body of Knowledge – PMBoK® Guide, Fourth Edition.
   PMI – Project Management Institute. 2009.
2. Agile Project Management – Second Edition.
   Jim Highsmith. Addison-Wesley, 2010.
3. Agile Product Management with Scrum
   Roman Pichler. Addison-Wesley, 2010.

A figura utilizada no topo do artigo, flikr2298, é do Flikr e liberada como Creative Commons (by).

Antes de qualquer coisa: por que precisaríamos de um novo gerente de projetos? Algumas respostas: 1) O Mundo Mudou; 2) Os Fracassos são Constantes; e 3) Os Gerentes Vivem Sobrecarregados e Criticados. Se você não acredita nessas motivações ou acha que elas não são suficientes para justificar esse papo todo, então poupe seu tempo. Caso contrário, espero não chateá-lo com a série de 3 ou 4 partes que se inicia aqui. Sim, precisarei de uma série para desfilar alguns ‘achados’. Vamos lá.

Gerentes de Projetos Vivem Sobrecarregados e Criticados

E as causas são conhecidas. Em TI, insistimos em gerentes de projetos (GP’s) que também devem apresentar bons conhecimentos de determinadas tecnologias. Ou seja, muitos esperam que o GP seja também uma espécie de arquiteto. Ou, no mínimo, que ele consiga orientar ou validar o trabalho técnico desenvolvido. Isso sem isentá-lo de todas as tarefas administrativas. Não é a primeira vez que toco neste ponto e não pretendo explorá-lo em maiores detalhes. Me limitarei a citar Fred Brooks (“O Mítico Homem-Mês”, Campus, 2009): “Pensadores são raros. Executores são raros. Pensadores-executores são raríssimos”.

Outra causa do excesso de trabalho é o microgerenciamento. Não importa se a “culpa” é do profissional ou do processo utilizado. Ou mesmo da falta de um. O fato é que, a partir de determinado porte, é simplesmente impossível microgerenciar um projeto. Claro, considerando uma jornada de trabalho de 8 horas por dia.

Mas o efeito mais importante do microgerenciamento é outro: a insatisfação da equipe. Projetos de TI são tocados por “trabalhadores do conhecimento” – profissionais que gostam e precisam de espaço e autonomia para desempenhar bem suas funções. Temos aqui um típico exemplo de relação “perde – perde”.

Aquilo que chamo de “Mundo Ágil”, o conjunto de propostas derivadas do Manifesto Ágil, endereça essas questões de diversas maneiras.  Tem poucos dias, por exemplo, Tobias Mayer escreveu em seu Twitter que: “Projetos ágeis não precisam ser ‘gerenciados’. Eu gostaria que este oxímoro fosse banido de nosso vocabulário”. Sua ‘revolta’ foi motivada por este anúncio, que fala de certificação em gerenciamento de projetos ágeis.  Só para clarear: oxímoro é uma figura de linguagem que coloca dois termos antagônicos, contrários, em uma mesma expressão. Tobias considera então que “gerenciamento” e “projetos ágeis” devem ser como água e óleo. Desconfio que ele quer dizer outra coisa: projetos ágeis não precisam de gerentes.

A implementação mais comum deste conceito de “não-gerenciamento” é o “autogerenciamento”. A equipe se gerencia, sem nenhum tipo de interferência externa. Não há ingerência, já que todos podem falar sobre o trabalho de todos. Na realidade, em dada situação, algum membro da equipe pode assumir a responsabilidade por uma tomada de decisão. Mas o gerenciamento é uma responsabilidade de todos.

Ainda no Mundo Ágil, mas em um pólo bem diferente de Tobias e outros, está Jim Highsmith. Na segunda edição de “Agile Project Management” (Addison-Wesley, 2010) ele quebra o termo “autogerenciamento” para clarear alguns pontos. Ele defende que uma equipe seja auto-organizada. Isso estaria no ‘core’ do APM (Agile Project Management) e a sua viabilização seria uma das principais responsabilidades de um Líder (ele não usa os termos gerente ou coordenador de projetos).

Ainda segundo Jim, existem também os times “autodirigidos”, aqueles que independem de um líder. Em inglês ele usa o termo Leaderless. Para ele, esse tipo de estrutura “vai contra várias pesquisas que mostram que o sucesso em projetos e organizações dependem de bons líderes”. Algumas páginas adiante, mais precisamente na 60, Jim ‘desce o malho’: “Equipes auto-organizadas estão no núcleo do gerenciamento ágil, mas os conceitos estão corrompidos em setores da comunidade ágil. Apesar de ser um bom termo, ele tem sido, infelizmente, confundido com anarquia”. E prossegue: “É fácil combater os gerentes fracos e defender sua eliminação. Muito mais difícil é trabalhar com as organizações para que elas alterem seu estilo de liderança de forma a suportar um ambiente ágil”.

Melhores líderes e um melhor estilo de liderança  não significam, na visão de Jim, que uma equipe não possa se auto-organizar e autogerenciar. Seria tudo uma questão de equilíbrio: “Auto-organização significa que, na medida do possível, a tomada de decisões é delegada para os times”. E explica: “Mesmo que líderes ágeis devam ser ‘light’ em termos de decisões ‘top-down’, eles devem ser ‘heavy’ na articulação de objetivos, facilitação de interações, melhoria da dinâmica da equipe, suporte a colaboração e incentivo da experimentação e inovação”.

Não me parece uma coincidência o fato da lista acima guardar várias semelhanças com aquela apresentada no artigo anterior, que tratava das responsabilidades de um Dono do Produto em um projeto guiado pelo Scrum. Vale lembrar: o Scrum é uma metodologia que, em certo sentido, se propõe Leaderless. As responsabilidades sobre o gerenciamento são compartilhadas pelo ScrumMaster, Dono do Produto e Time.

Acontece que, em vários trabalhos mais recentes (como “Product Management with Scrum”, de Roman Pichler – Addison-Wesley, 2010), a função do Dono do Produto está sendo apresentada de tal maneira que chega a ser estranho o fato dele não ser tratado como um Líder. De uma forma ou de outra, os autores são claros em um ponto: trata-se da função mais crítica e difícil em uma iniciativa guiada pelo Scrum.

Por fim, gostaria de destacar algumas possibilidades apresentadas por Phillip “Shoes” Calçado no papo que tivemos sobre o último artigo: “Cada projeto tem necessidades específicas. Como analogia, em alguns projetos precisamos de alguém 100% do tempo atuando como gerente de projetos e ainda de um gerente de iteração. Em outros projetos apenas o gerente de iteração pode fazer PM e IM. E em outros um desenvolvedor ou BA sênior pode facilmente fazer o seu papel e ainda cuidar de gerência de projetos.”

Queria apenas acrescentar que essa divisão entre gerenciamento de projetos e gerenciamento de iterações é totalmente compatível com o framework proposto por Jim Highsmith no livro citado acima. Aliás, “Agile Project Management – Second Edition” é uma compilação de práticas estruturada em torno de 3 das 4 “camadas” que formam o que Jim chama de “Agile Enterprise Framework”. As quatro “camadas” são: Governança do Portfolio, Gerenciamento de Projetos, Gerenciamento de Iterações e Práticas Técnicas. Apenas essa última camada, formada por práticas de engenharia, não está no escopo do livro.

Como eu disse lá em cima, (ainda) não apresentarei conclusões. Na próxima parte da série falarei sobre “Fracassos”. Inté.

.:.

Observações

A imagem utilizada, flikr0629, é de flikr e foi surrupiada no Flickr. Simples assim.

.:.

Primeiramente quero agradecer ao Paulo pela sua análise do BABOK® 2.0. Aliás, esta leitura crítica feita por ele é consequência de uma conversa nossa há algumas semanas, quando eu lhe mostrei o diagrama com a estrutura do BABOK® 2.0 e praticamente o provoquei a comprar o documento e estudá-lo… Acho essa discussão extremamente construtiva.

Concordo que o BABOK® 2.0 tenha defeitos. A imaturidade do BABOK® 2.0 citada por Joe Gollner em seu artigo “O Curioso Caso da Análise de Negócios” não foi contestada por Kevin Brennan, IIBA VP Body of Knowledge, em sua resposta “O Perfeito é Inimigo do Bom.” Ao invés de defender o BABOK® 2.0, Kevin defendeu a iniciativa do IIBA de documentar as práticas de Análise de Negócios mesmo numa época em que a própria disciplina está em processo de formalização. Ele ressalta que o BABOK® 2.0 não é uma compilação das melhores práticas de Análise de Negócios, mas sim uma compilação de “generally accepted practices”, ou práticas habitualmente utilizadas por Analistas de Negócios. (Vale aqui uma retificação da descrição utilizada por mim em palestras recentes do IIBA-SP. Utilizei o termo “melhores práticas” para descrever o BABOK® 2.0 quando eu deveria ter dito “práticas habitualmente utilizadas.”)

A discussão iniciada por Joe Gollner, rebatida por Kevin Brennan, e resumida por Jonathan Babcock em “IIBA: Timely or Premature?” ressalta o fato de que é preciso ter um ponto de partida, de que é necessário criar um Corpo de Conhecimento para poder depois aperfeiçoá-lo. A iniciativa do IIBA de trazer formalização e reconhecimento à profissão e de documentar suas práticas vem de encontro à necessidade dos profissionais desta área que, até hoje, enfrentam dificuldades para justificar não só seus cargos dentros das empresas mas tamtém o tempo despendido em atividades de Análise de Negócios nos projetos em que atuam.

Defendo a existência do BABOK® 2.0 como guia de referência para Analistas de Negócios que deve descrever as atividades com as quais devemos nos preocupar. O objetivo do BABOK® 2.0 é estabelecer uma visão abrangente, não um manual detalhado de como se executar Análise de Negócios em situações específicas.

Respostas oficiais que obtive até o momento:

Técnicas incluidas no BABOK® 2.0

A escolha das técnicas a serem incluidas no BABOK foi baseada numa pesquisa feita no final de 2008 com membros do IIBA ao redor do mundo. Foram escolhidas as técnicas que muitos Analistas de Negócios utilizam no seu dia a dia. Não são as técnicas mais recomendadas, nem as únicas que um Analista de Negócios deve saber mas sim as que um AN deve estar preparado para executar. Em linha com o restante do BABOK® 2.0, essa lista é um ponto de partida.

Referências ao PMBOK

A omissão de referências ao PMBOK na versão final do BABOK® 2.0 se deve à decisão do IIBA de não fazer referências a fontes específicas exceto em casos absolutamente necessários. Além disso, a data de lançamento da quarta edição do PMBOK não permitiu que o IIBA tivesse tempo de rever as referências mencionadas no DRAFT e atualizá-las para refletir a versão mais recente do PMBOK.

Encerro aqui a minha defesa do BABOK® 2.0 como Presidente do IIBA-SP. Minha opinião pessoal sobre o artigo “BABoK: Uma Leitura Crítica” colocarei como comentário, pois não posso defender cegamente algo que não escrevi. Repito o que disse ao Paulo pessoalmente e também em palestras do IIBA-SP: continua de pé o meu compromisso de levar ao IIBA críticas construtivas que nós brasileiros gerarmos. Acredito que temos muito a contribuir para a compilação das melhores práticas de Análise de Negócios. Levarei as críticas do Paulo Vasconcellos e as minhas próprias dúvidas ao Kevin Brennan e me comprometo a compartilhar as respostas assim que eu as obtiver.

-Suzandeise Thomé
Presidente
IIBA São Paulo

A Estrutura do BABoK

Alguma coisa muito estranha aconteceu entre a liberação da versão para revisão pública, em março/2008, e a versão definitiva publicada agora. A estrutura básica do BABoK foi mantida, com suas 6 disciplinas (KA’s ou Knowledge Areas), mas a ordem de apresentação sofreu consideráveis alterações. Se alguma justificativa para tal foi apresentada, não percebi. O fato é que complicaram a leitura. Em meu entendimento, desnecessariamente.

Na versão 2.0 liberada para revisão as duas primeiras disciplinas apresentadas eram aquelas de perfil mais gerencial e tático: “Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e Comunicação dos Requisitos”. Era uma alteração necessária em relação à versão anterior, a 1.6, que começava pela “Análise da Organização” (ou “Enterprise Analysis”). Necessária por agrupar, mesmo que de maneira implícita, as disciplinas cuja aplicação se diferencia substancialmente das outras quatro. (Mais sobre elas no decorrer do artigo).

A versão atual do BABoK inseriu “Elicitação” entre as duas, comprometendo uma certa lógica de leitura. E a “Análise da Organização”, que um dia foi a primeira disciplina apresentada, agora aparece apenas no quinto capítulo. Uma estrutura que parecia bem resolvida, como ilustra o gráfico abaixo, virou um diagrama de difícil entendimento.

No primeiro diagrama percebemos claramente uma sequência lógica de 4 disciplinas, além da informação de que outras duas guiam e/ou dão suporte à análise de negócios. O segundo desenho quebra essa lógica e não faz nada mais do que confundir. Realmente é incompreensível a mudança.

Além disso, ainda sobre a estrutura do BABoK, é preciso dizer que a forma como as disciplinas são apresentadas é boa. Destacam-se as entradas, tarefas e saídas principais de cada disciplina. Depois, para cada tarefa, são descritos: entradas, elementos (que são específicos para cada tipo de tarefa), técnicas, partes interessadas (stakeholders) e saídas. A sequência é lógica e didática, apesar dos deslizes que serão discutidos abaixo.

Armadilhas

Saca aquele sujeito que, aéreo e desastrado, acaba caindo em armadilhas que ele próprio armou? Essa imagem foi recorrente em diversos momentos durante o estudo do BABoK. Por exemplo: ele surrupia do IEEE, mais precisamente do Standard Glossary of Software Engineering Terminology, a definição de requisitos. Logo depois, ainda no capítulo 1, alerta que “é vital que o termo ‘requisito’ seja compreendido no mais amplo sentido possível”. Ao tentar ilustrar o que seria essa amplitude toda, confundem: “em uma iniciativa BPM, requisitos podem ser uma descrição dos processos de negócio atualmente em uso pela organização”. Além de comprometer a definição do IEEE utilizada na página anterior, criam um tipo de saco sem fundo onde tudo é ou pode ser um requisito. Armadilha armada no primeiro capítulo faz vítimas no decorrer de todo o BoK. Quando apresentando a técnica de “Análise de Regras de Negócios”, por exemplo, é dito que “regras de negócios devem ser separadas de outros requisitos…”. Ou seja, dão a entender que regras de negócios também seriam um tipo de requisito.

Um analista de negócios deve aprender cedo que a distinção entre elementos do negócio (recursos, processos, eventos e regras) e elementos da solução (requisitos) é crucial para o bom desenvolvimento de seu trabalho. Ele sabe que há uma única interseção entre esses dois conjuntos e ela atende pelo nome de Requisitos do Negócio. O BABoK os define corretamente, como “grandes objetivos, metas e necessidades de um negócio”. De tão importantes, mereceram uma disciplina só para eles, a “Análise da Organização”. O que torna ainda mais indecifrável a bagunça apontada no parágrafo anterior.

A segunda armadilha bastante notável no BABoK é a necessidade de manutenção de uma certa “compatibilidade retroativa”. O BABoK tenta colocar e manter os pés em dois mundos muito distantes. Ele os chama de “Plan-driven” e “Change-Driven” – nomenclatura criativa usada para diferenciar o mundo clássico¹ de projetos daquele universo que surgiu após o big-bang do Manifesto Ágil. Se num primeiro momento – no capítulo 2, que trata do “Planejamento e Monitoramento da Análise de Negócios” – ele se mostra muito atencioso com o enfoque “change-driven”, na parte que seria mais cara e necessária tal atenção evaporou. Em “Gerenciamento e Comunicação de Requisitos” (capítulo 4), por exemplo, quase nada é falado sobre a forma como requisitos são gerenciados quando é adotado um processo ágil qualquer (Scrum, XP etc).

O referido capítulo é repleto de  procedimentos para revisão e aprovação de requisitos, baselines, documentos e signoffs. Elementos e tarefas bastante conhecidos no mundo que eu gosto de chamar de clássico. Se mantido o mesmo balanceamento (de preocupações) apresentado no capítulo 2, aqui deveríamos ver no mínimo uma vez a expressão “software rodando”, ou “solução rodando” ou algo do tipo. Não vemos. O que permite dizer que o BABoK firma o pé mesmo é no mundo clássico, a exemplo de seu primo não muito distante, o PMBoK. E por falar nele…

O PMBoK é sumariamente ignorado pelo BABoK. Troco, já que o primeiro também ignora o segundo e ainda se mete a falar sobre elicitação de requisitos? Acho que nunca saberemos. Mas é importante destacar uma terceira perigosa armadilha presente no BABoK. Como vimos, ele possui duas disciplinas, “Planejamento e Monitoramento da Análise de Negócios” e “Gerenciamento e Comunicação dos Requisitos”, de perfil mais gerencial. Ambas invadem o domínio do gerenciamento de projetos sem se preocupar em fixar fronteiras. Criaram pelo menos  duas ‘faixas de Gaza’ e o risco de conflito é alto. Particularmente no que se refere ao gerenciamento e comunicação de requisitos (que inclui a tarefa “Gerenciar Requisitos e o Escopo da Solução”). Viu a palavrinha mágica ali? Escopo!

Por essa e muitas outras eu vivo defendendo que “Escopo” não é do analista de negócios e muito menos do gerente de projetos. Deveria ser só do arquiteto e ponto. Mas isso é tema para outra hora. Aliás, atenção piratas! Vou lançar o FAS – Formação de Arquitetos de Soluções. Preparem suas copiadoras! hehe..

Enfim, a quarta e mais comprometedora armadilha. Minha primeira e repetitiva crítica ao BABoK é o fato dele ignorar por completo a disciplina conhecida como Modelagem de Negócios. O problema se torna mais perceptível na versão 2.0. Porque de fato ele não ignora a necessidade da modelagem. Sugestões para o uso de técnicas de modelagem aparecem a todo momento, em diversas disciplinas. Mas elas surgem de forma tão solta e desestruturada que é difícil imaginar que sejam utilizadas em sua plenitude. Pior: é difícil imaginar que gerem algum valor. Aos fatos.

Ainda na primeira disciplina, “Planejamento e Monitoramento da Análise de Negócios”², são apresentadas como técnicas gerais a “Modelagem da Organização” e a “Modelagem de Processos”. Em “Análise da Organização”, o 5º capítulo, são elencadas as técnicas “Benchmarking”, “Análise de Regras de Negócios”, “Decomposição Funcional” e “Análise SWOT”. No sexto capítulo, “Análise de Requisitos”, o assombro: além de diversas das técnicas acima, sugerem inclusive o uso de “Diagramas de Fluxo de Dados” na tarefa que deveria ser apenas “Organizar Requisitos”. Dentre os elementos desta tarefa aparece uma breve explanação sobre cada um dos 5 conceitos que, segundo o BoK, “garantem a total cobertura do domínio do negócio”. Aliás, os 5 conceitos são: 1) Classes de Usuário, Perfis e Papéis; 2) Conceitos e Relacionamentos; 3) Eventos; 4) Processos; e 5) Regras.

Nada mais é necessário para confirmar que a Modelagem de Negócios é fundamental para o entendimento de um negócio. Colocando de outra maneira: é fundamental para a Análise de Negócios. O BABoK sabe disso. Acontece que, ao invés de tratá-a como uma disciplina – como um corpo – preferiu esquartejá-la e distribuí-la em pedacinhos em diversas de suas KA’s. É grave quando percebemos que a Análise de Requisitos, uma disciplina por si só complexa e crítica, vira uma espécie de monstro de Frankestein no BABoK.

Essa armadilha se torna mais visível quando percebemos que em outros pontos do BoK é apresentada como entrada para determinadas tarefas uma tal “Arquitetura Corporativa” (um documento que, segundo o BABoK, “descreve o estado atual da empresa, incluindo sua estrutura organizacional, processos de negócio, sistemas, informação etc”). Esse input já existiria de alguma maneira na organização. Duas coisinhas: 1) Essa “Arquitetura Corporativa” é igual cabeça de bacalhau – todo mundo sabe que existe ou deveria existir mas ninguém nunca viu; 2) Mas, se de fato ela existir, quem a desenvolveu? Não é factível supor que seu desenvolvimento e manutenção, mesmo que parcial,  sejam atribuições dos analistas de negócios? Tem hora que o BABoK finge que não é com ele. Em outros momentos (na Análise de Requisitos!?!), sugere que o analista desenvolva vários artefatos que ajudariam a compor uma “Arquitetura Corporativa”. Vai entender…

Conclusão

No final das contas o grande problema com o BABoK é esse: entendê-lo. Se por um lado sua estrutura geral é desenhada com esse fim, e é bem desenhada, por outro o conteúdo ainda apresenta inconsistências demais. Pouco adianta o reuso de conhecimentos bem consolidados, como definições do IEEE e diagramas UML, se eles são contraditos ou diluídos de tal forma que perdem seu sabor e valor.

Joe Gollner publicou em julho último um artigo chamado “O Curioso Caso da Análise de Negócios“. Brinca com o título do filme estrelado por Brad Pitt, “O Curioso Caso de Benjamin Button”. Joe erra feio ao dizer que não estaríamos prontos para definir um corpo de conhecimentos para a análise de negócios. Tenho certeza de que já temos conhecimento e maturidade suficientes para delinear um BoK. Mas ele acerta na analogia: o BABoK, assim como Benjamin Button, nasceu velho.

A necessidade de manutenção de uma “compatibilidade retroativa” é, sem sombra de dúvidas, a grande culpada. Como justificar, em 2009, o uso de técnicas como a elaboração de DFD’s e diagramas de contexto? Como viabilizar uma proposta que fala em documentar, documentar e documentar? Assim o BABoK só faz confirmar uma fama dos AN’s: seriam consumidores vorazes de papel. Não digo com isso que ele deveria se ater aos princípios pregados no Manifesto Ágil. Afinal, a análise de negócios não se limita a projetos de software. Mas é imperdoável que um BoK para análise de negócios se lembre de DFD’s e ignore por completo balanced scorecards, mapas estratégicos, conceitos Lean etc etc etc.

Então um analista de negócios deveria ignorar o BABoK? De jeito nenhum. Se almeja a obtenção da certificação CBAP (Certified Business Analysis Professional), fornecida pelo IIBA, ele deve decorar o BABoK. Além de ter boa experiência prática. Mas o analista deve ter consciência de todas as armadilhas e inconsistências que o BABoK apresenta em sua versão atual. Para não correr o risco de comprometer seu trabalho e até sua carreira.

.:.

Nota aberta ao IIBA

A lei de imprensa morreu, o finito não é imprensa, mas ética e educação não precisam ser regidas por leis. Caso o instituto julgue necessária uma resposta ao artigo acima, eu garanto o mesmo espaço e mesmo destaque. E reafirmo: não tenho interesse nenhum em criticá-los por criticar. Muito pelo contrário. Tenho certeza de que todos ganhamos com um instituto forte e, principalmente, com um BABoK forte e consistente. Todos sabemos que um debate franco e aberto é o melhor caminho para a realização desses objetivos.

.:.

Serviço:

• O BABoK pode ser obtido diretamente no site do IIBA, em http://www.theiiba.org/AM/Template.cfm?Section=Body_of_Knowledge

Outras Notas:

1. Entenda como “Mundo Clássico de Projetos” aquele que brotou e cresceu no século passado. Aquele que se baseia em modelos de ciclo de vida popularmente conhecidos como cascata ou waterfall e que sustenta seus métodos e práticas em diferentes níveis de comando e controle. Não há nada de pejorativo nessa definição. E não há nada de errado com esse modelo, desde que ele não seja utilizado em projetos de software.
2. O IIBA bem que podia surrupiar uma ideiazinha meio besta do CMMI. O nome de algumas de  suas disciplinas e tarefas é muito longo. Que tal usar siglas, a exemplo do que ocorre no framework do SEI?

Foto de Tom@HK.

Eu poderia citar n exemplos, como a mal explicada briga da MS com o padrão UML; as metodologias que adoram dar novos nomes e símbolos para coisas que já existem; “oceanos azuis” e outras metáforas criativas para diferenciação; sistemas de help-desk que viram, da noite para o dia, soluções de CRM… Pois é, não é só uma questão de reinvenção. As segundas intenções (as verdadeiras motivações para a “reinvenção”) são ainda mais perigosas.

Mas a motivação para este post veio de outro lugar. Do BABoK (Business Analysis Body of Knowledge), que é uma das minhas referências para o livro e o workshop/curso para formação de Analistas de Negócios.

O BABoK é novo. A versão que estou utilizando é apresentada como um “draft 1.6”, de julho do ano passado. Como eu disse em outro post, o BABoK se concentra quase que exclusivamente na Engenharia de Requisitos. Mas trata a disciplina como se fosse algo totalmente novo. Parece que o tema não foi estudado anteriormente e compilado em propostas como o CMMI, SWEBoK etc etc. O padrão da SEI, por exemplo, só aparece como “CMM” em algumas poucas referências. No corpo do “corpo” ele é sumariamente ignorado.

Caramba, o CMMI tem duas áreas-chave que tratam especificamente de requisitos: REQM (Gerenciamento de Requisitos) e RD (Desenvolvimento de Requisitos). A vinculação do BABoK com ele deveria aparecer, no mínimo, como uma matriz que mostrasse como as práticas ali recomendadas auxiliam na realização dos objetivos do CMMI.

Mas os “agilistas” não têm motivo para comemorar. Suas práticas e métodos também não existem no BABoK. Aparecem pequenas referências e alertas, dizendo, por exemplo, que “em projetos ágeis e iterativos os requisitos não são baselined (sorry) ao mesmo tempo”. Não há quase nada além disso.

Acho que nem preciso dizer que “gestão do conhecimento” e “aprendizagem organizacional” também não foram consideradas na elaboração do BABoK. Pois é, infelizmente, a versão atual é só uma compilação de práticas ‘levemente acopladas’. Apresentadas de forma linear, estruturadas de acordo com este diagrama. Como as práticas são relativamente bem documentas (propósito, descrição, técnicas, processo, stakeholders e deliverables – toda prática ou tarefa é apresentada com esta estrutura), o BABoK deve se tornar apenas um tipo de “guia de referência rápida”. Um excelente template para elaboração de provas de múltipla escolha. E talvez, numa versão 3.0, apresente uma disciplina nova chamada “integração” ou algo do tipo.

Talvez fosse só esse mesmo o seu objetivo. Mas acho que todo mundo espera mais de algo que se apresenta como um “Corpo de Conhecimentos da Análise de Negócios”. A primeira coisa que eu sempre espero é que ele não ignore os conhecimentos existentes. Rodas reinventadas giram em falso.

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.

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

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.