Objectif appliqué. Rapport Yandex

Pourquoi des objectifs sont-ils nécessaires? Comment devraient-ils être formulés? Quels problèmes peuvent survenir? A l'occasion de Y. Subbotnik Pro, j'ai préparé un rapport basé sur plusieurs années d'expérience dans la fixation d'objectifs pour les équipes de Yandex.



- Je vais vous parler un peu de moi, dans le contexte de pourquoi vous devriez écouter mon rapport. Je dirige une équipe qui s'appelle maintenant la direction. Je travaille ici depuis assez longtemps, j'ai vu beaucoup de choses - toute l'évolution de l'organisation de la direction dans une si grande entreprise, de la façon dont nous menons les objectifs.



J'aime aussi les outils et les méthodologies, du développement à l'échelle de l'entreprise. Et récemment, je dirige, entre autres, le département qui est engagé dans la création de nos outils internes.







Avertissement: Que ne vais-je pas couvrir dans mon discours? Je ne vous dirai pas toutes sortes de définitions encyclopédiques - que sont SMART, OKR, KPI. Tout cela a déjà été dit cent fois sur Wikipédia. Vous avez probablement entendu toutes ces choses vous-même. Sinon, une recherche rapide avec votre moteur de recherche préféré vous donnera la réponse. Il regorge de très bons articles. Je l'ai vérifié littéralement ce soir.







Qu'est-ce que je vais vous dire? J'essaierai de partager avec vous une expérience assez personnelle. Et l'expérience que nous avons chez Yandex sur l'établissement d'objectifs. Je vais vous montrer un certain nombre de bons exemples et essayer de donner des avertissements - quels éléments, me semble-t-il, devraient être pris en compte et quels râteaux ne devraient pas être piétinés.



C'est une conférence expérimentale dans un domaine qui ne m'est pas tout à fait habituel. Par conséquent, si vous posez des questions, je serai peut-être en mesure de dire de plus en plus ce dont vous avez besoin.

Pourquoi mener des objectifs?

Qu'est ce que ça a à voir avec toi? Premièrement, je m'attends à ce qu'il y ait parmi vous des gens qui se fixent eux-mêmes des objectifs. Et je pense qu'il vous sera utile d'entendre parler de l'expérience afin de mieux vous fixer des objectifs. Deuxièmement, même si vous ne vous fixez pas vous-même d'objectifs pour le moment, mais que vous les atteignez simplement, une compréhension commune de la méthodologie et des principes vous aidera à mieux les atteindre.



Très probablement, le public présent à la fois fixe des objectifs et réalise. J'appartiens moi-même à de telles personnes. Habituellement, la personne en position intermédiaire est impliquée dans les deux fils. J'espère donc que ce sera intéressant et utile pour tout le monde.







Parlons un peu de la raison pour laquelle fixer des objectifs. J'ai plusieurs citations que j'ai entendues à différents moments de la part de différents collègues et connaissances: ils disent que tout cela est de la bureaucratie, au lieu de fixer des objectifs et d'écrire des tâches, faites-le normalement et tout fonctionnera bien. Il n'est pas nécessaire d'inventer quoi que ce soit, pas besoin de perdre du temps là-dessus.







La deuxième sagesse populaire est qu'il suffit de travailler très, très dur, de prendre plus et de jeter, n'oubliez pas de vous reposer. Un tel travail acharné va tout broyer, et peu importe vos objectifs. Tout cela est bien sûr vrai. Mais seulement partiellement.







Même si vous êtes un très bon développeur et que vous travaillez très, très bien, il arrivera quand même un moment où vous n’aurez pas assez de mains pour tout faire. Et vous devez répondre à la question: que faire en premier lieu, que faire exactement maintenant? J'ai une tranche de temps finie, et il reste encore beaucoup à faire. Nous avons besoin d'une hiérarchisation.



Deuxièmement, si vous êtes un leader, alors un problème se pose - une seule et même chose peut être faite de très nombreuses manières différentes. Et vous devez comprendre comment revoir ce que vos subordonnés ont fait.



J'ai une discussion sur notre système d'examen. Là, je parle plus en détail du fonctionnement de notre RPG interne: avec les niveaux, les niveaux, les notes, etc.

Cycle de la vie

Parlons du cycle de vie. En fait, je vais passer à une exposition de la façon dont cela fonctionne dans notre pays.







