Les processus de développement sont un sujet de discussion constant au sein des équipes et lors de diverses conférences. Et, bien sûr, leur optimisation est un casse-tête constant pour tous ceux qui contrôlent en quelque sorte le développement.
Une fois, j'étais développeur junior et je n'aimais vraiment pas le mot «processus». Toutes ces réunions régulières et autres communications semblaient absurdes, distrayant du travail de fond (rédaction de code, bien sûr). Je pense que cette étape s'est produite dans la vie de tous ceux qui étaient engagés dans le développement; mais il est utile de répéter cette étape régulièrement: toute activité peut être optimisée (par exemple, en l'annulant complètement), et parfois le sentiment de non-sens de ce qui se passe a un véritable effet curatif.
Nous avons décidé de consacrer notre prochain Meetup Team Leader aux processus de développement, qui auront lieu dans la soirée du 17 juin au bureau de Yandex à Moscou. L'inscription est ouverte!
Nos experts ont convenu d'être:
- Anatoly anatolix Orlov, directeur technique, Ozon
- Alexey Kataev deusdeorum , responsable du développement logiciel, SkyEng
- Alexander Gutman, directeur technique, JoomPay
- Evgeny Paramonov, responsable du développement du mixage de recherche, Yandex
- Andrey Plakhov yafinder , responsable des fonctionnalités de recherche, Yandex
Aujourd'hui, ils répondent à quelques questions afin de préparer une future discussion:
1. Sur quelle base les processus sont-ils construits dans votre entreprise?
2. D'après votre expérience, quel pourcentage de réussite de l'équipe est déterminé par les bons processus et quelle est la compétence individuelle?
3. Y a-t-il des situations dans lesquelles le chef d'équipe a parfaitement le droit d'ignorer des processus?
4. Racontez une histoire effrayante de votre expérience avec le mot «processus»
Under the cut - beaucoup de feu, des sarcasmes adressés aux auteurs de questions, les opinions les plus diverses et, bien sûr, des histoires effrayantes.
1. Sur quelle base les processus sont-ils construits dans votre entreprise?
Nous essayons de construire tous les processus de manière à ce que le moins de temps possible passe de l'idée à la mise en œuvre. Dans la communauté de la programmation, cette approche est appelée "fig-fig et en production", et utilise souvent cette expression de manière négative. Dans le même temps, d'un point de vue commercial, il est beaucoup plus raisonnable de lancer rapidement un projet ou une fonctionnalité, de tester une hypothèse et, si tout fonctionne, de l'ajouter à l'état cible.
Cette idéologie sous-tend tous les processus: des microservices qui sont commodément déployés séparément; déployer automatiquement par fusion dans une succursale; des équipes verticales qui contiennent le produit, des programmeurs, des testeurs et des designers assis ensemble et ayant le droit de ne pas coordonner avec quiconque en dehors des changements dans leur domaine de responsabilité, etc.
2. D'après votre expérience, quel pourcentage de réussite de l'équipe est déterminé par les bons processus et quelle est la compétence individuelle?
L'intérêt est mauvais. Probablement, cela vaut le calcul de faire quelque chose comme ceci: les compétences déterminent la complexité des systèmes que vous pouvez exécuter, la productivité individuelle des spécialistes - la vitesse à laquelle vous pouvez le faire. Et les mauvais processus et l'architecture ralentissent le travail, c'est une taxe sur l'inefficacité. La taxe peut être n'importe laquelle, en principe, dans certaines entreprises, même 100% arrive, mais ces organisations ne vivent généralement pas longtemps (si ce n'est pas «GBU Housing Sviblovo», bien sûr).
3. Y a-t-il des situations dans lesquelles le chef d'équipe a parfaitement le droit d'ignorer des processus?
Toujours. Si vous comprenez que le processus vous dérange, mais ne vous aide pas, vous devez le changer. D'un autre côté, cela ne signifie pas que vous pouvez prendre une telle décision seul: convenez-en avec vos collègues, et si nécessaire, avec vos supérieurs, afin qu'il ne s'avère pas que vous travaillez sur un nouveau processus, et que l'équipe et toute l'entreprise sont sur l'ancien, et en conséquence, rien ne fonctionne du tout.
4. Racontez une histoire effrayante de votre expérience avec le mot «processus»
Permettez-moi de mieux écrire sur le principe de l'inversion de processus avec quelques exemples effrayants. Les programmeurs sont bien conscients du principe de l'inversion de dépendance, et donc le processus a la même chose.
Vous devez l'appliquer approximativement dans les cas suivants: disons que vous venez aux RH pour ouvrir un poste vacant, et ils vous demandent de remplir un questionnaire de 5 pages sur qui vous allez chercher. Ou vous venez demander de l'argent pour quelque chose de manifestement nécessaire, et vous êtes invité à rédiger un mémo.
Ce processus s'avère souvent brisé et bureaucratique, car la rédaction d'un questionnaire est pour vous, et il facilite la vie (ou même pas) pour les autres. En conséquence, nous n'avons aucun mécanisme pour convenir de ce qui devrait être dans le questionnaire - 2 lignes ou 5 pages.
L'application du principe d'inversion de processus ressemble à ceci: il est nécessaire qu'une personne explique pourquoi elle doit ouvrir un poste vacant, et les RH ont rempli lui-même le questionnaire, ou les finances - une note officielle. Habituellement, dans ce cas, il s'avère que toute la journée, vous ne voulez pas remplir de questionnaires de 5 pages et rédiger des mémos, et le processus devient immédiatement efficace, sans aucune conséquence. Et pour le client final, le processus se transforme en «écrire une phrase commune cohérente dans un outil de chat fonctionnel».
Alexey Kataev deusdeorum , responsable du développement logiciel, SkyEng
1. Sur quelle base les processus sont-ils construits dans votre entreprise?
Nous avons 284 dépôts sur le github: vous pouvez trouver du code dans n'importe quel langage de programmation. Parmi nos 20 équipes de développement, vous pouvez même trouver des cascades. La formation des processus était auparavant laissée aux timlids: le démarrage rapide du projet et le développement de la plateforme centrale avec une histoire de 7 ans nécessitent une approche différente. Lors des réunions hebdomadaires des chefs d'équipe, nous avons échangé les meilleures pratiques et elles se sont lentement répandues dans toute l'entreprise.
À l'échelle actuelle, cela ne fonctionne pas: certains chefs d'équipe manquent d'expérience, d'autres manquent de temps. L'entropie croissante commence à poser des problèmes. L'année dernière, j'ai étendu nos meilleures pratiques à toutes les équipes, en équilibrant les ventes et «le faire est définitivement une bonne chose». Il est plus facile de mettre en œuvre les bons processus lors de la création d'une équipe, c'est encore plus facile lorsqu'un chef d'équipe se détache d'une équipe performante: vous n'avez pas besoin d'expliquer ou de vendre, il sait que cela fonctionne.
2. D'après votre expérience, quel pourcentage de réussite de l'équipe est déterminé par les bons processus et quelle est la compétence individuelle?
D'après mon expérience - 100%. Même si un développeur seul écrit du code pour lui-même, il suit toujours le processus, bien que simple. Si vous reformulez la question: «combien pouvez-vous oublier l'équipe de développeurs sympas en changeant les processus», ma réponse sera «très forte». Il est important de commencer non pas par le processus de révision du code, l'augmentation des salaires et la rétroaction, mais par les éléments de base - la planification, la priorisation, la communication avec l'entreprise. Soit dit en passant, de nombreux développeurs sympas sans processus d'embauche sympa n'apparaîtront pas d'eux-mêmes.
3. Y a-t-il des situations dans lesquelles le chef d'équipe a parfaitement le droit d'ignorer des processus?
Lorsqu'une situation imprévue survient pour laquelle personne n'est prêt. Je me souviens immédiatement de l'ILV, qui interdisait autrefois des dizaines de nos API sur Amazon. Nous avons ensuite oublié Kanban, le réglage correct des tâches et dans le mode de téléphonie constante, nous avons élaboré un plan d'action à la volée. En une journée, tout a été restauré.
4. Racontez une histoire effrayante de votre expérience avec le mot «processus»
Il y a une histoire effrayante sur la façon dont le superviseur a infiniment respecté le processus du consommateur qui a payé le salaire. Et il est tombé avec une erreur, réussissant à envoyer une demande au portail de paiement. Mais je ne peux pas lui dire en public :)
1. Sur quelle base les processus sont-ils construits dans votre entreprise?
Les processus de notre entreprise ne font qu'émerger.
Pour la planification trimestrielle, nous utilisons OKR.
Ci-dessous, nous utilisons des cartes YouTrack et Agile pour planifier le développement. Nous utilisons le kanban. Pas dans le sens de "s'embêter avec le nombre maximum de tâches dans chaque état", mais dans le sens de "paresse pour transférer des tâches de sprint à sprint". Le prédécesseur de YouTrack avec des planches était une plaque en Excel avec toutes les tâches et responsable. Et cela a bien fonctionné aussi.
2. D'après votre expérience, quel pourcentage de réussite de l'équipe est déterminé par les bons processus et quelle est la compétence individuelle?
Il semble que la question contienne une présomption selon laquelle le succès de l'équipe est déterminé exclusivement par les bons processus et compétences, et le pourcentage devrait être de 100.
Mais il existe d'autres facteurs importants: les ressources ou, par exemple, aléatoires. Par conséquent, je répondrai: 10% de processus et 10% de compétence.
En revanche, on ne sait pas très bien comment appeler le pourcentage d'influence de chaque facteur. Presque tous les projets complexes peuvent échouer avec de mauvais processus ou un manque total de compétences individuelles. Par conséquent, ma réponse est: 99% de processus et 99% de compétence.
D'un autre côté, si nous parlons de projets non triviaux et de concurrence entre les équipes, les processus sont ennuyeux et tout le monde devrait avoir des processus raisonnables, mais les compétences individuelles peuvent devenir un facteur de différenciation. Par conséquent, la réponse finale: 10% de processus et 20% de compétence.
3. Y a-t-il des situations dans lesquelles le chef d'équipe a parfaitement le droit d'ignorer des processus?
Il y a des situations où n'importe qui peut ignorer quoi que ce soit. En particulier, chef d'équipe - tout processus.
Mais je n'isolerais pas un chef d'équipe comme ça. Ici, nous avons besoin d'un consensus au sein de l'équipe: les processus sont imparfaits, les règles ne sont pas universelles, vous devez être guidé par le bon sens.
Dites, vous devez déployer le correctif pendant la frise, car c'est logique, et non pas parce que le chef d'équipe a le droit. Même si vous n'êtes pas d'accord à ce sujet à l'avance et qu'il n'y a pas de règle pour ce cas.
4. Racontez une histoire effrayante de votre expérience avec le mot «processus»
Une fois, on m'a demandé de répondre à la question "Racontez une histoire effrayante à partir de votre expérience avec le mot" processus "."
Evgeny Paramonov , responsable du développement du mixage de recherche, Yandex
1. Sur quelle base les processus sont-ils construits dans votre entreprise?
Nous aimons les principes de l'agilité. L'équipe construit tout notre travail de manière à maximiser la réalisation des objectifs de l'entreprise et le moral de l'équipe dans les plus brefs délais.
Comme l'un des principes de l'agilité stipule que «les personnes et l'interaction sont plus importantes que les processus et les outils», la première chose que nous avons faite a été de corriger les règles de base de la mêlée.
Au sein de l'équipe, nous promouvons les principes suivants:
- Chacun de nous est à la fois bûcheron et bijoutier (analyste / testeur / développeur)
- Chacun de nous a ses forces (aidez un ami / n'hésitez pas à demander)
- Chacun de nous détermine à quoi ressemblera le produit final (chaque direction en a une responsable)
Les développeurs analysent indépendamment les tâches, les testent et démarrent des expériences ABT. Avec CI / CD, c'est un groupe de tueur, il nous permet d'avancer le plus rapidement possible, car chaque développeur possède le contexte entier. Par exemple, déjà pendant l'expérience, une nouvelle fonctionnalité ingénieuse lui vient à l'esprit, il l'implémente rapidement, la fait rouler et mène une autre expérience.
Pour chaque mois, nous nous fixons un objectif que nous voulons atteindre et vérifions chaque semaine la progression. Cela nous donne de la flexibilité. même pendant la semaine, nous pouvons changer nos plans si cela aide à atteindre l'objectif du mois.
Avec cette organisation du processus, l'implication des managers est minimale et l'équipe gagne en mobilité et en engagement à long terme.
2. D'après votre expérience, quel pourcentage de réussite de l'équipe est déterminé par les bons processus et quelle est la compétence individuelle?
Le temps avance, le monde change et nos processus évoluent avec lui.
La maîtrise c'est:
- établir un processus qui fonctionne sur le résultat;
- faire ressortir le problème dans les processus actuels et le résoudre;
- Faire comprendre aux gens pourquoi le processus est structuré de cette façon.
En prenant mon équipe comme exemple, je peux affirmer avec une grande confiance que ce rapport est de un pour un dans la région.
Mon équipe s'occupe immédiatement de trois domaines mondiaux: la recherche, l'apprentissage automatique et l'infrastructure (et, en fait, également le travail d'épicerie).
Dans ces domaines, il est assez difficile de construire des processus à l'avance pour tous les scénarios possibles. Souvent, le succès est fortement déterminé par l'intuition professionnelle de l'artiste et de son conservateur.
3. Y a-t-il des situations dans lesquelles le chef d'équipe a parfaitement le droit d'ignorer des processus?
Si les processus sont construits avec compétence, cela est peu probable. Un processus construit avec compétence repose très probablement sur les erreurs des autres.
Mais, comme je l'ai dit ci-dessus, nous continuons d'avancer et le monde change, donc tôt ou tard il y aura une situation où le processus devra être ignoré ou changé.
Timlid est responsable de la contribution de son équipe à la réalisation des objectifs de l'entreprise, et s'il comprend qu'ici et maintenant il est nécessaire d'agir, et que les processus actuels ne sont définitivement pas prêts pour une telle situation, il doit définitivement emprunter une nouvelle voie. Avec ce choix, il vaut la peine d'informer de leurs actions tous ceux qu'ils peuvent affecter.
Considérons une situation fictive:
- le gestionnaire a accidentellement apporté des modifications au fichier de configuration et l'a déployé automatiquement après 15 secondes;
- la recherche devient impossible à utiliser, 100% des utilisateurs en souffrent;
- Timlid et le développeur sur appel surveillent les appels et vérifient que tout va mal, car les erreurs sont versées dans le journal et il est clairement clair quel composant a été endommagé.
Dans ce cas, l'instruction est construite aussi mal que possible et lit:
- obtenir un billet;
- y attacher toutes les informations et analyses de débogage;
- le réparer via codreview.
Si nous allons dans cette direction et supposons même que nous le faisons très rapidement, cela prendra au moins 5 minutes, cinq minutes de souffrance pour les utilisateurs en direct!
Dans cette situation, chaque seconde est comme la mort pour nous. Vous devez agir dès maintenant. S'il est possible d'annuler cette configuration, lancez-la. Sinon, désactivez l'intégralité du composant. Ici et maintenant. Actes - plus tard.
4. Racontez une histoire effrayante de votre expérience avec le mot «processus»
Une histoire terrible avec le processus de mots s'est produite lorsque nous étions jeunes et verts. Nous avons entendu le mot agile - élégant, à la mode, jeunesse. Et ils ont introduit les sprints.
Au début, c'était amusant: un nouveau type de planification est apparu. Ensuite, les tâches ont commencé à passer d'un sprint à l'autre. Le directeur nous a demandé: "quand?" Nous avons répondu: "demain". Le timing s'est multiplié, bien sûr, par trois, mais nous ne nous sommes toujours pas adaptés aux sprints.
Petit à petit, nous avons commencé à perdre la moralité. Tâches empilées; le gestionnaire n'a pas compris ce qui se passait; la situation devenait ingérable. En conséquence, nous avons pendant un certain temps abandonné les méthodologies flexibles.
La morale de cette histoire est la suivante: avant d'introduire un nouveau processus, vous devez comprendre clairement pourquoi cela est fait et comment il est meilleur que l'état actuel des choses.
Andrey Plakhov yafinder , responsable des fonctionnalités de recherche, Yandex
1. Sur quelle base les processus sont-ils construits dans votre entreprise?
Yandex est une très grande entreprise et très, très démocratique. Quelle que soit la généralisation que j'écris ici, il y a quelque part le service Yandex.Botinki, qui se révèle être complètement différent.
Dans les endroits que j'observe, ça fonctionne comme ça. Il existe une norme stricte pour les processus à grande échelle. Il est clairement écrit comment les objectifs des unités sont déterminés pour une période de six mois à un an, comment nous nous entendons sur ce qu'il faut considérer comme un succès et ce qui est un échec. Comment il est établi, modifié et ce que le grade de l'employé affecte, comment les primes et les options sont payées, comment l'embauche et la transition entre les départements, etc.
Mais au niveau de la microgestion presque partout, selon les règles que l'équipe vivra, elle se détermine. La tournure des tâches, le calendrier et le contenu des réunions de travail, certains stand-ups là-bas, les sprints, c'est tout. Quelqu'un s'organise un idéal «comme dans un livre», pour certaines petites équipes, au contraire, l'anarchie. Cependant, même les plus anarchistes se rendent compte à un moment donné que vivre «comment ça marche» n'est pas optimal. Et comme les gens sont intelligents, cela vient rapidement. Ici, pour autant que je sache, il n'y a pas de cascades (bien que je ne garantisse pas les équipes impliquées dans le fer).
En tant que chef de département, j'exige une norme plutôt modeste pour les processus dans mon département: il devrait être possible à tout moment de voir qui a quelles tâches spécifiques dans son travail, combien de temps il reste dans cet état et qui a récemment fermé quelles tâches. Pour ce faire, il suffit d'utiliser le tableau Kanban en ligne en plus du tracker de tâches standard de l'entreprise (en théorie, ce n'est pas nécessaire, mais en pratique, toutes les équipes y arrivent en conséquence).
2. D'après votre expérience, quel pourcentage de réussite de l'équipe est déterminé par les bons processus et quelle est la compétence individuelle?
En général, la chose la plus importante est la réussite du modèle d'entreprise. Si l'organisation n'a pas compris quoi vendre, à qui et comment, alors ni les processus idéaux ni les développeurs ingénieux ne l'aideront. Par conséquent, supposons que l'entreprise fonctionne, et nous parlons de développement à long terme, de qualité des produits, de diversification, etc.
Ensuite, la réponse dépend beaucoup de la taille de l'équipe. Le succès d'une équipe de cinq personnes est presque entièrement déterminé par les gens. Le succès d'une entreprise de cinq cents ou plus est déterminé à près de cent pour cent par la bonne organisation. Culte du fret, lorsqu'une petite startup essaie de respecter les règles inventées par, disons, IBM, cela peut être tout aussi néfaste que le principe Peter lorsqu'un ancien «lien» devient un «centurion», mais essaie de vivre à l'ancienne.
Il faut aussi dire que des équipes très fermées de plusieurs personnes sont assez représentables à l'intérieur des géants industriels géants. Mais cet état de fait, malheureusement, combine les pires aspects des deux mondes, et non l'inverse. Un groupe de personnes faibles ne maîtrisera rien de sensible, même sur une infrastructure prête à l'emploi, et le mauvais processus répandra l'équipe star sur les engrenages, et personne ne le remarquera.
3. Y a-t-il des situations dans lesquelles le chef d'équipe a parfaitement le droit d'ignorer des processus?
Bien sûr, ils le font, et le mot «feu» est très approprié ici. Si:
- situation d'urgence
- se détériore rapidement s'il est laissé au hasard,
- et il peut être aidé par une intervention rapide et décisive,
alors au diable les règles et la "justesse"!
L'essentiel est que de telles situations ne donnent pas du plaisir à Timlid, sinon nous courons le risque de découvrir après un certain temps que les incendies autour de lui se produisent beaucoup plus souvent que la moyenne de l'organisation. Il est totalement incompréhensible pourquoi. Une sorte de mysticisme.
4. Racontez une histoire effrayante de votre expérience avec le mot «processus»
Le processus le plus terrible de ma vie que j'ai rencontré il y a longtemps, même avant Yandex, lorsque je développais des jeux informatiques. Plus d'une centaine de personnes ont travaillé sur le premier jeu d'une entreprise jeune mais riche et très ambitieuse qui venait d'emménager dans un nouveau bureau. De plus, tout gaspillage de toute somme d'argent aurait dû être approuvé par le PDG. Acheter 50 serveurs? Remplacer une chaise cassée par une nouvelle pour un programmeur? Commandez le déjeuner la semaine prochaine? Le chef de bureau a-t-il manqué de trombones? Une seule et même personne décide de tout, des piles de documents poussent sur la table. Comme vous pouvez le deviner, les interruptions dues à un tel «processus» se sont produites même avec du papier toilette. Pour bien imaginer l'horreur de ce qui se passe, il convient d'ajouter que le directeur général a combiné ce rôle avec le rôle de directeur créatif (comme le dirait SRO maintenant) et avec le rôle du concepteur en chef du jeu ...
La prochaine réunion, pour laquelle vous pouvez toujours vous inscrire , aura lieu le 17 juin 2019 au bureau de Moscou de Yandex. Il sera possible de poser des questions aux intervenants et de partager leur expérience.