“Análise de Negócios não cobre todos os temas que devem ser *dominados* por um DP.”

Correto. Mas é bom lembrar que quando falamos de projetos ágeis, relacionamentos/interações e colaboração do cliente estão entre os 4 valores.

Particularmente eu acredito que, com a colaboração do cliente, uma equipe técnica de qualidade e muita comunicação, não haverão grandes problemas.

Em outras palavras, o AN não precisará assumir nada sozinho, ele se apoiará tanto no cliente, quanto na equipe.
Não há abordagem top-down.

Tudo bem, cliente e equipe não são “cabide” pra ninguém, isso não elimina a necessidade de muita competência, mas ainda assim, acredito na sinergia da união de todas as forças/competências.

“Talvez falte dizer que isso não é um problema nem uma limitação. Afinal, nem todo AN precisará ou desejará essa atribuição. Certo?”

Certíssimo!

[]s
Ronan Lucio

Pois é, estou tratando do Scrum como ele é conhecido, e não de sua proposta específica. Mas isso não impede a sequência do papo, claro. Vamos lá:

Não estou falando que um AN “júnior” não pode ser PO. De novo: eu afirmei com todas as letras que uma pessoa que domine muito bem a Análise de Negócios ainda assim não está ‘gabaritada’ para desempenhar a função de DP. E a razão é simples: a Análise de Negócios não cobre todos os temas que devem ser *dominados* por um DP. Agora fui repetitivo pacas… perdão.

Talvez falte dizer que isso não é um problema nem uma limitação. Afinal, nem todo AN precisará ou desejará essa atribuição. Certo?

Abraços,

Paulo Vasconcellos

“Por que cheguei a essa conclusão? Porque acredito que um Dono do Produto deve de fato fazer valer sua propriedade. Ou seja, ele deve ter a palavra final sobre o Produto que será entregue.”

A sua colocação está correta dentro da proposta original de PO do Scrum, porém, não é a proposta que eu defendo.

Quando digo que um AN é um forte candidato a atuar como PO eu defendo que ele atue como uma ponte. Ou seja, ela passa a ser esse cara que você citou, somente diante da equipe, mas ele continua defendendo os interesses do cliente.

Defender os interesses do cliente significa que algumas decisões (menos importantes do ponto de vista do negócio, porém importantes do ponto de vista estratégico do desenvolvimento da solução) ele poderá tomar por si só, e para outras (principalmente as que afetam preço, prazo ou escopo) ele precisará do aval do cliente.

“E o que tenho visto por aí e aquela “pesquisinha” confirma: muitas empresas estão alocando gente muito nova e de certa forma inexperiente na função de AN.”

Certo. Mas aí eu penso que isso não é mais uma questão de AN ou PO. Infelizmente isso acontece em todas as áreas:
РEmpresas contratando desenvolvedor j̼nior para desenvolver projetos;
– Empresas contratando atendentes sem treinamento adequado;
– Donos de empresas exercendo administração e marketing sem maior conhecimento sobre a área/função e etc.

Neste caso estamos julgando a “sensatez” da empresa em assumir esse risco, e a sensatez do profissional em assumir uma responsabilidade a qual ainda não está devidamente preparado.

Acredito que este caso fuja do contexto da discussão.

“Repito: um AN “puro”, treinado especificamente para exercer a Análise de Negócios, não é um bom candidato para ser Dono do Produto.”

Neste caso me parece que o que não estamos julgando o nível de senioridade do AN, e não o fato de ele atuar como PO (DP).

Sobre isto que queria dizer que “qualquer” profissional sênior costuma contar com outras áreas de competência.
No mercado e realidade atual, “acredito” que raramente você irá encontrar um AN sênior atuando exclusivamente como AN.

Esse cara normalmente vai assumir outras responsabilidades devido à suas outras áreas de competência, a não ser em um projeto muito grande ou em uma necessidade específica. Mas não acredito que isso seja regra geral.

Sabemos que o mercado é carente de bons profissionais, mais ainda dos devidamente qualificados.
A empresa que tem um cara desses, dificilmente abrirá mão de suas competências.

