Automatisation impitoyable. Coupure du réalisateur

Je veux parler de mon expérience d'accélération de l'automatisation dans une équipe de programmeurs, et des techniques que nous mettons en pratique et de ce qui en est résulté.

Conditions initiales

Nous avons mené notre expérience pour accélérer le travail des programmeurs dans les conditions suivantes:

• c'était une entreprise manufacturière géographiquement distribuée;
• 4 programmeurs 1C et moi, leur chef ont participé à l'expérience;
• nous sommes des programmeurs à plein temps prenant en charge des configurations complexes;
• nous nous sommes ennuyés et nous avons décidé de nous développer.

Tout d'abord, le désir de se développer est né après avoir attiré l'attention d'un livre de Jeff Sutherland sur Scrum. Vous en savez probablement déjà beaucoup sur cette technique, je ne m'y attarderai donc pas. La partie principale de l'article ne traitera pas de Scrum.

Ainsi, lorsque nous avons lu ce livre, nous avons découvert qu'il y avait un dilemme, qui est la traduction incorrecte du nom du livre. Le nom anglais suggère que Scrum accélère quatre fois: "L'art de faire deux fois plus de travail en deux fois moins de temps."

Et dans la traduction russe, il est indiqué que Scrum est une méthode révolutionnaire de gestion de projet. Lorsque les responsables informatiques sont préparés pour les entretiens, on leur dit souvent - faites attention à ce sur quoi la personne se concentre - les processus ou les résultats. La traduction russe se concentre sur le processus .

Pourquoi est-ce que j'en parle avec confiance? J'ai vu des dizaines de personnes qui utilisaient Scrum en direct. La plupart d'entre eux viennent juste de commencer le processus Scrum , et quand vous leur demandez: "Qu'avez-vous changé?" - ils disent: "Nous sommes devenus transparents, intéressants, amusants." Mais lorsque vous êtes intéressé par la façon dont les résultats ont changé, si la vitesse de développement a augmenté, si vous avez commencé à remettre les projets plus rapidement, il s'avère qu'ils ne le savent pas, car ils n'ont pas mesuré l'efficacité .

