PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Ikujiro Nonaka

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

     

     

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