Alors que les institutions financières ne jurent plus aujourd'hui que par approches « lean startup » et autres méthodes agiles, leurs directions informatiques continuent à gérer des « grands programmes » pluri-annuels, aux budgets qui se mesurent en dizaines (centaines ?) de millions. Comment peuvent-elles justifier une telle schizophrénie ?
Les défauts des méga-projets sont pourtant bien connus, depuis longtemps, et s'aggravent avec l'accélération du monde contemporain et la volatilité des attentes : dépassements de budgets, retards de livraisons… et résultat généralement décalé par rapport aux besoins. Une des principales raisons de ces dérives quasi systématiques réside dans la démarche classique consistant à vouloir spécifier a priori toutes les fonctions requises par le système cible, puis à les implémenter d'un bloc.
Or non seulement il existe toujours une différence entre ce qui est décrit et ce qui est réalisé mais, en outre, ce qui est posé sur le papier est rarement ce qui serait vraiment nécessaire, ne serait-ce que parce qu'il est extraordinairement difficile de conceptualiser un produit futur. Il s'ensuit d'indispensables et fréquents réajustements de périmètre, qui perturbent les plans initiaux et introduisent des fragilités dans la construction, dont l'accumulation est dangereuse. Dans le pire des cas, tout finit à la poubelle.
Au passage, il me faut souligner ici qu'une multitude de projets pseudo-agiles ne font que décliner ce modèle, en répartissant simplement l'implémentation des spécifications sur une série de « sprints » de développement, sans validation intermédiaire auprès des destinataires réels de la solution. Naturellement, les mêmes causes produisant les mêmes effets, les taux d'échec sont aussi élevés qu'avec les méthodes traditionnelles.
La parade à l'illusion des spécifications parfaites, concrétisée par les concepts agiles originels, consiste à bâtir les applications par petits modules, réalisés en quelques semaines (au maximum) et mis entre les mains des utilisateurs (et jamais leurs « représentants »), afin de vérifier sur le terrain leur adéquation aux besoins et procéder aux révisions et autres réorientations qui s'imposent si ce n'est pas le cas.
Dans les organisations qui ont atteint une maturité suffisante en matière d'agilité, ces approches ont démontré leur efficacité, notamment dans le développement d'applications mobiles ou de services en ligne. Malheureusement, il subsiste des domaines dans lesquels il ne semble pas concevable de les mettre en œuvre. Un exemple typique serait le renouvellement d'un « cœur bancaire », qui est pourtant un chantier devenant de plus en plus urgent dans nombre d'institutions financières.
Le raisonnement aboutit ainsi implicitement à un dilemme insoluble, entre des projets tactiques qui peuvent être menés rapidement, par itérations, et des ambitions stratégiques qui ne pourraient être satisfaites que par des programmes titanesques. Le seul moyen de le rompre sera de comprendre qu'il n'est d'autre choix que de raccourcir les cycles de développement, en toutes circonstances. Et pour y parvenir, il faudra aborder tous les problèmes en les découpant en composants élémentaires, indépendants les uns des autres. Si cela paraît impossible, mieux vaut abandonner avant le démarrage…
Les défauts des méga-projets sont pourtant bien connus, depuis longtemps, et s'aggravent avec l'accélération du monde contemporain et la volatilité des attentes : dépassements de budgets, retards de livraisons… et résultat généralement décalé par rapport aux besoins. Une des principales raisons de ces dérives quasi systématiques réside dans la démarche classique consistant à vouloir spécifier a priori toutes les fonctions requises par le système cible, puis à les implémenter d'un bloc.
Or non seulement il existe toujours une différence entre ce qui est décrit et ce qui est réalisé mais, en outre, ce qui est posé sur le papier est rarement ce qui serait vraiment nécessaire, ne serait-ce que parce qu'il est extraordinairement difficile de conceptualiser un produit futur. Il s'ensuit d'indispensables et fréquents réajustements de périmètre, qui perturbent les plans initiaux et introduisent des fragilités dans la construction, dont l'accumulation est dangereuse. Dans le pire des cas, tout finit à la poubelle.
Au passage, il me faut souligner ici qu'une multitude de projets pseudo-agiles ne font que décliner ce modèle, en répartissant simplement l'implémentation des spécifications sur une série de « sprints » de développement, sans validation intermédiaire auprès des destinataires réels de la solution. Naturellement, les mêmes causes produisant les mêmes effets, les taux d'échec sont aussi élevés qu'avec les méthodes traditionnelles.
La parade à l'illusion des spécifications parfaites, concrétisée par les concepts agiles originels, consiste à bâtir les applications par petits modules, réalisés en quelques semaines (au maximum) et mis entre les mains des utilisateurs (et jamais leurs « représentants »), afin de vérifier sur le terrain leur adéquation aux besoins et procéder aux révisions et autres réorientations qui s'imposent si ce n'est pas le cas.
Dans les organisations qui ont atteint une maturité suffisante en matière d'agilité, ces approches ont démontré leur efficacité, notamment dans le développement d'applications mobiles ou de services en ligne. Malheureusement, il subsiste des domaines dans lesquels il ne semble pas concevable de les mettre en œuvre. Un exemple typique serait le renouvellement d'un « cœur bancaire », qui est pourtant un chantier devenant de plus en plus urgent dans nombre d'institutions financières.
Le raisonnement aboutit ainsi implicitement à un dilemme insoluble, entre des projets tactiques qui peuvent être menés rapidement, par itérations, et des ambitions stratégiques qui ne pourraient être satisfaites que par des programmes titanesques. Le seul moyen de le rompre sera de comprendre qu'il n'est d'autre choix que de raccourcir les cycles de développement, en toutes circonstances. Et pour y parvenir, il faudra aborder tous les problèmes en les découpant en composants élémentaires, indépendants les uns des autres. Si cela paraît impossible, mieux vaut abandonner avant le démarrage…
Réflexions inspirées par un article de BankNxt.
Aucun commentaire:
Enregistrer un commentaire
Afin de lutter contre le spam, les commentaires ne sont ouverts qu'aux personnes identifiées et sont soumis à modération (je suis sincèrement désolé pour le désagrément causé…)