Partir ou rester ?

Il arrive forcément un moment dans une carrière où on ressent l’envie de quitter son emploi. Cela peut avoir de multiples raisons : Le travail n’est pas très intéressant, le poste n’offre pas de perspectives d’évolution, on ne s’entend pas bien avec certains collègues, le salaire n’évolue pas comme on le souhaite… Toutes ces raisons sont bonnes, à partir du moment où elles sont légitimes.

Ça gratouille

Quand on commence à se sentir mal quelque part, c’est bien souvent qu’une petite gêne invisible a eu le temps de grossir jusqu’à devenir vraiment désagréable. C’est un peu comme lorsque l’étiquette de votre t-shirt vous pique dans le cou : au début on n’y fait pas attention, mais plus la journée avance plus on ne pense qu’à ça ; on commence à se gratter et à la fin on est obnubilé par l’idée d’enlever ce p$%*@ de t-shirt.
C’est certain, il est inutile de garder sur soi un t-shirt qui vous gratte. Mais plutôt que de l’arracher et d’en faire des lambeaux, il vaudrait mieux découper proprement cette agaçante étiquette, non ?

Alors quand vous sentez un certain mal-être professionnel s’immiscer en vous, prenez le temps de vous demander quelles sont les raisons à cela. Très souvent, le simple fait de se poser la question vous ouvrira les yeux sur les réponses à y apporter. Dans la plupart des cas, les soucis que vous ressentez sont partagés par d’autres personnes ; commencez par en parler avec elles, étudiez à plusieurs les solutions que vous pouvez mettre en place.

Si vous ne trouvez pas de solutions par vous-même, n’hésitez pas à requérir une discussion en tête-à-tête avec votre supérieur hiérarchique ou le responsable des ressources humaines. Ce n’est peut-être pas évident pour vous, mais la plupart des dirigeants désirent sincèrement que leurs employés se sentent bien au travail. Faites-leur comprendre votre désarroi ; s’ils ont un tant soit peu d’empathie, ils se mettront à votre place, tenteront de vous comprendre, et chercherons avec vous les résolutions qui pourraient ramener les choses à un état plus satisfaisant.

Dans certains cas, ce type d’entrevue doit être privilégié. Si vous n’êtes pas content de votre salaire, évitez d’en parler avec tous vos collaborateurs ; cela vous nuirait plus qu’autre chose.

Ça chatouille

Peut-être avez-vous envie de changer d’air, non pas parce que vous n’êtes pas heureux là où vous êtes, mais parce que l’envie de voir autre chose – ou de créer votre propre affaire – se fait pressante.

La bonne nouvelle, c’est qu’il s’agit là de bien meilleures raisons. Il est plus agréable, mais aussi plus « noble » du point de vue de vos supérieurs, d’être chatouillé par l’ambition que d’être gratouillé par un mal-être.
Là aussi, prenez le temps de vous poser quelques questions. Pour commencer, êtes-vous bien certain que cette envie n’a pas pour origine un petit gratouillage caché ? Si c’est le cas, relisez les paragraphes précédents. Ensuite, commencez par regarder autour de vous. Il est plus constructif de trouver de nouveaux défis sans pour autant tout envoyer valser.

Livre : Managing Humans

Je vais vous parler un peu d’un très bon livre, nommé Managing Humans, écrit par Michael Lopp et publié par Apress en 2007. Depuis 2002, il tient sous le pseudonyme de Rands le blog Rands in repose, dans lequel il parle de ses expériences en tant que manager d’équipes techniques. Et il en a des choses à dire, le bougre, après avoir travaillé pour Symantec et Netscape, entre autres.

Managing Humans - couverture

Le sous-titre du livre est assez explicite : « Biting and humorous tales of a software engineering manager ». Le livre est truffé d’anecdotes amusantes, de mises en situation réelles ou imaginaires, qui en font un ouvrage à part dans l’univers très fourni des livres dédiés à la gestion de projet et au management.
Personnellement, j’ai une affection particulière pour ce livre. Je l’ai acheté à sa sortie en 2007, alors que j’étais en train de créer mon entreprise. Je n’y ai pas trouvé de recette miracle, mais plein d’exemples de choses à faire ou ne pas faire ; je pense avoir évité plusieurs pièges dans la création de mon équipe grâce à ce livre.

Ne pas être un con

Le premier chapitre du livre se nomme « Don’t be a prick ». L’ensemble des 209 pages pourrait être résumé dans cette simple phrase. Ça paraît débile tellement c’est simple. Mais au cours de ma carrière, j’ai franchement rencontré tellement de personnes qui agissaient comme des gros cons, que ça mérite d’être souligné. Que ce soit par bêtise, inexpérience, indélicatesse, fainéantise, vanité ou parce qu’ils n’avaient rien à faire à ce poste, il est sidérant de voir combien de dirigeants sont inaptes à gérer les hommes et les femmes qui composent leurs équipes.

