Qual a fun\u00e7\u00e3o de uma pessoa de produto ? Onde come\u00e7am e terminam as responsabilidades desse papel? O que o mercado espera e o que a literatura sugere sobre a pessoa de produto\/PO?<\/p>\n
Depois de algumas buscas de job descriptions<\/em> no Linkedin, consultar a defini\u00e7\u00e3o de PO em materiais de refer\u00eancia e ver o que outros blogs falam sobre o assunto diria que existe um consenso geral:<\/p>\n “A pessoa de Produto deve entender o caso de neg\u00f3cio do produto, direcionar as decis\u00f5es pensando nos usu\u00e1rios e maximizar o valor do produto definindo quais problemas devem ser resolvidos primeiro.”<\/p>\n Ou seja: Foco no upstream do processo e na valida\u00e7\u00e3o da solu\u00e7\u00e3o para o usu\u00e1rio final! Agora que temos um ponto de partida, vamos expandir um pouco mais essas atividades e escrever um “Job Description<\/em>” da fun\u00e7\u00e3o. (Essa lista considera cerim\u00f4nias do Scrum, mas pode ser utilizada por qualquer PO)<\/p>\n B\u00f4nus: No fim do texto coloquei umas dicas para aqueles que, assim como eu, migraram da \u00e1rea de desenvolvimento para os pap\u00e9is de gest\u00e3o)<\/p>\n N\u00e3o obrigatoriamente. O guia do Scrum<\/a> tem um quote interessante:<\/p>\n “O Product Owner<\/em> pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento faz\u00ea-lo. No entanto, o Product Owner<\/em> continua sendo o respons\u00e1vel pelos trabalhos.”<\/p><\/blockquote>\n Al\u00e9m disso considere que parte dessas tarefas pode n\u00e3o fazer sentido para a sua organiza\u00e7\u00e3o.<\/p>\n Lembre-se: Cada empresa tem uma situa\u00e7\u00e3o \u00fanica que exige o seu pr\u00f3prio processo. Nosso objetivo como gerente \u00e1gil \u00e9 garantir que todas as atividades do processo tem um respons\u00e1vel e que o fluxo vai funcionar harmonicamente. Para isso n\u00e3o existe uma receita de bolo dizendo quais atividades a nossa pessoa de produto deve realizar exatamente.<\/p>\n Nesse ponto voc\u00ea deve ter entendido que o papel da pessoa de produto \u00e9 dizer o que tem que ser feito. N\u00e3o subestime a import\u00e2ncia dessa responsabilidade. O time precisa de algu\u00e9m que possa entender o neg\u00f3cio, a estrat\u00e9gia, as dores do cliente e trazer isso para eles.<\/p>\n \u00c9 normal que as pessoas de produto se percam um pouco no escopo das suas atribui\u00e7\u00f5es. Eu particularmente encontrei essa dificuldade em startups aceleradas e empresas pequenas onde essa pessoa, por ter um vasto contexto do neg\u00f3cio, acaba ajudando v\u00e1rios outros setores.<\/p>\n Sem uma no\u00e7\u00e3o clara do que deve ser atendido, o time de desenvolvimento pode come\u00e7ar a trabalhar em coisas que n\u00e3o s\u00e3o prioridade, come\u00e7ar a resolver problemas que n\u00e3o s\u00e3o importantes para a empresa\/cliente ou simplesmente parar o trabalho por que o processo entrou em starvation<\/em> (Quando n\u00e3o existem demandas prontas (DoR) para o desenvolvimento).<\/p>\n Deixe o backlog com hist\u00f3rias de usu\u00e1rio suficientes para o time de desenvolvimento trabalhar e com a prioriza\u00e7\u00e3o adequada. Se voc\u00ea est\u00e1 no in\u00edcio do projeto pode querer fazer um story mapping<\/em>( [Vamos falar sobre Story Mapping<\/a>] ) , se o story mapping<\/em> j\u00e1 foi feito ou o seu objetivo j\u00e1 est\u00e1 bem definido voc\u00ea pode querer melhorar o refinamento das hist\u00f3rias, para isso veja: User Stories. Quebrar ou n\u00e3o quebrar? Eis a quest\u00e3o<\/a> ou Melhorando o refinamento e a autonomia de times com a implementa\u00e7\u00e3o do 7D<\/a><\/p>\n Essa \u00e9 especialmente para aqueles que acabaram de migrar de desenvolvimento para cargos de gest\u00e3o de produto ou processos. Codar<\/em> \u00e9 legal! De verdade eu ainda gosto de fazer um script de vez em quando. Mas com o tempo, vamos perdendo nosso conhecimento da arquitetura do projeto, esquecemos a maneira otimizada de resolver certos casos e at\u00e9 a sintaxe nos foge um pouco. \u00c9 importante entender isso e abra\u00e7ar esse novo papel de gest\u00e3o, mantendo foco na nova especializa\u00e7\u00e3o como Pessoa de Produo\/PO. Assim voc\u00ea tamb\u00e9m evita que o time de desenvolvimento se sinta microgerenciado. Se sua realoca\u00e7\u00e3o for nova e o time ainda precisa da sua opini\u00e3o t\u00e9cnica, tente ao menos evitar fazer isso nas reuni\u00f5es de refinamento e deixe que te procurem quando for necess\u00e1rio. Por fim, defina um nivel claro de autonomia para o time produzir sem depender de voc\u00ea (ou voc\u00ea nunca mais ir\u00e1 tirar f\u00e9rias!).<\/strong><\/p>\n N\u00e3o existe nada de negativo em ter o time razoavelmente acess\u00edvel para debates com outros setores da sua organiza\u00e7\u00e3o. Na verdade, essa conversa tende a ser extremamente ben\u00e9fica. Por\u00e9m se voc\u00ea juntar Devs motivados, que querem codar e que est\u00e3o sem um objetivo claro, com pessoas de algum outro setor que visualizam uma dor no cliente, essa combina\u00e7\u00e3o pode resultar em trabalho e esfor\u00e7o para resolver um problema que n\u00e3o \u00e9 prioritario para a organiza\u00e7\u00e3o naquele momento. E em defesa deles, provavelmente est\u00e3o fazendo isso de boa-f\u00e9 acreditando que \u00e9 um bom uso do seu tempo. Escute o que os outros setores e pessoas est\u00e3o identificando como uma dor do cliente e inclua (ou n\u00e3o) isso no backlog<\/p>\n Lembre-se: Existe um objetivo para ser atingido, alinhe o conjunto de features necessarias para esse objetivo e o time ter\u00e1 um direcionamento de para onde seguir.<\/p>\n Uma situa\u00e7\u00e3o que pode ocorrer \u00e9 medir de maneira err\u00f4nea os impactos de riscos do projeto e priorizar erroneamente as atividades. Isso pode se traduzir em Bug Reports<\/em> com prioridade errada que acabam furando a fila de desenvolvimento, ou como uma feature realmente importante que deixamos de desenvolver. Sugiro a leitura desse artigo: Tipos de Demanda e Classes de Servi\u00e7o: Afinal, \u00e9 tudo a mesma coisa?<\/a> , principalmente a parte de cost of delay<\/em>, ir\u00e1 ajudar a entender como a prioriza\u00e7\u00e3o afeta o projeto do ponto de vista financeiro e como pensar de maneira calculada nos riscos.<\/p>\n J\u00e1 no quesito discovery<\/em>, ajude o time a eliminar as incertezas de neg\u00f3cio e permita que eles resolvam incertezas t\u00e9cnicas. Afinal voc\u00ea n\u00e3o quer que o time trabalhe por semanas para s\u00f3 ao final descobrir que uma parte cr\u00edtica do projeto n\u00e3o est\u00e1 dispon\u00edvel ou n\u00e3o existe tecnologia para constru\u00ed-la. Sugiro a leitura desse artigo :Requisitos em equipes \u00e1geis: Falando sobre complexidade e incerteza<\/a>.<\/p>\n Como a organiza\u00e7\u00e3o pode saber se o que foi entregue est\u00e1 de fato resolvendo as dores do cliente? Sem saber qual a aceita\u00e7\u00e3o dos seus usu\u00e1rios,podemos acabar criando os produtos errados. N\u00e3o quebre o ciclo de feedback, fa\u00e7a bom uso das reviews, verifique como est\u00e3o os OKRs e colete dados quantitativos e qualitativos do produto. Se ainda n\u00e3o tiver, pense neles: Dilemas de PO: como definir OKRs em equipes \u00e1geis<\/a>.<\/p>\n Se voc\u00ea como Pessoa de produto est\u00e1 conseguindo desenhar o “mapa da tesouro” para a time e ajudando eles a se manterem focados no objetivo parab\u00e9ns!<\/p>\n Caso ainda esteja iniciando no papel ou queira saber mais sobre o Pessoas de Produto e Agilidade veja os posts sobre PO no blog da Plataformatec<\/a>.<\/p>\n Quer conversar mais sobre o assunto, dar feedbacks ou tirar d\u00favidas? Fique a vontade para deixar seu coment\u00e1rio.<\/p>\n Guia do Scrum: https:\/\/www.scrumguides.org\/docs\/scrumguide\/v2017\/2017-Scrum-Guide-Portuguese-Brazilian.pdf<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Qual a fun\u00e7\u00e3o de uma pessoa de produto ? Onde come\u00e7am e terminam as responsabilidades desse papel? O que o mercado espera e o que a literatura sugere sobre a pessoa de produto\/PO? Depois de algumas buscas de job descriptions no Linkedin, consultar a defini\u00e7\u00e3o de PO em materiais de refer\u00eancia e ver o que … \u00bb<\/a><\/p>\n","protected":false},"author":79,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[3],"tags":[123],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8938"}],"collection":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/79"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=8938"}],"version-history":[{"count":6,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8938\/revisions"}],"predecessor-version":[{"id":8947,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8938\/revisions\/8947"}],"wp:attachment":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=8938"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=8938"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=8938"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Job Description<\/h3>\n
Definir o que fazer e a ordem de prioridade<\/h4>\n
\n
Planejamento e Gest\u00e3o do Backlog<\/h4>\n
\n
Execu\u00e7\u00e3o do Projeto:<\/h4>\n
\n
Alinhamento de expectativas (comunica\u00e7\u00e3o) com partes interessadas:<\/h4>\n
\n
Monitoramento do resultado:<\/h4>\n
\n
Ent\u00e3o o PO deve realizar todas as tarefas dessa lista?!<\/h3>\n
O que acontece quando o PO n\u00e3o consegue se concentrar nas suas tarefas? + Dicas para novos PO<\/h3>\n
Seu time vai ficar sem saber o que fazer:<\/h4>\n
N\u00e3o diga “Como fazer”, mas “O que fazer” e confie no seu time:<\/h4>\n
Outros setores podem come\u00e7ar a interagir com as demandas do time:<\/h4>\n
Prioriza\u00e7\u00e3o, Riscos e discovery<\/em> podem ficar abandonadas:<\/h4>\n
An\u00e1lise de m\u00e9tricas do produto n\u00e3o ocorre:<\/h4>\n
Resumindo<\/h3>\n
Referencias :<\/h5>\n