Stratégie de milieu de partie

Transcription

1 CHAPITRE 14 Stratégie de milieu de partie

2 278 Chapitre 14 Stratégie de milieu de partie Stratégie de milieu de partie, le titre de ce chapitre vient du jeu d échec. On distingue trois phases essentielles dans une partie d échecs : le début de partie (l ouverture), le milieu de partie et la fin de partie (la finale). Le milieu de partie commence lorsque les deux joueurs ont déployé leurs pièces sur l échiquier, en mettant par exemple en œuvre une ouverture particulière («Ruy Lopez», «défense sicilienne», etc.), et lorsque leur stratégie générale devient «évidente». La plupart des coups joués relèvent du milieu de partie. Les fins de partie concluent une partie : il reste en général peu de pièces sur l échiquier, et les joueurs appliquent des méthodes connues (les finales) pour mettre l adversaire mat (ou pour éviter de l être). Ce chapitre se concentre sur le «milieu de partie» d un projet. Le chapitre suivant portera sur la «fin de partie» du projet. «La chance ne sourit qu aux esprits bien préparés.» Louis Pasteur Le milieu de partie désigne la phase du projet durant laquelle celui-ci est dans son régime de croisière : certaines activités marchent bien, d autres moins, des problèmes ont été découverts et résolus, mais d autres restent à venir. Le milieu de partie est un vrai défi au sens où beaucoup de choses peuvent se produire au même moment, et où il est parfois difficile d identifier clairement ce qui marche bien et ce qui ne marche pas. Le terme brouillard de la guerre utilisé par Clausewitz (1) en référence au sentiment de chaos que l on éprouve au cœur du champ de bataille s applique aussi au milieu de partie. Le travail de développement plonge en général l équipe dans une sorte de brouillard qui peut provoquer sa perte si elle est inexpérimentée. Les responsables de l équipe ont pour mission de faire en sorte que le groupe traverse le milieu de partie avec succès, qu il sorte indemne de cette zone sans visibilité, et qu il puisse s engager vers les horizons dégagés de la fin de partie. Vu sous une forme très simplifiée, le milieu et la fin de partie sont essentiellement des phases de maintenance de haut niveau (2) : 1. Si tout s est bien passé durant la première journée du projet, l objectif est de faire en sorte que le jour suivant se passe aussi bien. 2. Si quelque chose se passe mal, le chef de projet doit identifier la nature du problème et agir pour le résoudre, afin que le projet continue sur de bonnes bases. Ce travail de «maintenance» du projet peut durer quelques heures, quelques jours ou quelques semaines. 3. Il faut poursuivre ce travail jusqu à la fin du projet. Le défi manifeste est que même sous cet angle simpliste, il existe une multitude de sources de problèmes venant compromettre le bon fonctionnement d un projet. Pire même, l identification d un problème doit être réalisée en un temps limité et sa résolution mise en œuvre en un temps encore plus restreint. Ce travail de résolution s ajoute par ailleurs à tout ce que vous devez faire pour que ce qui marche bien dans le projet continue à bien marcher. Pour toutes ces raisons (et bien d autres encore), l énergie dépensée et le niveau de stress sont très élevés en milieu et en fin de partie. L équipe progresse de plus en plus vite et les marges d erreurs s amenuisent jour après jour. Lorsque la fin de partie se profile à l horizon, quelqu un doit ralentir progressivement le rythme du groupe, afin que le projet se termine bien.

3 Voler devant l avion 279 Dans ce chapitre et dans le suivant, je m appuierai sur les hypothèses méthodologiques que j ai développées dans le chapitre 2, ces conseils s appliquant quelle que soit la méthodologie employée par vous. Une relecture rapide de la section Armes miraculeuses et méthodologies, p. 26, peut s imposer avant de poursuivre la lecture de ce chapitre. Bien que le milieu de partie soit l objet de ce chapitre et que le chapitre suivant soit centré sur les fins de partie, il existe de nombreux points communs sur la façon d appliquer les techniques de «maintenance» du projet : par exemple, une fin de partie pour une phase donnée du projet peut être assimilée à un élément de milieu de partie du projet pris dans son ensemble. Ne soyez donc pas surpris s il m arrive de passer du milieu de partie à la fin de partie et réciproquement. NOTE La présentation du milieu et de la fin de partie d un projet présuppose que celui-ci est réalisé dans une structure de grande taille. Si vous constatez que certaines questions ou que certains sujets ne s appliquent pas dans votre cas particulier, parce que vous travaillez dans un contexte et à une échelle différents, vous pouvez bien entendu omettre ce qui suit. Je n ai pas la prétention de croire que tout ce qui est écrit ici s applique à tous les projets. Cependant, mon but est bien de vous apporter des éléments qui vous seront utiles pour un projet ultérieur. De nombreuses questions et de nombreux points de vue s avèreront utiles à long terme, même si certains d entre eux ne s appliquent pas dans le contexte actuel de votre activité. Voler devant l avion Piloter une organisation complexe, telle qu une équipe projet, nécessite bien plus qu une main ferme. Plus le groupe à piloter est important, plus il est difficile de changer d orientation ou de faire des corrections de trajectoire. On peut comparer le pilotage d un groupe projet à celui d une poids lourd ou d un avion cargo. En particulier, les pilotes novices ont tendance à sous-estimer le temps nécessaire à un changement de direction : il faut du temps pour qu une décision prise par les responsables de l équipe ait des effets visibles au niveau du programmeur de base. Comme on peut le voir dans la figure 14-1, les corrections de trajectoire appliquées à un projet ou à un poids lourd dépendent de façon critique de l impulsion donnée pour changer de trajectoire et des autres forces subies par le système. Nombreux sont ceux, en particulier parmi les personnes peu expérimentées, qui jugent mal de l impulsion à donner pour obtenir l effet escompté. Souvent, leur erreur provient du fait qu ils ne comprennent pas toutes les forces qui contribuent à la dynamique d ensemble de l objet qu ils pilotent (poids lourd, avion, projet). Ils sont un peu dans la situation de quelqu un qui apprend à conduire sur la glace, et qui fait un tête-à-queue parce qu il ne contre-braque pas bien (trop ou pas assez) et parce qu il y a trop de forces en jeu dans la dynamique du véhicule. Lorsque ceux qui ont la responsabilité de garder les choses sous contrôle perdent effectivement le contrôle des opérations, leur réaction est souvent la panique, même s ils l admettent rarement. On constate d ailleurs souvent que les personnes qui basculent en mode panique refusent d admettre qu elles sont sous son emprise. La première réaction devrait être d engager une action corrective courageuse en réponse

