Comment communiquez-vous vos dates de sortie aux clients?

Question

En tant qu'équipe de développement, nous subissons beaucoup de pression (en interne) pour fournir des dates de sortie précises à nos clients. Comment devrions-nous nous y prendre? Les problèmes que nous voyons sont de définir exactement ce qui est requis pour chaque version et de ne pas savoir comment nos priorités sont susceptibles de changer au cours d'une publication. Nous utilisons FogBugz et pensons que nous pouvons utiliser la planification basée sur Evidence pour aider à l'incertitude, mais nous ne nous attendons pas à ce que nos clients soient très satisfaits d'une gamme de confiance.

Je vois que Fog Creek a pour politique de ne pas dire aux clients quand les versions seront disponibles jusqu'à ce qu'elles soient réellement terminées. Est-ce que quelqu'un d'autre prend cette approche?

EDIT: Merci pour les réponses - très difficile de choisir une réponse acceptée, alors j'ai voté quelques-uns d'entre eux pour vous donner le karma. J'ai choisi cowgod's comme celui qui correspond à la façon dont je voudrais gérer notre propre développement.

Answer 1

Pour le projet sur lequel je travaille actuellement, nous fournissons à la fois une version de production et une version d'assurance qualité (QA) chaque semaine. Si QA a approuvé le déploiement de la semaine précédente, il sera mis en production et nos dernières corrections de bogues et demandes de fonctionnalités seront packagées pour être validées par QA. Nous continuons ce processus indéfiniment.

Nous avons un Wiki de documentation qui est mis à jour avec les dernières notes de version que le client peut voir.

Answer 2

Nous prenons l'approche de ne pas annoncer une date de sortie jusqu'à ce que nous ayons fini. Si le client en a besoin plus tôt, alors nous expliquons quelles parties sont terminées et celles qui ne le sont pas. Parfois, ils sont d'accord avec seulement un ensemble de fonctionnalités de base, si ce sont les fonctionnalités vraiment importantes, et sont prêts à attendre d'autres fonctionnalités. Dans mon expérience cependant, ils veulent habituellement attendre que tout soit fait avant de les relâcher. J'ai la chance d'être dans une culture où il n'y a pas beaucoup de pression pour que nous sachions à l'avance quand nos sorties se produiront.

Answer 3

Google le fait également, ne publiant pas les dates de sortie.

Au sein d'un projet, il y a trois facteurs que vous pouvez varier sur, en ce qui concerne les rejets:

• temps
• argent/ressources
• Nombre de caractéristiques

Avec tous réguliers oui/mais/si à propos d'eux (ajouter des ressources supplémentaires tard dans le temps n'aide naturellement pas votre projet).

Si vous avez une date de sortie fixe, l'heure est fixée. De cette façon, vous ne pouvez gérer votre projet correctement que si vous changez les deux autres: en dépensant plus ou en limitant le nombre de fonctionnalités de votre produit.

Answer 4

Si vous êtes sous une telle pression que vos clients sachent quand vous lâchez, vous pouvez essayer certaines des techniques XP comme laisser les clients décider des fonctionnalités qu'ils veulent en premier et faire TDD.

Answer 5

Nous ne fournissons pas de date. Nous leur demandons simplement quand ils seront disponibles pour tester notre version. (Cela nous donne généralement beaucoup de temps pour conclure, car personne ne veut tester et ils ont tous leur propre travail à faire.)

Answer 6

Juste pour donner une autre perspective:

On nous donne notre date de sortie!

Pour une grande entreprise, vous ne pouvez libérer un produit interne le week-end, ce qui signifie que vous apprendrez rapidement que:

a/il n'y a que 52 d'entre eux
b/il y a beaucoup de concurrence pour en réserver un (l'équipe logistique est l'un des concurrents, pour les mises à niveau serveur et/ou réseau, et empêche toute mise en production puisque les serveurs peuvent être arrêtés à tout moment)

