Je vous ai déjà parlé du site « Jester Management » créé par mon ami Loïc. C’est un très bon blog qui parle de management, de gestion de projet, de geekeries, etc. Si vous appréciez mon blog et que vous lisez l’anglais, c’est vraiment une lecture indispensable. Les blogs ont souvent un…
La diplomatie au travail
Quand on travaille en équipe, on doit apprendre à gérer les rapports humains. Nous ne sommes pas tous égaux face aux relations humaines. Certaines personnes se sentent à l’aise, d’autre non. Certaines personnes n’hésitent pas à imposer leurs vues, d’autres se mettent en retrait.
L’essentiel est de garder, en toute circonstance, un comportement qui permette de travailler efficacement. Si on peut se faire des amis au boulot, c’est la cerise sur le gâteau ; mais il ne faut pas se faire d’ennemis.
Les désaccords
Il existe un principe fondamental en entreprise : Critiquer les idées, pas les personnes
Quand on n’est pas d’accord avec les propositions de quelqu’un, il semble parfois plus facile de chercher à démolir la personne elle-même, plutôt que d’expliquer en quoi on est en désaccord. Ce n’est pas constructif, et vous attirera les inimitiés de vos confrères.
Le nocif
Dans la série des billets consacrés aux types de collègues, et pour faire la suite à ceux consacrés aux affectifs et aux revendicateurs, je vais aujourd’hui vous parler des « nocifs », c’est-à-dire des personnes qui – pour une raison ou une autre – sont réellement néfastes pour une équipe ou une entreprise. Nous allons voir comment reconnaître un nocif, et quelles sont les solutions qui s’offrent à vous pour traiter leurs cas.
À quoi reconnaît-on un nocif ?
Nous avons tous cotoyé au moins une personne dont le comportement ne semblait pas correspondre à celui attendu. Cela peut toucher un assez grand nombre d’attitudes :
- Connaissances techniques trop faible. Un développeur qui est tellement mauvais techniquement qu’il produit systématiquement du mauvais travail.
- Problèmes d’horaires. Quelqu’un qui arrive à 11h00 le matin et part à 17h30 le soir, ou qui se prend 20 minutes de pause toutes les 45 minutes.
- Non-implication dans son travail. Une personne qui se met dans un simple rôle d’exécutant, au lieu d’utiliser ses compétences et son imagination pour faire réellement avancer ses projets.
- Mauvaise volonté systématique. Quelqu’un qui réfute par principe toutes les idées qui lui sont soumises, ou qui ne prend en compte que les choix qui l’arrangent.
- Problèmes de communication. La personne qui reste dans son coin en parlant le minimum possible. La personne qui n’arrive pas à avoir un débat constructif, et s’énerve dès que ses idées ne sont pas suivies. Celui qui ramène toutes les discussions à ses propres problèmes immédiats.
- Problèmes avec l’autorité. Quelqu’un qui n’accepte pas qu’une autre personne puisse décider de ses priorités et de son planning.
- Comportement non professionnel. Une personne qui se permet d’insulter ses collègues. Un commercial qui tutoies les clients. Un chargé de clientèle qui n’offre pas toute l’écoute qu’li devrait.
L’honnêteté paye toujours
L’honnêteté est généralement considérée comme une qualité humaine. Mais bizarrement, ce n’est pas une vertue très courante dans le monde professionnel.
Pourtant, c’est une approche qu’il faut chercher à avoir, car elle facilite grandement le travail, aussi bien quand on parle du boulot d’un développeur que de l’image d’une entreprise.
Au niveau individuel
Quand on commence à travailler, quelle que soit la branche, on a tendance à prendre assez mal les critiques. C’est le syndrôme du « petit enfant pris en faute » ; on s’en veut énormément, on a l’impression d’être en dessous de tout, et parfois on devient rouge pivoine. Avec le temps, on apprend à prendre sur soi, à faire la part des choses ; on arrive à comprendre les remontrances et à les intégrer pour progresser professionnellement, sans pour autant que cela devienne un traumatisme.
Mais cela peut avoir aussi un effet pervers. Quand on est un débutant, on remet peu en cause les remarques qui nous sont faites. Plus on progresse, plus on se sent à l’aise, et plus notre expérience professionnelle nous fournis des « armes » qui nous permettent d’embobiner nos interlocuteurs.
Combien de fois ai-je vu des gens expérimentés qui, lorsqu’ils se prenaient une remarques parce qu’ils avaient mal fait leur boulot, tournaient autour du pot pendant des heures, à expliquer pourquoi les choses s’étaient mal passées, que ce n’était pas de leur faute, qu’ils attendaient quelque chose d’un collègue, que c’était forcément un concours de circonstances, qu’il fallait incriminer les tâches solaires et les phases de la lune !
À chaque fois, il aurait été plus simple, plus rapide et plus professionnel, de répondre simplement « Ah oui, c’est ma faute. J’ai oublié tel truc ou j’ai mal fait telle chose ».
Gestion de sources, versions de logiciels
Lorsqu’on développe un logiciel, il est absolument nécessaire d’utiliser un outil de gestion de sources. Évidemment, il serait possible de stocker ses fichiers dans un répertoire. Mais si vous voulez travailler sérieusement, vous aurez besoin de stocker les différentes versions de vos sources, pour suivre leur évolution au fil du temps ; et si vous travaillez à plusieurs sur le même projet, cela devient impossible.
Les logiciels de gestion de sources permettent à plusieurs personnes de travailler sur les mêmes fichiers, chacun dans leur coin, puis de tout rassembler pour obtenir une version continuellement à jour des sources. Ils apportent des fonctions permettant de définir des versions globales. Il existe un grand nombre de ces systèmes :
- Les ancêtres RCS et CVS ont laissé la place à Subversion, qui offre des fonctionnalités supplémentaires bien appréciables. Ce sont des systèmes centralisés faciles à appréhender et à installer, et sont sous licence libre.
- De nouveaux système sont apparus, basés sur un modèle décentralisé. Parmi ceux-ci, ont peut noter que les plus connus dans le monde de l’open-source sont Bazaar (sponsorisé par Canonical, à l’origine de la distribution Linux Ubuntu), Git (utilisé pour le noyau Linux) et Mercurial.
- Du côté des logiciels propriétaires, les plus connus sont Visual SourceSafe de Microsoft et BitKeeper (qui a été utilisé pour le noyau Linux jusqu’en 2005).
Je vais vous présenter l’utilisation de ces outils, en utilisant l’exemple de Subversion (SVN en abrégé) car c’est le système de plus répandu et celui que j’utilise ; mais ces concepts sont toujours valables.
Principes généraux
Gestion basique
A la base, les sources d’un projet sont disponibles sur la branche principale (trunk). Les développeurs y récupèrent les sources (checkout) sur leur propre environnement de travail, et y ajoutent leurs versions modifiées (commit).
Pas d’intégrisme technologique
J’ai rencontré trop souvent des situations où mes interlocuteurs prenaient leurs goûts personnels pour de grandes vérités technologiques. Cela m’aurait systématiquement amusé, si je n’avais pas vu trop de mauvais choix résulter de ce genre de comportement.
On a tous entendu ce genre de réflexions :
- « PHP c’est juste bon pour faire des pages perso », venant d’un ingénieur JEE.
- « Perl, c’est pour prototyper un logiciel avant de le coder pour de vrai », entendu chez un codeur C/Unix.
- « DotNet, c’est une copie de Java, c’est forcément moins bien », d’un autre ingénieur JEE.
- « MySQL ce n’est pas une base de données sérieuse », assuré par un DBA Oracle.
- « Bah, pourquoi vous utilisez Linux ? », par un candidat à un stage habitué à Windows.
- « Ubuntu, c’est nul, je préfère Debian », par un autre candidat.
- « Avec la base de données et le serveur Web sur des machines différentes, on ralentit le site », par un développeur expérimenté.
On peut apporter des réponses intelligentes à toutes ces remarques :
- Si Yahoo, Facebook et Wikipedia sont codés en PHP, c’est parce que ce sont des sites perso, hein ?
- Pour la plupart des développements, le Perl est plus rapide à développer, avec des performances plus qu’acceptables.
- Les développeurs qui prennent le temps de mettre le nez dans DotNet semblent dire que c’est une très bonne plate-forme.
- Wikipedia utilise plusieurs bases MySQL, qui fonctionnent conjointement de manière très performante.
- La vraie question est plutôt « Pourquoi utiliser Windows ? ».
- Avec de l’Ubuntu Serveur sur les serveurs, et de l’Ubuntu Desktop sur les postes de développement, on s’assure d’avoir une plate-forme unifiée.
- Vous imaginez que Google tourne sur une seule machine ?
Faire un choix structurant
Nous avons tous des préférences. Je me sens bien sous Linux, à coder en C et en PHP. C’est ce qui correspond à mes goûts et mes choix. Je peux l’expliquer de manière factuelle, mais il y a aussi des raisons inexplicables.
Sus aux emails
Il existe plusieurs méthodes de travail qui s’intéressent à la relation que nous avons avec nos boîtes aux lettres électroniques. Pour n’en citer que deux, je dirais GTD et Zero Inbox, dont le but est d’améliorer le traitement des messages que nous recevons, pour être certain de traiter convenablement les informations reçues. Ce sont des approches très intéressantes, dont je vous parlerai dans de futurs posts.
Pour le moment, je vais vous parler de quelque chose d’autre, qui concerne aussi la manière dont nous utilisons les emails en entreprise. Plus particulièrement, je vais vous expliquer pourquoi il ne faudrait jamais – jamais – échanger de documents de travail par email.
Très souvent, les gens ont tendance à s’échanger les documents (spécifications fonctionnelles, spécifications techniques, listes de choses à faire, relevés de bugs, …) par email. Ça commence par un petit document rédigé par quelqu’un sur son traitement de texte ou son tableur. Voulant que ce document soit lu et utilisé par les autres intervenants du projet, cette personne va donc le leur envoyer par email. Les destinataires vont recevoir le document, le lire, et éventuellement le modifier. Les modifications seront elles-mêmes envoyées par email à toutes les personnes impliquées. Jusque-là, c’est assez clair.
Pourtant, malgré cette clarté apparente, le vers est déjà dans la pomme. Plusieurs pièges classiques peuvent apparaître :
- Plusieurs personnes modifient le même document, puis le renvoient. Vous vous retrouvez avec autant de versions différentes du même document. Tant que personne n’aura fait le travail de « réconciliation » pour fusionner ces versions, vous allez devoir jongler tel un acrobate.
- Le premier document aura certainement été nommé en respectant une norme, incluant le numéro de version du document et/ou sa date de création. Mais il y a de fortes chances pour que ceux qui l’éditeront ne pensent pas à modifier le nom du fichier avant de le renvoyer.
Le revendicateur
Je vais m’attarder sur un profil très particulier de personnes, celles qui ont le chic pour réclamer et revendiquer toutes sortes de choses, sans arrêt et quelles que soient les circonstances.
Nous avons tous rencontré ce genre de personnes un jour ou l’autre. Alors que vous mettez en place le design logiciel d’une nouvelle application, un de vos développeurs va prendre une heure pour vous expliquer à quel point il est important que tout le monde utilise les mêmes outils de développement que lui, par soucis de cohésion. Ou pendant que vous réfléchissez à une plate-forme serveur, l’architecte logiciel va réclamer à cors et à cris l’utilisation de tel ou tel module, même s’il sait qu’ils n’ont pas été validés pour une utilisation en production. Ou alors, votre supérieur tente de mettre en place une mauvaise méthode de travail parce qu’il n’en connaît pas d’autre. Cela pourrait même être un stagiaire qui revendique le droit d’utiliser une partie de son temps de travail pour travailler sur des projets scolaires.
La première chose à comprendre, c’est que ces personnes ne viennent pas vous casser les pieds pour le plaisir (même si parfois ça y ressemble fortement). Intrinsèquement, les revendicateurs sont des angoissés. Ils n’ont pas trouvé d’autre moyen de diminuer leur anxiété qu’en la partageant avec les autres ; et malheureusement pour vous, ils sont tellement submergés par ces préoccupations qu’ils ne trouvent pas la bonne manière de formuler les choses. Au final, ils tentent d’imposer leurs vues, alors que ce dont ils ont besoin, c’est d’être rassurés quant au fait que leurs problèmes sont connus et pris en compte.
Je distingue quand même deux types de revendicateurs : ceux qui sont de bonne foi, et les égoïstes primaires.
Ce qu’il ne faut pas faire
La réaction naturelle face à un collaborateur qui vous harcèle de la sorte, c’est de l’ignorer. Mais en faisant cela, vous risquez surtout de le voir revenir à la charge, encore plus souvent et de manière encore plus véhémente. Si vous insistez dans cette démarche, vous allez au-devant de gros problèmes : un revendicateur n’accepte pas d’avoir une porte fermée devant lui, il l’enfonce. Certains d’ailleurs finissent par y prendre plaisir et cherchent inconsciemment de nouvelles portes à défoncer.
Livre : Getting Real
Je vous ai déjà parlé de la société 37signals, au travers de ses outils Backpack et Basecamp. Je vais maintenant vous parler du livre qu’elle a publié en 2006 et qui contient toutes les règles de création et de gestion de projets web qu’elle applique en interne : Getting Real, The smarter, faster, easier way to build a successful web application.
Ce livre est disponible :
- Gratuitement, en le lisant en ligne.
- En version PDF pour 19 $ (49 $ pour une licence autorisant 10 copies).
- En version papier, pour 25 $ sur le service de publication à la demande Lulu.com.
Le titre du livre est sûrement un gentil jeu de mots avec la très connue méthode Getting Things Done. Ce clin d’œil est une manière à peine déguisée de dire qu’il faut oublier toutes les méthodes existantes, faire table rase et suivre leur direction. Le livre décrit leur propre méthode agile, qui est censée s’appliquer à la réalisation d’applications web, mais peut être utilisée – au moins partiellement – pour d’autres types de projets ou d’organisations.
37signals
37signals a été fondée en 1999, exerçant une activité de web agency. Au cours des années, elle s’est fait connaître en publiant tout d’abord Basecamp, l’outil de gestion de projet utilisé en interne, puis le framework Ruby on Rails sur lequel Basecamp est basé. Depuis, 37signals a sorti plusieurs services en ligne, allant de la gestion de données jusqu’à la relation client, en passant par la messagerie de groupe. Leur blog d’entreprise, Signal vs Noise, qui parle aussi bien des outils édités par la société que de design et de développement web, est très connu et visité.
L’effet tunnel
Toutes les personnes qui ont géré une équipe connaissent l’effet tunnel. C’est lorsqu’il vous est impossible de connaître l’état d’avancement d’une tâche ou d’un projet et que vous n’avez pas d’autre solution que d’attendre que le travail soit terminé pour pouvoir l’évaluer.
Avant d’étudier les origines de ce mal et comment le prévenir, voyons pourquoi l’effet tunnel est très mauvais :
- Vous n’avez aucune visibilité sur le planning. Comme il est impossible de savoir si la tâche sera terminée demain ou dans 2 semaines, il est tout aussi impossible de prévoir les retards sur l’ensemble du projet. Comment répartir les tâches et affecter les ressources lorsque vous ne maîtrisez pas la réalisation du travail ?
- Vous ne pouvez pas redresser le tir si le projet part dans une mauvaise direction. Vous pourrez évaluer les dégâts qu’une fois que tout sera terminé. Et bien souvent, vous aurez alors le choix entre vous satisfaire d’une réalisation bancale (travail incomplet, qui ne répond pas aux spécifications, insensé à maintenir) ou tout recommencer à zéro.
L’effet tunnel a toujours pour origine les choix des individus à qui vous confiez les tâches, et la manière dont ils les abordent. Dans tous les cas, vous pouvez l’éviter avec de la diplomatie et de la méthode.
Le glandeur naturel
La plupart du temps, l’effet tunnel est le fait d’une personne à qui vous avez laissé la possibilité de glandouiller tranquillement. Laissez 5 jours à un développeur pour créer un nouveau module, et vous pouvez être certain qu’il va passer 3 jours à faire autre chose, puis 1 journée à se demander ce qu’il va faire et à se motiver pour le faire, puis passer 3 jours à coder comme un fou. Résultat, il sera en retard et aura oublié qu’il devait faire une documentation succincte.
Lorsque vous demandez à un glandeur naturel ce qu’il est en train de faire, il ne va pas vous répondre « Je surfe sur des sites de foot parce que le nouveau championnat commence bientôt », même si c’est ce qu’il a fait pendant les 3 dernières heures. Il va plutôt prendre un air très affairé, peut-être même semblera-t-il agacé que vous lui fassiez perdre son temps, pour vous faire comprendre qu’il est vraiment plongé dans le boulot jusqu’au cou. Vous repartirez avec pour seule information « Je suis en plein dedans, c’est bientôt fini, je te préviendrai quand ce sera bon« , et une indéfinissable impression de vous être fait bananer.