Il se trouve que ces derniers temps, j'ai beaucoup travaillé avec les exigences des produits du «client interne», y compris des collègues de divers départements et équipes techniques (au sein de l'entreprise). Et les gens viennent constamment me voir pour que notre équipe implémente certaines fonctionnalités, refasse quelque chose, ajoute, supprime.
Dans cet article, je veux dire comment vous pouvez travailler avec tout ce chaos entrant.
L'article est rédigé sur la base de la pratique du travail, et n'a pas l'intention de couvrir l'ensemble du sujet de la gestion de projet, les exigences, les équipes, la qualité de la mise en œuvre ultérieure des exigences par les développeurs, le sujet de l'analyse des résultats de la mise en œuvre, etc.
Mais il ne couvre qu'une petite partie étroite entre la «liste de souhaits» et la «mise en œuvre», qui concerne précisément les exigences elles-mêmes: une liste de souhaits / exigences / souhaits / problèmes arbitraires nous envahit, et nous travaillons avec eux et à la fin nous obtenons ce que adapté au développement.Découvrir le vrai problème
Quand quelqu'un arrive avec un problème, une demande, une idée de nouvelle fonctionnalité, etc. alors il ne nous apporte pas toujours ce ready-made, adapté à la mise en œuvre. En règle générale, ce ou une sorte de «cosmos» est quelque chose de très grand, assommant, irréaliste, nécessitant de tout refaire complètement pour résoudre un petit problème, dont l'urgence est inconnue. Ou tout simplement une exigence "brute", incompréhensible et non spécifique.
Par exemple, une personne suggère d'ajouter une nouvelle fonctionnalité. Et faites-le de cette façon, en offrant une sorte de mise en œuvre technique. Dans ce cas, ne sachant pas ce qui est organisé et comment cela peut être mis en œuvre. De toute évidence, on ne peut pas simplement prendre de telles exigences et les mettre en œuvre. S'ils l'avaient fait, le monde aurait plongé dans le chaos et l'obscurité des enfers il y a longtemps.
Afin de pousser un peu le chaos et l'obscurité des enfers, nous devons comprendre ce qui se cache derrière ces idées et propositions. Quel problème la personne qui est venue chez vous voulait-elle vraiment résoudre, quel problème devrait être résolu?
C'est loin d'être toujours clair et évident tout de suite. Souvent, vous devez passer au travers et poser plusieurs fois les mêmes questions. Ou des questions différentes. Jusqu'à ce que finalement, il devienne clair ce qui ne va pas dans son essence, dans son essence, et comment, dans la compréhension d'une personne, il devrait y avoir «ainsi». Et cette compréhension, en règle générale, est très différente de l'énoncé original de la tâche / du problème. Mais sans le recevoir, il est impossible de passer aux étapes suivantes et de satisfaire le besoin.
Comprendre ce dont une personne a
vraiment besoin est un art entier, auquel des paraboles entières sont dédiées (par exemple, "Vladimir Tarasov - Rapprochez-vous d'un cerf"), des livres (par exemple, "Rob Fitzpatrick - Demandez à votre mère") et des intensités pratiques (par exemple, sur le développement personnalisé).
Vieux vélo sur l'acheteur de la perceuse
Un homme vient au magasin et y achète une perceuse. Mais en fait, il n'a pas besoin de perceuse, il a besoin d'un trou dans le mur qu'il veut percer. Par conséquent, il achète une perceuse.
Mais ce n'est pas tout. Un trou n'est pas nécessaire seul. Elle est nécessaire pour accrocher une belle grande photo dans un cadre lourd. Et ce héros veut accrocher une photo pour faire plaisir à sa belle-mère, qui lui avait longtemps demandé de suspendre une photo, mais il ne l'a toujours pas fait.
Il nous semble que nous avons déjà trouvé un problème fondamental. Mais non.
En fait, dans une journée, il y aura un match de football, que notre héros veut vraiment voir. Et pour que la belle-mère n'ait aucune raison de le déranger, il s'est arrangé pour avoir le droit de regarder le football - il a fait ce qu'on lui a demandé depuis longtemps - il a accroché une photo.
Autrement dit, en achetant une perceuse, il voulait vraiment regarder calmement le football.
Ici, il convient de noter que la situation où quelqu'un arrive avec des exigences étranges, incompréhensibles, formulées de manière tordue ou, de votre point de vue, incorrectes, est
normale . Pour les gens en général, il est naturel qu'ils veuillent quelque chose, mais ils ne peuvent pas toujours exprimer exactement et correctement ce qu'ils veulent. Les gens, en règle générale, sont comme ça - c'est naturel. Autrement dit, le fait n'est pas que quelqu'un a tort, mais comment vous savez comment travailler avec une telle situation.
À ce moment particulier, travailler avec un client interne n'est pas très différent de travailler avec un client externe.
Conditions requises pour les fonctionnalités qui existent déjà
Le vélo espion.
D'une manière ou d'une autre, ils ont envoyé un espion dans une ville pour savoir où se trouve l'usine de cartouches. Ils ont donné des informations pour aider à ce qu'il y ait une église dans la ville, et si vous marchez tout droit et à gauche le long de la rue, alors quelque part dans cette direction il y aura une usine.
Voici un espion dans la ville. Il rencontre la grand-mère et demande:
- Dis-moi, comment aller à l'église?
- Mais tu vois l'usine de cartouches? De lui, allez tout droit puis à droite. Il y aura une église.
Le cas le plus simple, quand il s'avère que ce que veut une personne, nous l'avons déjà. Peut-être pas tout à fait sous la forme qu’une personne attendait, supposait, imaginait. C'est juste que la personne ne sait pas que c'est le cas, ou ne sait pas comment l'utiliser, ou qu'elle a des informations incorrectes sur la façon dont cela fonctionne. Ou vous avez juste besoin de configurer / activer quelque chose pour obtenir ce dont vous avez besoin.
Lorsque tout est si simple, il ne reste plus qu'à donner à la personne des instructions sur la façon d'obtenir le résultat dont elle a besoin en utilisant les opportunités existantes.
C'est fait.
Exigences en double
Il arrive souvent que les exigences soient similaires, elles ne diffèrent que par les nuances du cadre (potentiel) ou à peu près la même chose, mais par des mots légèrement différents. Ces exigences peuvent être combinées pour comprendre dans quelle mesure et à quels endroits la flexibilité est nécessaire (ou sera nécessaire à l'avenir) et où elle n'est pas nécessaire. Quelles sont les principales fonctionnalités? Faire un seul système ou élément de fonctionnalité une fois qui satisfera tous ces besoins à la fois. Peut-être avec des paramètres ou des variations différents, mais il ne sera pas nécessaire pour chaque besoin de faire la même chose plusieurs fois séparément.
Un exemple:
Des représentants de plusieurs services différents viennent à vous (généralement indépendamment les uns des autres et à des moments différents) et disent que l'un doit envoyer des rapports par e-mail aux clients de la liste, l'autre - des notifications à un certain cercle d'adresses que certains systèmes techniques ne sont pas travailler. Le troisième vient et souhaite, selon les résultats de tel ou tel traitement des données client, une lettre avec les résultats du traitement est envoyée au client.
Il est évident ici que dans tous les cas, un système d'envoi de lettres est nécessaire, et les tâches d'envoi proviennent de différents endroits dans différentes circonstances.
En conséquence, un certain système unifié d'envoi de lettres se dessine. Dans lequel les tâches peuvent provenir de différents systèmes. Et si tous les événements ci-dessus (avec lesquels ceux qui souhaitent nous envoyer des lettres) venaient à se dérouler dans le même système, alors encore mieux: cela signifie que le système peut être rendu encore plus uniforme et plus simple.
Si nous ne travaillons pas avec les exigences entrantes de cette manière, et qu'elles entrent immédiatement en développement sous forme brute, alors après un certain temps, nous trouverons notre système avec plusieurs expéditeurs de lettres différents, chacun travaillant selon sa propre logique, ayant sa propre implémentation spéciale, paramètres, fonctions. Et pour changer un petit morceau de logique dans les trois, ou ajouter une fonction d'un autre à l'un de ces expéditeurs, vous devez soit copier-coller le code, soit réécrire une partie assez importante et refactoriser après l'implémentation et l'opération. Bien qu'en principe, on puisse comprendre à l'avance que tout sera ainsi.
Exigences contradictoires
Il arrive que deux ou plusieurs exigences particulières se contredisent. Parfois «complètement», qui ne peut en aucun cas être combiné. Parfois, néanmoins, des «modes différents» peuvent être envisagés, dans chacun desquels une exigence est satisfaite, tandis que l'autre n'est pas disponible. Ou résoudre l'un des problèmes d'une autre manière - alors la contradiction disparaîtra.
Pour aller vers une solution, vous devez commencer à dérouler la chaîne du «pourquoi / pourquoi». Pour chacune des exigences (comme décrit dans la première partie de l'article). C'est-à-dire que nous devons comprendre aussi profondément que possible à partir de quoi exactement de telles exigences sont nées et que les personnes qui sont venues avec ces exigences veulent «vraiment».
Ensuite, nous avons l'opportunité de trouver d'autres solutions à ces «vrais problèmes», ou de comprendre comment ces exigences contradictoires peuvent être combinées.
Par exemple, si une exigence n'est en fait nécessaire que dans certaines conditions étroites spécifiques et une autre dans d'autres conditions étroites spécifiques. Il s'avère ensuite qu'ils ne se croisent pas. Ou la tâche pour laquelle une telle exigence a été inventée peut être résolue d'une manière complètement différente, peut-être encore plus simple et efficace. Et puis l'une des exigences disparaît (ou se transforme en une exigence complètement différente - qui n'a rien à voir avec la seconde), et la seconde demeure. Et il n'y a pas de contradiction.
Ou comprenez: ces exigences ne peuvent être combinées en aucune façon, et vous devez en choisir une. Mais, heureusement, c'est encore assez rare.
Tout cela est possible car presque toutes les tâches peuvent être résolues de plusieurs manières. Et si nous nous élevons de plus en plus d'une formulation initiale spécifique, brute, peut-être semi-technique, dans la compréhension de ce qu'est la tâche, en principe, alors il y a de plus en plus d'options de solution. Y compris les solutions non techniques (niveau des paramètres, processus, organisationnel, etc.). Et plus le choix d'options est large, plus il est facile de choisir deux options pour résoudre deux problèmes qui n'interfèrent pas entre eux, et même, peut-être, aider, si possible.
Exigences de la chaudière
L'idée est qu'au départ, toutes les exigences différentes de toutes les sources devraient fusionner en un seul tas, en une seule chaudière. Ensuite, vous pouvez les démonter, les analyser pour les options ci-dessus - "répétitives" ou "contradictoires", afin de donner déjà préparé: des exigences non répétitives et cohérentes qui peuvent être "prises et faites" dans le bon ordre.
Autrement dit, l'idée est de regarder l'ensemble de l'image. Pour tout ce qui existe maintenant et qu'ils veulent ajouter, changez. Et sur la base de toute cette image, il a déjà été décidé: quoi, comment et quand le faire.
Dans ce contexte, toutes les exigences entrantes sont des matières premières afin de se préparer aux tâches de développement en sortie. De plus, les tâches à la sortie ne coïncideront pas toujours individuellement avec certains besoins entrants. Une tâche peut satisfaire plusieurs besoins à la fois ou fermer une classe entière d'exigences. Ou faites simplement partie d'une grande histoire.
Résumé
C'est ainsi que le chaos entrant se transforme en un ensemble magnifique, utile et compréhensible pour les développeurs de tâches et de fonctions de votre système qui plaît à vos collègues.