4 280 Chapitre 14 Stratégie de milieu de partie directe au problème qui survient. Cependant, comme ces personnes ne comprennent pas l ensemble des forces subies par le système qu elles pilotent, cette action corrective est en général bien trop forte, de la même façon qu un pilote sur glace inexpérimenté a tendance à trop contre-braquer si son véhicule part en travers (voir la figure 14-2). Le temps qu elles réalisent ce qu elles ont fait, une autre action corrective s impose (le véhicule part en travers dans l autre sens à cause du contre-braquage excessif) : elles l effectuent immédiatement, probablement avec excès, si bien que d autres problèmes surviennent et qu elles perdent de plus en plus le contrôle du système. Figure Une même action peut avoir des résultats différents, en fonction de l inertie du projet (résistance à changer de direction). Figure À la grande consternation de ceux qui sont supposés garder un projet sous contrôle, l application d actions correctives sur des systèmes soumis à des forces inconnues peut avoir des effets imprédictibles et souvent affolants. Le fait est que lorsqu un avion, une automobile ou un projet devient instable, il est extrêmement difficile de le contrôler, même pour un pilote très qualifié et très expérimenté. Les petites équipes projets ont certainement une inertie plus faible et elles réagissent plus vite à des corrections de trajectoire, mais il faut tout de même tenir compte d un certain temps de réaction. L instabilité du système fait que la plupart des actions correctives ont des effets imprédictibles car de nombreuses variables du système peuvent changer très rapidement. Le bon chef de projet doit donc se placer en position d éclaireur par rapport au projet : il doit avoir une vision anticipatrice lui permettant d appliquer les forces nécessaires pour d éviter les écueils. Les pilotes de chasse ont une expression qui signifie qu un pilote n anticipe pas : on dit qu il vole derrière son avion, au sens où il n anticipe plus les réactions de son appareil. Le pilote subit alors les forces qui s exercent sur son avion sans pouvoir les éviter. Le pilotage d un projet ressemble un peu à celui d un avion de chasse : il faut

5 Voler devant l avion 281 savoir maîtriser les forces qui s exercent sur le système piloté et leurs interactions. Un projet et un avion de chasse sont des systèmes non linéaires : on entend par là que la modification d une variable du système (vitesse, assiette, planification, objectifs) peut avoir des conséquences multiples et beaucoup plus fortes que prévu car elles sont amplifiées par différents facteurs, humains ou technologiques. J insiste sur le point suivant : même pour un projet stable et à très forte dynamique, la complexité technologique et humaine fait qu un acte de management peut avoir des conséquences inattendues. Parfois, ces conséquences ne deviendront visibles qu au bout de plusieurs jours ou de plusieurs semaines, mais lorsqu elles apparaissent au grand jour, il est souvent tentant de croire que leurs causes sont plus récentes : la résolution du problème n en est que plus difficile. Faites des vérifications d intégrité Pour les chefs de projet, il existe une méthode leur permettant de ne pas «voler derrière l avion» : il faut procéder à des vérifications d intégrité quotidiennes. Les programmeurs emploient le terme de vérification d intégrité (sanity check en anglais) pour désigner des conditions qui doivent impérativement être satisfaites lors de l exécution de leur code (en langage C, on s appuie sur la fonction assert()). Ce concept est particulièrement intéressant car il s attaque aux hypothèses implicites faites au sujet du code. Si dans celui-ci, une vérification d intégrité montre qu une condition n est pas satisfaite, alors il faut trouver la raison pour laquelle le code ne s est pas comporté comme prévu. Si vous voulez «voler devant l avion» (et non derrière), vous devez constamment vous assurer que les conditions qui doivent être satisfaites par le projet le sont bien en réalité. S il s avère que l une d entre elles n est plus satisfaite, vous savez immédiatement où concentrer votre attention. La difficulté réside dans la grande variété des vérifications d intégrité, qui peuvent porter sur les objectifs, la planification, les technologies, le moral du groupe, la concurrence, le budget et la politique : il est impossible de tout vérifier à tout instant, même si certains manageurs paranoïaques tentent de le faire. Il ne faut surtout pas vous lancer dans des campagnes quotidiennes de vérification portant sur des dizaines de points particuliers. Plus vous effectuez de vérifications concernant des conditions généralement satisfaites, moins vous faites confiance à l équipe et plus vous perdez votre temps. Il faut connaître l état d intégrité du projet sans perturber le projet luimême. Trois types de questions permettent d atteindre cet objectif : les questions tactiques, les questions stratégiques et les évaluations de l état d avancement du projet, qui doivent être traitées de façon transparente pour l équipe. Cette dernière question sera développée dans le prochain chapitre. Concentrons-nous ici sur les questions tactiques et les questions stratégiques comme vérifications d intégrité. Le principe général en est très simple : constituez une liste de questions qui vous permettront de «voler devant l avion», et faites en sorte que poser ces questions devienne un rituel. Posez les questions tactiques une fois par jour et les questions stratégiques une fois par semaine. Vous pouvez agir seul ou solliciter plusieurs membres de l équipe que vous impliquerez dans ce processus de questionnement périodique. Vous devriez aussi encourager tous les membres de l équipe, en particulier

6 282 Chapitre 14 Stratégie de milieu de partie ceux qui sont expérimentés et chevronnés, à procéder à leur niveau à ces vérifications d intégrité, et à confronter leurs conclusions aux vôtres. Pour ma part, je procédais de la façon suivante : je bloquais 30 minutes par semaine dans mon emploi du temps. Je fermais la porte de mon bureau et passais en revue ma liste de questions. Le plus souvent, quelques minutes suffisaient. Il m était alors possible de réajuster mes priorités du jour ou celles de l équipe, en fonction des réponses obtenues. Dans certaines équipes, j ai fait entrer ce type de questionnement dans la culture du groupe, et j organisais des formes simplifiées de questionnement durant les réunions d équipe. Questions tactiques (quotidiennes) pour voler devant l avion Quels sont nos objectifs et nos engagements? Sont-ils corrects? Chaque jour, il y a tellement de travail à faire que l on peut facilement perdre de vue les objectifs du projet. Se les remémorer quotidiennement permet de rester concentré sur les enjeux réels et sur les priorités. De façon plus importante pour l équipe, si les objectifs officiels ne coïncident pas avec les objectifs réels du projet (par exemple, à cause d une lubie d un vice-président) ou avec ceux de l équipe (ses membres préférant orienter leurs efforts vers les tâches les plus amusantes à réaliser), alors les objectifs ne sont pas corrects. S ils ne le sont pas, l équipe est dans une situation de conflit, et différents symptômes vont apparaître. N attendez pas leur apparition si vous identifiez des conflits qui vont fatalement dégénérer. Sachez voler devant l avion, en particulier pour traiter des questions ayant un impact direct sur les objectifs. Notre travail du jour contribue-t-il à nos objectifs? Examinez les tâches élémentaires à réaliser aujourd hui, demain et dans la semaine à venir. Ces tâches contribuent-elles bien à l atteinte des objectifs ou à la satisfaction des engagements pris? Si la réponse est non, le projet est en train de dériver. En vous appuyant sur les programmeurs pertinents, rappelez au groupe les objectifs et la nécessité d un travail qui contribue directement au succès du projet. Procédez ensuite aux ajustements nécessaires, sur les objectifs, sur le travail à réaliser ou sur les deux à la fois. Cette action est souvent désignée sous le nom de réalignement du travail, car il s agit bien de faire en sorte que toutes les tâches élémentaires avancent exactement dans la même direction. Les tâches élémentaires sont-elles réalisées de façon satisfisante vis-à-vis des besoins et des scénarios d utilisation? Il existe mille façons de réaliser une tâche élémentaire ne répondant pas à l esprit et à l intention initiale des concepteurs. Toute bonne conception et toute bonne spécification sera définie de telle façon que la tâche élémentaire réalisée satisfasse pleinement la demande de l utilisateur final. Cependant, les subtilités de l ergonomie, des besoins économiques, de l intégration des composants et de l interface visuelle sont souvent perdues de vue par les programmeurs qui ont souvent une quinzaine de tâches élémentaires à réaliser. Si un concepteur spécialisé dans les interfaces utilisateur (ou tout autre expert) est présent, il peut procéder quotidiennement à des revues de code pour s assurer que les tâches élémentaires non seulement répondent au besoin élémentaire visé, mais aussi s intègrent harmonieusement à l application.

