Où avons-nous obtenu la bouteille?

Flowcon, ou bouteille - technique de gestion, y compris les tâches. Stream, projet, développement, fonctions de routine, régulier, etc.

Beaucoup de gens, ayant appris la méthodologie et les solutions qui en découlent, posent des questions - quoi, comment, quelle est l'essence, sur la base de quelles «pratiques mondiales» sont faites, quelles mesures sont utilisées, à qui cela convient, d'où vient-il. J'ai répondu chacun individuellement, mais j'ai décidé - tout, arrêtez, fatigué d'écrire cent fois la même chose. Je suis programmeur, ou qui? La réutilisation peut être non seulement pour le code, mais aussi pour l'information. J'écrirai une fois, j'essaierai de répondre à toutes les questions de l'article, et quoi qu'il arrive.

Mieux encore, me semble-t-il, à présenter sous la forme d'une histoire, car la naissance d'une bouteille est intimement liée à ma carrière, pour ainsi dire. Je vais le faire. Pourchassé.

PMBOK

La première technique de gestion de projet et de tâche que je connaissais s'appelait PMBOK. C'était l'année lointaine 2006.

À cette époque, PMBOK était presque un monopole dans la gestion de projet. Dans les curriculum vitae et les postes vacants, il a seulement été entendu que PMBOK. Il n'existait alors aucune méthodologie flexible, même si elle existait déjà quelque part.

Le PMBOK était alors une méthode de gestion de projet purement en cascade, c'est-à-dire supposait une structure rigide d'étapes et de tâches, des délais et des dépendances de bout en bout. En conséquence, il s'est rapidement et magnifiquement brisé en fragments dans les projets de mise en œuvre 1C de l'époque, en raison de la violation constante de la fameuse (alors) règle du triangle Budget - Temps - Contenu.

À cette époque, ni les clients ni les exécutants n'étaient en mesure de faire des spécifications techniques raisonnables, de rédiger des exigences fonctionnelles, de simuler le travail de l'entreprise. Oui, et les configurations, comme SCP, ont constamment surpris - elles se sont développées. En conséquence, la liste des œuvres compilée est devenue sans objet quelque part un jour après le début du projet.

Mais les cerveaux des programmeurs sont curieux, et ils ont trouvé une certaine combinaison de PMBOK et de l'Agile alors inconnu. Nous l'appelons le bord jaune. Et moi aussi, j'ai été forcé de devenir son apologiste.

Bord jaune

L'Edge jaune était basé sur les scènes créées par PMBOK, ne remplaçant radicalement l'objectif de chacune d'elles. Quel est le but de PMBOK? Terminez toutes les tâches de la scène.

The Yellow Edge est venu avec un autre objectif: signer l'acte . Par exemple, il y a une étape - «Mise en œuvre de la comptabilité d'entrepôt». Au stade de la conception et de la rédaction des savoirs traditionnels, certains travaux y figurent, tels que «Rapport matériel», «Formation des utilisateurs», «Définition des droits d'accès», etc. - en fonction de la profondeur des études au stade de l'examen express.

Cette liste d'œuvres a servi de kit de démarrage pour commencer avec quelque chose. Un programmeur vient à la tête de l'entrepôt, ou des commerçants, ou des comptables de matériel, commence à leur parler, et il s'avère ... Eh bien, il y a tellement de choses à apprendre que les cahiers se sont terminés avec une force terrible.

Au début, le cerveau gâté par PMBOK a dit: non! C’est impossible! Il suffit de faire ce qui est écrit dans les TK! Et les chefs de projet ont entamé de longues négociations négatives avec le client. Quelqu'un a réussi à convaincre le client pour un travail supplémentaire, une tâche technique supplémentaire, etc. La plupart n'en ont pas. Le client a dit: bon sang, les gars, je ne sais pas ce que sont les savoirs traditionnels et quelles améliorations doivent être apportées à votre programme pour que tout fonctionne pour moi, mais si cela ne fonctionne pas, je ne signerai pas la loi .

La réalité, dans l'ensemble, a gagné, et le projet a vécu en deux dimensions - plan et fait. Il semblerait que le plan puisse être rejeté, mais il y a un hic - un budget a été établi en fonction de celui-ci, qui est protégé par le chef de projet de la part du client, et vous ne pouvez pas y toucher. Mais le fait est resté - il faut faire un minimum du maximum de ce que le client veut signer l'acte, sinon il n'y aura pas de paiement ou, en conséquence, de salaire.

Donc, dans ma tête, il y avait un modèle d'Edge, bien que jaune. La bouteille a commencé à se former et contenait deux pratiques de gestion des tâches. Il semble qu'ils se contredisent, mais ils s'entendaient bien dans la vie.

CORE PM

Donc, au tas, je vais mentionner. Voyant les problèmes de gestion de projet entre moi et mes collègues, j'ai commencé à choisir la théorie en dehors de PMBOK et j'ai trouvé un livre dans le magasin avec le titre simple "Project Management", écrit par les quatre Tates. Ils ont nommé leur méthode CORE PM.

L'essence est à peu près la même que dans PMBOK. L'invariance du plan est appelée la principale. Une procédure directement séparée, large, complexe et bureaucratique a été inventée, comment apporter des modifications au plan.

À ce moment-là, ayant déjà reconnu le bord jaune, je ne pouvais rien ajouter de ce livre à ma bouteille. Et c'est très bien, car je me suis de nouveau rendu compte qu'il n'y a pas d'oncle intelligent dans le monde.

Oncles intelligents

À propos du fait qu'il n'y a pas d'oncle intelligent dans le monde, j'ai compris il y a longtemps, de retour à l'institut, lorsque je suis passé par la pratique. Ensuite, j'aimais les méthodes statistiques de gestion de la qualité des produits, et je suis allé à l'usine, où j'ai passé un mois à recueillir des données pour le diplôme.

