35 ans et toujours pas de Rolex

Quel merdier! Mes 35 ans se rapprochent à grands pas et avec eux l'heure du bilan de parcours. C'est vrai ça. Quand j'y repense, à 20 ans, j'étais ignorant. A 25, j'étais prêt à bouffer tout le monde pour avancer. A 30, mon plan diabolique des 25 ans avait en partie marché et je savourais ce que j'avais réussi à faire. Et à 35 alors? Bah rien! Plus de progression depuis quelques temps. J'ai l'impression d'avoir fait un peu le tour de mon métier. Dans une certaine mesure, j'ai même l'impression de régresser. De toute façon, il ne faut pas se voiler la face : à 35 ans, mon positionnement général dans mon domaine métier est fait. Les managers sont déjà managers, les commerciaux sont confirmés et les geeks sont des barbus.

Un truc sympa avec les réseaux sociaux, c'est de pouvoir regarder le parcours de nos anciens amis et collègues de la vingtaine. Tant qu'à faire, il ne faut pas hésiter à rajouter nos vieux amis dans la marmite, ce qui sont toujours là en chaire et en os. L'idéal même, c'est de leur proposer de regarder un peu en arrière avec vous. C'est un petit jeu auquel j'ai joué l'année dernière. Dans mon petit cercle d'amis (tous sortis de la même école), nous voulions tous monter notre boite. On avait même essayé à l'époque (2001) . Et finalement, voilà ce qui s'est passé :

Le premier a monté sa boite. Respect. Il a quelques salariés. Il travaille comme un fou, a deux enfants. Sa moitié a arrêté de travailler pour se consacrer aux enfants. Il faut dire qu'il est toujours en déplacement. Il a un bel appartement en centre-ville et visiblement pas le temps de faire autre chose que la gestion de son entreprise et son boulot.

Le second vient de divorcer. Son auto-bilan semble avoir été plus violent que les autres. Il s'offre un nouveau départ : changement de région, changement de boulot, changement d'amis (pas tous quand même - déconne pas...). C'est un "sérial bosseur". Il est parti dans le management et s'y est investi à fond. Il loue un appartement sur Paris. C'est le "George Clooney" de notre groupe. Il est libre comme à 20 ans mais avec de l'expérience et de l'argent en plus.

Les troisième et quatrième (dont moi) sont de simples salariés. Propriétaires de leur maison, des enfants en prévision ou déjà là. Ils n'ont pas beaucoup de pression dans leur travail ce qui leur permet de dégager du temps libre pour... pour... ah oui... pour faire tourner leur bétionnière (travaux obliges).

La question qui vient juste derrière est : avons-nous réussi nos choix de vie?

Notre entrepreneur aimerait bien avoir une maison et du temps comme les deux salariés. Il me semble que sa boite commence à être pesante et qu'il aimerait bien s'en détacher. Pour ma part, je le regarde avec un peu de regret de n'avoir pas moi-même tenté la création d'entreprise. Notre "George Clooney", quant à lui, a carrément fait un "reset" total. Je crois donc qu'aucun d'entre nous n'a complètement réussi sont choix de vie. Par contre, une chose est certaine, chacun a fait un choix à un moment ou un autre.

Alors quid de l'entreprenariat? Je discute régulièrement avec une amie qui a les deux casquettes : salariée et entrepreneur. Et notre avis est clairement tranché : quel confort d'être salarié. Quel bonheur de ne pouvoir se consacrer qu'à son métier (à condition de l'aimer bien sûr). En revanche, pas question de s'endormir sur nos lauriers. Il faut bouger d'entreprise sinon le risque est de voir l'ennui s'installer et la motivation s'envoler. C'est un peu mon cas en ce moment. Il va peut-être falloir bouger...

Quid du salariat? J'ai un contre exemple sur le "bonheur du salariat". Un ami très expérimenté va de boite en boite et de déception en déception. Il n'arrive pas à trouver LE projet qui lui convienne. Dans son cas, c'est peut-être la création d'entreprise qui lui faudrait. Mais avec deux enfants et un crédit sur la maison, le choix de se lancer n'est pas trivial. Je crois que cette question se reposera quand les enfants auront grandi et que la maison sera payée.

