• Share
  • Email
  • Embed
  • Like
  • Private Content
Livre Blanc Sauvetage de projets
 

Livre Blanc Sauvetage de projets

on

  • 535 views

 

Statistics

Views

Total Views
535
Views on SlideShare
527
Embed Views
8

Actions

Likes
0
Downloads
85
Comments
0

2 Embeds 8

http://www.scoop.it 6
http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Livre Blanc Sauvetage de projets Livre Blanc Sauvetage de projets Document Transcript

    • Pourquoi ce livre blanc ?TheCodingMachine a eu souvent loccasion daider desclients à sauver des projets. Ces situations critiques nous ontpermis dappréhender les origines de ces dérapages, detrouver des solutions et de les mettre en œuvre.Le "sauvetage de projet" est un sujet passionnant à plusieurstitres :− Il nécessite de mettre en pratique une très large palette de compétences. Des compétences humaines pour distinguer objectivement les problèmes réels de ceux qui sont fantasmés, des compétences techniques afin de pouvoir plonger au cœur des applications, sans oublier la la créativité pour imaginer ou trouver les bonnes solutions.− Cest une activité exigeante. Les attentes des clients sont fortes. Ces missions nécessitent de déployer une énergie importante dans un délai record afin de convaincre les différentes parties et mettre en place les bonnes actions correctrices.Ce livre blanc est là pour vous livrer une synthèse de nosexpériences, les écueils à éviter et vous exposer lesméthodes que nous avons appliquées. 2
    • A qui s’adresse ce livre blanc ?Si vous estimez que votre projet est en danger ou en pleinetourmente. Si, plus simplement, vous souhaitez approfondir lanotion de risques sur un projet, ce livre blanc est fait pourvous.Avertissement :Ce livre blanc est le fruit de notre expérience. Vous ytrouverez peut être des défauts ou en soulèverez des limites.Dautre part, toutes les solutions présentées, parce quellesne sappliquent pas à toutes les situations, ne sont pasgaranties.Ce livre a pour objectif de vous donner des idées et departager nos expériences.Nhésitez pas à nous faire part de votre expérience !Note sur les auteurs et la version :Ce livre blanc a été écrit par Jean-Guillaume DUJARDIN etNicolas PEGUIN.Date de publication de la première version : septembre2012. 3
    • Plan du document :Le premier volet du document détaille les risques quimenacent votre projet et vous donne des repères fort pourles isoler.Votre projet navance plus ? Est dans une situation critique ?Le deuxième volet propose de vous donner des clés poursauver un projet en distinguant différentes étapes :1. Est-il possible de sauver le projet ?2. Quelles sont les pistes pour résoudre les problèmes humains ?3. Comment résoudre les problèmes techniques ? 4
    • La différence entre le risque & une situationdéchecLe risque est susceptible dêtre géré. Il est donc possible demener des actions correctives. A linverse, une situationdéchec est une accumulation de risques non gérés quiaboutissent souvent à un blocage global du projet.Si vous vous posez la question de savoir si votre projet esttotalement planté ou si vous êtes simplement en train degérer un risque, vous êtes à une étape cruciale dudéveloppement de votre projet. En général, plus on se rendcompte tard du plantage, plus cest grave. Autrement dit,plus on accumule les risques au fur et à mesure du projet,plus le sauvetage sannonce difficile ! 6
    • Les dangers qui vous guettent !Chaque étape d’un projet comporte des risques. La plupartdes risquent qui menacent un projet sont connus à lavancemême si certains apparaissent dans des situationsparticulières parce que liés à une problématique unique.Néanmoins, la manière de structurer la réponse aux besoinsdes utilisateurs (expression de besoin et cahier des charges)et le choix du prestataire constituent des étapes clés pourlimiter tout débordement sur un projet à venir. Vous devrez yporter une attention particulière.Les étapes Risque(s)Besoin, cahier des Le recueil des besoins, les entretiens avec lescharges utilisateurs ou les clients (surtout si lon est sur un business model web) sont indispensables. Le risque est de rédiger un document complexe et pas assez complet. Si vous organisez une consultation et que vous navez pas de compétences techniques, laissez l’opportunité au prestataire de concevoir la solution technique la plus adaptée et de répondre avec les technologies quil maîtrise le mieux. Cependant, ne vous désintéressez pas de la technique. Ne pas maîtriser cet aspect est très dangereux. Vouloir trop de fonctionnalités est parfois risqué. Commencez petit, avec les fonctionnalités indispensables. Plus vous élargirez le périmètre plus le projet sera difficile à gérer. [cf. #1 - La peur du « pas assez » ou le périmètre à la dérive] Le lotissement de la solution doit être logique et compréhensible. Lotir ne veut pas dire construire des briques non fonctionnelles 7
    • Choix du prestataire Ne consultez pas un seul prestataire (et surtout si cest un de vos amis). Mais n’en consultez pas trop non plus. Un trop grand nombre de réponses ne vous permettrait pas de les traiter correctement. Si le prix proposé par le prestataire est significativement peu élevé, soit le périmètre du projet a été sous-estimé, soit le prestataire propose un prix hameçon. [cf. #2 - Le prix hameçon] Les plannings doivent être réalistes. Ils ne respectent pas forcément vos attentes. Dans la réponse du prestataire, vous devez trouver les éléments qui justifient comment tenir (ou pas) le planning. Il est nécessaire de finaliser le montage du projet avant le démarrage, cest-à-dire éclaircir les points les plus compliqués trop souvent négligés (migration, intégration avec un système tiers etc.). Démarrer un projet sans contrat ou avec un contrat mal ficelé est très dangereux. Il risque de vous manquer des éléments fondamentaux tels que la propriété des développements par exemple.Conception fonctionnelle Ne laissez pas démarrer un projet (sauf pour unet technique périmètre très restreint) sans avoir validé et donc parfaitement compris les spécifications fonctionnelles. Les spécifications sont le gage de la bonne compréhension du projet, le développement sera la résultante de ces documents.Développements Des points d’avancement doivent être réalisés pour vous assurer de la bonne tenue du projet. Un retard peut représenter un risque technique quant à la compétence des architectes /développeurs de la solution. [cf. #3 – Mesurer plutôt que supposer] 8
    • Développements (suite) L’information doit être transmise de façon régulière, les bonnes nouvelles comme les moins bonnes. Ces points doivent détailler les risques et la manière de les gérer. L’intégration doit permettre au prestataire de valider techniquement la solution Une période de développement trop longue sans implication des utilisateurs est problématique. Il est nécessaire de parer ce risque en prévoyant des recettes intermédiaires. [cf. #4 – Leffet tunnel]Mise en place de la Impliquez-vous dans la recette de votre projet.solution Réalisez des cahiers de tests, créez des jeux de données pour tester les éléments clés de votre projet [cf. #5 – Le nombre danomalies] Le dimensionnement et les environnements doivent permettre une utilisation optimale de lapplication (gestion des serveurs, de l’infrastructure réseau, etc.) Il vaut mieux séparer les développements de la production (partie du travail qui consiste à mettre en place les serveurs, les environnements, gérer les sauvegardes etc.).
    • #1 - La peur du « pas assez » ou le périmètre à ladériveLa peur du "pas assez" est un symptôme fréquent. Dèslorigine du projet, le client définit un périmètre très vaste ouexprime des besoins de plus en plus complexes au fur et àmesure du projet.Ce cas est fréquent lorsque le client souhaite lancer unenouvelle activité. Proposer de nombreuses fonctionnalitésdonne limpression rassurante doffrir un service plus completau client final. Dans la réalité, cest souvent linverse. Il fautdéfinir le périmètre le plus petit possible, tester rapidement etredéfinir le besoin en utilisant les retours utilisateurs ou bêtatesteurs ("Pave the cow path").Définir un périmètre très vaste donne aussi limpressiontrompeuse de coûter moins cher quun développement enplusieurs étapes. Cela ne reste quun leurre. Au final, si denombreuses fonctionnalités ne servent pas, le coût de cesdéveloppements inutiles et de leffort nécessaire pour lesproduire peuvent mener le projet vers léchec.La dérive dun périmètre peut aussi être attribuée à unemauvaise gestion de projet. Un prestataire en mauvaiseposition, comme par exemple dans le cas dun retardimportant ou dun problème de ressources, peut accepterdes développements complémentaires en espérantconserver de bonnes relations avec son client. Il lui rend unmauvais service. En cumulant retard et nouveauxdéveloppements, le projet risque dêtre encore plus long àfinaliser. 10
    • #2 - Le prix hameçonLe prix proposé par le prestataire est volontairement bas afinde "hameçonner" le client. Un prestataire minimisevolontairement le prix de la prestation afin de remporter lemarché.Au fil du projet, deux situations se présenteront:• Les développements continuent car vous acceptez de nombreux avenants• Le projet est bloqué car vous ne souhaitez pas (ou ne pouvez pas) continuer à payer.Ce "faux prix" peut fortement dégrader la relation que vousentretenez avec votre prestataire à mesure que le projetavance.Il est cependant nécessaire de faire la différence entre unacte délibéré (un prestataire qui hameçonne un client) et unpérimètre qui évolue et grandit anormalement en cours deroute (là, cest un peu la faute du donneur dordre).#3 - Mesurer plutôt que supposerIl est important de mettre en œuvre, dès le démarrage, undispositif de gouvernance permettant de mesurerlavancement, gérer les risques, darbitrer les évolutions.Ces mesures : temps consommé, avancement etc. doiventpermettre de fournir à lensemble de léquipe un avis objectifsur létat de votre projet. Ils permettent de mettre en œuvredes plan dactions pour gérer certains risques ou re-planifiercertaines parties du projet. 11
    • # 4 - Leffet tunnelLeffet tunnel consiste à développer pendant une longuepériode sans faire intervenir les utilisateurs.La solution développée risque, in fine, de ne pas conveniraux besoins/souhaits des utilisateurs. La recette, longue etdonc fastidieuse, risque alors d’être bâclée, les utilisateurs nedisposant pas forcément du temps nécessaire pour la faireaboutir.#5 - Le nombre danomaliesVoilà une question qui revient souvent : est-ce quun nombreimportant danomalies durant la phase de recette indiquequun projet est en train de se planter ?Dans la plupart des cas, non ! Plus le nombre danomalies estimportant, plus vos utilisateurs testent la solution. Cest lorsquela solution nest pas assez testée que lon peut se planter.Donc, de manière contre-intuitive, cet indicateur est plutôtun facteur de qualité.La première recette technique doit avoir permis de régler laplupart des anomalies de base. Si cela n’est pas le cas, unrecadrage peut s’avérer nécessaire pour éviter lépuisementdes utilisateurs en cours de recette.Lautre nuance que lon peut apporter est de déterminer siles corrections sont efficaces. Des problèmes liés auxperformances qui ne peuvent être corrigés indiquent peut-être des problèmes importants liés à la conception. 12
    • Le diagnostic est sans appel : votre projet est planté. Pas depanique, TheCodingMachine vous apporte des solutions !Poser le bon diagnostic résout une grande partie duproblème, car une fois que les problèmes sont identifiés, il estpossible de mettre en place un plan d’actions efficace.Pour garantir un résultat fiable et sérieux, solliciter une sociétéextérieure reste, à notre avis, la meilleure option (si vouschoisissez cette solution, nhésitez pas à nous appeler). Car latoute première étape consiste à se débarrasser desproblèmes périphériques qui accompagnent inévitablementla dérive d’un projet et parasitent notre vision. Faire appel àun tiers qui est indépendant et sans a priori permet dedépassionner le débat.Limportance du contexteRéussir le sauvetage dun projet nécessite de plonger aucœur du problème afin de dresser un tableau objectif delétat du projet. Quels sont les problèmes ? Peuvent-ils êtrerésolus rapidement ? Par qui et de quelle manière ?Les solutions dépendent étroitement de létat du projet : leprojet est-il encore en développement ou bien enproduction. Elles dépendent aussi de la nature desproblèmes : est-ce un problème technique ? Un problèmeconcernant le périmètre ? Ces solutions dépendentévidemment de la taille du projet. Plus un projet est petit,plus il est simple de le reprendre depuis le début. 14
    • Méthode 1 : Ne pas avoir peur … de supprimer leproblèmeSi les problèmes ont une origine technique, lapplicationdéveloppée a peu de chance dêtre "sauvée". Corriger deserreurs graves de conception de larchitecture est souventtrès coûteux. A budget équivalent, il vaut mieux reprendreles développements techniques "from scratch".L’analyse de l’existant doit donc être méticuleuse pour éviterde jeter une application qui pourrait être sauvée, maiségalement pour ne pas vouloir sauver cette application àtout prix et faire durer l’échec.Méthode 2 : Gérer les problèmes périphériques :quelles solutions pour gérer les problèmeshumains ?Il faut tout dabord établir un constat déchec. Cela sembleévident aux chefs de projets dont le prestataire estdémissionnaire. Pour celui qui aura un prestataire qui tentede le rassurer, lui promet daboutir et qui tente de garder unebonne relation, établir ce constat sera, en revanche, difficile.Si lapplication mérite dêtre sauvée, il est nécessaire desattaquer aux problèmes humains. Cest souvent délicat carles sentiments qui agitent les parties sont rarementbienveillants. Il est toujours douloureux de se tromper oudavoir le sentiment de sêtre fait avoir par un prestataire peuscrupuleux. Se lamenter nest pourtant pas une solution. 15
    • Impossible, malheureusement, dindiquer ici une solutionuniverselle. Nous vous recommandons bon sens etpragmatisme : êtes-vous victime de votre prestataire ou biende vous-même ? Est-ce que changer le management duprojet va vous permettre de porter un nouveau regard sur leprojet, apporter une nouvelle motivation à léquipe ? Est-ilpossible de créer un électrochoc, de déclencher une prisede conscience de la part des équipes ?Dans ce domaine, la créativité na pas de limites. Voici uneprésentation des pistes les plus évidentes et les plusefficaces.1. Le désengagement du prestataire (et son éventuelremplacement), permet souvent de voir le projet avec unœil neuf afin dévacuer les problèmes récurrents. Cedésengagement est-il souhaitable, possible ? Quels coûtssupplémentaires va-t-il engendrer ? Quels bénéfices va-t-ilrapporter ? Comment envisager la phase de transition ?2. Faire une pause, pour se remettre les idées en place et seréorganiser : Cette pause est-elle souhaitable, possible ?Combien de temps (trop risquerait de mettre fin au projet) ?Qui et comment planifier la suite du projet ? 16
    • 3. Changer les équipes peut redonner un second souffle auprojet. Les équipes usées vont être remplacées par du sangneuf. Pour cela il est nécessaire que l’image du projet ne soitpas trop dégradée afin de ne pas décourager les nouveauxcollaborateurs. Ce changement est-il souhaitable, possible ?Quelle organisation mettre en place, qui conserver ?4. Relancer les développements par étape, morceler lesproblèmes, permet d’en voir le bout et ainsi de se motiver.Peut-être est-il possible de découper le projet en sous-ensembles ? Le coût de cette réorganisation est-ilsupportable ? Les équipes sont-elles prêtes à cechangement ?
    • Méthode 3. Gérer les problèmes techniquesSi le projet peut-être sauvé, alors allons-y, n’attendons plus !Ce qui nempêche pas dintégrer méthode et rigueur à notreopération de sauvetage.Pour identifier les risques et les actions associées à la reprisede votre projet, plusieurs techniques sont envisageables.Nous vous en proposons une qui a le mérite dêtre à la foissimple à partager et facile à appliquer :Classement des risques et actions :- Impact : le coût associé à la survenance du risque. Par exemple, la chute de la base de données principale a un coût supérieur à la chute d’un serveur de mail;- Probabilité : la probabilité de survenance du problème;- Effort de correction : le coût associé à la mise en place d’un correctif;- Catégorie : la catégorie associée au risque (architecture, sécurité du code, …).XXX: Description du risque et de l’action associée Catégorie Impact: Faible/Moyen/Fort : description de l’impact Probabilité: Faible/Moyen/Fort : probabilité de survenance de l’évènement Effort de Facile/Moyen/Complexe: description des tâches Correction: nécessaires pour corriger le problème 18
    • Les actions sont ensuite placées sur un quadrant : - En abscisse: impact * probabilité; - En ordonnée: complexité de mise en place du correctif.complexe A1 A16 A10 A12 A9 A7 A17 A4 A11 A3 A15 A6 A8 A14 A5Facile A2 A13 Nice to have Critique Les actions du quadrant en bas à droite seront les actions prioritaires. On remontera progressivement alors vers la section en haut à gauche. 19
    • Les problèmes de performances passent souvent à la trappedans les projets. Ils apparaissent souvent en fin de mission, silsnont pas été anticipés, et demeurent difficilementdétectables avant la mise en production du projet.TheCodingMachine a consacré un Livre Blanc à ce sujet.Nous y avons indiqué comment analyser et traiter cesproblèmes particuliers. Vous pouvez télécharger ledocument à cette adresse : http://www.thecodingmachine.com/fr/hautes- performances-web 20
    • Les projets et les situations évoqués ici étant purement fictifs, toute ressemblance avec des projets existants ou ayant existé ne saurait être que fortuite…
    • Le projet : Dans le cadre de la dématérialisation de sescorrespondances avec ses clients, cette filiale dun acteurmajeur de la banque-assurance a demandé à unprestataire de créer un système de gestion électronique dedocuments (ou GED). Le projet comprenait lexternalisationde l’ouverture et de la numérisation du courrier, puis ladistribution du courrier sous forme dématérialisée à traversune application qui gérait les workflows de demandes client.Notre intervention : Devant les retards accumuléspendant le développement de ce projet et lesdysfonctionnements constatés, TheCodingMachine a étémandatée pour conduire un audit, analyser finementl’application et dessiner le périmètre d’un plan desauvetage.Problèmes détectés :Larchitecture de la solution avaitété très mal pensée. Les données étaient distribuées dansdeux bases de données distinctes. Le prestataire était partiavec un outil open-source et une technologie quil nemaîtrisait pas. Les temps de réponse étaient parfois difficile àsupporter pour les utilisateurs et rendaient même parfoislapplication inutilisable (avec des temps de réponse parfoissupérieurs à 5mn). Lapplication était instable, avec parfoisdes arrêts de production de plusieurs jours.Solutions apportées : Le processus de build et l’utilisationsystématique de caches et sessions ont permis de consoliderl’application sans remettre en cause les fondements del’outil. L’industrialisation des développements, la mise enplace de bonnes pratiques ainsi que le lancement de testsautomatisés pour garantir les non régressions assurent lastabilité de l’application dans la durée.Notre avis : Le coût du projet (500k€) rendait difficile unabandon pur et simple de la solution. Il aurait peut-êtremieux valu. Notre intervention aura coûté 50k€ pour rendrelapplication utilisable. 22
    • Le projet : Le client, dans le domaine de limmobilier,souhaitait proposer à ses collaborateurs un Intranet :présentation des informations, gestion des formations,reporting etc.Notre intervention : En rupture avec son ancienprestataire, le client devait montrer que son projet nétait pasen échec. Une partie de la conception a donc été reprisepour conserver le schéma relatif de base de donnéesassocié à la gestion des utilisateurs notamment.Problèmes détectés : La technologie était parfaitementinadaptée aux besoins. Inexpérience du prestataire sur cetype de projet (spécialiste des sites vitrines).Solutions apportées : Refonte du projet dans des délaisrecord avec un budget réduit: 50k€ avait déjà été dépensé,il ne restait plus que 30k€ de budget pour faire le projet. Unerallonge de 15k€ a pu être obtenue. La structure du code atotalement été revue (utilisation d’un framework MVC,utilisation de bibliothèques open source, etc.). 23
    • Le projet : Grande franchise liée à lesthétique, le clientsouhaitait proposer la vente de ses services en ligne. Cestune agence marketing qui avait remporté le projet, quellesous-traitait, pour la partie technique, à une SSII tunisienne.Avec les profonds changements apportés par la révolution,et compte tenu du manque de marge de manœuvreautorisé par le budget, le projet avait été abandonné par leprestataire.Notre intervention : Pour respecter les délais, priorité trèsforte du client, nous avons conduit le sauvetage du projet endeux temps :- nous avons épuré le périmètre pour mettre en pré-production une version testable par le client et lui permettreainsi davoir une visibilité sur les avancées du projet,- en parallèle, nous avons mené finalisé le développementdu périmètre initial.Problèmes détectés : Nous avons rapidement constatéque le projet avait été considérablement sous-estimé parlagence.Solutions apportées : L’architecture initiale (utilisation deMagento) a été conservée. En revanche, nous avonsredéveloppé ou reconfiguré l’ensemble des fonctionnalitésspécifiques (multi-boutique, thème, autres modulescomplémentaires).Notre avis : Effectuer un sauvetage de projet pour lecompte dun tiers (et non du client final) nest pas possible.La communication et le ressenti client est primordial dans cegenre de sauvetage. Il faut se positionner en frontal clientpour le rassurer au mieux. Ne pas partir avec une agence quidénigre la technique ! 24
    • Le projet : Cette société de vente par correspondance etde vente à domicile avait décidé de refondre son systèmedinformations (approvisionnement, vente, facturation, etc.).Le choix d’un prestataire off-shore et d’une organisationcomplexe (pas de communication directe, passage par untiers, etc.) avait conduit le client à utiliser en production uneapplication à moitié finie.Notre intervention : Nous avons commencé par un audittechnique de la « solution » existante (bien que peu defonctionnalités aient été abouties). Puis nous avons décidé,conjointement avec le client, d’une nouvelle organisation.Problèmes détectés : Deux problèmes majeurs ont étédétectés :1. Aucune spécification précise des fonctionnalitésn’existait, les développements avaient tous été menés au filde l’eau à partir dun document général.2. Quand les relations sont devenues tendues entre leclient et le prestataire, les développements ont étéaccélérés au détriment de la qualité technique et des règlesde codage (utilisation des outils installés).Solutions apportées : Nous sommes repartis du point leplus avancé des développements respectant les règles etstandards en essayant, au maximum, de récupérer et deréutiliser les fonctionnalités développées. Nous avons ensuiteréorganisé les développements en écrivant les spécificationsmanquantes et en estimant/priorisant au préalable chaquetâche.Notre avis : Il ne faut jamais abandonner les règles debase de la technique dans le seul but de gagner du temps.Cela s’avère souvent contre-productif pour la bonneconduite d’un projet. Le projet en serait, au mieux, tropcompliqué à maintenir, et, dans le pire des scenarii,impossible à faire aboutir. 25
    • Ces méthodes ne sappliquent pas les unes isolées des autresmais bien souvent de front. On peut estimer simplement sicela vaut la peine de sauver lapplication en établissant lequadrant de gestion des problèmes techniques. Cequadrant peut aussi être utile pour diagnostiquerrationnellement et donc accepter plus facilement que leprojet est vraiment en panne.Notre expérience nous a montré que la plupart desproblèmes peuvent trouver une solution technique même sielle est parfois coûteuse. Le point le plus délicat à gérer sesitue bien souvent dans les relations entre les partiesprenantes. Des relations conflictuelles induites par deséchecs accumulés sur un projet savèrent parfois difficiles àneutraliser. Il est pourtant important de dépassionner lesdébats pour permettre à des décisions réfléchies etrationnelles démerger, motivées par la réussite finale duprojet.Même sil est compliqué de généraliser ce type deproblématique, nous espérons que ce livre blanc vous auraau moins donné un peu de courage si votre projet est àlarrêt, en panne ou même carrément raté.Evidemment, de nombreux éléments mériteraient dêtreapprofondis. Nhésitez pas à nous contacter si vous souhaitezen discuter. 26
    • The licensor permits others to copy, distribute, display, and perform the work. In return, licenses must give the original author credit. The licensor permits others to copy, distribute, display, and perform the work. In return,licenses may not use the work for commercial purposes -- unless they get the licensors permission. 27