Gestion des arrangements

Parlons de la gestion des arrangements. Pourquoi est-ce tout d'un coup? Oui, parce que nous, TeamLead Conf, aimons discuter des douleurs et des problèmes, mais nous n’oublions pas les solutions. Assurément, tout le monde a des problèmes liés à l'organisation du travail.

«Les dispositions ne sont pas mises en œuvre», a déclaré le capitaine Evidence

La douleur avec eux, en premier lieu, est que les accords ne sont pas respectés - tout le monde le sait, même notre ami, Captain Evidence, qui nous aidera dans cet article.

Il semblerait, quel est le problème? Beaucoup de choses ne se passent pas comme nous le souhaiterions. Par exemple, les jours ensoleillés ne sont pas toujours à Saint-Pétersbourg. Alors quoi, la ville se dresse, les gens viennent, on adore. Ce qui ne se passe pas comme nous le voulons n'est pas toujours un problème vraiment grave.

Cependant, dans ce cas, Stas Mikhalsky prétend que le problème est plus que sérieux. Sous la coupe, nous comprendrons ce qui conduit au fait que l'accord n'est pas mis en œuvre et comment, au final, les rendre indestructibles.


À propos de l'orateur: Stas Mikhalsky est engagé dans le développement web depuis 1998. Il est passé d'un programmeur Perl junior à un directeur du développement chez Biglion. Il a participé au développement de plusieurs dizaines de projets à forte fréquentation et a apporté leur soutien.

Pourquoi est-ce un problème

Les affaires et le leadership de nos équipes et de nous, en tant que chefs d'équipe, attendent le résultat. Terminer une tâche à temps peut ne pas aboutir à un résultat, mais c'est une autre histoire.

Le travail et le résultat sont deux choses différentes, mais parlons-en une autre fois.

Le résultat est le résultat du travail - l'achèvement des tâches, des projets, des sous-projets. Différentes divisions sont possibles, mais d'une manière ou d'une autre, le travail consiste en quelques actions, chacune étant en fait la conséquence d'un accord.

Il semblerait - tout est clair: lorsque nous n'effectuons pas d'actions, nous rompons les accords.

Prenons des exemples standard. La conformité à la norme de style de code est un accord avec un développeur spécifique. Toute l'équipe ne répond pas d'une seule voix: «Oui, sage Kaa, nous respecterons le style de code», mais tout le monde dit personnellement qu'il promet de le respecter. Le lancement de la version vendredi ou lundi est également un accord. Quoi que nous fassions, quelqu'un nous a posé des questions à ce sujet, ou nous avons nous-mêmes décidé que cela était nécessaire pour quelque chose, si un résultat est attendu de nous, alors c'est une action prise dans le cadre d'un accord.

- Si nous décidions nous-mêmes qu'ils attendent cela de nous - est-ce un accord?
- Oui, un accord avec lui-même, mais c'est un cas particulier.

Maintenant, la chose la plus intéressante est en fait le contraire: un accord échoué = une action échouée.

En d'autres termes, aucun accord n'est interrompu si l'action n'est pas exécutée, mais l' action qui n'est pas exécutée est le résultat d'un accord échoué . Nous ne l'avons pas fait, parce que nous n'étions pas d'accord, soit nous ne le voulions pas vraiment, soit autre chose. Au centre se trouve le problème avec l'accord. Ainsi, nous obtenons une image dans laquelle un accord échoué conduit à une action non réalisée, ce qui, bien sûr, affecte la qualité du travail, et finalement un manque de résultat.

Je veux vous transmettre l'idée que les développeurs, back-end, front-end, testeurs, chefs d'équipe, responsables de développement sont autant de fonctions et de rôles au sein desquels nous faisons quelque chose. Mais si vous regardez un peu plus haut, alors tout notre travail est la conclusion d'accords et leur mise en œuvre. C'est comme UDP - tout le reste est enveloppé dans un accord. Si nous ne savons pas comment conclure correctement les accords, nous pouvons être un excellent front-end ou back-end, écrire un excellent code, mais il n'y aura aucun résultat.

Au contraire, si nous apprenons à créer les bons arrangements, alors:

• gagner beaucoup de temps;
• réduire considérablement les frais généraux pour tous les contrôles, démontages, etc.;
• nous pouvons vraiment faire notre travail.

Que faire

«Assurez-vous que les dispositions sont mises en œuvre»

Témoignage du capitaine

Cela est clair pour tout le monde, même le capitaine de la preuve, il vous suffit de vous assurer que les accords sont mis en œuvre, et vous n'avez pas besoin de le faire pour qu'ils ne soient pas mis en œuvre.