Au départ, l'objectif était précisément la collecte de données que l'enseignant et moi voulions ensuite tordre dans des logiciels spécialisés (Statistica?). Il semble que l'idée était de construire un modèle mathématique de production de convoyeurs afin de comprendre l'influence des différentes étapes sur la qualité du produit final.

L'enseignant, avant le voyage, m'a remis quelques livres sur les cartes de Shekhart, le contrôle statistique des processus (SPC), la gestion générale de la qualité (TQM). Apparemment, lui-même ne les a pas lus - sinon il ne proposerait pas de construire un tapis. modèle de production. Ils étaient adaptés, par exemple, aux capteurs de pression, où la construction de modèles et l'analyse de régression Draper étaient la base de l'étalonnage, mais pas pour l'industrie automobile.

Et j'ai lu des livres. Tout était si simple là-bas que c'était à couper le souffle. Et l'usine avait également des Smart Uncles dans le service de gestion de la qualité. Ils connaissaient les concepts de base de ces livres, mais, à ma grande surprise, ils n'ont jamais utilisé non seulement des méthodes pour améliorer la qualité, mais même les formules les plus simples pour évaluer l'état actuel du processus technique.

Et les formules étaient méga-simples. Vous prenez une centaine de détails, mesurez, saisissez les nombres dans Excel, calculez la moyenne, l'écart type (le même sigma) et affichez un indicateur simple et compréhensible - l'indice d'aptitude ou l'indice de reproductibilité (si le processus est stable). En fait, cet indicateur indique clairement si tout est normal ou non avec le processus.

Quand j'ai calculé ce chiffre, ils étaient sous le choc. Et du fait qu'ils ont finalement vu ce chiffre, et à quel point il s'est avéré terrible. Ils ont demandé à compter pour quelques pièces et machines supplémentaires - mais qu'en est-il de moi?

Ensuite, il y a eu beaucoup de choses intéressantes, y compris un simple effort, en ma présence, pour améliorer radicalement la qualité de la production. Mais ce n'est pas l'essentiel.

Une pensée clé m'est alors venue: les Smart Oncles en savent beaucoup, mais ne font rien .

Les méthodes sont complètes - à la fois en gestion de la qualité, en gestion de tâches / projets et en gestion générale. Demandez à n'importe quel manager efficace - je vais vous donner une conférence sur comment et quoi faire selon telle ou telle technique. Et demandez brièvement - fait-il ce qui est écrit dans la méthodologie? Les figues là-bas.

La bouteille a été enrichie de connaissances très utiles. Tout doit être fait et vérifié par soi-même, personne ne peut faire confiance, surtout ceux qui ne peuvent pas montrer leurs résultats dans la pratique.

Modèle de gestion russe

Réalisant que je devais tout comprendre moi-même, j'ai décidé de lire autre chose. Je ne voulais pas apprendre une nouvelle technique toute faite, mais comprendre quelque chose de plus fondamental. Le livre «Russian Management Model» d'Alexander Prokhorov a attiré mon attention.

Dire que le livre est brillant, c'est ne rien dire. Vous devez le lire si vous travaillez en Russie. Heureusement, il n'y a pas de recettes toutes faites là-bas, mais toutes les raisons profondes pour lesquelles nous avons tout tel quel sont élégamment peintes.

Je ne peindrai pas longtemps, je ne mentionnerai que quelques réflexions importantes qui sont importantes dans le cadre de ce matériau.

La première est que le travail du peuple russe doit être mesuré afin qu'il ne se torde pas. Parce que nous sommes tellement habitués à tromper n'importe quel système que nous le faisons inconsciemment. Nous n'acceptons pas les règles, restrictions et lois. Plus précisément, nous hochons la tête, sommes d'accord et nous pensons déjà comment nous tromper.

Le deuxième - le peuple russe fonctionne mieux dans ce qu'on appelle cellules de cluster, c'est-à-dire petites équipes pas trop contrôlées. L'espace ouvert n'est pas pour nous. Comme vous le comprenez, le même principe est inscrit dans une mêlée.

Troisièmement, les Russes ne font rien, comme on leur dit. C'est une idée clé lors de la mise en œuvre d'une méthodologie. Vous donnez des instructions sur la façon d'agir, libérez les gens et attendez le résultat, mais ce n'est pas le cas. Parce que les gens jettent vos instructions et font comme avant.

La bouteille après ce livre est incroyablement enrichie. Il est vrai que les méthodes de résolution de ces problèmes "russes" devaient être recherchées seules. J'ai trouvé le contrôle.

Contrôle

Le contrôle est un contrôle basé sur des nombres. Une de mes techniques préférées. J'insiste sur l'essentiel: contrôler n'est pas contrôler. C'est la gestion.

S'il n'y a pas de nombres, le contrôle est effectué à l'aveugle, sur la base d'informations indirectes. Lorsque vous travaillez avec des tâches, cela est particulièrement vrai, car un système de mesure des tâches est généralement sans valeur. Habituellement, ce sont les coûts de main-d'œuvre en heures, le délai (et le respect) et, en fait, les éléments des tâches résolues. Il est impossible de gérer efficacement sur la base de ces données.

La partie du contrôle qui formule les exigences d'information, c'est-à-dire nombre, méthodes d'obtention, reproductibilité, qualité, profondeur d'étude, etc.

Le chiffre doit être de haute qualité, mais vous en voyez rarement de tels. J'ai déjà écrit plusieurs articles à ce sujet, je ne vais pas me répéter. Croyez-moi, vous ne trouverez pas de chiffres de très haute qualité en contrôlant très souvent les critères. Probablement parce que personne n'a lu l'article sur le contrôle sur Wikipédia.

Ainsi, le contrôle est apparu dans la bouteille. Il est universel et contrôle désormais la formation de tout nombre requis par toute technique.