Agora se você me perguntar se um AN Junior pode ser um PO?
De maneira geral, não. A não ser que o projeto seja muito pequeno, ou com pouco valor (como em alguns projetos internos).

Desculpe por eu nunca ter colocado isso antes.
Só agora percebi essa lacuna que eu deixei sobre a minha opinião.

[]s
Ronan Lucio

“Um AN precisaria de muito tempo de estrada e excelente trânsito em escalões mais altos de uma empresa para desempenhar bem essa função.”

Por que cheguei a essa conclusão? Porque acredito que um Dono do Produto deve de fato fazer valer sua propriedade. Ou seja, ele deve ter a palavra final sobre o Produto que será entregue. O Gerenciamento do Produto e suas versões e a gestão do orçamento são trampos muito sérios – são responsabilidades muito grandes.

E o que tenho visto por aí e aquela “pesquisinha” confirma: muitas empresas estão alocando gente muito nova e de certa forma inexperiente na função de AN. Pessoas que não estão preparadas para exercer aquelas tarefas táticas e estratégicas listadas no artigo. Meu caro Ronan, DP é a função mais árdua e crítica em um projeto guiado pelo Scrum. Se ele ficar muito dependente de gente do negócio para tomar decisões, ele vira um imenso gargalo.

Então um AN *nunca* será um DP? Não é isso que estou falando. Se ele se preparar para ser um DP, o que pode impedi-lo? A única coisa é que, depois deste momento, desta preparação, ele nunca mais será um AN.

Repito: um AN “puro”, treinado especificamente para exercer a Análise de Negócios, não é um bom candidato para ser Dono do Produto. Porque esta função extrapola os limites da Análise de Negócios. Ficou claro?

Abraços e muito obrigado pela participação.

Paulo Vasconcellos

Como sou um dos que defende a ideia que o BA é um bom candidato a PO (ou DP), vou adicionar minhas considerações:

Penso exatamente como o Phillip.
Concordo praticamente com todas as colocações do Phillip, pela mesma razão: É o que eu tenho visto funcionar na prática.

Paulo, referente a sua colocação:

“Um AN precisaria de muito tempo de estrada e excelente trânsito em escalões mais altos de uma empresa para desempenhar bem essa função. “

O AN precisaria o mesmo tempo de estrada para qualquer outro projeto, em qualquer outra metodologia, não vejo porque um AN em agile ou como PO ter que saber mais ou menos do que em outra metodologia, a não que você o esteja isolando do cliente ou da equipe.

A ideia que eu sempre defendi, é que o cliente continua sendo o cliente, e o AN defende os interesses do cliente, do negócio (ou estratégia) e do projeto.
Porém, acredito que dentro da equipe deva ter alguém(s) com maior visão do negócio, alguém que “brigue” mais pelo sucesso do projeto como um todo (não que a equipe não faça isso, mas porque na maior parte do tempo eles precisarão estar concentrado do lado mais técnico do projeto).

Esse alguém vai trabalhar em conjunto com o cliente (seja 1, 2, 3 ou n clientes) na priorização de requisitos e em decisões que afetem o negócio (fazendo a tradução), prazo, custo ou escopo.

Definitivamente, na grande maioria dos projetos, nem o cliente, nem o BA e nem a equipe tem como assumir isto “sozinhos”.

Por isso a minha sugestão é que o PO (ou DP) seja alguém com essa visão e que saiba recorrer ao cliente ou à equipe (ou a quem quer que seja), quando necessário.

O mesmo raciocínio vale para as responsabilidade do PO (DP) citadas por você.

Sim, ele “conhecerá” todo este contexto. Algumas tarefas mais profundamente, e outras mais superficialmente, porém, sempre apoiado de alguma forma pela equipe, pelo cliente, ou até mesmo alguém externo ao projeto, como no caso de uma pesquisa de mercado.