Le carquois du management

Rands utilise une métaphore assez intéressante. Il dit que nos compétences en management sont comme des flèches dans un carquois. Quand on rencontre un problème, on peut prendre la flèche appropriée, prendre un peu de recul, viser et tirer. C’est le titre qu’il a donné à la première partie du livre.

Les méthodes agiles

Cet article fait suite à ceux consacrés au cycle en V et au cycle itératif. Dans l’histoire des méthodes de gestion de projets informatiques, les méthodes agiles sont une évolution relativement récente qui tente de résoudre certains défauts des pratiques qui étaient en usage jusque-là.

Le manifeste agile

La définition de toutes les méthodes agiles est synthétisée par le Manifeste agile, qui a été rédigé en 2001 par plusieurs acteurs de ce domaine. Il distingue 4 valeurs fondamentales et 12 principes.

Les 4 valeurs

(traduction © Wikipedia et al)

  • L’interaction avec les personnes plutôt que les processus et les outils.
  • Un produit opérationnel plutôt qu’une documentation pléthorique.
  • La collaboration avec le client plutôt que la négociation de contrat.
  • La réactivité face au changement plutôt que le suivi d’un plan.
Les 12 principes

(traduction © Wikipedia et al)

  • Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
  • Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
  • Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
  • Les gens de l’art et les développeurs doivent collaborer quotidiennement au projet.
  • Bâtissez le projet autour de personnes motivées. Donnez leur l’environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
  • La méthode la plus efficace de transmettre l’information est une conversation en face à face.
  • Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
  • Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
  • Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité.
  • La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle.
  • Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent.
  • À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

Application concrète

Il existe plusieurs méthodes qui suivent l’esprit du manifeste. Elles ont chacune leurs spécificités, mais de manière globale elles œuvrent toutes dans les mêmes voies.

L’affectif

Pour bien gérer les rapports entre les intervenants d’un projet, il est nécessaire de comprendre comment chaque personne fonctionne. Je vais ainsi vous brosser plusieurs portraits types. Évidemment, les collaborateurs avec qui vous devrez travailler ne colleront jamais complètement à ces portraits ; ou plutôt, chaque personne présente des aspects qui peuvent être assimilés à tel ou tel type. À vous de les comprendre et de vous adapter en conséquence.

L’affectif

Si j’ai choisi de commencer par ce profil, c’est parce que nous avons tous une part d’affectif en nous. C’est quelque chose que nous connaissons bien, mais que nous avons parfois du mal à reconnaître ou à accepter chez les autres.

Un « affectif » a tendance à réagir à l’instinct. Quand il a un bon moral, que tout semble se mettre en place favorablement autour de lui, il devient un travailleur efficace et très impliqué. Malheureusement, il suffit d’un petit grain de sable pour stopper la machine.
Un des facteurs les plus importants pour ce genre de personne, c’est la reconnaissance de sa valeur, et donc de son travail. Un affectif pourra se donner à fond, même pendant de longues périodes, tant qu’il sent que ses supérieurs lui en sont reconnaissants et qu’ils apprécient son travail. C’est souvent quelqu’un qui doit être motivé de manière positive continuellement.

À l’inverse, il suffit parfois d’une remarque pour que l’affectif se démotive complètement. Cela peut être juste une question légitime, au sujet d’un bout de code que vous ne comprenez pas ; il aura quand même l’impression que vous pensez qu’il a fait du mauvais boulot. Il existe alors 2 versions, qui aboutissent au même résultat :

  • L’affectif « combatif » décidera que vous avez tort, et travaillera moins ou moins bien par choix. C’est une manière de revendiquer.
  • L’affectif « démoralisé » se mettra à douter de ses capacités et commencera à cogiter, jusqu’à ne plus pouvoir travailler parce que son cerveau est trop occupé.

Backpack

Je vais vous parler de Backpack, un outil réalisé par 37Signals, une entreprise dont nous aurons l’occasion de parler de nouveau.

Backpack se définit comme un outil d’organisation et de partage d’information. Voici des images qui vous feront comprendre rapidement de quoi il retourne :

(image © 37signals.com)

(image © 37signals.com)

Fonctionnalités

Ce logiciel est d’une grande simplicité d’utilisation. Sa fonctionnalité principale est la création de « pages ». Une page est, comme le montrent les exemples ci-dessus, la combinaison de plusieurs éléments :

  • Des listes minimales, qui comprennent juste un titre et un état fait/à faire.
  • Des notes, composées d’un titre et d’un texte.
  • Des « writeboards », qu’on peut assimiler à des pages de wiki simplifiées.
  • Des pièces-jointes (uniquement disponibles dans la version payante).