Le modèle classique de la façon dont cela peut être réalisé:

1. Comprenez les raisons.
   
2. Identifiez et prenez des mesures pour remédier à ces causes et modifier les résultats.
   

Parlons un peu plus en détail. Il y a trois acteurs:

1. Un arrangement à gérer.
   
2. Perturbation qui arrive à un arrangement.
   
3. Les raisons de l'échec.
   

Si vous regardez tout cela de tous les côtés, vous pouvez probablement comprendre quel est le problème et comment améliorer la situation. J'espère que la situation nécessite une intervention, tout le monde est d'accord.

Qu'est-ce qu'un arrangement?

L'arrangement comprend deux parties: l'engagement et la promesse. La différence entre eux, c'est qu'un engagement est pris, une promesse est faite .

Une promesse est un abat, c'est un message à quelqu'un que j'ai pris un engagement. En principe, il ne peut même pas être donné, car il ne s'agit que d'un message de notification. Mais je m'engage à cette obligation. Par conséquent, un engagement sans promesse est bien meilleur qu'une promesse sans engagement. Nous rencontrons ce dernier assez souvent.

Honnêtement, il me semble que tout le problème est que tous (et nous aussi) et pas toujours, lorsque nous concluons des accords, pensent aux obligations. Nous ne prenons pas toujours des décisions consciemment et ne comprenons pas vraiment ce que cette promesse nous menace. Nous hochons simplement la tête: «Oui, oui», nous partons, mais nous ne prenons pas notre obligation avec nous - et c'est un gros problème.

En fait, c'est encore beaucoup plus compliqué, car les dispositions sont de types différents:

• Dans le cadre de ses responsabilités immédiates , par exemple, écrire des commentaires dans le code, terminer la publication dans l'environnement.
• En dehors du travail principal , par exemple, pour surveiller la pertinence des informations dans le wiki, lire un livre, suivre des cours.
• Modifiez le comportement , par exemple, commencez à travailler à une certaine heure ou suivez le temps consacré à la tâche.

Ce sont des accords complètement différents, les gens les traitent différemment et vous devez travailler avec eux de manière complètement différente.

En règle générale, la portée du travail principal va au-delà des questions, qui dans un sens sont plus importantes, comme il me semble, que le niveau de codage actuel du développeur, car il peut être transformé à travers elles. Si une personne sait apprendre, c'est complètement différent que si elle venait d'apprendre à coder rapidement et sans erreur en 10 ans. Il peut parfois être plus difficile de convenir avec un développeur de lire un livre que de lui demander de documenter le code. Mais c'est encore plus amusant quand il s'agit de changer de comportement.

Un exemple classique, quand il n'était pas important de passer à 10 ou 12, car, si quelque chose, vous pouvez vous attarder et affiner, et maintenant vous devez être au travail au plus tard à 11, parce que les processus et ainsi de suite. Si une personne accepte simplement: "Oui, eh bien, je viendrai à 11 heures demain" - ce n'est pas un changement de comportement, mais un exploit. S'il s'avère que pour cela, il est peut-être nécessaire de reconstruire la vie - de se coucher un peu plus tôt ou de ne pas jouer à Warcraft, cela signifie que la personne elle-même doit changer. C'est difficile et, surtout, incontrôlable, comme tout projet.

Par conséquent, il est très important de comprendre de quel type d'accord nous parlons. Le degré d'élaboration dépend du type d'accord que nous essayons de conclure.

Perturbations

Non seulement les accords se décomposent, ils se décomposent, d'une part, de manière inattendue, et d'autre part, à la ligne d'arrivée - parce que c'est tellement plus amusant. Bien que cela soit inattendu, c'est généralement à un point prévisible. Je sais toujours quand l'accord sera rompu.

Nous travaillons maintenant en équipe, l'âge des célibataires et des ordinateurs de garage est passé. Nous avons une équipe, des processus et tous les arrangements dans une chaîne. S'il s'effondre, alors tout s'effondre. Si une personne n'a tout simplement pas lu le livre, alors, en principe, rien ne va mal ou se casser, mais dans un an, votre équipe ne sera soudainement pas meilleure que maintenant. Pour moi, ce fichier est bien plus volumineux que deux heures de panne de tous les systèmes.

Les perturbations sont également différentes.

L'échec est mon échec préféré, le plus honnête et le plus inoffensif. Nous avons accepté, la personne a promis et ne l'a pas fait - cela arrive. Il s'agit d'une simple panne, car tout est clair avec lui.

