J’ai déjà écrit plusieurs articles au sujet des collègues qu’on peut croiser au cours de notre vie professionnelle : les globalistes et les incrémentalistes, les affectifs, les revendicateurs, les nocifs…Je vais maintenant vous partager une expérience qui est intéressante. Je ne vous souhaite pas de vous retrouver face à ce…
Lectures pour les créateurs de startup
Voici une liste de livres et de liens à lire si vous voulez créer une startup. J’ai essayé de m’en tenir à des choses que j’ai trouvées vraiment utiles. (attention, cet article est très long)
Les pompiers pyromanes
L’un des profils de collaborateur les plus difficiles à manager sont les « pompiers pyromanes ». Voyons à quoi on reconnait un tel profil, les dangers qu’ils peuvent représenter et les solutions qui existent pour les gérer. C’est quoi un pompier pyromane ? Peut-être que vous vous êtes déjà retrouvés dans cette…
Management d’entreprise : trois exemples que tout oppose
Assez souvent, lorsque je discute de management et de gestion d’entreprise, on me dit que seule telle ou telle pratique garantit la réussite d’une entreprise ou d’un projet. Cela m’amuse, car je pense au contraire qu’il n’y a aucune recette miracle, et que chaque situation est différente. Pour illustrer cela,…
Les premiers enseignements de Rework
J’ai déjà parlé plusieurs fois de l’entreprise 37signals, de ses logiciels de gestion de documentation et de projet, et de sa méthode Getting Real. Actuellement, ses membres travaillent au successeur de leur livre, dont le nom sera Rework. Ils ont présenté quelques bribes d’information sur le livre, et je me suis arrêté sur le quatrième de couverture :
Je trouve que le texte qui s’y trouve est très intéressant, un brin controverse, et mérite qu’on s’y attarde. Voici une traduction très libre de son contenu, et ce que j’en pense.
“Dès que possible” est un poison
Il est vrai qu’en entreprise, on rencontre bien souvent ce genre de situation : On essaye de se mettre d’accord sur la spécification d’une nouvelle fonctionnalité, et quand vient le moment d’en définir la date de livraison, on se voit répondre “Dès que possible”. Cela peut sembler la réponse la plus honnête, la plus simple à comprendre de tous et la plus facile à gérer ; mais en fait il s’agit souvent d’un pis-aller qui démontre que le projet n’est pas réellement pris en main.
Quand on demande un développement ASAP (as soon as possible), on abdique sur tous les facteurs qui définissent un projet :
- La définition exacte du projet n’a pas été faite correctement. On sait bien qu’on n’a pas pris le temps de réfléchir à tous les cas limites, à penser à toutes les situations. On sait − mais on ne le dit pas ouvertement − que les développeurs devront affronter tous ces culs-de-sac fonctionnels au fur et à mesure qu’ils se casseront les dents dessus, ce qui empêche d’apporter une quelconque valeur aux estimations qu’ils peuvent faire de leurs développements.
- À partir du moment où la seule contrainte exprimée est celle du temps passé sur le projet, on accepte implicitement que des raccourcis soient fait pour atteindre l’objectif au plus vite. Un aspect en pâtira forcément, qu’il s’agisse de la qualité générale de la réalisation, de la maintenabilité du code, des tests, du débuggage, …
- À l’inverse, l’absence de deadline réaliste autorise les développeurs à se lancer dans des développements inutiles (je ne parle même pas de ceux qui se tournent les pouces). On arrive ainsi à des situations où on découvre au bout de 2 semaines que le développement “ASAP” aurait pu durer 4 jours si on avait pris le temps de dimensionner et budgéter le projet correctement ; mais si on en fait la remarque au(x) développeur(s), on obtient une réponse du genre «Ah, moi j’estime que tout ce que j’ai fait était nécessaire pour que le projet fonctionne correctement. Il fallait me prévenir si c’était plus urgent que ça !».
Et si Gordon Ramsay était informaticien ?
Depuis quelques temps je ne rate pas un épisode de l’émission Cauchemar en cuisine, qui est diffusée sur plusieurs chaînes télévisées françaises de la TNT ou du câble.
Le concept de cette émission est assez simple : Gordon Ramsay, un chef cuisinier écossais renommé, vient en aide à des restaurateurs au bord de la faillite. Là où ça devient amusant, c’est que Gordon n’a vraiment pas sa langue dans sa poche ; il n’hésite pas à s’énerver très fort quand il le faut, pour faire prendre conscience aux gens qu’il sont sur la mauvaise voie.
Bon, la traduction française a tendance à édulcorer son langage. Ainsi, la phrase «I will smash this plate on your fuking head» est devenu «Je vais casser cette assiette sur ta tête de bois»…
Au fil des épisode, on peut voir des cuisiniers sans talent, des gérants à l’égo stratosphérique, des restaurants complètement vides, des engueulades à côté des clients, …
Gordon goûte les plats, regarde comment fonctionne l’organisation du personnel, étudie les comptes financiers. Il met ensuite les responsables − le propriétaire, le gérant de salle, le chef cuisinier − face à leurs lacunes, leurs faiblesses, leur fainéantise, leur désorganisation. Quand les problèmes ont été compris (au bout de quelques bonnes engueulades hautes en couleur), il met en place un plan de bataille qui permet de remonter les résultats du restaurant.
Il utilise souvent les mêmes recettes (au sens figuré du terme, désolé je n’ai pas pu m’en empêcher) d’un restaurant à l’autre, mais à chaque fois avec des résultats différents. Ce qui est vraiment intéressant, c’est qu’il met en application des principes qui tiennent plus de l’entrepreneuriat que de la restauration. Il y a beaucoup d’inspiration à trouver là pour une équipe technique.
L’étude de marché
À chaque fois, Gordon fait un petit tour dans la ville où il est tombé. Il fait attention aux autres restaurants existants, et essaye de trouver le type de restauration qui n’est pas représenté. Il regarde aussi la clientèle existante (ou ce qu’il en reste), et à partir de tout ça il invente un nouveau visage au restaurant pour lui faire trouver une nouvelle clientèle.
Cette nouvelle identité est souvent mal vécue par les patrons qui voient leurs habitudes remises en question. Le menu est complètement revu (je vais y revenir), le restaurant est redécoré, parfois même renommé. Mais ce nouveau positionnement est gagnant, et l’augmentation des bénéfices lui donne toujours raison.
Lenny’s golden rule of management
Dans mon dernier billet, je vous parlais de la règle d’or du management de Loïc. Je vais maintenant vous parler d’une autre règle qui, sous son aspect – et son origine – humoristique, possède une réelle profondeur : « Tout le monde peut faire des erreurs, c’est pour ça qu’il y a…
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.
L’encadrement des juniors
L’encadrement de juniors (stagiaires et jeunes diplômés) est un sujet assez vaste, et je vais juste aborder ici un point de détail qui concerne la manière dont les entreprises abordent leur productivité.
Il existe un principe de base qui est valable pour tout le monde :
« Comprendre ce qu’on fait et ce sur quoi on travaille »
Quand on embauche une personne qui a de l’expérience, c’est souvent pour la faire travailler sur des projets assez pointus. Dans ce cas, on s’attend communément à ce que la complexité de la tâche implique un « temps de démarrage » conséquent.
Il est assez logique que les juniors, pour leur part, se voient affecter des tâches plus accessibles d’un point de vue technique. Mais de nombreuses personnes voudraient qu’un junior soit immédiatement opérationnel. La réflexion qui est faite est du style : « Ce n’est pas bien compliqué, franchement, il devrait avoir terminé dans 2 jours, non ? ».
Le problème, c’est que n’importe quel travail doit se faire en ayant une maîtrise de son environnement et de ses impacts potentiels.
On ne peut pas demander à un jeune embauché de faire du bon boulot, si on n’a pas pris le temps de le former correctement sur les méthodes et outils spécifiques employés dans l’entreprise. Même si le travail demandé semble mineur, il faut se souvenir que l’expérience du collaborateur est limitée elle aussi. Un défaut d’encadrement peut conduire à des situations désagréables. La plus commune est que le junior, après avoir travaillé 3 jours sans avoir reçu de formation interne, doit recommencer tout le travail parce qu’il n’a pas respecté les directives qu’il n’a pourtant pas eues. On voit aussi fréquemment des personnes qui commencent à modifier du code sans le comprendre, générant un nombre incroyable de bugs de régression.
La pire situation que j’ai vue, c’est une entreprise qui formait ses jeunes « à la dure » : aucune formation, directement affectés aux débuggages ! Autant vous dire que ce n’était pas très efficace…
Si vous encadrez un junior
Vous devez lui fournir toutes les informations nécessaires. On ne laisse pas les gens se débrouiller tous seuls ; cela revient à les laisser dans la merde. Prenez le temps d’expliquer les méthodes, outils et usages qui ont cours dans votre entreprise. Faites leur faire un premier projet pour se faire la main, sur lequel vous les encadrerez de très près.
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.