7 Voler devant l avion 283 Questions stratégiques (hebdomadaires ou mensuelles) pour voler devant l avion Les questions suivantes sont souvent traitées durant les réunions de l encadrement supérieur du projet. Si des revues hebdomadaires ou mensuelles de l état du projet sont organisées, ce sont ces questions sur lesquelles doit se concentrer l encadrement, même si un chef de projet peut adopter la même approche, à titre individuel, lorsque son champ d action est plus restreint. Quelle est la probabilité pour que nous atteignions la prochaine date clé, le prochain jalon, ou la date de la prochaine livraison en respectant le niveau de qualité demandé? Les choses ont pu évoluer depuis les dernières estimations faites à propos du projet. Quel est le sentiment des membres du groupe à propos de leur travail, maintenant qu ils sont plongés dedans? Selon vous et selon vos collaborateurs clés, quelle est la probabilité d atteindre les objectifs de la prochaine date clé : 100%, 90%, 50%? Soyez honnêtes dans votre estimation. Soyez attentif vis-à-vis de votre équipe : n en faites pas un défi ou une source de culpabilité en cas d échec. Ne laissez pas votre équipe supposer que vous mettez en doute ses estimations et que vous lui demandez de travailler plus dur. Faites-lui bien comprendre que vous voulez des estimations honnêtes. Que ces réponses soient plus ou moins fiables et quel qu en soit le responsable, il est clair qu il faut prendre en compte les doutes exprimés par le groupe : vous devez être conscient de ces doutes et tenter d en comprendre les causes. À quels ajustements faut-il procéder pour faire augmenter cette probabilité? Si vous êtes honnête avec vous-même, votre estimation ne sera pratiquement jamais égale à 100%. Vous devrez donc immédiatement vous demander comment augmenter cette probabilité. Faut-il moins de réunions ou de circonstances venant interrompre le déroulement du travail? Faut-il prendre des décisions plus vite, supprimer des fonctionnalités, prendre de meilleures décisions, clarifier les objectifs, faire de meilleures revues de code? Questionnez ceux qui sont en prise directe sur le travail quotidien. La recherche de ces ajustements doit être une priorité pour vous et pour toute votre équipe. Comment procéder aux ajustements en toute sécurité et de façon cloisonnée? Pensez en chirurgien. Quel est l ensemble minimal d actions permettant de résoudre un problème avec succès et d augmenter la probabilité de réussite? Un simple appel téléphonique? Un courriel? Rendre visible une décision importante? Congédier quelqu un? Ne craignez pas de prendre une grande décision si elle fait partie de l ensemble minimal d actions à entreprendre. Si une action chirurgicale est impossible, pensez en termes holistiques. Faut-il ajuster les objectifs ou le processus d intégration du code? Quel processus ou quelle attitude faut-il ajuster pour résoudre un symptôme et sa cause (voir la section suivante, Agir en toute sécurité.) Quels sont les risques les plus élevés ou les plus probables encourus aujourd hui, dans la semaine ou dans le mois à venir? Si ces risques se réalisent, quelles seront nos contingences? La simple identification des trois problèmes les plus problables ou les plus dangereux est un grand pas vers leur prévention. Vous vous mettez ainsi en état d alerte, et vous êtes plus sensible aux signaux avant-coureurs de ces problèmes. Même si vous ne passez que cinq à dix minutes par semaine à lister les risques potentiels et à esquisser des réponses en cas de problème, vous

8 284 Chapitre 14 Stratégie de milieu de partie volerez tout de même devant l avion. Cette façon d anticiper ne coûte presque rien : quelques minutes par semaine qui peuvent économiser des jours de travail. Le contexte du projet a-t-il changé à mon insu? Mon vice-président ou mon partenaire économique sont-ils encore bien en place? Ses objectifs ont-ils changé? Certains acteurs clés de mon équipe sont-ils inquiets à propos d un problème potentiel dont je ne suis pas conscient et qui peut avoir un impact sur le projet? Nos concurrents ont-ils engagé des actions qui nécessitent une réaction de notre part? Nos partenaires et ceux dont nous dépendons sont-ils toujours sur la bonne voie? Existe-t-il aujourd hui un dysfonctionnement qui ne sera visible que demain dans ses effets? Quelques coups de téléphones rapides et quelques discussions dans les couloirs permettent de répondre à ces questions. Néanmoins, n agissez pas en micro-manageur ou en paranoïaque, et n inquiétez pas les autres par vos questions. Faites de ces «enquêtes de terrain» une démarche habituelle et banale dans le groupe, et encouragez les autres à agir de même à leur niveau. Cependant, quel que soit votre degré d expérience, de préparation ou d agilité intellectuelle, vous volerez parfois derrière l avion. Comprenez bien la différence entre avoir un programme de travail chargé et voler derrière l avion. Vous aurez souvent le sentiment d avoir beaucoup de travail et trop peu de temps pous le réaliser. Si vous avez constitué vos listes de priorités (voir le chapitre 13), vous réaliserez que de nombreuses tâches attendent que vous leur consacriez du temps. En revanche, si vous volez derrière l avion, vous vous sentirez paralysé, déprimé, voire apathique. Vous aurez le sentiment de ne pas pouvoir remettre le projet sous contrôle, même si vous passez vos nuits au bureau. Voici trois dernières remarques sur ce sujet : 1. Lorsque vous volez derrière l avion, prenez-en conscience le plus vite possible. Rappelez-vous que toute planification repose sur des probabilités. Etes-vous certain de pouvoir finaliser le travail planifié pour la semaine à venir? Sûr à 80%, à 50%? Si la probabilité est de 50%, vous volez derrière l avion. Votre marge d erreur est faible et vous allez commettre des erreurs si vous n en avez pas déjà commises. 2. Quand les autres volent derrière leur avion, offrez votre aide. Ne niez pas le problème : dites-leur qu ils ont un problème et que vous êtes prêt à les aider. Dans votre sphère d influence, ne laissez personne s auto-flageller ou paniquer. Restez calme, aidez les autres à rester calme, et travaillez ensemble pour voler à nouveau devant l avion. 3. N hésitez pas à solliciter l aide de vos pairs ou de vos supérieurs. Il peut s agir de la seule façon de récupérer le contrôle de la situation et de voler à nouveau devant l avion. Grâce à leur aide, utilisez au mieux votre temps et celui de l équipe en établissant des priorités, en répartissant au mieux le travail et en faisant baisser la pression. Ne refusez pas la main tendue. Sollicitez-la si aucune main ne vous est tendue. Pour savoir comment gérer les situations de crise, vous pourrez vous référer au chapitre 11.

