- salut!
- salut!
- Dites-moi, qu'est-ce que ça fait de faire du support technique?
- Eh bien, imaginez un vélo ... et il brûle ... et vous brûlez ... et la route brûle ... et en général, vous êtes en enfer ...

(c) l'auteur est inconnu

Peu importe qui vous êtes, un novice ou un manager expérimenté, chacun de nous a été confronté à une situation où les tâches sont nombreuses, elles proviennent de différentes sources et la fin n'est pas visible du bord. Même en tant que «coup de contrôle», quelqu'un demande de tout faire hier. Vous êtes-vous reconnu dans ce paragraphe? Ensuite, cet article vous aidera.

Je vais vous dire quels problèmes majeurs j'ai rencontrés dans mon travail quand ils m'ont juste confié la gestion du support technique, où sont passés ces problèmes et comment vivons-nous maintenant, après 3 ans. Autrement dit, comment certains trucs et principes Kanban m'ont aidé personnellement et l'équipe dans son ensemble à réduire considérablement le fardeau des spécialistes.

Quels étaient les problèmes réels?

Les plus courants pour la gestion de projet dans le domaine informatique (et pas seulement):

• Grandes listes de tâches
  
• gestionnaires de montage;
  
• un grand nombre de sources de ces tâches mêmes;
  
• non-respect des délais;
  
• ressentiment du tout.
  

Ha, qu'est-ce qui est si terrible?! Vous prenez la tâche et vous le faites - c'est toute la magie avec le lapin. Alors oui, mais il semble que "notre lièvre était défectueux".

De nouvelles tâches arrivaient chaque jour et la durée de vie des anciennes augmentait de façon exponentielle. Chez chaque spécialiste, le nombre de tâches a été mesuré en dizaines et il n'y avait pas de fin en vue.

Tous ceux qui étaient impliqués dans la chaîne ont souffert, d'un programmeur à un client qui, il nous a semblé, lavait nos larmes (en fait, je pense qu'il était encore pire que nous, et nous avons sincèrement fait tout ce qui était possible à l'époque )

Quelles solutions ont été prises

Naturellement, il était clair pour nous que cela ne pouvait plus continuer et que quelque chose devait être corrigé. Nous avons trouvé la force et avons commencé à chercher des solutions.

Ci-dessous, je vais parler brièvement de quelques-unes des options les plus «cool» et une bonne.

Plan de 7 à 14 jours avec date d'échéance finale

Oui, ils étaient idiots, mais l'expérience a été utile.

Quelle est l'essence de l'idée:

• pour chaque tâche, nous avons déterminé combien de temps cela prendra en heures-homme;
  
• une liste spécifique de tâches a été attribuée pour chaque date au cours des 2 semaines suivantes;
  
• cette liste a été établie sur la base du temps total qui devait être consacré et du temps de travail disponible (nous avons 7 heures-personnes réelles);
  
• les tâches elles-mêmes sont immédiatement confiées à des spécialistes de manière à le remplir complètement de travail pendant 7 heures.
  

Cool! Maintenant, nous avons un plan clair et nous savons quelle tâche sera accomplie quand! Le voici - le salut!

Un jour après ces mots est venu le «BP de gestion».

Un peu de paroles.
Les spécificités du support technique (au moins avec nous) avec de nombreux projets différents sont telles que vous n'avez jamais de liste définitive des tâches planifiées (backlog) pour la semaine à venir. Même un carnet de commandes de 3 jours est quelque chose d'une catégorie fantastique. À tout moment, une tâche peut voler qui doit être faite en ce moment (parfois c'est justifié, parfois non, mais ce n'est pas ça).

Et maintenant, qu'est-ce que je veux dire exactement par «enfer managérial».



La tâche nouvellement créée de la catégorie «ici et maintenant» a complètement rompu tout le plan. Non seulement vous deviez déplacer des tâches pour la journée en cours , mais vous deviez également déplacer des tâches pour les 2 semaines . C'est logique, car si cela n'est pas fait, alors le spécialiste obtiendra une liste qui dépasse 7 personnes / heures par jour, mais pour nous dans ce cas, c'était inacceptable.

Beaucoup de temps et d'efforts ont été consacrés à ces mouvements, à la fois mentaux et physiques.

De là, toute demande des managers était perçue «avec hostilité», et toute nouvelle tâche devenait un désastre.

C'est peut-être la décision la plus «cool» sur laquelle nous avons essayé de travailler.

Création d'une liste de tâches pour les spécialistes en fonction des catégories

L'Univers a expliqué en temps opportun (cela aurait pu être plus tôt) que pour des tâches arrivant constamment, il n'était pas possible de définir un temps d'exécution spécifique et de s'appuyer sur cela. Accepté, compris, abandonné.

Mais vous ne rencontrerez pas non plus la liste générale des programmeurs, les pauvres boursiers seront perdus. Pour éviter cela, nous avons mis au point un système de catégories de tâches (petites, moyennes, grandes et très grandes) et avons commencé à tout répartir en catégories.

Quelle est l'essence de l'idée:

