Demain… les projets seront multi-prestataires.

poney_land
Chaque domaine du digital devient de plus en plus pointu, et réclame de fait d’être un expert dans chaque sujet abordé. Tout particulièrement dans le digital, la réalisation d’un projet s’avère très complexe, voire quasi impossible pour les entrepreneurs qui, avec une petite équipe, espèrent se placer face à des géants implantés lourdement sur le marché, et n’offrant plus que des « standards ».
C’était un peu l’espoir de l’open source, donner sa chance à des communautés, et permettre un usage professionnel, ça sentait le petit poney à plein tube et de beaux papillons surfaient sur des arc-en-ciel, mais on est encore loin de ce qui se profile.

  • Le monstre

Le problème principal repose dans le besoin de devenir multi-compétences (comme Leeloo Dallas Multipass) et d’avoir à la fois :
– Un rôle d’agence graphique, ergonomique, peuplée de talentueux esprits innovants, et spécialisés dans la recommandation d’architecture de l’information
– Un rôle d’agence dans l’accompagnement au marketing sous forme éditoriale, entre autre, mais pas que, parce que le wording, ça compte.
– Un rôle de conseil en marketing, couplée avec des outils pour faire des recommandations par l’étude du comportement des inter-intra-extra-nautes,
– Un rôle de référent et de metteur en oeuvre de projets mobilité et tous les aspects relatifs aux usages, qu’il s’agisse de téléphone ou de tablette


Mais il faut aussi…
– Connaitre parfaitement le SEO, ses enjeux, ses tenants et aboutissant, les services qui peuvent être consommés, et la régularité du suivi sur les différents moteurs de recherche
– Savoir faire du consulting dans toutes les phases projets de la conception à la réalisation en accompagnant par exemple dans le choix de l’outil et de technologie, en faisant de la recommandation d’architecture, du conseil de mise en oeuvre, et de l’accompagnement au changement -mais ça aussi c’est un peu de l’agence… ha ha !-
– Etre un pôle de production opérationnelle (depuis la réalisation : montage, développement, test unitaire, contrôle qualité …) mais aussi de la gestion opérationnelle (gestion de projet, suivi, recette, formation, accompagnement au changement aussi ici…)


Et en complément il faut…
– (tant qu’à faire) Proposer une offre d’hébergement et d’infogérance
– Avoir dans un coin quelque part (ou dans un placard) une petite possibilité d’offrir des services dans le Cloud (à pronnoncer Klaoudh par ce que je le vale bien !)
– D’être à l’occasion éditeur de solution si on peut, voilà voilà, rien que ça


Et avec tout ça faut avoir :
– un pôle commercial, riche, techniquement capable, pour aller chercher du business
– et puis un pôle recherche et développement pour s’assurer de la faisabilité technique d’une réalisation…
(Mais ces derniers sont des centres de coûts qu’il faut avoir la capacité d’anticiper et de couvrir… )
– etc. etc.

BREF ! A moins d’être un monstre à plusieurs têtes, de multiples yeux, de multiples cerveaux, et de nombreux bras, difficile de se positionner sur les demandes aussi larges que complexes qui ne représentent pas moins que l’absolument nécessaire pour la flopée d’appels d’offres qui inondent le marché.
Même les grosses structures peuvent souffrir du manque d’organes dans certains type de compétences : ce fut particulièrement le cas lorsque tous les sites webs ont du se décliner sur des terminaux mobiles, tablettes, et autres dessous-de-verre, et qu’aucun consultant n’était présent pour la recommandation de mise en oeuvre entre responsive design, site mobile et application mobile(…)
A l’absence de compétences existantes la seule réponse des grosses structures à cette problématique est d’abord d’opter sur les espaces de recherche et développement, difficile, pour le petit entrepreneur ou la petite structure qui souhaite montrer le bout de son nez sur le marché d’avoir une chance de pouvoir se positionner s’ils n’ont pas un gros temps à perdre.

Alors quoi faire ?

Laisser la place aux entrepreneurs a toujours été un moteur de l’innovation, un retour au simple et au sources de l’efficacité aussi. Alors pourquoi pas laisser une place aux entrepreneurs, mais surtout, leur donner la chance de s’associer en consortium.

Ce qui nous attend ?

A mon sens ce sont :
– Soit des grosses structures qui pourront répondre à des appels d’offre, seuls, voire avec de l’aide sur certaines briques toutes particulières puisées dans la source originelle des free disposables à volonté…
– Soit des mega-consortiums de petites structures qui se coordonneront et seront en mesure de répondre ensemble chacune avec son domaine d’expertise.

Ce qui va changer ?

multi_prestaLe mode de gestion de projet bien-sûr. Demain, on aura des supers-chefs-de-projets, probablement indépendants qui se chargeront à temps plein de faire le relais entre de nombreuses structures et le client qui ne souhaitera pas devoir consolider le travail de ces consortiums. En terme organisationnel ça va aussi changer la donne, on ne pilote pas de la même manière de nombreuses structures indépendantes (chacune avec son propre mode organisationnel) et des entités au sein d’une même société, déjà parce que chaque société a ses enjeux, ses forces mais aussi ses faiblesses (comme la folle envie de glandouille et de refourguer la patate chaude à un autre prestataire)… Il faudra aussi lutter contre l’improductivité, et accepter l’autorité de ce super-CP. Mais il faudra aussi savoir vendre sa prestation et faire valoir de son savoir organisationnel.

Est-on mature pour cela ?

