O proprietário do produto também é desenvolvedor da sua equipe?


9

Estou confuso sobre a responsabilidade do OP aqui. Eu era desenvolvedor de uma equipe de recursos de jogos, mas também um PO. O trabalho diário do desenvolvedor é quase em tempo integral, então eu tenho que trabalhar com o tempo para cuidar do meu dever de OP, e a responsabilidade do PO parece ser contra os pensamentos do desenvolvedor.

Como PO, vou escolher mais recursos no próximo sprint. Caso contrário, direi a mim mesmo para não fazer isso, porque sou membro da equipe para desenvolver esses recursos. Essa situação me deixa confusa, então eu quero ouvir algumas idéias de vocês.

Sou iniciante no Scrum e Game Dev (cerca de 1 ano e meio) e também sou novato aqui e inglês.


Eu votaria no pm, nem sabia que existia!
ObscureRobot

2
Linguagem ruim? Que linguagem ruim?
DeadMG

Por favor, desculpe meu pobre inglês. : |
Charlie

6
O uso do Inglês é clara e correta
ObscureRobot

3
É uma bandeira vermelha quando você diz que seu trabalho de desenvolvimento é em período integral, mas o dever do pedido de compra está "com o tempo". Se você definir essa prioridade, deve isso à equipe e a si próprio para convencer quem quer que o cargo não seja adequado para você.
GuyR

Respostas:


2

Pode parecer um pouco estranho, mas realmente não deve haver nenhuma razão para essas funções serem combinadas. Por um lado, alguém confiou em você esse papel; portanto, sua equipe deve respeitar isso. Em segundo lugar, você está agora em uma posição em que pode priorizar o trabalho que precisa ser feito, para sempre explicar por que as coisas estão indo do jeito que estão. Terceiro, você está na equipe e carrega sua parte da carga de trabalho. Finalmente, é um trabalho, se você tiver que trabalhar duro, tudo bem. Uma equipe sempre precisa se lembrar de agregar valor ao seu projeto, não se trata de distribuições gratuitas.

O que se resume é: "Você tem os bens para tomar essas decisões?" Se você acha que tem, faça-o!


3
Eu tenho trabalhado como desenvolvedor e PO por quase 5 meses. Não é impossível, mas a questão é "é razoável ou produtivo?" Se eu puder dar uma nota ao meu trabalho, Meu primeiro ano de desenvolvedor recebeu "A +", mas esses 5 meses de trabalho receberam "B" ou "B +" para os meus dois deveres.
Charlie

11
@Charlie A falta de foco prejudicará seu desempenho, com certeza. Enquanto seus colegas estiverem cientes disso, tudo ficará bem. Acho que a adição de uma pessoa extra para a equipe poderia ter resolvido isso, mas pode não compensar o custo extra.
Carlo Kuip

8

Na minha experiência, o proprietário do produto é um PM / TPM ou um membro da equipe de negócios. Embora não seja impossível para o PO ser um desenvolvedor, há algum perigo de conflito de interesses. Se o seu produto for altamente técnico, o pedido deve ter um histórico de desenvolvimento. Se for menos técnico e mais focado no usuário final, um PO com experiência em negócios é essencial.


Ter um histórico de desenvolvimento é o básico para entender como fazer o trabalho e qual é a ordem certa. Meu trabalho pode precisar, mas talvez não. Sou o único desenvolvedor como PO em todo o "Game Feature Team". O PO de outras equipes trabalha como designer que, na verdade, não "codifica" seus requisitos.
Charlie

6

Como programador (supondo que você seja um bom), você investirá em seu código. Como proprietário ou gerente, você precisa investir no produto.

Nem sempre são a mesma coisa. E quando não estiverem, você terá grandes problemas.

Eu sempre disse que o papel de um bom gerente é bloquear a porcaria de cima e roubar meu código quando é bom o suficiente. Sem um gerente, eu poderia trabalhar em uma única função pelo resto da minha vida, melhorando-a para sempre.

Os proprietários precisam olhar para o cenário geral, os programadores precisam observar os detalhes. Você não pode fazer as duas coisas a menos que seja Deus!