Gestion des limites

La gestion des frontières, ou gestion des frontières, est une science peu connue de la transformation des systèmes d'entreprise. Bien que, peut-être, quelque chose ait déjà changé maintenant - je l'ai étudié il y a plusieurs années, selon les articles sur les œuvres d'Eric Trist et de quelqu'un d'autre, je ne me souviens pas du nom de famille. Maintenant, Internet dit qu'il existe une sorte de livre en anglais sur ce sujet - je ne peux rien dire, je ne l'ai pas lu.

Le résultat est incroyablement simple: les limites . À l'intérieur des systèmes d'entreprise, des processus, même chez une seule personne - beaucoup de frontières. Physique, émotionnel, énergétique, etc.

Les frontières sont mauvaises et bonnes, utiles et nuisibles. Certains interfèrent avec le cours normal du processus, d'autres divisent le flux mélangé en deux parties, ce qui aide à le traiter plus rapidement. Certains isolent une personne des informations nécessaires, ce qui la rend difficile à réagir à temps, tandis que d'autres la protègent des informations inutiles, vous permettant de ne pas être distrait.

Bref, les frontières et leur gestion sont super cool. Pour comprendre cela, vous devez essayer. Pour les personnes intelligentes comme vous, il suffit de comprendre le principe clé pour commencer à l'appliquer. Le reste a besoin d'études de cas et de pratiques spécifiques, et il y en a en fait beaucoup. Seulement, ils ne sont pas sur Internet, mais nous devons l'inventer nous-mêmes.

Je suis venu avec quelques-uns, de publié - Iceberg et la méthode de couloirs de natation .

La gestion des limites a eu une très forte influence sur la bouteille, et presque toutes ses parties - sur la gestion du cycle de vie des tâches, sur l'organisation des priorités, sur la gestion régulière.

Enfer à faire soi-même

Il a appelé cette section la même chose que la publication du même nom. Il s'agissait de la première expérience dans la construction d'un système de gestion des commandes, mémos, plans et projets basé sur les connaissances accumulées.

L'expérience est plutôt réussie, bien que l'article semble plus négatif. Lors de la construction du système, les principes de contrôle, de gestion des limites et d'iceberg (issus de la programmation commerciale) ont été principalement utilisés. Bien sûr, cela s'est avéré trop technocratique, mais l'expérience, dans son utilité, a été énorme.

Premièrement, c'était un système pour toute l'entreprise, et non pour une petite équipe de programmeurs. Deuxièmement, le système a atteint son objectif - il a augmenté la discipline exécutive à des sommets sans précédent.

Mais l'essentiel pour moi est l'utilisation pratique de pièces de la bouteille à grande échelle, et non pas sur des programmeurs, mais sur des gens ordinaires. Selon les résultats, quelque chose a dû être jeté hors de la méthodologie, mais certaines méthodes se sont avérées efficaces. Pour la plupart, bien sûr, le contrôle.

Pensée systémique

Il ne s'agit pas pour moi, mais d'un domaine de connaissance appelé pensée systémique. Il est plein de livres et d'étuis, donc je ne vais pas raconter. Je note seulement un principe très important, qui a grandement influencé la bouteille - les propriétés émergentes ou émergentes. Ce sont toutes les propriétés du système qui ne peuvent être vues qu'à l'état activé.

Pendant que vous vous asseyez loin du système et que vous fantasmez sur son fonctionnement, vous ne voyez pas les propriétés émergentes. Vous pouvez concevoir, dessiner, programmer, tester, même en public, mais lorsque vous démarrez le système dans un travail réel, les propriétés émergentes commencent à fonctionner.

Vous avez, par exemple, supposé qu'une personne pose une tâche et que l'autre s'engage à la réaliser. Et bien. La deuxième personne peut tout simplement ne pas voir la tâche. Et s'il voit, il ne lira pas. Et s'il lit, il dira qu'il n'a pas lu. Ou ne comprends pas. Ou n'est-ce pas son travail. Etc.

Ou vous pensiez que dans l'équipe, le coordinateur est le patron. Ils lui ont fourni un AWP, avec une liste des tâches entrantes qu'il distribuerait aux interprètes. Démarrez le système et vous constaterez qu'il ne distribue rien, mais qu'il court uniquement autour des réunions et des fêtes d'entreprise. Et les tâches sont distribuées par un gars calme et indéfinissable assis dans le coin - un chef caché. Et lui, choqué par le fait qu'il n'ait pas été remarqué, va également commencer à saboter la mise en place de votre système.

Ce sont des propriétés émergentes. Ils ne sont pas visibles lors de la conception spéculative; ils apparaissent lorsque le système commence à fonctionner.

Il est clair que les «propriétés émergentes» sont une telle abstraction que quelqu'un a inventé pour nommer un phénomène qui est compréhensible par tout le monde - vous devez démarrer le système, et quelque chose d'autre en sortira, des erreurs de conception de l'architecture aux bugs triviaux.

Mais dans le cas de la gestion des tâches, nous avons toujours affaire à un système complexe composé d'automatisation, de gestion, de personnes avec leurs relations et des objectifs de l'équipe, des clients, des gestionnaires, etc. Le succès de la gestion des tâches dépend de tous les composants, bien qu'à des degrés divers, et aucun d'entre eux ne peut être ignoré.

Et si, par exemple, vous êtes un programmeur qui automatise la gestion des tâches, vous pouvez non seulement ignorer beaucoup. C’est plus simple. Par conséquent, le système peut et ne fonctionnera pas. Il n'y aura pas de bugs, mais aussi aucun sens.

Et je voulais que ça marche. Par conséquent, j'ai ajouté la pensée systémique à la bouteille - à la fois comme l'un des principes fondamentaux et comme des accents et des pratiques spécifiques.

Codex samouraï et Livre des cinq anneaux