J'ai ramassé de telles images. Que voyons-nous ici? Beaucoup connaissent sûrement les étapes du cycle de vie de presque tout - nous visons, tirons, regardons là où nous frappons. Habituellement, dans le monde Agile, c'est comme la planification de sprint. Ou rétro, ou démo - qui peut le faire.







Mais j'aime concevoir des processus afin que les choses complexes puissent être exprimées à travers des formules et des principes simples et mises à l'échelle fractalement. L'image avec la fractale de Mandelbrot nous fait allusion à ce sujet.



Qu'avons-nous? Différentes parties de notre fractale de processus. Il y a des intervalles de révision de six mois par les employés.







Tous les trois mois - à mi-parcours, où nous résumons les résultats intermédiaires de la période d'examen.







Une fois par mois, il y a des feux verts où les équipes racontent aux équipes concernées ce qui s'est passé sur les cibles. Ceci est nécessaire pour que les commandes soient synchronisées les unes avec les autres.







Et ces sprints de deux semaines.







Comme vous pouvez le voir, le résultat est une image fractale, très similaire à la méthodologie que vous devez d'abord viser, comprendre exactement ce que vous allez faire, le faire, puis regarder le résultat.







Ceci est très important car les personnes qui donnent les conseils susmentionnés de la sagesse populaire sont fermées dans l'image du milieu. Ils tirent juste. Plus ou moins ils ne visent pas, plus ou moins ils ne regardent pas là où ils ont frappé. Et cela donne des processus beaucoup moins prévisibles et contrôlables que si vous suivez ces trois étapes simples.



C'est comme si chaque rapport devrait avoir une introduction, un corps et une conclusion. De même, chaque action ciblée doit avoir un objectif, une exécution et un résumé.







Pour que ces résultats puissent être résumés, de sorte que l'établissement d'objectifs puisse également être fait, afin de viser correctement, vous avez besoin d'une propriété aussi importante que la mesurabilité.



Dans l'histoire de la mesurabilité, je donnerai un anti-exemple. J'ai un concept ailé (au sein de Yandex) - des objectifs "case à cocher".

Objectifs de la case à cocher

C'est un anti-modèle. Vos objectifs ne sont probablement pas très bons s'ils ressemblent à "créer une nouvelle version du composant X", "démarrer le service Y" ou "refactoriser Z". Pourquoi est-ce mauvais?

• , , . . , , , - : , , , , . , .
  
  
  
  «», — X? ?
• , . , , . — « X», - .
• L'évaluation du résultat devient plus compliquée. Par exemple, vous devez évaluer deux équipes. Sans un processus d'examen et d'étalonnage, vous ne pourrez pas constater qu'une équipe a travaillé comme un blooper, à la MVP, et la seconde a tout bien fait, pendant des siècles et dans les moindres détails.

Par conséquent, ma recommandation est d'essayer d'éviter les objectifs de "case à cocher", d'essayer de les traduire dans un plan plus mesurable.

Créer une métrique et définir des cibles fait partie du travail sur un objectif

La question peut se poser que quelque chose est très difficile à mesurer. Et parfois, vous devez commencer à courir. Il est déjà clair que le service X ou la refactorisation Y doit être fait, mais il n'y a toujours pas de métrique qui permettrait de mesurer cela. Nous ne comprenons pas quels objectifs nous voulons nous fixer comme image cible. Comment être?



Nous utilisons le modèle selon lequel le processus même de création de métriques et de détermination des cibles fait déjà partie du travail sur l'objectif. Il n'est pas nécessaire de bloquer le début du travail sur un objectif si vous ne l'avez pas formulé complètement.







Je vais vous donner quelques exemples tirés de nos objectifs réels. Yandex a une équipe qui s'occupe de la soi-disant beauté de la faucille, la rendant plus belle. Lorsqu'elle est apparue, il n'y avait qu'une idée générale. Ici, vous êtes tellement de gens, faites-le.



L'équipe ne savait même pas ce qu'est la beauté et combien de pour cent de cette beauté inconnue peut être changée. Cependant, ils ont commencé à travailler en parallèle. Il y avait une opinion intuitive que certaines choses sont plus belles, et faisons ceci. Et en parallèle, ils ont commencé à mettre au point un système qui mesurerait cette beauté même. Et en conséquence, nous avons obtenu un système, une métrique, dont Anton Vinogradov a parlé dans son rapport «Yandex Beauty: Design for Millions»:





