 |
| From blog.crisp.se |
Dans les
commentaires, George, un internaute rappelle à Henrik les conditions de
pression dans lesquelles les développeurs sont au quotidien.
Henrik lui répond
que dans le "monde réel" qu'il voit, les compagnies s'engouffrant
dans la dette technique vont de moins en moins vite, perdent des développeurs,
et finissent par regretter leur manque de discernement qui rend de plus en plus
coûteuse la correction des anomalies à posteriori.
Il synthétise en
disant que ne pas s'occuper de la qualité du code est un investissement court
terme, bien que les compagnies cherchent à vivre longtemps.
C'est sur ce dernier
point que je souhaite apporter mon point de vue.
"Les compagnies
cherchent à vivre longtemps"
Oui, toutes, les
compagnies clientes et les SSII! *
Hors pour que les
SSII vivent longtemps, il faut qu'elles aient du travail pour longtemps. Vous
voyez où je veux en venir.
Les SSI sont
facturées à la journée, à la charge consommée ou vendue
(au forfait ou en régie peu importe). Le développement des applications
est découpé en projet de développement puis en projets de maintenance (Tierce
Maintenance Applicative). Quel intérêt pour une SSII de faire que le produit
qu'elle fournit soit trop exempt d'anomalies, que la dette ne soit pas trop
réduite? De toute façon le client fera appel à elle (ou une autre, juste un
échange entre SSII du marché) pour une TMA, et au final repayer pour corriger
des bugs non vus avant et pour lesquels ils ont en plus déjà payé de la
garantie souvent.
Même chez les
clients. J'ai entendu chez un de mes clients, il y a fort longtemps, que le
coût des tests automatisés, par exemple, étaient trop élevés pour le projet de
développement et que ce n'était pas grave que ça coûte cher pour la
maintenance, "ce sera un autre budget pour le département d'à côté".
Là aussi problématique lié au découpage budgétaire et du cycle dev+maintenance.
Pour qu'une société
vive longtemps, c'est sur la valeur qu'il faut se focaliser, le ratio
valeur/coût.
Vérifier que vos
équipes ou vos prestataires puissent vous garantir le maintien de l'apport de
valeur au même coût et ce sur le long terme.
Et opter pour une
vision produit, tout au long de la vie de celui-ci, de façon itérative et
essayant sans cesse d'améliorer le coup suivant.
Comment va-elle
traiter la dette technique? pas en balayant la poussière sous le tapis.
Là aussi faut des tripes. SWCC ™
(*) j'ai vu dans un article aujourd'hui qu'il fallait maintenant appeler les SSII les SSN, Société de Services en Numérique, bon.
2 commentaires:
Bonjour Laurent !
Un commentaire bien dur ... Ce que je constate est que les SSII proposent à leurs clients des outils de mesure de la qualité (Sonar, CAST) pour démontrer la valeur de leurs développements. Les clients qui s'intéressent à la dette technique sont demandeurs de telles métriques. A l'inverse, les clients qui ne s'intéressent qu'au cout immédiat des solutions ne veulent pas voir l'évolution de cette dette.
Pour ce qui est de l'avenir des SSII, un client préférera toujours payer pour une évolution que pour une correction, donc mieux vaut fournir un code propre en continu !!! Bonne soirée !
Bonjour Guillaume.
Merci pour ton commentaire.
Tu as raison, Sonar et Cast peuvent servir à détecter de la dette.
Je ne parle pas de valeur des développements, mais de valeur du produit. Même un code propre peut ne servir à rien. 45% des fonctionnalités des logiciels ne servent jamais et 19% rarement (Etude Chaos Report du Standish group). Ce code contribue aussi à la dette.
Quant à ta dernière phrase, je suis en phase avec, et c'est bien de cela dont je parle.
Je ne fait aucunement l’apologie des SSII, bien au contraire, ou alors je me suis mal exprimé. ;-)
Enregistrer un commentaire