J’en suis parti et ai appris quelques mois plus tard qu’ils ont perdu les gros clients (qui avaient certainement/probablement marre de payer des correctifs abscons...)
En plus de 10 ans de boîte, je n'ai jamais eu de client qui parte car on avait trop de dette technique. Parce que c'est trop cher, parce que ça répond mal oui, mais pas parce qu'il y a trop de dette technique.
En revanche, des clients qui ne viennent pas parce qu'il manque une fonctionnalité, oui. Et pour réussir à les signer quand même, il n'y a rien de mieux qu'une fonctionnalité « ajoutée à l'arrache » et qui est retravaillée en parallèle de la signature du client ou de la mise en place.
Mais pour être capable de faire ça, il faut des développeurs qui comprennent l'enjeu et sont pro-actif dans cette stratégie de dette.
Ça ne veut pas dire saloper le travail, ça veut dire livrer vite même si un peu moche avec l'idée de rectifier / améliorer ensuite.
Certains vont me dire « oui on sait ce que ça donne ensuite ça passe sous le tapis » . Possible : si ça marche bien il n'y a pas de raison de retravailler la fonctionnalité (ou pas tout de suite).
En revanche, le prospect que tu n'as pas signé, tu as aucune chance de le voir revenir.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Je ne demande si l'auteur a compris l'enjeu (de la dette technique)
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au lien Most Technical Problems Are Really People Problems. Évalué à 4.
En plus de 10 ans de boîte, je n'ai jamais eu de client qui parte car on avait trop de dette technique. Parce que c'est trop cher, parce que ça répond mal oui, mais pas parce qu'il y a trop de dette technique.
En revanche, des clients qui ne viennent pas parce qu'il manque une fonctionnalité, oui. Et pour réussir à les signer quand même, il n'y a rien de mieux qu'une fonctionnalité « ajoutée à l'arrache » et qui est retravaillée en parallèle de la signature du client ou de la mise en place.
Mais pour être capable de faire ça, il faut des développeurs qui comprennent l'enjeu et sont pro-actif dans cette stratégie de dette.
Ça ne veut pas dire saloper le travail, ça veut dire livrer vite même si un peu moche avec l'idée de rectifier / améliorer ensuite.
Certains vont me dire « oui on sait ce que ça donne ensuite ça passe sous le tapis » . Possible : si ça marche bien il n'y a pas de raison de retravailler la fonctionnalité (ou pas tout de suite).
En revanche, le prospect que tu n'as pas signé, tu as aucune chance de le voir revenir.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo