PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Gestão do Conhecimento

  • +Aprendizado sobre Requisitos

    +Aprendizado sobre Requisitos

    Foi sincera a questão que encerrou o capítulo anterior: o que viria a seguir? Por natural que pareça o tema que será desenvolvido nesta parte – aprendizado – não é comum vê-lo em trabalhos sobre requisitos. A exagerada compartimentalização de disciplinas que inventamos no século passado e, infelizmente, seguimos alimentando, deixa entender que conhecimento e aprendizagem organizacional ficam em um lado, requisitos ou engenharia de requisitos noutro. Divisão falsa e danosa. O aprendizado e desenvolvimento de requisitos é um tipo de aprendizagem organizacional. Em minha opinião, o mais importante deles. Porque é em projetos que geramos e disseminamos o maior número de novos conhecimentos.

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

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

     

     

  • +Conhecimento sobre Requisitos

    +Conhecimento sobre Requisitos

    No capítulo anterior vimos conceitos básicos sobre dois elementos fundamentais para o trabalho com requisitos: Informação e Comunicação. O tema de hoje é Conhecimento – o que devemos aprender e desenvolver sobre cada requisito de um projeto. O papo será mais prático, podes crer.

    Como a conversa no artigo anterior ficou bem “matemática”, segue mais uma fórmula:

    Requisito = (Informação * Confirmação) – Ruído

    Vimos na introdução desta série que a informação representada por um requisito é uma “condição necessária para alcançar certo fim”. Depois, vimos que este “certo fim”, em nosso contexto, é um conjunto de objetivos do negócio. Objetivos que podem ser detalhados e organizados na forma de requisitos do negócio. É suficiente, para o desenvolvimento e condução de um projeto, que se conheça apenas essas informações (condições e fins) devidamente confirmadas e livres de ruídos? Sim, desde que interpretemos a variável “informação” da fórmula acima de uma maneira bem ampla.

    Se você não aprender corretamente os requisitos, não fará a menor diferença o quão bem trabalhe no restante do projeto. -Karl WiegersÉ relativamente comum que se conheça muito pouco sobre um requisito. Assim como são irritantemente corriqueiras as longas e amorfas transcrições textuais transmitidas e recebidas como sendo os “requisitos” de um projeto. É difícil encontrar bons requisitos nesses catataus.

    Assim como será praticamente impossível encontrar um cliente ou usuário que, durante a exposição de seus objetivos e condições, aja mais ou menos assim: “Vou relacionar os requisitos funcionais, anota aí. Prepare-se para os não funcionais. Agora, às restrições. Por fim, falemos sobre regras de negócio”. Este usuário não existe. E não precisa existir!

    Cabe ao analista os processos de estruturação e enriquecimento dos requisitos. Aliás, se ele fizer só isso por um projeto já terá justificado seu salário. Se você acha que isso é muito pouco, por favor, continue lendo.

    Estruturar significa organizar – separar os mais diversos tipos de requisitos e demais informações. Porque cada um deles merecerá um destino diferente. Porque cada um pede tratamento e ferramental específicos. Veremos isso nos capítulos sobre Funções, Atributos, Preferências e Restrições.

    Enriquecer significa obter mais informações e confirmações (feedback) sobre cada requisito. O diagrama ao lado ilustra sete atributos que todo e qualquer requisito (de todo e qualquer projeto) deveria merecer.

    Tipo

    Aqui simplesmente colocamos cada requisito em sua devida caixinha. Na classificação mais básica possível teríamos: Requisitos do Negócio, Funções, Atributos e Restrições. Quem quiser ser mais específico pode diferenciar requisitos de usabilidade, de dados, telas, relatórios, integração, transição, segurança etc. No modelo proposto por Suzanne e James Robertson¹ existem apenas: Restrições, Requisitos Funcionais, Não Funcionais e de Tecnologia. Com certeza há uma separação e nomenclatura mais adequadas para sua organização ou projeto. Esta série utilizará a primeira lista acima em todos os exemplos.

    Fonte

    O nome de quem manifestou aquele requisito pela primeira vez. A tabelinha² Fonte pode, obviamente, ser completada por outras informações como cargo, departamento etc. Em alguns casos não é possível identificar uma pessoa. Quando tudo o que um analista tem em mãos é um edital, por exemplo. Nessas situações (terríveis) registramos apenas o documento e, eventualmente, capítulos e páginas.

    Só não recomendo que se registrem aqui informações sobre o impacto que o projeto terá sobre a pessoa e sua influência. Porque são informações do tipo caixa preta que deveriam ser persistidas em um local menos público.

    Perspectiva

    É o ponto de vista defendido pela fonte. Sugiro uma distinção bem simples:

    • Estratégica: a pessoa está no topo da pirâmide organizacional, é proprietária ou da alta direção.
    • Tática: gerentes, coordenadores ou supervisores. A pessoa está no escalão intermediário.
    • Operacional: na base da pirâmide, onde ficam todos que de fato colocam a mão na massa (ou  no martelo).

    Além dessas, podemos ter perspectivas que não participam diretamente do negócio. Legal, por exemplo, para representar o corpo jurídico da empresa; Técnico para diferenciar todos os requisitos que vieram de TI e assim por diante. Em cada organização ou projeto podem existir pontos de vista diferentes que merecem destaque.

    Repare no diagrama acima que, apesar de qualificar a Fonte, a Perspectiva é um atributo do Requisito. É o primeiro mecanismo do modelo que visa a resguardar a história do projeto. Quando uma pessoa for promovida, mudando assim sua perspectiva, não levará consigo seus antigos requisitos. Fica registrado que, quando aquela pessoa manifestou determinado requisito ainda defendia o ponto de vista “operacional”, por exemplo.

    Valor

    Todo requisito tem um valor (benefício) e um custo. Representamos aqui qual é a contribuição de determinado requisito para a realização dos objetivos do negócio. Podemos utilizar uma escala bem simples, como:

    • Fundamental: a não realização deste requisito resultará em fracasso do projeto. Sua satisfação é incondicional.
    • Importante: este requisito não dá uma contribuição direta para a realização dos objetivos do negócio. É uma função ou característica que pode ser entregue em outro momento. Ainda assim, por algum motivo, ela é importante para o cliente ou usuário.
    • Opcional: requisito que não representa nenhuma contribuição direta ou indireta para a realização dos objetivos do negócio. Deve ser percebido apenas como algo que agradaria o cliente ou usuário caso haja tempo e dinheiro para sua realização.

    Quem precisar de uma escala maior pode utilizar, por exemplo, a sequência de Fibonacci. Costumo recomendar um pequeno subconjunto: 1, 2, 3, 5, 8, 13. Em situações que envolvam quatro ou mais interessados (proponentes de requisitos), sugiro também o uso do Planning Poker para a valorização das necessidades e restrições apresentadas. Geralmente esta ferramenta é utilizada apenas para estimativas de esforço, o que é um desperdício. Quando utilizamos unidades relativas, é importante que valor (benefício) e estimativas (custo) sejam medidos com a mesma régua. Tanto melhor se utilizarmos o mesmo método. No capítulo sobre estimativas e planejamento isso será melhor explicado.

    Este assunto merece livros inteiros. Porque está aqui boa parte dos problemas que presenciamos em projetos. Quanta grana se desperdiça com funções que raramente ou nunca são utilizadas; Quanto tempo é perdido em requisitos que representam nada ou muito pouco para a solução do verdadeiro problema; Enfim, como faz falta uma visão compartilhada sobre aquilo que realmente interessa em um projeto.

    Em praticamente tudo o que compramos ou construímos há prioridades e alternativas. Na lista do supermercado, no carro ou na casa nova pensamos em itens fundamentais, importantes e supérfluos ou opcionais. É curioso como no mercado de software sobrevive, por muito tempo, um jogo de tudo ou nada. Curioso porque software é infinitamente mais maleável que casas, carros e listas de supermercado.

    O que deve ficar, neste ponto, é a consciência de que esta pergunta – “Ilmo. Sr. Usuário, quanto vale esta solicitação?” –  deve ser feita. Imediatamente após a apresentação do requisito. O cliente ou usuário pode se enganar ou, em raros casos, tentar ludibriar o analista. Momento este que aciona o lado crítico do analista: “Me explique, caríssimo Usuário, como a função X (ou o atributo Y) ajudará a ACME a aumentar em 30% o faturamento”. Sim, os objetivos e requisitos do negócio devem balizar todos os demais requisitos. Não há outra maneira de analisar e de fato criticar e priorizar requisitos. Não há!

    Relações com os Outros Requisitos

    Se através do Valor rastreamos cada requisito na vertical (entendendo sua contribuição para a realização dos objetivos do negócio), está naquele pequeno círculo incompleto a rastreabilidade horizontal. Ou seja, o tipo de relacionamento que determinado requisito tem com todos os demais. Quando existe, a relação pode ser de:

    • Dependência: a realização do requisito B depende da realização do requisito A. É através deste mecanismo que agrupamos requisitos, formando um módulo ou uma funcionalidade completa, por exemplo.
    • Complementaridade: a realização do requisito A facilita a realização do requisito B ou simplesmente o completa. Aqui também sinalizamos um agrupamento, desta vez com elementos levemente acoplados.
    • Redundância: requisitos A e B, apesar de uma possível redação diferente, representam a mesma condição – necessidade ou restrição. Portanto, um deles deve ser excluído* do escopo do projeto.
    • Conflito: o requisito A impede a realização do requisito B. Este conflito normalmente se dá entre funções e atributos ou, principalmente, entre funções e restrições. E, infelizmente, boa parte deles só pode ser identificada na bancada de testes. Ainda assim, é recomendável que o analista fique atento aos conflitos em potencial. E registre-os.
    • Substituição: o requisito B substitui o requisito A. Está aqui o mais importante mecanismo de proteção da história do projeto de todo o modelo proposto. Uma vez registrado, nunca mais o requisito deveria ser editado ou apagado. Se determinado requisito precisa ser alterado por algum motivo qualquer, deveríamos registrar um novo requisito e indicar que ele substitui um ou mais existentes. Anotando cuidadosamente o motivo da alteração. No meio de tanto bafafá sobre gerenciamento de mudanças, normalmente perdemos o essencial: uma mudança é, antes de tudo, um requisito. Por isso, deveria ser tratada da mesmíssima maneira (no mínimo).
      * Portanto, o excluído daquela frase deve ser interpretado como uma desativação do requisito mas não sua exclusão física. Porque pode ser bom lembrar e medir, por exemplo, quanta redundância se originou do trabalho de diversos analistas entrevistando diversas pessoas.

    Há outro tipo de rastreabilidade, igualmente necessária mas não contemplada nesta sugestão. Ela trata do relacionamento entre requisitos e elementos da solução. Quem sabe usar (direitinho) a UML não precisa se preocupar com isso. Os demais ficarão com uma bela pulga atrás da orelha.

    É bastante provável que neste momento lhe tenha caído uma ficha: “Caramba! Quanto trabalho!” Entendeu agora porque um analista de negócios ganha tão bem? Brincadeirinha… A mensagem é outra.

    O diabo está nos detalhes. Em projetos, cada requisito é um conjunto de detalhes. O dito cujo se lambuza.É impossível – repito, é impossível realizar este trabalho de análise em um lote muito grande de requisitos. O bom profissional deve saber que boa parte do trabalho de análise de requisitos ocorre em paralelo à elicitação (sic 100x!), ou seja, no momento em que um requisito aparece ele já começa a ser analisado (estruturado, enriquecido, relacionado… você entendeu). A outra boa parte do trabalho de análise de requisitos ocorre imediatamente após um evento de coleta (sic 1000x!)³. Enquanto as informações ali aprendidas ainda estão frescas na memória dos participantes e, principalmente, dos analistas.

    Outra mensagem: se o analista envolvido com requisitos não faz este trabalho ele não está fazendo seu trabalho. Ponto!
    Não há análise, seja de requisitos ou de negócios, feita no atacado, por cima, nas coxas…

    Testes

    E por falar nas coxas… Hora de conversar um pouco sobre testes. Lembra-se da fórmula que abriu este capítulo?

    Requisito = (Informação * Confirmação) – Ruído

    Os testes são os grandes responsáveis por gerar confirmação e também por subtrair ruídos dos requisitos. Não por acaso, é o único atributo do modelo sugerido que mantém relação de muitos para muitos com os requisitos. Este tema também merecerá um capítulo só seu. Por enquanto, é importante o entendimento de que os testes ocorrem em diversos momentos e com propósitos distintos. No início, durante uma entrevista, por exemplo, testamos um requisito no sentido de confirmar i) Nosso entendimento; e ii) Sua (do requisito) real necessidade. Nos momentos seguintes, de forma isolada ou em conjunto, os requisitos são submetidos a baterias de testes que visam a i) Confirmar nosso entendimento; e ii) Confirmar a sua (do requisito) realização.

    Teste é sinônimo de confirmação, feedback, refinamento e aprendizado. Não deveria estar relacionado com coxas.

    Estado

    Enfim, o último atributo básico que todo requisito deveria merecer. Aqui simplesmente posicionamos o requisito em um momento de seu ciclo de vida. Podemos utilizar a mesma nomenclatura das divisões de um quadro kanban, por exemplo: Em Espera; Em Execução; Em Testes; Entregue. Claro, sua organização ou projeto pode requerer uma visão diferente, mais detalhada. O importante é que se saiba, a qualquer momento, qual o estado de cada requisito.

    A Tabela Central

    A tabela² Requisitos possui, além das diversas chaves estrangeiras (ligações com outras tabelas), alguns campos próprios. Mantendo o padrão, relaciono abaixo o que considero o mínimo necessário:

    • Número: sequencial, por ordem de entrada. Serve apenas para identificação e não tem relação nenhuma com a Ordem (posição do requisito no escopo do projeto ou backlog do produto).
    • Descrição: breve texto que exprime aquela necessidade ou restrição. Existem regrinhas de padronização para cada tipo de requisito. Veremos isso no momento oportuno.
    • Justificativa: explicação (opcional) para o requisito. É um campo texto, livre.
    • Material Complementar: Lista (opcional) de links e referências para fontes que completem o entendimento do requisito.
    • Versão: Número da versão do requisito. Cada substituição inserida (veja Relações entre Requisitos acima) se reflete aqui.
    • Analista: Nome (ou código) do analista que efetuou o registro do requisito.
    • Timestamp: (Agora exagerei. Perdão).

    Revendo Tudo

    • Informação é diferença que faz a diferença. (Gregory Bateson)
    • Informação é dado investido de relevância e propósito. (Peter Drucker)
    • A conversão de dados em informação requer conhecimento. (idem)
    • Informação é a principal matéria prima de projetos.
    • Comunicação = Informação * Relacionamentos * Confirmação (Jurgen Appelo)
    • Comunicação (em Projetos) = Requisitos * Relacionamentos
    • Requisito é informação devidamente confirmada e livre de ruídos.
      Requisito = (Informação * Confirmação) – Ruído
    • Requisito, enquanto informação estruturada e enriquecida, é conhecimento produzido por conhecimento.
    • Conhecimento é a capacidade de agir. (Karl-Erik Sveiby)

    Depois deste tour de force, quem sabe o que virá a seguir?

     

    Notas

    1. Em Requirements-Led Project Management (Addison-Wesley, 2005). É do casal Suzanne e James Robertson o modelo Volere, um “modelo de conhecimentos de requisitos” mais completo (e mais complicado) do que o que é sugerido nesta série. Não gosto da forma como o modelo do negócio é (mal) tratado no Volere.
    2. A sugestão aqui apresentada foi concebida, há mais de dez anos, como um modelo E-R (entidade-relacionamento). Quando ela deixou o laboratório e ganhou as ruas, através do treinamento {FAN}, manteve o desenho original. Para surpresa deste que aqui rabisca, o formato se provou bastante didático. No entanto, peço desculpas se a terminologia técnica ou as bobas explicações sobre ela causaram chateação, desconforto ou dúvidas. Neste caso, sou todo ouvidos.
    3. O termo elicitação não existe em língua portuguesa. E sua criação, convenhamos, é totalmente desnecessária. Não porque utilizamos coleta em seu lugar. Mil vezes não! Coletamos lixo ou material para exames clínicos. Não coletamos requisitos.
      Essa terminologia, particularmente a separação entre elicitação e análise de requisitos, é herança maldita das cascatas e cascateiros. No longínquo 1989, Donald Gause e Gerald Weinberg já nos mostravam a correção do termo Explorar requisitos (Exploring Requirements – Quality Before Design. Dorset House). São equivalentes os termos aprender e desenvolver, os meus preferidos.
      Não tem muito tempo que deixamos de chamar requisitos de requerimentos. Passa da hora de abandonarmos palavras que, além de feias, não refletem o real significado do trabalho com requisitos.

     

  • Repensando a Análise de Negócios

    Repensando a Análise de Negócios

    eria muita incoerência de minha parte se, após a palestra que apresentei no BA Brazil, seguisse tocando minha vidinha da mesma maneira. Aquelas provocações motivaram o maior redesenho que o Programa {FAN} já recebeu. O que, por sua vez, pediu por um rejuvenescimento deste {finito}. Não vou roubar seu tempo repetindo o que o programa já diz. Minha intenção neste artigo é outra. Que tal ver a Análise de Negócios de uma forma um pouco mais ampla?

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

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

     

    Definições Destroem

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

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

     

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

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

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

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

     

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

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

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

     

    Para Pensar e Repensar

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

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

     

    Notas

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

     

  • Scrum ‘de Raiz’

    Scrum ‘de Raiz’

    Assim como existem o samba e a música sertaneja ‘de raiz’, também existe um Scrum ‘de raiz’: ideias, princípios e práticas que antecederam e deram forma e jeito ao framework como é conhecido hoje. Ajornada antropológica proposta por este artigo tem como principais objetivos: i) Revisitar os pilares do Scrum; e ii) Descobrir se estamos esquecendo alguma coisa importante em nossos trabalhos com ele. Posso adiantar: estamos!

    ?

    O Scrum foi provocado pelo artigo “The New New Product Development Game” publicado na edição de Jan-Fev/1986 da Harvard Business Review (HBR). Escrito por Hirotaka Takeuchi e Ikujiro Nonaka, o artigo descreve o sucesso de empresas como Fuji-Xerox, Honda e Canon no desenvolvimento de novos produtos. Os autores descobriram que as empresas analisadas compartilhavam seis características fundamentais:

    1. Instabilidade intencional: os times de projetos recebem apenas uma diretriz geral, normalmente uma metáfora indicando o tipo de produto que a organização espera receber. Não existem especificações detalhadas ou plano de projeto. Tensão, pressão, ambiguidade e outros efeitos colaterais da prática são compensadas por tolerância aos erros e pela autonomia concedida ao time.
    2. Times auto-organizados: a autonomia, citada acima, é uma das três condições para a criação de um time auto-organizado. Auto-transcendência (equipe parece buscar algo além de seu limite normal) e fertilização cruzada (time é multifuncional e todos aprendem com todos) são as outras duas.
    3. Fases sobrepostas de desenvolvimento: como em um jogo de rúgbi, onde todos correm juntos e passam a bola lateralmente. A metáfora oposta é a corrida de revezamento (desenvolvimento sequencial ou linear), com um participante aguardando a passagem do bastão por outro.
    4. “Multi-aprendizado”: ocorre o aprendizado multiníveis (indivíduo, time e empresa aprendem) e o aprendizado multifuncional (fruto da fertilização cruzada, citada acima. Um especialista é provocado a aprender coisas de outras áreas).
    5. Controle sutil: a autonomia de um time não significa falta de controle, apenas um tipo diferente de gerenciamento.
    6. Transferência do aprendizado: o item 4 acima trata do aprendizado que ocorre entre as partes interessadas de um projeto específico. Aqui se trata do aprendizado interprojetos e também da transferência da e para a organização.

    A derivação da lista acima que hoje conhecemos como Scrum, criada por Jeff Sutherland e Ken Schwaber, parece dar ênfase aos itens 2~5 em detrimento do primeiro e último tópicos. Jim Highsmith, mesmo sem dar nome ao boi, sugere algumas correções (ou avanços) no já comentado “Agile Project Management“. Craig Larman e Bas Vodde, em “Scaling Lean & Agile Development” (Addison-Wesley, 2009) tentam o mesmo. Apesar de valiosas, essas colaborações não são suficientes.

    Enquanto o Scrum era gestado, Takeuchi e Nonaka prosseguiram com suas pesquisas no campo da Gestão do Conhecimento¹. Do segundo a mesma HBR publicou, na edição Nov-Dez/1991, “The Knowledge-Creating Company“. Em 1995 a dupla voltou com outro artigo seminal, “The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation“. Por mais que a estagnação da economia japonesa – que já dura duas décadas – tente provar o contrário, esses artigos não poderiam ter sido ignorados como aparentemente foram (pelos “criadores” do Scrum e demais envolvidos com métodos ágeis). Porque eles recolocam e evoluem os temas tratados no trabalho original de 1986.

    A crítica sem rodeios nem meias palavras ao jeito ocidental – cartesiano e taylorista – de ver as organizações talvez explique o fato desses artigos terem passado em branco. Mas é exatamente nesta crítica que está seu grande valor. O tal ‘jeito ocidental’ vê as empresas como “mecanismos para processamento de informações”. Nonaka explica:

    “De acordo com essa visão, o único conhecimento verdadeiramente útil é o formal e sistemático – dados difíceis² (leia-se quantificáveis), procedimentos codificados, princípios universais. E as métricas-chave para mensurar o valor do novo conhecimento são similarmente difíceis e quantificáveis – crescente eficiência, custos mais baixos, melhor retorno do investimento (ROI).”

    Por outro lado, no modo oriental (ou japonês):

    1. Há reconhecimento e valorização do conhecimento tático;
    2. A questão não se limita a “gerenciar conhecimentos” mas, principalmente CRIAR conhecimentos;
    3. Entende que todos os colaboradores, e não apenas os gerentes e diretores, são potenciais criadores de novos conhecimentos; e
    4. Recursos e atividades são organizados e desenhados de forma a facilitar a criação e transferência de conhecimentos.

    Voltemos a um ponto chave que deixei um tanto solto acima: a área de especialização de Takeuchi e Nonaka é a Gestão (ou Criação) de Conhecimentos. Eles entendem que cada projeto é uma oportunidade única para criação de conhecimentos (leia-se Inovação). Por isso depositam boa parte de suas sugestões nas trocas e transformações de conhecimentos. O Scrum, até certo ponto, reflete bem a mesma preocupação. Através de suas reuniões diárias, de revisão (de iterações ou sprints) e retrospectivas. Mas ele peca ao desconsiderar ou dar pouca importância ao que existe fora do time de projeto.

    Takeuchi e Nonaka descobriram um tipo de organização que chamaram “hipertexto”. Convivência, confronto e troca entre a estrutura hierárquica (sistemas de negócios) e times de projetos (forças-tarefa) dão forma a uma “hiper-rede”. Uma rede que não se desliga nunca! Por que isso é importante e muito diferente do que vemos no Scrum?

    O Scrum instituiu um e apenas um ponto de contato (ou interface) entre negócio (estrutura hierárquica) e time de projeto: o Dono do Produto. Se por um lado esse “mecanismo” simplificou o processo de comunicação, por outro ele destruiu a permeabilidade e transparência que existem na proposta original da dupla japonesa. Repare no diagrama ao lado. Times de projetos e o negócio se comunicam constantemente. E essa comunicação não se dá através de um “ponto focal”. Acontece que os times são de fato multidisciplinares, compostos por pessoas de todas as áreas de negócio envolvidas. Takeuchi e Nonaka chegam a falar de times com 20~30 pessoas e um “núcleo duro” de 5 integrantes. Essas 15~25 pessoas “extras” são gente do negócio atuando na força tarefa. Gente que “leva e traz”, no bom sentido, o conhecimento necessário.

    Por favor, não estou sugerindo que a figura do Dono do Produto é desnecessária e muito menos que ela seja redondamente equivocada. Mas precisamos aceitar que ela é um “ponto único de falha” nesse sistema chamado Scrum. Suas vantagens (particularmente a esperada agilidade na tomada de decisões) não a livra de um risco potencial: a falta de conhecimento.

    Existem ainda outros dois fatores que diferenciam essa proposta do Scrum. Os times, apesar de levemente acoplados, mantêm comunicação constante. Sei que isso começou a ser tratado quando pipocaram questionamentos sobre a escalabilidade do Scrum. Aquele papo sobre “Scrum de Scrums” e coisa e tal. O fato é que esse patch não seria necessário se o desenho original³ fosse preservado. O segundo fator é a “Base de Conhecimentos”: aqui temos todo o conhecimento explícito acumulado a cada projeto. A ênfase no conhecimento tácito (e na comunicação direta entre times de projetos e o negócio) não significa o desmerecimento de tudo o que pode e deve ser explicitado (e documentado).

    Resumindo, eu vejo dois grandes problemas no Scrum que não existiriam caso seguíssemos acompanhando os trabalhos de Takeuchi e Nonaka:

    1. O “sistema” original é completo. Ele entende que quem cria conhecimentos são os indivíduos mas quem os amplifica é a organização. Times de projetos são sintetizadores desse conhecimento. O Scrum não pode ignorar ou tratar de forma simplista essas trocas;
    2. A ênfase em dados “duros” e conhecimento explícito (e mensurável) é a prorrogação de uma mentalidade herdada do século XX, de Taylor, Ford e afins. Um pensamento que desemboca em um absurdo que vi na forma de um cartaz no último Agile Vale realizado em São José dos Campos: “Se o miojo fosse ágil ficaria pronto em um minuto e meio”. O Scrum, lá na sua raiz, nunca prometeu a agilidade pela agilidade. Nunca foi uma questão de fazer de maneira ultra-rápida o mesmo trabalho. A busca cega por eficiência está nos desviando de forma muito preocupante do que é fundamental: fazer a coisa certa!

    ?

    Observações:

    1. Os dois artigos citados, de 1991 e 95, podem ser encontrados em “Gestão do Conhecimento“, de Hirotaka Takeuchi e Ikujiro Nonaka (Bookman, 2008). Aproveito a deixa para recomendar outro livro, mais completo, que apresenta a versão original (em inglês) do segundo artigo: “Knowledge Management: Classic and Contemporary Works“, editado por Daryl Morey, Mark Maybury e Bhavani Thuraisingham (The MIT Press, 2000).
    2. Ana Thorell, tradutora do primeiro livro acima, optou por “difícil” ao traduzir “hard”. Mantive a tradução original mas, logo abaixo, falei de “dados ‘duros’”. Não sei qual ficou pior.
    3. Assim como não sei se Takeuchi e Nonaka têm noção do belo monstro que ajudaram a criar, o tal de Scrum. É importante lembrar, antes que levem a culpa por alguma coisa, que eles não tinham a intenção de criar um framework para gerenciamento de projetos ágeis. Miravam a lua. É importante que nossos tiros, a partir do momento que são cópias ou derivações, não se contentem em atingir apenas o topo da montanha.
    4. “Tree-in-Pot” é o nome do cartoon de hoje. Pra variar, do HikingArtist.

     

  • UMA Resumida e outros Desabafos

    UMA Resumida e outros Desabafos

    Necessária revisão dos últimos artigos publicados. Motivadas por alguns comentários? Sim, mas principalmente pela falta de comentários. Uma breve introdução tentará justificar os “desabafos”. Na sequência, a reapresentação dos últimos artigos utilizando uma perspectiva um pouco diferente.

    ?

    Scientia Interruptus

    Triste verdade: no processo de construção de conhecimento, o {finito} é interrompido em 1/3 do caminho. Porque praticamente não há diálogo algum acontecendo. Agradeço demais as reações, retweets e os poucos comentários que aparecem. Mas eles raramente representam uma conversa construtiva – raramente agregam conhecimento novo. As poucas críticas, particularmente as mais recentes, utilizam um tom e uma agressividade que impedem qualquer tipo de interação civilizada. Ou então simplesmente detonam uma ideia sem propor nada em troca. É o malho pelo gosto do malho, puro e simples. Como esta casa é minha, eu poderia simplesmente eliminá-los. Opto por mantê-los porque não aprovo nenhum tipo de censura¹. Mas também na vã esperança de que reações extremadas incentivem novas discussões. Por enquanto, não funcionou.

    Queria um dia entender todo esse consumo passivo de informações em pleno século XXI, na era da interatividade. Desconfio que minha redação e meu “estilo” não sejam muito convidativos. Desconfio também que alguns temas simplesmente não merecem um dedo de prosa. Erros exclusivamente meus que vivo tentando corrigir. Mas, por enquanto, é apenas isso que tenho: desconfianças. Porque nem retorno sobre elas eu tenho. E não vou fazer “pesquisinhas” porque não acredito nelas. Pesquisa não é conversa. Pesquisas não substituem conversas.

    Meus artigos são teses. Mesmo quando desastrados, são convites para um bate papo. Antíteses são esperadas. Elas não precisam, necessariamente, negar toda a tese apresentada. Mas, obrigatoriamente, deveriam agregar valor – jogar conhecimento novo no ventilador. Só então seria possível uma SÍNTESE, que simploriamente descrevo como uma combinação do melhor da tese com o melhor das “anti-teses”. Por isso falei que o {finito} é interrompido em 1/3 do caminho da criação de bom conhecimento. Ele praticamente morre nas teses. Por exemplo…

    Arquitetura Lean & Ágil

    Uma das duas críticas apresentadas ao último artigo, UMA Modesta Arquitetura, dizia que aquele era papo de “viado, charlatão, chefe com desejo de ser superstar etc”. Mesmo com a melhor das boas vontades eu não conseguiria compor algo novo a partir de tão grosseira reação. Mas esta e outra crítica acertaram em um ponto: aquele artigo ficou longo demais. Apelarei para o outro extremo e tentarei resumi-lo no parágrafo abaixo.

    A arquitetura dos sistemas de uma organização deveria refletir exatamente aquele negócio. Quando olhamos para a arquitetura de um negócio vemos três grandes conjuntos: Objetivos, Estrutura e Processos. Nossos sistemas deveriam respeitar essa organização. Para: i)Viabilizar o uso de um vocabulário comum; ii) Separar aquilo que muda muito (processos) daquilo que muda menos (estrutura); e assim iii) Garantir a agilidade e flexibilidade requeridas em tempos de mudanças e hipercompetitividade. A proposta DCI (Data-Context-Interaction) vai exatamente neste caminho, de separação nítida entre forma e funcionalidades de um sistema. Na distinção entre o que o sistema É e o que o sistema FAZ. Sem saber (ou sem citar), esta proposta também combina com uma leitura recente da Teoria da Complexidade que sugere a separação do que desafia nosso entendimento (estrutura) daquilo que desafia nossa habilidade de prever (comportamento). Três campos (ou domínios) – arquitetura do negócio, arquitetura de software e teoria da complexidade – parecem sinalizar UMA visão unificada. Ainda modesta, mas bastante promissora.

    Gastei três mil e tantas palavras para explicar e detalhar o que descrevo no parágrafo acima. Acho que pequei pelo excesso e pelas redundâncias. Minha intenção única e exclusiva foi mostrar bases e origens de cada uma das três áreas que parecem pedir por uma leitura unificada. Mas este problema, o tamanho do artigo, é quase insignificante quando comparado com uma famosa sugestão contrária ao DCI.

    Intencionalmente deixei de citar uma proposta que parece bater literalmente de frente com as sugestões de Trygve Reenskaug, James Coplien e Gertrud Bjørnvig. O DCI sugere a criação de um “Modelo Anêmico”, um anti-padrão (anti-pattern) arquitetônico documentado por Martin Fowler nos idos de 2003. Ok, tenho certeza de que esta última frase não está correta. Mas eu fiz vista grossa para o escancarado conflito exatamente para receber reações e desafios. Se minha memória não me engana, Coplien também ignora o anti-pattern no livro “Lean Architecture“. Não me interessam mais os debates que acontecem lá fora. Queria ver assunto tão caro em agendas e grupos de discussão tupiniquins. Combustível não falta. Coplien, por exemplo, disse que “SOA is Dead!” Não me preocupa a acusação de charlatanismo. Mas a falta de debate é assustadora.

    Scrum “de raiz”

    A pequena série “Sistema de Blindagem Inteligente” (partes 1 e 2) também mereceu uma crítica. A colega Nara disse não ter visto “nada de extraordinário” em minha proposta. Eu não havia prometido nada do tipo. Mas temo ter desperdiçado a oportunidade de uma boa conversa. Temo que ela tenha entendido que eu propus simplesmente a inversão das prioridades dos times que atendem verticais daquele negócio. Que eles, os times, passariam a dedicar 80% e não 20% do tempo para atender projetos (ou demandas evolutivas). Não foi o que sugeri.

    Citei “organizações ambidestras” e outras referências para sustentar a sugestão de separação radical dos times que deveriam cuidar exclusivamente de projetos. Desta separação radical viria a desejável “blindagem”. Perdi a oportunidade, naquele momento, de citar uma referência que deve fazer muito mais sentido.

    Todos sabemos que o Scrum foi provocado por um artigo de Hirotaka Takeuchi e Ikujiro Nonaka, “The New New Product Development  Game”, publicado na Harvard Business Review de Jan-Fev/1986. Este artigo compila uma série de achados da dupla ao pesquisar o desenvolvimento de produtos em empresas como Fuji-Xerox, NEC, Canon e Honda, dentre outras. Os autores sugerem a adoção de um estilo “rugby” para desenvolvimento de produtos em detrimento do tradicional modo linear (comparado a uma corrida de revezamento). Takeuchi e Nonaka, em outros trabalhos, enriqueceram suas sugestões originais.

    Neste caso nos interessa principalmente a “organização hipertexto”, proposta apresentada originalmente em “The Knowledge-Creating Company” (Oxford University Press, 1995) e reapresentada em “Gestão do Conhecimento” (Bookman, 2009). A organização hipertexto é formada por três níveis: equipe de projetos, sistemas de negócios e base de conhecimentos. Esta “base” seria a síntese do conhecimento proveniente dos sistemas de negócios (hierarquia) e das forças-tarefa (equipes de projetos). Interessante destacar que, para os autores, a distinção entre projetos e o dia a dia seria algo bastante natural. Isso nos idos de 1995. E a gente aqui, correndo atrás de um “sistema inteligente de blindagem”.

    Encerro desconfiado de que o tema “Scrum ‘de raiz’” merece um pouco mais de espaço e atenção. Espero, sinceramente, que você me diga que sim (ou não). E espero, claro, que você não seja tão “binário”. Desde já agradeço. Inté!

    ?

    Observações:

    1. É claro que spams são totalmente censurados. Mas já fui obrigado a barrar outros comentários, infelizmente. Não se dá carona para gente desonesta.
    2. “Three Monkeys“, o cartoon utilizado, foi legalmente surrupiado do HikingArtist.
  • Panelinhas na Prática

    Panelinhas na Prática

    Conclui o artigo anterior prometendo ilustrar o funcionamento das Comunidades de Prática através de dois casos de uso: uma comunidade de gerentes de projetos e outra de analistas de negócios. Descobri depois que precisarei de mais de um artigo para contar toda a história. Começo hoje com o caso de uma panelinha de gerentes de projetos. Ficção inspirada em acontecimentos reais.

    ?

    Era uma vez uma agitada empresa de serviços de TI que dia sim e no outro também enfrentava ‘probleminhas’ em seus projetos. Probleminhas dos mais diversos tipos e origens mas com um alvo em comum: o gerente do projeto. A empresa crescera ou inchara – dependia do ponto de vista – e os tropeços em projetos se multiplicaram. Os clientes se mantinham fiéis porque reconheciam a excelente capacidade técnica dos profissionais que ali trabalhavam. Mas não poupavam críticas à forma como os projetos eram conduzidos. Reclamavam principalmente das más notícias – atrasos e estouros – que só chegavam quando era tarde demais.

    A empresa, que contava com 11 gerentes de projetos, ouviu de um deles que a solução seria a montagem de um Escritório de Projetos. Um órgão que centralizaria discussões sobre métodos de trabalho e cuidaria para que os projetos obedecessem um padrão de qualidade. Os outros gerentes não gostaram da ideia. Desconfiavam, com certa razão, que ganhariam mais um cobrador, além do patrão e dos clientes. “Não precisamos de mais ninguém cobrando resultados – precisamos de alguém que ajude a entregar!” – foi a justificativa que apresentaram ao Poderoso Chefão (PC). Mas concordaram que as coisas não podiam continuar como estavam. Prometeram apresentar uma alternativa ao escritório de projetos. “Na próxima segunda, sem falta!”

    Assim a ‘hora feliz’ da sexta-feira se transformou numa quente reunião de trabalho. Os onze estavam ali no início. Mas o Gil, aquele que defendia a fundação do escritório, ao perceber que era voto mais que vencido, abandonou o barco e meio copo de chopp na mesa. Os demais tocaram o papo como se nada tivesse acontecido. “Temos que mostrar números e nos comprometer com alguns deles”, disse João. “Só assim podemos convencer o PC”, concordou Maria. “É fácil”, explicou José: “O escritório custará, no mínimo, 320 horas por mês. 160 do novo poderoso chefinho mais 160 de um auxiliar que, com certeza, ele vai demandar. 320 horas de fiscalização em cima de nossos 17 projetos, exigindo relatórios de status, cronogramas atualizados, pautas de reuniões etc. E se a gente pedir metade, 160 horas, pra gente debater nossos problemas e tentar, em grupo, encontrar as melhores soluções?”

    Era uma pechincha aos olhos e bolsos do PC: metade do custo¹ do escritório. Mas significaria quatro horas de trabalho a menos, por semana, de todos os gerentes. PC pesou prós e contras e decidiu fazer uma experiência: “Vocês terão 1 mês para provar que essa tal Comunidade de Prática pode ter mais valor que um escritório. Serão 4 reuniões semanais, sempre nas tardes de sexta-feira. Mas, lembrem-se: não quero nenhum cliente me ligando para reclamar que vocês deixaram alguma ponta solta. Não quero amolação, ainda mais no começo do final de semana. Ficou claro?”

    Ficou, apesar de todos concordarem que um mês era muito pouco tempo. Mas era pegar ou largar. Pegaram. E decidiram elaborar, no mesmo dia, a pauta do primeiro encontro. Sabiam que deveriam priorizar as questões que dessem resultado em curtíssimo prazo. Cada membro se comprometeu a apresentar três sugestões de temas. Adiantaram que cada sugestão seria avaliada sob dois pontos de vista: percepção do cliente e do PC sobre aquela possível melhoria e a complexidade de sua implantação. Esperavam, no pior cenário, a apresentação de 33 sugestões (contando com a improvável participação do Gil, aquele que defendia a criação de um escritório). Como sabiam que alguns problemas eram comuns, esperavam um número menor de sugestões a debater. Foi o que aconteceu: ao equalizar o entendimento de todos, terminaram com 12 sugestões de temas. Duas delas apresentadas pelo Gil, para surpresa de todos. Ele seguia com cara de poucos amigos e um tanto negativo, mas participou.

    E ficou surpreso quando, no início da primeira reunião, a turma pediu que ele apresentasse os principais benefícios de um escritório. “Vocês não acham que é tarde demais para isso? Já se arrependeram?” Ouviu que o pessoal queria conhecer melhor a alternativa e que o grande e praticamente único temor deles era o de ‘ganhar outro chefe’. Evitaram a armadilha da conversa que não leva a lugar nenhum insistindo na apresentação dos benefícios em apenas quinze minutos. Não haveria debate. Afinal, eles só tinham quatro horas.

    E aprenderam que, além de servir como ponto único de contato entre gerentes e o PC, o escritório também deveria: i) fixar padrões de métodos e práticas (uma metodologia); ii) ajudar gerentes de projetos em questões pontuais; iii) treinar gerentes de projetos; e iv) indicar gerentes para os projetos.

    Logo perceberam que o foco em ‘questões pontuais’ tornaria o grupo uma alternativa bem mais pobre que o escritório. Revisaram a lista de sugestões e, por sorte, não encontraram ali nenhuma proposta que não pudesse ser aplicada em mais de um projeto. Se de cada proposta emergisse pelo menos uma sugestão de método ou prática, eles começariam a atender o primeiro objetivo de um escritório. O terceiro, treinar gerentes, viria do aprendizado coletivo daquele determinado método ou prática. Já se deram por satisfeitos. E decidiram usar a próxima hora na priorização dos temas. Sobrariam pouco menos de duas horas para debater pelo menos um deles.

    Como priorizar os temas? Partindo da definição original de uso de duas perspectivas (percepção do cliente e/ou PC e complexidade de adoção), Maria foi até o quadro branco e desenhou uma matriz (ela, assim como este aqui rabisca, tem uma queda irremediável por ‘matrizes de apoio à decisão’). No eixo Y Maria anotou a escala de percepção do cliente ou PC. Decidiram que utilizariam cores para diferenciar temas que afetassem apenas um deles ou ambos: “rosa afeta o PC; azul o cliente; amarelo ambos.” Em X o número de semanas necessárias para adoção da possível solução encontrada para determinado tema. Debateram se valeria a pena o risco de adotar soluções cuja implantação durasse quatro semanas. Decidiram que não e concordaram que priorizariam soluções que demandassem o prazo máximo de três semanas.

    A turma gostou, mas destacou uma distorção: eles não estavam se preocupando com seus times, com a percepção deles. Acordaram que, dado o curto prazo, iriam privilegiar temas cuja melhoria fosse percebida pelos clientes ou pelo PC. Se e quando a comunidade vingasse, poderiam utilizar a mesma matriz para cuidar de temas que tivessem reflexo no time – o que chamaram de “questões internas” (ou “intrínsecas”, como quis o Gil, que já estava começando a gostar do rumo da conversa).

    ?

    E você, gostou do rumo da conversa? Espero que sim. Assim como espero que aguarde os próximos capítulos. Vou ilustrar o preenchimento da matriz e as prioridades definidas pela Comunidade de Prática. Um outro artigo será necessário para exemplificar uma comunidade de analistas de negócios. Tentarei evitar que a pauta do {finito} fique muito monótona intercalando pelo menos um artigo diferente entre os próximos. Inté!

    Observações:

    1. Conto com sua compreensão para a ‘conta de padaria’ aqui registrada. Sei que 160 horas de 10 (11) gerentes de projetos podem custar muito mais que 320 horas de um ‘chefe’ de escritório e seu auxiliar.
    2. “Under Pressure“, a foto da panelinha de pressão que ilustra este artigo, é do Anderson Mancini.
  • Formalizando Panelinhas

    Formalizando Panelinhas

    Continuação de “Escritórios, Comunidades e Panelinhas“. Naquele artigo sugeri que Comunidades de Prática podem ser uma alternativa mais eficaz e barata que Escritórios (de Projetos, de Análise de Negócios etc). Hoje tentarei mostrar como uma organização pode identificar, negociar e formalizar uma Comunidade de Prática. As comunidades ou panelinhas já existem e seguirão existindo, queira a gerência ou não. Sua formalização pode representar ganhos em termos de aprendizagem organizacional, ambiente de trabalho e agilidade. Três A’s que devem justificar este tipo de investimento. E que podem ser facilmente medidos.

    ?

    Até uma gerência muito mecânica e dura, baseada em Comando & Controle, sabe da existência de panelinhas entre seus “gerenciados”. A Identificação delas pode ser simples, mas merece alguns cuidados. Em ambientes de trabalho ruins, deteriorados por uma série de razões, as panelinhas ocupam-se demais com chororôs e reclamações diversas. O que une aquelas pessoas é um “inimigo” comum e não um interesse comum. Nestes casos é um tanto mais difícil a seleção de um grupo que possa vir a formar uma comunidade de prática. Se o gerente não for o “inimigo” comum (e ele sabe quando o é), deve tentar participar das rodas de conversas para avaliar quanto conhecimento bom circula por ali. Se pelo menos 20% ou 30% do tempo não for dedicado à chiadeiras em relação ao trabalho já é um bom indício. Sinal de que aquela panela pode ser mais produtiva.

    As panelinhas, por constituírem uma estrutura marginal e não reconhecida pela organização, funcionam nas brechas, nos horários vagos e geralmente em locais abertos, públicos. Reúnem-se ao redor de máquinas de café, nos restaurantes, bares e até em quadras esportivas. E costumam valorizar demais seu tempo e espaço. Por isso a intromissão de um gerente ou equivalente deve ser bem medida e cheia de tato. E silenciosa. Tudo o que ele quer é ouvir. Desnecessário dizer que um gerente boa praça e com ficha relativamente limpa não deve encontrar muitas dificuldades neste momento.

    Vamos supor que o interesse comum de determinado grupo seja a “arte” do gerenciamento de projetos. Entre choramingos, comentários sobre a roupa de fulana e os resultados dos jogos do final de semana, vez por outra as pessoas daquele grupo vão “falar de trabalho”. Este papo, normalmente censurado nas happy-hours de sexta-feira, é o que pode interessar para a organização. A conversa é rica? As pessoas estão realmente trocando experiências? Quantas dicas e momentos a-ha aparecem em um encontro? Os membros sentem-se à vontade para criticar? As críticas são bem recebidas? Não há trollagem (sic) nem rivalidade mal administrada? É fácil perceber quando uma conversa é boa, quando ela gera o que chamei acima de “bom conhecimento”. Se for o caso, acabamos de identificar um excelente candidato à Comunidade de Prática.

    Iniciamos então a etapa de Negociação. Espera-se que o gerente já tenha combinado previamente com a alta direção da organização. É dela que ele receberá os parâmetros negociáveis. E, sinceramente, é nesta negociação prévia que encontramos as maiores dificuldades. Como estamos muito distantes do costume de “formalizar panelinhas”, tudo pode soar muito estranho para os donos da grana: “Como assim, CEDER 4 horas semanais para o grupo? Por PRAZO INDETERMINADO? E EMPRESTAR uma sala de reuniões? E NÃO COBRAR resultado nenhum? Como assim?”

    Destaquei nas questões acima aquelas que considero ofertas mínimas que uma organização pode apresentar para uma comunidade de prática. Revendo:

    • Uma fração da jornada normal de trabalho, no mínimo 10%. Seria uma sacanagem sugerir encontros fora do horário de expediente. A panelinha já o faz e em lugares mais aprazíveis que as tradicionais salas de reunião. E não é nada eficaz colocar alguma condição para o uso dessas horas. É preciso criar costume, criar cultura. Sempre achei que a tarde das sextas-feiras existe exclusivamente para atividades “lúdicas”.
    • Uma Comunidade de Prática não é um projeto nem trabalha em um. Por isso sua existência não tem prazo de validade. Se um dia o grupo descobrir que não está aprendendo mais nada – que sua relação se esgotou – então ele pode decidir pelo encerramento de suas atividades. A organização, em casos extremos, também pode extinguir um grupo. Mas deve estar ciente das consequências negativas de sua decisão.
    • O grupo merece um local adequado para suas discussões. Por adequado entenda: minimamente isolado de outras áreas e equipado de recursos básicos (quadro branco, mesas, cadeiras etc).
    • Por fim, mas não menos importante – muito pelo contrário, o compromisso de não cobrar resultados de uma comunidade de prática. Se ela não é nem está em um projeto, não há metas ou objetivos específicos justificando sua existência. Talvez este seja o ponto mais controverso e mal compreendido de uma comunidade de prática. É claro que uma empresa pode avaliar a qualidade das conversas e do conhecimento que está sendo gerado ali (sobre isso eu falo abaixo). Eventualmente, pode até sugerir algum tema ou problema específico para a pauta do grupo. Mas é fundamental que o grupo não seja percebido como ou confundido com um departamento ou time de projeto, estruturas que são responsabilizadas e cobradas por resultados específicos.

    Fechando o tópico Negociação, é factível supor que a grande maioria das panelinhas receberá de braços abertos uma oferta como a sugerida acima. Ou seja, a negociação com elas tende a ser fácil e rápida. Os maiores riscos que podem existir referem-se à ambiguidade dos parâmetros ou fragilidade da decisão de formalizar uma comunidade de prática. Se os parâmetros acima foram bem costurados com alta direção e membros da panela, não há o que temer. Resta formalizar.

    A Formalização de uma Comunidade de Prática é uma etapa burocrática com valor simbólico. Se uma organização de fato acredita no potencial deste tipo de estrutura para aprender mais e melhor, então ela deve tornar seu apoio explícito. Ao comunicar para todos a iniciativa, a empresa aponta um caminho e uma referência. Na esperança de que outras panelinhas almejem destino semelhante. A boa inveja move montanhas. E talvez a organização descubra várias cumbucas com conteúdo apetitoso e muito relevante em relação aos seus planos e projetos.

    Acompanhando uma Comunidade

    No início do artigo adiantei a existência de três A’s que devem justificar a existência de uma comunidade de prática e também ajudar a avaliá-la: Aprendizagem Organizacional, Ambiente de Trabalho e Agilidade. Hora de explicá-los.

    Conhecimento é um negócio bem difícil de ser medido. Mas o número de vezes que repetimos os mesmos erros não. Uma organização percebe o valor de uma comunidade de prática longe dela, no trabalho cotidiano de seus integrantes. Se eles continuarem batendo cabeça em questões recorrentes ou repetindo erros, é claro sinal de que a comunidade não está funcionando como deveria – ninguém está aprendendo. Na realidade, existem três estágios de evolução que devem ser percebidos:

    • Cognitivo: foi gerado conhecimento novo. E houve também um nivelamento de conhecimentos. Uma diferença que poderia ser bastante perceptível no início do grupo tende a ser reduzida drasticamente ao longo do tempo. Difícil fixar um prazo, mas é de se esperar que em doze meses  (48 reuniões ou 192 horas depois) o grupo esteja muito mais homogêneo em termos de conhecimentos (de práticas e métodos conhecidos e exercitados por todos, por exemplo).
    • Comportamental: surge um padrão de comportamento positivo. Positivo porque não anula individualidades, mas reforça um denominador comum nos modos de pensar e agir.
    • Melhoria do Desempenho: por fim, a organização deve perceber ganhos quantificáveis: qualidade superior do trabalho, prazos respeitados, menor número de reclamações de outras áreas etc.

    A organização também deve perceber uma mudança em seu ambiente de trabalho. A comunidade não é um órgão fiscalizador ou repressor. Pelo contrário, é uma estrutura autônoma baseada na conversa franca e aberta entre membros que se autoselecionam. Se dessa cumbuca não brotar um ambiente de trabalho mais agradável, difícil supor o que conseguiria tal feito.

    O terceiro A é de Agilidade. Mesmo que se limite a encontros (formais) semanais, espera-se que o conhecimento flua e se espalhe de maneira mais rápida entre os integrantes da comunidade e deles para toda a organização (como normalmente ocorre com uma fofoca ou notícia ruim). Não há pontos de checagem e raramente existirão documentos dando forma para aquele conhecimento. Estamos falando de conhecimento tácito que não nasceu para morrer no papel. Estamos falando de experiência, de saber fazer e saber decidir.

    Uma Comunidade de Prática, bem chamada pelo Leandro Mendonça (em comentário) de “Rádio-Peão”, torna-se um grande amplificador e difusor de bons conhecimentos. Pois é, quem diria que panelinhas e rádios-peão virariam peças bem vindas no jogo dos negócios?

    ?

    Artigos como este que aqui se encerra, teóricos e um tanto genéricos, são necessários. Mas provavelmente deixam em ti a mesma vontade que sinto: de ver o outro lado, o lado prático. Por isso no próximo artigo vou mostrar como funcionariam duas comunidades de prática: uma de Gerentes de Projetos e outra de Analistas de Negócios. Inté!

    ps: A “Panelinha” utilizada hoje é do Guilherme Kardel e foi obtida no Flickr.

  • Escritórios, Comunidades e Panelinhas

    Escritórios, Comunidades e Panelinhas

    Somos trabalhadores do conhecimento. De maneira sucinta, meio risível e quase leviana podemos dizer que nosso trampo se limita a adquirir, desenvolver e transferir conhecimentos. Em uma organização é o conhecimento que nos une ou separa. As uniões podem ser temporárias – casamentos e projetos! – ou imunes a deadlines, desquites e processos litigiosos. Separações são concebidas para a eternidade. Até que uma reestruturação (ou recaída) as questione.

    Abertura inspirada, não? O tema deste artigo é a forma como organizamos trabalhadores do conhecimento. Trata de maneira mais específica de escritórios (de projetos, de análise de negócios etc) e comunidades de prática. Tese que deve levá-lo até o final do texto ou para outro lugar da Internet neste exato momento: Escritórios são desperdício de tempo e dinheiro (na maioria das organizações).

    ?

    Caso Real #1

    Reunião urgente e não programada. Desenvolvedores, analistas de negócios, arquitetos, gente de infra e outros (diversos) estão reunidos e ansiosos. É fim de tarde de uma sexta-feira de uma semana nada agradável (para variar). Pauta: metodologia. Ou: “a gente não trabalha do jeito que o cara tá ensinando no curso.” Trinta por cento de interessados. Trinta por cento de apressados. Quarenta por cento com ouvidos e olhos em outro lugar. Até que entra o “chefe” do PMO (Project Management Office ou simplesmente Escritório de Projetos). Se coloca na turma dos apressados e determina: “Vamos trabalhar assim e quem não se encaixar vai para o olho da rua“. Rápido, rasteiro e… desastrado. Fiquei sabendo que ainda sobreviveu alguns meses no cargo.

    Caso Real #2

    Reunião tranquila porque mais ou menos programada. Gerentes, desenvolvedores, arquitetos, gente de suporte e outros (diversos) estão reunidos e ansiosos. A terça-feira agitada aproxima-se do final e ainda há muito o que fazer – muitos problemas a resolver. Pauta: uma melhor maneira para se lidar com *muitos problemas*. Plateia menor (que do Caso #1) e, talvez por isso, cem por cento interessada. Lá pelas tantas, com a pauta discutida, resolvo matar uma curiosidade: “E o PMO? Por que não está aqui?” Resposta: “Não existe mais… para nosso alívio.”

    Interpretação dos Casos

    Ambos aconteceram em grandes empresas. Os PMO’s chegaram lá primeiro e, pelo visto, por lá ficaram. Ou tentaram ficar. Claro que os casos acima não servem para ilustrar o “estado atual dos escritórios de projetos”. Muitos ainda existem, e sobrevivem, inclusive naquela empresa do Caso #1. Vou utilizar os casos para colocar algumas questões.

    Com pequenas variações, normalmente são aceitas como principais responsabilidades de um escritório de projetos¹:

    • Oferecer consultoria em projetos;
    • Desenvolver e manter padrões e métodos para o gerenciamento de projetos;
    • Treinar gerentes de projetos; e
    • Prover gerentes de projetos para a organização.

    O escritório de projetos, como indica a bem intencionada lista acima, presta serviços para a organização. Bom, deveria ser assim. Como ilustra o Caso #1, em muitas organizações o PMO se intromete na cadeia de autorizações. Representa um nível hierárquico a mais, exigindo que parte da organização *responda* para ele. Uma nítida inversão das intenções originais. Naquele extremo caso #1, teria até autoridade para mandar alguém “para o olho da rua”.

    É fácil rastrear  a origem de tal distorção. Basta ver quem montou os escritórios. Foram os gerentes ou coordenadores de projetos mais experientes. Gente que expandiu a *autoridade* de seus conhecimentos e ganhou o direito de julgar, penalizar ou, no mínimo, exigir “relatórios de status“. Não têm culpa se tal *autoridade* lhes foi formalmente atribuída. Na maioria dos casos que conheço eles foram, vamos dizer, “pró-ativos”. Ninguém pediu, mas também ninguém os proibiu de exercer tamanho domínio. Ao deixar o perfil de servidor (prestador de serviços) em segundo plano os escritórios de projetos ganharam a antipatia que os caracteriza em tantos lugares. Fizeram por merecer. Por isso a turma do caso #2 se sentiu aliviada com a extinção de seu PMO.

    Joguemos nesta cumbuca já tão cheia de condimentos mais algumas pimentinhas:

    • Quem trabalha em um escritório de projetos não tem tempo para trabalhar nos projetos – raramente coloca a mão na massa. E, quando o faz, é porque o bicho tá pegando. Vou colocar de outra maneira: o PMO não agrega valor real para uma organização. Sua contribuição é sempre indireta, através dos serviços prestados (e/ou dos julgamentos realizados).
    • O escritório deve ser formado por gente experiente (leia-se *cara*). É uma tentativa (desesperada?) de fazer com que todo aquele conhecimento se espalhe de maneira homogênea por entre os coordenadores e gerentes menos experientes (leia-se *mais baratos*). Pense nisso: não posso alocar meu melhor gerente de projetos em minha iniciativa mais crítica porque ele está ocupado ensinando (e/ou fiscalizando) os menos experientes (em iniciativas de menor relevância para o negócio).

    Escritórios de projetos são uma péssima ideia? Longe disso. Em seu conceito original é uma estrutura fundamental para alguns tipos de empresas e órgãos públicos. O problema está em sua adoção torta e mal concebida por empresas que viram nele um elixir do século XIX, aquele remédio que curava tudo. São as mesmas empresas que já caíram ou ainda vão cair no conto do CMMI, MPS.br e vários outros. Gente que não lê bulas e quase sempre morre de raiva de quem as torna públicas.

    Alternativas

    A definição de Comunidades de Prática, se não for anterior, é contemporânea dos Escritórios de Projetos². Mas as Comunidades nunca tiveram um apelo “pop”. Provavelmente porque nunca ninguém ganhou muito dinheiro montando ou ajudando a montar uma. Provavelmente porque tal montagem deve ser orgânica e natural (leia-se: é lenta!), ao contrário dos escritórios que podem ser instituídos e financiados com uma simples canetada, literalmente da noite para o dia.

    Toda empresa tem várias comunidades de prática não reconhecidas. Aqui no Brasil elas são chamadas de ‘panelinhas’. São aqueles grupos informais de quase-iguais, gente que compartilha interesses e conhecimentos. Suas trocas de experiências (e fofocas e maledicências) ocorrem de maneira não muito programada, ao lado das máquinas de café, nos restaurantes e botecos. As ‘panelinhas’ são auto-organizadas e seus membros se auto-selecionam. Por isso o termo ‘panelinha’ tem um ‘p’ de pejorativo: para quem ficou de fora, uma ‘panelinha’ é sempre um grupo antipático, elitista, segregador. Enfim, uma panelinha.

    Acontece que, para quem está dentro, a mesma ‘panelinha’ é um ambiente estimulante, reconfortante e agregador. Seus membros aprendem trocando experiências e contando histórias. Mesmo estando alocados em projetos ou departamentos distintos, quando na ‘panela’ suas experiências e histórias são valiosas. Porque seus interesses são comuns: quem está lá quer, acima de tudo, aprender³.

    Uma organização, de qualquer porte ou ramo de atividades, tem muito a ganhar ao reconhecer e apoiar suas ‘panelinhas’. E, quando o fizer, poderá chamá-las de Comunidades de Prática – um termo bem mais aceitável. Não será exigido que, por apoiar uma, a organização seja obrigada a apoiar todas as outras. Uma comunidade que compartilhe interesses em culinária vegana ou sexo tântrico talvez não esteja alinhada com os objetivos estratégicos da empresa. Já uma comunidade de gerenciamento de projetos poderia assumir quase todas as responsabilidades que normalmente são atribuídas ao PMO. Por uma pequena fração do custo este representa.

    Uma organização pode identificar as comunidades que mais lhe interessem e negociar sua formalização. Sei que já escrevi sobre o tema aqui no finito. Mas faz tanto tempo (foi lá pelos idos de 2004), que vale a pena uma reescrita. Fiquei particularmente motivado pelo assunto depois que vi sugestões para montagem de “Escritórios de Análise de Negócios”. Antes que a ideia se espalhe como fogo em mato seco, gostaria que considerassem uma alternativa. No próximo artigo falarei especificamente sobre a identificação, negociação e formalização de uma Comunidade de Prática. Depois, se o papo render, farei uma comparação dos Escritórios versus Comunidades de Prática. Inté!

    ?

    Observações:

    1. Lista parcialmente surrupiada de The Project Office (Best Management Practices), de Thomas R. Block e J. Davidson Frame (Crisp Publications, 1998).
      Acabei de visitar a página do livro e acho que ganhei outro argumento (contra os PMO’s). Você sabe que tem alguma coisa *muito* errada com o tema quando se depara com um livro chamado “Business Driven PMO Setup“. Com 528 páginas?!? E você ainda ganha acesso a 150 podcasts? Meu, só falta mandar um bode expiatório como brinde. Com todo respeito… aos bodes!
    2. Ao que tudo indica, as Comunidades de Prática apareceram no radar no início da década de 1990. Segundo a Wikipedia, em 1991. Eu acho que Escritórios de Projetos vieram um pouquinho depois, em meados da mesma década. E se espalharam como fogo em mato seco a partir do ano 2000.
    3. Por isso as e-Panelinhas, extensões virtuais conhecidas geralmente como Grupos de Discussão, ainda não representam boa alternativa para as organizações. Alguns não estão lá para *aprender* e sim para *aparecer*. Detonam a intenção original e criam um sem número de efeitos colaterais indesejáveis. Talvez eu fale um pouco mais sobre isso em um futuro artigo. Se o estômago deixar.
    4. A “Panelinha” que ilustra este artigo é do Felipe Skroski e foi surrupiada legalmente do Flickr.

  • Capital Intelectual

    Quando publiquei minha lista com “11 Livros ‘Obrigatórios’” confessei uma dúvida: deveria colocar “A Economia da Informação“, de Carl Shapiro e Hal Varian, ou “Capital Intelectual“, de Tom Stewart. Um não serve como alternativa ao outro – eles são totalmente complementares. O primeiro, que acabou ganhando a posição na lista, fala de Economia. O livro de Stewart trata de ativos intelectuais e gestão do conhecimento. Já nem me lembro mais o critério que usei para decidir pelo livro de Shapiro e Varian. Mas desde então, folheando e relendo os dois trabalhos de Stewart, fiquei incomodado com a injustiça que cometi. Daí esta nova entrada em nossa biblioteca.

    .:.

    Original: Intellectual Capital (Doubleday, 1997).

    Autor: Thomas A. Stewart é CMKO (Chief Marketing and Knowledge Officer) da Booz & Company. Quando publicou o livro era membro da equipe de editores da revista Fortune. Depois, entre 2002 e 2008, foi editor e diretor da Harvard Business Review (HBR). É um dos papas em Gestão do Conhecimento e um dos principais nomes da administração moderna.

    Editora: Campus, 1998. Tradução (acima da média) de Ana Beatriz Rodrigues e Priscilla Martins Celeste.

    Assunto (direto da orelha): O conhecimento se tornou o fator mais importante da vida econômica. É o principal ingrediente do que compramos e vendemos, a matéria-prima com a qual trabalhamos. O capital intelectual – não os recursos naturais, equipamentos ou até o capital financeiro – tornou-se um ativo indispensável para as empresas.

    Relevante para:

    • Todos que lidam de alguma maneira com a tal “Gestão do Conhecimento”;
    • Empresários e empreendedores envolvidos com produtos ou serviços que i) são conhecimento; e/ou ii) são enriquecidos com conhecimento;
    • Trabalhadores do conhecimento;
    • Em suma, o livro deve servir para todo mundo.

    Tenta ensinar:

    • O que é Capital Humano, Capital do Cliente e Capital Estrutural;
    • Como mapeá-los e gerenciá-los como Ativos de Conhecimento da organização;
    • Como utilizar esses ativos para se diferenciar;
    • Como lidar com aquele tipo de capital que vai embora todo dia, ao fim do expediente;
    • Como o detentor daquele tipo de capital tem sua vida pessoal e profissional afetada neste ‘novo’ mundo dos negócios.

    Prós:

    • Texto muito bem fundamentado e amparado. Stewart não abre mão nem de citar Peter Pan ou Alice no País das Maravilhas. Ou seja, sua cultura ampla e diversificada torna o texto agradável e rico – isento de jargões e armadilhas efêmeras (lembre-se, o texto é de 1997);
    • As pesquisas e estudos de caso também ajudam a apoiar o texto e a tese de Stewart;
    • Não reinventa a roda: o trabalho de Takeuchi e Nonaka na área são fundamentais? Então apresente-os como tal!
    • E, sempre que possível ou necessário, estenda outros trabalhos provando que você não está simplesmente copiando e colando boas ideias.

    Contras:

    • A Campus raramente é tão infeliz na escolha das fontes e na diagramação. Não chega a comprometer a leitura, mas fica feio pra chuchu.
    • Não sei se é correto dizer que Stewart negligenciou o tema “arquitetura do negócio” (como o valor é criado – em alto nível) neste trabalho. O fato é que ele ‘corrigiu’ a falha no livro seguinte, “A Riqueza do Conhecimento” (mais sobre ele abaixo).

    Gotas (de conhecimento):

    “Os mercados são implacáveis. Recompensam o que cria valor e ignoram ou castigam o que não cria. Nada pessoal.”

    “O Capital Intelectual é o conhecimento útil em nova embalagem.”

    “As ideias são livres. são também um recurso abundante, provavelmente infinito. Qualquer pai ou mãe que já tenha deixado um filho de dois anos sozinho por um minuto sabe que ter ideias é uma característica humana inata que não requer treinamento nem educação especiais; o desafio gerencial está no desenvolvimento organizado de ideias construtivas.”

    “Estamos acostumados a pensar em funcionários em termos de seu salário – seu custo. Mas qual é o seu valor? Quanto vale realmente um emprego?”

    “Há um paradoxo no âmago da organização da Era da Informação: enquanto os empregadores enfraqueceram os laços da segurança no emprego e da lealdade, mais eles dependiam do capital humano.”

    “Quando o conhecimento é o principal recurso e resultado – a entrada e a saída, a matéria-prima e o produto acabado – a propriedade desse conhecimento torna-se indistinta, compartilhada: o trabalhador é parcialmente proprietário, assim como o capitalista e o cliente.”

    “As empresas precisam muito mais dos trabalhadores do conhecimento do que eles precisam delas.”
    (Stewart citando Peter Drucker)

    “Há um paradoxo na economia da informação e tanto o comprador quanto o vendedor estão sujeitos a ele: o comprador não pode julgar se vale a pena pagar por um pedaço de informação antes de possuí-la; mas, depois que a possui, ele não precisa mais comprá-la.”
    (Ah, como eu gostaria que alguns prospects entendessem isso…)

    “Quando se trata do trabalho criativo, não existe correlação econômica significativa entre o insumo do conhecimento e o produto do conhecimento: o valor do capital intelectual não está necessariamente relacionado ao custo de sua aquisição, o que impossibilita o uso de uma medida do que você faz como um meio de revelar como você está se saindo.”

    Agora, de bons e necessários que são, vou citar dois trechos do outro livro do Stewart, “A Riqueza do Conhecimento“:

    “As empresas são organismos vivos; os documentos são como defuntos.”

    “Conexões primeiro, coleções depois: esta é a essência da gestão do conhecimento.”

    A Riqueza do Conhecimento

    Como sempre acontece, um bom trabalho puxa outro. Thomas Stewart publicou, em 2001, uma sequência obrigatória para “Capital Intelectual”. “A Riqueza do Conhecimento” (Campus, 2002) completa o primeiro trabalho, com mais casos e exemplos e, principalmente, com um fator que era mais nebuloso em 1997 (data do primeiro): a Internet (e respectivas intranets, groupwares, páginas amarelas etc). Como chamei atenção acima, Stewart também aproveitou o novo trabalho para explorar um pouco mais os modelos para criação de valor. Seu primeiro livro trabalha com profundidade as Redes de Valor. Aqui ele compara este ‘meta-modelo’ com as Cadeias e Oficinas de Valor. Este será o tema de um dos meus próximos artigos.

    Aperitivo: fábricas de software (e várias outras organizações) estruturam-se como cadeias de valor. Segundo Stewart, esta é “uma metáfora tão poderosa que, por vezes, até nos esquecemos que ela aplica-se sobretudo aos contexto de fabricação e que não se adapta muito bem a muitos setores. Estendê-la a serviços, principalmente àqueles intensivos em conhecimento, pode envolver distensões, amputações e entorses tão procustianas que acabam confundindo em vez de esclarecer a situação real”. A gente vai conversar mais sobre isso. Inté!

  • Aprendizado Interprojetos

    Quinze meses mergulhado em um mesmo assunto, mesmo que ele seja amplo e saboroso, cansa. Aproveitei o feriado e meu 3º aniversário para “oxigenar” o cérebro. Trouxe de Sampa, na semana passada, a última edição da MundoPM. Não curto muito a (cara) revista, mas uma chamada de capa me pegou: “Gestão do Conhecimento Interprojetos: como evitar custos imensos de reinvenção e oportunidade a cada projeto“. Caramba… há 4 anos eu não via nada sobre o tema. Este foi o assunto do primeiro trabalho que publiquei aqui no finito, resultado de um estudo que fiz entre 2003 e 2004 (compilado neste PDF de 240kb e 21 páginas – versão revista hoje!).

    O artigo publicado na MundoPM é de Naomi Brookes, diretora do centro de práticas de gerenciamento de projetos da Aston University (UK), e Michel Leseure, professor de gerenciamento de operações na Escola Comercial de Negócios de Plymouth. Desnecessário dizer, são de um universo totalmente diferente do meu. Mas, caramba, como dois trabalhos sobre um mesmíssimo (e específico) assunto podem ser tão diferentes? Até na bibliografia não há uma única referência em comum! O único texto que conheço na lista deles é “The Knowledge Creating Company”, clássico de Takeuchi e Nonaka que não cito em minhas referências.

    O trabalho da dupla compila os resultados de uma pesquisa que fizeram com 14 empresas européias, dos mais diversos ramos. Sua conclusão não difere muito da minha:

    Os estudos de caso mostraram deficiência nos processos formais de gestão do conhecimento explícito para transferir conhecimentos de um projeto para outro.

    …

    Isto ilustra uma falta de consciência sobre o conceito de gestão do conhecimento nas empresas deste nível.

    Mas uma palavrinha da citação acima resume toda a diferença entre o trabalho deles e o meu: “explícito” (conhecimento). Para eles, “conhecimento tácito é difícil de transferir”. E concentram boa parte de seu trabalho na indicação de mecanismos que promoveriam ou facilitariam o aprendizado interprojetos, dentre eles intranets, bancos de dados e bancos de dados de intranets… (não brinquei – está na figura 2 daquele artigo).

    Todo o meu trabalho gira em torno de eventos de socialização, ou seja, na troca de conhecimentos tácitos. Sugiro o uso de dois mecanismos, as “Comunidades de Prática” e as “Histórias de Aprendizado”. Não acredito que intranets e bases de dados promovam aprendizado de verdade. Mas entendo que eles têm sua utilidade em uma empresa que leve a sério o papo sobre gestão do conhecimento. Se bem construídos, são excelentes “guias de referência rápida”.

    Assim como o artigo de Naomi e Michel, que guardarei com carinho. Não só pela sua qualidade, mas também porque me permitiu ressuscitar um assunto há muito ignorado por aqui.