Il existe des options plus désagréables, telles que l'exécution formelle.

Le vendredi soir, le développeur (pour une capsule de bière pour inspiration) exécute 40 heures de travail pour les tâches qu'il a effectuées en une semaine. En fait, la personne qui a conclu cet accord avec vous ne reçoit rien pour le moment. Si l'enregistrement du temps n'est pas nécessaire pour appuyer tout le monde sur le clou, mais pour comprendre statistiquement combien de temps différents types de tâches prennent, quelle est l'erreur moyenne, etc., alors son exécution ruine toute l'initiative. Il n'y aura pas de statistiques, car les données proviennent de la tête. En conséquence, l'accord n'a pas été respecté, bien que quelque chose semble être fait, et tout va bien.

Le problème est que nous n'enregistrons pas toujours l'exécution formelle comme un accord rompu. Surtout si vous-même n'êtes pas très intéressé. Par exemple, je suis chef d'équipe, le directeur m'a dit d'en haut: "Écris une montre, sinon je punirai tout le monde!" Je suis venu dans l'équipe et j'ai diffusé que je devais enregistrer le chronomètre, sinon tout le monde sera puni. En conséquence, l'horloge a été enregistrée d'une manière ou d'une autre, je suis satisfait - j'ai quelque chose à montrer au réalisateur. Je participe moi-même à ce sabotage, et pour moi l'exécution formelle est importante. Pour le fournisseur de tâches, ce n'est pas acceptable.

La substitution est légèrement différente de la mise en œuvre formelle du formulaire, mais en fait c'est la même tentative de violer l'accord. Juste au lieu de la visibilité de la tâche terminée, une substitution est créée. En utilisant l'exemple de l'enregistrement du temps, cela ressemble à ceci: «Pour enregistrer le temps de chaque tâche, j'ai besoin de 5 minutes. Au total, c'est deux heures par semaine. Oh bien lui. J'ai fait une tâche que je n'avais pas l'intention de faire, en 4 heures. Mais j'ai fait plus que ce que j'avais promis, ni que je n'ai pas mis en gage le temps.

C'est une tentative de vous donner quelque chose pour que vous soyez en retard avec le chèque, mais en fait c'est aussi une panne. Le problème est que, en règle générale, nous avons beaucoup d'autres choses, le temps non garanti n'est pas la pire chose. Nous nous pardonnons.

Je le répète: un accord en suspens est un travail négatif, un résultat négatif.

Comment survivre dans un monde d'arrangements inachevés?

Vous pouvez simplement rappeler : "Vous souvenez-vous que nous enregistrons l'horloge?". Lorsqu'il s'agit de changer de comportement, un rappel est un bon aperçu. Les affiches les plus astucieuses à accrocher soutiennent le modèle de comportement: «Temps engagé - sauvé le castor!». En fait, nous vous rappelons simplement qu'il y avait un accord, sans vérifier son statut pour le moment.

Vous pouvez être un peu plus persévérant et demander comment l'accord est mis en œuvre, si la personne a déjà fait quelque chose. Cela diffère d'un rappel en ce qu'il vous oblige à donner une sorte de réponse articulée. Mais vous mettez donc la personne avant le choix: mentir ou ne pas mentir. Soit dit en passant, la réponse n'est pas évidente pour tout le monde. Dans un sens, vous poussez une personne vers le mal. Demander est un type de contrôle latent - il semble être demandé, mais pas vérifié. L'homme a menti, mais nous laissons cela sur sa conscience.

Vous pouvez vérifier :

• par résultat;
• étape par étape;
• sur la dynamique.

Vérification par le résultat que nous avons déjà discuté. La question est de savoir quoi faire si le résultat n'est pas satisfaisant, mais nous y reviendrons plus tard.

Par étapes et par dynamiques, il est possible de vérifier le respect d'un accord au travail et hors travail. Par exemple, nous avons persuadé une personne de remplir une base de connaissances, décrit un plan avec elle et respectons ce plan - ce n'est toujours pas le cas. Mais qu'en est-il du changement de comportement? Une personne enregistre l'heure ou ne se connecte pas; vient à l'heure ou non. Il est ridicule de suivre cette transformation par étapes et dynamiques - aujourd'hui, il y a une demi-heure de retard, demain 25 minutes, après-demain 20.

Le plus gros problème de validation est que ce n'est pas toujours possible. Étant donné que des accords sont conclus tout le temps et avec de nombreuses personnes, cela demande également beaucoup de travail .