9 Agir en toute sécurité 285 Agir en toute sécurité Durant le milieu de partie, la plupart des tâches assurées par un chef de projet sont des formes plus restreintes et plus spécialisées de ce qu il a fait durant la conception ou la planification. Si un besoin a été omis et s il doit être intégré a posteriori, le processus de définition et de documentation est une répétition de ce qui a été fait durant la démarche d analyse des besoins : compréhension des besoins, identification de concessions éventuelles, définition et identification des priorités. Si quelque chose a été oublié durant les spécifications, le processus de résolution est une répétition de ce qui a été fait durant la phase de spécification. Peu de nouvelles compétences sont utilisées durant le milieu de partie. Elles sont simplement utilisées de façon plus limitée et plus rapidement que dans les phases antérieures du projet. Cependant, travailler plus vite est toujours risqué. Agir en toute sécurité durant le milieu de partie consiste à faire en sorte que cette action ne débouche pas sur une perturbation involontaire de l intégrité du projet. Agir en toute sécurité est difficile car le projet est sensible à toute modification durant le milieu de partie. Les choses sont déjà en mouvement et de nombreuses décisions ont déjà été prises, ce qui peut engendrer un conflit avec une nouvelle action. Par exemple, si en plein milieu de la construction de votre maison, vous décidez de changer sa forme, de nombreux matériaux et de nombreux travaux déjà terminés deviendront inutiles, et il faudra peut-être acheter de nouveaux matériaux et procéder à de nouveaux travaux, non prévus initialement et qui devront être réalisés dans l urgence. Il faut de l expérience pour savoir comment modifier l expression d un besoin, supprimer une fonctionnalité ou modifier une partie de la conception, lorsque cela a un impact technique et organisationnel sur l équipe. L objectif d un chef de projet doit être d agir en toute sécurité. Il lui faut agir et se comporter afin que le projet soit toujours orienté vers des objectifs qui peuvent évoluer avec le temps, tout en causant un minimum de dommages au projet. Les dégâts sont inévitables et il faut d ailleurs s y préparer. Cependant, plus les actions d un chef de projet sont efficaces, moins il y aura d effets collatéraux. Comme le montre la figure 14-3, plus un projet est avancé, plus il est difficile d agir en toute sécurité, car une action a d autant plus de chances d avoir des conséquences coûteuses : la probabilité pour qu un travail déjà réalisé doive être repris pour modification ou intégralement recommencé est de plus en plus élevée. Ces conséquences coûteuses peuvent faire l objet de certaines garanties, mais pour agir ainsi en toute sécurité, il faut avoir réfléchi préalablement au coût, avant de prendre la décision. Figure Procéder à des ajustements est d autant plus difficile qu ils sont importants ou tardifs. Lorsqu un ajustement sur une fonctionnalité, sur un objectif ou sur l expression d un besoin est envisagé durant le milieu de partie, vous devez vous poser cinq questions :

10 286 Chapitre 14 Stratégie de milieu de partie 1. Quel problème tentons-nous de résoudre? La résolution de ce problème est-elle indispensable au succès du projet? Devons-nous résoudre ce problème d ici à la prochaine date clé? Pouvons-nous simplement continuer à progresser sans résoudre immédiatement ce problème? 2. Ce problème est-il un symptôme ou une cause? Résoudre seulement le symptôme est-il acceptable? 3. Connaissons-nous suffisamment bien l état du code pour pouvoir prédire l impact exact d une action corrective? 4. Le coût de l ajustement, incluant le temps nécessaire à la compréhension de l état du code et de l équipe, l examen des alternatives et l obtention du soutien politique pour la prise de décision, sera-t-il compensé par les bénéfices apportés par cet ajustement? Identifier et résoudre le problème peut coûter plus cher que résoudre les symptômes ou simplement vivre avec eux. 5. Un ajustement peut-il déclencher de nouveaux problèmes venant annuler le bénéfice de sa mise en œuvre? La prise de décision repose sur le processus et la stratégie présentés au chapitre 8. Toute action relative à la conception, aux spécifications ou à la communication, et toute action politique reposent sur les tactiques discutées respectivement dans les chapitres 6, 7, 9 et 16. L attitude à tenir et l approche à suivre sont les mêmes, à ceci près que les délais et les marges d erreur sont bien plus faibles. La nécessité d étudier les options possibles en très peu de temps a deux conséquences. En premier lieu, il faut s appuyer sur les enseignements tirés des efforts déployés antérieurement, dans le cadre du projet, pour la conception et le prototypage. Certains ajustements envisagés en milieu de partie ont déjà pu être étudiés lors de ces phases préparatoires : il faut donc exploiter ces études antérieures dans le contexte du milieu de partie. En second lieu, il faut être défensif. Moins vous en savez, plus les risques dont vous n avez pas conscience sont nombreux. Plus le projet est avancé, plus il faut placer la barre haut pour déclencher une action corrective. Rompre des engagements Pour agir en toute sécurité, il faut aussi tenir compte des engagements pris par les manageurs vis-à-vis de leur équipe. Comme nous l avons vu dans le chapitre 12, les manageurs gagnent la confiance de leur équipe en respectant leurs engagements. Le document de vision, l expression des besoins et la planification sont des formes d engagement entre le management, les chefs d équipe, les programmeurs et le client. Toute action entreprise en milieu de partie peut invalider des engagements que vous avez pris antérieurement. Pour maintenir la confiance avec votre équipe malgré ces actions, vous devez avoir respecté vos engagements antérieurs. Comme l a écrit Humphrey, «si un changement a un impact sur les engagements, une notification préalable doit être faite et un nouvel engagement doit être négocié.» Les changements sont autorisés, mais il faut y procéder en respectant un processus de négociation similaire à celui qui a débouché sur les engagements initiaux, qu il s agisse de la vision, des besoins ou de la planification. Il n est pas nécessaire de signer des documents ou d organiser des grandes réunions, mais vous devez informer les autres de l évolution de ces engagements et les impliquer dans le processus décisionnel concernant la mise en place de ce changement.