Novamente: Ninguém conseguirá exercer 100% daquelas atribuições, sozinho(a), mas alguém tem que assumir a responsabilidade pelo sucesso do projeto. Alguém que tenha um conhecimento do todo e que saiba e possa buscar as informações certas, no lugar certo, quando necessário.
Alguém que tenha acesso direto ao cliente e a outros stakeholders.

Na minha opinião isso tem um pouco de PO e um pouco de BA.

[]s
Ronan Lucio

Jóia sua afirmação de que os “melhores ‘gerentes de produto’ com quem já trabalhei, entretanto, são bons BAs”. Acredito muito nisso. Assim como acredito que o inverso nem sempre é verdadeiro. Aliás, quase nunca é. E a diferença está exatamente na formação e no ‘tempo de estrada’ que esses profissionais costumam demonstrar. Não digo com isso que um AN não possa pretender tal função. Apenas alerto que, para assumi-la, a formação e experiência como AN não é suficiente.

Quanto a não ter AN’s (ou BA’s) responsáveis especificamente por ‘X’, eu concordo contigo. Apenas reforço que os AN’s não terão condições ou autonomia suficiente para assumir algumas das tarefas listadas. O planejamento do produto e o gerenciamento de versões e do orçamento, por exemplo.

Mesmo que você não concorde com algumas sugestões do livro, quero crer que apreciará a leitura e aproveitará algumas sugestões do Pichler. Devo destacar outros pontos no próximo artigo.

Não trato a Análise de Negócios como uma exceção. E nossas experiências parecem ser bastante diferentes. Como eu disse, seguirei defendendo que a Análise de Negócios seja atribuída a quem de fato a domine. Só neste nosso papo já admiti que gerentes de produtos, não necessariamente donos de produtos, podem assumi-la sem muitos problemas. Espero conhecer outros casos.

Forte abraço,

Paulo Vasconcellos

Interessante o ponto sobre o “cliente”, eu vivo confundindo os termos e isso é extremamente perigoso para um consultor. Existe o “cliente” e o “dono do produto”, como você disse, o cliente é quem paga minha hora mas não necessariamente manda no produto… De qualquer forma o “dono do produto” estar presente é, como tinha dito antes, algo relativamente simples de se conseguir ou se contornar. E eu considero que faço algo mais próximo de XP do que qualquer outra metodologia ágil.

Quando falei sobre BAs e POs eu estava me referindo às tarefas que você mencionou, não necessariamente no conjunto de habilidades que faz de alguém uma boa pessoa para gerenciar o produto em si -o que ele precisa ter, o que vai dar dinheiro, etc. Os melhores “gerentes de produto” com quem já trabalhei, entretanto, são bons BAs.

Dependendo do tamanho do projeto sim, uma única pessoa realiza as tarefas acima -em projetos pequenos esta pessoa ainda pode ter o papel de gerente de iteração além destes- mas para projetos maiores geralmente temos mais de um BA. O importante é que todos os BAs do time devem saber realizar aquelas tarefas e não há “BA responsável por X”, tarefas de BAs também devem funcionar em esquema de pull ao invés de push, preferencialmente com um quadro kanban.

Não conheço o livro que você citou mas só este conceito estranho de “time dentro do time” já me faz olhar para ele com maus olhos -existem *muitos* livros “engraçados” no mercado. Pode ser preconceito, está adicionado no meu carrinho de compras na Amazon.

Pelo seu último parágrafo eu entendo que você considera que análise de negócios *precisa* de alguém dedicado. Isso não corresponde com minha experiência. Cada projeto tem necessidades específicas. Como analogia, em alguns projetos precisamos de alguém 100% do tempo atuando como gerente de projetos e ainda de um gerente de iteração. Em outros projetos apenas o gerente de iteração pode fazer PM e IM. E em outros um desenvolvedor ou BA sênior pode facilmente fazer o seu papel e ainda cuidar de gerência de projetos. Tudo depende e eu não acredito que análise de negócios seja uma exceção.

[]s

