Peut-on être développeur et communiquant ?

Publié le 29 décembre 2007 | Catégorie Analyse, Second degrés

Voilà une question qui me fait réfléchir ces derniers temps. Pourtant, il y aurait une réponse toute faite : un développeur est, par nature, un non-communicant. Pour le commun des mortels, le développeur ou programmeur est vu comme discret voir introverti. Tantôt cerveau, souvent exécutant, cet invertébré issue d’une espèce de geeks nocturnes vit dans un monde parallèle au notre… euh, au votre. Travailleur de l’ombre, le développeur n’a pas le temps de discuter, pas le temps de dormir, pas le temps de regarder les gens en les saluant, pas le temps de manger car, c’est bien connu : “le temps, c’est du code”. Passionné d’informatique et dévoué à son Blackberry/iPhone lorsqu’il est privé d’écran, le développeur aime pourtant ces longues discussions techniques qui le distinguent lorsqu’il est en groupe. Chipotant d’une virgule ou d’un point, il se doit d’être pointilleux car le perfectionnisme, c’est son métier.

Deux visions opposées ?

2 visions opposées
Quant il existe, le développeur-communiquant peut être mal vu pas ses pairs. Et pour cause ! Il est différent des autres, et tout ce qui est différent fait peur. Il est un trolleur-blogueur-bullshiteur dont ils se passeraient bien. Il est un mouton noir, une anomalie congénitale, une vecteur d’hérésies faisant la risée de toute son espèce. Plus vraiment développeur, pas vraiment communiquant, il erre à la recherche d’un métier qui n’existe pas.

Et pourtant, il y a du bon de communiquer : communiquer pour transmettre, communiquer pour échanger, communiquer pour s’affirmer, communiquer pour partager, communiquer pour apprendre,… communiquer pour mieux comprendre. Certains diraient : “Evangéliser les foules”. Je parlerais plus d’échanges bidirectionnels qui, en augmentant la qualité des interactions, facilitent la compréhension de l’information.

Des objectifs différents ?

Je suis souvent sidéré par la distance qui sépare un développeur d’un utilisateur. Le développeur est soumis a de nombreuses contraintes (temps, technique, compatibilité, charge) qui le pousse à se concentrer très souvent sur des détails très pointus. Imaginez une montre constituée de centaines de rouages imbriqués les uns dans les autres. Le développeur a les mains dans le cambouis constamment, il sait qu’il va devoir mettre de l’huile par ici (optimizing), changer cette pièce-là (refactoring) ou nettoyer ce grain de sable qui ralenti tout le mechanisme (bug). Pendant ce temps, l’utilisateur lambda n’a pas la moindre idée de la complexité et de la finesse de ce qui se passe derrière. Ce qu’il souhaite c’est que sa montre lui plaise, qu’elle soit robuste, légère et surtout, qu’elle donne l’heure.

Vulgariser, pour quoi faire ?

L’utilisateur lambda n’existe pas, le développeur lambda n’existe pas non plus et heureusement.
A l’instar de l’évolution d’un Internet de plus en plus tournée vers le contenu généré par les utilisateurs, les professions et profils du web sont en constante mouvance : certaines naissent encore, d’autres se transforment dans un rythme de plus en plus effréné… et nous n’avons pas fini d’en voir. Alors un développeur-communiquant, pourquoi pas !

Commentaires

