Salut, je suis Olya et je suis un RO nouvellement créé. Je travaille en tant que propriétaire du produit depuis un an et demi, de nouvelles instances arrivent tous les deux mois, le monde est à l'envers et je pense: "Merde!" J'ai tout mal fait! Mais maintenant je sais exactement comment! Bien sûr, chaque fois que je ne peux même pas imaginer à quel point je me trompe.
La qualité de l'intro est un peu plus détaillée sur le produit, l'équipe et moi.
Nous créons une plate-forme technologique pour gérer les réseaux d'affiliation de stations-service. Nous le construisons à partir de zéro, utilisons des microservices, travaillons sur Scrum, essayons d'implémenter des devops, etc. Nous avons maintenant 30 stations-service, à la fin de l'année, il y en aura plus de 150.
Il y a 1 an et demi, après tous les événements obligatoires comme un pitch, une architecture de solution, une protection budgétaire, etc., j'ai réfléchi sans réfléchir à deux fois à une équipe de 8 personnes, 6 - BE, 1 - FE, 1 - designer. Chaque développeur est unique, il n'écrit que sur quelque chose qui lui est propre, j'ai entendu le mot «agile» quelque part, une fois que je l'ai lu sur Habré, et ce qu'un collègue y fait n'a pas beaucoup d'importance en principe.
J'ai étudié l'informatique appliquée et en même temps travaillé comme travailleur du narguilé, serveur, consultant en nutrition sportive, barman, spécialiste de la logistique dans le port, déclarant (dans le même port), responsable de la distribution des produits de grande distribution, analyste, chef de l'analyse commerciale, chef du département analytique du système SAP , chef de département pour le développement de solutions BI, le tout dans le même commerce.
Dans mon dernier poste, j'avais une équipe d'analystes et de développeurs système, un arriéré de tâches pour 100 ans à venir, beaucoup d'utilisateurs qui m'ont eux-mêmes apporté des commentaires (je n'avais même pas besoin de vierges moulées, même si à l'époque je ne savais même pas que cela tel). Nous avons travaillé des sprints pendant quatre semaines, car le CIO l'a dit, toute l'action se déroule dans le régime alimentaire. Démonstrations - non, rétrospectives - non, métriques - non, Scrum master - qui est-ce?
Et maintenant, il y a 1,5 ans, j'étais à l'école des propriétaires de produits à Gazprom Neft. La troisième semaine de cours est déjà en cours, on nous parle du service Bluetooth, des développeurs de cast, de CJM, des métriques ... et je ne comprends rien. Pourquoi ai-je besoin de ça? Pourquoi suis-je ici? Puis-je déjà aller recruter une équipe?
Donc ce que nous avons:- Idéal du point de vue du facteur de basse, une équipe réunie à partir de zéro
- Beaucoup de connaissances théoriques dans le domaine du développement de produits
- De nombreuses expériences différentes de lieux passés
- Une entreprise où il n'y a même pas de graisse
Mais il y a des gens importants qui, pour une raison quelconque, sont contre le brillant avenir de notre startup et les vues masculines louches de collègues qui ne comprennent pas vraiment ce que je fais ici.
Je termine par des préludes, passons aux erreurs.
Première erreur
Cela n'a aucun sens d'apprendre à être RO - vous devez essayer
Ainsi, l'école RO est une chose nécessaire, utile et obligatoire, mais seulement si vous êtes déjà RO. Sinon, ce sera comme dans une école ou une université - ils disent quelque chose là-bas, de façon intéressante, mais comment cela se rapporte-t-il à la vie? Ce n'est pas clair.
Lorsque vous commencez tout juste à travailler avec RO, vous êtes bien sûr extrêmement chargé de la qualité de votre produit et du produit lui-même en général, c'est un nouveau rôle pour vous, qui est très intéressant à écrire sur Internet, ils sont même trop cool lors de conférences et vous devez vous conformer.
Dans la poursuite d'incréments vraiment impressionnants, à chaque sprint, vous ferez tout ce qui est possible et impossible, les parties prenantes (investisseurs) vous «aideront» à déterminer les paramètres de VOTRE produit dont vous serez responsable, vous essaierez toutes les façons de motiver et de démotiver l'équipe et vous-même, vous rêverez du produit la nuit, et de nouvelles fonctionnalités seront générées à la vitesse de la lumière.
Comme vous le savez, le client n'a pas le temps de reprendre le produit!
Mais tôt ou tard, l'euphorie passera, et les retours des clients apparaîtront, cela vous ouvrira les yeux pour la première fois, et vous comprendrez: quelque chose s'est mal passé. Ici, vous commencerez à google, vous apprendrez ce qu'est CJM, à quel point la recherche est importante, et qu'en général, des hypothèses sont nécessaires pour les tester, et pas seulement à saisir et à faire.
Et maintenant, c'est le moment même d'aller à l'école RO.
Deuxième erreur
Snowflake man - très ambitieux mais inutile
Ceci est ma principale erreur. Et ici, tout est simple.
Lorsque vous êtes un RO nouvellement créé, il vous semble que personne ne connaît le produit mieux que vous (et c'est le cas) et que personne ne fait mieux (et ce n'est pas le cas), et ici vous essayez d'être un Scrum Master, un analyste et un architecte, et secrétaire, et bien d'autres par qui. Peut-être que vous pouvez même combiner tous ces rôles, MAIS pas pour longtemps, et surtout - vous cesserez d'être le propriétaire de votre produit.
Vous devez prendre soin de vous et apprendre à faire confiance à l'équipe, ils soutiennent le produit et veulent le réussir. Tout ce que vous devez à ces personnes, c'est une vision, un arriéré prioritaire et des tentatives pour les protéger de toute bureaucratie, en d'autres termes, pour ne pas les empêcher de prendre des décisions sur COMMENT FAIRE un produit.
Qui un tel homme de flocon de neige peut être trouvé ici:
Erreur trois
L'équipe se passera du scrum master
Souvent, les OR économisent sur cette position et considèrent qu'il vaut mieux prendre un autre développeur pour le même prix, car là l'effet est immédiatement visible.
J'ai pensé la même chose et j'ai presque perdu mon équipe de développement. Premièrement, il est très important d'immerger l'équipe dans la philosophie de la mêlée, de leur transmettre l'idée même du produit, de leur apprendre à bien faire les choses et de montrer pourquoi le quotidien est très nécessaire et pourquoi ils devraient prendre 15 minutes. Que se passera-t-il si les tâches sont évaluées de manière incorrecte, comment refuser au RO d'effectuer quelque chose d'inutile qui n'est pas dans le sprint (vous-même ne mettrez pas 2 casquettes, et vous ne leur apprendrez pas à vous refuser vous-même).
J'écris des choses apparemment banales, mais dans la pratique, une équipe bien organisée est une équipe beaucoup plus productive et efficace qui fera ce dont vous avez besoin, ne vous tirez pas dessus lors d'une rétrospective, dépasse vos attentes, puis vous aurez 50% de votre bonheur client.
La suite des erreurs sera, car j'ai accumulé beaucoup de fakaps. Et vous?