Après réflexion, j'aurais donc tendance à penser que l'entreprenariat se fait mieux à la vingtaine ou à la quarantaine. Pour les autres périodes, le salariat semble idéal. Enfin non... l'idéal, c'est d'être rentier (mais restons réalistes).

Et la Rolex dans tout ça? Et bien pour un codeur salarié comme moi, je crois que la Rolex, c'est d'avoir le pouvoir sur la technique, de pouvoir dire merde à son manager quand on n'est pas d'accord avec ses choix et d'avoir le choix de son entreprise. Pour le reste, c'est bien connu : l'informaticien n'a que faire des horaires. Alors pourquoi s'embarasser avec une montre?

Des specs sur un grain de riz

Ce n'est pas une nouveauté, les spécifications sont souvent montrées du doigts à chaque dérapage d'un projet informatique. Je ne sais pas pour vous mais dans mes différentes expériences, j'ai souvent eu à faire à des specs tenant intégralement sur un "Post-It". C'est un classique. Pire, dernièrement, j'ai même eu à faire à des specs écrites sur un grain de riz. Comme me l'a fait remarquer à juste titre un collègue : "tes specs, c'est le titre de ton projet". Bien vu! Alors, pourquoi n'arrive-t-on pas à avoir ce type de document? Quelle est sa taille optimale? A quel niveau de détail doit-on aller?

Pourquoi n'arrive-t-on pas à avoir ce type de document? D'abord, posons nous une autre question : qui doit rédiger les spécifications? Le client? Le chef de projet? Le développeur?(oups!)... Dans mes différentes expériences, c'est celui qui était demandeur du produit et qui maîtrisait le mieux le métier qui rédigeait son expression de besoin. Par exemple, chez un éditeur, c'est le chef de produit qui me fournissait généralement ce document. Pour d'autres collègues qui réalisaient des développements "plus métiers", les consultants-formateurs étaient mis fortement à contribution tout simplement parce qu'ils avaient un contact très rapproché avec les utilisateurs et donc une connaissance très "terrain". Cela peut-il être le chef de projet? Oui s'il a et prend le temps de s'investir dans le métier de son projet. En tout cas, je crois qu'il est bon d'ailleurs que le chef de projet soit moteur dans cette action et qu'il aide son client à spécifier ses besoins dès lors qu'il n'y a pas d'assistance à maîtrise d'ouvrage (généralement dans les petites structures). Il en est de même pour le développeur qui peut aider son utilisateur à la rédaction (Attention, le développeur ne peut pas être mandaté pour rédiger seul les spécifications,. Ce serait un non sens). Dans tous les cas, le rédacteur doit avoir une coloration informatique (ou bien de se faire aider par quelqu'un qui en a une) pour produire un contenu exploitable par le développement.

Mais alors, pourquoi n'arrive-t-on pas à avoir ce type de document? Et bien appelons un chat "un chat" : la rédaction des spécifications peut-être d'un ennui considérable. Il faut comprendre le métier, en faire une rétro-analyse, extraire toutes ses règles de gestion. Tout ça prend du temps. Et ce temps, le métier ne l'a pas forcément car il doit continuer à produire. D'autre part, les processus de travail ne sont bien souvent pas décrits. Honnêtement, vous en avez vu des documents décrivant les cycles de travail d'un service? Chacun y va de sa petite adaptation et c'est naturel. Bref, il est plus facile de jeter quelques phrases pendant une réunion (voire dans un couloir) pour expliquer ce dont on a besoin. D'où les specs "Post-It" mondialement connues mais malheureusement insuffisantes pour produire une application car elles laissent trop de zones d'ombre au développeur. Pire, elles permettent de s'engouffrer dans ce "no spec land" et d'inventer un métier qu'on ne connait pas. Résultat : la qualité attendue n'est pas au rendez-vous et cela donne lieu à des aller-retours avec le développement, des retards de livraison et des coûts explosifs, etc, etc...

