Publier tôt / publier souvent pour un logiciel commercial? [fermé]

Question

Y a-t-il quelqu'un qui a des expériences / des exemples sur la publication anticipée / la publication fréquente de logiciels commerciaux? Ça marche?

Je pensais à VMware où de nombreuses révisions sont publiées entre chaque version majeure. Et l’expérience de l’installation a été horrible. Parfois, ils cassaient les machines virtuelles existantes et d’autres fois, les outils VMware dans les systèmes d’exploitation invités ne fonctionnaient pas bien / n’étaient pas installés. C'est horrible.

Et je pensais aussi aux déploiements ClickOnce car avec ClickOnce lors de la mise à jour de votre logiciel, tous les clients sont automatiquement avertis de la version et, en un clic, ils sont mis à jour vers la nouvelle version. Si votre logiciel contient des bogues, ils seront automatiquement "mis à jour". pour obtenir ces bugs aussi bien.

Avez-vous l'expérience \ exemple \ suggestion pour appliquer le principe de publication anticipée / souvent à des logiciels commerciaux?

Je cherche à l'appliquer à un.

Answer 1

Kenny a raison: ça dépend.

Nous travaillons sur des logiciels d'entreprise, dans lesquels un client peut exécuter un projet interne de plus de 3 mois pour effectuer une mise à niveau vers une nouvelle version. Dans cet environnement, les versions fréquentes ne ne fonctionnent pas. Les clients resteront sur une ancienne version pendant des années et nous devons continuer à les prendre en charge. Ainsi, plus il y a de nouvelles versions actives, plus le travail de support est long.

À l'autre extrême, j'utilisais Google Chrome et je lisais une actualisation de la version bêta. Je suis allé voir comment l'obtenir et j'ai découvert que Chrome s'était déjà mis à jour. S'il y a eu une notification, je l'ai manquée et tout va bien pour moi.

La principale question est de savoir dans quelle mesure une nouvelle version perturbe . Par exemple, si MS publiait de nouvelles versions de Visual Studio tous les 3 mois avec une nouvelle version .NET, une exécution C, etc., nous consacrerions une bonne partie de notre temps à la mise à niveau, ce qui ne serait pas bon. Mais s’ils souhaitent publier de nouvelles versions de Windows Media Player avec un nouveau widget qui me convient, il suffit de rendre le processus de téléchargement / installation aussi transparent que possible.

Answer 2

Je pense que cela dépendra toujours de votre marché ou de votre clientèle. Changer / mettre à jour un logiciel est toujours douloureux et encore plus dans certains environnements et entreprises. Les cycles de libération rapides peuvent être perturbateurs. Ces perturbations s'étendent souvent également à vos opérations internes, en fonction de la qualité de la gestion du fluage des fonctionnalités par le marketing / la gestion.

Ainsi, la réponse classique «ça dépend» résonne de nouveau.

Si vous ajoutez vraiment de la valeur au produit, alors les clients, en particulier les nouveaux, le voudront. Le meilleur des cas est de supprimer la douleur liée au changement de mise à niveau, car cela fonctionne de la même manière, mais de manière plus évidente. Génial.

Answer 3

Faites attention à l'homme derrière le rideau. :
La chose que la pratique de Release Early - Release veut souvent que vous fassiez, c’est d’échouer tôt et rapidement au lieu de le faire à la fin du projet, quand il est trop tard. Cela vous donne davantage d’occasions de montrer ce que vous construisez au client final, d’obtenir des commentaires précieux et de vous adapter à moindre coût. La personne occupant le rôle de "client" doit pouvoir obtenir facilement la dernière version. jouez avec elle et répondez avec des retours constructifs aussi régulièrement que possible.

Si vous construisez quelque chose de critique, par exemple. Quelque chose qui surveille ou contrôle une centrale électrique, vous voudrez probablement être prudent avec cette pratique. Vous ne voulez pas que les gens sortent avec des flambeaux comme commentaires pour votre nouvelle version. Dans de tels cas, il est judicieux de se déployer régulièrement sur un banc d’essai, de le regarder pendant X jours (selon votre niveau de confiance) et de passer ensuite en DIRECT! Vous pouvez donner à votre client l’accès à ce banc d’essai pour jouer et développer son indicateur de confiance.
S'il s'agit d'une application non critique et que vous avez un bon historique de bonnes versions, faites quelque chose comme ClickOnce .. mais assurez-vous également qu'il est tout aussi facile de revenir en arrière pour le client.

Answer 4

Si vous envisagez de le faire, assurez-vous que, lorsque les utilisateurs achèteront votre produit, ils bénéficieront de mises à niveau gratuites des nouvelles versions pendant un an ou une autre période, de sorte qu'ils ne se sentent pas arnaqués. quand une nouvelle version sort 2 mois après l’achat d’une copie. Assurez-vous également que vous supportez les anciennes versions de sorte que ceux qui ne souhaitent pas mettre à niveau, veulent juste des corrections de bogues, puissent le faire sans risquer de casser leurs installations actuelles avec les nouvelles versions du logiciel. Personnellement, je pense que ce sera plus de travail, mais vous vous retrouverez avec un meilleur produit et vous permettrez à ceux qui utilisent votre logiciel de tirer plus rapidement parti des nouvelles fonctionnalités s’ils le souhaitent.

Answer 5

Nous exécutons une application SaaS. En principe, elle peut donc être mise à jour aussi souvent que vous le souhaitez.

D’autre part, dans la pratique, il n’obtient que quelques versions majeures par an (des versions plus petites des correctifs sont généralement publiées toutes les quelques semaines).

La raison en est que les rejets créent des perturbations pour le personnel des opérations; Parfois, une partie de l'application doit être supprimée. Tous les changements ne concernent pas le client, mais il y a beaucoup de travail à faire pour la publication , par opposition à l'ingénierie.

Ainsi, bien que StackOverflow semble être mis à jour tous les quelques jours, nous ne faisons rien de ce genre. Plusieurs bogues peuvent être corrigés en une journée, mais ils sont corrigés dans une version ultérieure qui devient un "big bang". Ou quelque chose.

Answer 6

Cela dépend de vos ressources. Si vous êtes MicroSoft, vous pouvez publier de manière anticipée un PDV encombré de bogues qui rime avec Sista et compter sur votre puissance marketing pour faire oublier aux utilisateurs leur première expérience avec le produit.

Si vous souhaitez un bon bouche-à-oreille, publier une première version n’est pas une bonne idée (à moins que vous n’ayez l’intention de changer le nom ou quelque chose d’avant la version finale).