• selon une évaluation préliminaire approximative, nous attribuons notre catégorie à la tâche - petite, moyenne, grande et très grande;
  
• chaque catégorie a son propre temps d'exécution moyen constant , quelque chose de similaire aux Story Points (ou peut-être qu'ils l'étaient);
  
• Chaque spécialiste a sa propre liste de tâches distincte basée sur une combinaison de catégories. Par exemple: 4 petits + 2 moyens; 3 petits + 1 grand; 6 petits; 1 très grand, etc.
  
• et donc pour les 3 prochains jours (le plan est nécessaire, au moins le plus tordu).
  

Vive enfin! Les gars, nous avons tout pour aller et venir ... Ici quelque part autour de Cosmos a rechargé son arme et a commencé à nous tirer dessus. Quel était le problème avec cette décision?

1. Tardivement, nous avons commencé à maintenir une base de tâches typiques pour simplifier l'affectation des catégories.
   
2. J'ai dû suivre les files d'attente de chaque spécialiste (bien que cela ait pris relativement moins de temps que de déplacer les dates de sortie plusieurs fois par jour).
   
3. Le problème des tâches urgentes à leur tour ne va nulle part - ils sont toujours obligés de reformuler les listes.
   

Cela semble être une bonne solution. Un peu mieux que la première option, mais toujours pas flexible en termes de tâches urgentes et importantes émergentes.

Technique basée sur le système d'extraction (Kanban)

Par chance, j'ai eu droit à une heure de webinaire gratuite consacrée à Agile et à certaines méthodes basées sur celui-ci (bien sûr, c'était une publicité pour les cours). Et donc, ce n'est qu'après la partie principale que quelqu'un a mentionné le Kanban comme technique bien établie pour le support technique et pas seulement.

Inspiré par les nouvelles informations, les jours de lecture sur ce miracle de la gestion ont commencé. Nous avons obtenu l'information, maintenant nous sommes prêts à expérimenter la méthodologie (actuelle) adaptée pour nous.

Quelle est l'essence de l'idée:

• les spécialistes N'ONT PAS leur propre file d'attente;
  
• toutes les tâches prêtes pour le travail sont déplacées vers une file d'attente commune;
  
• à partir de cette file d'attente, le plan actuel est formé. Un plan est une liste de tâches qui n'a pas de date d'exécution finale et qui est pertinente pour le moment, à cette seconde;
  
• les tâches relèvent du Plan actuel sur la base de ces priorités. Manager (vie de tâche, urgence, etc.);
  
• le Plan a une limite sur le nombre de tâches qu'il contient;
  
• tous les spécialistes de l'unité voient le même plan actuel;
  
• après avoir terminé la tâche en cours, le spécialiste tire la prochaine plus haute et ainsi de suite à son tour.
  

Bon! Ils sont venus avec, ils ont dit à tout le monde comment faire, on regarde. Les gars, vraiment?!

Quels ont été les résultats après 1,5 semaine civile:

1. Nous avons réduit le nombre de tâches en cours dans le seul développement de 75 à 25 !!! Et cela à condition que le flux de tâches entrant reste le même
   
2. Réduisez la quantité de négativité sur le timing
   
3. Flexibilité dans les processus
   

Et c'est exactement ce qui était immédiatement visible.

Mais comment se fait-il que tout ait plus ou moins fonctionné? Mes réflexions à ce sujet sont les suivantes:

• Les programmeurs eux-mêmes ne choisissent plus la tâche la plus compréhensible . Maintenant, le gestionnaire a géré la file d'attente et n'a mis dans le plan que les tâches les plus nécessaires pour le moment (c'est un point clé).
  
• Une telle attraction a directement influencé la réduction de la négativité de la part des gestionnaires et des clients. Pourquoi? Oui, car il n'y a pas de tâches tout aussi urgentes sur un projet et le négatif a probablement provoqué le plus de valeur pour le moment.
  
• La flexibilité et la grâce d'un chat, et parfois l'agilité des pommes de terre - le système de traction nous a permis de répondre à des tâches importantes et urgentes sans perdre ni perdre de temps à changer la file d'attente. Nous traduisons la tâche nécessaire dans le Plan et en supprimons la plus récente (rappelez-vous la restriction dans le Plan?).
  

Résumé

Si vous êtes confronté à un grand nombre de tâches, même d'une seule source, et que vous ne pensez pas que le vélo brûle plus que nous le souhaiterions, alors tournez-vous vers Kanban. Sur la base des principes de cette méthodologie, elle peut être mise en œuvre sans douleur dans les processus commerciaux actuels.

Pour le moment, nous avons adapté le système d'extraction à nos besoins, normalisé l'offre de rejets. Bien sûr, "l'encrassement" se produit également, mais après un certain temps, le système arrive à une norme relative basée sur les capacités actuelles.

Il convient également de comprendre que Kanban n'est pas seulement une méthodologie «sèche», mais aussi un système de valeurs et de principes visant à l'amélioration continue et à l'adaptation des processus actuels. Il n'y a pas de limite à la perfection, donc seulement en avant!