Approche globale ou pas-à-pas

Il y a plusieurs manières de mener une équipe. Je vais m’intéresser ici à la manière dont on communique pour suivre l’avancement des projets. Cette question est assez intéressante et complexe, car elle a des impacts sur la méthode de gestion de projet.

En fait, les gens peuvent être placés dans 2 grandes catégories :

  • Ceux qui veulent voir leurs projets de manière globale.
  • Ceux qui privilégient les petites avancées.

Je ne parle pas de la manière dont on choisit d’aborder les projets, mais plutôt comment on a tendance à réagir naturellement, comment on se sent mieux de travailler. Il y a des avantages et des inconvénients aux deux. Il est bon de savoir dans quelle mouvance on se situe et comment sont nos collègues, pour améliorer le travail d’équipe.

L’approche globale

Certaines personnes éprouvent le besoin vital de comprendre les projets dans leur globalité pour pouvoir travailler dessus. Ils ont souvent une bonne vision de l’ensemble des forces et des faiblesses d’un programme en cours de conception. Pour eux, le seul moyen raisonnable d’exécuter une tâche est de le faire de la bonne façon (ce qui pour eux signifie souvent d’y réfléchir pendant des mois pour être certain de prendre en compte tous les cas imaginables et inimaginables).

Le problème avec ces personnes, c’est qu’elles peuvent tomber dans l’immobilisme. Elles considèrent souvent qu’une réalisation incomplète ou imparfaite est pire que de ne rien faire. Et les tergiversations peuvent durer longtemps avant de définir la manière dont une tâche peut être effectuée suffisamment bien pour les satisfaire.

Le pas-à-pas

D’autres personnes, au contraire, sont capables de démarrer un projet très rapidement et de le faire avancer par évolutions successives. Ils ont une bonne idée du travail qui peut être réalisé en fonction des ressources disponibles à un instant donné, et connaissent souvent tous les petits détails techniques de leurs projets.

Par contre, ces personnes ont besoin d’être encadrées de près, car elles peuvent faire prendre à leurs projets des directions non souhaitables. Le souci, c’est que chaque petite amélioration peut sembler à la fois sensée et peu coûteuse.

Livre : Getting Things Done – Présentation

La méthode Getting Things Done (ou GTD en abrégé) a été inventée par David Allen et publiée en 2001 dans un livre nommé « Getting Things Done – The art of stress-free productivity ». L’ouvrage a été traduit en français sous le nom « S’organiser pour réussir – La méthode GTD ou l’art de l’efficacité sans le stress ».

Getting Things Done - David Allen - couverture

Malgré son nom un peu ronflant (sans parler du « sous-titre » qui est une perle marketing), cette méthode bénéficie d’une très grande notoriété. On ne compte plus le nombre de sites qui y sont consacrés ni le nombre d’outils qui s’adaptent à ses recommandations.

Le principe

La première chose à savoir est que GTD est une méthode d’organisation personnelle. Vous pouvez l’utiliser pour être plus efficace dans votre travail et dans vos occupations personnelles, mais vous ne pourrez pas vous baser dessus pour définir l’organisation de votre équipe ou de votre entreprise.

Contrairement à la plupart des méthodes qui tentaient d’organiser la gestion du temps, la méthode GTD se concentre sur la réalisation des tâches qui nous incombent. Pour cela, il faut se reposer sur un système unique pour recenser l’ensemble des tâches, identifier leur ordre de priorité, et passer en revue cette liste très fréquemment pour en cataloguer les éléments.

Je vais vous donner les grandes lignes de ce qui fait la force de cette méthode d’organisation. Je reviendrai sûrement sur le sujet dans le futur, tant il est vaste. Mais nul besoin de lire les 287 pages du livre pour en comprendre les concepts les plus importants.
Un schéma récapitule l’ensemble du processus (il est d’ailleurs répété 4 fois dans le livre !).

Getting Things Done - déroulement

Action Method

Je vais vous parler aujourd’hui d’Action Method, qui est le nom d’un web-logiciel d’organisation et de gestion de projets, mais aussi celui de la méthode d’organisation qui y est préconisée et que le logiciel permet de suivre et appliquer.
Cet un bon exemple de la mouvance des nouveaux outils de gestion de projet, qui privilégient la communication et résolution de tâches plutôt que la gestion du temps et le flicage des gens.

Pour la petite histoire, l’entreprise qui est à l’origine de ce logiciel (Behance) a commencé par faire connaître la méthodologie Action Method en vendant des organiseurs papier. Jetez-y un oeil, certains produits pourraient vous intéresser si vous gérez vos projets « à l’ancienne ».

