Il y a environ un an, je vous parlais du logiciel Action Method. Il propose une fonctionnalité «nagging», qui permet de rappeler au responsable d’une tâche que celle-ci réclame une attention particulière ou une exécution rapide. J’aime bien cette fonction toute simple mais très utile. J’ai implémenté la même chose…
Du micro-management jusqu’à la délégation, le long parcours de la confiance
Quand on gère une équipe, on se retrouve régulièrement confronté à un dilemme : Quand et comment déléguer ?
Même si on n’est pas un control freak, on ne va pas confier “les clés de la maison” aveuglément ; mais d’un autre côté, il n’est pas possible de demander aux gens de donner le meilleur d’eux-mêmes si on est sans cesse en train de les surveiller. Alors que faire ?
Types de management
La plupart des livres et méthodes de management mettent en avant 2 points qui sont réellement importants (et qui sont liés l’un à l’autre) :
- Il faut responsabiliser les personnes que l’on encadre. Ainsi ils gagneront en confiance, prendront des initiatives, réfléchiront par eux-même, travailleront de manière autonome, feront attention à la qualité de leur travail.
- Le corollaire : Il ne faut pas faire de micro-management.
Le micro-management consiste à être continuellement sur le dos des membres de son équipe, de surveiller leurs moindres faits et gestes. C’est une mauvaise pratique pour plusieurs raisons :
- Une surveillance constante induit un climat pesant et génère du stress. Personne n’aime travailler dans ces conditions, la qualité du travail ne peut pas être optimale.
- Quand on est à l’affut de la plus petite erreur, et qu’on signale chaque maladresse, on place la personne dans une situation d’échec continuel qui est fortement démoralisante.
- Tous les processus d’apprentissage comportent des cycles erreur-réessai qui ne peuvent pas se faire si on est paralysé par la hantise de l’échec.
- Dans une moindre mesure, quand on surveille les autres, on ne fait rien de réellement productif soi-même.
Donc nous sommes d’accord, il faut éviter le micro-management.
Mais l’excès inverse est tout aussi néfaste. Je connais des gens dont la technique de management est «Laisser les gars se débrouiller» ; cela a pour résultat de “laisser les gars dans la merde” et non pas de créer des gars débrouillards.
La confiance
On en vient au point essentiel : la confiance
Il est impossible de confier des responsabilités à quelqu’un si on ne fait pas confiance à cette personne.
Skriv : Fonctionnalités
(ce billet fait partie d’un ensemble consacré au projet Skriv)
Alors, j’ai commencé par discuter de l’accès au service et de son prix. Maintenant il serait bon de s’attacher au cœur du problème : à quoi va-t-il servir exactement, quelles vont être ses fonctionnalités ?
Je voudrais définir un outil qui puisse servir aussi bien pour gérer des projets professionnels que personnels. Je dois avouer que la plupart de mes projets personnels ressemblent furieusement à des projets informatiques, mais ce n’est pas une règle absolue.
Comme je l’ai dit en commentaire du précédent billet, la vision que j’ai de Skriv est celle d’un outil de travail collaboratif plus que d’un outil de gestion de projet. Je ne souhaite pas faire un logiciel qui servira uniquement aux “décideurs” pour suivre le travail de leurs employés ; je veux faire le méga-tableau-de-bord qui servira tous les jours (et plusieurs fois par jour !) à l’ensemble de mes collaborateurs pour organiser leur travail, pour communiquer sur tous les aspects de leur travail.
Fonctions de base
On peut reprendre les 4 grands types de fonctionnalités habituelles :
- Un affichage “tableau de bord” qui affiche l’activité récente sur un projet ou sur tous les projets auxquels l’utilisateur a accès.
- Les listes. Il faut pouvoir créer autant de listes que nécessaires, avec la possibilité de les adapter aux besoins (buglist, todolist, checklist).
- Les pages de documentation textuelle. Appelons ça un « wiki », même si j’hésite entre l’utilisation d’une syntaxe de type wiki et l’utilisation d’un éditeur HTML WYSIWYG. Il faut pouvoir lier une page de wiki à une tâche.
- Le partage de fichiers. Chaque projet a bien souvent besoin de fichiers binaires, qu’il s’agisse de feuilles de calcul, d’images ou autres. Il faut pouvoir lier un fichier à une tâche.
Fonctions supplémentaires
Ce qu’on peut y ajouter :
- Des “vues” calendaires, mais je place ça plutôt dans la partie ergonomie/affichage. Cela reste important, surtout si on se sert de ces vues pour éditer les tâches (ce qui revient plus ou moins à avoir un diagramme de Gantt).
- Des rappels par email ou SMS, que ce soit pour nous rappeler des tâches (todolist/buglist de projet) ou définis personnellement.
- La connexion à un compte IMAP. Il y a toujours des informations importantes qui sont échangées par email (même si ce n’est pas une bonne pratique). On pourrait dédier un dossier IMAP à chaque projet, et y accéder via l’interface. On pourrait trouver un moyen pour créer des tâches à partir d’emails, et extraire les pièce-jointes des emails pour les ajouter au partage de fichiers.
- Un système de micro-blogging. Même si j’ai déjà fait part de mon scepticisme vis-à-vis de ce genre d’outil, il y a sûrement moyen de créer un canal de communication supplémentaire. Les micro-messages seraient affichés sur le “tableau de bord” au milieu des indications d’évolution du projet.
Concernant la «communication» :
- On pourrait imaginer que le logiciel pourrait envoyer des emails avec un résumé quotidien ou hebdomadaire des évolutions d’un ou plusieurs projets qu’on aurait décidé de « suivre ».
- Il faudrait proposer des flux RSS permettant aux utilisateurs de suivre leurs projets dans un outil externe. Un flux qui reprenne l’activité de tous les projets, un flux pour l’activité des projets “suivis”, et un flux par projet.
- Il faudrait aussi proposer un export au format ICS (iCalendar), pour permettre de suivre les tâches et les projets dans un outil externe comme iCal, Sunbird ou Google Calendar.
Les clés de la réussite
Je n’aime pas le titre de cet article, il est assez pompeux et ressemble à une « formule miracle ». Mais je n’en ai pas trouvé de meilleur.
Je me suis déjà retrouvé plusieurs fois à tenter d’expliquer à de jeunes informaticiens (hum, même à des moins jeunes, d’ailleurs) les divers principes à appliquer au quotidien pour faire avancer leur carrière ou améliorer la manière dont ils gèrent leur travail. Et avec le temps, je me suis rendu compte que ces principes peuvent au final être résumés en 3 points clés :
- Simplicité
- Communication
- Passion
Évidemment, ils ne suffisent pas à donner toutes les directions à suivre. Mais si, jour après jour, chaque action est guidée par ces 3 principes, on se rend compte que l’on fait naturellement de bien meilleurs choix. Je me suis surpris moi-même récemment, au moment de prendre certaines décisions, à me demander «N’est-ce pas trop compliqué ? Qui dois-je en avertir et avec quel niveau de détail ? Ai-je vraiment envie de faire ça de cette manière, y ai-je consacré l’attention nécessaire ?». Et cela m’a permis de revoir certains choix de façon éclairée.
Voyons voir en quoi tout cela consiste.
Simplicité
La simplicité est un concept important mais trop souvent sous-estimé. Pourtant, il est valable à tous les niveaux.
Quelques exemples qui seront plus parlant :
- La modélisation d’un composant logiciel, d’une base de données, d’une API gagne toujours à être la plus simple possible. L’histoire est jonchée de technologies diverses, de protocoles réseaux, qui ont disparu par « sélection naturelle ». À chaque fois que quelque chose est trop compliqué, d’autres technologies plus simples à mettre en œuvre apparaissent. Alors réfléchissez à vos propres développements : s’ils ne sont pas aussi simples qu’ils le pourraient, c’est vous qui allez souffrir à l’avenir.
- L’offre de produits/services de votre entreprise doit être aussi facile à comprendre que possible pour vos futurs clients. Les offres à tiroirs et les options complexes n’inspirent pas confiance, ils ne donnent pas envie d’acheter. Assurez-vous d’avoir un discours clair et limpide.
- Vous n’arrivez pas à faire en sorte que votre équipe utilise correctement le coûteux logiciel de gestion de projet que vous avez mis en place, malgré toutes les fonctionnalités hyper-géniales qu’il offre ? Incitez-les à utiliser correctement des outils simples, pour commencer ; donnez-leur un bloc-note à chacun pour noter leurs todo-lists, et gérez vos projets à coups de post-its collés sur un mur visible par tout le monde. Puis introduisez graduellement les outils plus structurés.
- Vous n’arrivez pas à vous faire comprendre en réunion, vos idées sont systématiquement mises de côté ou on ne vous accorde pas tout le crédit que vous méritez ? Peut-être êtes-vous un peu trop brouillon, vous n’arrivez pas à agencer votre discours. Simplifiez-le ! Ne laissez pas les idées se précipiter toutes en même temps, prenez soin de les trier dans votre tête avant d’en exprimer les grandes lignes avec des phrases courtes.
Vous connaissez l’adage : on n’a pas atteint son but quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retirer. Adoptez une approche zen.
Communication
Une bonne communication est nécessaire en toutes circonstances. Quelques exemples :
Skriv : Identification et prix
(ce billet fait partie d’un ensemble consacré au projet Skriv)
J’ai rassemblé sur ce billet deux sujets différents et au final pas très importants − par rapport aux fonctionnalités ou à l’ergonomie, par exemple − mais dont je voulais parler quand même. Comme ça on pourra ensuite se concentrer sur le plus important.
Création de compte et identification
Il faut évidemment permettre la création de compte directement sur le site. Mais ce serait une bonne idée d’autoriser l’identification par des procédés d’authentification centralisés. Le premier qui me vient à l’esprit est OpenID, qui est un protocole standard prévu exactement pour cela. On peut y ajouter le Google Federated Login (basé sur OpenID), Yahoo! OpenID, Windows Live ID (basé sur OpenID lui aussi), l’identification centralisée de Twitter (utilisant OAuth), ou encore Facebook Connect.
Ces systèmes permettent de créer un compte quasi-instantanément. Il suffit de cliquer sur le bouton « Google », on arrive sur une page chez Google qui nous demande si on veut continuer (pour peu qu’on soit déjà identifié chez Google), on clique sur « Oui », et hop ça y est. C’est assez séduisant.
Ensuite, il faut voir la complexité d’implémentation de chaque protocole. Google, Yahoo! et Windows Live ne supportent que l’OpenID version 2. Ça a l’air idiot, mais les bibliothèques de connexion OpenID ne sont pas si nombreuses en PHP. Il en existe une très simple, qui fonctionne très bien, mais uniquement pour OpenID 1. Il en existe une autre, très complète mais lourdingue à mettre en place, qui est censée être pleinement compatible avec OpenID 2 (mais qui ne semble quand même pas fonctionner avec Google ni Yahoo!).
Pour Google, ce n’est pas un problème : Le Google Federated Login est très bien documenté, et j’ai trouvé une librairie qui s’y connecte directement, sans assurer de compatibilité OpenID, et ça fonctionne très bien.
J’hésite beaucoup pour Facebook. Vu le nombre de personnes ayant un compte Facebook, ça semble intéressant. Mais Facebook Connect est quand même assez galère à mettre en œuvre. Il faut créer une application, et les utilisateurs doivent accepter que cette application accède à leur compte. Et il faut mettre en place du cross-site scripting, pour que la partie Javascript de l’identification puisse accéder aux deux sites sans perdre de cookie. Bref, c’est casse-bonbon.
Mais il reste un espoir : Facebook s’est rallié au protocole OpenID. Pour l’instant, il n’est pas possible d’utiliser Facebook comme serveur OpenID, mais cela pourrait arriver à l’avenir.
Concernant Windows Live… Bah si ça fonctionne, c’est tant mieux. Si ça ne marche pas, je ne vais pas pleurer, je n’ai pas l’impression que ce soit un besoin si important que cela.
Pour résumer, la priorité est pour moi d’offrir l’identification par OpenID 1.0, Google, et si possible Twitter. Bref, ceux qui peuvent être mis en place facilement, et pour lesquels il existe des librairies faciles à utiliser. Si c’est pour déployer des usines à gaz et perdre du temps qui serait utile au développement des vraies fonctionnalités, autant laisser tomber.
Coûts et prix
Comme je l’ai déjà dis auparavant, je suis attaché au fait de ne pas faire payer l’accès au service. Je suis toujours éberlué de voir des outils faire payer pour des choses qui n’ont aucun coût réel, comme l’encryption SSL, le nombre d’utilisateurs autorisés, le nombre de projets gérés, le nombre de pages, …
Lancement du projet Skriv
J’en parlais récemment dans le post concernant l’avenir de ce blog : Je réfléchis à l’idée de développer un outil de gestion de projet ouvert à tous. Quasiment depuis que je travaille, j’ai développé des outils pour suivre les projets ou traiter les bugs. Comme j’ai souvent bossé dans des entreprises…
Faire des choix
Une idée assez connue, mais tellement importante : « Il faut faire des choix à la place de l’utilisateur. » J’en ai eu encore récemment un exemple, en travaillant sur la refonte d’une page d’un site Web. La page en question présente un certain nombre d’informations, dont des contenus écrits par les…
Des nouvelles du blog pour 2010
Ce blog a été ouvert il y a bientôt un an, c’est le moment de faire un petit bilan. J’avais créé ce blog parce que je pensais avoir des choses intéressantes à partager. Au début je voulais écrire un livre, mais un blog me semblait finalement une meilleure solution ; plus…
L’email n’est pas mort
Il y a quelques heures, j’ai écrit un commentaire en réponse à un billet du blog Entreprise 2.0. Ce billet, intitulé Peut-on envisager une entreprise sans email ? a pour thème l’abolition de l’usage de la messagerie électronique en entreprise. Son auteur estime que les nouveaux outils et les nouvelles pratiques permettent de se passer de l’email, et qu’il serait plus efficace de se concentrer sur l’emploi de plate-formes collaboratives, de messageries instantanées, de blogs d’entreprise, de micro-blogging, …
J’ai donc écrit un commentaire assez long pour donner mon avis sur la question. Je vais le reprendre ici en le développant un peu, parce que je pense qu’il s’agit d’un débat intéressant, qui est loin d’être clos.
Les outils de communication utilisés en entreprise
Avant de disserter sur l’évolution des communications intra- et inter-entreprises, passons déjà en revue les différents moyens de communication qui sont à notre disposition.
- Le téléphone. Parfait pour les échanges rapides d’information entre deux personnes, il remplace la discussion en face-à-face en éliminant les barrières géographiques. Les discussions orales ont le grand avantage d’être rapides, contrairement aux échanges écrits − qu’ils soient instantanés ou non.
- Le courrier postal et le fax. Encore très largement utilisés pour les échanges de documents écrits ayant une signification juridique, particulièrement lorsqu’il faut y apposer une signature. Je ne connais pas d’entreprise qui envoie ses contrats par email.
- Les emails. C’est un moyen simple et très généralisé d’envoyer des messages textuels à des individus ou des groupes d’individus. La réception de messages se fait de manière non intrusive (contrairement au téléphone), même si cela peut être modifié par divers alertes visuelles et/ou sonores.
- Les blogs d’entreprise. Ils permettent aux collègues d’une même structure d’échanger des idées utiles à l’avancement de leur travail ou de l’entreprise elle-même, dans un cadre où la réactivités des réponses aux idées n’est pas une nécessité forte. Ils permettent de suivre les différentes idées au fil du temps.
- Lespartages de fichier (au sens NFS ou Samba/CIFS). Ils servent à stocker et partager tous types de fichiers, avec deux buts différents mais pas antinomiques : 1) la pérennité des données, 2) l’édition par plusieurs personnes.
- Les wikis. Servent à stocker des données textuelles, avec les mêmes buts qu’un partage de fichiers (pérennité et accès multiple), en y ajoutant une facilité d’accès et des capacités d’édition collaborative accrues (historique des modifications, gestion des révisions).
- Les forums d’entreprise et les messageries instantanées (ou les outils similaires comme Campfire). Ils sont utiles pour une collaboration orientée temps réel. Surtout utile pour les équipes qui sont “éclatées” géographiquement, comme succédané aux discussions de travail habituelles au bureau.
- Le micro-blogging (popularisé par Facebook et Twitter). Sert à donner fréquemment des informations succinctes quant à l’avancement de ses projets.
- Les outils de liste (todo-list, buglist). Ils servent à gérer les tâches à traiter.
- Les lecteurs de flux RSS. Ils facilitent la veille technologique en permettant un accès centralisé rapide à un grand nombre de sources d’information.
On peut remarquer que j’ai aussi bien listé les moyens de communication stricto sensus (comparables au rôle de la voix dans une conversation entre deux personnes), que les moyens d’archivage des communications et des idées (comparable au rôle que les livres tiennent depuis qu’ils ont remplacé les traditions de mémoire orale).
Certains outils regroupent de manière centralisée certains de ces moyens de communication. La plupart des «logiciels de gestion de projet» intègrent au minimum un wiki et une liste de tâches, parfois en y ajoutant un forum et un partage de fichiers.
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 !».