11 Le pipeline de codage 287 Si vous demandez à votre équipe de jeter à la poubelle deux semaines de travail, tenez compte de ce coût dans le processus décisionnel. Expliquez à votre équipe le raisonnement qui justifie ce changement et qui démontre qu il est bon pour le projet, ainsi que tous les facteurs qui ont pesé dans la décision. Si possible, impliquez des membres de l équipe dans les discussions avant la prise de décision finale. N ayez pas peur d effectuer des changements. Le changement est une bonne chose et c est une chose inévitable. Il existe cependant différents types de changement, et différentes façons de le conduire au sein de l équipe. Si vous devez changer radicalement d orientation, les méthodes utilisées pour convaincre l équipe sont les mêmes que celles qui ont été employées pour l emmener dans la direction initiale. Vous devrez cependant agir plus vite et de façon moins formelle (voir les chapitres 3, 4, 11 et 12 pour revoir les méthodes de conduite du changement). Le pipeline de codage Sur un plan pragmatique, le milieu de partie consiste essentiellement à développer du code. C est en écrivant des lignes de code que le projet avance (les fonctionnalités exotiques, les optimisations non nécessaires, etc., ne font pas avancer le projet). Tout le travail de conception et de planification qui a précédé l écriture de code a pour but de mettre en place la séquence de travail la plus courte et la plus efficace possible : cette séquence est appelée pipeline de codage. Le travail du chef de projet est d assurer que le pipeline de codage fonctionne sans à-coups. Même si les programmeurs peuvent manager eux-mêmes ce pipeline, en décidant par exemple du qui-fait-quoi (3), le chef de projet doit garantir que les programmeurs travaillent dans des conditions permettant le bon fonctionnement du pipeline. Pour cela, le chef de projet peut être amené à réaliser des tâches de documentation, à organiser des réunions, à relancer diverses personnes pour finaliser des décisions ou, dans certains cas, à résoudre des questions relatives à la conception et restées en suspens jusque-là (4) (voir la figure 14-4). Le chef de projet doit travailler avec quelques jours d avance sur les programmeurs, afin de finaliser notamment les dernières questions de conception et d alimenter le pipeline. Si un chef de projet est responsable du travail de plusieurs développeurs, il doit gérer finement son temps afin de pouvoir jongler avec des demandes concurrentielles émanant de plusieurs pipelines : c est bien pour cela que le chef programmeur doit se charger de ce travail. Dans son ouvrage intitulé Web Project Management: Delivering Successful Commercial Web Sites (Morgan Kaufmann, 2001 non traduit), Ashley Friedlein appelle ce processus le briefing de l équipe, les détails de chaque tâche élémentaire à réaliser étant désignés sous le nom de mission. Comme l écrit Friedlein, «pour maximiser l efficacité et la rapidité du développement, vos missions doivent toujours être créées avec un peu d avance sur le travail du moment. Dès qu une tâche est terminée, la mission décrivant la tâche suivante est prête à être engagée.» Ces missions sont dérivées des spécifications (si elles sont encore pertinentes), mais elles incluent toute nouveauté et toute modification devant être connue du programmeur. Si les programmeurs ne sont pas activement briefés durant le milieu de partie, de nombreux éléments peuvent bloquer le développement d une tâche élémentaire et ralentir le pipeline : il peut s agir de questions d ergonomie, d interface graphique, de problèmes liés à d autres tâches élémentaires, de questions de marketing, de problèmes techniques ou de liens

12 288 Chapitre 14 Stratégie de milieu de partie Figure Les derniers détails de conception et de spécification peuvent être vérifiés et finalisés en parallèle par le chef de projet et le concepteur. Ce travail permet d exploiter au maximum le pipeline de codage. de dépendance externes. Du fait que les chefs de projet ont des compétences diverses, ils sont les mieux placés pour faire fonctionner le pipeline, pour identifier et résoudre les problèmes, et pour arrondir les angles avant que le programmeur débute son travail. Le chef de projet peut donc être amené à aider les programmeurs frustrés, bloqués dans leur travail, qui ne l admettent pas ou ne l ont pas encore réalisé. Quatre questions permettent de piloter convenablement le pipeline : Quelles sont les tâches élémentaires en cours de codage actif? Certains problèmes bloquent-ils les programmeurs dans leur travail de développement d une tâche élémentaire donnée? Si c est le cas, il faut résoudre ces problèmes. Cette situation est critique pour un projet, car si un programmeur est bloqué dans son travail de codage, c est tout le projet qui est bloqué. La résolution d un tel problème est une priorité absolue. En tant que chef de projet, vous devez demander au programmeur concerné de vous dire en quoi vous pouvez l aider. Si le problème bloquant provient d un lien de dépendance entre deux tâches (par exemple, si la tâche numéro 6 doit être terminée par Fred pour que Bob puisse commencer à coder la tâche numéro 7), tentez de trouver un travail réalisable par le programmeur bloqué afin qu il ne reste pas à attendre et à ne rien faire. Le programmeur connaît-il et comprend-il tout ce qui est nécessaire à l implémentation de la tâche élémentaire courante? Des questions et des points non traités apparaissent toujours au moment de l implémentation. Certains programmeurs, plus expérimentés que les autres, sont plus proactifs et sont capables de résoudre ces questions ou de compléter les spécifications pour implémenter concrètement la tâche élémentaire. Le chef de projet ou le concepteur doivent être à la disposition des programmeurs et s investir dans ces deux activités pour combler ces manques. Parfois, il est possible d anticiper l émergence de ces manques, par exemple en vérifiant que les questions soulevées dans la revue des spécifications (pour la tâche élémentaire courante) ont bien été résolues. Quels sont les prochaines tâches élémentaires à coder? Cette question constitue le cœur du management du pipeline : le bon manageur de pipeline doit réfléchir avec un coup d avance sur les programmeurs (voir la figure 14-4). Si le codage des tâches élémentaires courantes avance bien, il faut se tourner vers les prochaines tâches à implémenter (et donc à injecter dans le pipeline) : ces tâches représentent les prochaines activités d importance majeure pour le projet. Commencez toujours