10 réponses à la question “Peut-on être développeur et communiquant ?”

  1. pyke | le 5 janvier 2008 à 12:59

    Une question se pose : le développeur-communicant ne risque-t’il pas de se transformer en communicant-développeur, et finalement ne plus vouloir faire que du troll-blog-bullsh^W^W^W^W de l’évangélisation ? Auquel cas, ne faudrait-il pas qu’il assume son choix et se spécialise plutôt selon une approche produit ?

  2. Sylvain | le 5 janvier 2008 à 20:02

    @pyke : En effet, la question est intelligente. Mais au delà de l’assumation de ses choix, il faudrai encore que le développeur obtienne la confiance de ses supérieurs afin qu’on lui donne les moyens et surtout des possibilités d’évolutions vers un poste de communiquant au sein de l’entreprise, surtout si le poste en question doit être crée.

    De plus, cette métamorphose dépend essentiellement de l’ouverture et surtout de la confiance que l’entreprise donne à son salarié mais aussi des capacité du salarié à s’adapter à de nouvelles contraintes et objectifs. Je pense donc sincèrement qu’un salarié dont on n’écoute ni les idées, ni les observations, ni les critiques ne peut progresser dans sa carrière professionnelle.

    Enfin, je trouve particulièrement réducteur cette obstination très française à vouloir consigner les gens dans des cases, pratique qui se révèle souvent destructrice de créativité à la fois pour le salarié et pour l’entreprise.

    Merci pour votre commentaire.

  3. Etienne | le 7 janvier 2008 à 13:33

    Bonjour,

    Connais tu par hasard les méthodes de développement logiciel dites “agiles” telle que l’extreme programming qui place la communication parmi ses quatre valeurs fondamentales ?

    Je me considère développeur-communicant et j’en suis très heureux depuis que je travaille avec cette méthode.

    L’introversion est une _préférence_ psychologique et non une qualité. Pour faire simple, on n’*est* pas introverti, on préfère simplement tirer notre énergie de l’intérieur plutôt que des gens qui nous entoure, mais ce n’est qu’une préférence.
    Peut être préférez-vous les nouilles au riz, mais vous avez quand même du plaisir a manger du riz de temps en temps.

  4. Sylvain | le 8 janvier 2008 à 0:37

    @Etienne : Oui, je suis très intéressé par les méthodes dites agile, de type Scrum ou Extrem Programming, mais cela reste théorique. J’aimerai beaucoup tester ces méthodes et me faire un avis sur leurs mise en pratiques. Peux-tu nous partager ton retour d’expériences, concernant la communication, le développement itératif ? Cela en intéresse plus d’un.

    Concernant l’introversion, je ne suis pas tout à fait d’accord. Même s’il peut être considéré comme un choix, ce trait psychologique relève souvent de l’inconscience du sujet, et peut être provoqué dans une stratégie de défense personnel. Appliqué aux accros du code, la mauvaise image de l’ingénieur informaticien persiste dans les mentalités alors que nombreux sont les développeurs créatifs et/ou communiquant.

  5. Etienne | le 8 janvier 2008 à 11:32

    La mise en avant de la communication dans ce types de méthodes est aussi ce qui leur donne cette images de désorganisation : tout le monde peut s’exprimer. Pourtant il n’en est rien. En effet, tout les acteurs du projet peuvent s’exprimer, mais cela se passe à des moments prévues pour. Sur une itération de deux semaines par exemple, nous commençons par une réunion de planification, la personne qui tient le rôle du client dans l’équipe et qui est responsable du contenu fonctionnel de l’application communique les exigences sous la forme de scénarios écrit et d’explications orales. Les développeurs posent autant de questions qu’ils veulent jusqu’à ce qu’ils aient compris. La durée de cette réunion est fixe (par exemple 3 heures). A la fin du temps prévu, on peut discuter (encore de la comm) pour savoir s’il faut refaire une nouvelle réunion ou si on peu partir sur l’itération avec ce qu’on a. (Cette réunion à aussi pour but de définir le plan de l’itération avec une technique d’estimation et de prioritisation des scénarios, mais je met ici simplement l’accent sur l’aspect communication)

    Pour organiser un peu les discussions, la méthode prévoie aussi un coach, on dit aussi facilitateur en français.

    Un autre temps pour l’expression : la réunion quotidienne debout d’un quart d’heure. C’est un temps pour discuter de l’avancement et des points bloquant.

    En dehors de ces temps de parole “publique”, les développeurs travaillent en binômes et discutent donc tout le code qu’ils écrivent. Et pour faciliter les échanges d’informations spontanés, tout les membres de l’équipe (ce qui inclut le client) sont colocalisés : même pièce ou même zone de l’open space. Nous avons retiré les cloisons entre les bureaux.

    L’itération s’achève par une démonstration de ce qui à été fait au client.

    Après la fin d’itération, un temps est prévue pour faire le bilan. C’est la réunion de rétrospective. C’est le moment pour “vider son sac” si c’est nécessaire, mais aussi de discuter de l’efficacité du processus en place, quelles sont les améliorations possible, les choses qui ne vont pas… Ce type de réunion est aussi d’une durée fixe.

    Nous sommes donc ici très loin de la communication cloisonnée des méthodes “classiques” type en V où les acteurs du projet se parlent par documents interposés.

    D’après mon expérience, ce type d’organisation plait bien aux développeurs qui sont contents qu’on ne les prennent pas pour des “autistes” pour une fois.

    Enfin, concernant l’introversion, nous avons sans doute un désaccord sur la définition. Je pensais plus à la définition telle qu’on la trouve dans le modèle de Myers-Briggs : http://16types.free.fr/index.html

    Je suis d’accord que les informaticiens se referment parfois sur eux même et sur leur machine mais c’est une dérive d’un caractères aillant une préférence pour l’introversion (dérive classique chez l’adolescent). Considérer l’introversion de cette manière aide à valoriser cette préférence et permet aussi de la transcender (c’est à dire, la faire sortir de son caractère inconscient).

  6. Glagla Dot Org » Blog Archive » Le développeur communiquant | le 8 janvier 2008 à 15:24

    […] lu avec grand plaisir l’article de Sylvain Weber sur le développeur communiquant ; un brin second degré et suscitant pleins de […]

  7. Sylvain | le 9 janvier 2008 à 19:44

    @Etienne : Un grand merci pour toutes ces précisions. Cette approche alternative de conduite de projet me semble particulièrement pertinente. J’aimerai beaucoup tenter l’expérience mais la mise en place de telles méthodes nécessite pas mal d’étude préalable sur les bénéfices apportés ainsi que beaucoup de courage et de force de persuasion en interne, surtout si cela bouleverse les habitudes de travail de chacun… mais ce n’est certes pas impossible.

    Concernant l’introversion, on rentre dans des finesses psychologiques que je ne maîtrise pas, surtout si vous vous basez sur un modèle précis. Dans tout les cas, j’aimerai rappeler que cet article se veut particulièrement ironique en provoquant des descriptions de stéréotypes qui ne correspondent pas à la réalité. Mes propos sont donc à prendre au second degrés :)

  8. Neovov | le 10 janvier 2008 à 21:36

    Billet intéressant et amusant :) !
    On sent la situation vécue; à quand le billet sur le moral des développeurs ?

    Au passage : bonne année :) (et à Jacinthe aussi) !

  9. Sony | le 31 janvier 2008 à 3:19

    Je regrette l’angle de vue “developpeur centric” de l’article :)

    Si l’on regarde d’un point de vue plus “système” on peut effectivement se demander si le développeur ne s’enferme pas lui même dans un univers peu communiquant.

    S’il est vrai qu’on ne lui donne pas forcément l’occasion de s’exprimer, c’est très certainement en raison d’une méconnaissance de son métier. Cela est dû à la technicité, qui pour les néophytes et ceux qui ne sont pas du serail “IT” est bien difficile à comprendre. Cela est souvent du au développeur lui-même qui n’aura pas forcément une connaissance des problématiques auxquelles ses “clients” ou utilisateurs sont confrontés, ceux avec qui il pourrait être amené à communiquer. Cela peut aussi etre du au développeur qui pourrait ne pas faire d’effort pour se faire comprendre du monde “extérieur”.

    Je pense aussi que pour permettre au développeur de devenir communiquant, des étapes prérequises doivent être rencontrées, et ces prérequis ne sont pas forcément liés à la hiérarchie du développeur, mais plus au mode de pensée du système organisationnel dans lequel le développeur évolue.

    Pour permettre une communication, il faut un émetteur et un récepteur. Si l’on considère le développeur communiquant comme emetteur, il doit y avoir un terrain propice chez le recepteur. C’est ainsi qu’une connaissance et une compréhension mutuelle du développeur et de ceux avec qui il cherche à communiquer sont nécessaires.

    Une second prérequis est de disposer de points communs : objectifs concordants ou allant dans la même direction, valeurs similaires, compréhensions proches d’une problématique commune. Ces points communs vont permettre de dégager de la valeur à l’échange entre l’emetteur et le récepteur.

    Ces prérequis ne sont pas toujours en place pour permettre la communication dans les deux sens, et c’est souvent la raison pour laquelle on met en place des transcodeurs, des relais, qui ont pour but de faciliter la communication et la compréhension, mais qui peuvent aussi parfois la déformer ou la retarder.

    L’un des avantages des méthodes Agiles, c’est de favoriser le lien direct pour gagner sur la latence et la déperdition d’information, mais pour qu’une telle méthode soit acceptée, là encore des prérequis doivent exister, et ce sont sensiblement les mêmes que ceux vus précedemment.

    J’ajoute qu’amener le changement, ce n’est pas forcément faire preuve de persuasion, c’est souvent faire preuve de compréhension des enjeux de l’autre. Si l’on veut amener le changement, il faut comprendre où sont les résistances, quelles sont leurs fondements. Cette analyse permettra d’identifier les leviers de l’acceptation du changement, de le justifier et d’apporter de la valeur aux cibles du changement.

  10. Sylvain | le 6 février 2008 à 12:28

    @Sony : “La reconfiguration créative des processus (la ré-ingénerie créative ou “Fast Response”) est une méthode qui réorganise des processus fondamentaux de l’organisation ou de l’entreprise afin de les rendre plus efficaces.”

    Il est clair que dans toute réorganisation en vue d’une optimisation, l’analyse des interactions est plus que nécessaire. Au delà d’une vision developer-centric inévitable de part ma profession, je pense qu’il est important que les informations organisationnelles s’échangent sans rétention d’une part et avec le moins de jargon technique d’autre part, d’où l’importance de vulgariser des deux côté.

    Votre approche est pragmatique et sensé, mais je reste convaincu que beaucoup de développeurs sont des créatifs en demande d’une marge de manœuvre communicationnelle adaptative qui sera capitale dans l’évolution pérenne de la profession.

Laisser un commentaire