10 erreurs de jeune PO (conclusion)

Et maintenant 3 erreurs principales. S'ils sont répétés encore et encore, je crains que d'un jeune PO, vous puissiez jouer le rôle d'un ancien PO. Commencez ici et ici .


8. Vous ne pouvez renvoyer personne de l'équipe de développement
Sinon, toute l'équipe sera démotivée

Oui, dans les classiques du genre, l'équipe Scrum est auto-organisée, et vous vous asseyez sur le «trône» et priorisez l'arriéré. Peu importe comment)

En réalité, une équipe auto-organisée n'a pas peur de discuter des problèmes, de dire honnêtement à un autre membre de l'équipe qu '"en fait, nous n'allons pas discuter ici". Par exemple, si une personne apparaissait dans l'équipe - un procrastinateur, ils discutaient de tout cela en rétro, se rendaient compte que "cela ne fonctionnera pas" et avec les mots " C'est Sparte " ... lui dit au revoir. (Je ne sais même pas comment continuer à travailler dans une telle équipe :)

RO - il est le gestionnaire, le propriétaire du budget et, par conséquent, s'il ne se plonge pas dans les affaires de l'équipe "auto-organisée" et ne surveille pas sa "santé", il est peu probable qu'une telle histoire se termine bien. Vous et l'équipe avez essayé des choses différentes, mais cela n'aide pas? Ensuite, le licenciement, l'avertissement et tout cela est votre domaine de responsabilité. Bien que les meilleures pratiques suggèrent que de telles décisions devraient être prises par l'équipe, très peu d'entre elles atteignent un tel niveau d'interaction psychologique.

Je veux parler de deux cas de ma pratique. Notre équipe a 2 exemples sympas.

• Le premier exemple. Forcé . le développeur a participé à la planification, a discuté des fonctionnalités, pris en charge, tâtonné, puis il a pu dire: "Les gars, j'ai 2 mois de formation." Il est revenu, tout en cercle à nouveau. Mais l'équipe elle-même ne pouvait rien lui dire, ne voulait pas et était silencieuse, et une partie du travail s'est arrêtée, toute l'équipe s'est traînée sur ces tâches prévues et, bien sûr, n'a pas eu beaucoup de temps. J'ai regardé ça pendant longtemps, j'ai parlé avec le développeur, en conséquence, nous lui avons dit au revoir. Et rien n'est arrivé à la santé de l'équipe, tout le monde a dit: "Oui, la bonne décision, mais en général, ce serait bien de prendre de telles décisions en équipe" (mûri :)).
• Un exemple de la seconde . Positif . Le développeur a souffert de procrastination, on ne sait absolument pas ce qu'il faisait. Mais sur le rétro, l'équipe a dit que ce n'était pas bon, ils ont décrit les avantages et les inconvénients de la personne de leur propre équipe. Et tu sais quoi? Nous avons réalisé que nous ne nous comprenions tout simplement pas. Le développeur a commencé à travailler différemment, il gère beaucoup, écrit mieux. C'est assez rétro. Donc, parfois, l'illumination de l'équipe vient aussi s'il y a un bon maître de mêlée qui aidera à commencer à parler.

9. Toute entreprise doit être terminée.

Non, pas du tout. En général, une chose extrêmement rare doit être complétée dans le développement de produits. Bien sûr, si cette fin est correctement définie :)

Par exemple, vous avez inventé une fonctionnalité, vous avez menti à ce sujet, elle vit dans l'imagination, le prototype est magnifique et elle a aussi ce bouton bleu avec une bordure blanche. Heureusement, il existe un mvp salvateur qui ne vous laissera rien faire de superflu. Le client recevra tout d'abord le plus nécessaire, et seulement après cela - quelque chose de nécessaire, puis supplémentaire et seulement quelque chose pour l'âme.

Beaucoup de débutants de PO craignent de ne pas avoir fait leurs idées (épopée), ce sentiment les oblige à prendre des tâches qui apporteront peu de valeur mais dépenseront beaucoup de ressources, en attendant le client souffrira d'un problème que vous pourriez rapidement et décidez.

Éteignez le perfectionniste et ressentez un bon moment pendant un moment. Il viendra un moment où le client sera assez satisfait, et il sera possible de faire toutes les tâches à la fin du backlog (bien que je ne sois pas encore moi-même à ce stade de développement du produit, mais comprendre cela aide à prendre des décisions facilement).

Cette méthode fonctionnera d'elle-même si les tâches ont une histoire d'utilisateur décrite avec précision, je vais dessiner à quoi elle ressemble:



10. Travail et peur de perdre son emploi

Vous venez dans une nouvelle entreprise / démarrez une startup, mais en même temps vous travaillez et prenez des décisions basées sur l'expérience passée. Dans les nouvelles réalités, il y aura certainement des gens / règles / opinions qui vous diront qu'ici "c'est impossible ", mais "ce n'est pas accepté ", et "ne prononcez pas ce mot du tout. Cela devient une restriction artificielle sur un produit; elle est souvent basée uniquement sur des conjectures, des opinions subjectives et la peur des autres. Mais vous ne le savez pas, et construisez des murs en béton autour de votre produit, qu'ils ne lui permettent pas de développer.

Un exemple. Notre équipe a passé six mois sans serveurs pour le produit, car «de telles règles - tout le monde ici attend un serveur pendant 6 mois», ils coûtent comme Ferrari F60 America, et l'hébergement cloud est interdit. Ok, attendez - le serveur sous la table n'est pas si mal.

Tentez votre chance, essayez-le. N'a pas fonctionné? Essayez encore! Ou il s'avère que vous n'avez pas à construire un mur en béton ou vous pouvez le casser, ou la pire chose qui puisse arriver est que vous découvrirez qu'il est vraiment impossible de le démolir. Mais en chemin, vous découvrirez autant que possible le contexte du problème, vous trouverez plus d'options de solutions. Oui, très probablement vous mettrez en colère quelqu'un avec vos tentatives de briser quelque chose qui ne peut pas être brisé. Personne ne vous punira pour avoir essayé de faire tout son possible pour le produit et l'entreprise, et encore plus pour ne pas vous licencier :) les trois premières fois - c'est sûr. Le quatrième - c'est possible, mais vous avez fait tout ce que vous pouviez.

Soit dit en passant, nous sommes maintenant hébergés dans le cloud et déployons des machines virtuelles en 1 minute dans la quantité que nous jugeons nécessaire. Et je travaille toujours ici :)