Chez TeamLead cette année, Sergey a expliqué comment Agile se transforme en une grande organisation et, par conséquent, comment votre environnement (chefs d'équipe et équipes) évolue et quelles nouvelles exigences vous sont imposées en tant que leaders. Et il a montré tout le processus Agile avec des photos.
Premiers pas avec Agile
Si vous avez déjà Agile, comment avez-vous décidé? Avez-vous décidé par vous-même et consciemment de quel processus exactement (Scrum ou Kanban) vous avez besoin et qu'est-ce que cela aidera exactement à résoudre vos problèmes? Votre première rencontre avec Agile était-elle comme ça?
... ou est-ce arrivé?
Dans les grandes organisations, l'histoire habituelle est celle de l'arrivée d'un manager: «Ça y est, demain tout le monde est Scrum! Il n'y a pas de temps pour le découvrir - vous êtes un Scrum Master ou un Product Owner. " De plus, à partir de l'étude «Agile en Russie», les chiffres montrent: plus l'échelle est grande, plus cette histoire se produit souvent. Mais peu importe comment vous avez réussi à entrer dans Agile, voyons où vous en êtes, quel est cet environnement et quelles exigences il impose à vous et à vos équipes. Si cela n'est pas réglé, très souvent l'implémentation d'Agile se transforme en une fabrique de fonctionnalités.
Dans le passé, les développeurs prenaient des tickets à Jira. Maintenant, ils font la même chose, mais ils prennent de ce que l'on appelle maintenant l'arriéré: un arriéré est accumulé jusqu'à vous, vous en retirez - et le convoyeur continue. En même temps, quelque part, vos produits présentent à l'utilisateur ce qui s'est passé à la fin: utilisateur et produit, bisou!
Est-ce vraiment Agile? Nous ne l'avons pas fait pour ça.
Qu'est-ce que Agile et pourquoi?
Vous savez qu'Agile est une approche permettant d'exécuter des projets face à une grande incertitude. Voici la matrice de confusion de Stacy:
Agile fonctionne bien dans une situation où vous avez deux grandes incertitudes:
- ce que vous devez faire pour vos consommateurs afin qu'ils votent pour votre entreprise et votre produit avec de l'argent;
ou
- vous ne savez pas avec quelles technologies mettre en œuvre cela,
alors vous vous retrouvez dans un environnement complexe dans lequel on vous propose:
- renoncez à penser que vous savez ce dont vos utilisateurs ont besoin;
- émettre des hypothèses;
- mener une série d'expériences;
- obtenir des commentaires de l'utilisateur final (d'abord insatisfait, et à l'avenir, nous espérons trouver un moyen de résoudre son problème).
En conséquence, vos équipes et, en général, l'ensemble de votre organisation ont deux axes:
- Quelle est la valeur client? Vous devez apprendre à le mesurer en travaillant systématiquement avec la valeur du client.
- Fais le rapidement. On dit parfois que la ténacité d'une équipe se mesure par le nombre d'hypothèses testées par unité de temps.
Comment poser tout cela sur nos réalités?
Quelle est la tâche du leader?
Il y a deux acteurs dans le système: vous, en tant que chefs de file, et vos équipes. Prenons un exemple simple: une équipe fabrique un produit, mais le client est mécontent. Que devons-nous faire en tant que chefs de file, quelle est notre tâche dans cette histoire? Bien sûr, déterminez quel est le problème: vous, en tant qu'expert, allez le découvrir. Supposons que l'équipe de développement se soumette aux tests le dernier jour, de sorte qu'un grand nombre de problèmes atteignent l'utilisateur. Que faisons-nous ensuite?
Nous savons déjà quel est le problème, nous l'avons identifié. La chose la plus simple à faire maintenant est de venir à l’équipe et de dire: «Écoutez, les gars, vous faites ça maintenant - ne faisons pas ça! Faisons les choses correctement. » Cela se fait généralement avec des enfants. Je dis à mon fils de sept ans: "Vladik, ne fais pas ça, s'il te plaît!" Et cela, au fait, fonctionne vraiment - il arrête de le faire. Il est vrai que ma femme me dit plus tard qu'il ne fait pas ça devant moi. Et quand je suis au travail, tout continue comme avant.
Donc ça ne marche pas. On fait quoi alors? On change le processus, on pose des questions à l'équipe sur ce qui pourrait être fait pour ne pas mal faire. En gros, tout ce que nous pouvons en tant que leaders est de personnaliser l'environnement qui détermine le comportement de nos équipes. Nous créons un environnement qui rend les comportements négatifs impossibles et motive les gens à se comporter différemment:
Par exemple, vous implémentez Scrum. Désormais, il devient impossible de ne pas livrer le résultat au moins une fois toutes les 2 semaines. Non, un développeur peut le faire, mais il recevra des commentaires motivants et stimulants lorsque vous, en tant que leader, invitez des gens à revoir le sprint, qui diront tout ce qu'ils pensent du produit sans hésitation dans les expressions. Peu à peu, pour une raison quelconque, il devient un peu honteux de traîner la même tâche tous les jours - chaque jour, il doit répondre au Daily Scrum de ce qu'il a fait hier, de ce qu'il va faire aujourd'hui, et même avec l'ajout diabolique «dans l'objectif du sprint».
Autrement dit, vous créez un environnement qui change progressivement la façon de penser des gens, et ils commencent à se comporter différemment. Notre tâche est de réfléchir en permanence à la mise en place de l'environnement. En ce sens, nous ne devenons pas des leaders de personnes, mais des mécanismes de mise en place du système. Imaginez un système - les pignons-boulons tournent d'eux-mêmes (ce sont nos spécialistes intelligents), et il y a des frictions entre eux. Vous courez avec un bidon d'huile et ajoutez là où quelque chose commence à se fissurer - vous installez un système qui fonctionne tout seul.
Et les plus cool d'entre nous font en sorte que le système, pour une raison quelconque, commence à se développer. Par exemple, vous créez un environnement dans lequel l'équipe est capable de regarder les résultats de son travail et, comme on dit, de se coacher: que peut-on faire d'autre pour devenir encore plus cool? Cependant, si vous avez mis en place un tel système, vous êtes dans la difficulté, la tristesse (ou la joie) - vous n'êtes plus nécessaire par ce système (au moins sur une base quotidienne), le système commence à se développer. C'est ce qu'on appelle une équipe auto-organisée.
Mais comment y parvenir?
De quoi l'équipe Scrum est-elle responsable?
Allons de bas en haut - prenez juste une équipe Scrum, pas encore d'échelle. Une question pour vous: de quoi sont responsables les équipes à la fin du sprint? Quand le sprint est terminé, pourquoi les grondez-vous?
La réponse habituelle concerne les fonctionnalités. Si une équipe est une fabrique de fonctionnalités, comment les fonctionnalités sont-elles liées les unes aux autres? Pourquoi utilisons-nous ces fonctionnalités, et pas d'autres? Il n'y a pas de réponse à ces questions - un tel environnement n'a pas encore été créé. Un exemple classique est le conseil d'administration de l'équipe d'Avito il y a environ 2,5 ans. On peut voir qu'à la fin du sprint, beaucoup de tâches sont encore inachevées - seulement environ 40% sont prêtes:
découvrons quel est le problème. L'un des problèmes les plus courants au début est que les équipes ne savent pas comment évaluer. Nous devons leur apprendre ce qu'est Story Point, comment l'aborder correctement s'il y a un soutien, un front, etc. dans l'équipe. Montrez-leur comment faire cela par exemple.
Il y a un autre problème - ils peuvent tout faire, mais ils ne sont pas concentrés. Ensuite, nous amenons l'équipe à une rétrospective et demandons: "Quel était le but de votre travail?" En réponse, un regard de chèvre sur l'accordéon à boutons et la question: "Quels sont les objectifs du sprint?" OK, mettons dans une grande boîte ce que vous avez fait au cours des deux dernières semaines. Ils sonnent, écrivez-vous. Après cela, tout le monde met anonymement une note sur l'autocollant: "Dans quelle mesure en tant qu'équipe avez-vous atteint ces objectifs de sprint?" Autrement dit, l'équipe doit répondre à la question en examinant tout ce qui a été fait: regardons des
exemples.
Buts de sprint - 8
Ce sont essentiellement des tâches courantes. De plus, j'ai créé un environnement qui montrait que chaque employé avait son propre objectif (tâche). Et quand une autre personne a répondu, j'ai pris un marqueur d'une couleur différente:
on voit que chacun avait son propre travail. Et la compréhension de l'équipe de la façon dont nous avons atteint l'objectif est complètement différente. Après cela, la question est généralement posée: "Combien sommes-nous une équipe?" Car il semble que chacun n'a scié que son propre travail. Probablement, le mec qui a donné un deux menait vraiment une tâche difficile et, semble-t-il, personne ne l'a aidé. Le camarade avec les neuf n'a pas particulièrement aidé - il a écrit sa tâche et, probablement, à la fin du sprint, il était engagé dans le développement personnel, bien que dans l'autre partie de l'équipe, il y avait des bombardements et de l'aide était nécessaire.
Buts de sprint - 6 pièces
C'est une équipe différente, mais la situation est la même. La compréhension de la réalité est déjà proche de 8-9, mais il y a un six. C'est exactement le chef d'équipe - il comprenait mieux que quiconque à quel point ils étaient proches de l'objectif:
Buts de sprint - 5 pièces
Compresser les objectifs. C'est drôle, mais il existe déjà une distribution normale. 3-4-5 et 7-8-9 sont deux sous-équipes de trois personnes au sein de l'équipe, qui ensemble ont traîné un travail, et elles ont plus ou moins réussi. Les gars du 3-4-5 avaient une caractéristique difficile, ils n'ont pas fait face. Mais ils comprennent à peu près ce qu'ils ont grogné. Les trois six sont les seniors qui comprennent le mieux ce qui se passe car ils ont aidé les Juns dans les deux parties:
Objectifs de sprint - 2-3 pièces
Et si vous pincez du tout? Moins il y a d'objectifs de sprint, plus la compréhension de la réalité - ce que nous avons réellement fait et combien nous l'avons atteint - commence à coïncider dans la tête des gens:
pourquoi ai-je montré tout cela? Pourquoi est-ce cool si l'équipe a un objectif?
L'importance de la finalité dans Agile
Parce que Agile diffère des classiques par ceci:
Dans les classiques, nous promettons un ensemble de fonctionnalités et nous pouvons continuer à jouer: soit investir plus de ressources dans le développement, soit vendre les délais. Il n'y a que ces deux paramètres, car vous devez faire tout le volume.
En Agile, nous comprenons à l'avance que nous sommes dans une zone d'incertitude et ne savons pas de quel ensemble de fonctionnalités nos consommateurs ont vraiment besoin: nous n'avons que des hypothèses. Parfois, ils disent des hallucinations, et le plus grand expert en eux est notre Product Owner. Il hallucine sous deux contraintes: les ressources sont engagées (équipe à plein temps, toutes allouées à 100%) et le sprint se terminera exactement à la fin, ni plus tôt ni plus tard. Les deux paramètres sont fixes et nous voulons que la portée soit flottante. Ce n'est pas une mauvaise chose, c'est une fonctionnalité intéressante: nous aimerions pouvoir changer la portée, recevoir des commentaires - que nous le fassions ou non. Mais vous avez besoin d'un mètre - c'est l'objectif. À quel autre moment la cible tire-t-elle?
Quel est le but du Sprint Review?
Il existe deux options pour effectuer une revue de sprint.
L'équipe montre au propriétaire du produit un produit fonctionnel à la fin du sprint. Voyez comment il le regarde. Il posait la question la plus cruciale: «Product Owner, donnez-nous votre avis: jusqu'où avons-nous atteint l'objectif de sprint? Et comment devons-nous changer l'arriéré supplémentaire? " Le Product Owner a une pose fermée: «Que puis-je vous dire ici? Eh bien, oui, les boutons semblent fonctionner. " Une perplexité surgit: comment un propriétaire de produit peut-il donner des commentaires sur les boutons de travail s'il n'y a pas d'informations réelles sur la façon dont cela fonctionnera dans les champs, c'est-à-dire qu'il n'y a pas de commentaires des consommateurs finaux: La
deuxième option est mon histoire préférée de l'une des équipes Avito, qui également environ 2 ans. Cette équipe met en relation les vendeurs et les acheteurs dans le messager. Il comporte deux indicateurs clés:
- , , , ..
- , .
L'équipe au sein du sprint a implémenté une fonctionnalité banale - une pièce ronde, qui montre qu'à l'autre bout de la ligne l'acheteur ou le vendeur est maintenant en ligne: vous pouvez écrire rapidement, et il répondra immédiatement. Lors de la revue du sprint, ils ont montré les résultats d'un test A / B, déployant la fonctionnalité en production pour un nombre limité de clients et voyant si elle est vraiment en corrélation avec ces deux métriques. Il n'y avait pas de corrélation évidente, et l'équipe a demandé une semaine supplémentaire pour prendre des données et comprendre: si cette fonctionnalité est toujours nécessaire, comment la modifier?
Ce sont deux options différentes. Votre objectif fonctionnera si vous ne le mettez pas simplement comme slogan, mais aussi lorsqu'il est formulé en métriques qui peuvent être mesurées. Sinon, c'est encore une profanation.
Quels peuvent être les objectifs d'un sprint?
Vous pouvez vous fixer des objectifs en fonction des jalons: faire une sortie à telle ou telle date, etc. Il y a encore peu d'informations ici: comment mesurez-vous que c'est ce que veulent vos consommateurs?
OKR propose une approche différente: nous fixons des objectifs basés sur des métriques et spécifiques au client. Comment un client interagit-il avec votre produit? Comment cela affecte-t-il le fait qu'il résout ses problèmes plus rapidement, mieux, mieux, etc. et prêt à voter pour votre entreprise avec de l'argent? Par conséquent, vous devez avoir des compteurs.
L'une des propriétés d'un objectif, comme le dit l'OKR, devrait être un niveau d'ambition. Autrement dit, nous voulons améliorer la vie du client pour un sprint non seulement, mais de combien - jusqu'à 80%, 52%, etc. C'est le compteur où vous voulez sauter:
Conclusion: quel type d'environnement créons-nous?
Le carnet de commandes de produits n'est qu'un ensemble d'hypothèses. Nous, en tant que mécaniciens de ce système, au niveau de l'équipe, devons changer mentalement l'attitude des gens envers l'arriéré. Vous avez des hallucinations dans votre arriéré. Par conséquent, posez toujours une question au propriétaire du produit, à l'entreprise, etc. - Pourquoi fait-on ça? Pourquoi êtes-vous sûr que c'est ce dont nos clients ont besoin? Si vous n'êtes pas sûr, comment pouvons-nous mesurer que c'est vraiment ce qu'ils veulent? Changez la mentalité de l'équipe et de vos clients professionnels pour abandonner ensemble le sentiment de tout savoir à l'avance.
L'équipe est attachée à l'objectif du sprint. Veuillez ne prendre aucun engagement des équipes pour le cadrage. C'est ainsi que vous les poussez essentiellement dans Waterfall, bien que vous l'appeliez Scrum. Il ne s'agit pas de faire toutes les fonctionnalités du sprint. Non, votre équipe au cours du sprint du processus Scrum peut même changer votre backlog produit si elle découvre soudain que ce que vous avez halluciné il y a une semaine ne vous rapproche pas de votre objectif. Bien sûr, deux semaines est une courte période, et à la fin, peut-être que peu de choses changeront pour vous. Néanmoins, changez mentalement - à l'échelle, ce problème apparaît dans toute sa splendeur.
Le backlog de produit et de sprint n'est qu'un plan pour atteindre un objectif. Le plan doit être régulièrement vérifié par rapport au résultat et modifié en cas de rejet. J'ai déjà dit que dans le Daily Scrum vous devez vous poser la question tous les jours: "Que faisons-nous avec l'objectif en général corrélés?" Peu à peu, vous apprendrez aux gens à réfléchir davantage à l'objectif qu'à la portée. Mais d'abord, vous devez répéter cela plusieurs fois pour que les gens comprennent enfin pourquoi nous faisons cela.
L'accent est davantage mis sur le résultat final que sur la prévisibilité des délais de livraison. Nous nous concentrons davantage sur la modification de certaines métriques que sur l'intégration de fonctionnalités. Il est même possible de ne pas terminer certaines fonctionnalités: peut-être qu'en complétant 2/3 de votre backlog de sprint, vous obtiendrez une amélioration des métriques clés pour le client, et peu importe que 2 fonctionnalités ne soient pas terminées. Le but est autre chose.
Sprint Review - Évaluez votre progression vers un objectif en fonction des commentaires des clients. De plus, de vrais clients. Il s'agit d'un défi pour tous les employés lié à la pratique d'ingénierie que votre équipe utilise: intégration continue, déploiement continu, etc. C'est ce qui fait maintenant irruption dans d'autres industries où Agile tente de s'appliquer.
Par exemple, la société sibérienne Gurman de Novossibirsk, qui fabrique des boulettes, a décidé d'expérimenter la zone d'incertitude: que se passe-t-il si vous modifiez le remplissage aromatisant des boulettes ou de l'emballage, comment cela affectera-t-il le pouvoir d'achat du produit? Cool! - maintenant, nous allons mener des expériences et recevoir des commentaires. Mais que signifie l'expérience? Ils viennent chez le détaillant avec un nouveau format de boulettes, mais le détaillant ne veut pas faire de petits achats et propose une offre importante pendant six mois - c'est ainsi que l'expérience dure un an. En conséquence, Sibirskiy Gurman a ouvert son propre magasin, où vous pouvez rapidement obtenir des commentaires, mais le magasin est une partie complètement coûteuse du projet.
En informatique, comme vous pouvez le voir, tout est plus simple. Tout a déjà été inventé. Et dans d'autres secteurs, les gens sont créatifs pour obtenir des commentaires le plus rapidement possible. Mais cela arrive à tout le monde.
Que se passe-t-il sur la balance?
Quelque part ici sur l'image se trouve votre équipe. Et ça commence: chaque équipe a son propre backlog, son propre objectif, vous comprenez qui est votre client, mais pour une raison quelconque, beaucoup de gens (entrepreneurs, parties prenantes, etc.) accourent vers vous qui veulent autre chose de vous ( par exemple, collez vos hallucinations dans votre arriéré), et pour une raison quelconque, vous devez les faire aussi:
Au niveau des symptômes finaux, nous avons les éléments suivants:
- Un grand nombre de dépendances.
- Souvent, nous ne savons pas à l'avance de qui nous dépendons - c'est la faible transparence de la personne avec qui je dois négocier pour déployer certaines fonctionnalités. Vous commencez à le faire à l'intérieur du sprint et à ce moment-là vous le découvrirez: il s'avère que nous ne pouvons pas changer l'API nous-mêmes, nous devons courir vers celle-là; mais ici, vous devez vous mettre d'accord sur les réglementations, la sécurité de l'information, etc. Autrement dit, on ne sait pas à l'avance vers qui courir.
- , . , . , . .
- — . - , , ? , , , . .
- — . : « , ! !» — « ?» .
D'où tout cela vient-il à une échelle et pourquoi cela se produit-il? Prenons l'exemple d'un exemple classique d'obtention d'un crédit, d'où toutes ces dépendances naissent dans la banque.
La première chose qu'une banque devrait faire est de dire aux gens qu'elle a d'excellentes conditions de prêt: haute qualité, rapide, etc. En fait, travailler avec un client commence par le marketing. Ensuite, il y a une évaluation, un enregistrement, etc., jusqu'à la clôture complète du prêt. L'entreprise dispose de services opérationnels qui servent directement le client et communiquent avec lui:
Ensuite, il y a les systèmes informatiques qui prennent en charge, accélèrent, automatisent - en général, ils le font pour que le client obtienne un prêt cool et rapidement. C'est là que nos gens et notre structure organisationnelle apparaissent. Voici un exemple artificiel: il y a 310 développeurs dans le département informatique de Moscou, 30 personnes en Estonie et un autre fournisseur en Amérique (150 personnes):
Un vrai exemple sur moi. Lorsque j'ai obtenu ma troisième hypothèque de ma banque préférée, à l'étape 2 (évaluation rapide des demandes), j'ai été refusée. Le soir du même jour, mon VIP-manager m'appelle avec la question classique: «Sergey, est-ce que tout va bien avec toi avec notre banque? Peut-être que je peux vous aider avec quelque chose? " Bien sûr, je suis tombé sur lui: «Mec, que s'est-il passé? Je suis votre client VIP. Pourquoi mon hypothèque a-t-elle été refusée alors que tout allait bien pour moi? " Il a demandé un temps mort et m'a rappelé dans la soirée - il ne pouvait pas répondre immédiatement à la question, car il a regardé dans le CRM et n'y a vu aucune information indiquant que j'avais même soumis une demande.
La raison en est qu'à cette époque, cette banque a externalisé la première partie de ses services opérationnels à son partenaire. Autrement dit, il y avait une banque mère et une banque partenaire qui servaient les clients à l'entrée - en gros, ce n'est pas la banque mère qui m'aime, mais son partenaire qui m'a refusé. La responsabilité d'une banque ayant pris fin à la jonction avec la responsabilité d'une autre, l'intégration a échoué. Une petite erreur a fait ignorer à la banque mère que son client bien-aimé n'était pas très bien traité par la banque partenaire. À de tels jonctions, une entreprise perd très souvent ses clients et, par conséquent, de l'argent.
Pourquoi est-ce que je fais cela? Imaginez que votre équipe Scrum - interfonctionnelle en termes de backing, front, etc. - se trouve quelque part dans cette structure. La question clé est la suivante: dans quelle mesure vos équipes sont-elles interfonctionnelles dans la résolution des problèmes des clients? Idéalement, la transversalité doit être telle que vous puissiez aider le client à n'importe quelle étape de son cycle de vie de communication avec l'entreprise. Pouvez-vous imaginer le nombre de compétences dont vous avez besoin pour intégrer une seule équipe Scrum, par exemple pour 11 personnes?
Malheureusement, à grande échelle, c'est le problème principal: l'équipe cesse d'être interfonctionnelle vis-à-vis du client. La solution est la suivante: constituons une grande équipe d'équipes qui, ensemble, seront aussi transversales que possible.
Voici un exemple (deux autocollants rouges). Un autocollant avec l'inscription «Hypothèque» signifie que nous changeons la structure organisationnelle de telle sorte qu'une division hypothécaire apparaît (ruisseau, tribu, train, etc., dans différentes entreprises, on l'appelle différemment). Nous combinons des entreprises (responsables des mesures financières pour l'émission de prêts hypothécaires) et des équipes (vivant à Moscou et en Estonie) pour développer des systèmes dans la première partie de ce flux, corriger les erreurs d'intégration, etc.:
Dans mon histoire, le vendeur n'a pas pu être entraîné dans ce sujet. Ils ont dit: "Écrivez-nous le mandat, nous ferons tout." Mais dans tous les cas, vous formez une division qui regarde son client le plus largement possible. Il y a souvent un toast: «Concentrez-vous sur le client, valeur», mais comptez le nombre d'étapes que cette unité ferme. Plus il ferme, plus il fait frais, plus précisément, il deviendra progressivement raide et pourra résoudre tous les problèmes du client.
Pourquoi est-ce que je dis ça? La tâche du responsable n'est pas seulement de créer un environnement pour le développement de l'équipe. Vous devez d'abord comprendre:
- Dans quel contexte êtes-vous?
- Quelles étapes et quels problèmes clients votre équipe ou service résout-il?
- Quelle est votre entreprise?
- Quel est le KPI client final de votre unité commerciale? Autrement dit, qu'est-ce que vous améliorez, et pas seulement votre équipe, mais tout le circuit.
À titre d'exemple, je présente trois options pour les unités interfonctionnelles.
Option 1: par canal avec plateforme
L'un d'eux est essentiellement le flux Web complet, où se trouvent tous les développeurs Web. Par exemple, pour une banque, les principaux paramètres seront sur l'attraction, de sorte que le client essaie de le calculer avec un calculateur de prêt et se transforme en emprunteur hypothécaire.
Une application mobile (iOS, Android, etc.) déjà avec des métriques liées à l'activation et à la maintenance. Il peut également y avoir une division de plate-forme, c'est-à-dire créer un composant dont les consommateurs sont d'autres divisions:
Option 2: par produits avec plateforme
La deuxième option est plus cool: vous modifiez la structure organisationnelle de manière à ce que chaque unité devienne interfonctionnelle par rapport aux canaux. Nous devons corriger quelque chose dans les crédits - nous le faisons à la fois sur le canal Web et sur le téléphone mobile, de même avec les cartes de débit. Le département peut changer complètement tous les canaux. Mais vous devez vous assurer que les divisions peuvent apporter des modifications à la même base de code.
C'est une option plus difficile mais plus cool. L'entreprise aime vraiment ça, parce que le flux de débit rapporte: vous pouvez comprendre combien nous gagnons, et il y a une paie pour les équipes de développement. En conséquence, vous combinez les revenus et les coûts. Votre département devient une petite entreprise au sein d'une grande entreprise, car il a son propre P&L et vous pouvez voir à quel point vous êtes efficace en tant que micro-organisation:
Option 3: chaîne de valeur étape par étape
Les cas complexes ont un grand nombre d'unités, et chacun est responsable d'un ensemble de mesures. Dans les grandes organisations, c'est l'option la plus populaire:
Quel type d'environnement créons-nous à grande échelle?
À grande échelle, nous créons le même environnement qu'au niveau d'une équipe. Il fait en fait la même chose, mais nous développons la transversalité tout au long du parcours client. Il y a donc une mer de difficultés: communication avec les entreprises, les autres équipes, cycles plus complexes (pas sur deux semaines, mais trimestriels):
Partage de la planification des objectifs trimestriels: OKR Planning (PI Planning)
D'accord. Votre équipe comprend déjà que vous ne pouvez pas aider votre client à toutes les étapes. Mais vous comprenez qu'il existe une entreprise avec laquelle vous devez prévoir de modifier les paramètres clients. Vous voyez, il y a encore beaucoup de monde: environ 150 autres spécialistes (10 à 12 équipes). Et avec qui, semble-t-il, devra communiquer, parce que vous dépendez d'eux, et eux - de vous.
Comment communiquer? Dans toutes les approches, Agile donne une recette simple: "Il suffit de parler: vous avez une dépendance avec quelqu'un, allez lui parler." Les développeurs, en particulier ceux qui aiment communiquer davantage avec le moniteur qu'avec d'autres personnes, disent: "Eh bien, je ne peux pas faire ça - comment puis-je simplement parler?" Par conséquent, tous les cadres offrent une contrainte de communication: «D'accord, vous ne pouvez pas communiquer. Vous allez maintenant communiquer, mais selon l'algorithme suivant. "
La planification collaborative OKR (dans une autre approche appelée PI Planning) gagne en popularité. L'idée est que pendant une longue période (un quart) nous, avec toute la foule, comprenant qui est notre entreprise et nos dépendances à l'intérieur, planifions des objectifs communs. Il s'agit d'un événement de deux jours, mais certaines personnes parviennent à le tenir en une journée si les équipes ont déjà appris à communiquer entre elles. En gros, il s'agit d'un événement de questions-réponses facilité de deux jours, tel que:
- De qui dépendons-nous?
- Que faisons-nous ce trimestre?
- Quels paramètres financiers voulons-nous obtenir? Affaires, veuillez répondre.
Autrement dit, nous nous assurons que tout le monde parvient à un accord avec tout le monde et détermine où nous voulons courir d'ici la fin du trimestre. Ce sont de vraies photos lorsqu'il y a trois ans, la Sberbank a tenté pour la première fois de lancer de tels événements:
la planification conjointe OKR ou PI Planning est réalisée par étapes.
Compte rendu
Au départ, un briefing s'impose. Les entreprises devraient dire: «Je voudrais voir cela d'ici la fin du trimestre ...» Et par exemple, en haut, il y a Sberbank il y a 3 ans, et en dessous - GameDev-company Xsolla de Los Angeles. Les Américains, en passant, ont raconté une histoire simple selon laquelle ils n'avaient aucun problème pour activer de nouveaux clients: tout est cool avec les métriques d'activation. Mais il y a un problème avec les achats répétés: pour une raison quelconque, le pourcentage d'achats répétés est très faible. Et le deuxième problème est que pour une raison quelconque, ils n'achètent pas de services supplémentaires, le chèque moyen est faible. Et l'entreprise a demandé: "S'il vous plaît, toutes les fonctionnalités de ce trimestre sont destinées à des achats répétés et à une augmentation du chèque moyen (services supplémentaires)":
C'est l'une des façons dont une bonne vision peut ressembler: lorsque nous parlons de contexte commercial et de mesures financières. Mais on ne sait pas à l'avance ce qui sera fait dans le trimestre. Que se passe-t-il ensuite?
Discours d'architecte
Dans les entreprises informatiques, nous écoutons certainement l'architecte. Une histoire intéressante pour lui! - l'environnement change également. Lors de telles séances, les architectes comprennent enfin qui est leur client (la plupart des architectes d'entreprise pensent qu'il s'agit d'une entreprise):
cet architecte a voulu rapidement rendre compte du «terrible» paysage de Sberbank et s'enfuir: «Je vous ai tout dit! De plus, il a donné une architecture conceptuelle de 50 à 100 pages. Que puis-je faire d'autre ici? Toujours compréhensible, mais si quoi que ce soit - appelez. " Mais après la présentation, l'un des chefs d'équipe lui a posé une question:
- Cher architecte! Le troisième cube en haut à droite - saviez-vous que ce système n'est pas encore opérationnel?
- Bien sûr que je sais. J'ai moi-même dessiné ces cubes.
- Savez-vous qu'il sera mis en service dans six mois?
- Oui bien sûr.
- Rappelez-vous maintenant que nous sommes à la session de planification d'un objectif trimestriel, et que l'entreprise veut des fonctionnalités de notre part, qui, en théorie, devraient passer par ce système.
Ici, l'architecte comprend quelle est la question. Et l'équipe lui a demandé de rester avec eux, afin que lorsqu'ils planifient leurs fonctionnalités, ils réfléchissent ensemble à la manière de prendre une décision inappropriée.
Essaimage (génération cible)
Puis les équipes partent pour la nage libre. Ils disposent de trois heures et doivent générer des objectifs dont ils sont prêts à assumer la responsabilité sur une base trimestrielle. C'est ce qu'on appelle l'essaimage (essaimage, bourdonnement). C'est une sorte de réseautage, mais dans le cadre du travail:
Bien sûr, tout n'est pas si simple. Les enfants reçoivent un algorithme pour atteindre les objectifs adéquats qu'ils peuvent atteindre pour le trimestre. Ils font des feuilles de paperboard qui montrent les arriérés de sprint estimés un quart d'avance. Ceci est nécessaire pour qu'après qu'ils, en tenant compte de leur disponibilité, remplissent grossièrement leurs arriérés et discutent avec d'autres équipes de dépendances (qui, à qui, quoi fera / ne fera pas quoi), posez-leur la question: «Si vous faites glisser toutes ces œuvres, qu'est-ce objectifs que vous allez atteindre, et avec quelle mesure (métrique) pouvez-vous mesurer le degré de réalisation? "
Autrement dit, nous planifions les arriérés de travail, puis nous formulons des objectifs basés sur eux, après quoi nous refusons ces arriérés. C'est juste une technique pour arriver à un objectif adéquat. En aucun cas, pensez que les gars engagent toutes les équipes pour cet ensemble de travaux pour le trimestre:
- Équipe, trouvez un objectif!
- ... C'est tout!
- Êtes-vous sûr de l'atteindre?
- Non, vous venez de demander à trouver.
Non, nous facilitons, c'est-à-dire que nous aidons à atteindre des objectifs plus ou moins adéquats.
Sur la photo, des représentants des équipes qui ont été obligés de communiquer. Ils viennent parfois à cette séance avec le sentiment: "Oui, nous comprenons ce que nous allons faire, et il semble que nous connaissons même les dépendances aux autres équipes, car nous leur avons parlé la semaine dernière." Mais quand vous me demandez directement de dire ce que les équipes vont faire ce trimestre, les dépendances sont enfin révélées:
Nous leur donnons un outil pour qu'après avoir parlé de leurs addictions, ils puissent les afficher et voir qui dépend de qui. Les sauts verticaux sont des sprints dans un bloc, les sauts horizontaux sont des équipes. A l'intersection, l'équipe met la fonctionnalité qu'elle va faire, et la dessine avec une flèche rouge: "Mais ils nous ont promis de le faire un sprint avant l'API, puis nous ferons un bouton à l'avant." Il s'agit d'un protocole d'accord que nous avons convenu avec vous, qui, à qui, quand et quoi:
Présentation des Product Owners
Plus loin dans la présentation, les propriétaires de produits montrent les résultats de leurs équipes:
Le seul qui essaie de coller dans le cerveau comment le scénario de bout en bout fonctionnera est l'entreprise. Toute question adressée au Product Owner au début du type: «Quel scénario de bout en bout fonctionnera?» - reste souvent sans réponse: «Attendez, nous sommes responsables de ce composant. Cela fonctionnera pour nous, votre question n'est pas pour nous. Les balles ont volé de notre côté, cherchez dans d'autres équipes la réponse à votre question. " Au départ, l'entreprise ne comprend rien, mais elle essaie de coller cette image dans sa tête.
Dépendances externes
Xsolla a l'avant-dernière ligne de Tech Ops. Les gars comprennent déjà qu'ils doivent gérer respectivement DevOps pour apporter le support des environnements au sein des équipes. Mais à l'époque (il y a six mois), c'était une unité externe. Le directeur des opérations a également présenté - il a parcouru les autocollants rouges et a confirmé: «Oui, vous m'avez poussé ici que nous devons déployer tel ou tel environnement. Je prends la responsabilité, nous le ferons »:
Il est intéressant que lorsqu'il a dit sur un autocollant ce qu'ils allaient faire, son équipe a corrigé:
- Attends, mec, on ne t'a pas demandé ça, mais autre chose. Je l'ai?
- Je l'ai.
- Le feras tu?
- Je vais le faire.
- D'ACCORD.
Ils ont eu un problème avec les avocats, le marketing, les designers - ces types étaient en Amérique (à Los Angeles), et ils ne sont pas venus à cette réunion. Par conséquent, les dépendances sur eux ont été suspendues, mais il y avait de la peur: peut-être qu'ils le feront, mais vous devez appeler séparément, communiquer, etc. La conclusion pour cette entreprise est qu'elle les invite également à la prochaine planification trimestrielle.
Traitement des risques
Il existe un certain algorithme pour gérer les risques. Idée clé: nous créons un environnement dans lequel, il s'avère, la direction peut définir des tâches. Et ce n'est même pas effrayant, ils sont prêts à les prendre. Ils regardent: «Si je règle le contrat avec nos sous-traitants ici, il s'avère que nous pouvons faire plus de ce que je veux», et donc ils s'impliquent.
Voici des exemples de résolution de problèmes qui peuvent être acceptés si vous avez tout dans cette réunion:
Vote au doigt
La dernière étape consiste à vérifier si les équipes sont vraiment prêtes à assumer la responsabilité des objectifs qu'elles ont développés. Nous vous demandons de lever les doigts:
- 5 doigts - droits, très confiants dans leurs objectifs;
- 1 doigt - avec des objectifs en général, c'est une catastrophe, ils doivent être refaits.
Vous regardez la situation dans son ensemble et si vous constatez une faible confiance dans l'entreprise, demandez-leur de regarder autour de vous: «Regardez, il semble que vous-même ne croyez pas en vos objectifs. Allez le refaire, faites-le pour que vous croyiez vous-même en vos plans. Personne ne les pousse en vous (du moins ils essaient) ":
Rétrospective conjointe de fin de trimestre: examen OKR (Inspect & Adapt)
À la fin du trimestre, nous réunissons à nouveau tout le monde. En fait, il s'agit d'une grande rétrospective (appelée OKR Review dans OKR):
je vais vous montrer ce qui se passe là-bas avec un exemple réel. Les buts que l'équipe a pris pour ce trimestre sont écrits. Ils ont une évaluation planifiée de l'impact sur les métriques, c'est-à-dire sur les objectifs que l'entreprise attendait de l'équipe et de l'entreprise. La réalisation réelle est évaluée:
Ici encore des prises de vue: savez-vous comment évaluer le plan-fact non seulement comme "Il nous semble que cette fonctionnalité a probablement influencé", mais si les produits avec l'entreprise ont collecté des métriques réelles à partir de tests A / B, à partir de certaines options atteindre les clients.
Autre option: si l'équipe n'a pas encore mis en place l'ingénieur, ne sait pas comment rejoindre rapidement le client, elle n'évalue, comme dans Planning Poker, qu'avec ses doigts: "Il nous semble que nous avons atteint cet objectif pour autant":
Ils se fixent essentiellement un pourcentage de réussite: vous pouvez voir que l'équipe a atteint 88% sur le trimestre. L'idée est qu'une telle métrique montre:
- À quel point vous vous fixez des objectifs ambitieux avec l'entreprise
- À quel point vous savez comment les transporter:
À la fin, il y a une rétrospective régulière et chaque équipe travaille séparément. Point clé: les problèmes communs sont retirés: pas séparément pour chaque équipe, mais pour ceux qui en tirent plusieurs à la fois. Habituellement, nous avons fait le critère 3+ équipes. S'ils ont un problème commun, alors il est nécessaire de le résoudre au niveau de l'ensemble de l'unité:
Résumé. Quel est le problème du leader?
Quel est le défi pour nous dans toute cette histoire? Il semble clair quoi faire. Mais vous êtes dans le contexte d'un environnement plus large: les autres équipes, le métier, comprendre quelles parties du parcours client vous choisissez et pour quels clients. En fait, nous sommes nombreux, de tels leads et chefs d'équipe:
quelle est l'exigence pour nous sur l'échelle? Quel est le problème du leader? Le fait que la taille compte ... :)
Cheburashka a muté en crocodile pour une meilleure survie dans les environnements difficiles des grandes entreprises ... En d'autres termes, il faut se développer. C'est un dicton douloureux, mais en fait, si vous ne vous développez pas, les personnes en dessous ne le font pas non plus. Et dans une grande entreprise, les exigences sont impitoyables quant au type de leader que vous devriez être. Vous devez être en mesure de mettre en place l'environnement pour un grand nombre d'équipes, c'est-à-dire de s'auto-développer plusieurs fois plus activement.
Quels leaders survivent dans Agile
En gros, vous devez arrêter de gérer les gens. Formez des environnements dans lesquels les gens sont autonomes. Arrêtez d'être un expert, devenez négociateur.
Voici ce qui permet de vérifier à quel point vous vous êtes développé dans tous ces domaines:
Cette année, nous organiserons la deuxième TeamLead Conf à Moscou au lieu de la Saint TeamLead Conf à Saint-Pétersbourg. Déjà les 16 et 17 novembre, nous nous rencontrerons en direct et discuterons de ce qui a changé pendant cette période. Nous aspirons déjà à de véritables conférences en face à face. Pour que vous puissiez voir le charisme de l'orateur sur scène et lui demander ensuite une heure de plus dans la salle. Boire une quantité mensuelle de café et voir tous les chefs d'équipe que vous connaissez à la fois. Et pendant un mois après cela, triez les enregistrements avec des contacts, des livres et des mots-clés.
, , , , . : , , -, , .
. . . 2019 .