Ok, fui radical e perigosamente simplista na brincadeira que fiz com o “cliente presente”. É claro que não se trata de uma situação 8 ou 80. Mas a questão é: quem é o cliente? Em diversos projetos que vejo o número de partes (muito) interessadas, leia-se *clientes*, é muito grande. Isso gera sim graves impedimentos para uma adoção *pura* desta prática promovida pela XP. AN’s e dono do produto são, em minha opinião, alternativas muito boas. Entenda: estou falando da prática “pura”, como defendida nas principais obras sobre eXtreme Programming. Um bom AN, no meu modo de ver, é a melhor resposta que temos para as restrições de tempo dos clientes e usuários.

Ok, de certa forma repeti acima o que você escreveu no terceiro parágrafo. Mas há uma afirmação ali que me deixou preocupado, em dúvida ou ambas as coisas. Você escreveu: “Eu não consideraria um bom BA uma pessoa que não consegue exercer o papel de gerente de produto”.

Você está falando do Dono do Produto (como descrito no Scrum) ou de um Gerente de Produtos tradicional? Se for o segundo caso, permita-me discordar totalmente de você. Há diferenças demais na formação das duas funções. Agora, se você fala do Dono do Produto, preciso explicar que passei a desconsiderar o AN como bom candidato para esta função depois que percebi que na grande maioria dos projetos ela tem um caráter mais estratégico e tático. Um AN precisaria de muito tempo de estrada e excelente trânsito em escalões mais altos de uma empresa para desempenhar bem essa função. Na realidade que vejo aqui, AN’s assim são “mosca branca”. Daí minha restrição.

Sobre a lista de responsabilidades do DP: não é só o esforço e disponibilidade de tempo que me preocupam, mas a complexidade e criticidade de alguns itens daquela lista. Mas agora eu fiquei “encafifado”: Em seus projetos todas aquelas atividades são realmente executadas por uma única pessoa?

O “time do Dono do Produto” é uma sugestão do Roman Pichler, no livro citado. Não deve ser visto como um ‘silo’, ‘panelinha’ – como uma estrutura apartada do time do projeto. Seu nome apenas indica que AN’s e demais profissionais ali alocados desempenham parte das funções atribuídas ao DP. Só isso. Sei que a sugestão carrega um certo risco para a saúde e qualidade da comunicação no projeto. Mas também considero que, conhecido o risco, é relativamente fácil para o Time lidar com ele.

Já vi outros colegas fazendo a mesma afirmação que encerra seu comentário: “o mundo ágil precisa sim de *análise* de negócios, não necessariamente de um *analista*”. Da forma com eu vejo a Análise de Negócios, seguirei defendendo que ela seja atribuída para alguém que a tenha como sua principal responsabilidade, e não como uma ‘chateação’ que precisa ser resolvida antes da realização que realmente interessa a determinado profissional, como por exemplo, a programação. Apenas em projetos mínimos e / ou desimportantes para o negócio ela é opcional ou secundária. Nestes casos, por que cargas d’água este projeto está sendo desenvolvido afinal? Um bom AN saberia dizer e, melhor ainda, evitá-lo.

Muito obrigado pela participação.

Abraços,

Paulo Vasconcellos

Infelizmente desconfio que a não compreensão daquilo que você chama de “contexto” não seja uma exclusividade dos defensores e promotores de métodos ágeis. Nos últimos tempos, fontes diferentes relataram o seguinte: o PMI iria rever algumas de suas proposições no sentido de orientar GP’s a darem mais importância para os objetivos do negócio.

Depoimentos assim foram feitos tanto aqui em Pindorama quanto lá fora. E demonstram alguns dos efeitos colaterais bastante positivios da fundação do IIBA. Apesar dos ‘contras’ bem ilustrados por ti, o AN tem a obrigação de entender, comunicar e defender esse *contexto*, ou seja, os objetivos do negócio.

É por isso que acho que meu mantra-sacana vale para todo mundo: “É o Negócio, Beócio!”. Vale tanto para aqueles que ainda não entenderam que software é meio e não fim, quanto para o outro time que não vê que projetos buscam algo além do prazo, custo e escopo corretos. Para este segundo time será o artigo citado. E espero publicá-lo até amanhã, ok?

Muito obrigado pela participação.

Abraços,

Paulo