À la fin des grands projets de développement, il y a souvent le danger que personne n'ait plus la vue d'ensemble. Avec le courage de simplifier radicalement, ce problème peut être contré très tôt.
Dans les grands projets de développement comptant jusqu'à 20 000 jours de projet au bon moment, comment peut-on réduire les efforts, minimiser les risques et concentrer les ressources ? Comment peut-on éviter que des signaux d'alarme clairs ne soient simplement ignorés pendant la période de développement ? Dans ce qui suit, les phénomènes qui se produisent de manière répétée dans les grands projets de développement sont montrés et il est expliqué comment ils peuvent être mieux gérés.
Conditions cadres pour les grands projets de développement informatique
Les systèmes complexes de front et de middle office des institutions financières, souvent en activité depuis 15 ans, ont récemment nécessité des changements massifs dans les applications et la technologie, déclenchés par des exigences légales.
Les attentes des clients sont les suivantes :
Pour le financement, on recherche des clients internes qui définissent les autres objectifs de la demande pendant la phase de conception.
Dans ce scénario, une douzaine de services différents ou plus créent une multitude de nouvelles exigences et de demandes d'amélioration qui visent à faciliter le traitement et la fourniture de données.
D'autres conditions environnementales le sont : Des budgets de l'ordre de deux à trois millions de dollars, plusieurs fournisseurs, c'est-à-dire des contractants, en phase de mise en œuvre qui doivent travailler ensemble, une zone d'essai externalisée. Comme les équipes de spécialistes et de TI travaillent de manière ambitieuse sur le concept, mais que de nombreuses demandes de changement doivent être prises en compte, l'acceptation des concepts se fait sous une pression de temps considérable.
Bien entendu, il existe une "charte de projet" et tout ce qui est "à la pointe de la technologie", comme une vue d'ensemble de toutes les exigences, les unités organisationnelles responsables du projet, les sous-projets dotés en personnel en conséquence. Les voies de signalement sont respectées. Un ensemble d'outils pour la planification des projets a été mis en place, les rapports correspondants aux conseils de décision, y compris les réunions, sont disponibles et sont transmis aux comités de projet pour évaluation et décision.
Il est évident que le projet est parfaitement organisé - il y a des responsables de sous-projets, des experts, des juristes dans les sous-projets, chacun d'entre eux produisant des concepts techniques en quantité suffisante et d'une qualité spécifiée.
Les défis des grands projets de développement informatique
La durée du projet est de trois à cinq ans. Mais alors, qu'est-ce qui ne va pas ou provoque des incohérences, des phénomènes d'effort, des retards dans la conception, le traitement des dossiers et donc des changements dans le plan du projet ?
L'ordre prévu de traitement des sous-projets s'avère être le mauvais ordre car les sous-projets supposés plus faciles à gérer sont lancés en premier.
Les sous-projets complexes sont dotés d'un nombre insuffisant d'experts et de généralistes.
De nombreuses itérations sont nécessaires lors de la création des exigences commerciales.
Lors de la mise en œuvre de concepts liés aux TI, des inexactitudes considérables dans les concepts commerciaux deviennent apparentes, ce qui provoque fréquemment des questions de la part des développeurs et, à son tour, de nouvelles adaptations des concepts TI et donc, par la suite, des concepts commerciaux.
Les ministères insistent souvent sur leurs spécifications conceptuelles.
Au milieu du projet, il devient évident que le traitement des sous-projets ne peut être mis en parallèle que dans une mesure limitée : Le nombre de sujets notés dans l'"arriéré" augmente et le nombre de "demandes de changement" augmente.
Le fait de se concentrer sur quelques experts entraîne des goulots d'étranglement dans le projet
Le transfert de savoir-faire, des exigences et de la conception au développement, prend plus de temps que prévu
Des malentendus dans la description des cas de test jusqu'à la maintenance des testeurs entraînent des retards dans la phase de test importante du test d'intégration du système (SIT). Les erreurs de fonctionnement sont structurées trop tard par rapport aux sous-processus associés et ne sont pas traitées de manière cohérente. Au lieu de cela, seuls les cas problématiques manifestement les plus importants sont traités dans l'espoir que d'autres erreurs seront "drainées" dans le "chenal" des "défauts" traités dans la programmation.
Un effet secondaire négatif de ce scénario est que la volonté des ministères d'accepter la solution proposée et d'avaler des crapauds "cachés" diminue.
Notes sur les "Contre-mesures" (en anglais)
Comment pouvons-nous changer de cap à temps ? Un signal d'alarme est un numéro de "défaut" à trois ou quatre chiffres, dont le niveau de détail devient impénétrable dans sa totalité et entraîne ainsi un "flou" massif : un patchwork de "pseudoprécisions" de dix mètres de long.
Il est donc logique de "jeter" et "d'oublier" radicalement un tiers des erreurs constatées. Le rejet n'est pas seulement un tiers de toutes les erreurs, mais les erreurs classées comme faciles, en supposant qu'elles ne sont pas pertinentes pour le développement du système. Ces erreurs mineures comprennent : des phénomènes de données d'essai, des erreurs de fonctionnement qui entraînent des malentendus, une affectation incorrecte des champs de données, par exemple le remplissage "must instead of can" et vice versa, et des données d'essai incorrectes jusqu'à l'absence d'un inventaire d'essai stable.
Grâce au regroupement en temps utile des erreurs constatées dans les sous-processus correspondants, à la "formation d'équipes" cohérente, en temps utile et dans l'espace, de développeurs, de testeurs et d'experts techniques, et au courage d'oublier simplement les erreurs mineures, un projet majeur peut être bien maîtrisé et avec moins de stress pour toutes les parties concernées, malgré la division tayloriste initiale des tâches, et remis en production "à temps".