Donc nous n'avons pas le choix de la date de sortie: nous n'en avons qu'un petit nombre par an, et il est peu probable qu'ils changent. Pour continuer à délivrer une version significative, nous définissons un "top content" qui se réunira quelques semaines avant la date de sortie afin de définir ce qui sera réellement une partie de la version (certains développements actuels ne le seront pas, car ils se révèlent trop complexes, ou dépendants d'autres parties qui ne sont pas prêtes, ou pour tout autre changement "prioritaire")

Puis un Release Manager s'assure que toutes les équipes fusionnent les développements choisis sur un environnement de test pour tous homologation/UAT/cycle d'essai de pré-production. (Je saute beaucoup de détails ici)

Et puis nous livrons. À temps. (Et ensuite faire quelques correctifs;))

Answer 7

Les fois où j'ai été impliqué dans des projets qui précisaient les dates de sortie, nous l'avons fait en divisant les fonctionnalités en "essentiel pour cette version" et "peut être glissé à la prochaine libérer ", puis en choisissant une date de sortie de telle sorte que nous sommes très à l'aise, nous pouvons compléter toutes les fonctionnalités essentielles, et pense qu'il y a au moins une chance de remplir toutes les fonctionnalités inessentielles. Bien sûr, cela soulève plutôt la question de savoir pourquoi nous considérons même les caractéristiques inessentielles, mais dans un projet pratique, il y a généralement plusieurs choses qui peuvent être déplacées dans un sens ou dans l'autre, selon (a) si le (b) combien de temps devrait être la prochaine version et comment il est facile pour le client de la mettre à niveau, (c) comment votre plan d'affaires est affecté par, respectivement, un produit vendable maintenant, ou l'Ultimate Product of Awesomeness l'année prochaine. Donc, ce qui se passe réellement est trois catégories, "essentielles et attendues pour rester essentielles: si cela n'est pas fait à temps, nous serons forcés de libérer tard", "traité comme essentiel pour l'instant, mais nous pouvons changer d'avis comme la date de sortie approche ", et" traitée comme non pour cette version pour le moment, mais nous allons la faire avancer si le temps le permet ".

Un grand nombre de projets auxquels j'ai participé, cependant, ont été très longs, et les versions intermédiaires sont essentiellement des instantanés de la version de travail actuelle. C'est comme si vous aviez triché pour dire que vous aviez donné une date de sortie précise, quand un client a demandé une mise à jour, vous avez vérifié votre liste de bogues active pour ce client et vous avez vu deux problèmes en suspens. Je me suis dit qu'il faudrait une semaine pour corriger les deux et faire la vérification, et je leur ai dit "nous vous donnerons une goutte dans 1-2 semaines".

Answer 8

En tant que personne qui doit le plus souvent répondre à Fog Creek, je peux dire que notre politique mouth wide shut est très intelligente, mais prend un peu de contrôle.Au fil des mois, avec la bénédiction de la direction, j'ai trouvé quelque chose qui fonctionne pour moi de ne pas me sentir comme un membre obsolète d'une certaine administration présidentielle sortante, et aide à donner au client un contexte sans prendre un engagement potentiellement trompeur.

Il s'agit de faire savoir au client où nous en sommes dans le processus. À l'heure actuelle, je leur fais savoir que nous codons activement maintenant, et qu'une fois que nous atteignons le code complet, ce qui est loin, nous devons encore faire un AQ, corriger les bogues, corriger le bogue, et au moins quelques de betas.

Exemple de ce que vous pourriez obtenir si vous me demandez une date de sortie pour FogBugz 7:

Pour FogBugz 7, nous codez activement, tout à fait un certain temps hors de code complet, encore. Si vous avez un problème particulier qui vous préoccupe, faites-le moi savoir et je ferai de mon mieux pour le mettre en évidence auprès des ingénieurs ou vous donner un statut si nous en avons un. Une fois que nous sommes à l'étape du code complet, nous devons encore passer par le processus d'assurance qualité, de correction de bogue, de re-QA et de bêta. Nous sommes heureux de vous informer que nous sommes dans ce processus à chaque étape, de sorte que vous pouvez suivre nos progrès, mais nous ne pouvons pas dire avec certitude quand le processus sera terminé.