11
Estou nesse dilema (bom código e cronograma do produto) há muito tempo. Faço essa pergunta aqui porque acho que preciso escolher um papel e desistir de outro para não sofrer mais. :)
Charlie

11
Na verdade, como um bom desenvolvedor, acredito que você também deve tentar ver o cenário geral. No entanto, é difícil se você se aprofundar nos detalhes do trabalho, daí a necessidade de OPs / gerentes.
sleske

3

Como é definido no Scrum tradicional, não há um problema com um desenvolvedor que também funciona como proprietário do produto. No entanto, você precisa tomar cuidado ao planejar prestar contas de qualquer pessoa que esteja desempenhando sua função em período parcial, seja porque eles estão trabalhando em vários projetos ou porque têm várias funções na mesma equipe. No seu caso, você não pode se considerar um desenvolvedor em tempo integral, pois é necessário planejar o tempo em cada iteração para desempenhar as funções do Dono do Produto.

Eu acho que você também tem um mal-entendido do que o Dono do produto faz. Não é sua responsabilidade escolher quais recursos entram em uma iteração. Em vez disso, é seu trabalho ser a voz do cliente no projeto, quando se trata de introduzir novas histórias, atribuir prioridades a essas novas histórias e garantir que a implementação de cada história seja aceitável por meio da criação e execução de testes de aceitação. A escolha das histórias é baseada na velocidade da equipe e na lista de pendências priorizada, não em quantas histórias o Dono do Produto deseja implementar.


2

Interessante que estou dando conselhos a um cara chamado Charlie, (meu nome é Charles), mas tenho alguma experiência em papéis duplos como dev / PM e, na minha experiência, é MUITO fácil ficar muito envolvido em um papel ou o outro.

Se você conseguir manter o controle de ambas as funções, faça-o de qualquer maneira, mas faça um orçamento do seu tempo e mantenha a alternância de contexto entre essas duas funções no mínimo absoluto, especialmente em um único dia.

Idealmente, eu recomendaria que você evitasse misturar esses papéis, pois eles são, como você notou, bastante conflitantes entre si.


Eu escolho "Charlie" como meu nome em inglês porque é fácil de lembrar e de uso comum. No episódio de TV "LOST", um cara chamado Charlie e ele gostam de uma garota chamada "Claire" (nome francês da minha namorada :) Eu não tenho idéia do significado desse nome e da relação com "Charles".
24411 Charlie

11
O problema é que sou uma pessoa do tipo programador e adoro fazer algum trabalho de codificação. Então, alternar entre esses dois papéis é difícil para mim. Em nosso projeto, a programação diária da OP inclui uma reunião chamada "Revisão Diária". Isso acontece às 17:00 todos os dias, é uma coisa terrível deixar metade do seu código no IDE e voltar para finalizá-lo mais tarde ... Exceto nesta reunião inevitável, a comunicação entre as 4-5 equipes de recursos do jogo custa muito tempo durante o dia e interromper meu trabalho. Só consigo pensar e escrever um código à noite quando outros se foram.
Charlie

Charlie é um apelido para Charles, o nome que eu usei principalmente quando criança, e ainda uso entre alguns amigos.
SplinterReality

11
Você realmente precisa evitar pensar nessa transição da maneira que está fazendo agora. Pode não ser um trabalho de desenvolvimento, mas é uma parte importante da realização das tarefas, e você precisa garantir espaço mental adequado para lidar com as tarefas à sua frente. Isso provavelmente significa que você interrompe a programação bem antes das 17h para se preparar para a reunião e mudar de marcha para o seu novo papel. Você deveria fazer isso! Você está progredindo neste projeto, mesmo que suas tarefas não estejam mais no nível do macaco de código.
precisa

0

Quase sempre uma má ideia. Tínhamos um gerente de projeto que era proprietário do produto e isso era bastante conflitante.


0

Entendo os problemas gerais de equilíbrio entre os dois papéis, mas o que não entendo são suas preocupações específicas.

O desenvolvimento é apenas um papel em tempo integral, se você o fizer. Se você se considerar apenas 50% durante o planejamento do sprint (ao contar todas as horas / dias de desenvolvedor disponíveis), você terá tempo de sobra para suas tarefas de PO.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.