Cela semble étrange, mais ce sont ces livres qui ont fait de la bouteille une bouteille. Je vais expliquer brièvement maintenant.

Un samouraï décent dans la vie a fait cela. Au début, je suis allé étudier les arts martiaux avec un maître. Il a étudié jusqu'à ce qu'il le dépasse. Et ici, nous avons un samouraï décent qui possède la technique d'une certaine école (par analogie - PMBOK).

Il a quitté l'école et s'est éloigné dans l'ancien Japon, à la recherche d'un nouveau défi. Je suis allé dans différentes écoles, j'ai appelé le maître local pour un duel et j'ai pris des décisions en fonction des résultats. Si le maître était plus faible que le samouraï - eh bien, pas le destin. Si le samouraï a perdu, alors il est tombé à genoux et a demandé de le prendre comme étudiant. Et il a étudié jusqu'à ce qu'il excelle à nouveau le maître.

Cela s'est répété plusieurs fois. Et à un certain moment, le samouraï avait son propre style.

En général, il n'est pas né de tout le monde, c'est normal. Certains sont restés "sans visage", n'étant que les maîtres de plusieurs écoles bien connues (ce type de MBA).

Et certains ont trouvé leur propre style avant même d'entrer dans la première école. Par exemple, l'un des héros nationaux du Japon, Miyamoto Musashi, l'inventeur du style des deux épées et l'auteur du Livre des cinq anneaux. Ou Masutatsu Oyama, un ressortissant coréen, le créateur de l'école de karaté Kyokushinkai. L'un et l'autre ont inventé leur méthode quelque part au début d'une carrière, puis l'ont perfectionnée. Cela et un autre sur le chemin rencontrèrent des maîtres plus puissants et restèrent à apprendre d'eux.

Mais ni l'un ni l'autre n'ont quitté leur équipement pour le remplacer par un étranger qui semblait plus fort à un moment donné. Ils ont simplement enrichi leur technique.

Et enfin, un samouraï décent, qui a vaincu tout le monde, a ouvert sa propre école. Et d'autres samouraïs sont venus vers lui, quelqu'un a gagné et est parti, quelqu'un a perdu et est resté. Et ainsi de suite à l'infini. Ainsi, Masutatsu Oyama, ne trouvant pas d'adversaires parmi les gens, a commencé, pour une raison quelconque, à tuer les taureaux.

Donc, après avoir lu ce livre, j'ai d'abord compris ce que je faisais. Comme un samouraï décent, j'ai commencé avec l'école à distance de marche - avec PMBOK. Puis il a commencé à ajouter d'autres écoles. Certes, j'ai souvent fait une erreur indécente pour un samouraï décent - je n'ai pas combiné la pratique, mais je l'ai remplacé par un autre, à la recherche d'une balle d'argent. PMBOK ne convient pas - nous le jetons, prenons CORE PM, cela ne fonctionne pas - nous le jetons à nouveau, nous jetons dans la mêlée, etc. Par conséquent, j'ai changé de tactique - j'ai commencé à appliquer de nouvelles pratiques à titre d'expérience, à voir ce qui se passe et à laisser les solutions les plus efficaces dans la bouteille.

Programmation d'entreprise

La programmation d'entreprise est un ensemble de méthodes et de pratiques simples pour améliorer une entreprise. Au moins l'ensemble, au moins une certaine partie.

Il se trouve que la programmation d'entreprise s'est développée en parallèle avec la bouteille, et l'objet de l'amélioration était tout sauf le service informatique natif.

Mais, à un certain moment, la compréhension est soudainement venue. Eh bien, je n'ai pas tout à fait raison. Je sais comment améliorer n'importe quel processus et je tourmente mon processus natif avec des méthodes étrangères.

En général, j'ai appliqué la programmation d'entreprise, et pour la première fois de ma vie, j'ai reçu une augmentation mesurable de l'efficacité des programmeurs, et immédiatement - deux fois. Les changements concernaient le processus, la motivation, l'objectif, le système de gestion et l'automatisation. En général, les cinq composants avec lesquels la programmation d'entreprise fonctionne. Nous avons construit notre travail nous-mêmes.

Le résultat m'a impressionné, ainsi que les programmeurs, la direction et les spécialistes des systèmes de motivation. Mais moi, n'étant pas un samouraï décent, j'ai jeté tous les résultats à la poubelle, car à la vente, j'ai acheté un livre sur la mêlée.

Scrum

Il y a deux drames dans ce monde - le bien et le mal. Le bon est décrit dans un livre de Jeff Sutherland. Mauvais - en soi-disant scrum guide, et les auteurs énumèrent toujours le même Jeff Sutherland.

La mêlée correcte dit: il est possible et nécessaire d'accélérer le travail de 4 fois. Le mauvais ne dit rien, vous donne juste quelques règles.

Une mêlée correcte fournit honnêtement des références aux méthodes de gestion de la qualité japonaises, les qualifiant de l'un des fondements de la philosophie de la mêlée. En particulier, il recommande d'utiliser les règles d'un samouraï décent - prenez la mêlée comme base et créez votre propre technique. Une mauvaise escroquerie dit - faites ce que nous avons écrit ici. Et si vous le faites différemment, ce n'est pas une mêlée.

En général, j'ai pris le livre et j'ai tout fait tel qu'il est écrit. Tableau, autocollants, rallyes, rétrospectives, etc. Le résultat a répondu à toutes les attentes - nous avons doublé de vitesse, c'est-à-dire que nous avons commencé à produire deux fois plus de résultats par unité de temps.

Cependant, la mêlée dans sa forme pure a dû être jetée pour une raison simple - l'équipe de programmeurs s'est dispersée dans différents bureaux et la possibilité d'utiliser un seul tableau a été perdue. Ils ont souffert pendant un certain temps en utilisant deux planches, mais il y a aussi des rallyes, des rétrospectives qui nécessitent une participation personnelle. Par conséquent, la mêlée a été abandonnée.

