Je ne me suis jamais considéré comme un très bon développeur. N’empêche que c’est en tant que développeur que j’ai débuté ma carrière et j’en suis ravi. On peut même dire que j’ai développé des choses vraiment sympa durant ces quelques années ! Mais disons que je suis plus pertinent là où je suis aujourd’hui, un peu comme une passerelle entre le dev et le reste !
C’est un métier riche que celui de développeur.
Cela demande rigueur, réflexion, apprentissage permanent, écoute et créativité ! J’ai longtemps été frustré que tout cela ne soit pas reconnu, qu’on ne me permette pas d’exprimer tout mon potentiel. Juste une petite phrase qu’un de mes “managers” m’a dit un jour et qui résume bien cette frustration : “Non mais c’est pas ton métier de penser à ça. On a des experts qui sont payés pour ça. Toi, ton rôle, c’est de réaliser ce qui a été décidé (par ces fameux experts), de bien le faire et de le faire dans les temps”. Délivrer bien et dans les délais, ça fait partie effectivement de la mission d’un dev mais ces experts sont-ils vraiment si pertinents? Certains le sont, mais souvent on se retrouve plutôt avec des projets délivrés dans la douleur pour toutes les parties. Les clients mais surtout les devs, qui sont le dernier maillon de la chaîne !
En tant que dev, on peut (en simplifiant) travailler pour deux types de boîtes : celles qui développent leurs propres produits et celles qui développent des produits pour ses clients. J’ai toujours travaillé pour la seconde catégorie, et cet article est écrit dans ce contexte.
C’est d’ailleurs aussi ce que nous faisons chez BetterCallDave.
J’ai créé BetterCallDave pour plusieurs raisons et parmi celles-ci, j’en citerai une : remettre les développeurs au centre de la création de valeur et au centre des échanges avec le client.
C’est l’un des buts de l’agilité, me direz-vous !
Mais dans une société de services, où une petite équipe travaille pour plusieurs clients en même temps, où ces clients sont représentés par plusieurs personnes qu’il faut mettre d’accord et qui ont déjà beaucoup trop de réunions, que ces mêmes clients veulent savoir dès le devis :
- combien ça coûtera exactement parce qu’il y a tout un process à respecter avec leur contrôle de gestion,
- qu’évidemment ce devis est mega urgent, parce qu’on veut démarrer vite (idéalement le mois prochain mais la décision prendra tout de même 6 mois)
- qu’évidemment ce devis doit aussi indiquer le planning parce qu’il faut prévoir dès maintenant toute la campagne marketing avec d’autres partenaires…
Bref on commence à s’éloigner vraiment de l’agilité. Je grossis un peu le trait, mais n’empêche que je suis sûr que cela rappelle des souvenirs à beaucoup de monde !
Et souvent cela aboutit à ce type de schéma :
Un commercial discutant avec un ou deux mecs plutôt fonctionnels et techniques, qui eux, n’ont pas d’échanges directs avec le client; ce qui aboutit à un chiffrage pris sur des hypothèses foireuses et parfois au doigt mouillé. Avec un macro planning tout aussi foireux, et surtout un périmètre qui respecte à la lettre les demandes du client, dans les technos que l’on maîtrise… sans les avoir vraiment remises en question et s’être demandé ce qu’on pourrait vraiment proposer de mieux… et de différenciant.
Et le résultat final de tout ça, c’est :
- une équipe de dev qui fait ce qu’elle peut pour réaliser dans les délais un cahier des charges validé par un client qui n’a parfois pas compris l’intégralité de ce qu’il validait.
- Ce même client, qui lors de la recette, dit que le fonctionnel de l’appli n’est pas vraiment ce à quoi il s’attendait
- Du coup on se retrouve à refaire des choses, parfois des choses qui étaient structurantes, ce qui décale toutes les dates et pour réduire au mieux le retard, on va faire au plus vite donc on ne va pas prendre le temps de bien repenser les choses
- Un budget qui augmente et donc quelqu’un dans l’histoire va perdre de l’argent (soit le client parce qu’on va lui faire un avenant, soit le presta parce qu’il va devoir prendre sur sa marge, voir toute sa marge).
Et tout ça pourquoi ?
Parce qu’on a pas pris le temps de bien penser les choses et de mettre les bonnes personnes autour d’une table pendant quelques heures. Et quand je dis “bonnes personnes”, je parle de ceux qui savent et qui vont réaliser le projet, à savoir les développeurs en plus du commercial, et du profil plutôt fonctionnel.
Quand j’explique ça, la première remarque que j’entends c’est : “mais ton avant-vente elle coûte super chère à mettre tout ce monde autour de la table !”.
Et bien, non en fait, c’est plutôt efficace même : les bonnes questions sont posées directement par les bonnes personnes, moins d’allers-retours, la réponse n’est pas déformée par une éventuelle interprétation. Tout le monde s’approprie le périmètre, ce qui permet de vite établir un chiffrage et tout le monde peut participer à la création de valeur ! Qui plus est, le temps passé en avant-vente est du temps gagné sur la phase de recette, puisque tout le monde a pu s’approprier le périmètre. Donc le livrable correspond bien plus aux attentes !
Évidemment ce n’est jamais parfait mais il y a quand même beaucoup de positif :
- Déjà le dev n’est plus uniquement exécutant du projet, il participe dès le début et avec le client à la création de valeur, et son opinion compte. Ce qui est en plus valorisant. Et comme chaque client est différent, c’est aussi enrichissant parce qu’il faut voir plus loin qu’une simple tâche à réaliser, il faut s’imprégner du contexte, découvrir et comprendre les enjeux et le métier du client, savoir vulgariser son métier de dev et proposer de nouvelles idées.
- Et comme je le disais, tout le monde s’est approprié le périmètre et donc le projet, ses enjeux sont compris de tous. Ce qui contribue au final à des livrables plus en adéquation avec les attentes et donc moins de retours en phase de recette.
Ainsi tout le monde est gagnant : les délais sont respectés, les budgets aussi et donc le client peut utiliser le reste de son budget pour un nouveau lot de fonctionnalités ou un autre projet. Les développeurs participent à la création de valeur et n’ont pas ce désagréable sentiment de devoir refaire leur travail, non pas parce qu’ils n’ont réalisé ce qui était spécifié, mais parce que le besoin au fil des échanges et de sa transmission, a tout simplement était déformé ou mal exprimé.
Évidemment, ça c’est aussi dans le meilleur des mondes. Quand il y a beaucoup d’avant-ventes en cours, cela peut faire beaucoup d’ateliers, de réunions et donc moins de temps pour produire par exemple. Et puis quand le projet est lancé, il y a toujours des aléas, des livrables clients manquants, un événement qui fait que telle ou telle fonctionnalité doit être changée, etc… Sujets qui mériteraient bien d’autres articles, et d’ailleurs, bien de ces articles ont déjà été écrits !
