Les exigences vont grandir et changer. Je ne pense pas que quiconque puisse contester cela.
Comment collecter et traiter les demandes entrantes .
D'après mon expérience, cela aide lors de la collecte des exigences s'il existe un seul ou très petit groupe de clients agissant comme un filtre pour fournir des exigences nouvelles ou mises à jour à un petit groupe de planificateurs de développement. N'importe qui de leur côté peut les proposer ou les rédiger, mais la livraison ne doit se faire que par un très petit nombre. Moins il y a de personnes impliquées dans l'échange d'une partie à l'autre, mieux c'est.
Le filtrage à travers un plus petit groupe de personnes n'a pas pour but de rejeter ou de diminuer l'effort et les informations que d'autres mettent, même s'ils sont en double ou apparemment sans importance à la surface, mais de limiter les points de défaillance: informations perdues ou mal gérées. Il suit un principe similaire à celui de l'encapsulation et des interfaces: protéger les données privées et établir un protocole commun pour traiter les demandes similaires. Permettez-moi de répéter: la soumission de doublons est acceptable. En tant que planificateur, cela me dit que ce dont ils parlent ou proposent est important. Enregistrez ou enregistrez tout.
Comment suivre et organiser les exigences
A court terme, passez à la low tech
De toute évidence, il existe des solutions à faible technologie qui peuvent être efficaces dans une large mesure pour organiser et suivre les besoins entrants: tableaux blancs, adhésifs, affiches, etc. Ceux-ci peuvent être parfaits pour la planification à court terme. Ils sont très visibles, acceptent la notation de forme libre et sont faciles à «reconfigurer».
À long terme, utilisez un outil logiciel consultable, triable et pouvant être lié
Pour des efforts à plus longue portée, une sorte de logiciel serait utile. Il existe des outils spécialisés de gestion des exigences: Portes, Clearcase / Clearquest et bien d'autres. Ces outils hautement spécialisés sont excellents dans ce qu'ils font, mais sont souvent excessifs. Parfois, même un simple vieux tableur est plus que suffisant. Personnellement, je trouve les systèmes de suivi des problèmes généraux assez utiles pour y parvenir, et en ce moment mon préféré est Redmine, mais d'autres, j'en suis sûr, iraient bien aussi.
Avec un système de suivi des problèmes, toute personne que vous choisissez d'autoriser peut créer un `` nouveau problème '' ou une exigence, et ajouter tout détail qu'elle juge opportun d'inclure. Ils peuvent regarder le problème et donner leur avis sur toutes les actions que vous entreprenez. Vous pouvez le reclasser, ajuster la priorité, réécrire le corps, joindre des informations supplémentaires, l'associer à d'autres `` problèmes '', promouvoir à un niveau supérieur ou un `` cas d'utilisation '' ou une histoire ou la terminologie qui convient à votre système, ad nauseum. En d'autres termes, vous pouvez faire beaucoup pour créer une liste d'exigences liées, traçables, triables, hiérarchisées et liées à l'historique via des problèmes. De plus, étant assez configurable prêt à l'emploi et open source, si l'outil n'est pas tout à fait ce dont j'ai besoin ou que je veux à tout moment, je peux le changer assez facilement pour mieux répondre aux besoins de mon processus.
Une dernière remarque sur les outils, certaines personnes avec qui j'ai parlé ont beaucoup de succès à utiliser des fichiers de texte ancien dans un système de gestion des modifications et de gestion des versions. Ils bénéficient évidemment des avantages des versions historiques. Ils utilisent également le système d'exploitation de base et des outils supplémentaires pour rechercher, lier et cataloguer les exigences. Ils ne sont pas en mesure d'ajouter autant de méta-informations structurées et connexes, mais ils ne pensent pas en avoir besoin, et pour leurs efforts n'ajoute pas suffisamment de valeur. Cela peut ou non être le cas pour vous. L'avantage est qu'il y a potentiellement un peu moins de logiciels sur votre pile de développement à gérer et à maintenir.
Exigences d'attribution du contrat après l'attribution du contrat / de développement du projet
Le dernier aspect de la question est de savoir comment gérer les exigences après le début d'un effort. Je pense qu'il y a deux réflexions principales à ce sujet, et une partie de la façon dont vous les gérez dépend de la nature de votre relation avec le client: premièrement, si sous contrat à valeur fixe, les exigences qui surviennent après l'attribution du contrat peuvent être incorporées. L'implication est qu'ils peuvent changer la portée de l'effort, donc le taux ou la facture seront plus élevés lorsque ces articles supplémentaires seront livrés et acceptés; à moins qu'un effort équivalent ne soit supprimé de la proposition acceptée. S'il s'agit d'un changement de portée, vous devez vous assurer que le client comprend et accepte la conséquence, sinon, ces soumissions tardives devront être déposées.
Deuxièmement, pour les nouvelles exigences à venir après l'attribution du contrat, et le contrat est davantage orienté vers un temps et un effort matériel (tout ce qu'il faut pour terminer le travail), vous pouvez et devez être un peu plus flexible si le le client insiste pour l'inclure lors de cette opération. Vous serez payé, que vous l'incluiez ou non, tant que tout ce que vous dites que vous ferez sera fait.
Si vous ne les connaissez pas, vous pouvez envisager une approche Kanban et des méthodes Agiles. Ces techniques peuvent aider à se concentrer sur les préoccupations immédiates, sans nécessairement perdre de vue les objectifs de développement à plus long terme.
Présentez les options comme des scénarios de simulation et donnez au client le choix et la décision
Dans les deux cas, une estimation par simulation est une bonne stratégie à utiliser lors de la négociation avec le client et votre équipe. Construisez une comparaison côte à côte des tâches, de leurs coûts et du calendrier comme prévu, avec une colonne montrant les mêmes informations pour les approches alternatives. Microsoft Project est probablement un bon candidat pour cela, car vous pouvez construire différentes estimations basées sur un ensemble de tâches largement similaires.
Cependant, même une feuille de calcul de base est souvent tout aussi efficace pour démontrer comment des changements ou des inclusions spécifiques pourraient affecter le coût et le calendrier. Dans ce cas, une liste est probablement aussi efficace qu'un arbre pour démontrer les différences. L'outil et la méthode que vous choisissez pour construire ces scénarios dépendent en grande partie de la taille du projet et du personnel (mais même un logiciel triple A comme MS Project a ses propres limites d'utilité et de capacité).
Considérez ces scénarios comme des éléments de travail internes et enregistrez-les pour la durée du projet. Ils ont été des manifestations critiques du processus de prise de décision et de négociation. Vous devrez peut-être également les revoir, ou les répéter pour une série successive de ce qui se passe.
Lors de la préparation de scénarios hypothétiques, une explication supplémentaire des avantages et des inconvénients d'un point de vue technique ou de mise en œuvre (en termes simplifiés) pourrait être utile pour aider à justifier pourquoi une alternative aurait un impact si important.