Quelle est sa taille optimale? J'ai tendance à croire que des spécifications doivent être synthétiques. J'ai déjà eu un cas dans la vraie vie où les spécifications faisaient 300 pages. Ca arrive... Le développeur a reçu cela comme un pavé dans la figure (Karine, si tu te reconnais...) . Donc, soit le rédacteur est un littéraire et n'a pas compris que la valeur artistique de son document n'est pas l'objectif du travail demandé, soit il n'a pas l'esprit de synthèse. Il faut l'aider à reformuler sa demande. Il peut aussi s'agir d'un métier trop gros à décrire et là il faut découper le projet en sous lots car, de toute façon, le développeur ne retiendra pas le contenu de ces 300 pages. Dans la plupart des projets que j'ai rencontré, 10 pages par lot sont généralement suffisantes.

A quel niveau de détail doit-on aller? Là encore, je crois qu'il faut être synthétique. Dans une de mes précédentes entreprises, nous avions mené un travail sur le contenu des documents de spécifications. Nous avions pris partie de remplacer des pans complets de texte par des diagrammes UML. Par exemple, montrez les composants du projet dans un diagramme de classes. Montrez ensuite leur comportements à travers de diagrammes d'activité. Ne cherchez pas à respecter la norme à fond pour aller jusqu'à la génération de code. Enrichissez plutôt vos diagrammes avec des commentaires. Il peuvent d'ailleurs décrire des règles de gestion. Donnez leur alors des numéros, des codes. Je me fais un peu de pub au passage en vous rappelant que vous pouvez faire tout cela rapidement avec Violet UML Editor. En tant que développeur expérimenté, j'aime bien avoir des maquettes dès lors qu'une interface graphique doit être produite. Un powerpoint est largement suffisant pour cela. Enfin, je pense que la démarche de spécification doit être itérative. On ne peut pas tout décrire d'un seul trait. C'est d'ailleurs ce que préconise SCRUM. Produisez un document de spécifications générales et et détaillez le à chaque étape d'implémentation. Vous aurez en plus économisé votre énergie si vous décidez finalement de ne pas tout réaliser.

Que peut-on en conclure? Que des specs "grains de riz" ne sont bien évidemment pas acceptables car elles coûtent cher à l'entreprise en temps et en argent. En tant que développeur, nous pouvons être acteur de notre bonheur ou de notre malheur. Précisons ce que nous attendons en terme de documentation et exigeons une spécification générale. Si le projet démarre sans, organisez une réunion pour l'obtenir. Les "Post-Its" ont la peau dure mais nous finirons bien par nous en débarrasser!

Un projet, des points de vue

Ce que j'aime dans les projets, c'est qu'on fabrique quelque chose. Quand on y pense, c'est beau de voir toutes cette effeverscense, les gens qui bougent, les esprits en fusion. Ce qui est aussi intéressant, c'est de voir les différents points de vue des acteurs d'un projet. C'est un peu comme au cinéma. Il y a en a qui aime se mettre en bas pour être immergé dans le film et d'autres qui préfère les sièges du haut pour avoir une vue d'ensemble. Et bien c'est un peu pareil en entreprise.