Un modèle de gestion dans lequel presque tout le temps qu'un gestionnaire passe sur le contrôle de l'exécution des tâches existe, mais il ne fonctionne pas bien en informatique. Oui, et c'est le siècle dernier. J'espère qu'une telle approche de la gestion mourra un jour, comme le dernier dinosaure.

Au lieu de contrôler, essayons de mieux comprendre pourquoi la panne se produit réellement - pourquoi la personne qui nous a fait la promesse ne l'a pas tenue.

Raisons de la panne

Il s'agit probablement d'une liste incomplète, mais voici les exemples les plus frappants:

• Consentement déraisonnable. Une personne accepte, car il est gênant de refuser: vous êtes son chef ou juste une personne respectée, ou bien elle veut sincèrement vous aider, elle vous aime, ou elle n'aime pas du tout refuser.
• Erreur dans l'évaluation. Une personne peut penser, être d'accord, mais faire une erreur dans l'évaluation. Puis il viendra et dira: "Oui, j'ai promis, mais le travail était deux fois plus important que prévu."
• Changement de priorités: "J'ai presque fini, mais Vasya est venu, il a un problème encore plus important, donc je suis désolé."
• Manque de ressources - tout simplement pas assez de temps.
• Circonstances imprévues - le piano est tombé d'en haut.
• Sabotage

Souvent derrière toutes les excuses se trouve le roi des accords frustrés - le sabotage . Lorsque nous ne voulons pas faire et ne voulons pas admettre que nous ne voulons pas faire, nous obtenons le sabotage. Boire 40 heures par semaine pour des tâches utilisant la méthode du poke est du sabotage. Venir travailler à 9 heures du matin et boire du café est un sabotage. Il est basé sur une réticence à faire, qui n'a pas été explicitement exprimée.

En fait, il y a des causes plus systémiques de la panne . Ce que nous avons dit se trouve à la surface, et si vous creusez profondément, il n'y a que trois raisons:

1. Type d'arrangement non pris en compte.
   
2. Le type d'arrangement n'est pas convenu.
   
3. Une promesse sans engagement.
   

De plus, les premier et deuxième paragraphes peuvent être présents simultanément. Lorsque nous concluons un accord, nous ne pensons pas à ce sur quoi nous nous entendons. Cela ressemble souvent à ceci:

- Égée, fais-le!
- OK, je vais le faire! - et s'enfuit.

Cela peut être fait lorsque nous parlons de travail dans le travail, par exemple, d'écrire un module: "Faites rapidement la tâche 28." Mais cela ne peut pas être fait lorsqu'il s'agit de préparer une réunion lors d'un rassemblement, par exemple. Dans le bon sens, pour préparer un discours lors d'une réunion, vous devez vous asseoir, le trier, expliquer son importance, etc. Mais souvent, nous faisons tout au même rythme : «Faites ceci» ou «Regardez, ne soyez plus en retard!» - et a couru .

Il arrive que nous soyons d'accord, étant dans une compréhension différente du type d'accord. Un exemple classique est la documentation du code. Au cours du passé, peut-être que tout a changé, mais quand je suis tombé sur cela, mes collègues et moi avons eu un débat constant sur la question de savoir si le développeur devait documenter le code ou non. En tant que leader, je pense que je devrais. Le développeur estime que le code fonctionne, et bien, compte tenu de la charge de travail et des priorités en constante évolution.

Un conflit de compréhension du type d'arrangement n'est pas toujours révélé. Nous pensons souvent que cet accord n'a pas besoin d'être clarifié, renforcé, car tout est déjà clair: il suffit de le prendre et de le faire. Le subordonné croit que de lui ils veulent d'en haut ce qu'il ne veut pas faire. Et puis le sabotage commence .

La situation la plus populaire, comme je l'ai dit, est une promesse sans obligations. Un accord qui a donné lieu à une promesse, mais qui n'a pas donné lieu à une obligation, ne sera pas respecté pour une raison ou une autre: le piano tombera, une personne sera distraite, il se passera autre chose.

En fait, dans des conditions de complexité des systèmes, de l'intensité des changements: lorsque nous écrivons tous à la hâte, le déployons rapidement, le refaisons, en d'autres termes, dans des conditions d'entropie, quelque chose peut toujours se produire qui empêchera la réalisation de l'accord. Bien sûr, vous pouvez contrôler chaque étape, exploiter chaque cas de chacun de vos subordonnés, essayer de l'aider à arriver à la mise en œuvre de notre accord. Mais alors il n'y aura pas assez de temps pour rien de plus que de tout tirer par vous-même.

