10 erros do jovem PO (conclusão)

E agora 3 erros principais. Se elas forem repetidas vezes, receio que, de um jovem OP, você possa assumir o papel de um antigo OP. Comece aqui e aqui .


8. Você não pode demitir ninguém da equipe de desenvolvimento
Caso contrário, toda a equipe será desmotivada

Sim, nos clássicos do gênero, a equipe de scrum é auto-organizada, e você se senta no "trono" e prioriza a lista de pendências. Não importa como)

Na realidade, uma equipe auto-organizada não tem medo de discutir problemas, honestamente exprime outro membro da equipe que "de fato, não vamos conversar aqui". Por exemplo, se uma pessoa aparecesse na equipe - um procrastinador, eles discutiam tudo isso de forma retro, perceberam que "isso não funcionaria" e com as palavras " Isto é Esparta " ... despediram-se dele. (Nem sei como continuar trabalhando em uma equipe como essa :)

RO - ele é o gerente, o proprietário do orçamento e, portanto, se ele não se envolver nos assuntos da equipe "auto-organizada" e não monitorar sua "saúde", é improvável que essa história termine bem. Você e a equipe tentaram coisas diferentes, mas isso não ajuda? Em seguida, demissão, aviso e todas essas coisas são sua área de responsabilidade. Embora as práticas recomendadas sugiram que essas decisões sejam tomadas pela equipe, muito poucas delas atingem um nível psicológico de interação.

Eu quero falar sobre dois casos da minha prática. Nossa equipe tem 2 exemplos interessantes.

• O primeiro exemplo. Forçado . o desenvolvedor participou do planejamento, discutiu os recursos, apoiou, ficou sobrecarregado e, em seguida, pôde dizer: "Gente, eu tenho 2 meses de treinamento". Ele voltou, tudo em círculo novamente. Mas a equipe em si não podia contar nada, não queria e ficou em silêncio, e parte do trabalho parou, toda a equipe se arrastou para essas tarefas planejadas e, é claro, não teve muito tempo. Eu assisti isso por um longo tempo, conversei com o desenvolvedor, como resultado, nos despedimos dele. E nada aconteceu com a saúde da equipe, todos disseram: “Sim, a decisão certa, mas, em geral, seria bom tomar essas decisões como uma equipe inteira” (amadureceu :)).
• Um exemplo do segundo . Positivo . O desenvolvedor sofria de procrastinação, não está completamente claro o que ele estava fazendo. Mas no retro, a equipe disse que não era bom, eles descreveram os prós e contras da pessoa de sua própria equipe. E você sabe o que? Percebemos que simplesmente não nos entendíamos. O desenvolvedor começou a trabalhar de uma maneira diferente, ele gerencia muito, escreve melhor. Isso é retrô o suficiente. Às vezes, a iluminação da equipe também ocorre se houver um bom mestre de scrum que ajude a começar a falar.

9. Qualquer negócio deve ser concluído.

Não, nenhum. Em geral, uma coisa extremamente rara precisa ser concluída no desenvolvimento do produto. Claro, se esse final estiver definido corretamente :)

Por exemplo, você criou um recurso, mentiu sobre isso, ela vive na imaginação, o protótipo é lindo e também tem esse botão azul com uma borda branca. Felizmente, existe um mvp que salva vidas e não permite que você faça nada supérfluo. O cliente receberá antes de tudo o mais necessário, e somente depois disso - algo necessário, depois algo adicional e apenas algum dia para a alma.

Muitos iniciantes de OP se preocupam com o fato de não terem feito nenhuma de suas idéias (épico), esse sentimento os leva a executar tarefas que agregam pouco valor, mas gastam muitos recursos, enquanto o cliente sofrerá com um problema que você poderia rapidamente e apenas decidir.

Desligue o perfeccionista e tenha uma ótima sensação por um tempo. Chegará um momento em que o cliente ficará bastante satisfeito e será possível executar todas as tarefas no final do backlog (embora eu próprio ainda não esteja nesse estágio de desenvolvimento do produto, mas entender isso ajuda a tomar decisões com facilidade).

Dessa forma, funcionará por si só, se as tarefas tiverem uma história de usuário descrita com precisão, vou desenhar como fica:



10. Trabalho e medo de perder o emprego

Você chega a uma nova empresa / inicia uma startup, mas ao mesmo tempo trabalha e toma decisões com base em experiências anteriores. Nas novas realidades, certamente haverá pessoas / regras / opiniões que dirão a você que aqui "é impossível ", mas "não é aceito " e " não pronuncia essa palavra. Isso se torna uma restrição artificial a um produto; geralmente é baseado apenas em conjecturas, opiniões subjetivas e no medo dos outros. Mas você não sabe disso e constrói muros de concreto ao redor do seu produto, que eles não permitem que ele desenvolva.

Um exemplo Nossa equipe passou seis meses sem servidores para o produto, porque "essas regras - todo mundo aqui espera por um servidor por seis meses", custa como Ferrari F60 America e a hospedagem na nuvem é proibida. Ok, espere - o servidor debaixo da mesa não é tão ruim.

Dê uma chance, tente. Não deu certo? Tente novamente! Ou acontece que você não precisa construir um muro de concreto ou pode quebrá-lo, ou a pior coisa que pode acontecer é que você descobrirá que é realmente impossível destruí-lo. Mas, ao longo do caminho, você descobrirá o contexto do problema o máximo possível, encontrará mais opções de soluções. Sim, o mais provável é que você irrite alguém com suas tentativas de quebrar algo que não pode ser quebrado. Ninguém o punirá por tentar fazer todo o possível para o produto e a empresa, e ainda mais para que não o demitam :) nas três primeiras vezes - com certeza. No quarto - é possível, mas você fez tudo o que pôde.

A propósito, agora estamos hospedados na nuvem e implantamos máquinas virtuais em 1 minuto na quantidade em que consideramos necessário. E ainda estou trabalhando aqui :)