PAULO FERNANDO VASCONCELLOS NOGUEIRA

Tag: Iterativo e Incremental

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

     

     

  • 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.
  • Sistema de Blindagem Inteligente, Parte II

    Sistema de Blindagem Inteligente, Parte II

    Caso tenha perdido, aqui está a primeira parte. A encerrei relacionando quatro impedimentos para a adoção do Scrum na empresa YYZ (nome alterado). Importante lembrar: mais que ao Scrum, são impedimentos para a realização de sete objetivos da área de TI daquela empresa. O Scrum é só (!) um possível meio de atendê-los. Dos quatro ‘bloqueios’, um é mais crítico: os times consomem aproximadamente 80% de seu tempo cuidando de problemas do dia a dia. Como proteger os times? Há uma forma de blindagem minimamente inteligente? Abaixo, o desenrolar do enrolado causo.

    ?

    O impedimento crítico foi apresentado para uma equipe de coordenadores – quase todos os responsáveis pelos onze times que formam aquela unidade de TI. Seguiu-se um debate sobre alternativas de solução – opções de blindagem.

    A primeira, aparentemente bastante simpática aos coordenadores, considerava a alocação de poucos membros (20%) de cada vertical para o atendimento das demandas emergentes / urgentes. Além disso, todos os times dedicariam cerca de 20% de seu tempo para essas questões. Era, com certeza, a alternativa que menor impacto causaria na estrutura atual.

    O diagrama¹ acima destaca duas restrições principais para a sugestão. A primeira é “matemática”: mesmo que destacássemos 20% dos membros do time mais 20% do tempo de toda a equipe para cuidar dos requisitos urgentes, não seria possível atender todas as demandas (lembre-se: elas consomem atualmente 80% do tempo útil de todo o time). A consequência natural seria o acúmulo de demandas não atendidas, seguido do aumento da insatisfação dos usuários e assim por diante. Além disso, há o aspecto cultural que não pode ser negligenciado. Ele foi destacado na primeira parte: a empresa YYZ tem uma (honorável) política de portas abertas. Todo mundo pode falar com todo mundo praticamente a qualquer hora do dia (e da noite!). Fazer com que os usuários falassem apenas com determinados membros e/ou em período pré-determinado vai contra uma cultura estabelecida de longa data.

    A mesma questão cultural aparece como impedimento para a alternativa #2. Nela, conforme sugerido pelo responsável pela área de TI, todas as demandas seriam encaminhadas para a área de help desk. Muitos dirão que já deveria ser assim. De certa forma, é. A área de suporte da YYZ recebe uma média de seis mil (6k!) chamados por mês, 1500 deles relacionados ao ERP. E consegue fechar (bem) algo em torno de 85% deles. O resto? Sobra para as verticais de negócios. E junta-se aos requisitos que os usuários preferem apresentar de maneira direta (em uma mistura de demandas ditas “evolutivas” com simples alterações de telas, pequenos bugs etc). Como adiantei, há a questão cultural: os usuários não podem ser impedidos de se relacionar com as verticais que os espelham em TI. Mas há uma segunda e mais grave restrição para a segunda alternativa. Falta gente. Mais: falta gente qualificada. Cheguei a sugerir o deslocamento de analistas de negócios e desenvolvedores para lá. Propus engolindo. E engoli seco. Ninguém aceitaria um movimento que tinha cara e jeito de “rebaixamento”, por nobre que seja o serviço de suporte. O treinamento de novos integrantes foi cogitado. Mas, como o diagrama tenta indicar, é coisa que toma tempo. Muito tempo.

    Sobrou a terceira alternativa. Aquela que, como consultor, defendi. Partindo do princípio de que a blindagem total dos times é impossível, não resta outra opção que não seja a criação de um novo time. Um time que seja desconhecido pelo negócio e respectivos representantes. Ou seja, além de blindado ele também é invisível². Desta forma as verticais de negócios cuidariam exclusivamente do cotidiano – atendimento aos usuários e solução de pequenos problemas. Seriam também a porta de entrada para as chamadas “demandas evolutivas”. Para tanto, seguiriam contando com pessoal capaz de executar atividades de análise de negócios. Talvez um pouco mais que isso. O coordenador de cada área poderia vir a ser um Dono do Produto (Product Owner ou simplesmente PO, como queira). Eu sei, eu não curto muito esse papo de dublê de PO. Mas, neste caso, dado o invejável conhecimento do negócio que cada coordenador apresenta, os riscos inerentes ao desenho eram consideravelmente reduzidos. E haveria outro benefício: o novo time seguiria de fato invisível. Mas, quem integraria o novo time?

    Você se lembra que os coordenadores estavam dispostos a “sacrificar” 20% de seu time para cuidar exclusivamente das demandas não previstas? Bom, se pegarmos 20% de cada uma das sete verticais de negócios (que têm, em média, 8 integrantes) mais o time de controle de qualidade (pelo menos 60% dele – seis profissionais) temos uma nova composição com cerca de 17 pessoas. Praticamente 3,5 times de Scrum (considerando o tamanho ideal sugerido: 5 (+/- 2)). Claro, este time seria multidisciplinar, auto-organizado, dono de seus processos e, o mais importante, orientado por um e apenas um Product Backlog. Quase sem querer (querendo!) já atendemos o objetivo #1 da lista que foi apresentada na primeira parte: “Ter uma fila única de demandas”. Dois coelhos, talvez alguns mais, numa única porretada. Parecia tudo muito bom para ser verdade. Quais restrições para esta alternativa foram apresentadas?

    “Esse time não teria real domínio do negócio”, disseram alguns. Oras, para isso existem os PO’s e seus asseclas (analistas de negócios e afins), certo? Além disso, o novo time é formado por gente que já tem, em média, três anos de casa. E são provenientes de todas as verticais de negócios, o que representa um certo conhecimento e visão do todo. Sinceramente, isso não é restrição que se apresente. Porque ela não para em pé. Então, uma segunda restrição – aparentemente mais forte – foi colocada: “O <nome_do_responsável_por_ti> não quer que demandas evolutivas sejam separadas das corretivas”; “Além disso, o <nome_do_responsável_por_ti> não permite em hipótese nenhuma que duas equipes trabalhem nos mesmos artefatos“. Quantos traumas, quantas noites mal dormidas e quantos sistemas bisonhos de controle de versões são necessários para criar restrições tão… sei lá. Prefiro não adjetivar. Assim como preferi não gastar meu tempo com um estudo antropológico daquelas raízes pré-históricas. Me limitei a lembrar Peter Senge: “Os problemas de hoje vêm das soluções de ontem.”

    Percebi que não se tratava apenas de restrições do <nome_do_responsável_por_ti>. Os próprios coordenadores não gostaram nadinha da ideia de um novo time. Um time que provavelmente viveria sem a figura de um coordenador e que ficaria com o filé, enquanto eles seguiriam com o feijão com arroz do cotidiano. A antipatia deles pela sugestão é perfeitamente compreensível. Mas não é justificável.

    Faltou a eles enxergar um pouquinho além e entender que este desenho, como todos os outros, é temporário. Não entenderam que o novo time seria um “super” prestador de serviços para eles. E faltou acreditar que, com o tempo, o novo time poderia ser gradativamente incorporado às suas unidades. E que isso seria possível tão logo o tempo de resposta fosse reduzido para prazos que excedessem minimamente as expectativas dos usuários; o que os levaria para a fixação de acordos de níveis de serviços (objetivo #4 da lista original). Antes que você me chame de ingênuo e/ou simplório: resumi veredito e consequências.
    {Mas, caso queira explorar um pouco mais esta parte, por favor, comente! Acho que o assunto é bom demais para morrer aqui, só com minhas palavras.}

    Algumas Referências para a Alternativa #3

    Pois é, o artigo está ficando mais longo que o usual. Mas não quero fazê-la(o) esperar por uma terceira parte. Conto com mais um pouco de sua atenção.

    Já tem um bom tempo, creio que quatro ou cinco anos, que li um artigo sobre uma grande mudança que estava acontecendo na Promon. Eles estavam “duplicando” várias gerências. Uma cuidaria do dia a dia. A outra, nova, trabalharia apenas no “amanhã”. Me apaixonei pela ideia mas, infelizmente, não vi mais nada a respeito. Sei lá se foi mantida, muito menos o que conseguiram. Temo que, por considerar apenas os gerentes, a coisa não tenha vingado.

    Mais recentemente começaram a pipocar artigos e teses sobre “organizações ambidestras“. Apesar de algumas interpretações meio tortas e rebuscadas, a proposta central parece ser a mesma: separar o presente do futuro. E fazer com que as organizações trabalhem nas duas frentes com a mesma atenção e dedicação. Não necessariamente com o mesmo volume de recursos. Mas, desejavelmente, com princípios e processos em comum.

    Sinceramente, não vejo alternativa que não passe por uma divisão assim. O problema com esse tipo de mudança é que ela é drástica. O que significa dizer que a resistência a ela será igualmente forte. Pensando Scrum ou, mais precisamente, pensando Lean, não estamos mais falando de Kaizen (melhoria contínua) e sim de Kaikaku (mudança radical). E o que é necessário para a implementação de uma mudança radical? Coragem; sangue frio; apoio dos altos escalões; comprometimento com a solução… A lista é longa e não é estranha para você que conhece mudanças. Por isso vou tocar em um ponto relativamente incomum: quem promove uma mudança radical não alimenta a ilusão de que não haverão “mortos” e feridos. Muitos pularão do barco. E isso não é necessariamente ruim.
    {Está aqui outro ponto que podemos discutir bastante, não?}

    Epílogo

    Se você respeita o jeito Lean de pensar, então sabe que não pode tratar problemas (impedimentos ou bloqueios) com remendos rápidos e muito menos fazer vista grossa para eles. Você deve, literalmente, “parar a linha”, analisar as raízes do problema, encontrar e implantar uma solução para ele. Foi o que aconteceu com este serviço de consultoria. Interrompemos o processo, eu parei meu “relógio”, apresentei e propus discussões sobre os impedimentos. Um mês. Dois meses. Três meses…

    Fiquei sabendo que o <nome_do_responsável_por_ti> foi transferido para outro negócio da YYZ. Não sei dizer se as restrições que ele defendia permaneceram. Creio que não. Mesmo assim, não acredito que minha sugestão tenha uma nova chance. É assim mesmo: quantas vezes já fomos aconselhados a ter uma vida mais saudável, menos sedentária, mais preocupada com o amanhã? E quantas vezes seguimos os conselhos? São poucos os consultores, pais, esposas, médicos e afins que são de fato escutados. Menor ainda é o número dos que recebem prêmios milionários por seu poder de persuasão e objetivos alcançados.

    ?

    Observações:
    1. Não julgue o “diagrama” rabiscado, please! É só um resumo da apresentação das três alternativas e respectivas restrições. E, sim, é um Causal Loop Diagram (Diagrama de Círculos Causais). Caso você não conheça, a “o” (bolinha) ao lado de uma linha significa força (ou feedback) contrário (ou negativo). O “c” significa uma restrição (ou constraint). É uma ferramentinha que, pelo visto, está ganhando novo impulso. Na última segunda vi Jurgen Appelo utilizá-la para mostrar como esse negócio de desenvolver software é “doomed”. Mas pode ser salvo! Craig Larman também usou e abusou dela em seu último livro, “Scaling Lean & Agile Development” (Addison-Wesley, 2009).
    2. O aspecto “invisível” (do novo time) é desejável neste caso específico. Não o indicaria em ambientes que não tenham uma política tão aberta e generosa de “relacionamentos muitos-para-muitos 24×7”. Insisto, na YYZ o time só estaria 100% blindado se fosse “invisível”.
    3. “Trainee hatchings” é o título do cartoon de hoje. Como sempre, foi surrupiado do HikingArtist.
    4. Aquele xampu segue me provocando com o seu “Sistema de Blindagem Inteligente”.
  • Sistema de Blindagem Inteligente, Parte I

    Sistema de Blindagem Inteligente, Parte I

    Não é piada: o “sistema” que dá nome a este post aparece em uma embalagem de xampu. E me incomoda, a cada banho, há algumas semanas. Até xampu consegue fazer uma blindagem inteligente! Então por que seria tão difícil para algumas organizações isolar e proteger, ou seja, blindar um time de projetos? A questão passou a me atazanar com mais frequência depois que publiquei uma breve compilação sobre problemas mais comuns na adoção do Scrum. Aquele artigo passou batido pelo problema. Tentarei corrigi-lo agora. E vou fazê-lo através de um causo real minimamente maquiado por razões óbvias¹.

    ?

    A empresa YYZ, um imenso conglomerado com presença global, desenvolveu seu próprio ERP. Lá se vão anos desde que aquele imenso monolito viu a luz. Ele fora concebido para cuidar do núcleo do negócio e, claro, das finanças. Com o passar do tempo, ganhou inúmeras novas responsabilidades, da produção até a logística de armazenamento e entrega passando por tudo o que é possível existir entre estes polos. Ou, melhor dizendo, quase tudo. Não se aventurou a cuidar do RH, por exemplo. Apenas um detalhe. O fato é que o ERP, cimentado firmemente em um desenho Cliente/Servidor (de duas camadas e milhares de Stored Procedures), é grande. Quase imensurável.

    São onze os times que cuidam da manutenção e evolução do sistema. Sete deles cuidam de verticais específicas, como Vendas, Administração e Produção, por exemplo. Os outros quatro “prestam serviços” para eles. Bem, para dizer a verdade, eles não são vistos assim na maior parte do tempo. Um deles é o Controle de Qualidade. E não é tão comum assim ver este “departamento” sendo percebido ou se apresentando como um “Prestador de Serviços”. A verdade é que ninguém lá dentro precisava de um consultor para informar que a qualidade e seu respectivo controle deveriam ser incorporados aos times. Acho que apenas a própria área de qualidade. Consultor? Retomemos o causo.

    “Paulo, você nos ajuda a implantar o Scrum?” Claro, por que não? Mas, diga aí, por quê? Ops… perguntinha maldita, não? Alguns meses se passaram até que a contratação fosse fechada e, mais importante, até que a perguntinha maledeta fosse respondida:

    1. Ter uma fila única de demandas
    2. Saber o esforço que cada demanda consumiu
    3. Reduzir o tempo de entrega
    4. Fechar acordos de níveis de serviços (SLA) com áreas usuárias
    5. Tornar as demandas visíveis para as áreas usuárias
    6. Ter tempo para o planejamento estratégico
    7. Medir o desempenho dos integrantes das equipes

    Rabisquei o diagrama acima para determinar uma sequência de trabalho. Conclui que a realização do item 3, a redução do tempo de entrega, favoreceria a satisfação de todos os outros requisitos. E que o fechamento de SLA’s (item 4) só seria possível depois que todos os outros objetivos fossem minimamente atingidos. Portanto, o próximo passo era descobrir a razão das entregas serem tão demoradas (60 dias, em média, entre o registro da demanda e sua entrega definitiva para os usuários).

    Não nos custou um dia o diagnóstico dos quatro principais fatores que retardavam as entregas:

    • As especificações, elaboradas por analistas de negócios, são muito extensas (e de pouca ou nenhuma utilidade após as entregas);
    • A área de qualidade só sabe que algo é prioritário quando ouve gritos. No mais, administra uma fila que mistura tudo das sete verticais de negócios. E tem pouca gente para tanto trabalho, apesar de não cobrir 20% dos tipos de testes possíveis;
    • Dada a complexidade da distribuição – várias unidades espalhadas geograficamente – é compilada e entregue apenas uma “versão” por mês; e
    • Os desenvolvedores são atropelados diariamente por problemas, de bugs até o mal entendimento de determinadas funcionalidades pelos usuários, passando pelo que é mais grave: novas demandas urgentes.

    Me sinto à vontade para descrever o causo principalmente porque sei que os quatro problemas acima podem apontar para um sem número de empresas ao redor do globo. Não há nada de particular aqui, o que pode tornar este artigo realmente útil. Voltando para a história.

    Seria relativamente fácil solucionar os três primeiros problemas. Existe um padrão único para especificação de demandas. Requisitos imensos e minúsculos recebem o mesmo tratamento (burocrático), o que não faz sentido. Mais: toda a análise de impacto e definição do “como” (protótipos de telas, lista de alterações nos bancos de dados etc) é realizado pelos analistas de negócios, o que torna a vida dos desenvolvedores um sossego (e uma chatice só). Qualidade, o segundo problema, deveria ser incorporada (de fato e de direito) pelas verticais de negócios. Que deveriam ganhar também autonomia em relação a atualização de versões. Apesar do jeitão monolítico do ERP, vimos que era perfeitamente possível gerar mais de uma versão por mês. Daí a estimar (salivando) que seria possível uma redução de 60 para 15 dias do tempo médio de entregas foi um pulinho. Ingênuo pulinho.

    O quarto problema – o atropelo das verticais de negócios por questões do dia a dia – se apresentou monstruoso logo no primeiro dia da experiência com o Scrum. A empresa YYZ tem uma bela política de “portas abertas” para todos. Aliás, mal existem portas (e paredes). O que gera um efeito dramático na área de TI: usuários aparecem a qualquer momento com seus choramingos e requisitos. E não atendê-los está fora de questão.

    “Oras, Paulo, parece que fazes tormenta numa pequena caneca d’água! Não bastaria separar alguém do time ou parte do tempo de todo o time para o atendimento das demandas imprevisíveis?” Como, respondo perguntando, em um cenário onde elas consomem cerca de 80% do tempo útil de toda a equipe?

    O papo segue na parte II. Inté!

    ?

    Observações:

    1. Não revelo a identidade de meus clientes de consultoria exatamente para ter a liberdade de tratá-los como causos, aqui no {finito} e em meus cursos e palestras.
    2. Não, o xampu com “Sistema de Blindagem Inteligente” não é meu, ok?
    3. “getting away from it all” é outro cartoon que surrupio do HikingArtist.com

     

  • Análise de Negócios – 4 Anos Depois

    Análise de Negócios – 4 Anos Depois

    Há quatro anos iniciava meu mergulho na Análise de Negócios, estudando o mercado e desenvolvendo o programa de treinamento que seria lançado em junho/07. Muita coisa parece diferente agora, particularmente a difusão da disciplina. Infelizmente, muita coisa parece inalterada ou ter mudado para pior. Neste artigo pretendo discutir alguns problemas que impedem o uso pleno e eficaz da Análise de Negócios pelas organizações.

    ?

    Naquela época algumas pessoas diziam que o bafafá sobre Análise de Negócios não passava de uma moda. Sempre admiti que a disciplina vivia seu momento, algo semelhante ao que havia acontecido com o Gerenciamento de Projetos a partir da segunda metade da década de 1990. E completava: “antes tarde do que nunca”. Porque já tinha muito tempo que diversas fontes, ao analisar as razões de tantos fracassos em projetos de TI, apontavam o mau entendimento de um problema e questões de comunicação entre times técnicos e de negócio como algumas das principais causas de tanto insucesso.

    Surrupiei e uso desde então uma colocação que Fred Brooks fez em seu artigo “No Silver Bullet” (publicado originalmente em 1987 e disponível como capítulo adicional do livro “O Mítico Homem-Mês“, Campus – 2009):

    “A precisa definição sobre o que precisa ser feito é a parte mais difícil da construção de um software. Nenhuma outra compromete tanto um projeto quando mal executada. E nenhuma é mais difícil de ser corrigida.“

    A Análise de Negócios, por definição, ataca exclusivamente¹ a “parte mais difícil da construção de um software”. Por isso eu dizia e repito: “antes tarde do que nunca”. Que a disciplina tenha vindo para ficar. Ou, melhor dizendo, que a “moda” (assim, entre aspas) tenha vindo para ficar. Porque a disciplina está conosco há um tempão.

    O problema é que sua presença não era percebida como sendo uma disciplina, um único corpo de conhecimentos. No RUP, por exemplo, surgia em dois lugares: Modelagem de Negócios e Requisitos. Em outras propostas e métodos dava sua cara sob o disfarce de “<verbo> Requisitos” (Levantamento (sic) de Requisitos, Coleta (10x sic) de Requisitos, Gerenciamento de Requisitos  etc). Esta ligação direta, Análise de Negócios -> Requisitos, é tão comum e pouco questionada que contamina não só a forma como muitas empresas interpretam e usam a disciplina, marca também os mais graves enganos do BABoK.

    Por incrível que possa parecer, muitas empresas (algumas bem grandinhas) entendem que o analista de negócios é aquele cara que senta na frente de um usuário e anota tudo o que ele pedir. Não são analistas de negócios, são “tiradores de pedidos”. É fácil identificar empresas com tal grau de miopia: basta pegar a média de idade e de tempo de casa de seus analistas. Em outras (poucas) organizações tive a surpresa e felicidade de encontrar analistas com mais de 20 anos de casa². É nítida a mensagem que elas passam: “essas pessoas conhecem como pouquíssimas a organização, por isso elas têm melhores condições de analisar nosso negócio”.

    A atenção exclusiva ao incêndio nosso de cada dia – às operações insanas tocadas por times pequenos tentando segurar diversos sistemas bichados – anula qualquer benefício que a Análise de Negócios pode trazer.

    Como em toda “moda”, há aqueles que compram sem saber o que estão comprando. Nem sabem se precisam daquilo. “Como o vizinho da grama mais verde está usando analistas de negócios, então eu também quero”. Não são poucos os profissionais que me procuram reclamando que foram contratados como AN’s mas que só fazem o trabalho de analistas de sistemas ou de suporte. Na realidade, como já chorei por aqui, a atenção exclusiva ao “incêndio nosso de cada dia” – às operações insanas tocadas por times pequenos tentando segurar diversos sistemas bichados – anula qualquer benefício que a Análise de Negócios poderia trazer. Cheguei a pensar no seguinte título: “Parem de Contratar Analistas de Negócios!“. Mas acho que soaria alarmista demais… e incompleto. Quem dera o problema fosse “só” esse.

    A alta rotatividade de profissionais – tema que tenho debatido no GRAFFiTi (1,2) – é particularmente nociva quando atinge analistas de negócios. Sei de empresas que perderam mais da metade de seu time de AN’s em menos de dois anos. Desenvolver as habilidades técnicas de um AN é relativamente rápido e barato. O mesmo não pode ser dito sobre o Conhecimento do Negócio. Dependendo das experiências anteriores do analista – se já atuou naquele ramo de atividades, por exemplo – pode ser demorada e custosa a aquisição deste conhecimento. É difícil justificar a adoção de uma política de retenção específica para AN’s. Mas as empresas precisam entender que cada AN perdido (ou demitido) pode ser um desperdício que não se recupera em 12 meses.

    O que mais me angustia é a sensação de que boa parte dos participantes de meus treinamentos não poderá utilizar ou praticar muito do que aprendeu (ou que eu espero que ele tenha aprendido). Por quê? Porque a Análise de Negócios é apenas uma peça do complexo quebra-cabeças chamado “Desenvolvimento de Sistemas”. Como desenvolver requisitos de maneira iterativa e incremental se a empresa ainda está casada (através de muito papel passado) com o modelo Waterfall? Por isso algumas de minhas sugestões sempre são recebidas da mesma maneira: “meu ‘chefe’ (sic) deveria estar aqui ouvindo isso”. AN’s trabalhando em duplas? AN’s dedicados a apenas um ou no máximo dois projetos? Esquece…

    As empresas vivem aturdidas e um tanto perdidas. Significa dizer que seus objetivos nem sempre ou quase nunca são conhecidos (ou entendidos). Jogue na mesma cumbuca departamentos de TI que, de tanto não entregar, desaprenderam a dizer “não” ou perderam o direito de dizê-lo. Pronto: está criado o ambiente maluco de gente que acredita (na marra) que é possível atender e entregar 20 ou 10 projetos simultâneos.

    Mais triste é saber que a Boa Análise de Negócios, se bem aplicada, ajudaria a reduzir essa sensação de não saber o que fazer. Ajudaria tanto a área de TI quanto a organização como um todo. Acontece que são raríssimas as organizações que percebem a disciplina desta forma. As outras, mesmo que percebessem, agora veriam uma área repleta de “tiradores de pedidos” com rostos assustados.

    ?

    Não queria abrir a temporada de artigos em tom tão pessimista. Mas eu entendo que é minha obrigação publicar esse tipo de alerta. Espero já ter esgotado as principais notícias ruins acima. Porque sei que também é minha obrigação tentar dar algumas dicas que ajudem as organizações a combater o mau uso da Análise de Negócios. Ou, colocando de forma mais positiva, tentarei mostrar como é o bom uso da Análise de Negócios. Inté!

    Observações:

    1. Antes que atirem pedras: eu escrevi acima que a “análise de negócios, por definição, ataca exclusivamente ‘a parte mais difícil da construção de um software’”. Claro que estou falando da Análise de Negócios aplicada *exclusivamente* em projetos de software.
    2. Por favor, entenda que não estou defendendo que todo AN deve ter 10 ou 20 anos “de casa”. Apenas ilustrei um caso extremo e bastante específico. Por outro lado reforço sim que uma empresa que leve a sério a Análise de Negócios deve ter um bom número de analistas com considerável experiência naquela organização ou mercado. O que chamo de “considerável experiência”? No próximo artigo a gente conversa sobre isso.
    3. A imagem utilizada, “4“, foi liberada por rosmary com licença Creative Commons (by).

  • FDP – Sprint Review I

    No artigo que escrevi sobre “O Dono do Produto” prometi mostrar um pouco mais sobre a oficina “Formação de Donos de Produtos“. Vou fazê-lo em duas partes. Na próxima semana, logo após a estreia, publicarei uma prestação de contas com avaliações dos participantes. Hoje, neste primeiro Sprint Review, tentarei explicar a mecânica e filosofia do evento.

    .:.

    Um treinamento sobre Scrum ou fortemente baseado nele, como é o caso do FDP, deveria ser planejado, construído e apresentado como produto de um esforço guiado pelo próprio Scrum. Sem artimanhas ou enfeites baratos – ou até com alguns deles, como mostrarei na sequência – mas preocupando-se e ocupando-se com a experiência e a contínua melhoria do produto. Daí a necessidade de aparição aqui e das possíveis conversas que virão. Daí o fato da última atividade prevista, de um total de sete, ser uma revisão informal do próprio evento. As fichas de avaliação, por exigência do parceiro, seguirão existindo. Mas todos os participantes serão convidados para um Sprint Review no final do dia. Papo informal que deve escorregar para um etílico happy-hour. Mas é papo sério!

    Ainda são poucos os trabalhos, livros e eventos dirigidos especificamente para os Donos de Produtos (DP’s). Meu trabalho de exploração, além das experiências práticas, se baseou principalmente em dez títulos (apresentados no final deste artigo). Como adiantei no programa e em outros lugares, esta oficina está repleta de “licenças poéticas”. Explico: apesar de respeitar integralmente as diretrizes do Scrum e práticas mais aceitas (ou comuns), precisei adaptar e incluir várias coisinhas que são ignoradas pela gramática oficial do framework.

    Dediquei especial atenção ao momento inicial de um projeto. E incorporei elementos do framework APM (Agile Project Management) apresentado por Jim Highsmith no livro homônimo. As etapas de Visualização (Envision) e Especulação (Speculate) são cruciais para o DP. Mas elas são ignoradas em trabalhos clássicos sobre métodos ágeis ou mesmo sobre Scrum. A grande maioria deles parte de uma Visão já existente e não se preocupa em mostrar como ela é construída. Por isso dediquei dois “capítulos” do programa só para isso, “O Produto” e “Roadmaps, Releases, Sprints…”. Os participantes vão elaborar a Visão de um produto e derivar dela o Backlog do Produto. Das seis atividades práticas, quatro têm esta finalidade.

    Outro relativo “buraco negro” da gramática oficial do Scrum é a definição do Valor: a relevância de determinada funcionalidade, requisito, história ou tarefa para o negócio ou para a realização do produto. Incorporei parte do método que sugiro no FAN, mas o temperei com o algoritmo de definição de Pontos de Valor também sugerido por Jim Highsmith. Gostei tanto da brincadeira que adaptei o Planning Poker para o debate sobre o Valor de cada item do Backlog. Os participantes ganharão um jogo de cartas personalizado. Para a definição de pontos de valor utilizamos um conjunto menor da escala de Fibonacci. Mas, como já estava com a mão na massa mesmo, fiz um baralho que pode ser utilizado no Planning Poker tradicional.

    Aliás, o baralho é um dos “enfeites baratos” que citei acima. Aquilo que chamei de “Kit do DP Moderno” também é composto por fichas para anotação de Histórias de Usuários, um modelinho para especificação de Casos de Uso (mesmo utilizado no FAN), um Risque & Rabisque com um Quadro Scrum e, claro, post-it’s.

    Os enfeites, que pra falar a verdade não são assim tão baratos, evitam improvisos e perda de tempo. E são ferramentas que o DP utilizará em seu dia a dia. Mas ai de quem aparecer na oficina só para ganhar brinquedinhos.

    Não é fácil consolidar em um evento com sete horas de duração uma boa simulação da vida de um DP em um projeto. Só a primeira execução me dará uma boa noção da distribuição do tempo, mas eu estimo que teremos algo entre 2h30 e 3 horas de atividades práticas. É pouco, eu reconheço. E está aqui o principal ponto de extensão (para uma possível versão com carga horária maior).

    Já sei que estamos com sala praticamente lotada (40+ inscritos). Levarei também alguns convidados – gente que não pisa em cascas de ovos quando vai me criticar. É um feedback mais que necessário para um evento totalmente novo. Resta torcer para que eu não tenha cometido muitos erros. Na próxima semana eu conto o resultado. Inté!

    .:.

    Os Principais Livros Utilizados:

    • Agile Project Management – Second Edition
      Jim Highsmith | Addison-Wesley (2010)
    • Agile Product Management with Scrum
      Roman Pichler | Addison-Wesley (2010)
    • Kanban e Scrum – Obtendo o Melhor de Ambos
      Henrik Knibert e Mattias Skarin | InfoQ (2009)
    • Succeeding with Agile
      Mike Cohn | Addison-Wesley (2010)
    • Agile Estimating and Planning
      Mike Cohn | Prentice-Hall (2006)
    • Coaching Agile Teams
      Lyssa Adkins | Addison-Wesley (2010)
    • Subject to Change
      Peter Merholz et al | O’Reilly (2008)
    • REWORK
      Jason Fried e David H. Hansson | Crown Business (2010)
    • Sistema Toyota de Desenvolvimento de Produtos
      James M. Morgan e Jeffrey K. Liker | Bookman (2006)

    A imagem utilizada neste artigo, “Walking in Circles“, é de HikingArtist.com.

  • Museu de Grandes Novidades

    Finalmente encerro a série de artigos onde tentei transcrever a palestra “O Futuro Não é Mais como Era Antigamente“. Este trabalho foi desenvolvido para o Seminário Engenharia de Software promovido pela Tempo Real Eventos. Para minha surpresa ele foi encomendado por algumas empresas, o que resultará em sua promoção para o status de Produto. Não do finito, mas de seu co-irmão que está brotando das cinzas com renovados propósitos. Assunto para outra hora.

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

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

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

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

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

    .:.

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

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

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

    .:.

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

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

  • O Dono do Produto

    Tão ou mais complicado do que criar o produto – em meu caso, um treinamento – será o trabalho de ‘criar’ uma freguesia para ele. Sei que o FDP¹(Formação de Donos de Produtos) atrairá gente letrada e com experiência em projetos de software. Ok. Entendo que a maioria delas não vai desempenhar o papel e sim apoiar e orientar os profissionais que o farão. O treinamento deve contemplar esta modalidade de uso e o faz². Mas eu também sei que o evento não será legal se não contar com “não-letrados”, gente que não seja de TI e sim do negócio. Este treinamento foi desenhado principalmente para eles, nossos (frequentemente) mal compreendidos e (invariavelmente) mal tratados usuários. Ok, sei que não vou atrai-los com demagogia barata. Antes de mais nada, é preciso explicar melhor quem é esse tal de Dono do Produto (ou Product Owner), o que ele faz, como, porque etc. É o que tento com este artigo.

    .:.

    O dono do produto é O Cara. O cara que deve gerenciar o escopo de um projeto e garantir que o produto criado realmente gerará valor para o negócio. Do glossário oficial não consta o termo “escopo do projeto” e sim “Product Backlog”. Aqui, para desagradar a gregos e troianos, vamos chamar esse trem de Pauta. Antes que você tenhas ideias criativas e/ou nocivas, retomemos o fio da meada. O dono do produto, como o próprio nome confessa, tem a palavra final sobre funcionalidades, características e formato da obra gerada pelo projeto. E, acima de tudo, ele deve garantir que o produto atenda os objetivos pré-estabelecidos, ou seja, que ele gere valor. Peço sua atenção para o termo “pré-estabelecidos”. Obrigado. Já já conversaremos sobre isso.

    O dono do produto (DP daqui pra frente) deve ser do negócio. Aqui temos duas possibilidades. Se o produto destina-se para uso interno, então o DP será um representante de todos os usuários. Dele será exigido domínio do problema que o produto ajudará a resolver. Ele será escolhido não só pelo (amplo e profundo) conhecimento que detém, mas também pelo bom relacionamento com todas as outras partes interessadas. Deve ser reconhecido e merecedor da autonomia que receberá.

    Quando o produto é dirigido para o público externo, então o DP pode ser o próprio gerente do produto, quando existir, ou então um representante da área de marketing da empresa. É interessante notar que neste contexto o DP, na maioria das vezes, não cuidará de apenas um projeto mas de todo o ciclo de vida de um produto. Desconfio que seja uma possibilidade pouco aproveitada em solo tupiniquim.

    Do DP espera-se autoridade e autonomia em todas as decisões sobre o escopo do produto e as prioridades do projeto. Dele será cobrada disponibilidade para atender os demais membros da equipe do projeto. Recomenda-se que ele dedique, no mínimo, uma hora por dia ao projeto.

    Um DP por Projeto – Um Projeto por DP

    Por óbvio que pareça, é preciso dizer que cada projeto, cada produto tem um e apenas um dono. Invertendo a equação pisamos em terreno não tão óbvio: um DP deveria cuidar de apenas um projeto. Dois, no máximo. E desde que sejam pequenos. As empresas de Pindorama têm a péssima mania de jogar em seus profissionais uma carga de trabalho exagerada. Os profissionais de Pindorama têm o péssimo costume de tentar equilibrar em seus ombros uma carga de trabalho muito além de sua capacidade de entrega. Daí a relevância deste parágrafo.

    Um ponto não tão claro que só agora ganha a devida relevância é a solidão do DP. Segundo algumas interpretações, esta seria função de uma só pessoa. Uma visão mais prática e pragmática nos abre outras possibilidades. O DP pode ser uma pessoa sem disponibilidade para entrevistar n usuários, detalhar n cenários, responder n dúvidas do time etc. Pode ser muito n para uma pessoa só. Por isso autores como Jim Highsmith e Roman Pichler sugerem a existência ou necessidade de um Time do Produto³. Este time, como já foi apresentado aqui no finito, pode ser composto por analistas de negócios, consultores, especialistas no domínio e outros usuários ou partes interessadas. Cabe ao DP manifestar a necessidade de apoio. E ele não pode ser constrangido por dogmas bobos. Ele é o *dono* e, como tal, deve saber do que precisa para fazer seu trabalho bem feito.

    Colocado e Falante

    De boa que é, merece repeteco uma afirmação que fiz em artigo recente: “é o olho do dono que engorda o boi”. Colocando de outra forma: não há DP distante ou remoto. No mundo ideal ele ocupa a mesma sala dos outros integrantes do time. No mundo real ele deve visitar esta sala pelo menos uma vez por dia. E permanecer lá, à disposição e sem interrupções (celular desligado, please!), por pelo menos uma hora.

    Quando apostamos na figura de um DP estamos fazendo uma aposta bem maior: no valor do conhecimento tácito, na eficácia das conversas. Ou, como colocou um freguês, “estamos trocando 10 páginas de documentação por 10 minutos de prosa”. Se o DP não tiver disponibilidade e não for onde o time está não há conversas. Se elas não ocorrem então perdemos a aposta. Simples assim.

    O Passo Esquecido

    Este é o título de um dos capítulos do FAN. Descreve aquele fundamental e mal tratado momento que ocorre entre o entendimento de um problema e o desenvolvimento de sua solução. Aqui ele ganha escopo mais amplo. Trabalhos clássicos que ajudaram a criar e definir o papel do DP – como “Agile Project Management with Scrum“, de Ken Schwaber (Microsoft Press, 2004) – partem de uma visão do produto já definida. Sim, agora estou falando sobre aqueles “objetivos pré-estabelecidos” para os quais chamei sua atenção lá no início do artigo. É razoável supor que o DP participará da criação da visão do produto do qual é *dono*, não? Não me pergunte porque aqueles trabalhos ignoram este momento. Eu não saberia responder. Não sem uma considerável dose de veneno.

    Os conhecimentos do DP são mais exigidos nos momentos iniciais do projeto. Será um sinal de sanidade do projeto a decrescente dependência dos outros membros do time em relação ao DP. Significará que o conhecimento realmente se espalhou pela equipe. Todos passarão a demonstrar de razoável a impecável domínio do problema que tentam resolver. O que não pode significar, de forma alguma, o afastamento ou distanciamento do DP. Ele sempre terá responsabilidade pela manutenção e priorização da Pauta do projeto, do primeiro ao último dia do projeto. E, claro, é ele quem aceita ou não o resultado de cada iteração (ou sprint).

    Os Passos Executados

    Como já vimos, o DP tem duas grandes responsabilidades em um projeto: i) Definir a Visão do Produto e respectiva Pauta – funcionalidades e características de um produto. Fica subentendido aqui que a Pauta é formada por itens devidamente priorizados e que a priorização também é responsabilidade exclusiva do DP; e ii) Garantir que o produto em gestação está definitivamente a caminho de realizar os objetivos do negócio. Cada responsabilidade compreende um conjunto de atividades que fica a cargo do DP.

    A Pauta (lembre-se, o Product Backlog segundo gramáticas oficiais) deriva da Visão do Produto. A criação de ambas é responsabilidade do DP. Espera-se que a Visão, normalmente de alto nível (2km X 2cm…), seja estável durante todo o projeto. Ela explica funcionalidades e características gerais do produto, além de oficializar restrições (escopo, prazos e custos). A visão deve mostrar, principalmente, como o produto gerará valor para o negócio.

    Já a Pauta será desenvolvida de maneira iterativa e incremental. O DP e o time se preocuparão em detalhar apenas os itens necessários no horizonte pré-fixado (da iteração ou sprint). Uma iteração geralmente dura duas ou quatro semanas. Projetos estressados (complexos em sua porção negócio ou tecnologia ou ambas) devem utilizar a primeira opção. Projetos tranquilos se contentam com a calmaria dos ciclos de trinta dias. Espera-se que o DP (e seu opcional Time de Produto) esteja trabalhando no entendimento e detalhamento dos itens que comporão a pauta da iteração imediatamente posterior. Particularidades do projeto, da organização ou a velocidade do time podem pedir que o DP trabalhe com duas ou até três iterações de antecedência. É importante notar que isso não pode significar, em hipótese nenhuma, o não atendimento do time na iteração atual – dirimindo dúvidas e verificando a realização do produto, principalmente.

    Praticamente todos os proponentes de métodos que utilizam a figura do DP sugerem que os itens que compõem a Pauta sejam redigidos na forma de Histórias de Usuários (ou User Stories). Este padrão “força” a realização de conversas. É importante que o DP saiba que existem alternativas (casos de uso, por exemplo) e que ele deve optar pelo formato que lhe deixe mais confortável. Algumas organizações precisam de um pouco mais de formalidade (aka Documentação), por razões mil (sendo que 989 são bullshitagem/burocracia pura). Dependendo de suas exigências, parte do time pode ser destacado para atendê-las. Colocando de outra maneira: da porta (da sala do time de projetos) pra fora é oferecida uma documentação mais formal; Da porta para dentro o time pode optar por um padrão de conversas mais informal e leve. Um bom DP saberá lidar com as duas modalidades de comunicação.

    Em inglês fala-se que o DP é responsável por “grooming the product backlog”. Em tradução literal o verbo groom significa preparar, arrumar (ou adestrar cavalos). Acho que, em português, devemos nos contentar com o termo “manutenção da Pauta”. É crucial que o DP saiba que a Pauta é um (documento? artefato? ferramenta? – são tantos termos detestados, tantas emoções desperdiçadas…) Começando de novo: É crucial que o DP saiba que a Pauta é um trem vivo – um negócio que exigirá sua atenção diária. Itens da Pauta (requisitos, histórias ou casos ou…) ganharão ou perderão prioridade; mudanças surgirão (e não serão tratadas como más notícias); erros serão cometidos (e não significarão pena de morte aos seus causadores). Se o DP não administrar (!) diariamente todas as ocorrências as quais estão sujeitas a sua Pauta, me diga: que p%&R@ o cara está fazendo lá?

    Aos Donos com Carinho

    Por tudo isso e mais um tanto é que se diz que a função do DP é a mais crítica e complexa em um projeto guiado pelo framework Scrum. A vida de um DP não é nada fácil. Mas pode ser muito gratificante e edificante (Houaiss: que conduz à virtude). Quem já entregou projetos e viu os olhos dos usuários brilharem (e seus respectivos negócios lucrarem) sabe do que estou falando. A entrega de um produto pelo DP guarda uma satisfação ainda maior, exatamente porque foi ele quem desenhou e de certa maneira conduziu aquela realização. O bom DP sabe que o sucesso deve ser compartilhado por todos que participaram do projeto. Mas lá no fundo ele guarda algo que não confessará: a impressão digital mais notável deixada no produto é sua. Para o bem ou para o mal.

    .:.

    Observações:

    1. Foi em um belo boteco de Copacabana, bem servido de chopps, que consegui convencer meu parceiro de que a sigla FDP é filhadaputamente excepcional para uma oficina que se propõe a Formar Donos de Produtos. Além do apelo pop, serve também para peneirar e manter chatos ultrasensíveis bem distantes. Quem não güenta o leve tranco d’uma brincadeira boba demonstra não possuir um requisito mínimo que todo DP deve apresentar: bom humor!
    2. Faço questão de frisar na divulgação do FDP que todo o material didático utilizado está liberado para uso. As restrições são mínimas: i) Agradeça publicamente o autor; ii) Compartilhe o material utilizando a mesma licença; e iii) Se você pretende ganhar algum $ com o material, combine antes a comissão que irá me pagar. Preciso salientar isso porque sei que muitos vão querer replicar o treinamento em suas empresas. Em breve vou mostrar aqui no finito alguns dos itens que vão compor aquilo que estou chamando de “Kit do PO moderno” e que você poderá reutilizar.
    3. De longe já são os dois livros mais citados aqui no finito: “Agile Project Management – Second Edition“, de Jim Highsmith (Addison-Wesley, 2010) e “Agile Product Management with Scrum“, de Roman Pichler (Addison-Wesley, 2010). Se eu seguir referenciando-os assim periga eu te dispensar de estudá-los. Hehe.. brincadeira.
    4. Aproveitei o artigo para experimentar mais um pouquinho o método do Pensamento Visual. A sequência utilizada para apresentação do DP – quem, quanto, onde, quando, como e porque – obedece as regrinhas dos 6 W’s propostas por Dan Roam em “The Back of the Napkin” (Portfolio, 2008).
    5. A foto utilizada no topo, “Home Market: 1941 in Worthington, Ohio“, é do Don O’Brien.

    Faltou dizer:

    Caramba, ainda estás por aqui? Este artigo está com o dobro do tamanho padrão (2200 palavras!). Mas faltou dizer… Que o DP não é uma exclusividade dos projetos que são guiados pelo framework Scrum. Aliás, não precisa ser uma exclusividade. Ele é uma adaptação, por exemplo, do Engenheiro-Chefe utilizado pela Toyota há décadas. Pode ser visto também como uma exótica e criativa remixagem das funções do gerente de produtos e do gerente de projetos.

    É claro que, apesar das “licenças poéticas”, baseio boa parte de minhas sugestões no DP conforme definido na gramática oficial do Scrum. Mas preciso dizer que a idéia do DP, de boa que é, não deve ficar limitada ao uso do Scrum. Pronto, disse. Inté!

  • Scrum kanbanbanban balangandã

    Conclusão do papo iniciado em “Scrum praticundum burungundum“¹. Naquela primeira parte tentei ilustrar a crescente adoção do Scrum em Pindorama. O texto de hoje se ocupará dos principais problemas enfrentados, possíveis causas e soluções. É necessário lembrar que minhas conclusões não estão baseadas em uma pesquisa estruturada. Elas são fruto de conversas e consultas informais.

    .:.

    O Scrum, pequeno e simples que é, não deveria ter significados diferentes para as pessoas. Quando alguém me diz que está adotando o Scrum, minha primeira pergunta é: “Scrum e?…” Muitos interlocutores não entendem a questão. Ignoram o fato de o Scrum orientar apenas o processo de gestão de um projeto. Uma parte deles está de fato adotando derivações ou até mesmo o XisPê (eXtreme Programming). Outra parte descobre depois de um tempinho que “tá faltando um monte de definição”. Alguns deixam que a equipe técnica selecione suas práticas favoritas ou que trabalhem como os Allman Brothers, em puros e longuíssimos improvisos. Nada disso se configura um problema se combinado previamente. No entanto, no mínimo para não falar besteiras, é bom saber o que vem do Scrum e o que foi importado de outros lugares.

    Um dos exemplos de “práticas importadas” são as User Stories (ou histórias de usuários). O Scrum não diz como deve ser explicitado o backlog do produto nem como devem ser redigidas as necessidades dos usuários. Autores como Jim Highsmith, Mike Cohn e Roman Pichler² manifestam sua preferência pelo padrão User Story. Sua natureza evolutiva “combina” melhor com o Scrum e com métodos ágeis em geral. Acontece que muitos acreditam que esta seria a única maneira de registrar os requisitos do negócio ou dos usuários, o que não é verdadeiro.

    Mas o que realmente importa é a necessidade de *completar* o Scrum com práticas de engenharia. E aqui deveríamos ver variações mil. Por quê? Oras, organizações, equipes e projetos têm necessidades e restrições bastante específicas. O chapéu Scrum, largo e leve que é, pode caber em qualquer cabeça. Mas seu complemento demanda cuidado. Um zelo que tem faltado em algumas implementações.

    E por falar em implementação. Qual a melhor estratégia? Implantar o Scrum em toda a organização em uma tacada só ou, como um bom e legítimo mineiro, promover uma adoção gradual (comendo quieto e pelas beiradas)? Sou mineiro. E quanto mais conservador ou desestruturado for o ambiente, mais lento é o ritmo que recomendo. Aposto nos hábitos e gostos que são desenvolvidos de maneira natural e orgânica, sem imposições. Deveríamos acreditar mais no potencial das boas ideias que são incorporadas – aprendidas de verdade – através de bons exemplos. Mesmo em organizações que precisam ou merecem radicais safanões, é complicada a implantação do tipo big-bang. Só o exorcismo do espírito Waterfall (cascata), que assombra por anos ou décadas, já é um trabalho e tanto. Representa uma mudança que raríssimas vezes pode ser classificada como simples ou sem traumas. Resumindo: é mais fácil adotar o Scrum de maneira gradual. Poucos casos, como o da Salesforce.com documentado por Mike Cohn em “Succeeding with Agile” (Addison-Wesley, 2010), justificam outra estratégia.

    E por falar em cascata. Não é que tem gente que fala que tá usando o Scrum mas manda um analista lá no cliente para “levantar *todos* os requisitos”? Gente que depois compila isso tudo numa proposta com escopo, preço e prazo fechados? Isso sim pode ser julgado como pecado mortal – um crime premeditado. Mas, guarda o fósforo menino! Não é questão de jogar hereges na fogueira. Uma das perguntas mais frequentes que ouço é exatamente sobre isso: como um prestador de serviços vende um projeto baseado no Scrum? O assunto é tão espinhoso e controverso que merecerá um artigo (ou série) só para ele.

    Outro ponto que facilmente se converte em discussão é o autogerenciamento pelo time do projeto. Existem duas interpretações principais: i) o time cuida de tudo e decide tudo; ii) “autogerenciamento não significa falta de liderança mas um estilo diferente de liderança”, escreveu Jim Highsmith na segunda edição de “Agile Project Management“ (Addison-Wesley, 2010). Sou ignorante pra burro (hehe) e conheço pouquíssimos casos da história da humanidade que comprovem a viabilidade da primeira opção. Pra citar assim, de cabeça, só o caso da Democracia Corinthiana, que durou cerca de dois anos (1982-83). Ainda assim, garanto que a leitura da última frase lhe trouxe lembranças do Dr. Sócrates, Casagrande e Vladimir.

    Henrik Kniberg e Mattias Skarin colocam em “Scrum e Kanban – Obtendo o Melhor de Ambos” (InfoQ, 2009) que “o Scrum é suficientemente minimalista tal como é, se você remover coisas e continuar chamando isso de Scrum a palavra ficará sem sentido e confusa”. Porém, nada nos impede de “colocar coisas” no Scrum. Parece ser o que fez Jim Highsmith no livro  já citado. Ele coloca a figura de um líder de projetos. Estranhamente, sem usar o termo Scrum. Sei lá se por respeito ou qualquer outro motivo. Também precisamos considerar um aspecto cultural: o brasileiro parece gostar de líderes e de ser liderado. Não é o caso de discutir se isso se dá por preguiça, submissão ou letargia (que é a preguiça chique). Ou é (o caso de discutir isso)? Sei lá.

    Outra pergunta de meu informal check-list: “Você confia em seu PO? Ele tem a palavra final sobre o escopo do projeto?” Espanta o número de vezes que ouço um “não” como resposta. Um “não” que algumas vezes nem tem noção do tamanho de engano que representa. Se há um termo muito feliz³ criado no Scrum é Product Owner (PO) – *Dono do Produto*. “Dono” dispensa explicações. Quando um dono não tem palavra final então ele não é dono de nada. Não existe meio dono.

    Existe um dito popular que ensina que é “o olho do dono que engorda o boi”. Adaptado para nosso caso, podemos dizer que é “o olho do PO que garante a entrega do produto”. E o que dizer dos PO’s indisponíveis, daqueles que não têm tempo para olhar o boi?

    E que dizer dos PO’s que não são do negócio? O que dizer dos PO’s?

    Outro dia eu digo. Inté!

    .:.

    Observações:

    1. Sigo firme na tradição dos títulos ridículos. Mas desta vez escondi ali uma provocação. Se surtiu efeito eu não vi. Chamei o artigo anterior de “Scrum praticundum burugundum”. A rima (!) só é possível se a pronúncia estiver errada. É  que eu ouço “ScrUm” com mais frequência que  “ScrÃm” (ou “Scrammm”). Fecho a provocação (mas não a tradição dos títulos ridículos) com o “Scrum kanbanbanban balangandã” de hoje.
      E não, (ainda) não tenho a intenção ou condição de falar sobre o Kanban. Dele só aproveitei a rima mesmo. Se o tema lhe interessa, aquele livro aberto e gratuito citado é uma boa dica.
    2. No próprio texto já referenciei os trabalhos de Highsmith e Cohn. Faltou citar o livro do Roman Pichler, “Agile Product Management with Scrum” (Addison-Wesley, 2010). Um dos poucos dirigidos especificamente para PO’s.
    3. Não sei se você sabe, mas os termos criados para o Scrum são intencionalmente “infelizes” ou “ruins”. Ruins no sentido de serem bastante diferentes daqueles utilizados tradicionalmente: Product Backlog, ScrumMaster, Product Owner, Sprint Backlog… A sacada do vocabulário original e radical é boa porque evita confusões. Bom, deveria evitá-las…
    4. “Battle against Time”, a bela foto que ilustra o artigo, é do Joakim Jardenberg.

  • Identificando Partes Interessadas, Interesseiras, Indiferentes e Encrenqueiras

    Ao seguir o método do Pensamento Visual, a segunda¹ questão que o analista de negócios deve responder é “Quem / O quê?”. A pergunta é repetida n vezes se o analista trabalha de forma iterativa e incremental. Mas desde as primeiras ocorrências ele deve se preocupar em identificar todas as partes interessadas – as pessoas que terão algum tipo de relacionamento com o projeto ou seu produto. Este artigo é sobre o processo de identificação e ferramentas que podem ajudar analistas e equipe a gerenciar o relacionamento com clientes e usuários.

    Um dos problemas mais frequentes e irritantes com requisitos é a sua não estruturação. Eles são listados de maneira ad hoc em documentos de texto, cartões ou planilhas eletrônicas e carecem de mínimos atributos que os qualifiquem. Uma das informações essenciais para a contextualização de um requisito é sua origem, sua fonte. Quem pediu? É claro que não basta registrar o nome da pessoa e sua posição na empresa. Por isso a correta identificação de todas as partes interessadas de um projeto é tão cara para a Análise de Negócios.

    Cara e complexa, porque a identificação não será produto da aplicação de um simples questionário ou check-list. A equipe, particularmente o analista de negócios, dependerá de seu poder de observação para identificar, avaliar e classificar cada pessoa envolvida com o projeto. Algumas informações serão fornecidas naturalmente, logo no primeiro momento. Outras aparecerão com o tempo, através da convivência (atenta e atenciosa). O mínimo que se espera de um Mapa de Partes Interessadas² é uma tabela com os seguintes atributos:

    • Papel / Função na organização;
    • Papel no projeto. Podemos completar esta informação com a Matriz RACI sugerida no BABoK:
      • esponsável – executa o trabalho;
      • ccountable – tem a última palavra (só deveria existir uma pessoa com tal poder);
      • onsultado – deve ser ouvido pela equipe;
      • nformado – deve ser comunicado sobre o projeto e algumas decisões.
    • Impacto que o projeto terá no dia a dia da pessoa. Pode ou deve ser simples como Alto, Médio, Pequeno e Nenhum;
    • Influência que a parte interessada exercerá no projeto. Pode usar mesma classificação sugerida acima;
    • Receptividade ao projeto: Contrário, Indiferente, Favorável ou Entusiasmado;
    • Razões para a resistência ou apoio.

    As três primeiras informações podem ser obtidas logo no primeiro momento. Elas devem compor aquele grande mapa que chamo de ‘fotografia com 2km de extensão e 2cm de profundidade’. As outras três informações – Influência, Receptividade e Razões – só surgirão com razoável confiabilidade no decorrer do projeto.

    É interessante notar que o Mapa das Partes Interessadas, quando completado com os últimos três atributos, é um dos únicos artefatos do tipo ‘caixa preta’ de uma equipe de projetos. Ou seja, ele deve ser confidencial. Não interessa a mais ninguém as percepções e cuidados que a equipe tem com cada pessoa envolvida.

    Sim, o mapa servirá para que a equipe saiba com quem está falando e evite riscos de mal entendidos ou até mesmo de conflitos. Sejamos mais visuais. A matriz ao lado sintetiza três informações fundamentais para que uma equipe gerencie seu relacionamento com as partes interessadas. O eixo X indica o Impacto que o projeto terá na vida das pessoas envolvidas. No eixo Y demonstramos a Influência que cada pessoa terá sobre o projeto. E quatro ícones ilustram a Receptividade de cada um ao projeto.

    O gráfico indica, por exemplo, que Joaquim e Carlão são contrários ao projeto. Pode ser por resistência às mudanças ou gosto de ser encrenqueiro. Joaquim pode exercer forte influência no projeto, o que o torna fonte de potenciais problemas. Apesar do pequeno impacto que o projeto terá em seu cotidiano. A equipe deve ‘pisar em cascas de ovos’ quando se relacionar com ele. Carlão, por outro lado, não tem tanta influência assim. Mas terá sua rotina muito impactada pelo projeto. Merece especial zelo quando entregas forem realizadas.

    Três pessoas, José, Dedé e Terezinha, são favoráveis ao projeto. José será muito impactado e terá forte influência no projeto. Dedé será muito impactado, mas não apitará nada. E o apoio da Terezinha pode ter efeito moral, mas nenhum benefício prático: ela tem muito pouco a ver com o babado. Quase como o Euclides, que se mostra indiferente. O que não fará muita diferença. Já a indiferença do Tonho deve ser percebida pela equipe com preocupação. Afinal, ele pode exercer forte influência e será muito impactado. Qual a razão de sua indiferença? O que pode motivá-lo? São questões que deveriam preocupar a equipe, particularmente o gerente do projeto e os analistas de negócios.

    Assim como Magda e João, entusiasmados com o projeto. Magda tem pouca influência, mas o João é relativamente influente. A equipe deve tratá-los como aliados e fazer de tudo para não desagradá-los. Afinal, seu entusiasmo pode contagiar outras partes interessadas. O que nos leva para outra questão: quais são as relações entre os envolvidos? Quem influencia quem? Se o número de pessoas envolvidas no projeto for relativamente grande, talvez se justifique a elaboração de um Mapa de Relacionamentos, como mostra o diagrama ao lado. Nas linhas indicamos o poder de influência de cada pessoa sobre as demais. Ele pode ser: Forte, Médio, Pequeno ou inexistente (“-“).  Vemos, por exemplo, que Euclides e Terezinha não influenciam ninguém. E que a Maria, que não é influenciada por ninguém, tem poder sobre todo mundo. Então ela não pode permanecer tão indiferente (alienada) em relação ao projeto, certo?

    Carlão e Joaquim são contrários ao projeto. É importante que a equipe saiba ‘blindar’ de alguma maneira todas as pessoas que estão em seu círculo de influência. Deve preocupar, principalmente, que Magda e Dedé não se deixem levar pelo pessimismo ou possível jogo sujo do Carlão.

    É claro que estou brincando com a simplicidade. Relações humanas são de uma complexidade absurda e nunca serão resumidas em uma ou duas matrizes. Mas isso não pode significar que a equipe se isente de sua responsabilidade de gerenciar o relacionamento com todas as partes interessadas. É sabido que boa parte dos problemas que ocorrem em projetos derivam de deficiências na comunicação e conflitos de interesses. As ferramentas aqui sugeridas podem ajudar equipes a cuidar melhor de suas relações com clientes e usuários. Faz bem ter a resposta na ponta da língua toda vez que alguém perguntar: Você sabe com quem está falando?

    .:.

    QuiProQuó

    Aproveitando os exemplos acima, alguns desafios:

    1. Das dez pessoas apresentadas qual seria o melhor candidato para a função de Dono do Produto (Product Owner) caso o projeto seja guiado pelo framework Scrum? Por quê?
    2. Há um conflito de informações entre as duas matrizes apresentadas. Qual é o conflito e qual a possível razão da inconsistência?
    3. Qual diagrama pode ilustrar e complementar a Matriz de Relacionamentos?
    4. Quais quadrantes podem significar requisitos mais ricos? Por quê?
    5. Seria a Magda carente ou influenciável demais?
    6. O que é que o Euclides tá fazendo no projeto?!?

    Observações:

    1. No método original, “Quem / O quê” é a primeira e não a segunda pergunta. Na adaptação que fiz para a Análise de Negócios transportei “Por que” para o início do questionário. Quer saber por quê?
    2. Mapa de Partes Interessadas?!? Pois é, o nome é ridículo. Sugestões?
    3. “Key-People” é o cartoon do HikingArtist.com utilizado hoje.