Mais le meilleur est resté dans la bouteille. Quel est le meilleur de la mêlée? C'est vrai, le système de mesure des tâches est la planification du poker. Il n'y a rien de plus décent pour évaluer les tâches des programmeurs dans notre monde.

Le système d'horloge précédemment utilisé est bien pire, car l'inflation ou la déflation des estimations surviennent constamment. Les points sont beaucoup plus stables.

Parmi les éléments de mêlée restants dans la bouteille, peut-être, seul un sprint est resté, comme l'une des options de planification. Celui qui a travaillé avec 1C sait que le sprint est la planification de calendrier spatial la plus courante, c'est-à-dire une certaine quantité de produits qui doivent être vendus / achetés / fabriqués pendant une certaine période.

Alors, merci, mêlée, pour tout ce que vous nous avez appris, mais vous avez creusé vous-même votre tombe, avec votre guide mêlée. Nous n'avons pris que le meilleur.

Stream scrum

Ensuite, j'ai eu une telle expérience que la mise en œuvre de la stratégie d'une entreprise. L'expérience est unique pour un programmeur - on peut dire que j'ai eu beaucoup de chance. Il était nécessaire de modifier le travail de la plupart des départements de l'entreprise et, comme vous le savez, une variété de méthodes.

L'une des unités problématiques était l'approvisionnement. Je ne comprends toujours pas pourquoi c'est si difficile - la fonction est simple. Ensuite, j'étais toujours intéressé par la mêlée et j'ai décidé de l'utiliser pour l'approvisionnement.

Mais il a immédiatement rencontré des contradictions méthodologiques. Les programmeurs sont une chose - chaque tâche y est unique et mérite d'être écrite sur un autocollant et suspendue sur un tableau noir. Et quelles sont les tâches des fournisseurs? Acheter une centaine de bagues? Et demain - encore une fois pour acheter une centaine de bagues? Et après-demain?

Bref, les autocollants ne sont pas ça. Et le diagramme de combustion n'est pas ça. Scrum est conçu pour la mise en œuvre d'un projet, et qu'est-ce qu'un projet? C'est une sorte d'activité qui se terminera un jour. Il faut en finir, en ce sens, c'est le but.

Et ici - les achats. Les achats peuvent-ils jamais se terminer? Eh bien, seulement avec l'entreprise. Alors quels sont les achats? Pas un projet, mais un processus. Mais le processus est un mot pour ainsi dire, car il donne également une certaine complétude, et il y a un début et une fin. Et entre eux - une pause fumée, Internet et la communication dans la cuisine.

Le président a donné une réponse en parlant de son travail en tant que Premier ministre en 2008-2012. Il a dit: être le Premier ministre - comment se tenir sous une cascade de tâches, de problèmes et d'objectifs sans fin. Le travail ne s'arrête jamais. Combien n'essaient pas, il y aura toujours quelque chose à faire.

Qu'est-ce qu'une cascade? Ceci est un flux. C'est ainsi que l'idée de flux est apparue. Merci, Vladimir Vladimirovitch.

Comme j'aimais beaucoup la mêlée à ce moment-là, je ne voulais pas abandonner ce nom, et j'ai appelé la méthodologie de la chaîne d'approvisionnement d'abord «mêlée allemande» (car elle était fortement impliquée dans le contrôle, que les Allemands aiment plus que tout autre chose), puis - «Kazakh Scrum» (donc, pour rire), et, enfin, «streaming Scrum».

Le point est simple.Les tâches pour le fournisseur viennent toujours de l'extérieur - des besoins de vente et de production. Le système de priorité pour ces tâches est très simple. Et l'essence du travail est encore plus simple - de la clôture au déjeuner.

Il y a un besoin de bagues - commandez des bagues. Nous avons besoin de boulons - eh bien, vous savez quoi faire. Et ainsi de suite, à l'infini. Parce que le flux.

Et le contrôle, qui est resté longtemps et fermement coincé dans la bouteille, a fourni les mesures correctes et les indicateurs individuels. Il est vite devenu clair que les anciens fournisseurs chevronnés, hélas, fonctionnent bien pire que les "filles" qui prennent et font simplement, et ne parlent pas de "comment c'était avant".

Le résultat a été stupéfiant en termes de qualité et de rapidité de réalisation - en un mois, ils ont rempli l'entrepôt de consignation à un niveau auparavant inaccessible pendant les années de gestion «ordinaire».

Eh bien, ici, à un moment donné, il m'est apparu qu'il n'y a pas de projets sur l'automatisation interne, mais il y a un flux. La décomposition de l'automatisation interne en projets est une convention héritée du grand amour de 1Snikov pour PMBOK. Les projets sont nécessaires là où il y a de l'argent, des délais, des budgets, des formalités et de la bureaucratie. Si tout cela est dans l'automatisation interne, alors, évidemment, quelque chose doit être fait.

En général, les cours d'eau et leur gestion sont fermement entrés dans la bouteille. Pour l’avenir, je dirai que le nom Flowcon est dérivé de l’expression contrôle des flux.

Théorie des contraintes système (CBT)

La théorie de Goldratt sur les contraintes du système est un principe qui dit que dans tout système, il existe une contrainte, le lien le plus lent, dont la vitesse détermine la vitesse globale du système. Eh bien, un tas de méthodes basées sur ce principe ont été développées par Goldratt lui-même et ses disciples. Par exemple, la technique Velocity décrite dans le livre «The New Goal» implique TOC et Lean.

Bien sûr, le principe principal est passé du CBT dans la bouteille - comprendre l'existence des restrictions et les moyens de travailler avec. Je n'écris pas consciemment "supprimer les restrictions", car La TCC implique non seulement l'élimination, mais aussi la protection des restrictions, et parfois leur création artificielle.

