Comment les stratégies chinoises aident au travail

Notre travail quotidien est souvent comme une série de confrontations. Nous nous «battons» avec les clients et les autres équipes, avec les testeurs et les collègues, et les départements de l'entreprise se font concurrence. Nous nous battons pour les salaires, prenant des décisions techniques pratiques, des délais et des milliers d'autres choses. Dans cette série de conflits, le chef d'équipe est le chef d'une petite unité de combat, l'équipe. Il connaît les forces et les faiblesses de chaque "ordinaire", coordonne et organise leur travail afin d'atteindre des objectifs avec un minimum de pertes.

Si vous regardez le travail du chef d'équipe de ce point de vue, la planification stratégique et le travail de position au sein de l'équipe et au-delà sont importants. Dans le même temps, n'oubliez pas les tactiques. De façon inattendue, la connaissance des anciens stratagèmes chinois aide à planifier une stratégie et à réagir tactiquement.



Alexey Zolotykh ( zolotyh ) - chef d'équipe dans Infobip. Alexey utilise dans son travail les règles de guerre de la Chine ancienne. À partir d'un article basé sur son rapport sur Saint TeamLead 2019 , vous apprendrez comment les stratagèmes aident la vie d'un chef d'équipe: comment faire la paix avec un développeur au sein d'une équipe, comment gagner en crédibilité auprès de ses collègues, comment défendre votre opinion, pourquoi sacrifier une prune, gronder un acacia, faire semblant d'être fou et battre sur l'herbe.

Stratagèmes

Un stratagème est une séquence calculée d'actions visant à résoudre un problème spécifique.

Ce sont des règles, des mouvements stratégiques et des tactiques pour atteindre différents objectifs. Des stratagèmes ont été utilisés dans les hostilités. Fondamentalement, ils sont décrits dans les livres "Trente-six stratagèmes" et "L'Art de la guerre", qui sont attribués à Sun Tzu. Ce stratège et penseur chinois a vécu environ 500 avant JC. Mais le concept de «stratagème» vit dans la culture chinoise depuis 3 000 ans, nous pouvons donc supposer que l'auteur des traités est l'ensemble du peuple chinois.

Mais la question se pose - sommes-nous Timlidés, d'où vient la guerre? Nous ne nous battons pas, ne nous battons avec personne et ne capturons pas, pourquoi avons-nous besoin de stratagèmes?

Système de freins et contrepoids

Dans le livre de Ray Dalio «Principes», il y a une idée importante: toute entreprise ou équipe est un système de freins et contrepoids. Une entreprise est figée de conflits et d'affrontements.

Je vais vous expliquer avec un exemple. La société "Abstract" comprend deux départements: les testeurs (QA) et les développeurs. Le but des développeurs est d'arriver à la production le plus rapidement possible et de sortir le produit à temps, car ils ont des KPI pour cela. Les testeurs ont des priorités différentes: il est important pour eux de trouver autant de bugs que possible, car ils ont des KPI de qualité. Deux départements abstraits d'une entreprise abstraite entrent constamment en conflit et en confrontation abstraite.

Une situation similaire existe entre les RH et les propriétaires d'entreprises. En termes simples, l'objectif des RH est d'embaucher autant de personnes que possible. Mais pour cela, vous devrez gonfler le budget, car les informaticiens coûtent désormais cher. Les propriétaires d'entreprise veulent embaucher des gens moins chers. Encore une fois, conflit et confrontation.

Les conflits dans les entreprises entre les différents départements, les employés, les équipes, la direction et les subordonnés se produisent constamment sous la forme de rassemblements, de dialogues et de discussions. Ils peuvent être considérés comme une sorte de confrontation militaire, et des conseils sur la conduite d'une guerre seront tout simplement utiles.

Regardons ces stratagèmes qui peuvent utiliser des timlids. Les stratagèmes sont écrits en langage poétique, et ce n'est pas un hasard, car ils sont faciles à retenir.

