Salve!

Ontem acabou o Agile Brazil 2010, realizado em Porto Alegre, tive a oportunidade de participar do evento pela Locaweb, que patrocinou o evento, e no total vieram 12 pessoas de diversas áreas e, além de participar da conferência, no começo da semana fiz o curso de Product Owner da Adaptwork ministrado pelo Alexandre Magno e pelo Luiz Parzianello.

Como Jack diria, vamos por partes, então vou escrever alguns posts sobre o curso de PO e sobre o evento. Também recomendo a leitura do post sobre o curso escrito pelo André Nascimento, da Stefanini. As fotos foram gentilmente “roubadas” do Flickr do Fernando Meyer, que também fez o curso, além do Alan Baptista e do Victor Cazzonatto, todos camaradas de Locaweb, mas de á;reas diferentes.

Curso de Product Owner

Atualmente sou o PO de Cloud Computing na Locaweb, e decidi fazer o curso para aprender mais sobre esse papel e poder melhorar meu desempenho. Apesar de ter pesquisado um pouco sobre o assunto, sempre me pergunto se estou no caminho certo, e o curso me mostrou que sim, e ainda me mostrou algumas ferramentas extras.

O curso de maneira geral foi bastante interessante, especialmente porque, além das explicações do Magno e do Parzianello, os alunos participaram bastante, expondo suas opiniões, relatando experiências e fazendo muitas perguntas.

Além de fazer a obrigatória revisão-relâmpago do processo do Scrum, eles falaram bastante sobre a importância do PO entender e se interessar pelo negócio por trá;s do projeto, o que trouxe a tona um ponto interessante sobre a existência de duas fases ou á;reas distintas onde o PO atua: o negócio e o projeto.

Negócios

Na á;rea de negócio temos que entender os motivos de negócio que justificam o projeto, onde precisamos entender os aspectos financeiros (custos estimados, lucratividade esperada, etc), de oportunidade (datas importantes como o Natal, por exemplo), de mercado (competidores, economia, etc) e as restrições e pré-condições (plataforma, contratos, leis, etc) que tornam o produto/projeto necessá;rio e viá;vel, bem como definem os critérios que farão com que essa empreitada seja classificada como bem sucedida.

É nessa fase que definimos a visão do produto, que é a definição das metas que queremos atingir com o produto, e então fazemos o tal “product discovery”, que é o momento onde precisamos entender o que precisamos colocar nesse produto para atingir essas metas. Até esse ponto, não estamos falando de user stories super detalhadas ou coisas do tipo, e sim de uma idéia macro do que precisamos fazer para guiar nosso projeto até as metas definidas.

Nessa fase há; uma confusão entre as responsabilidades e a autoridade de um Product Owner e um Product Manager, que não necessariamente são a mesma pessoa, e isso gerou algumas discussões interessantes, que chegaram também à questões de quem é o “dono do time”, e sob o ponto de vista do Magno, o time é do PO, e o Scrum Master é do time :) Achei uma posição interessante, mas vale um post só sobre isso.

Sobre product discovery e product management, recomendo a leitura do livro Inspired, escrito pelo Marty Cagan da SVPG e também indicado pelo Magno, que fala bastante em como fazer esse discovery de maneira inteligente e prá;tica. Apesar dele não focar nenhuma técnica á;gil em específico, ele dedica um capítulo para discutir como fazer isso em ambientes á;geis e de maneira geral o que ele fala para product managers pode ser feito por POs, basta trocar as palavras.

As contribuições do Parzianello foram especialmente nesse ponto, que é seu principal foco de estudo, e o que ele falou faz muito sentindo, especialmente para nos fazer ficar mais atentos ao negócio do que normalmente fazemos. Essa discussão é extensa e ele não teve tempo de mostrar tudo o que poderia no curso, o que foi ruim por dois motivos. Em primeiro lugar porque não deu para se aprofundar nesse assunto tão importante e interessante, e em segundo porque quebrou o ritmo do curso (esse assunto foi discutido principalmente no segundo dia) e modo como ele apresentou não ficou muito compatível com o resto. Mesmo assim, pretendo conversar mais com ele e pesquisar mais sobre o assunto, não sei como expressar o quanto as coisas que ele falou são importantes e vou começar a me aprofundar nisso o quanto antes.

