Je parle de dire non dans le cadre professionnel, hein !

Story of my life

En tant que développeur, je suis souvent mené à rechigner à faire ce qu'on me demande. Exemples :

• on me demande de développer une feature très compliquée, pas KISS ;
• on m'interrompt pendant une tâche importante pour me demander de traiter en urgence une autre tâche (important aussi ou bien dont je n'ai rien à foutre) ;
• on me demande de faire un quick dev dégueulasse plutôt que de faire un développement propre ;
• ...

Au fil du temps, ma réaction par rapport à ce genre de cas a évolué.

Quand j'étais en tout début de carrière, n'ayant aucune personnalité, je disais oui à tout sans jamais rien questionner. Je fonçais, je faisais tout, et je rattrapais mon retard sur mon temps libre. En tant que gros bébé, je n'avais pas encore la culture et le recul nécessaire pour juger de la pertinence d'une demande. Et même quand j'étais sceptique, mon manque d'assurance me faisait penser que je devais rater quelque chose. Effet pervers : dire oui à tout sans questionnement faisait augmenter exponentiellement les demandes à la con.

Ensuite est arrivée l'adolescence. L'assurance est arrivée, et je ne me sentais plus pisser.

400 ko le gif, ça valait vraiment la peine ? Oui.

Je me suis mis à dire "non" fermement. Mais cela ne me satisfaisait pas :

• au final, la plupart du temps, je finissais quand même par m'exécuter ;
• n'aimant pas contrarier les gens, en disant "non" je me sentais devenir un gros connard dépressif aigri.

Et maintenant

J'ai depuis quelques années trouvé la solution qui me convient personnellement : je ne dis jamais "non" à une demande. Je dis que c'est possible, je donne le coût, je donne les implications, et je donne une alternative. Et je laisse décider. Systématiquement. Même pour la demande la plus débile qui me fout la rage de feu intérieure.

Le plus important au niveau de la forme est de ne pas montrer de négativité dans ma réaction : le fonctionnel qui vient me voir avec son besoin a un problème à régler, et il est convaincu de l'intérêt de ce qu'il demande. Si je commence directement par faire la tronche, dire que ce n'est pas possible, dire que c'est une idée de merde, je braque mon interlocuteur. Et ça ne va pas m'aider à discuter ni à le convaincre.

J'annonce avec le sourire que j'y réfléchis. Je prends quelques secondes pour penser le problème à haute voix. Si je réponds du tac au tac que non, je ne veux pas faire cet affichage spécifique pour ce client car ça m'ajoute de la dette pour un truc inutile, mon interlocuteur entend "tu me fais chier, j'ai pas envie d'écouter ton idée de merde". En montrant de l'intérêt pour le besoin de la personne, je deviens sympa, et je trouve ça super important, d'être sympa.

L'autre intérêt de se forcer à réfléchir à un besoin débile, c'est que ça permet... d'y réfléchir vraiment. Et je ne compte plus les fois où je me suis ravisé intérieurement sur la pertinence d'une demande. Cela permet aussi d'identifier les très fréquents XY problems.

Petite disgression sur la sympathie : je fais tout pour être gentil. Les développeurs très forts mais qui se comportent comme des cons, il ont tendance à être attendus au tournant, et le jour où ils ont une baisse de régime/efficacité, il deviennent juste cons.

Chiffrer pour effrayer

Sur le fond, la première information que je donne, c'est un chiffrage grossier (mais honnête) : est-ce que cette tâche va me prendre 5 minutes, quelques heures, ou peut-être que ça représente une story de X jours à saisir ? Dans les trois quarts des cas, rien que le fait d'informer un demandeur que son développement va coûter plusieurs jours, ça lui permet de se raviser et de fuir en courant. Le besoin super important se transforme tout d'un coup en un "ah non mais je proposais ça juste comme ça, en nice-to-have, c'est pas grave tant pis !".

La demande bouleverse mon emploi du temps ? J'explique que je peux m'exécuter, mais que cela va du coup repousser tel autre développement. Je pourrais en fait résumer mon article à "il suffit d'expliquer".

Noter

Quand le sujet traité est important, je n'hésite pas à faire un petit mail pour avoir une trace écrite. Ca fait un peu old school de dire ça, alors que la mode est au management horizontal et à une vision candide de la collaboration dans laquelle tout le monde avance main dans la main en se faisant des bisous sur la fesse gauche. Mais poser les choses par écrit permet de s'en souvenir, et d'être sur que l'on s'est bien compris. Sur la forme, c'est bêtement un mail de compte-rendu de mini-réunion, pas un SCUD mesquin à base de "Tiens, voilà ce que je te ressortirai le jour où tu me demanderas pourquoi j'ai développé cette connerie".

Se résigner

Avec tout ça, j'élimine 90% des demandes qui ne me plaisent pas. Les 10% restants, je les vis bien. Je réalise la demande sans grogner et en la faisant de la meilleure manière possible. Pour les raisons suivantes :

• Au final, j'ai beau m'exciter, le développement sera quand même fait.
• Un héritage des sports collectifs : quand on estime que le coach nous soumet une tactique de merde, on la met en oeuvre exactement comme il nous l'a demandée, pour lui prouver que ça ne marche pas (et des fois on se rend compte que ça marche). De la même manière qu'une tactique peut être corrigée en cours de match, un développement peut être défait.
• Un héritage de 3 ans dans la réserve de la Gendarmerie : j'ai un sens poussé de la hiérarchie. Et quand en formation on nous demande de monter en haut d'un tas de terre au coup de sifflet et de revenir en courant à l'envers et en chantant la marseillaise, une fois qu'on revient dans l'informatique, une demande d'ajout de popin de pub fait grand sens.
• je suis développeur salarié. Même si je m'intéresse au fonctionnel et que j'essaie d'y apporter ma contribution, je n'ai pas toute la vision. Mon avis est peut-être mauvais.

Ces différentes raisons ne sont certes pas suffisantes. On peut s'insurger du fait que les développeurs ne soient pas totalement mis au courant de certaines problématiques que rencontre la boite, qu'ils ne soient pas plus consultés. Mais c'est comme ça. Je ne sais pas si c'est bon ou mauvais, mais ça ne fait actuellement pas partie de mes sujets de préoccupation pour changer le monde.

Prévenir

Quand le quick-dev demandé en urgence induit de la dette technique, je négocie une story de remboursement à caser en priorité critique sur le prochain sprint. Ou pas : je suis aussi capable de dire que je peux vivre un certain temps avec cette dette technique, qu'il ne sera obligatoire de la rembourser que quand telle future grosse fonctionnalité devra être développée. Comment j'arrive à négocier une story de remboursement de dette sans que quelqu'un la vire discrètement ? En expliquant, en étant sympa, et en ne faisant pas recours sytématiquement à cette carte : si un développeur gueule sur tout, il ne gueule sur rien. Je choisis mes batailles.

Dans tous les cas, je préviens de la dette technique qui augmente, et je consigne parfois son remboursement dans les prérequis d'une story ultérieure en lien avec le sujet et à laquelle les fonctionnels tiennent.

les 1% restants

Il reste au final de temps en temps des demandes qui me restent vraiment en travers de la gorge. Elles sont calmement ajoutées au compte "frustration" : quand ce compte a un solde trop élevé, c'est le moment où je change de boite. On a la chance d'avoir un métier très demandé, j'en profite. Pour l'instant, ma moyenne de temps passé dans une société est de 2 ans, mais l'actuelle est en train de la faire monter.