Le général est lent car il envisage la victoire

Il faut se préparer à chaque rallye. Captain Evidence apparaît ici, mais non, attendez ...

«Ce n'est pas celui qui sait jouer selon toutes les règles qui gagne. Le vainqueur est celui qui sait abandonner toutes les règles au bon moment, imposer au jeu ses propres règles inconnues de l'ennemi et, le cas échéant, les abandonner. » Ceci est une explication du stratagème d'un livre à leur sujet. Si appliqué à l'informatique, il est dit que celui qui fixe les règles au début du rallye et gagne .

En 2017, j'ai pris la parole lors d'une conférence. L'un des objectifs de ma présentation était de «vendre» le langage Dart au public. C'est un PJ assez étrange, pas grand public, mais je l'aime beaucoup. Il est clair que le public de la conférence n'est pas prêt pour lui, j'ai donc trouvé un «truc militaire».

J'ai appelé un «jury» de trois personnes sur scène pour exprimer certaines caractéristiques de JavaScript, TypeScript et Dart et comparer ces trois langages. Mais j'ai moi-même fixé le format de la compétition et j'ai moi-même établi les règles. En tant que leader et principal de la scène, j'ai dit:
- Selon mes estimations, en TypeScript, la frappe est de 5 points sur 10, en JavaScript, ce n'est pas du tout, et en Dart, c'est 10 sur 10.

Qui, à part Chuck Norris, choisirait toujours TypeScript avec de tels arguments? Ce n'est pas logique, personne ne veut être «pas comme tout le monde». Par conséquent, le jury n'a tout simplement pas eu l'occasion de choisir un gagnant différemment que dans le format que j'ai demandé. On pouvait s'y attendre dans cette «bataille», Dart a vaincu parce que je me suis préparé.

Seul attend un ennemi las

Un grand stratagème illustré par deux histoires.

"Réécrivons tout sur ..."

En tant que chef d'équipe, j'ai une relative liberté dans le choix des technologies, donc mes coéquipiers viennent souvent à moi (je n'utilise pas le mot «subordonnés», je pense que c'est faux). Habituellement, ils disent quelque chose comme ça:
- Jetons TypeScript et réécrivons tout sur Flow!

Ou:
- Il y a une chose sympa - GraphQL. Vous avez fait un rapport à son sujet et vous faites campagne pour elle. Implémentons-le!

Je suis sorti de cette situation très simplement:
- J'aime vraiment GraphQL. Mais laissez-nous rédiger un plan de mise en œuvre pour six mois, en tenant compte des deux douzaines de services que nous avons déjà mis en œuvre, puis faire un rapport à ce sujet?

Nous avons un format de présentation le vendredi. Curieusement, cela a lieu le mercredi, car charger des collègues avec quelque chose de nouveau vendredi n'est pas très bon.

Si une personne est responsable, motivée et sûre d'avoir raison, alors il est probable qu'elle terminera le projet. Mais s'il veut juste parler et discuter, il ne regardera même pas dans cette direction: il devra communiquer avec quelqu'un, chercher, préparer une présentation et travailler en plus.

Alors je tue deux oiseaux avec une pierre:

• Je ne tais pas une personne et ensuite je n’entends pas à chaque rassemblement parler de GraphQL comment il résoudra tous nos problèmes et ainsi de suite;
• si une personne termine néanmoins le projet, elle deviendra un bon chef d'équipe à l'avenir, et nous aurons quelque chose de nouveau et de cool.

"Je suis trop paresseux pour écrire, viens en voix"

Ce hack de vie m'a dit un bon ami. Imaginez que vous recevez une demande d'extraction et que vous devez effectuer un examen, trouver des erreurs. Vous comprenez que dans cette demande d'extraction, la racine du mal est profondément ancrée: le développeur ne comprend absolument pas ce qu'il fait, donc tout est mal écrit et vous le signalez. Le développeur n'est pas d'accord (attendu), vient vers vous et dit: «Écoutez, je suis trop paresseux pour écrire, discutons-en comme ça».

Ne vous contentez pas de cela! Si les gens viennent vous parler, «parler» est gratuit. Vous pouvez dire une heure, et cela ne vous coûte rien. Nous avons toute la correspondance en anglais, et lorsque vous devez répondre, il est parfois plus rapide de refaire que d'aller sur Google Translate. Il y a moins de disputes: la personne est déjà fatiguée, elle n'est pas intéressée à se battre.

Sacrifiez une prune pour sauver une pêche

Il y a des situations où vous pouvez donner quelque chose de petit en échange de l'essentiel. Par conséquent, avant d'entamer des négociations, il est important de comprendre ce qui est important pour nous et ce qui est secondaire.

Nous arrivons à des négociations avec une position préparée.

Mêlée cérébrale

Il y a deux opinions conditionnelles dans Infobip: certains disent que Scrum et Agile sont cool, tandis que d'autres suggèrent d'écrire plus de code et moins de chat. Lors des réunions, la deuxième position s'exprime dans le fait qu'une personne emporte un ordinateur portable avec elle et s'y heurte - on ne peut rien en tirer.

Dans ce cas, nous communiquons avec l'employé:
- Faisons comme ça: vous ne pouvez pas du tout venir à un rallye Scrum, mais vous devez connaître les résultats. Mais si vous êtes toujours venu, retirez l'ordinateur portable et travaillez avec nous.

Une personne comprend que s'il manque la réunion, il devra se rattraper et personne ne connaîtra son opinion. J'ai sacrifié la présence d'un employé, et cela fait mal à la fierté, et à la fin il vient quand même. Le problème est résolu.

Pointant vers un mûrier, gronder l'acacia

Grigory Bakunov a un bon rapport dans lequel il suggère que tout développeur est dans le processus créatif caractéristique des enfants de 5 à 7 ans. Selon lui, tout développeur de 5 à 7 ans (conditionnellement), et il doit lui parler comme un enfant .

J'ai un fils, il a presque un an et demi. J'ai lu des livres spécialisés sur la parentalité et la garde d'enfants. Dans l'un des livres, j'ai appris à «tromper» un petit homme pour qu'il mange de la bouillie: racontez un conte de fées qu'il y a un estomac, et il se sent mal quand sa bouche ne lui donne pas de bouillie, et tout cela est comme l'exemple d'un garçon .

Comment l'appliquer aux développeurs? Auparavant, lorsque je voulais donner un feedback à quelqu'un, je le disais directement:
- Oleg, ici et ici tu te trompes. Pour améliorer les choses demain, faites ceci et cela.

Dans la plupart des cas, cela mine l'estime de soi: une personne fait des excuses et dit pourquoi elle a raison ou pourquoi elle ne pourrait pas faire autrement. Maintenant, je vais de l'autre côté:
- Imaginez que vous êtes un chef d'équipe et que vous avez une telle situation. Que ferez-vous?

Je l'ai mis à ma place et je lui ai demandé ce qu'il ferait dans cette situation. La fierté du développeur est de mise, il s’habitue au rôle de chef d’équipe et cherche des moyens de résoudre le problème.

Faites semblant d'être fou, gardez votre esprit

Faites semblant d'être un imbécile mon hack de vie préféré. Le principe est simple: si vous avez une question technique, posez-la. Je ne sais pas pour vous, mais je ne suis pas la personne la plus intelligente de l’équipe et j’en suis bien conscient.

Poser des questions est normal.

Dans l'une de mes entreprises précédentes, une personne occupait un poste assez élevé de vice-président de l'ingénierie (CTO). Il répétait sans cesse:
"Je ne comprends pas vos trucs techniques, expliquez-le en russe."

Ou:
- Cela entraînera une confusion dans le code. Et de quoi cela nous menace-t-il? Pourquoi? Comment?

Les CTO comme moi ont 30 personnes de plus. La seule façon de comprendre ce qui se passe est de demander encore et encore.

Quand une personne répond à votre question «stupide» avec des mots simples, alors vous comprenez où il y a des lacunes dans sa logique. À ce moment, vous posez des questions de clarification et trouvez où quelque chose ne va pas: l'euphémisme entre les arguments, les problèmes potentiels qui peuvent alors se déclencher. Alors n'ayez pas peur de poser des questions stupides.

Si vous pensez que vous perdez ainsi votre «autorité» et votre «visage professionnel», alors souvenez-vous de Richard Feynman . Il s'agit d'un lauréat du prix Nobel, co-auteur de la théorie de l'électrodynamique quantique, l'un des développeurs de la bombe atomique, artiste et cracker de coffres-forts. Dans les années 1960, Feynman a donné ses conférences à Caltech, qui ont ensuite été publiées en trois volumes de Feynman Lectures on Physics. Jusqu'à présent, c'est l'une des explications les plus compréhensibles et les plus populaires des phénomènes physiques, de la mécanique à la physique quantique.

Selon les insignes, il semble que ce soit une personne respectable et sérieuse. Mais au contraire, il n'avait pas peur d'avoir l'air maladroit. Une des caractéristiques de Feynman est un esprit vif et une ironie de soi. Il posait constamment des questions stupides , n'essayait pas de paraître «solide» et cherchait à expliquer des choses complexes avec des mots simples. L'une de ses citations: "Si vous êtes un physicien quantique et que vous ne pouvez pas expliquer brièvement à un enfant de cinq ans ce que vous faites, vous êtes un charlatan."

Si les lauréats du prix Nobel peuvent paraître stupides, c'est encore plus vrai.

Attirer le toit et retirer les escaliers

J'ai rencontré un problème dans l'équipe: il y a une grosse fonctionnalité qui prendra un temps indéfini. Les gestionnaires me demandent constamment quand la fonctionnalité sera terminée et les développeurs ne connaissent pas le «quand» car ils ne peuvent pas déterminer les exigences. À un moment donné, j'ai dit:

- Arrête! De quoi avez-vous besoin pour comprendre le timing?
- Ceci, ceci et cela.
- Ensuite, nous organiserons un rassemblement le 1er octobre. Comprenons d'ici là si nous sommes dans le temps ou non.
"Mais qu'en est-il?" Peut-être que l'ouragan démarre, que le bus ne vient pas, que quelqu'un tombe malade - comment en tenir compte?
- Ouais, et Godzilla va attaquer ... Simplifions la tâche: nous décidons que nous ne trouverons rien, et si nous trouvons, nous en informons simplement la direction. Mais d'ici le 1er octobre, cela devrait être fait.

Plus important encore, j'ai demandé à tout le monde s'il était d'accord avec la date du 1er octobre. Si je ne suis pas d'accord, j'ai suggéré de proposer une date différente, de la justifier et de le dire en haut. Le stratagème est brièvement décrit en une phrase.

Otez les voies d'évacuation.

Si vous voulez attraper quelque chose, lâchez d'abord

Donnez la possibilité de sauver la face

Je suis venu avec un chef d'équipe dans une équipe déjà établie. Naturellement, la première chose que j'ai décidé de faire a été de «vendre» mon autorité.

Dans l'une des revues de code, j'ai eu une grosse dispute avec un développeur sur l'architecture. J'ai décidé de savoir qui avait raison et qui n'avait pas raison: j'ai demandé à tous les leaders de l'industrie une opinion objective sur le code dont nous parlions. Tous ceux que je voulais évaluer ont confirmé que j'avais raison.

