1.7 KiB
The Phoenix Project
On pourrait résumer ce livre comme "L'histoire d'un projet qui prend feu". Plus ou moins jusqu'à la moitié du livre, c'est la descente aux Enfers de la gestion d'un projet IT: Bill Palmer se retrouve propulsé de la tête des opérations à la tête du département IT; son premier jour à cette fonction le met face à face avec une erreur au niveau de la paie, liée à une mise à jour du SAN (mais spoiler alert en fait liée à un process IT de sécurité qui obfuscait les valeurs du numéro d'identification national de chaque employé - parce que c'est pas légal).
Ensuite, on part sur les échecs continuels du plus gros projet IT mis sur les rails, mais qui accumule déjà 3 ans de retard et 20 millions $ hors budget.
Le petit plus, c'est que chaque point est analysé et une solution est envisagée; au final, on arrive à la mouvance DevOps, où l'idéal visé est de d'avoir un Time To Market le plus faible possible. Et pour ça, on doit laisser tomber les grosses releases contenant plusieurs fonctionnalités attendues, mais effectuées seulement tous les 9 à 12 mois.
Au niveau du releases et changes managements, il y a un article intéressant ici, qui spécifie que Il n'existe pas d'infrastructure infaillible, mais il existe des processus qui permettent de minimiser l'impact des risques encourus par un système d'information. On doit donc veiller aux points suivants:
- Mises à jour et suivi de la pile logicielle
- Systèmes de sauvegarde
- Restauration de ces sauvegardes.
Les "petites économies" réalisées au fur et à mesure d'un projet se traduisent par dette technique.