finito

Categoria: Enxuto & Ágil

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

  • Scrum praticundum burungundum

    A crescente adoção do Scrum por empresas tupiniquins chega a ser surpreendente. Seu uso por pequenas e médias empresas da indústria digital é facilmente justificável. Mas quando vemos grandes negócios – de áreas não relacionadas diretamente com TI – adotando aquele framework ágil para gerenciamento de projetos, devemos entender que algo importante está acontecendo.

    Este artigo é o primeiro de uma pequena série que tem a intenção de ilustrar um pouco o estágio atual de uso do Scrum no Brasil. Nesta primeira parte, um breve panorama – uma fotografia com 2km de extensão por 2cm de profundidade. Na sequência escreverei sobre os probleminhas que tem sido reportados com mais frequência em relação ao uso do Scrum. Questões relativamente pequenas, mas com potencial para batizar o mais novo integrante da família das boas ideias que fracassaram.

    .:.

    O Scrum, na forma como o conhecemos hoje, está quase completando 20 anos de existência. Partiu de ideias e experiências da dupla Takeuchi e Nonaka¹. Mas adquiriu corpo e alma nos trabalhos e escritos pioneiros de Ken Schwaber e Jeff Sutherland². Ganhou trilha e impulso para o mainstream com a publicação do Manifesto Ágil. Dentre as diversas propostas de métodos e processos ágeis, o Scrum se destaca por ser o único que se preocupa exclusivamente com os aspectos gerenciais de um projeto. Por não incorporar nenhuma prática de engenharia, o Scrum possibilita sua combinação com diversas outras propostas, do RUP (Rational Unified Process) ao XisPê (eXtreme Programming), passando pela galáxia que existe entre eles.

    O que vou colocar no próximo parágrafo não tem a força de uma pesquisa estruturada. Por outro lado, a população amostral é suficientemente grande (2000+) para garantir que eu não esteja viajando ou forçando a barra.

    Nas primeiras turmas do FAN, no já longínquo 2007, apenas 5% dos participantes, em média, levantavam a mão quando eu perguntava: “Quem *conhece* o Scrum?” Na última edição do evento em São Paulo, no final de setembro, mais de metade da sala respondeu positivamente. E esta é a média de todas as turmas que encontrei neste ano, em São Paulo, Belo Horizonte e outras praças. Claro que não posso concluir que a adoção do Scrum no Brasil aumentou 1000% em três anos. Mas, pensando bem, desconfio que foi algo com tal magnitude que aconteceu. Aliás, está acontecendo.

    Testemunhei algo parecido, em menor escala, entre os idos de 1998 e 2000 e pedrinha. A moda e elixir para todos os males dos projetos de software de então era o RUP. Foi adotado por grandes empresas, como Petrobras e BankBoston, e estava nas bocas e agendas de todo mundo minimamente antenado com a área. Algum tempo depois, em empresas diferentes e distantes, vi reações parecidas: “Não fala de RUP que me dá urticárias!” Não vale o espaço e muito menos o seu tempo o diagnóstico sobre o que aconteceu com aquele incomensurável corpo de boas ideias (pobres estratégias e falsos evangelistas).
    {Mas merece nosso tempo a preocupação de que algo semelhante aconteça com o Scrum. Neste artigo, publicado em setembro/2009, eu falo um pouco sobre isso.}

    Antes, porém, vale a pena ilustrar um pouco mais a crescente adoção do leve processo de gestão que sugere a divisão das partes interessadas entre “porcos” e “galinhas”. Como já coloquei, não é difícil justificar o uso do Scrum por pequenas e médias empresas prestadoras de serviços de TI. Elas não puderam saborear adequadamente o RUP porque ele era um produto (leia-se: seu uso significava, na maioria das vezes, um pesado investimento em ferramentas que ‘viabilizariam’ o uso do método). Agora, elas ganharam um método que não cobra royalties nem força o uso de (dispendiosas) ferramentas. E, talvez um ponto mais importante: elas ganharam um método cuja implantação é relativamente fácil, rápida e barata. Ou seja, um sonho.

    Surpreendente é o fato de algumas grandes empresas também apostarem no Scrum. Inclusive empresas de ramos que têm a péssima fama de serem conservadoras e burocráticas – pelo menos no que se refere a TI – como bancos e seguradoras. Entre tudo o que é sinalizado em movimentações deste tipo, parece nítida uma grande insatisfação com processos, padrões e metodologias utilizados até então.

    No primeiro semestre apresentei duas palestras para um dos maiores bancos do Brasil. Fui convidado para “provocar” e apresentar “tendências”. A segunda palestra foi motivada pelo “burburinho” gerado na primeira. E foi dirigida para gerentes e afins. Ao justificar o encontro, um dos principais executivos da área disse: “Precisamos de novas ideias”. Em outro momento, nas entrelinhas de uma nova intervenção do mesmo executivo, havia uma mensagem bem direta: “Não dá pra continuar trabalhando da forma como fazemos hoje”.

    Há tempos, esta e diversas outras empresas acreditam que os problemas de comunicação entre áreas de negócios e TI podem ser combatidos com mais documentos, assinaturas, change requests e coisas do tipo. Ao final do evento aquele mesmo executivo brincou concluindo que “cada dez minutos de boa conversa pode eliminar a necessidade de dez páginas de papel”. Para todas as empresas que chegaram neste ponto, e não são poucas³, o Scrum apresenta possibilidades maravilhosas. É difícil ignorar o canto da sereia que cobra tão pouco pelo muito que promete.

    O movimento no mundo dos negócios tem reflexos no universo da educação. Agora, além dos tradicionais cursos relacionados com Scrum e similares, passaremos a ver apostas mais ambiciosas e, de certa forma, mais abrangentes. Um curso de extensão da Universidade Federal de São Carlos (UFSCar), que neste ano fez uma experiência com um método “genérico” baseado no modelo iterativo e incremental, adotará o Scrum para a turma de 2011. Os Donos dos Produtos (Product Owners, ou simplesmente PO’s) já foram nomeados – são funcionários da Universidade – e os projetos já foram definidos. Assim como a grade com a distribuição das disciplinas. É o tipo de experiência com potencial para espalhar ainda mais a “novidade” Scrum. Realizada por uma entidade com o nome e peso da UFSCar, pode significar um impacto ainda maior.

    .:.

    Observações:

    1. Desconfio que Takeuchi e Nonaka nem prestem muita atenção em sua distante “criatura”. Na realidade eles apenas inspiraram a criação do Scrum. O que eles devem realmente lamentar é o fato de outras grandes descobertas e experiências suas não ganharem o impulso “pop” que o Scrum experimenta hoje. A dupla – que digo parecer dupla sertaneja ‘de raiz’ de Piracicaba – publicou alguns dos trabalhos mais relevantes da mal interpretada disciplina conhecida como Gestão do Conhecimento. Vou citar três: “Gestão do Conhecimento“, compilação de artigos organizada pelos dois (Bookman, 2008); “Theory of Organizational Knowledge Creation” e “Reflection on Knowledge Management from Japan“, artigos publicados na obrigatória coletânea “Knowledge Management – Classic and Contemporary Works” (MIT Press, 2000).
    2. De Ken Schwaber: “Agile Project Management with Scrum” (MS Press, 2004) e “Enterprise and Scrum” (MS Press, 2007).
      De Jeff Sutherland: Scrum Log (desde 2002).
    3. Essa coisa que diz que escrever mais é a solução gera situações cômicas. Em uma turma fechada do FAN no Rio de Janeiro, eu explicava os cinco níveis de detalhamento que uma especificação de casos de uso pode ter. Mostrava aqueles cinco ícones sugeridos por Alistair Cockburn em “Escrevendo Casos de Uso Eficazes” (Bookman, 2006). Quando terminei a explicação um aluno falou: “Pra gente, que trabalha com fábricas de software, isso aí não vai funcionar não. Faz o seguinte: depois da ‘ostra’ (o nível mais baixo) vamos colocar mais um ícone. Sete mil metros abaixo do nível do mar. Coloca o símbolo da Petrobras e vamos chamar isso aí de ‘Nível Pré-Sal’. Só assim as fábricas fazem o que a gente precisa”.
      Triste conclusão de outro participante: “Nem assim funciona…”
    4. A foto utilizada, “Vertical Scrum“, foi tirada pelo Jurvetson.

  • Muita Areia no Caminhãozinho do AN

    De todas as sugestões que apresento no FAN, a que causa mais espanto e suspiros é: um analista de negócios (AN) não deveria cuidar de mais de dois projetos ao mesmo tempo. Dois projetos pequenos! Invariavelmente a casa cai neste momento. E o burburinho parte, principalmente, de profissionais que atuam em médias e grandes empresas. Alguns deles são responsáveis por 10 ou mais projetos. Maluquice pura.

    Não entendo como eles podem tocar tantos projetos simultaneamente. E, considerando que essas empresas contam com algumas dezenas de AN’s, não entendo como elas conseguem disparar e cuidar de tantas iniciativas.

    O burburinho vira debate quando emendo uma segunda recomendação: AN’s deveriam trabalhar sempre em duplas. Uma rápida conta de padaria, que tanto caracteriza a matemática dos novos tempos, deve deixar todos aturdidos: “Hoje tenho 100 projetos e 10 AN’s. Você está sugerindo que eu contrate 190 analistas?!?” Isso sim seria uma bela política para geração de (bons) empregos. Mas reconheço sua inviabilidade.

    É fato que a sobrecarga insana de trabalho não é um privilégio dos AN’s. Infelizmente, é outra característica do século XXI. Mas ninguém deveria aceitar isso como um fato consumado e pronto. No caso específico dos AN’s não é difícil descobrir e tentar corrigir as razões de tanto trabalho¹.

    Em primeiro lugar é preciso dizer que nenhuma empresa tem tantos projetos assim. Projetos, com ‘P’ maiúsculo, devem representar apenas algo entre 10% e 20% de toda a demanda. O restante trata de alterações ou evoluções em soluções existentes, nos famigerados sistemas legados. E por que as empresas estariam utilizando analistas de negócios para cuidar de solicitações de manutenção em aplicações?

    Uma desculpa razoável seria a competência desses profissionais para o desenvolvimento de requisitos. O que muitas organizações não entendem é que não existem, na grande maioria dessas solicitações, requisitos. Não no sentido de existirem necessidades verdes o suficiente para justificar todo o processo de maturação intrínseco à Análise de Negócios. Noventa e tantos por cento das novas necessidades dos usuários são simples e diretas, como por exemplo: “coloca um novo campo assim nesta tela”. Gastar AN’s com solicitações dessa natureza é um belo desperdício.

    Sabe-se lá por que cargas d’água inventaram um novo nome para atendentes de help-desk. Sim, porque solicitações de manutenção deveriam ficar no âmbito daquele grupo que um dia batizamos “help desk”.

    Ouço de algumas empresas que parte das solicitações tem real necessidade de Análise do Negócio. Ok, mas quantas? Duvido que sejam 10% delas. E insisto: é desperdício. Mas entendo: começaram a colocar AN’s para desempenhar essa função na vã esperança de melhorar um cadinho a qualidade do atendimento. Acontece que a solução virou um tiro de bazuca no pezão: AN’s estão aprendendo a desenvolver um monte de coisa. Leem o BABoK ou participam do FAN e absorvem dezenas de ferramentas que podem tornar seu dia a dia menos desagradável. Pena que sejam coisas que agregam muito pouco ou nada quando o trampo é só de manutenção de sistemas. Pior: são coisas que custam tempo e dinheiro.

    Uma grande, imensa empresa tupiniquim se prepara para experimentar um novo desenho. Deve instituir a figura dos Analistas de Demandas ou algo parecido. Seria o meio termo entre analistas de negócios e atendentes de help-desk. Não sei se a solução não deveria ser simplesmente uma melhor preparação do pessoal de suporte. Uma preparação que passasse obrigatoriamente pela especialização. Por exemplo: o cara que atende chamados sobre impressoras não pode ser o mesmo que recebe solicitações para o SAP/R3. Parece óbvio, mas não é tanto assim em alguns lugares que conheço.

    Não há processo ou ferramenta que substitua um simples “Não!”

    Um segundo fator que contribui muito para a sobrecarga de AN’s é a incapacidade que algumas organizações têm de falar “Não”. Em tempos de nervos à flor da pele, competição interna sanguinolenta, políticas demasiadamente corretas e grave miopia onde deveria existir só *Visão*,  a impressão que fica é que todas as demandas e projetos são prioritários, vitais e pra ontem. Uma peneirinha meio esburacada já ajudaria muito. Gastamos tanto com soluções para gestão de portfólios, PMO’s e afins, e seguimos sem a mínima capacidade de dizer qual projeto merece mais atenção e recursos. Enquanto uma organização não aprender a colocar suas iniciativas e demandas em uma fila indiana (uma atrás da outra, sem exceção) ela seguirá com a sensação de sempre ter mais trabalho do que recursos disponíveis para executá-lo².

    Justificando as Sugestões

    “Que tal sugerir que cada dupla de AN’s tenha um mordomo ao seu dispor?” Já ouvi algo parecido, de um colega que interpretou de maneira um tanto precipitada minhas sugestões. Não defendo sombra e água fresca para AN’s. Apenas insisto que eles não conseguirão provar seu valor se: i) Trabalharem em mais de um projeto (ou dois projetos pequenos); e ii) Não trabalharem em duplas. Por favor, me permita justificar.

    Defendo que todo projeto de software seja desenvolvido seguindo um modelo Iterativo e Incremental. Deve estar implícita nesta sugestão a necessidade dos AN’s permanecerem no projeto do primeiro até o último dia. E, a menos que o projeto seja pequenininho, é impossível que os AN’s cuidem (bem) de mais de um. Repito: impossível.

    Pense nas principais tarefas desempenhadas por um AN: entender um negócio e determinado problema ou oportunidade; e entender o usuário, suas necessidades e restrições. Ambos “entendimentos” ocorrem simultaneamente, em diversas situações. Vamos simplificar e usar o modo mais corriqueiro: o AN entrevistando um usuário. Ele deve prestar atenção em seu interlocutor e conduzir a entrevista. O “olho no olho” é importante, assim como a leitura de sinais, caretas e tiques. A explicitação da conversa, seu registro na forma de diagramas, especificações de casos de uso etc, é igualmente importante. E demanda a mesma fatia de atenção. Como um AN pode desempenhar bem, simultaneamente, duas funções tão distintas?³

    Já experimentei de tudo para substituir a explicitação anotada: gravação de áudio, vídeo etc. Nada substitui uma segunda cabeça. Ao término de uma entrevista, no momento da análise dos requisitos aprendidos, ela completa o entendimento, ajuda a destacar pontos obscuros e dúvidas. Enfim, duas cabeças sempre serão melhor que uma.

    Outra justificativa para o uso de duplas é o melhor aproveitamento das habilidades de cada um. Tem analista que parece ter nascido para a socialização: é bom de papo, transmite segurança e sabe lidar com usuários e clientes. Outros são talentosos na redação e desenho. É relativamente raro encontrar um AN que faça muito bem as duas coisas. Como é impossível que ele faça bem as duas coisas simultaneamente, por que não equipá-lo com seu par ideal?

    Eu sei, a implementação dessas sugestões tem que entrar na fila. As empresas que pretendem obter o máximo da Análise de Negócios devem ter outras prioridades: i) Aprender a dizer “Não!”; ii) Colocar os projetos em fila indiana; e iii) Separar o hoje (operação) do amanhã (projetos). E não é que a Análise de Negócios pode ajudá-las até nisso? Bom, acabei de arrumar mais areia para os abarrotados caminhõezinhos dos AN’s. Inté!

    .:.

    Observações:

    1. Eu quis dizer que a identificação dos problemas é fácil. Sua solução, nem tanto.
    2. Perguntinha retórica mas necessária: capacity planning só vale para máquinas?
    3. Vira e mexe me deparo com uma solução curiosa: o AN diz que anota tudo rapidinho, priorizando o contato “olho no olho” com o usuário ou cliente. Depois volta para casa e “passa tudo a limpo”, inclusive escrevendo os casos de uso. Esforço total: 4 horas, por exemplo. Se ele tivesse um par que o isentasse da anotação, ciente de que “passar a limpo” é desperdício e que especificações de casos de uso são construídas na frente do usuário, consumiria as mesmas 4 horas.
    4. A imagem utilizada, “Colorful toy trucks parked in a circle“ é de Horia Varlan e foi obtida no Flickr.

  • Times

    Existem Times, times, timinhos e igrejinhas, como a Copa recém-encerrada bem mostrou. A formação de equipes, para projetos de qualquer natureza, é uma complexa mistura de ciência, bom senso, tato e intuição.

    Ciência porque é preciso conhecer o projeto, as partes interessadas, as habilidades requeridas – tanto sociais quanto técnicas, e o desenho sócio-técnico mais adequado. O bom senso delineia fronteiras, particularmente em relação aos selecionáveis. O tato é exigido tanto na convocação quanto na exclusão de integrantes da equipe. Por fim, a intuição, subjetiva qualidade que permite perceber que aquele improvável jogador pode render bastante em determinado momento do projeto.

    Este artigo trata exclusivamente o primeiro componente, a ciência. E, claro, não falará sobre seleções de futebol. Apesar de sua possível utilidade em outros tipos de iniciativas, o alvo aqui são os projetos para desenvolvimento de sistemas.

    Até pouco tempo atrás eu me gabava de ter feito apenas uma pequena alteração em um metamodelo sócio-técnico que tinha uns 10 anos de idade. Vendia-o como um modelo para um Dream Team, ignorando alguns padrões emergentes que exigiam outro nível de abstração. A ficha só caiu depois de uns tabefes na cara, particularmente os proferidos por Jim Highsmith em “Agile Project Management – 2nd Edition” (Addison-Wesley, 2010). Roman Pichler, em seu “Agile Product Management with Scrum“ (Addison-Wesley, 2010), deu o bofetão de misericórdia.

    O Líder do Projeto

    O Movimento Ágil colocou o auto-gerenciamento no topo da agenda de todos que estavam formando times seguindo seus princípios. “Indivíduos e interações são mais importantes que processos e ferramentas”, é o que diz o primeiro verso do Manifesto Ágil. Dele derivaram os conceitos de auto-direção, auto-organização, auto-disciplina, respeito pelos indivíduos, igualitarismo e um bom ambiente de trabalho.

    Highsmith diz com todas as letras que “times auto-organizados não se caracterizam pela falta de liderança, mas por um estilo de liderança”. Reforça a mensagem citando Larson e LaFasto (“Teamwork: What Must Go Right, What Can Go Wrong”. Sage Publications, 1989): “bons líderes são o principal ingrediente de projetos e organizações de sucesso”.

    Highsmith ataca frontalmente,  resguardando os nomes dos santos, as propostas de auto-direção. Estas sim se caracterizariam pela ausência de um líder único. Os integrantes se revezariam nesta função dependendo de determinada situação em um projeto. Parece claro que ele dirige suas críticas para algumas práticas sugeridas em frameworks como o Scrum e a XP (Extreme Programming). Critica as práticas ou algumas interpretações delas, preciso dizer.

    Déjà vu? Pois é, já falei um tanto sobre o líder aqui no finito, na seguinte série:

    O Time de Produto

    Residem aqui todos os que ajudam a definir e priorizar o que precisa ser feito. Sim, é aqui que fica o Product Owner (PO – Dono do Produto) em um projeto guiado pelo Scrum. Uma coisa que precisa ser mais reconhecida e divulgada é que o PO, normalmente um usuário ou especialista no domínio, raramente terá disponibilidade para executar e entregar tudo o que está sob sua responsabilidade. Para muitos não fará sentido, por exemplo, a execução de várias tarefas operacionais para desenvolvimento e manutenção da Pauta (ou Product Backlog, como queiram).

    Além do PO ou gerente do produto, o time de produto pode ser formado por: analistas de negócios, especialistas no produto / domínio e parte do pessoal de controle de qualidade (QA). Highsmith reconhece que “a formação deste time, com as pessoas mais adequadas e com tempo suficiente, pode ser um complicado desafio para muitas organizações porque o comprometimento exigido é bem maior do que em projetos tocados de maneira tradicional”.

    É por isso que teimo tanto com a Formação de Analistas de Negócios. Por entender que os bons analistas podem compensar a indisponibilidade de usuários e clientes que mal têm tempo para cuidar de seus afazeres cotidianos. Que fique claro: eles compensam, mas não substituem nunca os usuários e especialistas.

    O curioso é que até hoje vemos equipes sendo formadas sem um único representante disso que chamo (depois do Highsmith) de Time de Produto¹. Gerentes de projetos e analistas-programadores normalmente se revezam na posse dessas atribuições. O (imenso) problema com este enfoque é um só: gerentes e analistas-programadores não percebem o “levantamento de requisitos” (sic) como sua responsabilidade principal: “a gente não foi contratado pra isso”. Eles querem é gerenciar e programar. “Requisitos”, vejam só, é um tipo de impedimento para que eles executem seu trabalho real. Uma amolação.

    O Time de Desenvolvimento

    Gerentes de projetos, analistas-programadores (é melhor Desenvolvedores, não?) e afins moram aqui. Se o Time de Produto define o que precisa ser feito, este é o grupo responsável pelo como será feito e pela construção propriamente dita. Apesar de vivermos em tempos de massificação simplista e beócia – formando e contratando “analistas-programadores” como se tudo fosse a mesma coisa – não custa insistir que este time também é multidisciplinar. Que, dependendo do projeto, vários especialistas podem ser requeridos. Um profissional que saiba desenvolver para o Android ou iPhone, por exemplo.

    Gosto de ver, de forma macro, uma estrutura com um mínimo de 4 células: interfaces, serviços, dados e infraestrutura. Isso não significa hierarquização nem divisão excessiva do trampo, mas sim a aceitação de que existem conhecimentos específicos. Não é “linha de montagem”, mas o reconhecimento do fator humano e da impossibilidade de contratar gente que saiba tudo sobre tudo. Estão distantes os tempos dos monoblocos cobolísticos.

    Juntando Tudo

    Se há um projeto então existe um objetivo ou conjunto de objetivos bem definido. Se o Líder, o Time de Produto e o Time de Desenvolvimento trabalham no sentido de alcançar o mesmo objetivo, então eles formam um único time. Este deveria ser o único critério para definir um time de verdade, não as eventuais divisões internas que só existem para organizar o conhecimento e as responsabilidades de cada um.

    É muito sadia a divisão entre a turma do “que” e do “como”:

    • Falando como um usuário: “Eu realmente participo do projeto, faço parte do time. E quando não posso participar de algum encontro, fico tranquilo porque tenho um representante que defende meu ponto de vista. Isso, mais as entregas regulares que um processo iterativo e incremental garante, torna o projeto um trabalho agradável e estimulante, ao contrário do calvário que caracterizava nossos projetos anteriores.”
    • Falando como um desenvolvedor: “Finalmente inventamos uma maneira de ter o usuário bem perto da gente sem aquela sensação de ‘nós contra eles’, de dormir com o inimigo. Somos um time só e o que nos une são os objetivos do projeto.”

    Divisão sadia, mas naturalmente conflituosa. Sempre foi, independente da arquitetura social ou processo de desenvolvimento utilizado. E sempre será. Os conflitos podem gerar uma tensão criativa, desejável ou até mesmo fundamental dependendo da natureza do projeto. Uma hora é um time que apresenta sua caixa – suas restrições e condições. Outra hora a outra divisão o faz. E todos trabalham, como diz Scott Berkun², “pensando dentro da caixa, debaixo dela, fora dela, quebrando-a e fazendo uma bela fogueira”. É nesta hora que a presença de um líder pode fazer diferença. Quando o “que” e o “como” demoram para atingir um consenso, transformando a caixa numa solução criativa, nada melhor que um olhar isento mas igualmente comprometido com os mesmos objetivos. E com 3 votos nunca teremos empates, certo?

    .:.

    Observações:

    1. Já usei o termo “Time do Dono do Produto”, traduzindo literalmente Roman Pichler no livro já citado. “Time de Produto”, conforme sugerido por Jim Highsmith, é bem melhor. Mas confesso que não sei como ficará de forma definitiva em português. Aliás, nem sei se vingará como conceito!!
    2. Em “A Arte do Gerenciamento de Projetos” (Bookman, 2008).
    3. A ilustração utilizada neste artigo, “Chain of People”, foi legalmente surrupiada de HikingArtist.

  • Ora (direis) Gerir Estrelas

    “Certo perdeste o senso!”

    Perdão Bilac, mas não resisti. Não é a primeira vez que surrupio belas obras com fins questionáveis. Certo não será a última. A espoleta da vez não veio de TI, mas de um mundo tão distante quanto Pandora está da Terra: veio da bola, do pé na bola, do futebol. É a Copa que se aproxima. Mas não deveria ser. O futebol é algo tão rico de ensinamentos que merecia outro status e mais presença. Pena, ele segue em outra direção. E acaba de perder um de seus melhores tradutores, Sr. Armando Nogueira. Pena. Mas voltemos ao princípio: “Ora (direis) Gerir Estrelas!”

    “Certo perdeste o senso!” Porque, se há algo difícil de gerenciar, é a tal da estrela. Dá de mil e um no pior dos piores projetos. Dá de mil e dois no pior dos piores fregueses. Estrela, como o Flamengo está aprendendo da pior maneira, está sempre acima da gerência. Não apenas na grana depositada mensalmente, mas em praticamente tudo.

    É certo que estrelas de verdade brilham. Adriano foi o artilheiro do último campeonato brasileiro. Sem ele provavelmente o Hexacampeonato não teria acontecido. Em outra nação, a Corinthiana, Ronaldo decidiu, no primeiro semestre de 2009, uma série de partidas importantes. Sem ele o Timão não teria conquistado dois campeonatos. Benefícios assim costumam fazer com que os custos sejam tratados como pequenos detalhes, bobeirinhas. Perdão, mas são pouquíssimos no mundo que podem tratar um milhão de qualquer coisa por mês como um pequeno detalhe. No Brasil, talvez o Batista e mais dois. E olhe lá!

    O custo (exorbitante) de uma estrela é fixo. Seus resultados variam mais que bolsa de valores em tempos de crise. O que permite concluir que, em médio e longo prazos, uma estrela nunca se paga. Ok, “nunca diga nunca”. Então fechamos com “quase nunca se paga”.

    Defina “Estrela”

    Estrela é o craque, o expert, o bambambam em determinada área do conhecimento. Domina como poucos sua arte. Quando brilha, o faz de forma tão intensa que cega, maravilha e entorpece.

    Se a definição se limitasse ao que foi escrito acima este artigo não teria razão de existir. Acontece que uma estrela é apaixonada pelo próprio umbigo. Se acha tão acima dos normais que acaba criando um universo só seu. Heliocêntrico, é claro. Tem seus próprios processos e regras. Seus próprios horários e calendários. E ai de quem discordar.

    Talvez só o futebol rivalize com TI no número de pessoas que recebem, de forma pejorativa ou não, apelidos como “deus”, “rei”, “gênio”, “monstro”, “fenômeno” etc. Mas há ESTRELAS e estrelas. Existem as anãs e as pagãs, as supernovas e os buracos negros. Supernovas, por exemplo, berram por “autogerenciamento” mas não conseguem botar ordem na própria mesa. Já os buracos negros sugam toda a energia (e recursos) ao seu redor – são mal humorados de nascença – e costumam sumir antes que algum resultado seja entregue.

    Em comum todos os (nossos) tipos de estrelas só apresentam dois fatores: i) normalmente são realmente bons no que fazem;  mas, ii) são difíceis, chatos, desagradáveis etc etc etc.

    Seu Projeto depende de uma Estrela?

    Meus pêsames. Ops… perdão. Não são raros, particularmente numa área tão nova, dinâmica e mal formada como TI, projetos que dependam muito da atuação de um craque. E é importante notar que nem todo craque é estrela. É claro que existem os humildes e mortais – que se caracterizam principalmente pelo tanto que são cientes de suas próprias limitações. Traduzindo: craques sabem dizer “NÃO”, “NÃO SEI” e também nunca apresentam estimativas absolutas. Mas você não deu a sorte de contratar um craque. Tens uma estrela em suas mãos. E agora?

    Só tenho duas dicas:

    1. Não crie a ilusão de um relacionamento duradouro. Contrate a estrela especificamente para um projeto. E faça girar em torno dela um ou dois planetas (funcionários de sua confiança) que tenham: i) estômago forte; ii) vontade de aprender.
    2. Vincule todo e qualquer pagamento à entrega de resultados. Faça com que a estrela se comprometa realmente com o sucesso do projeto. Desconheço outra maneira que não seja através do zelo extremo com os desembolsos e reembolsos.

    Seu Gerente é a Estrela?

    Hmmm… Mas que situação, hem? Não prestou atenção na hora da entrevista não? Ok, pode não ser o fim do mundo. Considere uma das alternativas abaixo:

    1. Trocar de emprego;
    2. Tomar o lugar do gerente;
    3. Ajudar alguém (gente boa) a tomar o lugar do gerente;
    4. Convencer o gerente que ele será mais importante, mais bem visto, mais sexy e bem sucedido se começar a trabalhar para a equipe, esquecendo o comportamento “comando & controle” e aprendendo que a “delegação de poderes” o fortalece e não o contrário. Pode garantir que, se ele aceitar tudo isso, será convidado para todos os happy-hours e churrascos da turma.

    Você é a Estrela?

    Desculpa aí. Não é nada pessoal não, viu gente fina?

    Inté!

    .:.

    Slinky Abstract, a foto utilizada este artigo, é de Paul Stevenson.

  • O Mundo Ágil precisa de Analistas de Negócios?

    Na realidade, a dúvida mais frequente em nossos papos e debates é: Como o Analista de Negócios (AN) se ‘encaixa’ em um projeto guiado por um método ágil? Acontece que possíveis respostas para essa questão obrigatoriamente nos levam para a pergunta do título: Projetos ágeis precisam de AN’s? Temo que não são poucos os que responderiam com um rápido e sonoro: Não!

    E não é muito difícil entender suas razões. Primeiro, como Roman Pichler lembra em “Agile Product Management with Scrum”¹, nenhum livro “clássico” derivado do Manifesto Ágil cobre aquelas etapas iniciais de um projeto que podem se beneficiar da atuação de um AN. Ken Schwaber, em “Agile Project Management with Scrum” (2004), Kent Beck, “Extreme Programming Explained” (1999) e “Crystal Clear” (2005) de Alistair Cockburn – todos partem de uma visão ou pauta* (Product Backlog) previamente definidos. Pouco ou nada falam sobre aquele momento em que equipe e organização definem ou, melhor dizendo, começam a definir o que precisa ser feito.

    Pichler não cita, mas “Agile Project Management – Second Edition” (2010) de Jim Highsmith e até “Utilizando UML e Padrões” (2008) de Craig Larman apresentam a mesma restrição. Este último não o faz de maneira explícita, como é comum em obras baseadas no Processo Unificado (PU). Mas isso é assunto para outro artigo. O que nos interessa aqui é a confirmação de que não só o AN, mas a própria Análise de Negócios é em parte ignorada por pessoas e obras que ajudaram a fundar, definir e consolidar o Movimento Ágil.

    Por favor, não entenda que a análise de negócios é apenas uma fase no início de um projeto. Utilizada corretamente em um modelo de ciclo de vida iterativo e incremental, ela existirá durante todo o projeto. E até depois dele. O que tento destacar aqui é que, nas fases iniciais de um projeto, a análise de negócios é caríssima. E o é porque é ela que ajuda a definir uma clara visão dos objetivos do negócio ou do produto. E, como diz Jim Highsmith², “na ausência desta clara visão, a natureza exploratória de um projeto ágil resultará numa espiral infinita de experimentações”. No popular: “para quem não sabe para onde vai, qualquer caminho serve”.

    Não é minha intenção tentar explicar essa grave omissão. Já ouvi muitas pessoas dizendo que a Análise de Negócios seria, por si só, um projeto específico. Não concordo. Todo projeto de software depende, mesmo que em graus diferentes, de um conjunto de métodos e práticas que: 1) ajudam a definir o que precisa ser feito; e 2) ajudam a garantir que o que está sendo feito realmente atende aos objetivos fixados (e respeita as restrições colocadas). A esse conjunto foi dado o nome “Análise de Negócios”. E eu não entendo como um projeto para a construção ou implantação de um sistema de informação poderia prescindir dele.

    Um segundo motivo pelo qual os AN’s parecem “ignorados” pelo Mundo Ágil é a forma como este, em seus vários sabores e formas, conclama e exige uma participação mais efetiva dos usuários e demais partes interessadas que não fazem parte do “time de construção”.

    Na proposta conhecida como eXtreme Programming (XP ou XisPê), por exemplo, uma prática requer o usuário literalmente sentado ao lado dos desenvolvedores. Costumo brincar que, quando um bom AN se deparar com um usuário que tenha total disponibilidade para ficar alimentando um projeto com seus requisitos, deveria recomendar sua sumária demissão. É brincadeira. Mas procura iluminar um ponto crítico: quem, nos dias de hoje, pode abandonar seus afazeres cotidianos durante todo um projeto? É claro que se trata de uma prática de difícil aplicação. Assim como deve ser óbvio que, quando possível e em determinados tipos de (pequenos) projetos, ela deve ser adotada. Não questiono sua eficácia. Apenas desconfio de sua viabilidade.

    O Scrum é outra proposta derivada do Mundo Ágil, que se caracteriza ultimamente pelos altíssimos índices de popularidade. Ele concentra suas sugestões nos aspectos gerenciais de um projeto. E define a existência de 3 “entidades” principais na comunidade de um projeto: o ScrumMaster, o Time e o Dono do Produto (Product Onwer). Este seria o representante de todos os usuários e teria, segundo Ken Schwaber (um de seus “criadores”), duas grandes responsabilidades: 1) Maximizar o ROI (Retorno sobre o Investimento); e 2) Gerenciar a Pauta (Product Backlog). Roman Pichler, no mesmo título citado anteriormente, sugere uma revisão das duas principais preocupações que devem guiar o Dono do Produto. Elas seriam: 1) Definir a Visão; e 2) Entregá-la!

    Repare como a sugestão de Pichler se encaixa perfeitamente na definição da análise de negócios que apresentei acima: 1) Ajudar a definir o que precisa ser feito; 2) Ajudar a garantir que a entrega realmente satisfaz os objetivos colocados. A mudança está apenas no tom, no tamanho da responsabilidade: o Dono do Produto realmente define a visão e é o principal responsável por entregá-la**. A análise de negócios ajuda.

    Então podemos dizer que o Dono do Produto (DP) elimina a necessidade de um Analista de Negócios (AN)? Em minha opinião, quase nunca! Citarei Pichler novamente, listando aquelas que seriam as responsabilidades de um DP:

    • Pesquisa de mercado;
    • Planejamento do Produto;
    • Análise de Negócios (!);
    • Gerenciamento da Pauta (Product Backlog);
    • Descoberta, Descrição e Priorização de Requisitos;
    • Gerenciamento de Versões (Releases);
    • Acompanhamento da evolução do projeto;
    • Gerenciamento do orçamento;
    • Relacionamento com clientes, usuários e outras partes interessadas; e
    • Participação nas Reuniões Scrum.

    Gerentes de projetos devem ficar um tanto “encafifados” com a listinha acima. Mas outro dia eu falo com eles. A questão aqui é: até que ponto é possível que apenas uma pessoa realize (bem!) todas as atividades listadas acima? Repare ainda como questões operacionais, táticas e estratégicas são misturadas, causando a falsa impressão de que seriam equivalentes. E lembre-se que existem pessoas que ainda cogitam a utilização de um DP que não tem 100% de disponibilidade de tempo para o projeto!

    Não é por acaso que vários trabalhos recentes – dentre eles o já citado Pichler e também “Scrum Product Ownership”³, de Bob Galen (2009) – afirmam que o trampo do DP é “o mais pesado em um projeto Scrum” (Galen). Portanto, não deve causar espanto nem revolta o fato de alguns autores começarem a sugerir uma Equipe do Dono do Produto. Pichler chega a citar um exemplo mostrando uma equipe formada por “dois analistas de negócios, um arquiteto chefe e um assistente de projeto”, além do próprio DP, é claro.

    É importantíssimo salientar que o DP continua sendo uma única pessoa. O que muda com a sugestão acima é a aceitação de que o DP não dá conta sozinho de tudo o que ele precisa fazer. Mesmo em projetos considerados pequenos. Sendo assim, ele sempre poderá montar um time próprio. Sinceramente, eu não entendi o que um “arquiteto chefe” fez naquele exemplo do Pichler. Mas, tendo em vista a lista de responsabilidades acima, é muito fácil supor a ajuda que AN’s podem dar para os DP’s. Sendo mais direto: todo o trabalho operacional listado (descoberta e descrição de requisitos; análise de negócios de uma maneira geral; pesquisas e parte do relacionamento com outras partes interessadas) pode ser atribuído exclusivamente para AN’s. Além, claro, do apoio na execução de atividades de caráter tático (como o gerenciamento da pauta).

    Eu entendo e até tento compartilhar o temor que muitos demonstram quando veem uma sugestão como essa. Mais pessoas, mais intermediários, podem comprometer a qualidade da comunicação. Nunca vou dizer que esta não é uma preocupação relevante. Acontece que os problemas causados por um DP sobrecarregado podem ser consideravelmente piores. Imagine, por exemplo, o início de uma iteração sem uma pauta fechada; ou então com uma pauta repleta de requisitos (ou histórias) incompletos, ambíguos ou mal estruturados e porcamente priorizados.

    Se ambos os cenários, comunicação e sobrecarga, são ruins e indesejáveis, mas devemos escolher um, qual seria melhor administrado? Qual representa menores riscos?

    Conclusões (?)

    Reparou nas datas de publicação das obras citadas? Pensou na base histórica que temos desde o dia 13 de fevereiro de 2001, data de ‘nascimento’ do Manifesto Ágil? Desconfiou que a consolidação de nossos métodos de experimentação (desenvolvimento) é também uma experiência? Por isso tasquei um ‘?’ ali no subtítulo. Porque conclusões, nesta altura do campeonato, ainda são muito perigosas. E relativamente frágeis. Daí a quantidade de debates e embates que vemos por todo canto. De um lado, ainda vemos muita resistência em mudar (o que configura uma boa piada). De outro, muitas vezes, a falta de humildade para admitir que ainda estamos todos aprendendo.

    Por isso, caros AN’s (e GP’s), não é preciso ter medo do ‘monstrinho’ Ágil. Todo projeto seguirá apresentando necessidades e consequentes atividades, independentemente do processo, metodologia ou ‘modinha’ utilizada. Todo projeto seguirá tendo uma etapa onde definimos o que precisa ser feito. Assim como todo projeto seguirá precisando de líderes.

    O que não pode significar, de forma alguma, que você AN (ou GP) possa baixar a guarda e ignorar tendências fortes, verdadeiras, viáveis e inevitáveis como o Movimento Ágil. E o SEMAT (?). E o Flu? E 2012?? E o Flamengo e a Terezinha???

    Desconfianças (!)

    Foi um bom mineiro, Guimarães Rosa, quem disse: “Sei de nada não… Mas desconfio de muita coisa”. Quem dera eu tivesse as desconfianças do Rosa. As minhas, no assunto em questão, são:

    • Não vejo mais com bons olhos a alocação de um AN para desempenhar o papel de Dono do Produto. Cheguei a sugerir isso algumas vezes. Peço desculpas e retiro minha sugestão. O DP deve ser de fato uma pessoa do negócio (ou, em algumas situações, o Gerente do Projeto).
    • Em projetos guiados pelo Scrum, o AN deve fazer parte do Time do Dono do Produto. Em muitos projetos, bastará 1 (um) AN. Seu par, na maioria das atividades, será o próprio DP ou um integrante do Time.
    • Corpos de conhecimentos vão incorporar cada vez mais práticas ágeis. Não adiantará muita coisa se seus espíritos (Princípios) não forem seriamente questionados.
    • AN’s (e GP’s) que já se deparam com projetos ágeis ou desconfiam (ou desejam!) que eles estejam em seu horizonte próximo, deveriam priorizar o estudo de obras como aquelas listadas abaixo, em detrimento até mesmo do BABoK (por razões já explicadas aqui).
    • Opa, quase me esqueci. A resposta é: Sim, o Mundo Ágil precisa de Analista de Negócios.

    Bibliografia

    1. Agile Product Management with Scrum
      Roman Pichler. Addison-Wesley (2010).
      Obs.: Tomei por base uma versão preliminar do livro, um Rough Cut. Seu lançamento está previsto para 5/mar/10.
    2. Agile Project Management – Second Edition
      Jim Highsmith. Addison-Wesley (2010).
      Obs.: Já disponível.
    3. Scrum Product Ownership
      Bob Galen. Draft v1.3 (2009).
      Obs.: A versão final, independente, já está disponível via Lulu.

    Observações:

    A foto utilizada neste artigo, “Danger: Keep Clear“, é do PSD, surrupiada legalmente no Flickr porque liberada como Creative Commons (by).

    * A sugestão do termo “Pauta” como alternativa para “Product Backlog” deve ser creditada para o colega Leandro Mendonça. Muito obrigado, meu caro. Tenho testado o termo com um surpreendente índice de aceitação.

    ** Antes que me batam: O DP é o principal responsável pela entrega no sentido de que ele deve ser accountable (aah! palavrinha maldita). No popular: é o dele que estará na reta em caso de problemas com a entrega do projeto. Ok? Então guardem as facas, please!

  • Crise no Mundo Ágil. Que Crise?

    Sabe aquela sua colega que parece ser a única num raio de 500km que conhece e gosta de uma obscura banda de rock belga? Lembra-se como ela se revoltou e desgostou quando a banda assinou contrato com uma grande gravadora? É o mesmo caso daquele amigo que era fanzaço de um diretor de cinema chinês, mas desistiu da idolatria quando o cara resolveu fazer um filme em Hollywood: “O cara se vendeu”. Todos conhecemos gente assim, que gosta de coisas muito diferentes, distantes do universo pop(ular). Pessoas que se sentem traídas quando seus modelos ou ídolos tentam falar para um público maior, tentam atingir mais pessoas.

    Desconfio que algo muito parecido esteja acontecendo agora, naquele universo que surgiu após o big-bang do Manifesto Ágil. Dois excelentes artigos, de José Paulo Papo e Rodrigo Yoshima, ajudaram a alimentar minhas suspeitas. Além de um bate papo bem legal que rolou sobre a possível morte do RUP (Rational Unified Process) no grupo UML-BR.

    O Yoshima está certo: RUP e Agile compartilham hoje uma mesma tendência. Mas seria a de morrer? Márcio Tierno, o MT, fez um diagnóstico diferente ao falar especificamente sobre o estado atual do RUP:

    Acho que o RUP, pior do que estar morto, entrou para o mainstream. Hoje um cliente ou usa um processo waterfall ou usa um processo *pretensamente* baseado no RUP.

    E entrar para o mainstream significa ter sua evolução freada. Ninguém entendia direito o RUP. Poucos dos que o “adotaram” em suas empresas se deram ao trabalho de ler a última versão e entender. Os “metodologistas” das empresas sempre gostaram do RUP exclusivamente pelos artefatos, pela sensação de controle e pelo tamanho. Jamais pela iteratividade.

    Surrupiei do Google Trends alguns dados que de certa maneira confirmam as palavras do MT e solidificam minhas suspeitas. Veja os gráficos abaixo:

    Tendências para RUP, Agile e Scrum no mundo

    Tendências só no Brasil

    Azul = RUP | Vermelho = Agile | Laranja = Scrum

    O primeiro gráfico abrange o mundo todo. O segundo levou em consideração apenas as buscas e notícias realizadas no Brasil. O Google Trends faz exatamente isso: mostra a quantidade de buscas pelos termos. Não pode ser considerado ao pé da letra, afinal Scrum e Agile significam outras coisas para outras pessoas. O que não tira totalmente o valor do indicativo de tendências.

    E o que os gráficos nos mostram? Uma queda constante porém gradual no interesse pelo RUP e um crescimento vertiginoso nas buscas pelo termo “agile”, particularmente aqui no Brasil. Seria isso um indicativo de morte? Só para aqueles que, como os fãs de bandas e diretores obscuros, gostariam de permanecer num grupo pequeno e muito restrito.

    Eu entendo e compartilho o que acredito que sejam as principais preocupações do MT e do Yoshima. Ao se transformarem em artigos pop – ou “carne de vaca”, para usar um termo bem nosso – RUP e Agile saem do controle. Do nosso controle. E não serão poucos os que irão distorcer, desfigurar e desmontar os valores e princípios que caracterizam e definem essas propostas. Aliás, preciso confessar, eu sou um deles. Tanto que já fui criticado, aqui mesmo no finito, por chamar de “bullshitagenzinhas ágeis” algumas das práticas sugeridas. Falei de práticas, não de princípios e valores. Mas isso não importa. O que importa aqui é saber se é mesmo o caso de decretar a morte do RUP ou do Agile.

    Se o RUP é muito mal utilizado, e de fato é, boa parte da culpa é dos seus criadores e evangelistas. Já mostrei por aqui como o RUP foi uma verdadeira metamorfose ambulante desde o seu lançamento. Alteraram sem pudor seus princípios, causando confusão. O artigo do José Papo mostra que agora a versão 7.5 tem um “Agile Core”. Não estou dizendo que o RUP não deveria evoluir. Estou afirmando que a evolução foi mal conduzida (parece improviso) e muito mal comunicada. O que não isenta, claro, os cabeças de pamonha que fizeram dele uma cascata iluminada.

    O universo Agile pode e vai sofrer com problemas semelhantes. Cabeças de pamonha estão longe da extinção. Mas o caso aqui é diferente. Os valores e os princípios consolidados no Agile Manifesto permanecem os mesmos desde o dia 13 de fevereiro de 2001. E eles não sofrem com um dono nem com as pressões comerciais que este faria.

    Esqueçamos por alguns minutos os Pamonhas e suas cascatas e contratos a preço fechado. Cabe aqui uma autocrítica por todos aqueles que defendem o manifesto:

    • Será que estamos sendo didáticos o suficiente?
    • Não somos impacientes demais para explicar, por exemplo, por que uma iteração não é uma mini-cascata?
    • Será que, ao invés de explicar, não estamos detonando demais o “outro lado”. Vide meu termo acima: Pamonha!
    • Não estamos sendo religiosos e puristas demais?

    Meu maior temor é que os agilistas de hoje se comportem como os cascateiros de ontem. Não concordo com o MT quando ele diz que “mainstream significa evolução freada”. Oras, se no contexto de um projeto estimulamos (ou forçamos) a participação de todos, exatamente para gerar mais ideias e inovações, por que numa escala maior esta mesma prática seria nociva – por que ela geraria o efeito contrário?

    Se de fato nós acreditamos que RUP e Agile são as respostas para melhores projetos, não faz o menor sentido o medo de que essas propostas se transformem em suculentas “carnes de vaca”. Ou nós queremos seguir como os raros fãs de obras cult que ninguém conhece?

    .:.

    A foto utilizada neste artigo, “We Love Crisis”, é de Daquella Manera (Daniel Lobo), fotógrafo profissional que disponibiliza alguns de seus trabalhos como Domínio Público.

  • Meme #016 – Diversidade faz Bem

    When solving problems, diversity may matter as much as, or even more than, individual ability.

    – Scott Page (professor na Universidade de Michigan e autor de “The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools and Society“).

    .:.

    Meme achado-forçado, que ajuda no debate sobre ‘Especialistas Generalistas’.

    .:.
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 Brazil License.

  • Help Wanted: Especialistas Generalistas

    Perdão. Não, o finito não está contratando ‘especialistas generalistas’. O help necessário é outro. Preciso de ajuda na definição do termo. Queria entender as certezas que aparecem com certa freqüência em algumas listas de discussão e artigos. Normalmente o pessoal cita um artigo do Scott Ambler. Ele fala em ‘Generalizing Specialists’. Tropicalizado, o termo virou ‘Especialistas Generalistas’. Só a ausência do gerúndio já me deixa encucado. Mas o problema não está só na tradução não. Começa no próprio artigo do Mr Ambler. Ele cita Robert A. Heinlein, um escritor de ficção científica:

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

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

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

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

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

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

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

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

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

    .:.

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

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

    .:.

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

    .:.