C'est la table des matières qui m'a fait regarder non seulement la phase de la tâche, mais aussi le «kit» - ce qui se passe avant et après le travail de l'exécuteur direct. Ce n'est un secret pour personne qu'il faut souvent 15 minutes pour terminer une tâche, et cela prend quelques jours pour accepter, coordonner, accepter le résultat. Et tous ces quelques jours, le client, ou l'initiateur de la tâche, attend.

Ces étapes bureaucratiques, au sein du cycle de vie d'une tâche, peuvent être analysées sous différents angles. TOC dira que ce sont des limitations car elles enlèvent le plus la vitesse de génération des unités de la cible. La même gestion des frontières dira que le problème est la présence de frontières supplémentaires, dans ce cas, entre les personnes impliquées dans la coordination. Beaucoup de temps est consacré à surmonter ces limites.

Les points de vue sont différents, mais le résultat est un - la tâche est résolue de manière prohibitive. Et l'alignement n'est qu'un exemple. Et qu'en est-il du choix de la tâche d'un programmeur lorsque la «newsletter» est trop longue? N'est-ce pas une limitation? Et qu'en est-il du mauvais choix d'un exécuteur testamentaire, lorsque des tâches du même type parviennent toujours au même exécuteur testamentaire et qu'une très longue file d'attente est construite devant lui?

Des méthodes spécifiques de TOC sont également entrées dans la bouteille, par exemple, en utilisant un tampon pour déterminer quand une tâche devrait commencer à fonctionner si elle a un délai. Mais l'essentiel dans CBT, bien sûr, c'est le principe, pas les méthodes. Goldratt lui-même a écrit à ce sujet dans l'article «Debout sur les épaules de géants».

Debout sur les épaules de géants

C'est un article si célèbre de Goldratt, dans lequel il met tout à sa place, y compris - avec ses mots Goldratt, il dit qui sont ces samouraïs décents. Je ne reverrai pas l'article, il est accessible au public sur Internet.

Je ne donnerai qu'une citation clé.

«Il existe une différence entre les solutions appliquées (applications) et les concepts fondamentaux sur lesquels ces solutions sont basées. Les concepts sont généraux, les solutions appliquées sont l'adaptation des concepts à un environnement spécifique. Comme nous l'avons déjà vu, une telle adaptation n'est pas simple et nécessite de développer certains éléments de la solution. Nous devons nous rappeler - la solution appliquée est basée sur les prémisses initiales (parfois cachées) d'un environnement spécifique. Vous ne devez pas vous attendre à ce que cette solution d'application fonctionne dans un environnement pour lequel les prémisses d'origine ne sont pas vraies. "Nous pouvons économiser beaucoup d'efforts et éviter toute déception si nous formulons soigneusement ces prémisses initiales."

Si, selon vos propres mots, Goldratt dit la même chose que le samouraï et la pensée systémique: pas besoin de fantasmer, pas besoin de crier «mêlée pour toujours» ou «TOS - conneries», car vous aurez toujours tort. Prenez et essayez, et n'oubliez pas qu'aucune méthode pure ne vous conviendra. Il faut tout de même observer, penser et ajuster.

Observations

Présentant la bouteille dans différentes équipes, j'ai beaucoup regardé. Il s'est avéré que ce n'est pas seulement simple et intéressant, mais aussi utile. Donc, la bouteille a été enrichie avec un tas de méthodes, de pratiques et de hacks de vie de ma propre invention. Je comprends honnêtement que je n'ai rien inventé de nouveau, et bien sûr certaines méthodes décrivent de telles méthodes, mais il n'y a pas assez de vie pour lire tous les livres.

Par exemple, beaucoup a été écrit sur le caractère destructif du choix d'une tâche. Et si la tâche est sélectionnée, mais qu'il est nécessaire de décider comment l'implémenter, le programmeur, par exemple, peut passer beaucoup de temps jusqu'à ce que le moment soit venu, et il ne prendra pas la première option disponible.

Comme Maxim Dorofeev, l'auteur des techniques Jedi, l'a écrit dans une drôle d'image, quel est l'intérêt d'attendre la date limite à travers * opu, si vous pouvez immédiatement le faire à travers * opu, mais y aura-t-il du temps pour tout réparer?

J'ai vu à plusieurs reprises, en moi-même et chez d'autres, que le choix d'une solution à un problème peut prendre des jours. De plus, les options peuvent être complètement identiques en termes de performances, d'optimalité et de confort d'utilisation. Mais quelque chose ne prend aucune décision, et c'est tout. Travaillez - pendant 15 minutes et réfléchissez - comme si vous construisiez une fusée.

Il existe de nombreux exemples de ce type, et tous ont influencé la bouteille. Et ils continuent d'influencer, car une fois que j'ai compris que mes propres observations ne sont pas pires que les livres, je ne peux plus m'arrêter - il n'y a pas de limite à la perfection.

Automatisation impitoyable

Une fois, après avoir rassemblé toutes mes connaissances en tas, j'ai créé une nouvelle version du système de gestion des tâches, j'ai commencé à appliquer toutes les connaissances de la bouteille et j'ai obtenu un résultat inattendu - la productivité de l'équipe de programmeurs a été multipliée par 4. Probablement, seuls les paresseux n'ont pas encore regardé la vidéo de mes reportages sur ce sujet - une et deux fois .

En fait, cette expérience m'a incité à distribuer la bouteille en tant que technique. J'ai commencé à systématiser les informations et les méthodes, à écrire des articles sur la bouteille et ses méthodes et à parler de ma pratique.

Arrangement pour un nouveau système

Après cette expérience, je suis passé à une entreprise purement logicielle et, bien sûr, j'ai continué à utiliser la bouteille. Mais j'ai rencontré un défi intéressant - je n'avais pas de système de gestion des tâches avec moi, sur lequel j'ai obtenu une accélération 4 fois.

