Merci pour tes retours, qui m'invitent à leur tour à des remarques
Réduire les coûts sans sacrifier la qualité est évidemment intéressant pour l'entreprise ou le client car :
- soit vous avez la même chose pour un coût inférieur,
- soit vous avez un périmètre fonctionnel plus étendu pour le même prix.
Ce n'est pas totalement vrai. Les plus gros défauts des analyses de coûts que je peux lire sont systématiquement 1. qu'elles font l'hypothèse que l'univers peut être modélisé avec des additions et dans quelques cas extrêmes des multiplications, et 2. qu'elles ne décrivent pas assez soigneusement le système qu'elles étudient. Ici c'est le 2, car lorsque tu as livré ton produit, ton entreprise n'est plus la même! Tu as des développeurs qui ont acquis des connaissances, soit purement techniques, soit plus conceptuelles (techniques de programmation, techniques de génie logiciel, gestion de projet par exemple), par exemple.
Il n'empêche que c'est intéressant pour l'entreprise de pouvoir réduire les coûts pour une qualité équivalente. Ça n'est pas forcément LA solution à retenir (et en tout cas surtout pas la solution à retenir systématiquement). Après il faut savoir faire la distinction entre les cas où c'est à mettre en oeuvre et les cas où c'est à proscrire.
Et je te rejoins sur le fait que certains projets peuvent ne pas être concernés par "une rentabilité optimale en terme de temps de dév". Mais sur certains projets (au hasard, des dév sur des technos vieillissantes et des produits qui sont condamnés), on peut réduire les temps de dév sans "bacler le travail", ce qui permet de consacrer plus de temps à d'autres projets.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Hypothèse fondamentale discutable
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 1.
Merci pour tes retours, qui m'invitent à leur tour à des remarques
Il n'empêche que c'est intéressant pour l'entreprise de pouvoir réduire les coûts pour une qualité équivalente. Ça n'est pas forcément LA solution à retenir (et en tout cas surtout pas la solution à retenir systématiquement). Après il faut savoir faire la distinction entre les cas où c'est à mettre en oeuvre et les cas où c'est à proscrire.
Et je te rejoins sur le fait que certains projets peuvent ne pas être concernés par "une rentabilité optimale en terme de temps de dév". Mais sur certains projets (au hasard, des dév sur des technos vieillissantes et des produits qui sont condamnés), on peut réduire les temps de dév sans "bacler le travail", ce qui permet de consacrer plus de temps à d'autres projets.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo