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
- 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. - Agile Project Management – Second Edition
Jim Highsmith. Addison-Wesley (2010).
Obs.: Já disponível. - 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!
The O Mundo Ágil precisa de Analistas de Negócios? by finito, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.
Artigos relacionados:
- Um Roadmap para Analistas de Negócios
- BABoK: Uma Leitura Crítica
- O Jogo dos 7 Erros para Analistas de Negócios
- BABoK = REBoK? Conversando sobre Análise e Modelagem de Negócios
- O Analista de Negócios e o tal BABoK
{ 1 trackback }
{ 17 comments… read them below or add one }
Blog Post: O Mundo Ágil precisa de Analistas de Negócios? http://bit.ly/5zrfJC
This comment was originally posted on Twitter
New blog post: O Mundo Ágil precisa de Analistas de Negócios? http://bit.ly/8QJEhc
This comment was originally posted on Twitter
E se a imagem utilizada falar mais que minhas 1841 palavras? http://bit.ly/5zrfJC hehehe
This comment was originally posted on Twitter
O Mundo Ágil precisa de Analistas de Negócios? http://bit.ly/5zrfJC by @pfvasconcellos
This comment was originally posted on Twitter
Oi Paulo!
Ainda não trabalhei com projetos ágeis, mas algumas coisas ainda me confundem. Por exemplo se o DP seria o responsável por Acompanhamento da evolução do projeto e Gerenciamento do orçamento, qual seria o papel do Scrum Master?
Att.
Gisele
Oi Gisele, tudo bem?
O ScrumMaster, em primeira instância, cuida para que a equipe utilize direitinho o Scrum, e resolve eventuais probleminhas nas interações entre o Time e o DP.
Quando a turma já é craque em Scrum, então o Master se torna Escravo ou, melhor dizendo, Servente da equipe. Explico: ele é o responsável direto pelo tratamento dos riscos e impedimentos. Ele trabalha para o Time e para o DP tirando da frente destes qualquer coisa que os esteja impedindo de performar. Por isso ele é chamado também de “limpa-trilhos”.
Ok? Abraços e muito obrigado pela participação.
Paulo
Muito bom, Paulo.
“para quem não sabe para onde vai, qualquer caminho serve.”
Lembra no outro post que falei de Contexto? Em algumas discussões de grupos de estudo de métodos ágeis eu tenho a sensação de que algumas pessoas, ao comentar a aplicabilidade e as benesses de tais métodos, o fazem tendo implicitamente que todo o (importante) entorno relacionado ao negócio já está tratado: por que vamos fazer?, quais as restrições, requisitos e motivações de negócio?, em que projeto maior da empresa este (sub-)projeto de software se encaixa? etc..
O papel do AN é relativamente recente também e, embora esteja amadurecendo, ainda sofrerá ataques daqui e de lá. Eu vi esses “ataques” em várias situações. Em projetos de implantação de softwares de prateleira (notadamente ERP), muitas vezes não se considera (ou não se considerava?) o AN, mas somente o Consultor Funcional, que abocanha tanto do domínio do problema quanto da solução.
Em alguns momentos, os AS´s não viam valor no trabalho dos AN´s. Enquanto isso, o usuário não entendia por que o AN não tinha ido na área dele apenas “para tirar o pedido” em vez de ficar querendo saber que benefícios aquilo traria para a empresa.
Artigos como este ajudam a todos a identificar os limites e amadurecer a área como um todo.
Aguardo ansiosamente o direcionamento aos GPs
Oi, Paulo,
Não concordo muito com seu texto. Existem nele muitos pontos que, para mim, ficam claros conforme se passa a trabalhar em times ágeis experientes. O grande problemas dos métodos ágeis no Brasil, na minha opinião, é que todo mundo está aprendendo ao mesmo tempo e muita gente está fazendo e divulgando práticas… estranhas.
“Cliente presente” não é nada muito difícil de se ter e deve fazer parte do modelo de staffing do projeto. Na maioria dos casos a pessoa não consegue colocar 100% do seu tempo à disposição mas isso nunca foi impedimento, basta que o time -incluindo desenvolvedores, testadores, BAs e quem mas for- consiga ter suas dúvidas respondidas pelo cliente de uma maneira eficiente e sob demanda. Muitas vezes o cliente dispõe apenas 2,4 horas para o time e isso é suficiente. Se seu cliente não consegue dispôr de tempo para seu projeto provavelmente é porque (1) o projeto não é, de fato, tão importante assim ou (2) não existe nenhuma pessoa que seja responsável por 100% do produto.
Os dois casos são ruins mas são contornáveis pela criação de um cliente (eu realmente não gosto de usar termos de Scrum) “sintético”, o que geralmente é feito por um BA mais sênior. Eu não consideraria um bom BA uma pessoa que não consegue exercer o papel de gerente de produto -atente para o fato de que ele não vai estar usando as suas “vontades” mas sim consolidados as dos múltiplos clientes espalhados.
Sob a lista de responsabilidades do PO, eu não vejo nada demais ali. A lista é bem condizente com a realidade dos 5,10 últimos projetos que participei. A maioria das coisas ali requerem esforço pontual e não diário.
Uma coisa importante é que em Scrum e em outros métodos não há “time do dono do produto”. Existe o time do projeto e stakeholders, alguns comprometidos e outros só interessados. É bem comum termos muito mais que um BA por projeto e eles são todos parte do mesmo time, junto com os desenvolvedores, gerentes de projeto e demais.
Concluindo, o mundo ágil precisa sim de *análise* de negócios, não necessariamente de um *analista*. Da mesma maneira que precisa de arquitetura de software mas não de um arquiteto.
[]s
Olá Marcel,
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
Oi Phillip,
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
Oi,
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
Oi Phillip,
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
Olá,
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
Oi Ronan,
“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
Paulo,
“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
Oi Ronan,
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
Oi Paulo,
“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