
Petite entreprise ou grande entreprise - partout où se construit le processus d'interaction avec le client. Quelque part cela se fait par un produit / projet (le souligner si nécessaire), quelque part, l'équipe est directement impliquée dans les communications. Je viens du deuxième camp. Dans cet article, je vais vous expliquer comment notre équipe a construit le processus d'interaction avec les clients sans impliquer les managers. Sous la coupe, un plan d'action sur la façon de vivre de manière organique avec un grand nombre de clients sans brûler les délais et sans oublier votre liste de souhaits.
L'équipe
L'équipe dans laquelle je travaille développe une API publique et est l'un des principaux fournisseurs de données pour 2gis.ru et partenaires commerciaux. Toute requête de recherche avec 2gis.ru passe par notre équipe - nous générons des données dans la réponse.

L'ensemble des tâches venant à l'équipe peut être conditionnellement représenté comme suit:
- Tâches indispensables pour la mise en œuvre complète de l'ensemble du département ou de l'entreprise. Cela ne peut pas être fait.
- Tâches de support produit. Si quelque chose se casse - il devrait y avoir du temps pour le réparer.
- Dette technologique. La présence de ces tâches dépend du besoin et du nombre d'autres. Malheureusement, dans la lutte des priorités, ils sont les premiers candidats à l'élimination.
- Tâches des clients. Ces tâches qui ne sont pas incluses dans les plans du service, mais qui feront du bien à un client spécifique.
Le premier et le dernier type de tâches proviennent des mêmes personnes, la principale différence réside dans les priorités et la portée de ces tâches. Si vous devez sacrifier quelque chose, ce sera le plus souvent une dette technique et des tâches de la part des clients.
Exemple: la tâche
indispensable est de
publier beta.2gis.ru , la tâche du client est d'ajouter un nouveau champ à la réponse de l'application.
La répartition des tâches était presque toujours à peu près la même que celle décrite ci-dessus, mais l'approche de travail avec le flux de ces tâches était différente de l'actuelle.
Comme avant
Nous étions une équipe qui s'est arrêtée au milieu de la transition de la mêlée au kanban. En essayant de contrôler le flux des tâches à l'aide du tableau kanban, nous n'avons pas abandonné l'ensemble mensuel de tâches que nous avions prévu de faire dans un mois - c'est-à -dire que nous avons tapé un sprint typique.
Nous avons collecté la liste complète des tâches, défini les priorités et les notes dans Google. Cela demandait beaucoup de force, de nerfs et de temps - donc, nous sommes nés le rôle d'un «plan directeur», transmis au sein de l'équipe. Une personne ayant ce rôle, en plus de ses tâches principales, vérifiait une fois par mois l'exactitude des formules de calcul des ressources, les tâches indispensables collectées, la liste de souhaits des clients et les souhaits de l'équipe. Il a tenu de longues réunions d'équipe pour évaluer ces tâches et a essayé de les ramener dans une seule liste d'œuvres, basée sur ses propres idées sur les priorités. L'approche était loin d'être idéale.
Problème 1. Les clients ne savent pas ce qui se passe avec leurs tâches.
Chaque mois, nous posions aux clients la question «Que se passera-t-il si nous ne faisons pas cette tâche?». Si le non-respect des tâches n'a pas entraîné de pertes financières pour nous, alors le plus souvent, nous avons donné à l'équipe des ressources pour ces tâches, dont le résultat sera visible pour l'utilisateur final. Comme vous vous en souvenez, il y avait 15 à 20 clients, donc certaines tâches restaient en attente depuis des années et attendaient dans les coulisses.
Les clients ne comprenaient pas combien de temps s'écoulerait à partir du moment où la tâche a frappé le tableau kanban. Lors de l'élaboration des plans, nous avons déclaré que la tâche serait achevée dans un mois. C'est possible. Si nous avons le temps. De plus, le client ne comprenait pas ce qui devait être fait, avec qui parler et comment résoudre la tâche.
Googlodok n'était pas informatif. C'était à la fois une liste de tâches pour un mois et un arriéré de tâches qui était transféré de feuille en feuille. Les tâches ont été perdues et dupliquées. Il n'était pas clair où intégrer la tâche, comment comprendre s'ils l'avaient portée au sprint mensuel ou non. Et en général, le Google Dock avait l'air répugnant.
Problème 2. Le tableau Kanban ne reflète pas la réalité
En plus des problèmes avec les clients, nous avons eu un problème avec le maintien de la pertinence de la liste des tâches à la fois sur le tableau et dans l'arriéré. Dans l'arriéré, il y avait des tâches du temps des rois, et de nouvelles tâches étaient tout simplement perdues. Seules les tâches avec des délais ou ayant la plus haute importance pour l'équipe sont transmises au tableau. Toutes les autres tâches s'accumulaient quelque part en dessous, dans les profondeurs du tableau, répétant l'arriéré et augmentant la file d'attente des tâches à faire, sans aucun espoir.
Problème 3. L'équipe ne sait pas ce qui se passe avec les tâches
À l'intérieur de l'équipe, il n'y avait pas de compréhension claire de l'origine des tâches, de la suite et de ce qui arriverait à ceux qui se trouvaient au bas du tableau kanban. Ceux qui se sont engagés à s'immerger dans les subtilités du processus ne partageaient pas les joies de la planification et tentaient de ne jamais revenir au rôle de «schéma directeur». La plupart étaient ignorants.
En général, rien n'est clair pour personne, les tâches s'accumulent, les clients sont en colère, l'équipe ne plonge pas dans le processus, car c'est compliqué, et vous devez faire quelque chose avec tout cela. De tous les problèmes, nous avons déduit une liste d'étapes qui ont résolu deux problèmes - pour le rendre transparent pour le client et pour rendre l'équipe transparente.
Rendre le client transparent
- Ils ont abandonné les tâches de battage de tous types en un seul sprint grand et complexe. Comme précédemment, un ensemble de tâches principales pour l'ensemble du département a lieu tous les quelques mois, après quoi les tâches indispensables pour la période suivante sont claires. Dans le passé, nous avons essayé de les casser et de les emballer par mois, en promettant de libérer toutes les tâches d'ici la fin du mois. Le non-respect de certaines tâches a causé au client un manque de compréhension quant à leur libération. Nous donnons maintenant une estimation du nombre d'entre eux qui seront inclus dans quelques mois, et nous les décomposons approximativement par mois. Dans ce cas, nous donnons au client une évaluation plus vague du calendrier - par exemple, cela se fera en février ou en mars - mais de tels accords conviennent aux clients. Cela leur a permis de comprendre ce que nous ferions sans faire de fausses promesses ou surcharger le sprint.
- Passé de la hiérarchisation à guglodok à la hiérarchisation à jira. La pratique s'est étendue à la dette technique, aux tâches des clients et aux tâches de support du produit. Avec cela, nous avons résolu le problème de la complexité des outils.
- Refus de prioriser les tâches non indispensables des clients. "Si vous ne pouvez pas déterminer la priorité, déplacez cette tâche vers l'outil", avons-nous pensé, et nous avons créé l'outil "carrousel client".
L'algorithme du carrousel est le suivant: une fois par semaine, en plus de l'ensemble principal des tâches indispensables, nous prenons une autre tâche du client. De qui exactement, il est déterminé par le tableau, le même que dans l'exemple ci-dessous. Et puisque l'ordre est circulaire, d'où le nom de l'instrument.
Les priorités parmi ses tâches sont fixées par le client lui-même, en choisissant dans notre carnet de commandes, qui lui est personnellement tracé. Afin de rendre le travail en retard confortable pour les clients et pour nous, nous avons fait ce qui suit:
- Archivage de toutes les tâches du backlog depuis plus d'un an. C'était très agréable, vu l'ancienneté des problèmes. Le billet le plus ancien existe depuis plus de 4 ans.
- Marqué manuellement toutes les tâches avec la balise personnelle du client afin que vous puissiez configurer des filtres rapides sur le tableau dans jira, dans lequel le client détermine la priorité parmi ses tâches. Le travail est énorme, mais le résultat en valait vraiment la peine. Le client voit une liste de toutes les tâches qu'il a jamais créées, change de priorités, sans en informer l'équipe.
- Après qu'il soit devenu pratique de travailler avec l'arriéré, nous sommes revenus aux origines du kanban et avons recommencé à compter et à nous concentrer sur les tâches de temps de cycle - le temps moyen pendant lequel une tâche passe par un tableau kanban. Ce chiffre indique maintenant au client combien de temps sa tâche atteindra la sortie et quand elle atteindra le plateau. Autrement dit, le problème de prévisibilité est résolu.
Rendre l'équipe transparente
- Mettez les choses en ordre au tableau. Tout ce qui est inutile et non pertinent, qui réside dans les tâches profondes, a été fermé, et ce qui doit être fait est mis dans l'arriéré. Le tableau kanban a de nouveau commencé à refléter le flux des tâches tel quel. L'introduction de limites sur la file d'attente avant le développement - à faire - et sur la file d'attente avant la sortie de la version - fait - a contribué à maintenir la carte à jour. Pour rappeler à l'équipe la nécessité de surveiller les restrictions, ils ont écrit un bot qui, en cas de violation des limites, écrit à ce sujet dans le chat de l'équipe. Ici, après avoir tué deux oiseaux avec une pierre, nous avons résolu les deuxième et troisième problèmes du processus passé: le tableau reflète la réalité et l'équipe comprend ce qui se passe.
- Le backlog étant un outil de planification des tâches, vous devez le tenir à jour. À la lumière de tous les changements, nous avons eu une réunion régulière, où nous examinons collectivement les tâches qui sont arrivées et posons des questions sur les termes et conditions. Un grand avantage de cette solution est que les exigences sont spécifiées / écrites avant que la tâche n'atteigne le tableau, c'est-à -dire que nous effectuons des analyses simplifiées à l'avance, sans perdre de temps pendant le développement.
Toutes les tâches qui ont réussi les questions du test de l'équipe reçoivent une note supplémentaire, ce qui leur permet de monter au tableau.
Le rôle du «schéma directeur» a évolué pour compléter le rôle de l'officier de permanence en charge de l'appui au projet au cours de la semaine. Il doit lancer des tâches sur le tableau et tenir une réunion hebdomadaire.
Il n'y a plus de peine à déterminer les priorités et à essayer de tout pousser à la fois dans un sprint bondé. Il n'y a pas beaucoup d'heures de discussions et de clarifications des exigences pour un grand nombre de tâches qui sont arrivées en un mois - avec une analyse hebdomadaire, le processus va vite et il y a peu de tâches. Les tâches sont toujours en vue et toute l'équipe dans le contexte de ce que veulent les clients.
Comment
Une fois tous les problèmes évidents résolus, il est devenu plus transparent pour tous les participants, et vous pouvez maintenant participer au processus sans perdre vos nerfs et beaucoup de temps. Bien qu'il ne s'agisse pas de la version finale du processus de planification, il y a place à amélioration partout.
Ce que je veux faire ensuite:
- Automatisez le processus d'obtention des tâches sur le tableau Kanban. Maintenant, les tâches sont prises dans l'arriéré par la personne de service, qui pendant une semaine surveille la présence des tâches au tableau. J'aimerais qu'une partie des tâches (ou, éventuellement, tous leurs types) passe automatiquement à todo, si nécessaire.
- Automatisez le processus d'interaction avec les clients et travaillez avec le carrousel. Une solution possible serait de mettre en place un bot qui rappellera au prochain client de vérifier les priorités de ses tâches.
- Automatisez les tâches d'extraction avec des délais, le cas échéant. Autrement dit, ajoutez simplement l'automatisation pour suivre ces tâches.
Avez-vous résolu l'un de ces problèmes? Partagez vos idées dans les commentaires.
Voulez-vous continuer? Rejoignez la diffusion en
direct DevDay
Manage IT de demain.