it-swarm-fr.com

Comment gérez-vous les demandes de fonctionnalités et les changements de logiciels?

Je suis un ingénieur logiciel et, au cours des dernières années, je suis devenu le gestionnaire de projet de logiciel de facto simplement parce qu'il n'y en a pas. Donc, pour garder notre santé mentale dans le département R & D/Ingénierie, les clients sont devenus habitués à venir à moi avec leurs demandes. Je n'ai aucune expérience dans ce domaine, c'est donc ma première fois d'agir en tant que gestionnaire de projet pour les projets logiciels. J'ai géré d'autres choses mais pas des logiciels.

Alors, comment gérez-vous des projets logiciels et marquez-vous des priorités? Les demandes arrivent à des intervalles peu fréquents afin que nous puissions très bien travailler sur quelque chose pour quelqu'un d'autre, puis une autre personne entre une tâche "précipitée" qui a besoin de travailler. Est-il plus facile de simplement dire d'abord venir, d'abord servir ou est-ce la personne avec le plus d'argent?

21
Brian

Ce que nous avons terminé à venir, nous aurions-nous désormais des réunions bimensuelles de vente/d'ingénierie pour discuter des projets actuels et des demandes de fonctionnalités futures ou futures. Les ingénieurs des ventes deviendront des gestionnaires de projets et au moins elles seront en phase avec les dernières offres de produits. Dans le passé, c'était juste facile de le transmettre à l'ingénierie et à l'oublier. Cela diminuera probablement la charge d'un ingénieur logiciel doit faire et mettre les ONUS sur les ventes et la gestion pour utiliser notre temps judicieusement.

2
Brian

J'ai constaté que plus un client se plaint à quel point leur demande est urgente, à moins qu'elles soient également développées à part entière, c'est généralement un bon signe que la demande n'est pas du tout urgente. Un de mes professeurs au collège nous disait toujours à ne pas laisser l'urgence d'interrompre l'importance.

Je classer habituellement des demandes dans cet ordre (YMMV):

  1. Questions liées à une mise à niveau ou à une migration récente (la plus importante).
  2. Fixes de sécurité.
  3. Fonctionnalité cassée du système existant.
  4. Fonctionnalité cassée dans les caractéristiques RC et BETA.
  5. Demandes de fonctionnalité payées.
  6. Fonction R & D Demandes d'une grande partie de la base d'utilisateurs.
  7. Fonction R & D Demandes d'un ou deux utilisateurs seulement.

Ce dernier prend beaucoup plus de temps parce qu'ils ont tendance à être ceux "urgents, j'en ai besoin hier" Demandes. En réalité, l'utilisateur a rarement pensé complètement à travers ce qu'ils ont réellement besoin ou comment il appuiera leur modèle d'entreprise. Le plus souvent, ces demandes urgentes, une fois livrées, finissent par être utilisées une ou deux fois et sont oubliés. Et une fois oublié, ils deviennent un mal de tête sans fin des trous de sécurité et des conséquences inattendues.

21
Michael J. Sabal

J'apprécie CoveyPrincipes de's:

  1. Qi - Important et urgent
  2. QII - Important mais pas urgent
  3. QIII - Pas important mais urgent
  4. QIV - pas important et pas urgent
12
Adamizer
  1. Configurez une fonctionnalité/un système de suivi des bogues/Demande et des tickets de fichiers de vos clients/collègues. S'ils ne déposent pas de billet pour cela, vous ne le faites pas. Les billets doivent être suffisamment détaillé pour être opérationnelle et spécifier une "urgence" ("J'en ai besoin maintenant" vs "bien d'avoir").
  2. Parcourez de nouveaux billets et soigneusement les étendre. Entrez le coût dans le billet en dollars, développeurs, ressources et/ou fois. Ceci est essentiel. Lorsque vos clients voient ce que quelque chose va vraiment leur coûte, vous verrez des choix très différents dans le champ "Urgence".
  3. Sur une base quotidienne, déterminez votre horaire basé sur les billets déposés et leur urgence. Faites de l'horaire visible pour les autres afin qu'il soit évident ce que vous faites et votre disponibilité pour les demandes futures.
6
Yevgeniy Brikman

J'ai vu des projets dans lesquels des modifications requises sont gérées par un système de contrôle des changements très lourds. C'est mauvais. De nombreux changements importants ne se produisent pas car le client ne veut pas passer par le problème de la soumission d'un contrôle de changement, le logiciel ne correspond pas à leurs besoins. Certains petits changements sont glissés dans "sous le radar" pour éviter le processus, le logiciel ne correspond même même pas à ce que vous pensez.

Inversement, j'ai également vu des projets dans lesquels le chef de projet pense que "réactif" signifie que les codeurs répondent à chaque demande des utilisateurs, ce qui signifie simplement que vous n'avez jamais eu de développement de base effectué et que votre code devient un gros gâchis de hack au sommet. pirater. Essentiellement, vous n'avez maintenant aucun développeur, vous avez une équipe d'ingénieurs de vente surqualifiés.

Donc, on pourrait 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 mieux pour vous est à la fois un choix personnel et situé. Il y a vraiment de la valeur pour capturer le coût de chaque changement. Dans un cadre tel que Scrum, vous pouvez exprimer le coût des points de l'histoire et que l'équipe peut échanger des travaux qu'ils font dans chaque itération par rapport à l'effort total disponible. Si vous avez un responsable de produit, vous pouvez obtenir cette personne pour quantifier l'avantage attendu d'une demande de changement ou de fonctionnalité. Cela se fait généralement en termes de revenus protégés (combien de clients partiraient si vous ne l'avez pas fait) et attiré le chiffre d'affaires (combien de clients arriveront si vous le faites). Cela peut aider avec la priorisation, mais peut également simplement refléter le parti pris ou la préférence personnelle du gestionnaire de produits.

3
user4051

Voici quelques pensées ...

Il y a de nombreux logiciels sur le marché qui vous aide, http://www.fogcreek.com/ avec Fogbugz, Genexus USA avec XPM http://www.genexususa.com/xpm , etc.

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

Vous avez le temps, des ressources et une portée, faites de votre mieux.

Henry Ford a également dit une fois célèbre: "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 dit ... et faites attention aux règles des autres ... ils peuvent bien travailler dans leur contexte, mais pas dans la tienne.

2
Armin Bachmann

La société que je travaille pour des utilisations 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 la fonctionnalité RFC

1
GrumpyMonkey

Les réponses que je vois jusqu'à présent sont bonnes. Une chose que je vais spécifiquement épeler, c'est que vous allez devoir être bon à dire "non" à certaines demandes.

Si vous autorisez le client à définir l'urgence, il sera presque toujours "élevé" (ou plus).

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

1
Wonko the Sane