La seule chance que l'accord soit respecté est qu'une personne veuille le réaliser.

Si j'ai le désir de respecter l'accord, je m'occuperai de tous les problèmes qui s'envolent: avec les pianos qui tombent, le fait que j'ai fait une erreur d'évaluation, etc.

Ceci est similaire à l'idéologie de Scrum, tout comme la complexité de la tâche n'est pas complètement connue. Nous faisons quelques hypothèses avec une erreur sur l'expérience précédente, évaluons, puis faisons tout pour fermer le sprint. Nous reconnaissons que oui, ce sera difficile, que nous pourrions faire une erreur quelque part dans l'évaluation, que le système pourrait nous surprendre, mais nous le ferons simplement pour résoudre le problème.

Avec l'arrangement, la même chose devrait se produire qu'avec les sprints dans Scrum. Une personne qui s'est engagée à faire quelque chose n'a qu'à le faire. Tout est simple!

En résumé, ce qui a été dit sur les raisons de l'échec de l'accord:

• Une promesse n'est pas une garantie.
• Le contrôle est difficile.
• L'échec est révélé sur le fait.

Il est clair ce qui doit être fait: il suffit de créer des accords durables qui sont faciles à gérer et enfin d'aller aux Bahamas.

Témoignage du capitaine

En d'autres termes:

• Tel quel - le système ressemble maintenant à ceci: des arrangements plutôt fragiles et difficiles à gérer.
• Pour être - cela devrait être: des accords indestructibles, dont la gestion est transparente et peu laborieuse.

Pour une situation d'analyse GAP standard, «Être» est le but ultime que nous visons, mais pas le fait que nous atteindrons. Mais nous devons nous efforcer.

Reste à savoir ce qu'est un accord solide et comment le gérer.

Accord solide

Accord fort - ce sont de véritables obligations qui sont conclues avec une personne contraignante. C'est très important. Nous avons parlé d'obligations, comme de certains paquets qui doivent être transférés, et maintenant nous allons parler un peu du transporteur de ce paquet.

Les dispositions prises avec une personne facultative entraînent des incohérences. Si vous imaginez le travail sous la forme d'un flux d'accords qui sont distribués dans des directions différentes par des packages, alors lorsque vous essayez de conclure un accord avec une personne facultative, préparez-vous au fait qu'avec une probabilité de 50%, vous perdrez du temps. Par conséquent, la première chose à faire est d'augmenter le prix d'un mot.

Prix ​​du mot

Idéalement, chacun de vos collègues devrait comprendre que les obligations de service sont leur tâche principale. C'est l'essence de son travail. Le code écrit et la libération dégonflée sont des dérivés des obligations remplies. Par conséquent, j'essaie de parler spécifiquement avec les gens des obligations et du fait que le problème n'est pas que le code n'est pas écrit ou qu'il n'y a aucun résultat. C'est une conséquence et beaucoup de douleur. Mais l’essence du problème est qu’après avoir assumé l’obligation, nous n’avons pas trouvé de moyen de la remplir.

, , , . , , , , « — — — » . , , — , , , .

, , . - . , , 10 3. , — .

, .

, — . — , .

, , .

, — : « , ».

— , . , — . , .

— . , .

, , , .

, - — .

« » . , — . , , . , . , - . , , , , :

1. , .
   
2. , .
   

, , . — — , . - . , , , . , . .

, , «» :

• .
• .
• .

— , , , , , .

, . , .

, .

. , , : , , . , , , , . , — , - , . — .

, . — , «» . , — . - , . :

— , !
— .

-: «, , . 10:55. , ».

, , 5 — , , . , : , .

— — , .

?

, : ? 4 , , - :

1. ?
   
2. ?
   
3. , ?
   
4. , ?
   

. , . , .

: «, - , , , !» , , , .

, . . - , , , , .

« » . — . , , — .

« » , - , . , , — . , . , , .

, :

• .
• .
• , , — , .
• « » . , .

, Excel, : , , , . , .

?

, , , . , …

? ? — : — , — , — .

, «» , , . «» — - . « » , « ?» « ?»

…

Mais le choix d'aller à TeamLead Conf ou non, à mon avis, est évident. De plus, le programme est presque prêt. Mais vous pouvez choisir Moscou en février ou Peter en septembre, et vous inscrire à la newsletter pour ne pas manquer de nouvelles vidéos et de nouveaux articles, l'ouverture de l'appel à communications et les dates clés.