J'ai exposé tous ces résultats à mon «rival» dans l'espoir qu'il serait au courant de son erreur et que tout se calmerait. Mais tout s'est déroulé différemment. Mon adversaire s'est rendu compte qu'il perdait sa crédibilité. Maintenant, il n'est plus intéressé par le produit et de toute façon, qui a raison et qui ne l'est pas est important pour sauver la face. Après cela, toutes mes décisions ont été rejetées. Le développeur n'a pas pensé au projet, il a réfléchi à la façon de montrer qu'il est plus intelligent. Tout s'est terminé par un douloureux transfert d'une personne dans une autre équipe (licenciement). J'avais raison, mais je n'ai pas laissé la personne sauver sa face. Je le regrette toujours.

Donnez à l'ennemi la possibilité de sortir de la situation avec dignité.

Même si vous avez parfaitement raison - l'adversaire doit conserver sa dignité. Si vous marchez sur le cal, vous gagnerez l'ennemi.

Site comme une tomate

J'ai entendu un autre exemple amusant dans une conférence de Ludwig Bystronovsky, directeur artistique du studio Lebedev. Imaginez un designer qui propose de créer un site Web comme une tomate. On ne sait pas à quoi cela ressemblera, et surtout pourquoi? Mais le designer l'aime et il ne fait la promotion de son «idée» que parce qu'il l'a inventée.

Bien sûr, il ne faut pas être d'accord avec de telles idées. Retourner l'homme sur terre:
- Je comprends que tu es un grand designer, mais cette idée n'est pas toi, ça ne marche pas maintenant.

C'est le même principe de conservation du visage, mais dans le cas où une personne associe sa décision à elle-même. Cela doit également être pris en compte et travailler avec lui.

Malheureusement, cela ne se produit pas seulement dans un environnement créatif. J'ai vu des cas où des développeurs se sont associés à GraphQL ou à MongoDB, par exemple. Essayez de séparer les idées de la personne, je me suis déjà brûlé dessus.

Battez l'herbe pour effrayer le serpent

Lorsque vous recevez un grand projet à long terme, je vous conseille de mettre en œuvre MVP: un projet minimal avec toutes les puces, les problèmes, les bugs, ce qui permet d'évaluer correctement le calendrier. Si la construction MVP simple conditionnelle 2 semaines, alors il est clair ce qui se passera ensuite.

C'est un bon conseil et ça marche partout. Maintenant, je suis opposé à une approche différente, déjà à ce sujet, j'ai reçu un cal. Laissez le développeur mieux faire le MVP et quelque chose de spécifique par le code que de travailler différemment sur un grand projet.

L'évasion est le meilleur stratagème

Éviter les conflits n'est pas une perte.

Comme l'a dit Sun Tzu, il y a trois options.

• Faites un compromis. C'est une décision sans enthousiasme: gagner et perdre.
• Reconnaissez la défaite.
• Pour partir. Mais ce n'est pas une perte, mais une chance de revenir et de corriger.

Ne vous mêlez pas de conflits! Mieux vaut ne pas se battre, mais vivre en paix.

«Se battre cent fois et gagner cent fois n'est pas le meilleur des meilleurs. Le meilleur des meilleurs est de conquérir une armée extraterrestre sans se battre. »

Sun tzu

Tout ce qui a été discuté dans l'article du dernier stratagème est la manipulation. Tout le monde ne veut pas les contacter, mais vous devez les connaître pour deux raisons: parfois, vous devez encore utiliser des manipulations dans votre travail , malheureusement, et il est toujours préférable de savoir quand vous êtes utilisé que de ne pas savoir.

Essayez de réduire les conflits et ne vous laissez pas manipuler.

Sur cette note positive, je vous rappelle que vous pouvez soumettre une demande de rapport à la prochaine conférence des chefs d'équipe d'ici la fin de la semaine, soit le 22 décembre. Et une semaine plus tard, sur des centaines (je pense qu'il y en aura encore plus), nous choisissons les intervenants de la TeamLead Conf de février pour que vous ne doutiez plus de la nécessité d'acheter un billet pour la conférence.