13 Le pipeline de codage 289 par le travail le plus critique, même s il s agit du plus difficile. Pour chaque tâche du pipeline, tentez d identifier (et de résoudre) les questions ouvertes qui pourraient ralentir ou bloquer le programmeur lorsqu il devra prendre en main cette tâche. Quelle est la dernière tâche élémentaire à avoir été intégralement terminée? Cette question a pour but de cerner la production concrète du pipeline. Il faut vérifier que le code produit dans le pipeline s intègre bien dans l application et qu il répond bien aux besoins de l utilisateur. L implémentation de la dernière tâche élémentaire a-t-elle bien fourni la fonctionnalité et le comportement attendus? Le code a-t-il été validé par l équipe de test? Tous les tests unitaires ont-ils été passés avec succès? Quelqu un a-t-il cherché des bogues ou des éléments de fonctionnalité manquants? La compilation et l édition de liens quotidiens de l ensemble du code (décrites dans le chapitre suivant) permettent de les mettre facilement en évidence car vous pouvez tester la version courante de l application, qui est un bon indicateur de l état d avancement du projet. Plus une tâche élémentaire représente un volume de code important, plus cette pratique est utile. Certains programmeurs s investissent plus que d autres dans les responsabilités qui gravitent autour du pipeline. De nombreux programmeurs vont prendre à bras le corps certains types de problèmes (d ordre technique) mais auront tendance à en ignorer d autres (d ordre économique ou politique). Vous devez connaître suffisamment vos programmeurs pour agir vous-même sur les questions qu ils ne traitent pas. Savoir qui fait quoi dans ce contexte est sans importance, pourvu que tout soit fait : votre travail consiste à vérifier que tout est fait correctement et à traiter vous-même les problèmes laissés de côté par les programmeurs du pipeline. Cette vigilance active est le seul moyen de garantir la qualité de l implémentation de la tâche élémentaire courante. Le partage et la complémentarité des rôles ont été décrits au chapitre 9. Management agressif et management défensif du pipeline Souvent, il suffit d avoir deux ou trois tâches élémentaires d avance sur le pipeline de l équipe de programmation : si chaque tâche nécessite deux jours de travail, cette avance représente une durée d une semaine. Des discussions informelles entre le chef de projet et les programmeurs peuvent permettre de définir la prochaine séquence de tâches à réaliser par le pipeline. S il existe un chemin critique majeur ou un diagramme de Gantt encore d actualité, il est possible d en déduire l activité du pipeline. Travailler avec une semaine d avance sur le pipeline permet de résoudre les derniers problèmes à éclaircir avant le codage, et si cela n est pas possible, de trouver une autre tâche élémentaire à implémenter. Une équipe ayant une position agressive peut faire des paris en s appuyant sur le pipeline pour établir des priorités. Au lieu de réaliser une structure de travail éclatée complexe, incluant toutes les tâches élémentaires, l équipe peut faire le pari d une gestion en flux tendu du pipeline. Les risques sont alors plus élevés : si le pipeline fait marche arrière ou s il ne peut suivre le rythme, de mauvaises décisions seront prises et du temps sera gaspillé. Pour en savoir plus sur l élaboration d une structure de travail éclatée et son utilisation dans le cadre d un projet, on pourra se référer en particulier à l ouvrage intitulé Total Project Control, écrit par Stephen Devaux (Wiley, 1999 non traduit).

14 290 Chapitre 14 Stratégie de milieu de partie Pour une équipe ayant une position plus défensive, le management du pipeline constitue un affinement de la liste originale des tâches élémentaires, créée durant la phase de planification. Le travail du pipeline peut être planifié, programmeur par programmeur, pour les prochaines semaines ou les prochains mois, sur la base de la planification initiale. De légers ajustements sont possibles, mais l idée est que le plan initial doit être respecté au moins jusqu à la prochaine date clé. Une fois celle-ci franchie, une nouvelle liste de tâches élémentaires est générée à partir de la planification initiale, et le processus se répète. Ainsi, en fonction de la durée séparant deux dates-clés et de la stabilité du projet, le travail du pipeline peut être planifié. Le point clé du management d un pipeline n est pas dans la façon dont il est géré. Il existe de nombreuses méthodes de management, toutes aussi valables les unes que les autres. L essentiel est d avoir un management efficace : le bon travail doit pouvoir être effectué au bon moment et de la bonne façon, sans que du temps soit perdu à déterminer la tâche suivante à implémenter. Quand le pipeline de codage devient le pipeline de débogage Lorsque le projet est très avancé et que toutes les tâches élémentaires ont été implémentées, le pipeline poursuit son existence, à ceci près qu il n est plus alimenté en tâches élémentaires à coder mais en bogues à résoudre. Dans le chapitre 15, j évoquerai ce nouveau rôle du pipeline, notamment à l occasion de la présentation du triage des bogues, en particulier le processus décisionnel des modalités de traitement des bogues. Suivre l avancement du travail Le moyen le plus simple d évaluer quantitativement l avancement du travail consiste à s appuyer sur la liste des tâches à effectuer, qui permet de savoir immédiatement combien il reste de tâches à implémenter : lorsque ce nombre atteint la valeur 0, le milieu de partie est terminé (voir la figure 14-5). Toutes les stratégies de milieu de partie nécessitent une bonne compréhension de l état du projet, ce qui permet de garder l équipe sur les bons rails et de préparer la fin de partie sous les meilleurs auspices. Le nombre de tâches élémentaires complètement réalisées est l indicateur le plus fondamental permettant de déterminer l état d avancement du projet. Figure Le milieu de partie n est pas terminé tant que l implémentation de toutes les tâches élémentaires n est pas terminée. La fin de partie débute lorsque le nombre de tâches à réaliser tombe à zéro. Les activités qui n influent pas sur ce nombre doivent etre considérées comme secondaires par rapport à celles qui ont une influence.

15 Toucher les cibles mobiles 291 Je recommande de décrire l état d avancement d un projet le plus simplement possible, comme on peut le voir dans la figure 14-5, et de faire en sorte que cette description soit la plus visible possible aux yeux des membres de l équipe. Pour des projets complexes, il suffit de donner le pourcentage de tâches élémentaires implémentées par grand domaine. Si l équipe projet dispose d un site web, une synthèse des tâches élémentaires (à réaliser, en cours de réalisation ou terminées) peut être proposée en ligne, avec une mise à jour quotidienne. On peut aussi installer un grand tableau dans le principal lieu de passage de l équipe, afin d afficher ces mêmes informations. Toutes les réunions hebdomadaires d état des lieux devraient débuter par une synthèse rapide de la situation. Chaque tâche élementaire représentant en général une à trois journées de travail, un graphique ou un tableau tel que celui de la figure 14-5 montrera des évolutions quasi quotidiennes. Les membres de l équipe doivent être encouragés à consulter régulièrement ces sources d information, et à identifier en particulier ce qui vient d être réalisé et ce qui va bientôt l être. Des informations d importance secondaire, telles que le nombre de jours restant avant la finalisation d une tâche élémentaire, ou le nombre de jours de travail restant à effectuer par chaque programmeur, doivent aussi faire l objet d un suivi. Ces données secondaires ne doivent cependant pas occulter les chiffres essentiels évoqués plus haut. Durant le milieu de partie, il est bien plus important de donner à l équipe une vision holistique de l état du projet. Les membres du groupe ont toujours une vision de ce qui se passe dans leur entourage professionnel proche : il faut leur donner une vision globale du projet. Le suivi de l état d avancement d un projet est un vaste sujet, qui sera détaillé dans le prochain chapitre : en particulier, le traitement des bogues et l émergence de tendances sont d importance capitale. Toucher les cibles mobiles «Aucune bataille n a jamais été gagnée en suivant aveuglément un plan, mais aucune bataille n a jamais été gagnée sans un plan.» Dwight D. Eisenhower L une des justifications des cycles courts sur lesquels s appuient l extreme programming et d autres méthodes est qu il y a tout le temps des changements d orientation. En travaillant selon des cycles de développement courts, l équipe projet peut s adapter à des changements d orientation majeurs sans compromettre son travail ; elle peut aussi focaliser sur le court terme, tangible par essence, ses efforts de conception ou de planification. Cette idée me paraît tout à fait sensée, de même que la volonté de multiplier les «victoires» à court terme. Un élément supplémentaire mérite cependant d être mentionné : les plans de long terme, même s ils sont peu détaillés, facilitent les modifications à court et à moyen terme. La raison en est que lors d un changement d objectif, de besoin ou de conception, le plan initial est très rarement remis en cause dans son intégralité. En réalité, les changements sont toujours effectués par rapport à la vision initiale du projet, telle qu elle est décrite dans le plan (initial) à long terme. Plus le plan initial est correct (même s il s agit d un plan grossier), plus il constitue un point de référence et plus il est facile et rapide de procéder à des ajustements. Cela signifie que la meilleure assurance

