Comment démarrer un projet de développement quand il y a trop de parties prenantes potentielles

Je viens de prendre un nouvel emploi dans un collège en tant que (seul) développeur d'applications Web.

Le collège a un certain nombre de systèmes hérités disparates mais tous assez mal codés. Principalement construits en PHP, ils traitent de choses comme la fréquentation, les résultats des examens, la notation, etc.

Mon premier travail consiste à construire un système qui incorpore une grande partie de ces données, qui repose actuellement dans diverses bases de données sans aucune sorte d'API conviviale pour les extraire (les systèmes existants sont codés en PHP vanille sans séparation des données et des vues) avec une nouvelle plate-forme pour enregistrer les informations pastorales sur les étudiants et les présenter aux tuteurs et aux cadres supérieurs de manière utile afin qu'ils puissent réagir rapidement aux problèmes avec les étudiants.

Lors de notre première rencontre, il y avait 18 personnes! Il n'y avait ni leader ni voix clairs représentant la majorité. Aucun client identifiable . La réunion est passée d'idées d'implémentation détaillées sur les fonctionnalités mineures des chefs de faculté à des arguments pour savoir si nous devrions utiliser des feuilles de calcul Excel ou non pour la saisie de données!

Comme vous pouvez l'imaginer, ma tête tournait à la fin. En fait, j'avais beaucoup de bonnes idées mais je ne pouvais pas les faire entendre. C'est un tout nouveau rôle pour moi, avant de faire partie d'une équipe de développement dans une agence marketing. Nous avions des rôles très bien définis: chef de projet, client, concepteur, développeur.

Je voudrais savoir si des développeurs ou des gestionnaires chevronnés peuvent me donner des conseils sur la façon dont je peux concocter mes collègues en quelque chose qui ressemble à une équipe de projet. L'agilité est-elle la voie à suivre? Comment aborderiez-vous la gestion de toutes les voix disparates? Il est clair qu'un processus doit être mis en place très rapidement, je ne suis tout simplement pas sûr de ce que c'est.

Je ne m'attendrais pas à un "processus de développement agile" ici comme solution à votre problème actuel. La première chose pour vous devrait être: effacer votre mission . Cela signifie:

• clarifier quelles sont vos propres responsabilités
• clarifier les responsabilités des autres parties prenantes
• identifier qui est responsable de chacun des systèmes existants
• s'il n'y a pas (encore) de client pour votre application Web, trouvez-en un qui va l'utiliser à l'avenir et demandez la permission de l'intégrer en tant qu'utilisateur représentatif de votre système (une personne avec qui vous pouvez discuter des exigences)
• s'il y a différentes parties prenantes ayant des objectifs différents, recueillez leurs besoins (par exemple, en les interrogeant une par une, pas 18 personnes au total dans une même pièce). Écrivez les résultats sur une liste. Ensuite, commencez à prioriser.
• écrivez une feuille de route (la grande image) et une petite spécification pour la version 0.1 et faites en sorte que votre patron ainsi que le client représentatif l'acceptent formellement
• EDIT: voir le commentaire de GlenH7

Cela peut prendre un certain temps, vous n'écrirez probablement pas beaucoup de code à ce stade du projet. Dans une telle situation, vous devez d'abord effectuer une "ingénierie des exigences". Mais commencez petit, voyez grand. Une fois que vous avez développé votre première version, vous aurez quelque chose à montrer, discutez à nouveau des exigences avec les parties prenantes, etc.

Séparez ceux qui veulent vraiment que ce projet fonctionne du troupeau.

En raison de beaucoup de politique, quelqu'un a organisé cette réunion avec une liste de participants où l'adhésion a été déterminée par qui serait le plus contrarié si je ne les invitais pas. Ça arrive. Cet objectif était atteint, mais en tant que développeur, vous avez constaté que rien n'avait été décidé. Personne n'a été chargé de quoi faire. Si vous êtes chanceux, ils ont réussi à planifier la prochaine réunion ou à Dieu ne plaise, ils ont fixé une réunion récurrente le 3ème mardi de chaque mois.