L'essence du système: nous faisons une comparaison côte à côte de l'ancienne version et de la nouvelle. Ensuite, nous calculons la somme des changements positifs de chacune de nos implémentations sur une certaine période de temps.



Au cours du premier semestre de travail sur cet objectif, nous avons formulé une métrique. Nous avons fait une vue en pourcentage - un peu du plafond. Au semestre suivant, en fonction de nos performances, nous avons déjà compris comment cette métrique se déplace, quelles implémentations l'affectent, ce que vous pourriez souhaiter.







Le deuxième exemple dans le contexte du travail sur les métriques est l'un de nos plus anciens contours, l'équipe qui s'occupe de la vitesse des interfaces.



Quand il a commencé, il y avait aussi un message général: veuillez accélérer le chargement de la faucille. Mais comment mesurer si c'est rapide ou pas? Il y avait des plaintes comme: «Je l'ouvre sur mon téléphone, il me semble que quelque chose est lent. Les moteurs de recherche des concurrents sont plus rapides! " Pour commencer à faire ce travail, il n'était pas nécessaire de formuler exactement la métrique. Nous savions des choses banales: si vous envoyez beaucoup d'octets sur le réseau, exécutez beaucoup de code en JS, cela prendra beaucoup de temps. Commençons par faire quelque chose, et en cours de route, collectons de véritables métriques, comprenons comment nous allons les mesurer.



Il existe également un rapport à ce sujet. Andrey Prokopyuk a parlé de tous nos détails sur la façon dont la vitesse est mesurée sur de vrais utilisateurs et sur des mesures synthétiques à l'intérieur:





En même temps, les gars ont travaillé pour atteindre un objectif significatif: réduire ces mêmes octets.

Mesurez l'incommensurable

La prochaine question qui peut se poser: eh bien, nous voulons mesurer et c'est plus ou moins clair à la vitesse du frontend - il y a une règle qui nous permet de détecter les octets. Mais comment mesurer quelque chose de généralement incommensurable? Avec la beauté que vous avez imaginée côte à côte, et s'il n'y a rien? Par exemple, vous devez mesurer le bonheur des utilisateurs dans le développement interne.







Tout d'abord, cela vaut la peine de réfléchir à nouveau. Comme je l'ai dit, avec la même beauté qui semblait subjective, nous avons pu en déduire une métrique plus mesurable.



Deuxièmement, vous pouvez penser aux métriques proxy. Ici, je vais également vous envoyer vers votre moteur de recherche préféré: vous pouvez trouver de nombreux articles sur ce qu'est une métrique proxy et comment la sélectionner. En bref, la métrique proxy vous permet d'approcher indirectement votre situation réelle, de faire des hypothèses telles que: "Si nous continuons à être beaucoup utilisés, notre interface n'est probablement pas si mauvaise."



Il est clair que cela comportera un certain degré d'erreur et de permissibilité. Mais si vous imposez un nombre suffisant de métriques proxy, vous pouvez au final obtenir une approximation suffisamment bonne, qui ne nécessitera pas la création d'une métrique complexe importante.



Cette dernière a été suggérée dans les commentaires de mon rapport précédent: vous pouvez toujours réunir un jury d'utilisateurs ou d'experts pour l'un des sujets les plus incommensurables et leur demander de les noter sur une échelle. Faites-le régulièrement et obtenez ainsi un système de coordonnées, une métrique reproductible qui vous permettra de comprendre si vous progressez correctement. Même cette métrique sera toujours meilleure que ces objectifs de "case à cocher". Comme Porthos: "Je me bats juste parce que je me bats!"



Quelques mots clés pour faciliter les enquêtes auprès des utilisateurs: csi nps. Mais je pense que l'idée est claire.

Métrique Antibug

Un autre exemple concerne la métrique antibug. Nous avons un processus spécial qui nous permet d'améliorer la qualité de nos interfaces et de réduire les bogues.



Maintenant, je vais vous dire comment cela fonctionne. Plusieurs points peuvent y être illustrés.