16 292 Chapitre 14 Stratégie de milieu de partie contre la volatilité du projet est encore un plan de travail viable, réalisé dès le début du projet, et ajustable à tout moment. «À mon sens, une bataille ne se déroule jamais conformément à un plan. Le plan est une donnée de base permettant d effectuer des ajustements. Tout le monde doit connaître le plan, afin que vous puissiez le modifier facilement... La guerre moderne est très fluide, et il faut pouvoir prendre des décisions très vite, mais pas forcément en suivant le plan. A tout le moins, tout le monde sait [donc] plus ou moins d où vous venez et où vous allez.» Général Dan Laner, Commandant des Forces de défense israéliennes Pour gérer correctement un plan dont les objectifs sont censés évoluer, l astuce consiste à mettre à jour fréquemment ce plan. Si vous pouvez identifier l intervalle de temps correct entre deux mises à jour, les objectifs n évolueront pas suffisamment pour créer des difficultés : ces évolutions reflèteront simplement des orientations nouvelles et une «vitesse instantanée» du projet. Si le projet comporte de multiples dates clés ou de multiples phases (voir le chapitre 2), elles matérialiseront naturellement ces intervalles entre deux mises à jour. Si une période de temps est prévue dans chaque phase, cela vous donne l occasion d examiner à nouveau des tâches réalisées antérieurement. Même si l intervalle de temps est de l ordre de trois à six semaines, vous pouvez aménager un ou deux points d étape pour ré-évaluer la trajectoire du projet par rapport aux objectifs ou aux besoins qui ont pu changer. Pour cette raison, il faut adapter cet intervalle à la volatilité du projet : plus celle-ci est grande, plus l intervalle doit être court. La figure 14-6 illustre un exemple simple d ajustements réalisés pour rester orienté vers des objectifs mouvants. Le projet débute au point A ; il est censé se terminer au point B. Si deux semaines après le début du projet, les responsables de l équipe constatent que les objectifs matérialisés par le point B ont changé, le projet doit faire l objet d une correction de trajectoire lui permettant de toujours viser le point B. Deux semaines plus tard, une autre correction de trajectoire doit être effectuée. Il faut jeter à la poubelle une partie du travail réalisé, mais moins qu en cas de correction de trajectoire tardive. Si ces évolutions coïncident avec des dates clés, l équipe peut consacrer un peu de temps à des tâches de conception pour atténuer les effets de ces changements, et ajouter des tâches élémentaires tenant compte de ces modifications, pour les effectuer dans la foulée. Même si le projet ne prévoit pas de dates clés adaptées, le pipeline de codage permet de contrôler ces ajustements intermédiaires. Ces corrections de trajectoire peuvent être traitées un peu avant l entrée d une tâche dans le pipeline de l équipe de programmation. Il faut donc disposer d une sorte de tampon «pré-pipeline», dans lequel le chef de projet peut se donner le temps d ajuster le tir avant d alimenter le pipeline. Plus ce tampon est gros, plus les ajustements peuvent être conséquents (voir la figure 14-7). Si le chef de projet ou le responsable des programmeurs gère correctement le pipeline, l équipe ne sera jamais bloquée et les corrections de trajectoire pourront être effectuées harmonieusement. Il suffit que le pipeline soit suffisamment alimenté en travail. Cependant, tout cela suppose que les modifications ne sont pas radicalement orthogonales à la direction initiale du projet : planifier le travail permet des ajustements limités (voir la figure 14-7). Si de nouveaux besoins ou de nouveaux objectifs dépassent une certaine limite, un travail exploratoire ou de conception très important

17 Toucher les cibles mobiles 293 Figure Les objectifs, les besoins et les contraintes peuvent changer, mais si la vitesse et la direction du projet sont bien comprises par l équipe, les dates-clés permettent de maîtriser les changements. Figure Tout plan peut supporter des modifications de plus ou moins grande importance. Plus le plan est anticipateur, plus cette souplesse d adaptation est grande. s avèrera nécessaire, dans des proportions excédant les capacités d adaptation du pipeline de codage, ou nécessitant un temps de conception excessif au regard de la prochaine date clé. Par exemple, si le plan initial était de fabriquer un grille-pain, il est envisageable d en modifier la taille durant le milieu de partie, mais pas d en faire un accélérateur de particules ou un super-tanker. La figure 14-7 présente une modélisation simpliste du degré d adaptation d un projet. La zone délimitée par le contour gris foncé matérialise l espace à l intérieur duquel peut encore évoluer le projet, moyennant un effort de reprogrammation modéré. Un diagramme similaire pourrait être réalisé pour chaque tâche élémentaire. En fonction de l approche du programmeur, son plan peut évoluer à l intérieur d un espace plus ou moins vaste. Il convient de noter la relative naïveté de la figure L écoulement du temps y est représenté verticalement, ce qui laisse croire que les possibilités de changement n évoluent pas avec le temps : il n en est rien. Il est plus correct de penser que l amplitude des modifications acceptables évolue dans le temps, en fonction de l état du projet. En général, cette amplitude diminue avec le temps, au fur et à mesure que les tâches