La méthode

Pour bien utiliser ce logiciel, il faut donc comprendre la méthode sous-jacente. Ses idées principales sont :

  • Réduire les échanges de communication (bannir les emails !) au profit de l’action et de la résolution des tâches. Les discussions importantes doivent pouvoir être suivies facilement et non être cachées dans des chaînes d’emails.
  • Partager uniquement les informations qui le nécessitent.
  • Les actions peuvent être déléguées et non assignées ; on ne s’en débarrasse pas.
  • Les fonctionnalités prouvent leur importance par « sélection naturelle ». Voir la notion de harcèlement plus bas.

Cette méthode définit 5 types d’éléments de base :

  • « Action steps » : Actions à réaliser. Devrait toujours commencer par un verbe (« Appeler machin », « Faire ceci », …).
  • Références : Toutes informations (notes, liens, fichiers) liées à un projet qui donne du contexte aux Action Steps.
  • « Backburners » : De simples idées qui ne génèrent pas encore d’action, mais sur lesquelles on veut revenir plus tard.
  • Discussions : Toutes les communications concernant un projet (documents partagés, décisions, solutions aux problèmes, feedbacks, …) sont regroupées au même endroit et sont accessibles aux personnes travaillant sur ce projet.
  • Evénements : Réunions, étapes, occasions particulières, dans le futur du projet. Peuvent servir de deadline aux Action steps.
Le logiciel

La vue globale de chaque projet récapitule tous ces éléments d’une manière assez réussie à mon goût. Les informations sont clairement affichée et facilement accessibles.

Action Method - Page projet (image © actionmethod.com)

Le cycle itératif

Si vous avez lu mon billet sur le Cycle en V, vous savez pourquoi ce type de méthode de travail n’est pas adapté à la plupart des projets informatiques, qui réclament une plus grande souplesse. En l’appliquant de manière rigide, on finit par obtenir des logiciels mal adaptés (fonctionnalités sans priorités), livrés en retard (chaque étape bloque les suivantes) et souvent buggués (la technique se plie au fonctionnel).
C’est ainsi qu’est née la méthode du cycle itératif (ou incrémental), qui tente de formaliser une approche plus pragmatique et maniable.

Cycle itératif

Définition

Cette méthode se décompose en 6 étapes, dont 4 qui en constituent le « coeur » :

  • L’expression de besoin : Le client explique ce qu’il veut obtenir. On peut faire un parallèle avec l’étape de faisabilité du cycle en V, et dans une moindre mesure avec les spécifications fonctionnelles. L’idée reste que les informations en entrée peuvent être modifiées par la suite du processus.
  • Le coeur du processus itératif :
    • Spécification : C’est la traduction en langage technique des besoins fournis en entrée. C’est la réponse aux questions « qu’est-ce qu’on fait ? » et « comment on va le faire ? ».
    • Développement : Il s’agit de la réalisation concrète de ce qui a été défini.
    • Validation : C’est l’ensemble des tests qui permettent de s’assurer que le développement effectué correspond bien à ce qui était attendu.
    • Évaluation : Cette étape sert à effectuer un retour sur les écueils rencontrés et les fonctionnalités abandonnées pendant les 3 étapes précédentes, et l’utiliser comme informations d’entrée pour un nouveau cycle.
  • Déploiement : Les livrables qui ont été validés sont déployés pour que le client y ait accès.

Sous-estime, surestime et implication

J’espère que vous avez lu mon article Échelle différente, problèmes similaires. J’y décris le fait que les obstacles rencontrés sont souvent les mêmes, quel que soit notre place dans notre entreprise, seule l’échelle de valeurs de ces problèmes diffère. C’est une constatation simple, que tout le monde peut faire en observant les personnes qui les entourent.

Mais il existe un corollaire à cela, qui est très intéressant lui aussi, et qui touche au comportement des gens. Quand on arrive dans une nouvelle entreprise ou un nouveau poste, on a tous une tendance naturelle à se sous-estimer et à surestimer nos supérieurs. Si, si. Je vous vois déjà faire la moue en vous disant « Mais non, pas du tout ! ». Mais si vous prenez le temps de regarder les choses en face, vous vous rendrez compte que plus d’une fois vous n’avez pas osez remettre en question une décision d’un supérieur, alors que vous n’auriez eu aucun scrupule si l’idée était venue de quelqu’un de même niveau hiérarchique que vous. Et combien de fois avez-vous remis à plus tard une implémentation ou une discussion dont vous étiez convaincu de l’utilité, uniquement parce que vous n’osiez demander l’aval de votre – très occupé – manager ?