.:.

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é!

.:.

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.

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 Novo Gerente de Projetos
• Fracasso 2.0
• O Mundo Mudou

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.