18 294 Chapitre 14 Stratégie de milieu de partie élémentaires sont finalisées. Chaque modification influe sur l espace des modifications ultérieures envisageables. Faites un peu de prospective Lorsqu un projet fonctionne bien dans une organisation saine, c est souvent parce que la plupart des changements de haut niveau sont effectués en respectant le rythme imposé par les dates clés du projet. Ce bon fonctionnement est généralement facilité par le fait que la durée entre deux points clés est adaptée à la volatilité du projet ou de l organisation. Le management a la patience et la sagesse d attendre la fin d une phase de travail pour provoquer un réajustement dans le projet. Cependant, même dans ces organisations, des directives peuvent être prises par le management en plein milieu du gué (entre deux dates clés), sans véritable temps de préparation. La plupart du temps, le management, le client ou une action de la concurrence peuvent vous «inciter» à envisager une correction de trajectoire, sans qu il y ait de décision claire à ce propos. Parfois, la décision à prendre relève de votre compétence ; parfois, il vous suffit d attendre que la décision soit prise par quelqu un d autre. Dans tous les cas, vous devez réfléchir aux actions à entreprendre si cette «incitation» se transforme en décision réelle de procéder à une correction de trajectoire. Dans les jours ou les semaines qui précèdent une décision importante du management ou un changement complet de la stratégie d un concurrent, il y a toujours des signes avantcoureurs, que vous pouvez détecter si vous êtes attentif. Ces signaux faibles vous parviendront d autant plus facilement que votre réseaux relationnel et que votre habilité politique sont grands. Vous pouvez parfois anticiper la situation grâce à cela. Sur la base des informations dont vous disposez, tentez périodiquement de deviner les changements de direction les plus probables : va-t-il falloir rendre le produit compatible avec une nouvelle technologie, implémenter une nouvelle fonctionnalité, se donner un nouvel objectif? Imaginez, même grossièrement, le travail à entreprendre pour mettre en place concrètement ces corrections de trajectoire éventuelles. Par exemple, ayez une conversation rapide avec le chef programmeur à ce sujet : «Fred, que faudrait-il faire pour être compatible avec l API version 2.0, en plus de celles que nous utilisons déjà?» Le but n est pas de dresser un plan de bataille, mais simplement d avoir une idée de l effort à déployer dans l hypothèse d un changement. Ré-examinez votre liste de priorités des tâches élémentaires (voir le chapitre 13) et vérifiez si vous n avez pas déjà des éléments de réflexion sur cette question. Explorez l impact d un changement Si la probabilité d un changement devient élevée, vous pouvez ajuster le travail du pipeline de codage pour mieux vous préparer à cette éventualité. Aux échecs, il y a deux façons de préparer un mouvement : 1. Stratégie défensive. Recherchez les mouvements qui vous donnent le plus de degrés de liberté possibles et qui vous permettent de garder un maximum d options ouvertes. 2. Stratégie agressive. Engagez-vous à fond dans une option stratégique précise et mettez la pression sur votre adversaire. Dans un projet (ou dans une partie d échecs), soyez agressif lorque vous êtes en confiance ou lorsque vous vous sentez plus fort que l adversaire (le management ou

19 Toucher les cibles mobiles 295 la concurrence). Soyez défensif lorsque les choses sont incertaines ou lorsque vous ne vous sentez pas en position de force. Dire à votre équipe que vous avez retenu l option défensive peut provoquer un léger ralentissement de son activité, mais vous y gagnerez en sécurité. À l inverse, une stratégie agressive incite les autres à prendre des décisions, et si vous donnez la priorité à la rapidité des décisions, des prises de décisions agressives peuvent avoir des effets favorables pour vous, même si vous êtes dans une position politiquement faible. Cependant, envisager un ajustement n est pas forcément synonyme d une baisse de qualité du code ou d un temps de développement supplémentaire. Par exemple, un algorithme alternatif peut être aussi fiable que celui qui a été retenu, mais plus flexible d un certain point de vue. Demandez alors à vos programmeurs d examiner le degré de faisabilité et de simplicité d un changement d algorithme, en précisant qu il ne faut rien sacrifier à la qualité et ne pas envisager de changement majeur. Ce travail exploratoire peut être mené dans le cours normal du travail, sans perte de temps véritable. Parfois même, ce travail peut être très succinct : par exemple, un programmeur peut déjà avoir envisagé cette possibilité de changement et avoir bâti une opinion solide sur la question, si bien que quelques minutes de discussion suffisent pour obtenir une réponse. Cependant, la situation n est pas toujours aussi simple, et il faut alors consacrer des heures à l étude d une question. De toute façon, plus vous avez une vision claire du coût d une modification, plus vos arguments pour soutenir (ou empêcher) cette modification seront forts. Le coût potentiel du changement On notera aussi que plus un projet est proche des objectifs initiaux (ou des derniers objectifs validés), plus il sera difficile de procéder à des ajustements ou à des corrections de trajectoire. Dans la figure 14-8, le projet progresse officiellement vers le point B, alors que des rumeurs circulent à propos d un éventuel changement de direction (représenté par un point d interrogation sur la figure). Le chef de projet anticipe cette évolution et prépare un ajustement ad hoc. Pour cela, il bâtit avec ses programmeurs un premier plan d action succinct venant répondre à l évolution éventuelle. Figure Si vous savez qu un changement va intervenir mais si vous ne savez pas quand, appuyez-vous sur une démarche prospective pour tenter d en cerner les effets et pour vous y préparer.

20 296 Chapitre 14 Stratégie de milieu de partie Le projet progresse toujours, mais la rumeur d un changement à venir persiste. Plus le projet s approche du point B, plus le changement éventuel va se traduire par une correction de trajectoire forte : la nouvelle direction éventuelle va faire un angle de plus en plus important avec la direction actuelle, d où un risque de problème de plus en plus marqué. Plus le nombre de lignes de code croît, plus il est difficile de se préparer à un changement. Lorsque le projet est sur le point d atteindre les objectifs matérialisés par B, la distance entre l état courant du projet et l éventuel nouveau point à atteindre, en cas de changement, devient très supérieure au chemin à parcourir pour atteindre le point B. Plus l équipe tarde à s engager dans un changement, plus le coût induit est élevé : ce coût, matérialisé par la (grande) distance à parcourir vers les nouveaux objectifs éventuels, est désigné sous le nom de coût du changement dans la figure Si le changement se produit réellement, et si vos efforts prospectifs n ont pas été payants, vous n avez plus le choix : il faut réorienter les efforts de l équipe. Si ce changement ne s accompagne pas d un délai supplémentaire, vous devez retourner à vos listes de priorités et supprimer les tâches élémentaires qui vous permettront de dégager le temps nécessaire à la correction de trajectoire (voir le chapitre 11). Manager et contrôler le changement Certaines équipes projets font un suivi et un contrôle actif de toute modification de conception exigeant la réalisation d une nouvelle tâche élémentaire ou l élimination d une tâche existante (ce suivi peut débuter juste après la revue formelle des spécifications). La crainte de ces équipes est que si des changements de conception sont effectués sans qu un processus précis soit suivi, des décisions épouvantables peuvent être prises sans que les personnes concernées en soient informées. En fonction de la culture et des objectifs de l équipe, agir peut être indispensable, ou au contraire inutile. Comme Friedlein le souligne : «La façon dont vous managerez le changement dans l équipe-projet va dépendre... de la taille et de la nature du projet. En général, plus un projet est gros et complexe, et plus les spécifications sont rigides, plus vous devrez manager le changement d une main ferme.» Si votre équipe se moque du processus de spécification, elle se moquera aussi d avoir un processus de management du changement, puisqu il n y a pas de point de référence permettant d évaluer l ampleur d une modification. Cependant, même dans une équipe qui a mis en place des processus formels, plus le projet est sur le point d atteindre ses objectifs, plus il sera sensible à des modifications. S il n existe pas de processus de communication, de suivi et de management du changement, il devient très difficile et très frustrant de repartir en arrière si près du but. Plus un équipe a de maturité, plus elle aura tendance à contrôler tôt le changement. Il ne s agit pas là d un processus de fin de partie, mais lorsque la fin de partie approche, les risques augmentent, ainsi que le désir de les contrôler. La façon la plus simple de manager le changement consiste à mettre en place une version allégée du processus de spécification. Dans le jargon de Microsoft et de la NASA, on parle de demande de modification de conception (DCR design change request). Dans d autres organisations, on parle de demande de modification d ingénierie (ECR engineering change request), de commande de modification d ingénierie (ECO engineering change order) ou, plus simplement, de demande de modification (CR change request).