Tout d'abord, nous avons construit des graphiques récapitulatifs du nombre pondéré de bogues pour les équipes. Autrement dit, nous comptons le nombre de bogues émergents dans la fenêtre flottante et leur attribuons des pondérations proportionnelles à leur priorité. Nous avons des mineurs, des triviaux, des normaux, des critiques et des bloqueurs qui diffèrent les uns des autres d'un ordre de grandeur. Le mineur et le trivial ont un poids de 1, le normal en a 10, le critique en a 100 et le bloqueur en a 1000. Le résultat est un graphique qui reflète le nombre de bogues actuellement sur le service, en tenant compte de leurs priorités.



Deuxièmement, nous avons commencé à créer de tels graphiques séparément pour les bogues que l'équipe elle-même et les testeurs de l'équipe ont trouvés, et pour ceux qui ont été signalés par des utilisateurs externes. Ensuite, nous avons suspendu le composant de la cible, réalisé la cible. En nous, ce processus est appelé politique zéro bogue. Mais il est clair que zéro est un idéal irréalisable, et chaque équipe peut avoir un zéro différent à tout moment. Là, un seuil est défini - que le poids ne dépasse pas 50 ou 100.



Si une équipe commence à peine à travailler sur un antibogue, nous disons qu'il doit être réduit de 20% chaque mois. Il y a six mois dans un semestre, cinq mois pour une réduction de 20%, plus un mois supplémentaire pour conserver ce résultat. Ainsi, il est possible pour un semestre d'atteindre la valeur cible et d'avoir un petit nombre de bugs.



La métrique antibug est de 20% basée sur le principe qu'il devrait y avoir plus de bogues trouvés seuls que de bogues utilisateur. Autrement dit, les tests sur le projet devraient mieux fonctionner et les utilisateurs devraient trouver moins de bogues que nous.



Le dernier critère est le respect du SLA de clôture. Même si vous n'avez pas beaucoup de bogues, mais qu'ils sont suspendus depuis longtemps, cela peut agacer les utilisateurs: le nombre de personnes affectées par un bogue en production augmente chaque jour jusqu'à ce que ce bogue soit corrigé.



Et voici deux points. Outre la méthodologie de mesure, d'estimation de ce poids et du nombre de bogues, il existe un autre exemple de la façon dont vous pouvez combiner plusieurs critères différents en une seule métrique.



Vous mettez simplement des poids et des pourcentages sur ces critères et dites que l'un affecte 40%, le deuxième 20%, le troisième 40%. En voici un exemple, et cette métrique permet de répartir plus ou moins un travail unifié sur l'antibug entre des dizaines d'équipes dans Yandex.







Nous revenons au mot-clé «équilibre». Vous devez essayer de le trouver. Je vais vous parler de plusieurs équilibres, dont vous devez garder à l'esprit le fait même lorsque vous êtes engagé dans le processus de fixation d'objectifs.



Le premier est un équilibre entre «trop peu d'objectifs» et «trop d'objectifs». Il ne devrait pas y avoir trop peu d'objectifs, car ce ne sera pas assez ambitieux pour l'équipe. Vous n'utiliserez tout simplement pas votre plein potentiel. Trop est aussi mauvais: à partir d'un moment donné, la surcharge de reconnaissance et de maintien d'un objectif deviendra trop importante. Ils s'accumuleront au total et vous dérangeront.







Nous en avons quelques exemples. Par exemple, il y avait une équipe composée de huit personnes. Ils avaient environ six buts. Ils ont dit: «En tant qu'équipe, nous ne pouvons pas suivre six cibles à la fois. Nous devons les suivre sur les feux verts, comprendre en permanence si chacun d'eux progresse bien avec nous. Divisons-nous en deux équipes de quatre et distribuons ces trois buts à une équipe, les trois autres à une autre. C'est une méthode de travail qui vous permet en fin de compte de concentrer les gens un peu plus étroitement sur un objectif spécifique.



Le prochain équilibre est l'équilibre entre nos désirs et nos capacités. S'il n'y a pas d'équilibre dans une équipe engagée dans l'établissement d'objectifs, il y a très souvent un biais dans un sens ou dans l'autre. Supposons que vous ayez une haute direction forte et qu'il vous dise: "Nous devons absolument le faire." Et tous les objectifs sont fixés à partir de nos désirs - nous voulons que cela se produise, et tout ce que vous voulez, "retirez-le et posez-le". Une telle situation peut être lourde du fait que ces désirs ne seront pas alignés avec la réalité et ne seront tout simplement pas satisfaits.