Tout d'abord, je me suis assis et j'ai fait un analogue simplifié, en 1-2 jours. Lorsque vous connaissez la technique, ce n'est pas un problème, surtout si vous n'avez pas à choisir votre commodité, votre interface, etc.

Mais je n'ai pas eu à travailler avec ce système pendant longtemps, car notre entreprise a communiqué avec les clients via GitHub. Si vous le savez, il existe également une sorte de gestion des tâches appelée Problèmes.

Le défi est devenu encore plus intéressant. C'est une chose de créer le système soi-même, à partir de zéro, et c'en est une autre d'adapter l'existant pour qu'il réponde aux exigences de la méthodologie. Bien que vous ne puissiez rien y changer, seules une interface et une API standard sont disponibles.

J'ai donc commencé avec l'API. Cela ne veut pas dire que c'est tout simplement chic, mais cela donne suffisamment de données. Le premier problème s'est avéré être l'impossibilité d'indiquer l'évaluation du problème sous la forme d'un nombre. J'ai dû sortir à travers les étiquettes (étiquettes) - elles sont de type chaîne, mais peuvent être transformées en nombre par un script externe. J'ai écrit ce script et l'ai utilisé pendant plusieurs mois - il a dessiné un graphique d'efficacité.

Mais il y a des problèmes que je n'ai pas pu résoudre sur GitHub. Par exemple, la priorisation. Il y a des balises, il y a des jalons, il y a des projets. Théoriquement, avec leur aide, il est possible d'identifier quelle tâche est la plus importante, mais l'utilisation de ces informations est extrêmement gênante - vous ne pouvez pas trier par étiquettes. Je devrais faire un autre script qui extrait des tâches via l'API, trie et affiche la liste correcte.

En général, la succursale s'est avérée être une impasse. J'ai fouillé dans d'autres systèmes de gestion des tâches en ligne - les problèmes sont similaires. Partout, il y a la possibilité d'entrer et de stocker des données, mais très peu d'outils de configuration - à savoir, la configuration transforme les données en un système de contrôle. Partout il y a une API, et à travers elle, vous pouvez construire votre système, mais la question est alors - pourquoi leur système? Tout comme une source de données?

Ce dilemme est resté dans ma tête pendant plusieurs mois. Faire ou pas? Adapter la technique à GitHub en créant votre propre tache? Ou vers un autre système? Dans sa forme pure, aucun ne convient, mais aucun ne peut être adapté, dans un délai raisonnable. Oui, et utilisez des scripts externes déjà fatigués.

Mais, malgré le dilemme, l'expérience a été couronnée de succès. La bouteille a très bien fonctionné pour elle-même, bien que sur un système assez court, et elle a accéléré le travail - d'abord 4 fois, puis 6, elle a atteint 10. Il est clair que le coefficient dépend du point de référence, mais j'ai cessé de m'inquiéter pendant longtemps - j'ai la bouteille a déjà tout prouvé.

Transfert vers un autre nouveau système

Ensuite, je me suis souvenu qu'il y avait 1C dans le monde, et un produit aussi merveilleux que 1C: Workflow. Si quelqu'un ne sait pas, c'est un tel programme dans lequel vous pouvez configurer n'importe quel processus. En conséquence, il ne contient aucune méthodologie en soi, seulement une technique, et quelqu'un devrait lui dire une technique.

Ici, juste, les gens allaient à la prochaine conférence 1Snu, et j'ai décidé d'y participer. J'ai pris un 1C: flux de documents standard et vide, et j'ai commencé à y mettre en place ma propre méthodologie - une bouteille. Honneur et éloge 1C: Gestion des documents - il a fallu plusieurs heures pour mettre en place, et nous avons obtenu un système de gestion des tâches assez décent qui correspond fortement à la bouteille.

Lors de la conférence, il a parlé, les gens l'ont aimé, beaucoup se sont intéressés à la technique. Il est vrai que peu de gens utilisent 1C: Gestion de documents pour la gestion des tâches - ce fut une surprise pour moi. Ils prennent certains systèmes en ligne dans lesquels rien ne peut être correctement configuré, et il n'y a pas de méthodologie intelligible à l'intérieur, ainsi que le concept d'efficacité. Oh bien.

Le résultat est toujours positif. Lui, couplé à l'utilisation de tâches dans GitHub, a montré que la bouteille peut être complètement intégrée dans d'autres systèmes. Nous avons donc eu du conseil et plusieurs projets pour accélérer les équipes sur leurs propres systèmes.

Propre système

Le conseil est bien sûr amusant, mais long et coûteux. La plupart des gens ne regrettent pas trop de jeter leur ancien système de gestion des tâches, qui est peu utile. Eh bien, les gens veulent deux en un - et la méthodologie et le programme, dans lesquels "tout est conforme à la méthodologie".

Par conséquent, nous nous sommes assis pour écrire notre programme de gestion des tâches, clairement affûté sous la bouteille. Il y a peu de paramètres, car les paramètres peuvent expulser la bouteille du programme, et ce sera le prochain système de gestion des tâches, plus comme un ordinateur portable.

Fait intéressant, le développement du programme a immédiatement commencé à donner une rétroaction à la méthodologie. Certaines choses ont dû être jetées de la bouteille, certaines - ajoutées, quelque chose - ont changé. Bien sûr, nous sommes nous-mêmes rapidement passés de GitHub à Flowcon.

Et coule à nouveau

Je n'ai jamais dirigé d'entreprise auparavant. En fait, je ne peux toujours pas dire que je suis en charge - nous sommes deux ici, et les droits et responsabilités sont divisés environ en deux. Mais nous devons traiter toutes les questions de la vie de l'entreprise, et pas seulement le développement ou la mise en œuvre.