Par exemple, le codeur (au hasard...) est focalisé sur la conception technique du produit. Il a deux niveaux de vision : de près et de loin, tout en restant proche du sol. Je m'explique. De près, il a le nez dans son application. C'est un peu normal, il la code. Néanmoins, il lève très souvent les yeux pour regarder au loin. Non pas pour admirer le bleu turquoise de la cloison qui le sépare de son collègue d'en face mais pour projeter son application dans le futur. Comment se comportera son code à la première demande de changement? Son application sera-t-elle facilement évolutive, migrable? Bref, c'est la hantise du concepteur : concevoir un truc bancal. A tel point qu'il regarde parfois tellement loin qu'il arrive à des équations en rupture totale avec l'espace-temps. Dans ce cas symptomatique, il s'aperçoit généralement à la fin de la journée qu'il n'a rien produit! Et ça, ça coûte très cher à l'entreprise en argent et très cher au développeur en satisfaction. Bref, malgré ce regard porté au loin, le codeur reste souvent au niveau du sol. Je veux dire par là qu'il reste principalement au niveau technique de l'application. Et c'est un peu normal : comment pourrait-il imaginer ce que deviendra le métier de son client? D'abord, son client sait-il lui même ce que sera son métier demain? Moi, quand j'achète une perceuse, c'est que j'en ai besoin maintenant. Si, dans un an, il m'en faut une plus puissante, j'en achèterai une autre. De plus, le codeur n'a pas une vision globale du métier de l'entreprise. Du coup, il prépare son application à recevoir l'inconnu. Et même s'il sait que ça coûte cher à l'entreprise sur le moment, il a la conviction de la préparer à l'avenir (d'autant plus qu'elle n'accepterait pas de refaire toute l'application à la première demande d'évolution un peu carton). Reprenons pour résumer : codeur = visions de près et de loin proche du sol.

L'utilisateur, lui, a plutôt une vision intermédiaire. C'est le gars qui va chez Renault et qui fait trois fois le tour de la Mégane. Il monte dedans, touche les boutons. Il se fout de savoir si la voiture a un des disques de frein ventilés sans amiante patin, couffin, etc, etc... Il est très factuel : la Mégane, c'est une voiture (oui oui). Se projeter dans l'avenir de la Mégane, ce n'est pas forcément son truc. Seul hic, le modèle qu'il souhaite avoir n'a jamais "l'Option" qui déchire. Il est soit frustré parce que son application ne fait pas ce qu'il veut, soit résigné parce qu'elle n'a jamais fait ce qu'il voulait (c'est pire), soit chiant car il harcèle sans arrêt le service informatique. Dès fois, il est satisfait. Quand c'est le cas, il faut savourer ce moment d'exception. Sa vision est aussi quelquefois bouillonnante. Il s'aperçoit en pleine recette de l'application qu'elle pourrait faire ceci... et cela... et puis ça... et ainsi de suite. Dans ce cas, il faut sortir son arme secrête : le chef de projet qui dit NON. (Le chef de projet PAS MAINTENANT est aussi assez efficace et moins conflictuel)

Quant au DSI, c'est celui qui a une vision de loin et de haut. En principe, il aime bien s'assoire tout en haut au cinéma. Il regarde de haut ses projets parce qu'il aime tous les voir en même temps. Il les regarde de haut parce que c'est le métier autour de son SI qu'il aime observer. Il regarde aussi au loin pour essayer de préparer l'entreprise à l'avenir. Finalement, la technique l'emmerde probablement royalement. Elle ralentie ses idées. Le rêve du DSI, c'est le développement "PowerPoint" : si tôt projeté, si tôt réalisé. Au quotidien, il trouve ses collaborateurs pas assez "méta", "high level". Le plus terrible, c'est qu'ils ne peuvent pas vraiment l'être car ils dépensent déjà toute leur énergie à se débattre dans la glue de la réalité du terrain.

Mais alors, développeur et DSI ont donc tous deux leur vision de loin du projet? Oui. Sauf qu'elle n'est pas identique, d'où leur sentiment parfois d'incompréhension mutuelle. Ils vivent deux réalités différentes autour d'un même projet. Pourtant, ils ont le sentiment faire l'effort de prendre du recul par rapport au projet. Pas simple.

Quel est donc le dénominateur commun à tout cela? J'ai malheureusement l'impression qu'il est tout petit : juste le métier du projet, son service rendu. Hélàs, vous devez accepter messieurs les codeurs que votre DSI a peu d'intérêt pour la technique du moment que ce service est rendu. Messieurs les DSI, vous devez accepter que la technique est un mal nécessaire et qu'il a un coût en argent et en temps. Messieurs les utilisateurs, vous devez accepter que certaines fonctionnalités ne soient pas développées. C'est donc une affaire de compromis où chacun met de l'eau dans son vin. Les projets informatiques seraient donc condamnés avoir des DSI frustrés, des utilisateurs jamais complètement satisfaits et des développeurs se sentant déconsidérés? Peut-être. Soyons indulgents les uns envers les autres et acceptons d'avancer moins vite, mais tous ensemble dans la même direction. Ca sera déjà pas mal.

Chef de projet n'est pas chef

Petit retour d'expérience. L'autre jour, je travaillais avec un collègue sur l'analyse fonctionnelle d'un projet quand à un moment, il me sort (très sûr de lui) : "demande à ta chef". La fameuse "chef", 25 ans, tout droit sortie de l'école et propulsée chef de projet s'est alors sentie pousser des ailes. C'est en tout cas ce que j'ai ressenti. Il est vrai que ça flatte son égo de se faire appeler chef... enfin... tant qu'on ne s'est pas penché sur ce qu'est être chef de projet. Justement, dans une vie antérieure, j'étais moi même "chef de projet". Je me souviens aussi de mon oncle, très fier de son neveu me demandant de combien de personnes j'étais responsable : "0 tonton, je suis chef de projet, pas des gens avec qui je travaille". Sauf que la frontière est quand même fine. Plaçons nous du côté du développeur. Son responsable hierarchique est monsieur X mais il travaille pour monsieur Y. Pas simple, surtout quand monsieur X lui demande un service alors qu'il est déjà à la bourre sur le projet de monsieur Y. En théorie, messieurs X et Y doivent communiquer pour apprécier le travail de notre développeur, gérer sa carrière, ses absences, etc... Dans la pratique, je ne l'ai pas souvent constaté.

Mais revenons en au "chef de projet". Je n'aime pas la confusion portée par le terme. "chef". Je préfère largement celui de "chargé de projet". Ca peut sembler banal mais je trouve qu'il lève l'ambiguîté ambiante. En fait, j'aimerais que le métier de "chef de projet" soit rebaptisé en "chargé de projet" dans les entreprises telles qu'on les connait actuellement.

Poussons l'analyse un peu plus loin. Finalement, les organisations de nos entreprises sont-elles toujours en phase avec notre façon de travailler? Elles ont souvent été bâties alors que les employés ne travaillaient pas en mode projet. Avons-nous atteint les limites du modèle hiérarchique tel qu'on le connait? Possible. Pour que nos chefs de projet soient chefs tout court, Il faudrait qu'ils recrutent leur collaborateurs, un peu à la manière d'intra-entrepreneurs. L'entreprise serait alors une sorte d'incubateur à projets et offrirait des services d'infrastructure, de paie, etc... Le problème, c'est qu'il y aurait peut-être beaucoup moins de candidat à la gestion de projet qu'il y en a actuellement. Pour le moment, je propose donc d'en rester à nos "chefs de projet" renommés "chargés de projet". C'est peu mais ça serait déjà une progression.

Le mythe du pisseur de code

C'est l'histoire d'un développeur qui travaille dans une grande entreprise (très grande même) où les développeurs sont comptabilisés en ETP (employé à temps plein) sans tenir compte de leurs compétences. Ce gars se retrouve sur un plateau de dév de 50 personnes. Ce n'est pas rien. Lorsque les projets souffrent, on fait rentrer 2, 3, 5 ETP. Quand ils vont mieux, on les fait ressortir aussi vite. Bien sûr, le directeur de projet fait totalement confiance à CSC, Unilog et tous ses beaux commerciaux très "Messieurs de Fursac". Après tout, les CV, c'est bon pour les RH. Après quelques années, le gars part chez un éditeur de progiciels. Là, il découvre des développeurs inertes qui codent comme des lapins en cage. Alors, il leur secoue le cocotier un peu. Il fait des grands gestes devant une direction désemparée car elle ne comprend pas pourquoi les développeurs n'arrivent pas à sortir des fonctionnalités à une cadence "commerciale". Plus tard, notre gars décide de rejoindre un client final, une PME de bonne taille. Et là, c'est le ponpon, La direction qualifie les développements de "visqueux". Le pire, c'est que le gars comprend leur impression mais qu'il n'arrive pas à trouver les mots pour leur expliquer que le développement est un vrai métier d'ingénieur et qu'il coûte cher. Alors que dire à un DSI qui dans un moment de déprime vous demande s'il ne faudrait pas mieux de tout refaire en PHP plutôt qu'en Java? Voilà, je suis fatigué de constater que le mythe du pisseur de code a la peau dure et qu'il n'est pas prêt à rendre l'âme. Et vous, qu'en pensez-vous?