Alors, pourquoi n'y a-t-il pas de nouvelles productions? Où sont les victoires en compétitions? Que voulez-vous dire deux mois consécutifs et de collecte de papiers? Quelle autre créativité? Et pourquoi n'avez-vous pas le temps pour ça? Quelle autre secrétaire devriez-vous engager? Que voulez-vous dire "je pars"? Pensez-vous sérieusement que vous pouvez le gérer sans nous? Eh bien, bonne chance.
Quelque chose comme ça a été décrit par un très bon leader d'une très bonne vie de groupe de danse «sous l'aile» d'une institution d'État, quand il a expliqué pourquoi il était parti «de sous l'aile».
L'affaire s'est enfoncée dans l'âme, tk. Je faisais juste une expérience (encore une fois) pour débarrasser d'autres personnes créatives - les programmeurs - des non-core, mais "un travail si important, nécessaire et obligatoire" - être dans le temps.
Ce qui se passe si?
J'ai mené cette expérience à plusieurs reprises, dans différentes entreprises - à la fois sur des projets, sur le développement, sur des programmeurs d'usine et sur la fourniture de services de révision. Croyez-le ou non, le résultat est toujours le même.
Si les programmeurs arrêtent de se soucier des délais et résolvent simplement les problèmes, l'un après l'autre, sans aucune distraction, la productivité doublera. En conséquence, si vous réactivez le mode «rattraper le temps», le coefficient est exactement le même - deux fois, seule cette fois la productivité est divisée par lui.
Et le plus important: le programmeur n'a toujours pas atteint la date limite, pour ma vie. Et si c'est le cas, alors seulement parfois, par accident. Ou au prix d'une productivité réduite.
Tout est très simple ici. Je ne prouverai pas l'axiome qu'un programmeur ne sait jamais exactement combien de temps il faudra pour résoudre un problème - il existe de nombreux articles et livres sur ce sujet. Si vous avez travaillé en tant que programmeur, aucune preuve n'est requise. Il existe, bien sûr, des exceptions - des tâches similaires et répétitives - mais ce sont les exceptions.
La plupart de notre travail contient autant d'inconnues en constante évolution, des flashbacks constants d'anciennes tâches, des surprises de la part des sous-traitants et des mises à jour des dépendances, des erreurs de conception, etc.
Comment comptez-vous faire ce travail? Fondamentalement, il existe quatre approches: la fantaisie, la réserve, le volume et le débit.
Méthodes de "planification"
Fantasy est l'application de méthodes de planification de la production par lots au travail des programmeurs. Par exemple, Lean ou MRP. Cette approche est utilisée par tous les «gestionnaires classiques», en particulier leur caste distincte - les «gestionnaires». Il vous suffit de presser les coûts de main-d’œuvre prévus du programmeur, en ignorant tous ses cris du type «Merde, je ne sais même pas à quoi je vais faire face», et de dessiner une belle saucisse sur le diagramme de Gantt. Et redessinez tous les jours.
La réserve est constituée d'approches telles que la théorie des contraintes, quand la part d'un cheval est simplement ajoutée aux coûts de main-d'œuvre prévus, au cas où. La figure résultante est également dessinée sous forme de saucisse sur le diagramme de Gantt. Il est redessiné moins souvent, mais presque toujours.
Le volume, c'est quand ce n'est pas le délai de résolution des problèmes qui est planifié, mais la productivité. Par exemple, cette approche est utilisée dans Scrum - connaissant la vitesse approximative du travail d'une équipe (en points d'histoire), vous pouvez planifier la quantité de travail par sprint (dans le même SP). En conséquence, toutes les tâches de sprint ont la même date d'échéance.
Le débit, c'est quand il n'y a que de la vitesse. Les tâches sont alignées, le programmeur s'assoit et résout une par une. Les dates ne sont pas connues, mais elles peuvent être calculées - connaissant la vitesse et le numéro de la tâche dans la file d'attente. L'essentiel est de ne pas dérouter le programmeur lui-même avec le calcul du terme.
Avantages et inconvénients
Il ne sert à rien de discuter d'une approche fantastique - cela ne fonctionne pas. Non seulement cela - cela crée également un stress constant et sauvage et un travail de rééchelonnement idiot. Vous pouvez vivre si quelqu'un d'autre n'est pas impliqué dans la replanification, mais cela se produit rarement. Habituellement, le programmeur est juste martelé tous les jours avec des questions telles que "dites-moi la date limite", "quand finirez-vous cette tâche?" ou "tous les délais sont passés, travaillerez-vous ou non?" De manière naturelle et harmonieuse, le programmeur arrive à des réserves de temps, même s'il ne sait rien des techniques à la mode.
Les réserves de temps vous évitent les tracas, mais réduisent la productivité, en raison de l'action de la loi de Parkinson - le travail prend tout le temps qui lui est alloué. Dans certaines circonstances, cette approche convient à tout le monde - par exemple, pour les programmeurs d'usine. Certes, jusqu'à ce que le programmeur démissionne, alors, en règle générale, il se rend compte que sa vitesse de travail est inférieure aux exigences du marché.
Les délais sont respectés, car les réserves de temps peuvent représenter des milliers de pour cent des coûts réels de main-d'œuvre. Si l'entreprise ou le processus est structuré de manière à ce que l'indicateur clé atteigne précisément la date limite, la méthode de réservation de temps est très appropriée.
Les méthodes en vrac comme Scrum peuvent pratiquement doubler votre productivité car réduire l'influence de la loi de Parkinson et se concentrer sur une productivité plus ou moins réelle, pas sur les fantasmes et les réserves de temps. Cependant, un sprint est toujours une date limite, donc la loi de Parkinson continue de fonctionner, tout comme les réservations de temps et les tentatives de manipulation des points d'histoire. Les gens sont des gens - à la fois des programmeurs et des gestionnaires. Les programmeurs veulent être de bons employés. Et les managers sont tellement habitués à ne considérer les bons employés que ceux qui «respectent le délai» qu’au moins un décompte est sur leur tête. Tout cela sera simplement appelé différemment - comme "toutes les tâches de backlog doivent être effectuées dans le sprint, et il n'y a rien à faciliter ici." Et ils proposeront d'autres KPI pour cette entreprise, car l'imagination n'est pas riche.
Il n'y a pas de tels problèmes dans le flux, car il n'y a aucune raison pour eux - la planification du travail du programmeur et les tentatives, d'une manière ou d'une autre, d'estimer le calendrier du travail. Le flux protège l'essence du travail du programmeur - la créativité. Je voudrais bien sûr dire que le flow est une pure créativité, mais cela ne se produit pas. Cependant, la pureté est beaucoup plus élevée. Et la productivité est plus doublée que Scrum.
Ce qui est intéressant: la protection du programmeur, ou de tout interprète du travail, est incorporée dans l'une des méthodes ci-dessus. Mais en ce qui concerne les programmeurs, la protection est toujours oubliée.
Quelle est la base de toute méthode
Par exemple, Lean, assez curieusement, est également basé sur l'idée de flux, puisque inventé sur un tapis roulant. L'idée est d'organiser le travail aussi uniformément et harmonieusement que possible. Pour que chaque interprète de la chaîne, d'une part, ait toujours quelque chose à faire, et d'autre part, pour qu'il n'y ait pas de file d'attente devant lui. Seule la marge minimale requise. Pour un programmeur, c'est une tâche. Essayez de donner cette idée à un manager qui est un expert Lean - il ne comprendra même pas de quoi il s'agit, car J'ai ignoré la section sur la protection des artistes interprètes lorsque j'ai lu l'article de Wikipédia sur le Lean Manufacturing.
Dans la théorie des contraintes, qui concerne les réserves, la protection du lien d'exécution est généralement un postulat de base. Là où les programmeurs sont assis, ils constituent presque toujours un goulot d'étranglement. Que dit la CBT sur le goulot d'étranglement? C'est vrai - il doit être protégé. Supprimez toutes les charges de travail non essentielles (y compris la planification de votre propre travail), évitez les temps d'arrêt, ne vous collez pas le cerveau avec des questions et des réunions stupides. Organisez le flux de travail à la vitesse à laquelle le goulot d'étranglement fonctionne. Eh bien, les gestionnaires-experts en TOC, admettez-le - avez-vous réfléchi depuis longtemps à la façon de protéger les programmeurs de toutes sortes d'absurdités?
Eh bien, Scrum est une question de flux. Là, le principe «ne pas interférer avec les gens au travail» est élevé à un absolu, et s'exprime dans l'exigence d'une autonomie maximale de l'équipe pendant le sprint. Après - venez voir ce qui s'est passé, choisissez des tâches pour la prochaine course, fouillez dans la douche. Pendant le sprint, ne respirez même pas à proximité. Qui travaille dans Scrum - que dites-vous? Personne ne vous touche pendant le sprint, hein?
Total
Partout où vous crachez, partout où vous avez besoin d'un flux. Pour que le programmeur s'assoie et programme simplement. Je n'ai pas calculé les délais, je n'ai pas fantasmé sur les coûts de main-d'œuvre, je n'ai pas réorganisé cent fois les priorités, je ne suis pas allé aux réunions, je n'ai pas participé à des correspondances et des discussions idiotes.
Cependant, partout où vous crachez, il n'y a aucun flux nulle part. Quelle que soit l'approche utilisée, le manager, ou le client, ou un idiot trouvera une raison pour arracher le programmeur du flux créatif harmonieux pour le plaisir d'une absurdité incroyablement importante.
Vous pouvez toujours revenir au flux. Ou revenir. Besoin, cependant, volonté - et de revenir, et de maintenir. La démangeaison de la surveillance constante du travail du programmeur hante. Surtout ceux qui ne comprennent rien au travail d'un programmeur.