La deuxième partie avec mes erreurs, la première
ici .
Permettez-moi de vous rappeler que je suis le propriétaire du produit dans une équipe composée uniquement de développeurs et que nous créons une plate-forme informatique pour gérer les réseaux d'affiliation des stations-service.
Erreur quatre.
Facteur de bus: ce qui a d'abord semblé être beaucoup d'erreurs, mais en fait, cela s'est avéré être un jackpot clair pour l'équipe
Recruter 8 personnes qui ne peuvent pas se remplacer du tout, sans testeur, et d'abord sans analyste? Il semblerait que je sois devenu fou et ai décidé de couler le produit.
En fait , j'ai besoin de faire 6 groupes de services différents, pour chacun d'eux il y a déjà «les meilleures pratiques», qui se déploient rapidement et facilement, le marché des développeurs expérimentés est large.
Que
signifie pour moi une telle
équipe ? La capacité de trouver rapidement une équipe avec les bonnes compétences, de déployer rapidement MVP et de commencer à valider des hypothèses commerciales, et d'occuper cette niche très libre sur le marché.
Qu'est-ce
que c'est
pour l'équipe ? Au niveau de départ, il existe de nombreuses compétences différentes qu'ils peuvent partager entre eux, la capacité de chaque fonctionnalité à utiliser la solution la plus rapide possible, et surtout, ils apprennent constamment quelque chose de nouveau, et cela, vous voyez, est intéressant même pour les seniors. (Au moins, mon équipe de développement partage ces principes).
Tout en testant les hypothèses commerciales, l'équipe de développement se rapproche les unes des autres et au fil du temps commence à tester les hypothèses techniques en elle-même, ainsi, dans les conflits, l'architecture cible de la plate-forme créée par le TEAM, et non pas un seul architecte, est formée. "Tout architecte" est une personne, à mon avis, inutile, chère et ils n'existent pas :) Quand une équipe a une responsabilité égale, le produit devient une idée commune, tout le monde l'acclame, je ne veux plus déplacer la responsabilité. De manière si épineuse, l'équipe s'agrandit, prend des décisions, COMMENT faire avancer le produit, les compétences s'étendent, l'interchangeabilité et l'auto-organisation apparaissent. Nous n'avons pas encore franchi cette voie, mais tôt ou tard nous passerons. Bien sûr, nous élargissons maintenant l'équipe à un testeur dédié, mais au début, l'équipe est tout à fait capable de gérer cette fonction elle-même.
Oui, il est plus facile de prendre 6 développeurs java et maintenant ils sont immédiatement interchangeables, mais rapidement à partir de zéro, ils ne feront pas un produit fonctionnel et seront très limités par leurs compétences.
Soit dit en passant, il est extrêmement difficile d'être propriétaire d'un produit informatique sans expérience dans ce domaine, par exemple un développeur, un analyste système ou un consultant (n'importe qui, sauf les chefs de projet), et même si vous avez un gourou de l'architecte, ce sera son produit, pas le vôtre . Ici, vous pouvez discuter, mais la pratique et les statistiques sont les suivantes.
Erreur cinq.
C'est gênant pour moi, donc les autres ne l'aimeront pas
Notre équipe a souvent demandé «Qui a besoin de ça?», «Le client le veut comme ça», «C'est vraiment gênant parce que je n'aime pas ça» et ainsi de suite. Au début, bien sûr, vous pouvez penser au client, lui offrir quelque chose et, sur la base des commentaires, remplir l'arriéré. L'essentiel ici est de mener une étude qualitative et d'entendre des douleurs, pas des solutions toutes faites, sinon ils demanderont un «cheval plus rapide», et non une machine parfaitement fonctionnelle.
Il est nécessaire de plonger l'équipe dans la douleur du
client , d'appeler les
clients et l'équipe pour le toilettage, de donner à l'équipe les contacts de ces clients à qui ils peuvent toujours demander un avis ou vérifier rapidement la fonctionnalité.
J'ai commencé à me dire plus souvent: "N'essayez jamais le rôle d'un client si vous n'étiez pas à sa place et ne laissez pas l'équipe le faire." Pourquoi argumenter en vain si vous pouvez demander à la personne pour qui vous faites cela?
Erreur six.
Personne n'a besoin de prototypes
Une très grosse erreur pour un RO débutant n'est pas de faire des prototypes ou de tester des hypothèses. Je voudrais créer rapidement le beau et immédiatement le productif.
Si la douleur du client: il ne voit pas les étoiles la nuit à cause du mauvais temps, et vous créez immédiatement un vaisseau spatial pour lui, en essayant de dépasser ses attentes et de faire 100 fois mieux qu'il n'aurait pu l'imaginer, alors c'est une erreur claire. Il avait une tâche, une douleur et des désirs différents.
Vous pouvez passer trois jours ou une semaine, dessiner à la main à quoi ressemblera le produit et également le montrer au client. Demandez-lui de comprendre comment il va l'utiliser et n'oubliez pas de le faire chaque fois que des idées sont transférées dans le backlog de produit.
Eh bien, lorsque vous avez proposé une fonctionnalité brillante, que vous l'avez prototypée, votre utilisateur tape dans ses mains et le veut vraiment - non, vous ne pouvez toujours pas le faire fonctionner :) N'oubliez pas les mesures des fonctionnalités, à la fois pour l'épicerie et pour l'entreprise. Les mesures sont généralement une histoire spéciale avec des erreurs - plus à leur sujet plus tard et plus en détail dans le prochain épisode. Alors que l'annonce ...
Erreur sept.
Métrique de toute-puissance
Permettez-moi de vous rappeler que notre équipe fait partie d'une très grande startup dans une grande entreprise. Il était difficile de traiter les paramètres des produits avec les parties prenantes. Mettre une métrique commerciale sur une solution informatique qui est encore au stade de la conception est une mauvaise idée. Mais les investisseurs doivent montrer leur travail, même s'il n'y a pas encore d'incréments pour l'utilisateur.
Toute mesure de l'argent vous démotivera, vous et l'équipe, mais c'est précisément sur eux que les parties prenantes voudront regarder. Et maintenant, vous êtes déjà sur la piste glissante PI, en vous efforçant en toute confiance, vous ne pouvez pas influencer cette métrique dans un sens positif. Et dans tous les sens, le produit semble désormais inefficace et non rentable.
Si vous n'avez pas commis d'erreur numéro 6, vous avez toutes les chances de convaincre les parties prenantes, d'utiliser et de montrer le prototype aux utilisateurs, de recueillir des commentaires et de mettre des mesures d'attraction dessus. Rendez le développement aussi transparent que possible, montrez ce que vous faites sur ce prototype, quel bouton ou formulaire fonctionnera, ce qu'il vous permettra de faire et comment utiliser un beau calendrier qui apparaîtra très bientôt. L'essentiel ici est de ne pas trop
promettre et de tenir toutes vos
promesses.Résumé des conclusions:
- Essayez d'abord, si le vôtre - aller à l'école RO
- Vous n'êtes pas immortel, ne saisissez pas tout à la fois, recrutez une équipe en laquelle vous êtes prêt à faire confiance
- Vous avez certainement besoin d'un Scrum Master. À plein temps.
- Tentez votre chance. L'équipe Scrum deviendra tôt ou tard interchangeable, et les hypothèses commerciales ne reposent pas sur le sol, il est préférable de prendre un siège vide sur le marché plus rapidement avec votre MVP, bien qu'avec les risques du facteur de basse au début, que de ne pas avoir le temps de le prendre.
- Communiquez davantage avec le client, souvenez-vous de sa douleur, essayez de la résoudre.
- Questionnez toutes vos idées, créez des prototypes et testez des hypothèses, regardez la réaction du client, nous sommes là pour nous réunir :)
- Choisissez les métriques vous-même, elles devraient vous aider à créer un produit de qualité et itérativement bon. N'oubliez pas qu'il y a beaucoup de produits qui sont restés dans la "vallée de la mort" en raison du manque de qualité.