Que faire lorsque votre projet «en échec» est réellement «réussi»?

Que feriez-vous si vous étiez dans une situation où le projet sur lequel vous travaillez est évidemment mal construit et aura des échecs à l'avenir et sera un cauchemar à entretenir ... mais il est considéré comme un "succès" par la direction car les clients est heureux?

Dois-je simplement ne pas m'en soucier? Est-il normal que les clients ne réalisent même pas qu'ils pourraient avoir une meilleure application que celle-ci?

À quel moment dois-je cesser de me soucier de le construire correctement et de simplement suivre le courant?

Si les clients sont satisfaits, vous faites quelque chose de bien. Beaucoup de gens aiment les hot-dogs sans savoir comment ils sont faits ...

Si l'application est une bonne solution au problème, mais que vous craignez que la fondation soit défectueuse, découvrez comment améliorer les choses de manière incrémentielle et présentez un plan pour mettre en œuvre ces améliorations lors de la mise à jour du produit. L'incrémentation est la clé: si vous avez envie de réécrire des parties entières, votre gestionnaire va dire à juste titre que c'est déraisonnable. Le parfait peut être ennemi du bien. Consultez l'histoire de jwz sur la façon dont Netscape a laissé IE prendre la tête parce qu'ils "devaient" réécrire Navigator.

Si l'interface utilisateur de l'application est en elle-même un gâchis, les clients peuvent toujours être satisfaits car ils la comparent à «la dure» et même un programme de buggy peut être bien mieux que cela. Vous le comparez à un idéal que vous pouvez imaginer en raison de vos antécédents et de vos compétences. Encore une fois, réfléchissez à la façon dont vous pouvez améliorer les choses de manière incrémentielle, et inscrivez cela dans le cadre du plan.

Ne cessez pas de vous soucier: vous voulez que votre travail soit le meilleur possible. Mais souvenez-vous également que c'est le client qui paie vos factures et que vous écrivez un logiciel pour lui, pas vous.

Ce n'est pas un cauchemar pour eux. Ce sera un cauchemar pour vous et ils semblent penser que vous savez ce que vous faites, donc ce sera réparé. Préférez-vous les gens qui ne connaissent pas la programmation et pensent que votre application est pire qu'elle ne l'est réellement? Ce n'est pas l'exception. Profites-en tant que tu peux. Vous feriez mieux d'espérer que le client dépasse cette application. Ils peuvent aller si loin dans une autre direction en tant qu'entreprise que cela est absolument inutile. Vous pourriez le réécrire pour un ensemble de raisons complètement différent de ce que vous pensez.

Je ne pense pas que vous devriez jamais cesser de vous soucier, même s'il semble que la haute direction s'est arrêtée. Je pense que la chose importante à retirer de cette expérience est de se souvenir et de documenter toutes les choses qui, selon vous, ont mal tourné. Éviter ces erreurs à l'avenir sera finalement reconnu, sinon ce groupe actuel de gestionnaires, peut-être le prochain groupe de gestionnaires pour lequel vous travaillez.

Je commencerais à présenter des idées pour les prochaines étapes de développement qui incluent la refactorisation pour améliorer la qualité du code. Évitez d'aller trop loin dans les détails techniques, mais montrez comment les correctifs que vous proposez signifieront une satisfaction continue du client. Soyez prêt à mélanger le nettoyage avec de nouvelles fonctionnalités, car la direction recherchera toujours quelque chose de nouveau à vendre.

En général, les clients ne se soucient pas de l'entretien tant que quelque chose ne va pas. Idéalement, votre entreprise se soucierait de sa réputation et voudrait la protéger en maintenant le code.

Cependant - si ce produit est considéré comme étant à très court terme, il peut ne pas réellement y avoir de valeur ajoutée pour le faire correctement. Dans ce cas - recherchez les correctifs bon marché - les choses avec peu d'effort qui ont une grande valeur pour la raison du développeur.

Non. Vous utilisez le succès pour sécuriser le financement / l'autorisation / l'adhésion pour commencer à refactoriser vers techniquement correct et facile à maintenir. Ou vous utilisez le succès pour être promu hors du département "Je parviens à maintenir l'ancien code base".

Peut-être que votre priorité / point de vue est faux.

La chose la plus importante à propos de tout projet logiciel est qu'il satisfait aux exigences des utilisateurs.

C'est un gazillion fois plus important qu'être "correct" selon la mode de conception de ce mois-ci.

Oui, vous devez utiliser des modèles de conception corrects, utiliser la technologie correctement, etc., etc. mais uniquement dans la mesure où cela facilite la mise en œuvre des exigences des utilisateurs de manière robuste et maintenable.

Un système vraiment mal écrit qui répond réellement à un besoin commercial est toujours meilleur qu'un morceau de code magnifiquement écrit et merveilleusement écrit que personne ne veut ou n'a aucune raison d'utiliser.

Essayez de communiquer avec les utilisateurs actuels et demandez-leur quels aspects ILS pensent devoir être améliorés. Ensuite, vous pourriez améliorer certains aspects qui, selon vous, doivent être améliorés et améliorer également les aspects proposés par les utilisateurs. Vous pouvez justifier vos améliorations comme "nécessaires pour mettre en œuvre les améliorations proposées par les utilisateurs"

Par exemple: si les utilisateurs pensent que la fonction de recherche est lente. Vous pouvez améliorer cela en créant une meilleure couche de données qui sert évidemment plus que la recherche, mais vous pouvez alors justifier le temps passé.