Traiter des spécifications incorrectes / incomplètes / peu claires?
Je travaille sur un projet où notre équipe de développement obtient les spécifications de la partie commerciale de l'entreprise. Tant la gestion commerciale que la gestion informatique nécessitent des estimations et des projections de délais, comme il se doit.
La bonne chose est que les estimations sont principalement faites par les développeurs réels qui arrivent à faire les fonctionnalités requises. La mauvaise chose est que les spécifications sont généralement soit trop simples (il se trouve que vous vous retrouvez avec beaucoup de points d'interrogation au-dessus de votre tête parce que beaucoup d'informations semblent manquer) ou trop complexes (au point que vous pouvez ne visualise même pas où tout "rentrerait" dans l'application). Plus souvent qu'autrement, la partie métier des spécifications est soit incomplète, soit ignorante de ce qui peut et ne peut pas être fait (compte tenu de la logique métier précédemment mise en œuvre).
L'équipe de développement reçoit environ un jour par nouvelle spécification pour donner une estimation et nous essayons de lever les incertitudes, généralement en rencontrant celui qui a fait la spécification. La plupart du temps, il s'avère que les rédacteurs de spécifications n'ont pas vraiment pensé à tout, et ce n'est généralement que lorsque nous commençons à concevoir et à développer que nous nous retrouvons en difficulté, car la plupart des spécifications semblent avoir des trous.
Comment gérez-vous cela? Êtes-vous généreux sur les estimations à l'avance?
Si vous rencontrez des problèmes lors de la conception, avez-vous vraiment un problème?
Assurez-vous que ceux qui créent les spécifications ne se sentent pas obligés de tout faire à l'avance. Ils ne peuvent pas penser à tout et nous non plus. Ils doivent également savoir qu'ils ne peuvent pas simplement faire une nuit blanche sur un document de spécification et ensuite en finir avec le projet. Cette pratique les amène également à ajouter tout ce à quoi ils peuvent penser, car ils peuvent en avoir besoin et s'ils ne le demandent pas maintenant, ils l'obtiendront jamais. Ils doivent être disponibles pour examiner, tester et approuver leurs exigences à maintes reprises.
N'essayez pas de concevoir ou de créer l'application en une seule fois. Tout projet/application peut être décomposé en une sorte de phases, de parties, de modules ou comme ils veulent l'appeler. Vous n'avez pas besoin d'être agile si ce n'est pas votre truc. Commencez par la partie Sécurité de l'utilisateur et continuez à partir de là.
Prenez le temps de vous asseoir avec ces gens et de découvrir ce qu'ils veulent vraiment. J'adorerais que quelqu'un me remette des spécifications qui m'ont permis de créer tout le projet en une seule fois, mais que ferais-je pour la prochaine année et demie?
J'utilise le Cone of Uncertainty Dites d'une voix forte et éclatante
Fondamentalement, vous faites la meilleure estimation que vous puissiez donner des informations dont vous disposez.
.
À mesure que vous progressez vers l'objectif et resserrez les spécifications, vous pouvez mettre à jour votre estimation et resserrer l'incertitude.
Oui, je suis généreux sur les estimations. N'oubliez pas loi de Hofstadter
Loi de Hofstadter: Cela prend toujours plus de temps que prévu, même si vous tenez compte de la loi de Hofstadter. De Gödel, Escher, Bach: An Eternal Golden Braid.
Le processus que vous décrivez est en fait tout à fait normal. Le problème est que les types d'entreprises ont tendance à penser les choses en termes de "phase des exigences", puis de "phase de conception", etc. Lorsqu'une équipe crée un produit, vous avez vraiment besoin d'une approche itérative. Voici quelques idées que j'ai trouvées utiles:
- Définissez les principaux objectifs des modifications proposées/nouvelle application. Ce sont des affaires objectifs comme "réduire le coût du traitement des réclamations de 10%" ou "partager les études de marché de nos bureaux satellites afin que les produits répondent mieux aux besoins de nos clients". Il aide à mettre l'accent sur les exigences ouvertes sur les besoins réels.
- Faites votre Swag initial (Serious Wild-A ** Guess) pour les mauvaises exigences telles qu'elles sont écrites, mais documentez ce que vous supposez que l'implémentation sera. Il s'agit de commentaires dont les gens d'affaires (et votre client) ont besoin pour s'améliorer et réfléchir à ces choses. Ils comptent sur vous pour eux.
- Si vous avez le choix entre une estimation vraiment longue et une estimation très courte, optez toujours pour une estimation longue. Cela choquera probablement quiconque vous demande de travailler, ce qui est une bonne chose. Cela vous forcera à discuter de ce qu'ils recherchent vraiment.
N'oubliez pas que votre première estimation ne peut pas être exacte. Basez vos estimations sur des interprétations raisonnables des exigences que vous obtenez et documentez vos hypothèses/interprétations. Il y aura plus d'exigences dérivées en raison des trous que vous avez découverts. C'est normal.
Être généreux sur les estimations peut sembler agréable, mais quel problème résout-il? Cela n'améliorera pas les spécifications, cela ne facilitera pas la planification. Il dit "ça ne peut pas être bien pire que X", par opposition à dire "ça pourrait être Y". La vérité est que tu ne sais pas. Découvrez ce que vous pouvez.
Si les analystes commerciaux doivent impliquer les développeurs plus tôt, dites-le-leur. Un rapport écrit n'est pas vraiment la meilleure méthode de communication. Si vous pouvez faire appel à un développeur pour la collecte des exigences initiales et à un analyste commercial pour le développement et les tests, vos résultats seront meilleurs.
Je viens de lire le cône d'incertitude; ce sont de bonnes choses, mais il est facile de se tromper. La direction peut regarder la première image et dire: `` ok, nous avons les exigences commerciales, donc votre estimation doit être précise à 50% selon votre cône. Dîtes-moi'. Ça n'aidera pas.
Analogie avec la voiture: quelqu'un vous demande combien coûte une voiture et vous donne un document avec ses exigences. Le document indique qu'il devrait peser environ 1200 kg, avoir quatre roues et au moins deux portes, mais peut-être quatre, devrait accueillir quatre personnes et de bons phares sont très importants. La couleur doit être grise (mais le noir est-il également possible?).
Vous pouvez dire 25 000 $, et s'il s'avère plus tard, il veut un tout nouveau Range Rover, vous êtes foutu. Cela ne le rend pas plus correct, ni plus utile de dire qu'il en coûte 100 000 $. Il peut juste avoir besoin d'une Prius d'occasion (désolée, d'occasion). Si vous n'avez pas le temps de le découvrir, vous ne le saurez jamais.
La plupart du temps, il s'avère que les rédacteurs de spécifications n'ont pas vraiment pensé à tout, et ce n'est généralement que lorsque nous commençons à concevoir et à développer que nous nous retrouvons en difficulté, car la plupart des spécifications semblent avoir des trous.
L'utilisation de la plupart est incorrecte.
Il n'est pas possible pour les rédacteurs de spécifications de penser tout à travers. Période. S'ils pensaient tout à travers, ils sauraient combien de lignes de code écrire et quelles lignes de code étaient correctes.
Étant donné que la spécification doit être incorrecte, vous ne pouvez pas faire grand-chose à ce sujet.
Les se retrouvent en difficulté est le problème.
Tant la gestion commerciale que la gestion informatique nécessitent des estimations et des projections de délais, comme il se doit.
Peut-être pas. Les estimations globales et les délais ne sont pas les choses les plus utiles.
D'où le développement des méthodes Agiles.
Le point est le suivant. Toutes les estimations basées sur les spécifications doivent comporter des erreurs. Ils ne sont corrects que par chance. La moitié du temps, l'estimation est bien en deçà et la moitié du temps, l'estimation est bien au-dessus. C'est une conséquence logique de tenter de prédire l'avenir avec des informations incomplètes.
Comme cela doit arriver, vous ne devriez pas vous retrouver en difficulté lorsque vous vous trompez. Vous devez vous tromper. Et vous devez vous tromper de manière cohérente et aléatoire. Sinon, vous truquez les chiffres.
Vous devez expliquer à la direction qu'avec des spécifications vagues, le degré de confiance dans l'estimation est faible. c'est à dire que vous estimez peut varier de 30% ou 40% ou 50% ou tout ce que vous pensez. Donc, si quelque chose est estimé à 2 jours, cela représente en fait une plage de 2 à 3 jours.
Créez ensuite un registre des problèmes de projets (peut être sur un wiki ou Jira, etc.). Créez toutes vos questions comme des problèmes et demandez à l'entreprise de répondre à votre question. Tant qu'un problème n'est pas résolu, l'estimation reste incertaine. Dans la mesure du possible, demandez à un analyste commercial d'être le relais pour faciliter cela et faire de meilleures exigences. Demandez à votre équipe de test de revoir les spécifications car elles doivent créer des cas de test par rapport aux spécifications. Souvent, leur implication peut conduire à la rédaction de meilleures spécifications. Signalez quotidiennement à la direction le nombre de problèmes non résolus que vous rencontrez. Plus ce sera résolu, meilleures seront vos estimations. Présentez toujours des mesures à la direction, car les chiffres les font réfléchir objectivement et vous mettent également sur des bases solides.
. Organisez de nombreux ateliers avec des PME commerciales et essayez de les comprendre et d'expliquer à votre tour vos points de vue pour arriver à la conclusion. Ce n'est qu'après que les principaux cas d'utilisation ont été compris et que vos estimations atteignent une confiance d'environ 80% si vous passez à l'étape de la construction.
La communication aide généralement, au moins dans une organisation saine.
Ce n'est pas une solution miracle, mais ce que j'ai essayé de faire (et cela a fonctionné dans notre entreprise), c'est de convaincre les hommes d'affaires d'expliquer le problème, plutôt que de suggérer une solution tout de suite. Nos demandes de fonctionnalités commencent donc par une description du problème ou de l'objectif qu'ils souhaitent atteindre.
Ensuite, un développeur ayant une certaine connaissance du domaine essaie d'étoffer une solution, tout en consultant quelqu'un du côté des affaires. Habituellement, ce processus donne plusieurs solutions alternatives, complètes avec des estimations.
Il appartient aux entreprises à ce stade d'en choisir une en fonction du coût et du degré de complétude d'une solution. C'est aussi ainsi que vous pourriez leur vendre cette méthode, qu'ici, ils ont des options, pas seulement un certain nombre de mandays, à prendre ou à laisser. Bien sûr, il a également besoin de plus de ressources de leur côté, mais si vous rencontrez des problèmes avec les estimations et les spécifications, c'est un investissement qui en vaut la peine.
Pourquoi accepteriez-vous une spécification d'exigences incomplète, contenant des exigences contradictoires ou irréalisable? Je recommanderais que votre processus inclue un moyen pour vous d'évaluer la spécification et de la renvoyer pour corrections avant de l'accepter et de donner des estimations.
Convaincre la direction/le client qu'il vaut la peine d'investir dans de meilleures spécifications. Essayez de impliquer davantage les personnes connaissant le domaine. En fin de compte, tout le monde en profitera.
Éliminez les spécifications.
Convaincre les entreprises d'essayer Agile (ou au moins un processus Agile-ish) pour un projet.
Au lieu d'écrire des spécifications
- rencontrer les gens d'affaires pour identifier les caractéristiques
- travailler avec eux pour identifier l'ensemble minimal de fonctionnalités/fonctions qui seraient utiles (même si ce n'est que pour une version interne)
- cardez le travail
- fixer une date pour le travail (moins il y a de fonctionnalités/de travail, plus il devrait être facile d'estimer avec précision une date).
- travailler avec les entreprises pour prioriser le travail, s'assurer qu'elles ont la possibilité de changer d'avis sur la commande de carte, leur dire comment cela affecte la date
- avec chaque fonctionnalité terminée, avoir un système de travail pour les montrer et les faire signer sur chaque travail comme il est fait
- libération
- rincer
- répéter
Affichage fonctionnalités au fur et à mesure. Relâchez tôt et souvent. Soyez transparent et réactif. J'ai trouvé que cela conduirait à l'élimination des délais inutiles.
Modifier pour l'architecture
Celui qui est le leader devrait avoir une réunion de lancement pour communiquer aux développeurs ce que l'architecture devrait être. Le responsable est aussi vraiment la personne qui doit faire preuve de diligence pour s'assurer que tous les besoins sont satisfaits.
Si vous avez besoin d'étapes supplémentaires dans votre processus, ajoutez-les. Un processus est là pour faciliter la capacité de l'équipe à faire le travail. Si quelque chose ne fonctionne pas, changez-le. Ajoutez-y, supprimez-le, changez-le pour répondre à vos besoins vos. Si vous devez être particulièrement préoccupé par la sécurité, ajoutez des étapes pour cela.
N'oubliez pas, chaque fois que la spécification est modifiée pour ajouter de nouvelles fonctionnalités ou pour résoudre des questions, il est temps de revoir l'estimation. Ce n'est pas tant que notre estimation originale est mauvaise compte tenu de ce qu'on nous a dit, mais que nous ne repoussons pas et ne disons pas que nous en avons besoin lorsque plus de détails seront disponibles. Si j'étais un entrepreneur qui construisait une maison et que j'évaluais le coût en utilisant un comptoir en lamiante et un mois plus tard, le client en voulait un en granit, vous pouvez être sûr que je reverrais l'estimation des coûts avec lui. Nous laissons nos clients s'en tirer avec des exigences de mauvaise qualité, puis ne repoussons pas quand il s'avère qu'il y a beaucoup plus de choses à faire que prévu initialement.