Développeurs, devenez chef de projet

Il y a quelques temps, on pouvait voir pas mal de blabla sur le web qui disait que les développeurs devaient s'affirmer dans leur rôle, qu'on pouvait rester développeur après 30 ans, qu'on n'était pas obligé de passer chef de projet, etc. Belles paroles, peut-être réalistes dans les chez des éditeurs de logiciel, des clients finaux ou en tant que freelance MAIS certainement pas en SSII. Et les SSII, ça concerne 80 % des développeurs.

Alors arrétez le masochisme les mecs. Si vous êtes en SSII, allez le plus vite possible vers le poste de chef de projet (CP pour la suite de l'article because la flemme).

Je vous dis cela en connaissance de cause et parce que je regrette de ne pas avoir maintenu ce choix pour mon projet actuel. Les projets sur lesquels j'ai eu la meilleure expérience sont ceux pour lesquels j'occupais ce poste. Il apporte deux choses pour moi : confiance et liberté. Confiance d'abord parce qu'en devenant CP, j'ai eu l'impression d'arriver dans une communauté de gens éclairés. Je n'étais plus un connard de développeur, j'étais un mec qui avait accès à la stratégie liée à un projet (si merdique soit-elle), au budget, au contrat. Croyez-moi, le regard qu'on vous porte change. On vous donne les rennes du projet et on vous fait confiance, parce qu'on ne peut pas faire autrement. Vos supérieurs ont d'autre chats à fouetter (c'est ce qu'ils disent en tout cas), ils ne seront pas là pour vous materner au quotidien.

De cette confiance jaillit la liberté. Tant que vous jouez le jeu, c'est à dire que vous suivez correctement votre budget, mettez en place les actions qui auront été discutées lors de votre suivi (mensuel) et que le client ne vous perçoit pas comme un psycopathe pervers, vos supérieurs vous foutrons une paix royale.

Le meilleur pour la fin : vous avez accès à votre client. Vous pouvez pousser vos idées au vous aurez accès à toute l'information sur la situation du projet. Ça vaut de l'or.

Après, tout dépend de votre attitude. Votre chef actuel ne comprend pas ce que vous faites, ne soutient pas vos idées et ne tient pas tête au client ? Il a lui-même chiffré le projet et vous mets la pression pour livrer dans ses contraintes non réalistes ? Ça ne donne effectivement pas une bonne image de la fonction. Et heureusement que vous vivez ça : il vous donne l'exemple à ne pas suivre.

En tant que développeur expérimenté et passionné, vous avez tout pour faire un bon CP. Vous savez estimer sans trop vous planter en prenant en compte le fait que des développeurs junior vont faire le taf (car vous vous rappelez comment vous étiez à leur place), les développeurs vous font confiance et vous avez déjà prouvé votre valeur à vos supérieurs. Le gros plus est que vous savez ce qu'il y a à faire, vous connaissez le domaine métier sur lequel vous travaillez (ou êtes à même de monter en compétence dessus à la vitesse de la lumière) et êtes à même de mettre les mains dans le cambouis si nécessaire pour sauver la situation.

Les tâches de suivi ne sont pas compliquées à faire. Sur mon projet précédent, le suivi du budget me prenait entre 30 min et 1h par mois. Je passais 1h en suivi de projet hebdomadaire avec mon client. Pour le reste, je faisais de l'encadrement technique, de la conception, du chiffrage, de l'indus. J'étais seul membre expérimenté de l'équipe. Bref, j'occupais 80 % de mon temps sur des tâches de développeur confirmé. Surtout parce que j'ai un mal fou à déléguer :p. Et j'ai pu développer des supers outils dans les technos qui m'intéressaient pour me faciliter la vie. J'avais pas mal de boulot, mais prenez en compte le fait que je bossais au 4/5e.

Pourquoi rester développeur ? À plus de 30 ans, vous êtes sur un échelon trop élevé : vous coutez trop cher. Si vous avez un temps soit peu d'XP sur une techno donnée (genre du PLSQL ou mieux, du Cobol), vous pouvez être sûr qu'on va essayer de vous bloquer en régie sur cette techno à perpétuité. C'est ce que je ferais en tout cas : je négocie un bon TJM et je vous place. Vous êtes bon : le client ne se plaindra pas parce qu'il a l'habitude de se voir refourguer que des clampins par vos concurrents. La conséquence de ça est que vous allez voir un beau gel de salaire. En plus vous bossez sur des technos de merde. Franchement, de ce que j'ai connu, il n'y avait rien de bandant. Considérez que vous n'allez jamais travailler sur une tech qui a moins de 10 piges (même s'il peut y avoir des exceptions, bien sûr). Oubliez Angular, Mongo et Node. Pensez Cobol, ksh, Java 1.5 et .Net 3.5. Sans déconner : pourquoi se faire chier !?

Pour conclure, réfléchissez-y. Retrouvez un peu de liberté et accédez à un meilleur salaire tout en gardant un pied dans la techno. Innovez par rapport à vos chefs précédents qui n'ont rien compris à la gestion de projet et d'équipe. Mettez en place du Kanban si ça vous fait réver. Dites merde à votre client quand il le faut. Rester développeur en SSII ? J'ai essayé et je le regrette. Pour moi c'est terminé.

Allez, prenez soin de vous et à la prochaine.

Architecte

J'ai récemment assisté à une formation d'architecture sur le framework maison. J'étais super enthousiaste. À vrai dire, je ne savais pas trop ce que c'était qu'un architecte logiciel et comment il pouvait occuper ses journées.

Alors, un archi c'est quoi ?
Et bien, c'est une personne qui va concevoir une solution pour répondre à un besoin de son client. Cette solution peut être technique, inscrite dans le SI de l'entreprise avec une description allant jusqu'au niveau serveurs, versions de logiciels à utiliser, etc. Un architecte peut aussi être orienté métier : les solutions ne sont en effet pas systématiquement techniques (même si elles sont techniquement systémiques !).
Par exemple, imaginons que l'objectif d'une entreprise est d'accroitre sa présence à l'international. Elle peut pour cela revoir son portail Internet mais aussi ouvrir des points de vente dans des pays clés. Tout dépend de la culture, des valeurs et des principes de l'entreprise. Tous ces éléments constituent le contexte d'étude de l'architecte.

C'est la partie qui m'a le plus intéressé : l'importance du contexte. Il est nécessaire de connaître l'entreprise cliente en profondeur pour modeler la façon dont on va répondre à sa demande. Toutes les étapes par lesquelles passe l'architecte au cours de sa démarche doivent être développées en fonction de cette analyse contextuelle.

Clairement, cette formation m'a donné un nouveau regard sur mon métier. L'objectif n'est pas de chercher la meilleure techno du moment et essayer de l'imposer. Au contraire, il s'agit de s'imprégner de son client et de son métier, de sa culture pour lui proposer les solutions qui lui conviennent le plus et qu'il pourra lui même porter. Le but ultime est de présenter des solutions au client et qu'il choisisse sa solution, celle qu'il pourra défendre auprès des parties prenantes.

Mais qu'est-ce qui m'arrive ? Au lieu de codeur, je deviens consultant ou quoi ?

Dernière remarque culturelle : vous avez peut-être entendu parler de la loi de Conway. Je pensais au départ que c'était une fatalité liée à la difficulté des organisations à changer et à innover. Maintenant, je comprends que c'est simplement parce que c'est là le but recherché de l'architecture d'entreprise...

Pourquoi s'embéter avec l'agilité...

...en SSII. C'est la question que je me pose. Les pratiques de conduite de projet agiles, dont l'implémentation la plus populaire en France est a priori Scrum[1], restent encore globalement méconnues (il faut dire que le manifeste a seulement 10 ans. Il faut du temps pour traverser l'Atlantique). Elles sont assez souvent jugées comme peu sérieuses (mon expérience). C'est encore délicat aujourd'hui pour les évangelistes, je pense, d'en faire susciter l'adoption dans l'enthousiasme général. Alors, pourquoi ne pas arrêter ?

Rassurez-vous, je ne vais pas vous suriner avec tout le bien que je pense des projets en cascade, en V, en Y... Les spécifications mal écrites, mal lues, pleines d'erreurs... Les cahiers de tests manuels mal écrits, jamais rejoués, périmés... Les règles de développement jamais discutées en équipe, prônant l'usage de cette saleté notation hongroise (je crois que je m'égare...).

Reprenons. Scrum, c'est quoi ?

C'est un ensemble de pratiques et de rôles qui va permettre à l'équipe de développement de se rapprocher d'un collège d'utilisateurs afin de développer une application informatique censée les aider dans leur travail, les rendre plus efficaces, heureux et riches.
Ils sentent ce qu'ils veulent mais ne savent pas -au sens de compétence mais aussi de disponibilité, de temps à consacrer- le formaliser de façon exhaustive dans des spécifications.
Ainsi l'équipe de développement fait de son mieux pour interpréter ces besoins et les traduire en application afin de les montrer rapidement aux utilisateurs. À la vue du travail effectué, leur besoin se précise et l'application évolue. On s'aperçoit que finalement, une fonctionnalité A est suffisamment remplie par une fonctionnalité B qui devient donc très peu prioritaire, que ce serait bien d'avoir telle et telle information dans un nouvel écran. Oh et Jean-Jean, tu nous ferais pas un tableau de bord là en page d'accueil ? Ce serait tellement pratique pour les gars...

Dans ce cas de figure, ça mène à un niveau de synergie étonnant. On arrive à faire de grandes choses à couts maîtriser et avec une vraie satisfaction du client en la personne de l'utilisateur final. Je l'ai vécu. En SSII. Et c'est une exception.

La règle habituelle des projets au forfait est très différente.
En premier lieu, l'équipe n'est jamais au contact des utilisateurs. Les utilisateurs formulent un besoin à une maîtrise d'ouvrage (MOA) qui la transmet accompagnée d'un budget à une maîtrise d’œuvre (MOE) qui va la traduire en cahier des charges et parfois même en spécifications (chance pour vous). La MOE fait appel à la SSII pour sous traiter le vil travail de développement (elle n'est pas obligée, mais là ça m'aide pour écrire un article sur les SSII).

La MOE n'a pas besoin du projet. Elle n'a pas un besoin viscéral du projet. Faire le plus beau logiciel du monde ne va pas rendre son travail plus efficace, plus facile. Il ne va pas rendre ces personnes plus heureuses chaque matin d'aller utiliser une application faite uniquement pour eux, pour leur besoin spécifique.

Alors pourquoi vouloir faire du Scrum ? Où est l'agilité dans ce processus ?
Un processus dans lequel le besoin des utilisateurs est livré entre 6 mois et 1 an après leur demande. Un processus au cours duquel de multiples équipes se sont interposées entre l'utilisateur et son besoin et le producteur capable de le satisfaire, avec ce que cela représente de coûts mais aussi de déformation du besoin exprimé ? Où est l'agilité lorsque le logiciel n'est pas en accord avec l'interprétation des spécifications et que les acteurs repartent dans un cycle demande-chiffrage-planning-réalisation ? Je cherche encore...

J'ai vu une fois un projet soi-disant Scrum avec une structure décrite ci-dessus et au forfait. Cela est revenu à développer un une liste d'exigences mouvante sans réviser l'engagement sur le périmètre à livrer. Un beau massacre.

On peut éventuellement se dire qu'on peut faire un contrat forfait pour rassurer la partie cliente et obtenir le budget et ensuite ne pas honorer l'engagement sur les fonctionnalités. En d'autre terme, on signe un contrat forfait pour au final de la régie. Cela peut marcher... si on aime faire de l'escalade sans corde (avec de la graisse sur les mains). C'est à refuser absolument.

Restons simples. Rendez-vous service. Rendez service à votre hiérarchie et à votre client. Si vous avez une MOE qui veut du forfait, donnez lui du forfait. Si elle veut faire du Scrum et du forfait, dirigez votre interlocuteur vers ce billet : il est possible qu'il n'ait pas réellement saisi l'intérêt.

Vous voulez cependant travailler de façon moderne malgré ce carcan austère ? Ajoutez mon journal dans votre agrégateur RSS et laissez moi formaliser la suite (on peut aussi faire du blabla incrémental :)).

Ouais, c'est un to be continued, baby.



[1] n'insistez pas, je n'ai pas de source. Vous connaissez Crystal et DSDM vous ?