C'est là toute la problématique : d'un côté tu as ceux qui demande, et qui veulent avoir au plus vite et au moins cher, et de l'autre ceux qui font, et qui veulent avoir un max de temps et d'argent (soyons sympa : pour payer au mieux les développeurs pour qu'ils fassent du bon boulot). Et comme tout problème ayant des besoins conflictuels, il n'y a pas de juste milieu, tout dépend des besoins et influences. Dans le cas d'un système critique, tel qu'un avion, tu as beau faire tes plannings, tu as des règles qui t'imposent d'avoir telles fonctionnalités, respectant telles contraintes, validés par tels tests, etc. Donc même si on te dit "On m'avait dit pour vendredi, donc je le veux pour vendredi !", si ces règles ne sont pas respectées, ton avion n'est pas autorisé à voler, donc tu es obligé de dépasser tes délais si tu ne veux pas avoir fait tout ce qui précède pour rien. Et c'est là qu'on fait jouer les pénalités de retard. Et les compromis dans le cahier des charges/planning sont à trouver en fonction de ces règles et pénalités. Ce n'est pas qu'une question de décision perso.
Enfin, personne n'est à l'abri d'un oubli ou de ne pas savoir. Pour les systèmes critiques, il y a des tas de standards ou que sais-je, qui permettent de réduire les risques, mais le risque zéro n'existe pas. Et comme on l'a discuté dans une autre discussion, faire voler un avion au risque qu'il se crash et tue des gens, désolé d'être aussi rabat-joie, mais ça aussi ça se chiffre, et si ça coute moins cher que d'améliorer l'analyse alors on prendras ce risque. Chaque vie a un prix quand on est capitaliste. Une entreprise est là pour faire du chiffre, pas de la charité. J'aime pas l'idée non plus, mais c'est comme ça qu'on te l'enseigne. Mais tu me diras, c'est un autre débat {^_^}.
Partager