Comment gérez-vous les clients en fonction de l'évolution des exigences? [fermé]

Question

Malgré la sagesse de Steve Yegge , la plupart des développeurs sont confrontés à des exigences qui ont été recueillies auprès de clients non techniques. Parfois, il y a des chefs de projet qui traitent avec les clients et traduisent leurs exigences, d'autres non. En tout état de cause, le fait que les exigences vont changer est une fatalité.

La plupart de ce qui constitue & "les bonnes pratiques de programmation &"; mettre au point des systèmes adaptables pour pouvoir répondre aux exigences changeantes . Des principes tels que YAGNI, DRY, couplage lâche, etc. y contribuent. Les processus de développement itératifs tels que Agile tentent également de tenter de toucher une cible en mouvement, et bien sûr, le fait de tester un système permet de faire des changements infiniment plus facilement.

Néanmoins, il semble que pour beaucoup d'entre nous l'évolution des exigences ne peut pas seulement nuire à la qualité de nos logiciels , mais également anéantir notre motivation et nous donner envie de poignarder quelqu'un.

Cette question concerne la gestion du client afin de lui permettre de modifier ses exigences de la manière dont il le souhaite, tout en décourageant les modifications arbitraires ou frivoles. Comment faites-vous cela?

• Avez-vous des chefs de projet pour isoler les développeurs du client?
• Avez-vous un processus formel de gestion du changement? Changer les gestionnaires?
• Dans quelle mesure est-il difficile pour le client d'obtenir un changement lorsqu'il en a vraiment besoin?
• Inversement, est-il facile pour un client d'obtenir un changement lorsqu'il est " frivole & ";?
• Combien de détails donnez-vous au client pour expliquer le coût d'un changement?
• À quelle rapidité êtes-vous en mesure de fournir ces informations au client après avoir reçu une demande de modification?
• Quels facteurs peuvent torpiller le processus (par exemple, des PM qui ne peuvent pas dire non au client? )
• Qu'est-ce qui fonctionne pour vous?

Answer 1

Si vous recherchez le monde idéal dans lequel le client ne change jamais d’avis ou si vous obtenez la spécification idéale - vous n’êtes pas dans la bonne affaire . Cela dit, le mécanisme le plus efficace que j'ai trouvé pour gérer les attentes des clients et les demandes de changement consiste à mettre en place un système de mesure précis.

Voici comment je dirige mon équipe:

1) Nous commençons par les user stories. Le client est impliqué dans leur rédaction et l'équipe de développement estime la durée relative de chaque user story.

2) En utilisant l'expérience antérieure, je prends ces estimations relatives (points d'histoire) et crée un calendrier approximatif indiquant le moment où les principales étapes du projet seront terminées.

3) Dans ces jalons, nous exécutons des itérations de 2 semaines. Le client participe à la définition des critères d'approbation et détermine si l'article a été approuvé ou non. Un simple graphique de réduction indique au client à quel point nous sommes sur le point d'atteindre l'objectif de lancement.

4) Souvent, lors des sessions d’approbation, le client demande une modification car la fonctionnalité n’a pas fonctionné comme il l’espérait (même si elle répondait à ses critères d’approbation initiaux). À ce stade, vous générez une nouvelle histoire avec une nouvelle estimation. Vous pouvez également ajuster vos dates jalons de manière appropriée. Cela remet ensuite la balle dans le camp des clients:

• Souvent, ils se rendent compte que leur demande de changement n'en vaut pas la peine (ils doivent obtenir l'approbation de leur patron) et nous allons tuer la nouvelle fonctionnalité
• Parfois, il est important que nous retardions la date d'échéance pour que la fonctionnalité soit disponible dans
• Enfin, il existe toujours la possibilité de supprimer une autre fonctionnalité moins importante qui prendra un temps équivalent.

L'important n'est pas de fuir les demandes de changement, mais bien d'établir que chaque demande de changement a des conséquences sur le produit. Il n’existe pas de repas gratuit.

Answer 2

Je travaille en tant que développeur indépendant et contacte donc directement les clients. Il est normal que la plupart du temps, ils n'aient aucune idée de ce qu'ils veulent réellement. Nous commençons donc lentement et je leur donne très tôt le prototype avec lequel jouer, puis les modifications seront apportées progressivement. Si je pense que les clients veulent & Quot; frivole & Quot; change alors je lui dis que ce changement ne fonctionne pas ou n'est pas nécessaire. Si cela fait 5 minutes de travail, je pourrais même le faire quand même.

Il est utile d’ajouter ultérieurement au contrat une clause de maintien afin d’obtenir de l’argent pour les modifications mineures à venir. Pour des modifications plus importantes, vous ne faites que facturer à l'heure.

Answer 3

Il est difficile de gérer le client et il est très facile de se tromper.

Je pense que vous devez gagner la confiance du client le plus tôt possible. Pour moi, je pense que vous pouvez le faire en:

• Demandez au client de nommer un responsable produit - qui réfléchit suffisamment pour pouvoir communiquer les exigences souhaitées et cherche à établir une relation de travail solide avec lui / elle.
• Essayez vraiment de comprendre leur entreprise - vous n'avez pas besoin d'être un expert du domaine, mais vous devez savoir d'où vient le client.
• Posez des questions pertinentes sur ce qu'ils veulent - ne supposez pas ce qu'ils demandent (au début), c'est ce qu'ils veulent vraiment .
• Au début, accueillez tous les changements . Ce n'est pas que le client soit ennuyeux et instable, c'est une opportunité de mieux comprendre ce que le client veut vraiment. Si cela vous coûte du temps et de l’argent, vous devrez peut-être l’accepter comme responsable des pertes .
• Fournissez un prototype à l'avance et intégrez le plus possible les commentaires des clients.
• Donnez au client un produit qui tue .

Une fois que vous avez fait cela et que le client vous fait confiance, vous serez alors en mesure de commencer à annuler des modifications déraisonnables ou à demander des paiements / temps supplémentaires pour des éléments précédemment considérés comme hors de portée.

Bien sûr, vous ne pourrez pas créer ce type de relation avec chaque client, certains sont des idiots (dans ce cas, voyez si vous pouvez nommer un autre chef de produit), mais vous devriez faites toujours autant que vous pour établir une relation de travail efficace.

Answer 4

Vous ne pouvez & # 8217; ne vous attendez pas à ce que les clients sachent ce qu'ils veulent au début, vous devez donc être adaptable. Mais vous devez également arrêter le changement pour des raisons de changement.

Ceci est pour & # 8216; interne & # 8217; clients.

J’ai constaté que la négociation avec le client est un moyen efficace. Ils peuvent avoir n'importe quelle fonctionnalité voulue s'ils l'attendent ou s'ils sacrifient certaines autres fonctionnalités (à implémenter). Cela les oblige à réfléchir à la valeur du changement qu'ils demandent par rapport au système dans son ensemble.

Parfois, cela fonctionne bien et un bon compromis est atteint. D'autres fois, le client jette ses jouets hors du landau et continue d'afficher une fonctionnalité aussi élevée que possible, ce qui réduit la qualité.

Si le client paie, c'est un jeu de balle différent. Ils doivent être informés que les coûts de modification et les coûts augmentent à mesure que le produit est presque terminé. Cela signifie que vous devez faire beaucoup d'analyse dès le départ sur ce que vous allez livrer et vous assurer que les spécifications sont convenues. Vous pouvez alors mesurer ce qui a changé. Ce n'est peut-être pas la solution la plus efficace pour les deux parties, mais cela permet de garder les choses sereines. Ainsi, ils ne sont pas mécontents et vous & N ° 8217; ne finissez pas par faire beaucoup de travail gratuitement.

Answer 5

En génie logiciel, le changement n’est qu’un fait. Cela va arriver. Pour nous, tout a un prix. Nous apporterons à peu près tous les changements souhaités par les clients, mais il existe toujours une estimation du temps et un coût qui y sont associés. Devons-nous jamais dire au client non - pas normalement, mais parfois, la demande de modification a un coût très élevé. Nous tracons la ligne en cas de menaces potentielles pour la sécurité, etc., auquel cas nous leur expliquons calmement que nous ne pouvons pas répondre à la demande.

Combien expliquons-nous au client, nous expliquons où l’argent va être alloué, que ce soit pour le développement, pour l’analyse, etc. Nous ne leur expliquons pas explicitement pourquoi quelque chose coûte si cher. Maintenant, je dois admettre que cela varie un peu avec certains de nos clients. Certains d’entre eux reçoivent une facturation très détaillée indiquant exactement combien d’heures sont passées où. Pour obtenir le contrat, nous avons dû l'accepter, bien que cela soit très rare pour nous.

Nous avons des vendeurs qui ne peuvent parfois pas dire non, ce qui peut poser problème. Nous avons passé beaucoup de temps à travailler là-dessus, mais malheureusement, cela continue. Nous combattons cela en expliquant combien ils nous ont coûté en citant quelque chose sans chercher ce que cela prendrait. La transparence est la clé à tous les niveaux. Tout le monde doit savoir comment leurs décisions affectent les résultats.

Faisons-nous des changements frivoles? Oui. Ce qu'il ne faut pas oublier, c'est que lorsque vous facturez toutes les heures, la plupart du temps, une modification de 5 minutes est facturée à l'heure complète, ce qui est donc très lucratif. Nous expliquons tout cela auparavant, comme nous le faisons pour toute demande de changement, afin qu'ils en soient conscients, mais cela tend à décourager un tel comportement, à moins que ce soit vraiment important. Le fait est que nous traitons tous les changements de la même manière. Nous ne supposons pas que nous savons ce qui est considéré comme frivole pour eux, aussi absurde que nous le pensions. Nous avons un processus de changement formel dans lequel le client demande quelque chose que nous écrivons et le fait signer. C’est ce que nous évaluons et présentons une estimation du coût du travail. Ils conviennent soit dans quel cas ils signent officiellement un document nous laissant savoir qu'il est possible de commencer, soit ils annulent la demande. Nous essayons de faire preuve de diligence, mais nous leur faisons savoir qu'il nous faudra quelques jours pour obtenir une réponse à leur demande.

Un de mes collègues m'a donné le meilleur conseil que j'ai jamais entendu sur la gestion des navires de relation client. C'est un compromis. Pour rendre le client heureux, vous devez être prêt à les aider quand ils ont besoin de quelque chose, mais en même temps, vous devez pouvoir dire non. Lorsqu'ils traitent avec des personnes, ils veulent que vous les aidiez, mais ils veulent également que vous ayez une colonne vertébrale et que vous vous défendiez. Cela devient une situation gagnant-gagnant de cette façon.

Answer 6

Je & # 8217; Je préférerais un terme d'exigences évolutives à & # 8220; exigences changeantes & # 8221 ;. Professeur MMLehman ( http://www.doc.ic.ac.uk/~mml / et http://en.wikipedia.org/wiki/Meir_Manny_Lehman ) a apporté une contribution considérable à la recherche sur l'évolution des logiciels; ses travaux suggèrent également que tous les types d'exigences n'évoluent pas. On peut se considérer chanceux s’ils travaillent sur l’un de ces systèmes, où les exigences restent les mêmes (bibliothèques de mathématiques, etc.).

L’expérience montre que les développeurs préfèrent le plus d’informations possibles sur les exigences requises à l’avance, tandis que les clients ou les utilisateurs finaux apprécient la possibilité de spécifier ou d’ajuster les exigences le plus tard possible dans le processus de développement. Les premiers ont besoin d'informations détaillées pour aider à la planification et à la conception de la solution, les seconds peuvent acquérir un avantage stratégique en modifiant tardivement une exigence, car ils offrent une marge de manœuvre au client pour répondre à l'évolution de l'environnement ou aux informations obtenues suite au premières étapes / itérations du projet. Un compromis entre la possibilité d’avoir un plan détaillé et de changer les choses détermine en grande partie le processus de développement lui-même (cascade, agile, spirale, etc.).

Quelques conseils pratiques pour gérer l’évolution des besoins:

• Créez un espace dans le plan initial pour tenir compte de l'évolution des besoins, des points de contrôle multiples ou des itérations.

• Intégrez des exigences volatiles au début du projet afin qu'une sorte d'étude de prototypage ou de faisabilité soit susceptible de les clarifier ou planifiez le changement ultérieurement dans le projet.

• Vérifiez que les exigences sont toujours pertinentes.

• Ayez à portée de la main une liste à jour des exigences actuelles, classées par ordre de priorité. Rien d’autre ne permet de garder le contrôle de l’évolution en tant que bonne visibilité pour tous les acteurs de la & # 8220 actuelle; doit avoir le & # 8221; y compris leur priorité relative et leur coût.

• Continuez à gérer les attentes des clients quant à la durée des choses; cela aide également à rester concentré.

• Introduisez un processus formel pour modifier ou ajouter des exigences si vous en avez besoin. La description du processus doit spécifier les rôles des personnes impliquées, la fréquence des examens, etc. Elle pourrait constituer une bonne protection contre certaines exigences politiques très opportunistes mais non essentielles.

• Prévoyez du temps pour le refactoring, même pour la première version. Vous & # 8217; êtes très susceptible de jeter tout ou partie de la solution à la suite de l’acquisition de connaissances supplémentaires au cours du développement.

Answer 7

Le client vient à vous pour faire quelque chose parce qu'il n'a pas le temps de le faire ou ne sait pas quoi faire (et veut vous payer pour le faire pour lui) Si vos exigences changent, c'est à cause de ces dernières. En d'autres termes, ils vous paient pour comprendre les détails! Et ils savent ce qu’ils aiment et n’aiment pas, mais ils ne savent pas comment cela fonctionne.

Reconnaissez-le et quelle que soit la solution à adopter.