Nous avons le développement de logiciels et de services, la finalisation d'anciens produits, l'introduction de nouveaux clients, les ventes nettes sans services, le soutien aux anciens clients, le marketing, les négociations, les expositions avec séminaires, les problèmes domestiques, comme l'argent, etc. En bref, nous sommes une entreprise miniature.

Cet état de fait nous a fait reconsidérer la bouteille et y introduire deux nouvelles entités - les flux et l'équilibre.

Chaque type d'activité que je dois faire est un flux. Par exemple, je dois programmer de nouveaux produits, résoudre les problèmes des clients sur les implémentations et écrire des articles. Je suis une personne passionnée, comme tout programmeur, donc ce n'est pas si difficile, mais je suis très réticent à basculer entre ces threads.

Je voudrais par exemple m'asseoir pour développer un nouveau produit et ne pas sortir pendant une semaine. Que va-t-il se passer? Il n'y aura pas d'argent, car le diable connaît le nouveau produit lorsqu'il commence à se vendre. Nous devons passer au travail avec les clients.

Si vous vous laissez emporter par le travail avec les clients, un effondrement se produira également, car bâtir une entreprise sur les mêmes services est assez risqué.

Eh bien, impliquez-vous dans la rédaction d'articles - généralement, crachez. Mais alors il n'y aura pas de produits, pas d'argent. Par conséquent, vous devez vous retenir. Au début, il l'a fait sur une intuition, il s'est souvent trompé, emporté et a reçu des échecs. Et puis j'ai réalisé que ce sont des flux, et tout s'est mis en place.

Il y a des flux qui peuvent être mesurés et planifiés. Par exemple, 100 heures par mois - pour les services, 300 points - pour le développement de nouveaux produits, et entre - 4 articles. Chaque flux a sa propre unité et méthode de mesure, et son propre objectif. Et la bouteille doit équilibrer ces flux, assurant un développement uniforme de l'entreprise.

Bien sûr, il n'y a pas trois flux, mais plus - à la fois avec nous et avec vous. Et il faut tout équilibrer pour ceux qui veulent un développement durable, bâti sur une stratégie, et non sur le contexte actuel et l'extinction des incendies.

La bouteille est ainsi passée d'une technique de gestion des tâches à une technique de gestion d'entreprise. Eh bien, ce n'est pas encore tout à fait normal - ce processus est toujours en cours, mais les résultats sont impressionnants.

Gestion du développement

Auparavant, je n'avais pas à m'occuper du développement de produits logiciels de grande diffusion, de box ou de services. Par conséquent, la bouteille ne contenait pas de méthodes spécifiques à ces types d'activités.

Des lacunes sont apparues lorsque nous avons eu un problème - nous travaillons beaucoup et rapidement, et les produits n'entrent pas sur le marché. Comme ils disent dans des blagues sur la mêlée, il reste à comprendre quel genre de merde nous faisons à une telle vitesse.

J'ai dû ajuster la bouteille - pour introduire le concept des versions et reconstruire le système de priorisation basé sur elles. Après tout, une version n'est pas un projet et non une tâche, mais une sorte de conteneur d'autres tâches qui doivent être effectuées pour que la version ait lieu. Et la sortie, en particulier la première, est l'accès au marché. Jusqu'à ce que cela se produise, personne ne verra le produit et, en conséquence, il n'y aura ni retour ni argent.

Qui d'autre a oublié?

Je sens qu'il est temps d'arrêter. Si vous lisez cet endroit, vous avez beaucoup de respect. Je n'ai pas encore écrit grand-chose, mais l'essentiel, comme, se reflétait dans ce matériel.

Il y a encore un tas de techniques et de pratiques qui ont affecté la bouteille, mais je ne les énumérerai pas. Peut-être qu'un jour, je ferai quelque chose comme un glossaire ou une liste de références - pour ceux qui respectent fortement toutes sortes d'approches scientifiques, d'indices de citation et de "s'appuyer sur des méthodes de renommée mondiale".

Oui, chers auteurs des méthodes dont j'ai pris quelque chose d'utile pour la bouteille, mais que je n'ai pas mentionné dans cet article, je m'en excuse.

Quel est le résultat?

En conséquence, nous avons une bouteille - un mélange explosif de meilleures pratiques de gestion qui améliore l'efficacité. Et il existe exactement pour augmenter l'efficacité.

Ce qui est important pour moi personnellement, c'est un mélange, un ensemble, pas une séquence. Vous pouvez appliquer toutes les méthodes, vous pouvez - une seule ou la moitié de votre choix. Toute méthode, en soi, donne une augmentation de l'efficacité. Un de plus, un autre de moins.

Comme déjà mentionné dans l'article, au cours des années de pratique, j'ai essayé des parties de la bouteille dans différentes entreprises et, plus important encore, dans des types d'activité humaine complètement différents. Il y avait des programmeurs, des ingénieurs de conception et des services de qualité, et de l'approvisionnement, et des ventes, et de la production, et des comptables, et des économistes et des gestionnaires, et qui diable sait qui d'autre.

Il est clair que chaque profession a besoin de son propre ensemble de méthodes pour la bouteille et de sa propre automatisation. Mais vous pouvez choisir le bon kit pour tout le monde. Mais le plus important - la bouteille se développe et à un rythme accéléré. Parce qu'il est allé au-delà des limites de ma pratique, et a commencé à s'enrichir rapidement avec les retours des autres personnes, entreprises et professions.

Il y a même des gens qui ont tiré une ou deux idées de documents publiés et les ont mis en pratique. Ce qui est particulièrement intéressant, c'est qu'ils ne m'écrivent pas à ce sujet, mais s'ils traversent accidentellement quelque part lors d'un forum ou d'une conférence, ils parlent honnêtement de leur expérience et n'hésitent pas à dire qu'ils ont pris des idées dans la bouteille.

Donc, tout ira bien.