De plus, le déséquilibre est si les marins ont pris le pouvoir sur le navire. Ensuite, l'équipe tentera de formuler des objectifs de manière à ce que tout soit précisément garanti. Comme je l'ai dit, cela entraîne une sous-utilisation de votre potentiel. Il devrait toujours y avoir un défi, un moyen de sortir de votre zone de confort, un point où vous atteignez. Par la tension, l'évolution se produit. Il est important que cette tension ne soit pas telle que vous vous déchiriez les ligaments. Il devrait se développer. Et cet équilibre doit être recherché.



Il existe également un équilibre entre ce que l'on appelle la largeur et la profondeur. Il y a toujours un choix, ce qui est mieux: définir un objectif en détail, mais un seul, ou atteindre de nombreux objectifs, mais en fin de compte, ne pas avoir le temps de travailler sur chacun d'eux au moins dans une certaine mesure. Il n'y a pas de conseil universel ici, car les situations de vie sont très différentes. Certains fils sont très importants à supporter au moins d'une manière ou d'une autre, et dans ce sens, la largeur est nécessaire. Par exemple, se brosser les dents, manger, faire du sport, travailler sont tous des fils tout aussi importants. Ici, il est impossible de dire - laissez-moi me brosser les dents très bien le premier mois, trois fois par jour, le mois prochain je vais très bien faire du sport, etc.



Mais il y a aussi des situations inverses, quand il est important pour nous de travailler jusqu'au bout, il est bon de clore un problème et de passer à autre chose. Et ne commencez pas deux réparations en même temps. S'il y a une telle opportunité, vous pouvez d'abord faire une chose, bien investir, la suivre, puis en faire une autre.



Il nous faut un équilibre entre les deux formulations: «se réorienter dans le temps vers la réalité changée» et «se rendre aux premières difficultés». Parfois, vous pouvez commencer à faire quelque chose et constater que les tâches sont plus difficiles que prévu. Ou des facteurs externes se sont produits, tels que le coronavirus ou autre chose. Il est très tentant, en étant guidé par le principe Agile, de s'adapter de manière flexible à la réalité changée et, par exemple, de sous-estimer son KPI, d'abandonner certains objectifs ou autre chose. Nous nous trouvons ici dans la même situation que dans la fixation d'objectifs initiale, uniquement dans la dynamique.



Assurez-vous de ne pas abandonner aux premières difficultés, même en dynamique, lorsque vous continuez à modifier la répartition du poids des cibles, mais aussi de ne pas vous cogner la tête contre le mur lorsque cela ne donne plus de résultat.



La dernière chose dont je veux parler sur cette diapositive est l'équilibre entre les différents objectifs. Parfois, les objectifs commencent à entrer en conflit les uns avec les autres.



Dans ce lieu particulier, nous avons des méthodologies claires pour échanger l'une contre l'autre. Mais il est également important d'évaluer le reste, les mêmes objectifs contradictoires à une distance suffisante. Sous quelle forme pourrait-on échanger l'un contre l'autre?







Et quelques analogies et images de ce genre sur l'équilibre. Il, dans la forme sous laquelle je le formule pour moi-même, est de deux types:

1. « ». — , , - — , .
   
   
   
   , . : « , ». , , . , : .
2. «». , , . . , : - . , , . , , .

À la fin, je voulais reproduire tout ce que j'ai dit et vous montrer à nouveau les diapositives. Mais ils n'étaient pas si nombreux et ils semblent plus ou moins compréhensibles.



Un bref résumé de l'ensemble du rapport: l'établissement d'objectifs est difficile. Vous constaterez peut-être que l'établissement d'objectifs lui-même prend beaucoup de temps. Mais ça vaut le coup! Au moins, c'est mon jugement de valeur basé sur mon expérience personnelle.



Je suis très heureux que nous soyons généralement parvenus à un système avec des objectifs et que nous continuions à l’évoluer et à l’améliorer. Tous ces efforts, il me semble, portent leurs fruits.



Il pourrait y avoir une publicité pour notre ou l'un de vos outils, car il est possible d'utiliser n'importe quel outil pour effectuer des tâches ou des objectifs. Recherchez simplement dans votre moteur de recherche préféré [le nom de votre outil, l'espace, les cibles]. Vous trouverez sûrement un article qui décrit exactement comment procéder. Merci de votre attention. Je vous souhaite à tous le même succès que dans ce gif.