Viendra ensuite la formation de comités, de sous-comités et de groupes de travail. C'est betteer, mais vous les trouverez tous également sans valeur.

Enfin, vous allez découvrir qui se soucie vraiment de ce projet. Qui veut vraiment mettre le temps de bien faire les choses. Espérons que cette personne aura un superviseur qui lui laissera le temps de le faire et pas seulement d'en faire un autre élément de sa liste de tâches déjà longue. Trouvez ces personnes dès que possible! Aidez-les à gérer les attentes de leur patron et à obtenir un engagement convenu.

Obtenez quelque chose devant autant de personnes dans le groupe d'origine qui prendront même la peine de revenir. Ils peuvent tous être des gens intelligents et / ou instruits, mais ils ne liront pas un tas de spécifications. Ils aimeront certaines choses, en détesteront d'autres et en voudront plus. Cela ne fait pas de mal d'écrire des suggestions, mais essayez de faire suivre cette fête avec un peu de peau dans le jeu. Ne promets pas de tout faire. Réfléchissez simplement à ce qui peut être fait dans un proche avenir.

Si vous devez vous retrouver régulièrement avec plus de 5 personnes, c'est parce que certains managers ont fait participer plusieurs de leurs collaborateurs qui ne veulent pas vraiment être là.

Élaborez une liste d'idées qui, selon vous, consolideraient / amélioreraient les systèmes existants en fonction de vos observations et de leurs "besoins" et vous assurer de vous concentrer sur les domaines où vous pouvez réaliser des gains visibles réels. Incluez sur cette liste chaque idée que vous pensez utile, ainsi que toute suggestion "raisonnable" de la part des non-développeurs.

Construisez une liste de fonctionnalités qui "devraient" être incluses dans vos efforts de développement. Donnez à chaque membre le pouvoir de «voter», peut-être sous la forme d '«étoiles collantes» et découvrez ce que l'ensemble veut réellement en plaçant des étoiles à côté de ce qu'il pense important. Certaines personnes peuvent se retrouver avec plus d'étoiles si elles signent le chèque, ont le dernier mot, etc. puis traduire en feuille de route

1). Sondez l'équipe - Découvrez ce que chaque membre considère comme important / nécessaire / priorité absolue

2). Obtenez quelque chose rapidement , n'essayez pas de résoudre tous les problèmes en même temps, obtenez la fonctionnalité "strict minimum" et faites-les approuver, puis progressez-la collectivement en fonction des commentaires des utilisateurs.

3). Utilisez leurs commentaires et ceux des autres utilisateurs pour guider le processus de développement

(Créer, évaluer les commentaires, Créer, évaluer les commentaires) Rincer et répéter.

En outre, vous pourriez envisager de mettre des «points d'effort» ou des heures estimées à terminer. Cela pourrait également aider à établir des priorités.

Votre premier défi est d'identifier la nécessité de ce projet. Tenez une autre réunion avec tous ces gens et demandez-leur d'écrire les problèmes qui doivent être résolus. Ne les laissez pas parler des nombreuses façons dont ce projet sera la solution. Forcez-les à vraiment identifier les besoins / problèmes.

Une façon de le faire est de leur demander individuellement de documenter ces besoins sur des notes autocollantes - une idée par pense-bête. Exécutez ensuite un diagramme d'affinité pour les aider à regrouper ces idées disparates en besoins spécifiques. Enfin, faites-les voter (vote multiple ) afin que vous puissiez voir les plus grands besoins.

Agile nous rappelle d'aborder la fonctionnalité qui a le plus de valeur client. Commencez par le plus grand besoin, puis continuez à diviser cet article jusqu'à ce que vous ayez le premier petit morceau que vous puissiez réellement faire en peu de temps.

KISS - Faites un itinéraire. Merci à tous d'être venus, de l'examiner, de le faire Le suivi latéral ralentira si vous y répondez en partageant leurs préoccupations et en leur demandant de rester après la réunion. Prenez des décisions par vote là où il y a controverse pour être le plus heureux. La motivation à participer à tout système est directement liée à la croyance des individus en ses méthodes.