Comment gérez-vous les demandes de fonctionnalités et les modifications logicielles? [fermé]

Je suis ingénieur logiciel et au cours des dernières années, je suis devenu de facto chef de projet logiciel simplement parce qu'il n'y en a pas. Donc, pour garder notre raison au sein du département R & D / Engineering, les clients ont pris l'habitude de venir me voir avec leurs demandes. Je n'ai aucune expérience dans ce domaine, c'est donc ma première fois en tant que chef de projet pour des projets logiciels. J'ai réussi d'autres choses mais pas de logiciel.

Alors, comment gérez-vous les projets logiciels et marquez les priorités? Les demandes arrivent à intervalles peu fréquents, donc nous pourrions très bien travailler sur quelque chose pour quelqu'un d'autre, puis une autre personne arrive avec un travail "précipité" sur lequel il faut travailler. Est-il plus facile de dire simplement premier arrivé, premier servi ou est-ce la personne qui a le plus d'argent?

J'ai constaté que plus un client se plaint de l'urgence de sa demande, à moins qu'il ne soit également un développeur à part entière, c'est généralement un bon signe que la demande n'est pas urgente du tout. Un de mes professeurs de collège nous disait toujours de ne pas laisser l'urgence interrompre l'important.

Je classe généralement les demandes dans cet ordre (YMMV):

1. Problèmes liés à une récente mise à niveau ou migration (le plus important).
2. Correctifs de sécurité.
3. Fonctionnalité cassée du système existant.
4. Fonctionnalité cassée dans les fonctionnalités RC et bêta.
5. Demandes de fonctionnalités payantes.
6. Demandes de fonctionnalités de R&D provenant d'une grande partie de la base d'utilisateurs.
7. Demandes de fonctionnalités R&D d'un ou deux utilisateurs seulement.

Cette dernière demande en fait beaucoup plus de temps car ce sont généralement des demandes "urgentes, j'en ai besoin hier". En réalité, l'utilisateur a rarement réfléchi complètement à ce dont il a réellement besoin ou à la façon dont il soutiendra son modèle commercial. Le plus souvent, ces demandes urgentes, une fois délivrées, finissent par être utilisées une ou deux fois et oubliées. Et une fois oubliés, ils deviennent un mal de tête sans fin de failles de sécurité et de conséquences inattendues.

J'aime les principes de:

1. QI - Important et urgent
2. QII - Important mais pas urgent
3. QIII - Pas important mais urgent
4. QIV - Pas important et pas urgent

1. Configurez un système de suivi des fonctionnalités / bogues / demandes et demandez à vos clients / collègues de déposer des tickets. S'ils ne déposent pas de ticket pour cela, vous ne le faites pas. Les billets doivent être suffisamment détaillés pour être utilisables et doivent spécifier une «urgence» («J'en ai besoin maintenant» vs «agréable à avoir»).
2. Parcourez les nouveaux tickets et étudiez -les soigneusement . Entrez le coût dans le ticket en dollars, développeurs, ressources et / ou temps. C'est essentiel . Lorsque vos clients verront ce que quelque chose leur coûtera réellement , vous verrez des choix très différents dans le champ "urgence".
3. Au quotidien, déterminez votre emploi du temps en fonction des tickets déposés et de leur urgence. Rendez le calendrier visible pour les autres afin qu'il soit évident de ce que vous faites et de votre disponibilité pour les demandes futures.

J'ai vu des projets où les changements d'exigences sont gérés par un système de contrôle des changements très lourd. C'est mauvais. De nombreux changements importants ne se produisent pas parce que le client ne veut pas passer par les tracas de soumettre un contrôle des modifications, de sorte que le logiciel ne correspond pas à ses besoins. Quelques petits changements sont glissés "sous le radar" pour éviter le processus, donc le logiciel ne correspond même pas à ce que vous pensez qu'il fait.

Inversement, j'ai également vu des projets où le chef de projet pense que "réactif" signifie obliger les codeurs à répondre à chaque demande des utilisateurs, ce qui signifie simplement que vous n'obtenez aucun développement de base et que votre code devient un gros fouillis lourd de hack au sommet pirater. Essentiellement, vous n'avez plus de développeurs, vous avez une équipe d'ingénieurs commerciaux surqualifiés.

On peut donc espérer qu'il y a une situation entre ces deux pôles qui fonctionne bien, et je m'attends à ce que ce qui fonctionne le mieux pour vous soit à la fois un choix personnel et situé. Il est certainement utile de saisir le coût de chaque changement. Dans un cadre comme Scrum, vous pouvez exprimer le coût en points d'histoire, et l'équipe peut échanger le travail qu'elle fait à chaque itération contre l'effort total disponible. Si vous avez un chef de produit, vous pouvez demander à cette personne de quantifier l'avantage attendu d'une modification ou d'une demande de fonctionnalité. Cela se fait généralement en termes de revenus protégés (combien de clients partiraient si vous ne le faisiez pas) et de revenus attirés (combien de clients arriveront si vous le faites). Cela peut aider à établir des priorités, mais peut également refléter le parti pris ou les préférences personnelles du chef de produit.

Voici quelques réflexions ...

Il existe de nombreux logiciels sur le marché qui vous aident, http://www.fogcreek.com/ avec Fogbugz, GeneXus USA avec XPM http://www.genexususa.com/xpm , etc.

C'est comme un art d'équilibrer les nouvelles demandes de fonctionnalités avec des corrections de bugs et avec vos propres idées. Vous devez vous procurer de la nourriture pour l'hiver prochain, mais vous devez aussi manger aujourd'hui.

Vous avez du temps, des ressources et de la portée, tirez-en le meilleur parti.

Henry Ford a également déclaré: «Si j'avais écouté les clients, je leur aurais donné un cheval plus rapide» ...

Personnellement: soyez dynamique, ne mettez pas de règles comme celles que vous avez dites ... et faites attention aux règles des autres ... elles peuvent bien fonctionner dans leur contexte, mais pas dans le vôtre.

Ce que nous avons fini par proposer, c'est que nous aurions désormais des réunions bimensuelles de vente / d'ingénierie pour discuter des projets en cours et des demandes de fonctionnalités à venir ou à venir. Les ingénieurs commerciaux deviendront chefs de projet et au moins ils seront en phase avec les dernières offres de produits. Dans le passé, il était facile de le transmettre à l'ingénierie et de l'oublier. Cela réduira probablement la charge qu'un ingénieur logiciel doit faire et incitera les ventes et la gestion à utiliser notre temps à bon escient.

La société pour laquelle je travaille utilise deux applications principales, un outil Web appelé JIRA pour gérer les aspects liés au projet et notre système d'assistance pour gérer la demande de changement via sa fonctionnalité rfc

Les réponses que je vois jusqu'à présent sont bonnes. Une chose que j'expliquerai spécifiquement, c'est que vous devrez être bon pour dire «non» à certaines demandes.

Si vous autorisez le client à définir l'urgence, elle sera presque toujours «Élevée» (ou supérieure).

Vous (vous-même ou une équipe, selon votre configuration) devrez évaluer ces demandes et les hiérarchiser en fonction de vos propres critères.