Je ne sais pas, je pense qu’avec un peu d’ouverture d’esprit (et de temps et d’argent bourdel!) oui. On voit bien de nombreux mode de management se profiler : entre la journée recherche et développement chez Google et l’auto management chez Valve (la célèbre marque de jeux vidéo on a démontré que d’autres formes de « faire » se profilent, on peut bien imaginer une « méthode universelle » et des consortiums particulièrement performants et actifs entre petites structures d’entrepreneurs et qui auront tout à fait leur place sur le marché concurrentiel. Ça offrira un nouveau panel aux clients et les prestataires ne seront plus seulement des mégas structures bureaucratiques avec de niveaux hiérarchiques, mais probablement des hybrides composites travaillant en parfaite symbiose… (et là on pourra retourner rêver à nos magnifique petit poneys) poney_land_2

Sauvez un projet, fouettez un graphiste (en plus il aime ça)

Je sais que depuis que je suis consultante, je n’ai pas mis beaucoup d’article sur la gestion de projet, mais je rattrape sous peu, plein de petits articles attendent au four.

Voici LA checklist du chef de projet pour qu’il casse les pieds, lourdement, aux graphistes, créa et autres ergonomes qui font dans la dentelle, la fantaisie, l’effet WWOuahou, et qui vont gentiment, sans le savoir, eux, plomber la relation client parce que « sur les maquettes c’était plus beau » ou « mais pourquoi c’est si lent ? » ou encore « comment ça c’est pas dans le périmètre du projet ? C’est sur les maquettes ! »

C'est beau le lisssage... en web ça donne plutôt la partie à gauche

  1. Le lissage des polices.


    Le lissage des polices sur une maquette, c’est la joie de présenter au client une maquette toute propre, suave, et peut-être éventuellement si les clients n’utilisaient que Firefox, quelque chose de presque reproductible.
    QUE NENIE. Le lissage sur les maquettes c’est le Bad, il faut le bannir, ça ne sert non seulement qu’à flatter l’égo du graphiste mais ça ne produit jamais l’effet final = l’effet web (tu sais le truc avec des pixels)
    Présenter une maquette « propre » à une direction de la communication, ce n’est pas présenter un site web à un million d’utilisateurs.
    Comment savoir ? Tout simplement, demander au graphiste « est-ce que tu as fait la grosse connerie de lisser les polices sur les maquettes, elle a l’air bien propre et… pas très ouebe » ? Vous verrez ça fait tout de suite son petit effet.

    polices_non_web

     

  2. Les polices « non web »


    On a beau se persuader que les navigateurs se modernisent à outrance, le jeu de police associé reste le même. Donc quand un graphiste ajoute une police non web à une maquette, le résultat sans Javascript activé = police web (entendez un moche Arial, un hideux time new roman, ou un acceptable Verdana) ; par conséquent ? Que faire ? Opter pour un de ces plugin JavaScript Barbare : @font-face ? @cùfon ?
    Et la compatibilité navigateur de ces petits plugins ? Une jolie petite blague pas vraiment drôle pour les versions d’Internet Explorer, et de longues heures de recette… (et puis avec les utilisateurs d’IE6, qui devraient être flagellés au marti-fouette trempé dans l’acide, parfois on se retrouve des heures à faire des tests et des ajustements sur une machine virtuelle aux performances tout ce qu’il y a de plus relatives)
    Bref, quand un graphiste introduit une police non-web attendez-vous à souffrir, par conséquent, prenez de l’avance, offrez-lui un cactus.

     

  3. Les blocs Étirables.


    Le bloc étirable est adaptable partout, il est beau, il est mignon… sauf que pour faire un bloc étirable il faut lui donner une structure proche de celle d’un plan d’architecte, tout en lui confèrent la solidité d’accueillir le contenu du client qu’il soit volumineux ou minuscule, bien sûr, celui-ci sera encore plus complexe dès qu’il aura des bords arrondis, des effets ombrés, du relief, une image qui en déborde etc… etc…
    Pour chaque minute de css pour répondre au besoin complet, mettez un petit caillou dans une jarre, une fois terminé, faites en une soupe que vous ferez boire au graphiste.

    graphiste_etirable

     

  4. Les alignements verticaux


    Il est mignon le bloc à gauche, et puis il est encore plus mignon le texte flottant à droite, qui est parfaitement aligné avec les titre de la 3ième lignes, du bloc de gauche… Pareil pour les deux blocs en dessous… Ha ? ils peuvent être intervertit ? C’est magique ??? Pas d’illusion ici : l’alignement vertical n’existe pas, pour aucun navigateur. Seul le JavaScript peut vous aider, et seule une construction souple adaptative et évolutive du code permet de jouer à ces petits jeux d’alignements qui, même en print (=à l’impression papier), ne se produisent jamais par hasard.
    Bref, quand le graphiste vous fait des alignements verticaux, à outrance, et que l’ergonome recommande le déplacement de tous les blocs dans tous les sens, alignez-les, eux aussi, tous les deux

    graphiste_align

     

  5. Le périmètre fonctionnel


    Ouahhh mais elle est géniale cette maquette, mais que fais le bouton ici ? Et le bloc là ? Et la fenêtre là ? Et la popin là ? Et la popup ici ? Tiens mais que fait ce nouvel élément dans le Footer ? Et cette fonctionnalité là, dans le header, elle vient d’où ? Elle fait quoi ?
    Soyez psychorigide, quand le graphiste réalise plus que le cahier des charges, ou qu’il ne respecte pas les story board de l’ergonome (qui lui était en atelier fonctionnel avec vous ): les développements devront couvrir TOUS le périmètre fonctionnel de maquettes, même si ces nouveaux points n’étaient pas initialement au périmètre fonctionnel du CDC ou du CCTP, a fortiori si les maquettes ou la charte graphique sont validés. Bref, quand un Graphiste ajoute un truc, demandez-lui d’aller chercher le budget correspondant chez le client, sans cravate et avec son beau sourire col-guette, et attendez patiemment qu’il écoute la courte et froide réponse du client.

     

  6. Le brief


    On se demande souvent pourquoi le graphiste n’a pas fait ce qu’on lui a transmis, pourtant on avait peut-être fait un pseudo Compte rendu de ce qu’on attendait… et en fait ça tombe vraiment à coté.
    Obligez-vous à rédiger un brief, pour le graphiste : soyez efficient, précisez ce que vous attendez, où trouver des informations graphiques propre au client, les terminaux cible, l’historique et les attentes du client, les navigateurs attendus et tout le tintouin, ça vous servira aussi pour le travail de montage graphique, ça vous assurera de pouvoir renvoyer le graphiste à la lecture de l’énoncé et s’il le lit pas tatouez le graphiste avec un RTFM

     

  7. La projection


    Malheureusement, de nombreux graphistes se persuadent encore que les développeurs sont meilleurs qu’eux. Ils ont raison. C’est dommage parce qu’ils pourraient devenir meilleurs et se souvenir qu’une maquette doit pouvoir être montée dans un environnement web, et par conséquent faire leur travail jusqu’au bout, mais non, ils savent que les développeurs talentueux, devineront les noms sibyllins mis derrière des calques de votre fichier toshop, gimp ou illustrator, que 2433 calques valent toujours mieux qu’une 50aines bien organisés, et que les calques « trashs » sont toujours utile quand on a du temps à gaspiller.
    Bref, la prochaine fois que vous donnez un brief à un graphiste, écrivez-le en sanscrit, faites lui livrer par coursier au bengali, et dites-lui de se débrouiller pour aller le récupérer.

     

  8. La culture


    Vérifiez, vérifiez tout derrière le graphiste.
    Recontez les nombres, vérifier les ordre alphabétiques des glossaires, vérifier la place et le n° des départements sur une carte vécu, refaite les parcours de produit, lisez les textes qu’ils ont choisi vécu aussi…, soyez vigilant, car même si le graphiste est dans le speed comme vous, lui, il n’est pas obligé d’avoir une culture ni de parler au client
    Là, si le graphiste fait de la merde et surtout qu’il refuse de corriger parce que c’est « une pétouille », enfermez-le dans une pièce avec 1 moustique, il verra ce qu’une broutille peut faire…

     

et le département de Marseilles tu le mets où ?

et vous ? vous mettriez quoi de plus à cette check-list ?

La Technique du Bulldog

Pas très loin des clichés du cinéma réservé à un public qui commence à peine à maitriser sa langue natale, la technique du bulldog, consiste à se comporter comme un chien qui jamais ne lâche  sa prise sur un élément (l’os) et réagit agressivement ou de manière menaçante (grogne, aboie) lorsqu’on tente de lui retirer. Cela parait être un peu cabot, mais il ne faut pas « être chien » pour faire une petite revue des inconvénients, et avantages de la technique du bulldog :

* Pourquoi l’employer ?

Bon, d’abord, pour avoir la technique du bulldog, il ne faut pas forcement se sentir l’âme d’un chanteur de rap qui porte une arme et un râtelier doré (ou pas d’ailleurs, de nombreuses chaines et pacotilles, ou signes extérieur de richesse font souvent parfaitement l’affaire –oui, tu peux ranger ton i-ped) ni d’un homme de main qui doit faire le sale boulot (le cliché veut que beaucoup de ceux qui emploient la méthode s’inspirent des films sur la pègre, la mafia, ou les caïds des cités…)

Il faut avoir un enjeu à employer cette méthode : soit une absence totale d’éthique et de sens moral, soit, a contrario, une cause morale indemordable et indiscutable dans laquelle on se sent dans son bon droit.

Parfois, la méthode est indispensable car :

« l’homme est un loup pour l’homme » (ouais j’aime bien quand je cite Rabelais comme ça…)

et surtout :

le collègue de travail et un loup enragé et ambitieux qui ne se privera pas d’aller voler dans ton assiette surtout si ses dents sont plus longues que les tiennes

et que :

le client est un Dahue pour le prestataire qui peut parfois souffrir de longues heures sous les postillons de la colère divine parce que là, y’a un angle, il est moche, et que bon, c’est inadmissible de livrer ce niveau de qualité, parce qu’un angle, qui est moche, dans un bloc, dans un coin, ça remet bien-sûr en cause tout le business.

(oui certaines expériences reste sans commentaire…)

* Quand l’employer ?

Mais revenons à nos bulldog plutôt que de les compter, ou de jouer à saute bulldog.

Que ce soit à temps plein ou à temps partiel, la technique du bulldog est à employer de préférence lorsqu’on est certain de gagner : ça consiste à tenir à son os car on est certain de pouvoir le conserver (oui, si vous avez une tendance chie-wouah-wouah*, ou char-pet*, laissez tomber, ça va pas le faire), ou à tenir à sa proie comme si on était le ou la seul(e) à pouvoir la manger.

Lorsque je dis « certain de gagner » je veux clairement dire « savoir par expérience » (et donc par un minimum de factuel et d’empirisme, n’allez pas appliquer la méthode à l’aveugle après la lecture de votre horoscope chinois qui vous disait que ce matin, vous allez mettre le feu) Il faut donc employer la méthode lorsqu’on a une chance d’avoir le dessus, ou de gagner : la méthode ne se pratique pas comme on pari aux courses (même si parait-il c’est basé sur un minimum de factuel), car sinon, parfois on perd son meilleur cheval.

Il faut donc se sentir l’envie d’endosser un « mauvais rôle » pour quelque chose pour lequel on est certain de faire un maximum de bénéfice ensuite (vous mettant par là même à l’abri de toute représailles attendues, et facile à prévoir lorsqu’on emploie cette méthode), il ne faut pas avoir peur de l’avis d’autrui, l’opprobre est un peu le principal risque de la méthode, le temps est le seul allier pour montrer qu’on a eu raison de procéder ainsi.

Un bulldog c’est donc quoi ou qui ?

« Un bon bulldog a la mâchoire articulée sur avec un cran de blocage inusable » (Sylvain P. Chef de projet), je vais quand même nuancer le propos, on peut voir le bulldog aussi comme une « mère juive » qui veut protéger ses enfants et son patrimoine des agressions ou profits extérieurs.

Le bulldog-style est une méthode comme une autre pour illustrer un propos, ou défendre un principe.

Il est difficile de travailler dans une société capitaliste et de se rappeler que l’on travail pour la communauté des employés qui la peuple : c’est à la fois antinomique et contradictoire : le capitalisme étant la valorisation de l’individualisme, la société étant une somme d’individu qui doivent former un groupe homogène et solidaire ; Ceci, Provoque  parfois des débordements.

De même, une équipe projet entre client et prestataire, bien que chacun « dans un camp » doit former une unité solidaire, prête au dialogue, au pardon et à la compréhension mutuelle dans un but commun : sortir un projet, mais doit aussi défendre ses intérêt personnel : défendre ses ressources, ses estimations, son besoin, son périmètre fonctionnel.

Comment éviter le combat de chien ?

  • Restez factuel. Lorsqu’un bulldog grogne et râle sans raison, il convient de savoir quel est son intérêt et s’il a une réelle légitimité à le faire. Par conséquent si vous employez la méthode, pensez à avoir les bonnes raisons de le faire.
  • Restez ferme. Ne pas augmenter l’agressivité, juste tenir fermement sur son os, ou son propos, ne pas en faire trop, ne pas être agressif sans raison.
  • Restez ponctuel : Un Bulldog qui grogne de manière aléatoire pour la moindre broutille, et qui ne fait jamais preuve de souplesse lorsqu’on lui flatte un peu la tête perdra toute crédibilité et toute marque de potentielle confiance.


Sinon il reste la bonne vieille méthode de la patte de velours, plutôt que bulldog, restez gros minet.

En plein dans le mur.

Je sais : savoir qu’un projet part dans le mur ne vous intéresse pas, d’abord parce que souvent ceux qui vous l’annoncent vous cassent bien assez les pieds, mais surtout, parce que les chevaux sont lancés, alors difficile de faire machine arrière… Petit précis de gestion de projet en plein dans le mur.

D’abord, un peu de statistique de comptoir.

Saviez-vous que 30% des projets sont rendus en temps et en heure ? Seulement 30. Mais où sont passés les 70 autres ? Et bien… 20%n’arrivent jamais à terme et les 50 autres restants trainent parfois sur la longueur, consommant ressources humaines et matériels jusqu’à épuisement total, abandon de poste, et perte d’adhésion. Perfectionniste comme je suis, cette statistique, fournie par un ami qui avait longtemps creusé la question depuis qu’il était passé par 5 SSII pour finir par un cabinet de formation, m’a fait froid dans le dos. QUOI ??? Il existe des projets qu’on ne rend pas en temps et en heure ? Et moi ? MOI,  je devrais potentiellement être dans l’un d’entre eux  au moins une fois sur 3 parce que c’était dame statistique qui l’avait dit ?

Finalement, oui, c’est arrivé. Et dans mes instants de partages et de complaintes, j’ai eue l’occasion de pouvoir collecter l’histoire de plusieurs personnages expérimentés (malgré eux) sur le sujet pour pouvoir définir une liste, non exhaustive, mais relativement complète des signes qui font qu’un projet part dans le mur :

1. Le projet n’est pas un projet. (the cat is not a cat)

Lorsqu’on commence à travailler, il faut savoir pourquoi. Quelqu’un de très avisé me disait dernièrement « sans cahier des charges c’est un NOGO ». Commencer un projet sans savoir ce qu’il doit apporter, pour qui, et sans rien d’écrit quelque part pour sceller cet accord sur la raison et la manière, sont un gage de doutes et de remises en question perpétuels. Un Cahier des Charges, des spécifications, voire une Expression de Besoins sont des simples repères qui permettent de retourner aux basics : je fais QUOI, pour QUI, COMMENT. Et un projet sans devis, c’est un projet bandit manchot, on ne gagne pas le jackpot à tous les coups.

Les projets qui sont ou ne sont pas : «ni  vivants ni morts » comme le chat de Shrödinger dans sa boite, sont aussi quantique que couteux, et bien souvent ils mènent à une courte, voire à une non existence.

2. Le projet sans tête.  (pas de bras, pas de chocolat)

Si aucun intervenant n’est désigné pour être le responsable du projet, le projet est un caillou qui ne roule pas, il amasse mousse et autres saloperies qui l’empêcheront de se dégripper par la suite. Un projet ne se pilote pas tout seul. Un projet, avant tout, a besoin d’entrer dans les esprits comme « le projet est dirigé par… et est commandité par… ».

Pas de responsable de la tâche à accomplir et pas de responsable du besoin métier : Pas de projet.

Pas de bras, pas de Chocolat. Et les projets sans tête sont aussi creepy que sleepy hollow.

3. Le projet pas attendu. (manifeste pour l’avortement)

Parfois, tous les intervenants majeurs sont désignés, mais ils n’ont pas très bien compris le besoin métier, ni le besoin des utilisateurs et exploitants, d’ailleurs, ils n’ont parfois même pas compris que le projet ne répondait pas à un besoin, ni même une envie. Du coup, ils débarquent avec leur projet dans les bras comme un bébé pilule : on s’enthousiasme, on trouve un budget, des ressources, On fait de la pub, un peu de marketing interne, on vante les mérites,  on cherche un « pourquoi FAIRE ? » mais ce n’est pas très clair. On avait de la thune, du temps, des gens, tiens si on la mettait là-dedans, mais sans volonté réelle et propre pour que le projet existe : Il n’a pas la légitimité d’un projet attendu.

Un projet sans besoins clairement définis, ou qui ne répond pas à un besoin exprimé, ne mobilise pas les équipes utilisatrices, et  crée une charge à maintenir perpétuellement pour quelques modules à qui on a trouvé utilité, mais dont on ne se sert pas vraiment.

4. Le projet aventure. (Indiana Jones était Monsieur Seguin)

A part quelques routard endurcis et parfois inconscients, personne ne choisit sa destination de vacances au hasard. On n’entend pas souvent un collègue de travail annoncer la bouche en cœur « Tiens, si je partais pour la Lybie, y’a des billets pas chers sur SuperJet et derniereseconde.conne ». Par contre on entend tout de même encore quelques « tiens, si on faisait une étude de ce projet », ou « tiens si on répondait à ce pitch, on verra plus tard si on sait faire, et si on a les moyens de faire ». A la fois, il faut ouvrir son esprit à la nouveauté et conquérir de nouveaux marchés, ou de nouvelles technologies, à la fois, il ne faut pas s’aventurer trop loin là où on n’a pas pied, en se leurrant par quelques cordes de sécurité qu’il n’y aura pas d’impacts.

Un projet psychanalyse où on cherche le sens de sa profession et de son activité en tentant toute sortes de nouveautés, est un projet tenu par une laisse autour d’un poteau. Un jour, à force de spiraler, le poteau fera office de mur.

5. Le projet délicat (ou comment appréhender la médecine avec Docteur Maboule)

On est toujours tenté de se dire qu’on connait son métier, qu’on en a vu d’autres, et qu’on a déjà fait du quick and dirty mais qu’on a bien menés à terme des projets, même dans des situations délicates, et qu’on a roulé sa bosse, ce projet ne va pas dans le mur, on en a vu d’autres et des pires. Mais voilà le projet est parfois plus délicat qu’il n’y parait. Le client est plaintif, le chef de projet a de gros doutes, et le petit personnel refuse d’opérer, nul doute c’est un projet docteur maboule : Une grosse pince, de toutes petites encoches, des organes en plastiques, et un buzzeur très très fort. On se marre mais sur la table le projet et les ressources agonisent, et le client est perpétuellement insatisfait.

Lorsqu’un projet montre des signe de fatigue, d’épuisement et ce dès le départ, qu’il commence à se couvrir d’ecchymoses et que le client commence par se plaindre, comdamne le projet de fait, que vous soyez grand spécialiste ou pas.  Un projet dont on n’écoute pas les symptômes est un projet malade. Et si en plus on opère malgré tout, c’est un projet avec de très faibles chances de survie.

6. Le projet est en panique (Le sapin de noël était un Jirophare)

Le projet panique n’est pas très loin du projet délicat : le chef de projet vrille les oreilles à force de remonter des warnings plus ou moins factuels, les ressources sont en modes pompiers à éteindre des feux à n’importe quelle heure du jour et de la nuit, Le client est un distributeur de poudre pour spectacle pyrotechnique à force de répéter que tout est inadmissible, et le management regarde ne s’intéresse à cesser ce spectacle de western que lorsqu’il reçoit des balles perdues.

Le projet panique est  une bonne méthode pour appréhender le mur en 1000 images par secondes. On est noyé dans une multitude de détails parfois signifiant qui font oublier la collision finale : le mur : c’est un crash test où peu survivent.

7. Le projet est mésestimé (sauvez une marmotte mangez un castor)

Par manque de connaissance, et parfois par surestimation de la capacité, un projet est lancé en toute confiance alors que son panier à provision est trop petit pour l’ogre, grâce à un commercial zélé. Il parait beau, intéressant, challenge, et audacieux, et puis le client y a vite adhéré.

A moins d’avoir une machine à avenants doté d’un producteur de spécifications fonctionnelles au kilomètre, le projet mal estimé est un boulet au pied sans chocolat dans le papier d’alu pour faire de la marge ou assurer de la sécurité. C’est le projet infinite void ou trou noir par excellence.

8. Le projet part dans le mur. (Précepte de la raideur cadavérique)

Je voudrais pas jouer à Captain Obvious, mais lorsque ça ressemble à un canard, que ça a des plumes de canards, que ça fait coincoin comme un canard et que ça batifole au milieu de la mare avec plein de petit cannetons autour… C’EST UN CANARD !!!

Si votre budget fond comme neige au soleil, que le projet ne montre pas de signes d’avancements flagrants, que les utilisateurs ou client n’y adhèrent pas, que les ressources ne sont pas motivées voire se refusent à bosser dessus,  point de mirage ici : vous êtes bien en présence d’un projet qui part dans le mur ! Alors, même si vous êtes au milieu de nulle part, dans un désert ou au milieu de l’océan, et que comme Christophe Colomb ou Moïse, vous ne pouvez faire autrement que de faire marche avant, sans vous retourner, vous pouvez au moins abandonner le but principal du projet, pour vous reconvertir dans une conquête prophétique ou avant-gardiste, en faire un projet formateur, ou une quête spirituelle.

Le projet qui part dans le mur de manière annoncée ne génère qu’amertume et rancoeurs, on y cherche des coupables, quelques rustines pour ne pas dire qu’on a laissé coulé, mais c’est un projet sans destination. Le projet est mort, vive le projet.

9. Le projet est à l’abandon. (Au revoir poisson rouge)

Lorsque les ressources sont démissionnaires, que le client ou le demandeur ne rappellent pas (à tel point que vous connaissez son annonce de répondeur par cœur, et que vous êtes persuadé de filer dans sa boite à Spam) et que vos collaborateurs et supérieurs, changent de sujet lorsqu’on parle de votre projet, c’est que votre projet est déjà relégué au rang d’inutile, inexistant, inefficient. (voire chiant)

Pas de secret ici, un projet mort, est un projet qui a fait corps avec le mur bien avant l’impact, c’est un poisson rouge dans les toilettes, on attend quelqu’un pour faire la prière avant de tirer la chasse.

10. Le projet bullshit (Le syndrome de Stalingrad)

Je terminerais donc cette saga par une parenthèse historique qui m’a aimablement été soumise d’une main preste, pour vous conter l’histoire des hordes nazies (oui j’assume mon penchant pro-soviétique, comme tout le monde je préfère être du côté des vainqueurs) qui sont allé s’entêter sur Stalingrad alors qu’elles n’en avaient pas besoin…

Pendant que les allemands s’acharnent a essayer de prendre la ville, poussant toute leur troupes  à l’Est, les russes se massent patiemment au Nord et au Sud attendant de pouvoir prendre l’ennemi par derrière et par devant : dans une tenaille écrasant quelques milliers de soldats allemands affamés, et privés de munitions depuis 3 mois dans un froid à pas sortir mémé.

Post mortem : La bataille de Stalingrad commence en septembre et dès le mois d’aout (!) Hitler annonce qu’il craint une offensive russe partant du Nord de Stalingrad et qui priverait ses troupes de leurs arrières. Il se se l’est dit et répété, mais, va savoir pourquoi, il n’a jamais fait ses plans que sur une offensive en décembre et d’une portée limitée (Alors que les russes ont lancé une super grande offensive dès début novembre)

Le problème c’est que pour prendre la ville il aurait fallu un pont car le principal problème de cette offensive fut le ravitaillement : jamais assez de munition pour trucider les popovs qui malgré les 50.000 obus qu’on leur envoyait sur la gueule tous les jours (48.000 seulement en vrai, il faut toujours que j’exagère) refusaient de partir.

Mais la construction de ce pont : ça aurait ralenti la machine de guerre pendant une dizaine de jours.

Alors pépère Hitler s’est dit, par un raisonnement discutable, qu’en persistant à envoyer continument une quantité insuffisante de munitions et de vivres il parviendrait à son but quand même et qu’une fois la ville conquise il pourrait faire construire le pont (…pour amener des munitions pour conquérir la ville, logique quoi). Bon et puis dans son entêtement la conquête a mis plus de temps que prévu, et comme ça coutait de plus en plus cher, il a décidé qu’on allait économiser sur les trains de fournitures et de matériels alors que l’hiver approchait et que c’était déjà insuffisant.

Bref pour conclure, quand un projet va foirer on le sait toujours un peu, on décide de prendre le risque quand même mais on gère mal, parce qu’on pose mal les problèmes et SURTOUT parce qu’on garde nos illusions, qu’on confond nos désirs (prendre vite la ville) et la réalité  (c’est pas possible sans construire un pont et sans se préparer pour l’hiver).

Un grand merci à Laurent, Vincent et Ereinon qui ont rendu possible cet article.

Techniquement Impossible

Il n’existe rien, mais alors rien, de techniquement impossible, ou bien si, peut-être, d’avoir une chasse d’eau qui ne fuit pas, ou que le papier toilette soit correctement découpé (c’est agaçant ça !), mais non, concrètement, et si on cherche bien, il n’y a rien de techniquement impossible, c’est connu, la technique résout TOUT, connait TOUT, sait TOUT faire, et bien sûr aucun problème pour vous faire une machine de Rube Goldberg pour qu’en plus de vous griller les toasts et de vous caresser le petit doigt, la technique puisse répondre à votre besoin, et aux objectifs correspondant.

Sauf qu’il y a toujours, et forcement quelques problèmes humains, budgétaires, et équipementiers qui peuvent être à l’origine d’un blocage dans une réalisation technique et qui peuvent amener les équipes techniques à vous répondre la phrase terriblement irritante « C’est techniquement impossible ».

Faisons donc un petit tours des paramètres à prendre en compte :

– Est-ce que les équipes réalisatrices ont les compétences ADEQUATES pour réaliser ?

Pour cela il faut donc s’intéresser à l’humain, et accepter d’entendre que « ben non, on l’a recruté mais il ne sait pas encore faire, et s’il doit apprendre, ça prendra plus de temps que s’il savait déjà le faire » (c’est un peu le principe du boulot, en particulier en matière technique : 40% de réalisation 60% de recherche, si vous n’êtes pas prêts à accepter ce ratio, vous êtes techniquement et cérébralement pas équipés pour faire un métier dans la technique –oui franchise- le principe du recrutement, c’est de chercher du terreau, un bon terrain pour apprendre, et non uniquement un bon terrain déjà fertilisé et prêt à l’usage dès le jour 1 et cela ad vitam aeternam, jusqu’à ce que la mort vous sépare.

=> Les gens qui ont terminé de chercher et qui savent tout faire ne sont jamais uniquement et exclusivement des opérationnels (ou bien la vie a été honteusement cruelle) et se retrouvent à des postes de management qui leur permettent de transmettre tout leur savoir à défaut de le mettre exclusivement en oeuvre -ce qu’on appelle la séniorité-.

Parfois, « techniquement impossible » peut vouloir dire « techniquement impossible pour les ressources qu’on a ».

  • Là ne soyez pas stupides : celui qui ne connait pas la capacité de ses ressources et un mauvais gestionnaire.

– Est-ce que les équipes réalisatrices sont disponibles ? Sont-elles disposables à volonté comme des petit lutins dans une mine de poudre ou rentrent-elles parfois dormir, avoir une vie privée, ou partent-elles en vacances ? Existe-t-il aussi d’autres projets ou sujets sur lesquels elles sont allouées et sur lesquels on ne peut les débooker ?

Parce que « machin peut le faire » du verbe POUVOIR comme ETRE CAPABLE DE , ou AVOIR LA COMPETENCE DE ne remplace pas « machin est disponible pour le faire » du groupe verbal  ETRE DISPONIBLE, il faut se mettre dans l’idée que le booking est un art de la gestion des contraintes de disponibilité.  Dans l’optique du client qui veut tout, tout de suite, maintenant, il faut revenir à l’air de la couche culotte : Pour faire caca, soit on attend d’aller au pot, soit on porte une couche qu’il faut être prêt à assumer. 80% du temps le « tout prêt tout de suite » si c’est bien fait : a été judicieusement anticipé, si c’est mal fait : a été réalisé selon la demande dans un temps impartis trop court et avec ce qu’on appelle du QUICK AND DIRTY.

Parfois donc « techniquement impossible » peut vouloir dire « techniquement non viable » ou techniquement irrecevable pour un MCO correcte ».

  • Et là ne soyez pas trop bêtes, ne pas se projeter dans l’avenir c’est être un mauvais gestionnaire.

– Est-ce que le budget pour réaliser est suffisant ? Dans un monde parfait, on rédige des specs AVANT de réaliser. On les valide aussi avant. Cela permet de voir réellement le périmètre d’une réalisation, avec une marge de risque, et donc de déterminer, le plus justement possible le budget à impartir sur ce sujet.

Donc si on a plus de sousous, il faut toujours se poser la question de qui est la poule qui pond des œufs d’or, où qui trouve les arc-en-ciel (qui, comme chacun le sait, renferme à ses pieds des trésors qui sortent de nulle part).

Parfois, répondre donc « techniquement impossible » peut aussi vouloir dire « financièrement impossible ».

  • Et là… Ben rien, je vous réexplique pas le truc du gestionnaire qui sait pas gérer les sousous.

– Est-ce que les équipes réalisatrices ont les moyens matériels et techniques de réaliser ? Parce que la réalisation ne se limite jamais uniquement à l’humain mais bien à l’équipement aussi, il faut se poser la question de la possibilité technique de réaliser. Les équipes rélisatirices ont les bons process, le moyen de récupérer l’encours facilement et techniquement, les logiciels, et matériels pour réaliser, tester, traiter au sens large ?

Alors c’est l’histoire d’un Ingé qui avait un vieux PC, avec des outils vieux de 10 ans, et des serveurs-rameurs qui ne connaissaient pas le RAID, et une petite pièce sans fenêtres où il travaillait 15h /j avec une connexion internet intermittente limitée à superDico.com et le site corporate de sa boite et dont les managers avait décidé qu’il allait développer (tout seul hein) des applications pour le tout nouvel outil que la planète convoite : une puce intra cérébrale. Oui, c’est caricatural, enfin je ne grossis pas tant que ça le trait.

Parfois « techniquement impossible » veut VRAIMENT dire « techniquement impossible » et il faut vous y faire, ou changer la politique des « moyens généraux », des « autorisations réseau » (etc…)

  • Alors c’est l’histoire d’un gestionnaire ….

En conclusion. Non, la technique n’est pas d’une honteuse mauvaise foi, et n’a pas envie de rien faire, ni n’a pas forcement que des bras dans le plâtre : lorsqu’elle vous annonce qu’une chose est techniquement impossible, normalement, elle a des arguments, que vous avez le droit de demander mais que peut-être vous ne comprendrez pas ou que peut-être vous comprendrez mais refuserez parce que vous en avez marre que votre client insatisfait ne connaisse que les foudres de ZEUS pour s’adresser à vous.

Je ne saurais vous répondre qu’une chose : Faites-vous une raison avant que d’envoyer au bûcher la technique, se faire le relais de la torture n’est pas un mode de management qui tiens sur la durée et la qui peut compter sur la fidélité des gens, mais 1. Consultez-la plus souvent, parfois  elle permet d’anticiper ce genre de problématique et de vous fournir les arguments pour 2. Donnez les moyens de faire, en matière de ressources humaines et matérielles (et donc financières !) 3. Parfois invitez la technique et ses représentants les plus pertinents et les plus au fait de la situation à se joindre aux réunions ou réponses aux clients (même si parfois, le tekos qu’on invite c’est un glapion à qui il manque un œil et qui marche en boitant)

Sinon, ben, regardez un bon film, faites-vous faire un massage des pieds, ou commandez un gâteau au chocolat… ça détend.

Et Dieu Créa l’Agilité pour les projets…

Au départ, au commencement, la gestion de projet Agile c’était meugnon, plein de grands principes et de jolis propos, visant à rendre une meilleure et plus rapide qualité de service, de faire apparaitre plus vite des outils… Ben oui, au lieu de faire de gigantissimes expressions besoins, des spécifications à n’en plus finir, des cas d’utilisations discriminant, et déterminant, à la pèle en veux-tu-en-voilà , le tout pour partir gentiment en excursion sous marine de mise en œuvre pour parfois revenir, au mieux, en ayant été oubliés (mais payé) ou, au pire, en ne correspondant plus aux attentes qui avaient évoluées entre temps (les coquinoutes), on pouvait alors prôner l’Agilité, la Souplesse, le Dynamisme ! Et c’était aussi émouvant que la déclaration d’indépendance, que l’abolition de la l’esclavage et que l’invention de la roue.    

Les développeurs étaient  tout le temps, à s’agiter sous les yeux d’un représentant métier et à lui demander tout plein de choses à faire, et le chef de projet passaient son temps à poser des questions  ça donnait la garantie certaine qu’ils bossaient et qu’ils essayaient au mieux de répondre aux besoins…  

Oui mais voilà, du coup, il a fallu mettre en place des modes de fonctionnement très très rigoureux, parce que le manifeste qui disait que la « collaboration des parties » devait prendre le pas sur la contractualisation, a fait déborder un peu les caprices de la clientèle dans des proportions budgétaires aussi hasardeuses qu’exponentielles.

C’était de fait, donc, plus cher mais au moins là du coup, on savait dans quoi on dépensait, puisqu’on le suivait à la semaine parfois à la journée, alors open-bar on faisait sa liste de course et en toute mauvaise foi on osait dire que les développeurs, qui travaillaient déjà comme des chevaux de poste qu’on remplaçait régulièrement, tellement on les usait moralement, n’en faisaient pas assez dans le périmètre du projet.

Et c’était bien là tout le problème. Le périmètre du projet n’étant défini que dans ses grandes lignes, il devenait le tonneau des développeurs à défaut de celui des Danaïdes.

Ce qu’on tricotait avec ses petits doigts de développeurs, un jour, on le détricotait le lendemain pour faire une autre partie. A la fin, on était à la fois plus tellement sûr de réaliser un pull-over tellement on y avait mis de poches, de raccords, de bout de laines ou de ficelles, de ci de là et on avait tellement découpées de parties, remplacés des bouts par d’autres, que la cohérence technique ET fonctionnelle de l’ensemble en pâtissait, mais on était un peu incapable de comprendre comment on en était arrivé là, puisqu’on avait quand même assigné des chefs de projets qui étaient sensés assurer la maitrise de l’ouvrage, et donc, tout l’équilibre de l’ensemble…

Vite fait bien fait, il a donc fallu mettre en place un mode de gestion budgétaire tangible, compréhensible, pilotable, et à défaut d’un processus (puisque le manifeste encourageait plus à la compréhension humaine qu’à la rédaction de spécifications) mettre en œuvre une méthodologie et une flopée de bonnes habitudes :

Dans les grandes lignes ça a donné ça :

Phase 1 : Définir un périmètre fonctionnel à grosse maille, et un pré-découpage fonctionnel rapido –et les chiffrages correspondants) –Et demander la production en conséquence d’un budget pour cela.

Phase 2 : Prévoir le bas de laine : laisser quelques cases vides avec de quoi faire dedans, pour les fonctionnalités supplémentaires à venir (inévitablement) –et les clients, quand ils peuvent faire quelque chose, ils auraient tort de se priver, alors ils font-   

Phase 3 : Surveiller, quotidiennement la consommation des ressources et vérifier la cohérence entre la vélocité des équipes, le consommé, le reste à faire, et les briques fonctionnelles (et là tous les outils sont bons pour réaliser cela : de votre cerveau en passant par votre calculette, votre tableau Excellent, ou votre pur outil de gestion de projet qui envoi du poney),

Phase 3.1  s’affoler vigoureusement si à 1/3 du budget, 1/3 des fonctionnalités n’ont pas été réalisées. –à noter que s’affoler vigoureusement, ne consiste pas agiter les bras frénétiquement mais bel et bien de faire un rapport d’identifications des raisons du retard, et d’en avertir le client-

Phase 4 : A 2/3 du budget consommé, procéder à un contrôle rigoureux du Reste A Faire (le RAF) et des fonctionnalités ajoutées dans les cases vides, et déterminer s’il faut rentrer en phase 5.

Phase 5 : Commencer à faire de la gestion des priorités –et donc commencer les exclusions voire la chirurgie- et/ou à demander à nouveau du budget.  

(Bon, ça ne s’applique pas si vos budgets sont infinis, vos clients adorablement réalistes, vos investisseurs peu exigeants, et que le monde autour de vous est peuplé de Bisounours)

Et en contrepartie ça obligeait :

– A chaque nouvelle « évolution » demandée par le client, à défaut de la refuser, de tracer les changements (et donc de quantifier les impacts (non, les méthodes agiles ne réduisent pas le temps de travail, surtout pas du Chef de Projets) pour pouvoir faire un ratio du Delta entre ce qui était prévu à T0, ce qui s’est passé à T1, T2, T3…TN et à faire la différence finale entre TN et T0 pour en apprendre un peu plus.

– A accepter que les temps de réalisation que vous aviez communiqués étaient a) Soit compressibles (et du coup, un tout petit peu bidons ;)) b) Soit incompressibles (et du coup, un tout petit peu pas réalistes) c) n’étaient pas les éléments sur lesquels on devait faire reposer la « dynamiques » de la gestion de projet agile, mais uniquement les bonus de celle-ci. –je vous laisse réfléchir sur quoi on plaçait la souplesse alors ;)-

A Ranger sa timidité ET son stress au placard pour communiquer, collaborer et joyeusement interagir avec les équipes techniques mais aussi ne pas leur transmettre de parasites (entendez sollicitations directes qui auraient pu être évitées), parce que déjà bien assez sollicitées (même si bon, c’est connu, les teckos sont des gurus, et on ne leur confierait pas ce travail s’ils n’étaient pas experts ( ?!) –Mais oui, ayez la foi… et, si vous n’avez pas la foi : persuadez vous !-)

– A apprendre à dire « non » en souriant, ou à répondre « ok pour ça, mais du coup, on doit retirer quelque chose, on enlève quoi ? » comme on faisait avant, sans Agile, et qu’il fallait placer son sacro-saint « oui, mais » dans les conversations avec le client.

En conclusion, agile c’est ni mieux ni moins bien que les méthodes de gestion de projet « classiques », c’est différent, cela dit, ça ne doit pas empêcher d’avoir un peu de rigueur, et donc d’en connaitre les écueils.