Projeto

Uma vez definida a visão do projeto e feito o product discovery, passamos à pensar nas etapas mais prá;ticas para atingir as metas, que é a definição do projeto que será; realizado. Nesse ponto analisamos o que foi levantado na definição do produto para pensar em releases e o que precisa entrar em cada um deles para atingirmos as metas da visão.

Nesse ponto o Magno apresentou mais ferramentas prá;ticas para entendermos e sedimentarmos a visão do produto e depois planejar as features e escrever as histórias. Para entender a visão ele mostrou duas ferramentas, o Elevator Pitch e o Product Vision Box, que apesar de parecerem fórmulas prontas e bobas são bem interessantes, especialmente para comunicar a visão à equipe e também a stakeholders. (P.S.: eu sei que os dois links acima estão interligados)

Depois disso passamos à discutir como escrever as histórias que entrarão no backlog, e isso pode ser feito de vá;rias maneiras, sendo a utilização de user stories apenas uma delas, mas foi com ela que ficamos para o resto do curso. Fizemos um mini workshop de user stories e o Magno falou sobre o “conceito de ready”, que é similar ao “conceito de done”, mas que define quando uma história está; pronta boa o suficiente para entrar no sprint backlog, que é um conceito interessante e pretendo revisitá;-lo um dia.

Depois falamos sobre a questão de como priorizar as histórias, e o resumo disso é sempre priorizar as histórias que trarão mais valor e tem mais risco na frente, o que faz sentido. Dessa forma, garantimos que as histórias realizadas no começo são as que trazem mais valor para o projeto e ao mesmo tempo são aquelas que podem dar mais dor de cabeça, assim não temos surpresas no fim do release, porque deixamos os riscos para os 45 do segundo tempo.

Resumo

Depois disso ficamos sem tempo e não pudemos discutir coisas sobre como escalar o trabalho do PO em projetos maiores e coisas do tipo, o que foi uma pena, mas nem de longe isso desmerece o curso. Durante os dois dias discutimos vá;rias outras coisas e técnicas, e ainda escreverei mais sobre isso, mas o bá;sico foi isso.

Minha opinião final sobre o curso é que ele foi bastante útil, aprendi coisas bacanas e voltei dando uma importância ainda maior ao negócio por trá;s do projeto, e vou me dedicar para fazer com que meu trabalho sempre leve em consideração esse aspecto. As discussões paralelas foram legais e tivemos muitos insights interessantes, e recomendo o curso para todos que se interessarem pelo trabalho de ser PO ou mesmo que queiram entender melhor a dinâmica dos projetos sob um ponto de vista menos técnico.

Além do curso de PO e de Scrum Master, também foram realizados cursos de XP e Agile Coaching e tive excelentes relatos sobre eles, especialmente o curso de coaching com o David Hussman, foi uma pena não poder fazê-lo também. Gostaria de parabenizar o Magno e o Parzianello pelo excelente trabalho, e também a organização do Agile Brazil por colocar esses cursos na grade pré-evento, foi uma excelente oportunidade.

Certified Product Owner? Hell no!

Por fim gostaria de esclarecer uma coisa. Oficialmente o curso foi um CSPO, onde o CS significa “Certified Scrum”, ou seja, eu teria direito a um diplominha bonito da Scrum Alliance e seria membro oficial por 1 ano. Porém, seguindo meus princípios e com uma ajudinha do Magno, pedi para não enviarem meus dados para a certificação então, para os trolls de plantão, continuo sendo um PO não certificado :) O importante é o conhecimento que temos e o que fazemos com ele, o papelzinho dizendo que você pode colocar 3 ou 4 letrinhas na sua assinatura de e-mail é só um papel. O único chato é que, como o Freire falou, eu perdi a oportunidade de queimar o certificado e colocar o vídeo no YouTube :)

Leia também a parte 2 da restrospectiva.