Nous avons donc lu ce livre et lancé le Scrum classique avec toutes ses principales étapes du processus métier (elles sont illustrées dans l'image).

Je mentionnerai la méthode de mesure (elle apparaîtra tout au long du rapport). La méthode traditionnelle de mesure dans Scrum est la planification du poker . Il consiste en ce qui suit: pour chaque tâche, l'équipe (ou les participants qui comprennent quelque chose dans cette tâche) reçoivent un score de 1, 2, 3, 5, 8 et jusqu'à 34 (nombres de la série Fibonacci). Selon la totalité des estimations, la moyenne est prise. La tâche est considérée comme terminée lorsqu'elle a été acceptée par le client.

Premiers résultats

Que nous a apporté l'introduction du Scrum classique? Avant lui, la production journalière moyenne par personne était de 4,2 points, et avec son introduction, l' indicateur est passé à 7,73 points . Il s'est avéré que notre productivité a doublé.

Tout le monde l'a aimé, nous en avons parlé à des collègues d'autres départements, toute l'entreprise s'est intéressée, tout le monde a commencé à implémenter Scrum à la maison.

Mais rien ne s'est passé, car tout le monde a été emporté par un fétiche - ils ont acheté des planches de liège, collé des autocollants dessus et se sont limités à cela. Même le propriétaire, qui était également intéressé par Scrum, traînait les employés: il est allé au tableau de liège, en a pris une photo, puis est revenu une semaine plus tard et a de nouveau pris une photo - la planche n'a pas changé.

Je voulais plus

L'amélioration des performances nous a paru deux fois ennuyeuse. J'ai donc recommencé à lire le livre. À la page 54-55, certains shuhari l'ont remarqué. Il était écrit dans le livre que c'était un principe de l'Aïkido, qui disait - tout d' abord faire selon les règles (syu), puis commencer à improviser (ha), et ensuite seulement séparer et créer votre propre technique (ri) .

Fait intéressant, dans le célèbre guide Scrum, ce principe a été rejeté, et il ne restait que «syu» du «shuhari».

Et nous avons décidé d'aller jusqu'au bout.

L'algorithme d'accélération de base recommandé dans le livre de Jeff Sutherland est le cycle de Deming . En termes simples, cela peut être formulé comme suit: vous regardez comment fonctionnent vos employés, vous remarquez où ils sont stupides, où il y a un retard, vous proposez une sorte de changement, vous l'implémentez et regardez ce qui s'est passé. Si ça va mieux, plus vite - vous quittez le changement. Si cela empire - supprimez le changement. L'essentiel est de le faire rapidement.

Soit dit en passant, la théorie des contraintes de Goldratt Systems dit à propos de la même chose, se concentre uniquement sur l'autre. Elle dit: trouvez le lien le plus étroit dans votre système, développez-le ou supprimez-le. Répétez ensuite.

L'objectif de l'un et de l'autre est de permettre d'obtenir le résultat le plus rapidement possible sur l'ensemble du cycle de production. La même idée, d'ailleurs, a été exprimée par le développeur de Toyota Production System - le but du système de production est de faire arriver l'argent du client le plus rapidement possible.

Le rôle de l'observateur du workflow est assuré par le Scrum-master. On peut dire que c'est un coach. Lorsque vous lisez l'expérience de vos collègues Scrum, ils perçoivent les Scrum-masters comme un défenseur et disent que le Scrum-master devrait supprimer les obstacles , chasser certaines personnes, aider dans quelque chose.

Cependant, je suis sûr que le Scrum-master est un observateur et un formateur qui apprend à ses employés à travailler plus rapidement, regarde où ils sont stupides, aide, invite, recherche quelque chose de nouveau, essaie différentes combinaisons. Comme un entraîneur de football.

Équipe expérimentale.

Pour comprendre le contexte dans lequel s'est déroulée notre expérience, nous devons introduire une équipe. Si je vous dis qu'il y avait deux Stas, Oleg et Igor, cela ne vous dira rien, car personne ne connaît ces gens. Vous, plus ou moins, ne connaissez que moi.

Par conséquent, au lieu de deux Stasov, Oleg et Igor, l'équipe mettra en vedette des personnages que tout le monde connaît et qui sont aussi similaires que possible à de vraies personnes:

• Le lapin est intelligent, silencieux, silencieux.
• Le porcelet est le plus jeune, le plus rapide, le plus curieux.
• L'âne est le plus déprimé, et il est comme ça dans la vie.
• Et le hibou ... En fait, le livre original n'était pas un hibou, mais un hibou aigle, masculin. L'équipe avait donc un hibou grand-duc.

L'étape suivante est l'improvisation.

Le premier jour, quand nous avons décidé de tout changer, nous:

• Jeté Scrum-board et autocollants. Scrum-board a été remplacé par un système d'information basé sur 1C: Gestion des documents;
• Les autocollants ont été remplacés par des tâches dans ce système d'information;
• Poker gauche et mesure de vitesse;
• Suppression des réunions quotidiennes, des rétrospectives, des projets (en général, en tant qu'entité) - laissé juste une certaine classification des tâches par sujet;
• Ajout d'une surveillance constante des temps d'arrêt, des pertes;
• Et ils ont ajouté un changement constant de processus.

Au total , au cours de cette expérience, qui a duré environ un an avec nous, nous avons trouvé une quarantaine d'accélérateurs . J'ai essayé de regrouper ces 40 accélérateurs et maintenant je vais vous expliquer rapidement comment chacun d'eux a influencé le flux de travail.

Au cas où, je mentionnerais d’où venaient ces accélérateurs. Il n'y a rien de nouveau ici. Je suis moi-même venu avec quelques principes, certains de mes gars ont trouvé quelque chose, nous lisons quelque chose dans les livres. Par exemple, lorsque dans un livre, il est recommandé d'agir comme ceci pour résoudre un tel problème, vous devez prendre et essayer. Si cela s'avère, laissez-le. S'il n'y a aucun sens, nous le jetons.

Zéro changement

Ainsi, la première chose qui a commencé à repenser le processus est le livre «Code of Samurai» . Je recommande à tout le monde de le lire, de l'acheter et de le garder à la maison. Parce qu'il a été écrit il y a 500 ans, et déjà il y a 500 ans, les gens savaient comment gérer, comment obéir, comment se développer et comment s'améliorer.

L'attention du personnage, que j'appelle Porcinet, dans le "Samurai Code" a été attirée par ces deux phrases. Il a vu que:

• La décision doit être prise très rapidement - en sept respirations;
• Et si vous ne prenez pas une décision rapidement, le résultat sera désastreux.

Piglet était tellement emporté par cette idée que s'il ne pouvait pas prendre de décision en sept respirations, il refusait. Une fois, j'ai même raté un alcool amusant.

Cela est devenu intéressant pour moi, j'ai relu ce livre et j'ai remarqué qu'environ chaque 10e page dit: pour prendre des décisions rapidement, vous devez penser à l'avance comment vous allez agir dans une situation donnée.

À quoi ça ressemble?

C'est comme une stratégie lorsque vous avez des règles pour prendre des décisions .
Quelle est la stratégie la plus courante dans notre pays? Lorsque vous demandez à quelqu'un: "Quelle est la stratégie de votre entreprise?", Ils vous montrent un long "pied" qui dit ce qu'ils feront cette année - quels sont les plans, les budgets, les tâches de l'entreprise, comment ils vont croître dans les ventes, etc. .d.

Cette définition ne m'est pas proche, elle ne convient pas à mes fins.

Par conséquent, nous n'avons laissé pour nous que la deuxième définition et avons commencé à percevoir la stratégie uniquement comme un ensemble de règles pour prendre des décisions .

En conséquence, le changement zéro que nous avons introduit dans notre processus Scrum était que, dans notre équipe , essayant de nouvelles techniques d'accélération, nous formulons des principes pour eux , leur donnons des noms (pour les rendre plus faciles à retenir et à discuter), et les utilisons plus dans notre travail . Ces principes sont porteurs de tout le reste.

Le principal secret des améliorations

Le prochain principe fondamental auquel nous sommes parvenus est «le principal secret de l'amélioration» .

Vous le voulez, croyez-le, vous le voulez - non, mais nous avons trouvé le «secret principal des améliorations», dont nous avons vu l'efficacité à maintes reprises.

Il peut être formulé comme suit: 75% des problèmes de changement surviennent du fait que les gens ne travaillent pas comme on leur a dit.

Pourquoi cela se produit-il? Le fait est que les gens qui essaient de mettre en œuvre des changements (par exemple, Scrum) viennent dire à leurs subordonnés: "Vous travaillez maintenant d'une nouvelle manière." Et puis ils partent. Et quand ils reviennent dans une semaine ou deux, ils voient qu'il n'y a pas de résultats. Et à la fin, ces «tricheurs» décident que Scrum ne fonctionne pas et le suppriment définitivement de leur mémoire et de leur ensemble d'outils. La même chose se produit avec toutes les autres méthodes. J'ai vu cela un nombre fou de fois dans mon entreprise, et ils ont constamment essayé de me convaincre que quelque chose (une sorte de changement) ne fonctionnait pas.

Par conséquent, nous avons formé les principes de base du changement - pour que des changements se produisent, ils doivent être appliqués . Si nous décidons de ne pas avoir de support technique aujourd'hui - nous voulons juste voir ce qui se passera sans support technique - alors il n'y a pas de support technique, et rien d'autre.

C'est probablement la chose la plus importante sur laquelle notre succès a été basé - sur le fait que les gars qui ont travaillé avec moi ont accepté ces règles. Ils ne m'ont pas demandé d'ordres, d'instructions, de changements de personnel ou de permutations. Nous venons juste d’accepter et de le faire ensemble. En conséquence, en un jour, nous avons pu vérifier le fonctionnement de certaines méthodes, pratiques, etc.

Il y avait toujours beaucoup de managers sympas autour. J'ai moi-même voulu une fois le devenir.

Qui est un manager sympa? C'est celui qui croit qu'il est nécessaire de fixer une tâche, de nommer la date limite, et quand la date limite passe, et que la tâche n'est pas terminée, l'exécutif est à blâmer. Ce n'est pas le mien, mais leur expression. Ils le disent: Scrum est une merde, vous devez définir des tâches et les sécher quand ils ne respectent pas les délais.

Mais nous avons décidé par nous-mêmes que les délais sont mauvais . Pourquoi?

• Premièrement, lorsque vous disposez d'un pool de tâches, par exemple 150, et que vous définissez une date limite pour chacun d'entre eux, vous devez recalculer ces dates chaque jour, car elles «flottent» tout le temps. En conséquence, beaucoup de temps est consacré à l'administration;
• Deuxièmement, du fait que les dates «flottent» tout le temps, elles sont toujours incorrectes ;
• De plus, le degré auquel une personne tombe dans le temps ne signifie rien du tout . C'est juste qu'une personne, pour une période, pourrait avoir une tâche;
• Et pour quoi ont-ils alors besoin? Si vous vous embêtez beaucoup, mais en fait le timing est toujours mauvais? Le timing est juste un fétiche;
• Nous avons décidé par nous-mêmes que la gestion du timing est une «approche féminine» dans la gestion .

Le dernier point doit être clarifié séparément. Je demande immédiatement aux femmes de ne pas être offensées, d'autant plus que cette approche est désormais encore plus courante chez les hommes. Cette métaphore a été inventée afin d'expliquer en quelque sorte les actions de certains managers.

Une analogie de la vie: imaginez qu'une femme demande à un homme de réparer un robinet et lui donne 5 jours pour le faire. Que va-t-il se passer pendant ces cinq jours? Un homme va faire certaines de ses affaires et une femme le rappellera? Non, ce ne sera pas le cas. Elle viendra tous les jours et regardera tranquillement - réparée ou non réparée. Et voici le cinquième jour, la femme se lève, regarde - ne l'a pas réparé. En attendant le matin et le matin ...

Et surtout, pour une femme, c'est un résultat positif . Pourquoi? Parce qu'après cela, vous pouvez faire comme ça:

Tracez maintenant une analogie avec les managers difficiles qui fixent la tâche afin que la personne ne l'achève pas à temps, puis elle pourrait être explosée . Il me semble que c'est une sorte de sadisme. Ils s'amusent tellement et croient que c'est du travail , et pour cela, vous devez payer 300-500 mille roubles par mois.

Nous ne sommes pas comme ça, nous avons donc formulé pour nous-mêmes le principe qu'un terme n'est nécessaire que lorsque rien ne doit être fait après . Par exemple, la date limite de déclaration. Après cela, vous ne pouvez plus faire la tâche, car la pénalité pour déclaration tardive, semble-t-il, est d'environ 20% des revenus?

Buts

Il est certain que tout le monde a vu ses subordonnés dans cet état.

Vous venez travailler - et votre employé est assis comme ça.

Ou comme ça.

Que faire avec ça? Je faisais ça:

En conséquence, il a été franchement envoyé plusieurs fois, une fois amené une personne à l'évanouissement, et cela ne compte pas les larmes versées - hommes et femmes. Dégoûtant, toujours honteux.

Une personne qui hurle constamment se transforme en merde. Bien qu'il soit plus correct de dire que c'est le connard qui l'a fait comme ça.

Pourquoi cette condition est-elle mauvaise? Si vous criez constamment sur une personne, vous ne verrez plus ses larmes, ce qui signifie que vous ne saurez pas qu'elle est assise et ne fait rien . Parce qu'une personne en dépression ne fait rien . Pour l'efficacité, c'est une énorme perte. Si une personne est déprimée le matin, elle passera toute la journée à naviguer sur Internet, ouvrira le configurateur et basculera rapidement. Pourtant, les programmeurs sont assis près du moniteur depuis la porte, non?

Par conséquent, il vaut mieux ne pas crier après les gens. Il est nécessaire d'analyser la situation et il peut s'avérer que la personne n'a aucune motivation courante . Mais une personne n'a aucune motivation parce qu'elle n'a pas de but . Il est venu travailler et ne sait pas pourquoi. Et s'il a également reçu une sorte de négativité à la maison, par exemple, parce qu'il n'a pas atteint ses objectifs à la maison (sa femme veut partir en vacances aux Maldives, mais il ne peut pas le fournir), il vient travailler juste pour s'asseoir . Parce que comment atteindre l'objectif, il ne sait pas . Ou peut-être qu'il n'a aucun but.

Par conséquent, nous avons formulé pour nous-mêmes le principe selon lequel nous devons parler d'objectifs . D'abord, nous nous sommes assis un à la fois, avons parlé, puis nous nous sommes réunis, avons discuté.

En conséquence, nous avons réussi à dériver un certain objectif «moyen» - un pour tous .

Cet «objectif moyen» était le suivant: travailler pour le futur employeur . Cette formulation a beaucoup de sens (enfin, il me semble). Je n'en mentionnerai que deux:

• Premièrement, l'objectif du programmeur n'est pas lié au travail en cours pour l'organisation actuelle. Parce que les gens qui s'attachent à l'organisation actuelle lorsqu'ils la quittent reçoivent un très gros coup à leur importance. Après tout, ce qui était important ici, personne n'en a besoin .
• Deuxièmement, que signifie «travailler pour le futur employeur»? Cela signifie acquérir l'expérience la plus abstraite qui sera utile à la plupart des futurs employeurs.

C'est l'objectif que nous avons formulé pour les enfants, et cela a eu un effet très positif sur eux.

Quelques mots sur la «personnalisation à la volée» est un moyen purement technique pour accélérer le travail.

L'image montre une liste incomplète de ces accélérateurs. Ce sont des solutions abstraites qui résolvent très rapidement certaines classes de problèmes . L'exemple le plus courant est la validation des données. Au lieu de chaque fois que l'utilisateur veut interdire quelque chose tout en tenant un document, écrire du code pendant 30 minutes, nous effectuons une vérification en trois minutes sans lancer le configurateur. C’est tout.

Après avoir ajouté l '«objectif moyen» et la «personnalisation à la volée», nous obtenons le «kit de mise à pied». Qu'est ce que c'est Ce n'est que l' ensemble des connaissances, de l'expérience, des idées qu'une personne, quittant l'entreprise, emporte avec elle .

Pour chaque membre de l'équipe, nous avons dressé une liste assez longue de ce que nous devons étudier, de ce que nous devons essayer, de ce que nous devons comprendre, de sorte que lorsque nous quittons l'entreprise, cela puisse être appliqué à un nouvel emploi.

Les priorités sont une chose incroyablement importante.

Dans ma vie, j'ai essayé de nombreuses options différentes pour attribuer des priorités aux tâches - dans la mesure où j'ai utilisé le modèle de développement vectoriel innovant d'une entreprise à partir d'une thèse de doctorat en économie.

Mais la pratique a montré que l'efficacité est dans la simplicité. Par conséquent, pour définir les priorités, j'ai finalement choisi la matrice Eisenhower habituelle . Tout le monde connaît cet outil - lorsque toutes les tâches sont divisées en quatre carrés.

Dans les principes de l'équipe, cela se reflétait comme suit:

• L'urgence / l'importance est mise par le (s) gestionnaire (s);
• L'employé n'a pas le choix de l'ordre d'exécution;
• Pour Nefig.

Pourquoi l'employé n'a-t-il pas le choix d'un ordre d'exécution? Parce que la possibilité de choisir une tâche pour le programmeur est un mal terrible pour l'efficacité . Il peut choisir une tâche toute la journée. Qu'est-ce qu'un jour? C'est 20% de la semaine. Voilà, la journée est passée. Il ne se contente pas de choisir une tâche, il peut aller dans le configurateur, voir comment elle est résolue, quels sont les pièges, puis il aura peur et changera d'avis à ce sujet. Et donc ça va toute la journée, et peut-être plus.

Et les deux plus grands maux pour l'efficacité sont quand une personne a peur et quand elle ne comprend pas .

Effrayant - c'est quand une personne s'assoit et lui:

• Effrayant de demander;
• C'est terrible de se tromper;
• Il est effrayant de distraire des collègues pour leur demander quelque chose;
• C'est terrible de ne pas le faire de manière optimale, car ils vont le gronder.

, . , – , – ?
, , . , . . ?

, .

, metadata.js.

, , 20 . , , – , – . .

, . , .

, . . , . , , .

, ? , , , .

- , , , . ? : « , ». , . - – . , : «, , ». , , , , . , , .

, ? – , . :

• .
• « ». , – . , , – . – , , .
• - – - . , - , – . , : «, , , , , ». , – 30 .
• – . : , , , . , . : , . : «, , » – . - - .

, , . – – , , .. , .

– , ? . , , , , .

. 30 % . :

• – ;
• – ( - , --);
• – ;
• – .

, … , , . , , , . , . .

– .

, , . . , — , . , , – , . – . , . , . – . , , , .

, , .

… , « ». .

, ? . :

• , ;
• , , ;
• , – ;
• .

, , , . , - , .

, , .. , – . – , , , . « », .

, . . , – , - . , , , , – , , , , – -, .

, , , , . , – , , , -, , , . , . , .

. , , , . , . , . , , . .

Déposé chez eux, au service des achats, Piglet. Je dis - depuis combien de temps pleurez-vous que vous manquez d'automatisation? Voici Piglet à votre entière disposition. L'atterrissage était avec une intention malveillante, car Piglet est un gars gai et charmant, et les filles l'aiment vraiment (dont la plupart sont dans le service des achats).

Pendant une semaine, il s'est simplement assis avec eux - c'était la tâche du centre, de s'asseoir et de regarder. J'ai regardé, je suis venu et j'ai dit - ils travaillent 3% du temps. Ils fonctionnent - dans le sens d'achat, de recherche de fournisseurs, de passation de commandes, c'est-à-dire remplir leur fonction principale. Tout le reste du temps, ils sont engagés dans une sorte de processus, un non-sens bureaucratique et autre.

Naturellement, nous n'en avons pas informé les acheteurs, afin de ne pas être offensé. Piglet a reçu une nouvelle tâche et est retourné à l'approvisionnement. Il a commencé à poser au patron des questions inconfortables, ou tout simplement à la traîne. Assez pour quelques jours - la patronne elle-même est venue nous voir au département informatique et dit - ahhh, qu'en est-il de ce zoo?

Eh bien, j'ai encore un plan de l'époque de Vasya - ici, je dis, faisons-le. Et c'est tout.

Maintenant, un peu sur le lapin. Il a travaillé seul très longtemps dans des usines.

Qu'arrive-t-il à une personne lorsqu'elle travaille seule à l'usine pour 1C en tant que programmeur? Il commence à résister aux tâches. Il le fait de très haute qualité - je vous le rappelle, le lapin est très intelligent, il a bien étudié à l'école et à l'université. Ils lui apportent une tâche, ils disent - faisons-le, et Rabbit répond - non, vous n'avez pas besoin de le faire, et donne beaucoup de raisons apparemment objectives pour lesquelles le problème n'a vraiment pas besoin d'être résolu.

Tout irait bien, mais il a commencé à faire de même avec moi. Par exemple, je lui ai confié la tâche. Il ne dit rien, s'assoit devant l'ordinateur.

Je vais à mes affaires et pense sincèrement qu'il s'assoit et résout le problème. Et lui, le chien, s'assoit et réfléchit pourquoi cela ne devrait pas être fait . Le résultat de son travail en un jour, voire deux, est une liste de haute qualité des raisons pour lesquelles la tâche ne doit pas être effectuée!

Et s'il réussissait toujours à surmonter cette étape, il se penchait en arrière sur sa chaise, leva les yeux vers le plafond et commença à dire quelles difficultés il rencontrerait pour résoudre ce problème. Je dis - euh, arrête! Savez-vous comment faire tout cela? Eh bien, oui, il le fait. Alors pourquoi me parlez-vous de vos difficultés ici! Eh bien, donc je ... - dit Rabbit.

En conséquence, nous avons formulé le principe le plus simple: le problème doit être résolu . Peu importe ce que vous en pensez, si moi, en tant que leader, j'ai pris cette tâche au travail, vous devrez la résoudre - sans options. Ne cherchez aucun moyen d'échapper à cette tâche. Et c'est tout, plus de ces situations ne se sont pas produites.

Il s'agit d'un principe très simple. Les tâches sont grandes et petites. Scrum dit - vous devez diviser les tâches en morceaux afin que chacune ne prenne pas plus d'une journée.

Mais parfois ça se passe comme ça. Un homme s'assoit, fait une tâche et termine, par exemple, à 15 h 00, deux heures avant la fin de la journée de travail. Réticence à démarrer une nouvelle tâche. De même le matin - alors que le café, le courrier, les réseaux sociaux, cela, et alors seulement les tâches.

Pour utiliser efficacement ces délais, nous avons identifié un ensemble spécial de tâches, que nous avons appelé «raccourcis». Ils n'obéissaient pas à la matrice d'Eisenhower, se trouvaient sur une liste distincte et étaient destinés spécifiquement à «boucher les trous». Il reste une heure avant la fin de la journée de travail - faites quelques shorties. Simple, sans plonger dans le contexte, mais des tâches bénéfiques. Si vous ne les ignorez pas, vous pouvez obtenir une augmentation de l'efficacité de trente pour cent.

La mouche importune est moi.

Scrum classique dit que vous devez faire des réunions quotidiennes le matin. Et je me souviens de mon contrôle préféré et je regarde à travers son prisme. Que sont les réunions quotidiennes du matin? Il s'agit d'un acte de gestion une fois par jour. C'est-à-dire dans Scrum classique, vous pouvez vous approcher de la barre une fois par jour.

Cela ne me suffit pas, car si lors de la réunion une personne a dit que tout fonctionnait bien pour lui, et après cinq minutes, cela n'a pas fonctionné, alors je ne le saurai que le lendemain, après avoir perdu 20% d'efficacité.

J'ai donc remplacé les réunions quotidiennes par le contrôle.

• Vous demandez une fois par jour - vous gérez une fois par jour;
• Vous demandez une fois par semaine - vous gérez une fois par semaine;
• Vous demandez une fois par mois - vous gérez une fois par mois;
• Vous demandez 5 fois par jour - vous gérez 5 fois par jour;
• La gestion est un changement dans la bonne direction .

Naturellement, une planche de mêlée n'était pas adaptée à un tel contrôle. Elle répond à la question "ce qui a été fait pendant le sprint", mais ne sait rien de ce qui a été fait le matin ou hier. Ils ont essayé de s'adapter - par exemple, d'écrire la date et l'heure de l'exécution sur un autocollant, mais la lecture de ces informations n'est pas pratique.

Par conséquent, le scrum-board, en tant que leader, m'a terriblement enragé - n'a pas fourni d'informations à la direction. Eh bien, je l'ai jeté, remplaçant l'automatisation simple du système d'information. La tâche close est immédiatement tombée dans le rapport, que j'ai divisé en deux sections - depuis le début de la semaine et le matin. En contrôlant ces deux indicateurs, à tout moment, j'ai vu qu'une sorte d'échec avait disparu.

Les principes sont simples:

• Regardez le volume des tâches plusieurs fois par jour ;
• Renseignez-vous consciemment et d'urgence sur les difficultés et les obstacles;
• Comprendre immédiatement;
• Merci 1C: AVANT, bye scrum-board.

Résultats finaux

En conséquence, nous avons obtenu une certaine technique avec des principes et des points de contrôle. Étant donné que nous avons déjà élaboré les principes, nous avons dû trouver un nom, car sinon, il n'est pas pratique de discuter. La recherche du nom a pris exactement une minute!
D'abord, comme ça.

Et puis comme ça.

L'expérience que nous avons menée selon la méthodologie «kazakhe» a duré environ un an.

• Permettez-moi de vous rappeler qu'avant l'introduction du Scrum classique, notre efficacité était de 4,2 points.
• Book Scrum a relevé le score à 7,73 points.
• Et sur la mêlée «kazakhe», nous avons commencé à donner 17 points.

Et après tout cela, j'ai quitté cette entreprise, et un «manager coriace» est venu à ma place. Un manager vraiment cool, que Scrum appelle "scrum" et qui dit que c'est une technique nouvelle. Depuis que mes gars sont restés dans l'entreprise, ils ont continué à mesurer leur efficacité et m'ont donné leurs indicateurs de la façon dont ils travaillent maintenant. Maintenant, leur efficacité est tombée à 2,5 points.

Si nous calculons le quotient des mesures finales et toutes premières, il s'avère que toutes les méthodes et tous les principes appliqués nous ont permis de multiplier par quatre l'efficacité .

PS Il existe également une version vidéo: un et deux .