Le revendicateur

AmauryOrganisation d'équipeLaissez un commentaire sur 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.

Taskii

AmauryOutils3 commentaires sur Taskii

Taskii est un logiciel créé par une entreprise belge, qui surfe sur la mouvance des outils de collaboration en ligne (dont le fer de lance est Basecamp). Dès la première page du site, la couleur est annoncée : « Taskii importe le concept de Basecamp en français » (extrait d’une revue du service effectuée par TechCrunch).

Et c’est vrai qu’on pourrait rapidement synthétiser Taskii en 2 points :

  • Globalement la même ergonomie que Basecamp, mais en français.
  • Globalement les mêmes fonctionnalités que Basecamp, mais moins cher.

L’outil propose 5 fonctionnalités principales :

  • Les todo-lists.
  • La vue calendaire.
  • La messagerie partagée.
  • Le partage de fichiers.
  • Les feuilles de temps.

Le prix

Commençons par le premier facteur différenciant (en dehors de la langue). Taskii est disponible en 5 formules différentes :

  • L’accès gratuit permet de créer 2 projets et offre un espace de 10 MO.
  • L’offre Basic (12 € par mois) permet de gérer 15 projets, apporte 4 GO de stockage et le support par email.
  • L’offre Premium (45 € par mois) monte à 50 projets et 10 GO.
  • L’offre Secure (65 € par mois) ajoute à la précédente l’encryption SSL.
  • L’offre No limit (145 € par mois) offre un nombre illimité de projets, 100 GO d’espace de stockage, l’encryption SSL et le support par email et téléphone.

Comme on peut le voir, les tarifs sont plus bas que ceux auxquels on est habitué. Et même si je persiste à trouver ridicule de faire payer l’encryption SSL, je salue l’effort qui est fait pour rendre accessibles toutes les fonctionnalités dès la création d’un compte gratuit.

Les todo-lists


(image © Taskii.com)

La création de tâches se fait d’une manière très souple. On peut facilement les affecter à un utilisateur, et leur définir une date d’échéance. Il n’est malheureusement pas possible de définir une priorité aux tâches. On peut les réorganiser par drag ‘n drop, mais il est impossible de changer l’apparence d’un titre (même pas de syntaxe wiki pour mettre du texte en gras, par exemple).

Livre : Getting Real

AmauryOrganisation d'équipe4 commentaires sur 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 :

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é.

Flyspray

AmauryOutilsLaissez un commentaire sur Flyspray

J’en parlais dans mon billet consacré aux listes, les buglists sont un élément essentiel dans la gestion des développements informatiques. Impossible de créer un logiciel, quel qu’il soit, sans y introduire des effets indésirables imprévus. Et il faut trouver un moyen efficace de lister ces bugs et de suivre leur résolution.

Je vais vous parler d’un logiciel open-source entièrement dédié à cela : Flyspray

Flyspray - page principale

Présentation

Flyspray est un logiciel développé en PHP, proposé gratuitement sous licence libre. Il est très facile à installer sur un serveur Linux, avec une base de données MySQL ou Postgresql. Ce n’est donc pas un logiciel qui s’utilise à distance sur les serveurs de son éditeur ; pas besoin de payer un abonnement mensuel. Par contre, il faut avoir un serveur à disposition (mais c’est souvent le cas en entreprise).

Basecamp

AmauryOutilsUn commentaire sur Basecamp

Je vais vous présenter aujourd’hui le logiciel Basecamp, qui est développé par 37Signals. C’est un peu le grand frère de Backpack dont je vous parlais la semaine dernière.

Là où Backpack visait à faciliter le stockage et l’échange d’information autour de projets, Bascamp va plus loin et propose des outils pour gérer plus finement le travail de groupe. On peut distinguer 5 fonctionnalités principales :

  • Les todo-lists.
  • La messagerie partagée.
  • Le partage de fichiers.
  • Les objectifs calendaires.
  • « Reporting » du temps passé sur chaque projet.

Auxquelles s’ajoutent des panneaux de vues globales sur un projet ou sur tous les projets.

Les todo-lists

(image © 37signals.com)

Je vous ai déjà expliqué pourquoi les listes sont à la base de toute organisation. Basecamp permet de créer facilement des listes et de les organiser comme on le souhaite. Très similaires à celles de Backpack, on peut éditer leurs titres en utilisant la syntaxe Textile (syntaxe wiki-like simplifiée), et leur affecter un état fait/à faire simplement en cochant ou décochant une case. Par contre, elles offrent la possibilité d’affecter une tâche à un utilisateur, ce qui était un des manques que je pointais du doigt sur Backpack.

Il est aussi possible de créer des listes privées, qu’on est le seul à pouvoir voir. C’est une bonne idée, qui permet d’avoir au même endroit les todo-lists générales et celles qui nous concernent ; cela évite d’avoir à gérer plusieurs systèmes de listes en parallèle.

La messagerie partagée

(image © 37signals.com)

On a beau classer nos emails dans des dossiers, il est toujours pénible d’y rechercher une information intéressante. On est souvent obligé d’ouvrir une demi-douzaine de messages – de quelques lignes chacun – avant de retrouver ce qu’on veut.

L’effet tunnel

AmauryOrganisation d'équipe24 commentaires sur 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.

Partir ou rester ?

AmauryVotre carrière5 commentaires sur 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

AmauryOrganisation d'équipe5 commentaires sur 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

AmauryOrganisation d'équipe26 commentaires sur 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

AmauryOrganisation d'équipeLaissez un commentaire sur 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é.