Comment démarrer un projet de développement lorsqu'il y a trop de parties prenantes potentielles
Je viens de prendre un nouvel emploi dans un collège en tant que développeur d'applications Web (Sole).
Le Collège dispose d'un certain nombre de systèmes hérités districats mais tous très mal codés. Principalement construit PHP Ils traitent de choses comme présence, résultats d'examen, marquage, etc.
Mon premier emploi consiste à créer un système qui intègre de nombreuses données, qui reposent actuellement dans diverses bases de données sans aucun type d'API amical pour le tirer (les systèmes existants sont codés à Vanilla PHP = sans séparation des données et de la vue) avec une nouvelle plate-forme pour enregistrer des informations pastorales sur les étudiants et la présente à des tuteurs et des cadres supérieurs de manière utile afin qu'ils puissent réagir rapidement aux élèves.
Lors de notre première réunion, il y avait 18 personnes! Il n'y avait pas de dirigeant ou de voix claire qui représentait la majorité. Non identifiable client. La réunion a balancé des idées de mise en œuvre détaillées sur des caractéristiques mineures des chefs de faculté aux arguments sur le point de savoir si nous devrions utiliser des feuilles de calcul Excel ou non pour la saisie de données!
Comme vous pouvez imaginer que ma tête tournait à la fin. En fait, j'ai eu beaucoup de bonnes idées mais je ne pouvais pas les faire entendre. C'est un très nouveau rôle pour moi, avant de faire partie d'une équipe de développement dans une agence de marketing. Nous avons eu des rôles très bien définis: gestionnaire de projet, client, concepteur, développeur.
J'aimerais savoir si des développeurs ou des gestionnaires chevronnés pouvaient me donner quelques indications sur la façon dont je peux fouiller mes collègues dans quelque chose qui ressemble à une équipe de projet. Est agile la voie à suivre? Comment approcheriez-vous la manipulation de toutes les voix disparates? Il est clair que certains processus doivent ê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 à ce qu'un "processus de développement agile" ici comme une 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 quelles sont les responsabilités des autres parties prenantes
- identifier qui est responsable de chacun des systèmes hérités
- s'il n'y a pas de client (encore) pour votre application Web, trouvez-en un qui va l'utiliser à l'avenir et demander la permission de l'intégrer en tant qu'utilisateur représentatif de votre système (une personne que vous pouvez discuter des exigences)
- s'il existe différentes parties prenantes avec des objectifs différents, collectez leurs exigences (par exemple, en les interviewant un par un, pas de 18 personnes allouées dans une pièce). Écrivez les résultats sur une liste. Ensuite, commencez à primer.
- ecrivez une feuille de route (la grande image) et une petite spécification pour la libération 0.1 et rendez votre patron ainsi que le client représentatif d'accepter officiellement
- EDIT: Voir Glenh7
Cela peut prendre un certain temps, vous n'écrirez probablement pas beaucoup de code à ce stade du projet. Dans une telle situation, vous devriez d'abord faire des "exigences en génie". Mais commencez petit, pensez 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 nombreuses politiques, quelqu'un a rassemblé cette réunion avec une liste de participants où l'adhésion a été déterminée par qui aurait le plus contrarié si je ne les invite pas. Ça arrive. Cet objectif était rempli, mais comme le développeur, vous avez constaté que rien n'a été décidé. Personne n'a été attribué quoi faire. Si vous avez de la chance, ils ont réussi à planifier la prochaine réunion ou à Dieu interdire, ils ont défini une réunion de réoccupation du 3ème mardi de chaque mois.
Ensuite, viendra la formation de comités, de sous-immobiliers 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 dans le temps pour le faire correctement. Espérons que cette personne aura un superviseur qui leur permettra de le faire et de ne pas en faire un autre élément sur leur liste déjà longue de TODO. Trouvez ces personnes dès que possible! Aidez-les à gérer les attentes de leurs patrons 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 personnes intelligentes et/ou éduquées, mais elles ne vont pas lire un tas de spécifications. Ils aimeront certaines choses, détesteront les autres et veulent plus. Cela ne fait pas mal d'écrire des suggestions, mais essayez de faire un suivi de cette partie avec une peau dans le jeu. Ne promettez pas de tout faire. Adressez simplement ce qui peut être fait dans un proche avenir.
Si vous finissez par avoir à traiter de plus de 5 personnes régulièrement, c'est parce que certains dirigeants ont fait participer plusieurs de leurs personnes qui ne veulent pas vraiment être là.
Proposez une liste d'idées que vous pensez solidifier/améliorer les systèmes existants en fonction de vos observations et de vos "besoins" et de vous assurer de vous concentrer sur l'endroit où vous pouvez obtenir des gains visibles réels. Inclure sur cette liste chaque idée que vous pensez être utile, ainsi que toute suggestion "raisonnable" autonome des non-Devs.
Construisez une liste de choses qui "devrait" être incluse dans vos efforts de développement. Donnez à chaque membre de la puissance de "vote", peut-être sous la forme de "Sticky Stars" et découvrez ce que le tout veut réellement par chaque membre placant des étoiles à côté de ce qu'ils pensent. Certaines personnes peuvent se retrouver avec plus d'étoiles s'ils sentent le chèque, ont finalement dit, etc. Après cela, vous espérez-vous, et tout le monde, verra ce qui est important pour l'ensemble, et j'espère qu'ils accepteront la priorité, ce qui sera puis traduire en feuille de route
1). Enquête à l'équipe - Découvrez ce que chaque membre considère comme une priorité importante/nécessaire/supérieure
2). Obtenez quelque chose là-bas, rapidement - N'essayez pas de résoudre tous les problèmes à la fois, obtenez la fonctionnalité "minimale minimale" et demandez-leur d'approuver, puis de l'avancez collectivement en fonction des commentaires des utilisateurs.
). Utilisez leurs commentaires et la rétroaction d'autres utilisateurs pour guider le processus de développement
(Construire, évaluer les commentaires, construire, évaluer les commentaires) rincer et répéter.
En outre, vous pourriez envisager de mettre des "points d'effort" ou des heures estimées à compléter .. Cela pourrait également aider à la priorisation.
Votre premier défi consiste à identifier le besoin 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. Les forcer à identifier vraiment les besoins/problèmes.
Une façon de le faire est de leur demander chacun individuellement de documenter ces besoins sur des notes collantes - une seule idée par collant. Puis exécutez un diagramme d'affinité pour les aider à regrouper les idées disparates en besoins spécifiques. Enfin, faites-les voter ( multi-vote ) afin que vous puissiez voir les meilleurs besoins.
Agile nous rappelle de m'attaquer à la fonctionnalité qui a la plus grande valeur client en premier. Commencez avec le besoin le plus important, puis continuez de fractionnez cet élément jusqu'à ce que vous ayez le premier petit morceau que vous pouvez réellement faire dans une courte période.
Baiser - faire un itinéraire. Merci à tout le monde d'être venu, passez l'avis, faites-le. Le suivi latéral ralentira si vous y remédiez en partageant leur préoccupation et demandez-leur de rester après la réunion. Prendre des décisions par vote où il y a une controverse pour rester le plus heureux. La motivation vers la participation à tout système est directement liée à la croyance des individus en sa méthode.