Communication et productivité : synonymes ou antonymes ?

AmauryOrganisation d'équipe2 commentaires sur Communication et productivité : synonymes ou antonymes ?

Je suis assez étonné et amusé de remarquer qu’il existe des « courants de pensée » assez contradictoires concernant les méthodes à employer pour maximiser sa productivité personnelle. Certaines solutions proposées sont un peu extrêmes dans leur propos et revendiquent leur manque de nuance. Qu’elles soient le résultat d’une démarche personnelle et la dernière méthode à la mode, il semblerait que leur adoption doit être obligatoirement sans demi-mesure…

La sur-communication

Je vais commencer par vous parler de ce qu’on appelle l’«Entreprise 2.0». Derrière ce terme un peu brumeux (et repompé du «Web 2.0») se cache un ensemble de pratiques qui ont pour but d’amener les plate-formes de travail en entreprise vers des pratiques plus participatives, plus “organiques” − quoi que cela veuille dire.

Si on regarde bien, cette démarche a été entamée il y a un bon nombre d’années déjà, lorsque les entreprises ont commencé à migrer leurs gestions documentaires simplistes (partage de documents en réseau) ou difficiles d’accès (GED de premières générations) par des intranets intégrant wikis, blogs et bookmarks partagés. Et il faut bien avouer qu’en procédant ainsi, l’accès à l’information est devenu plus facile et leur mise à jour est plus fréquente.
Rapprocher l’information de ceux qui en ont besoin, tout en leur permettant de la modifier facilement, permet de rendre celle-ci moins « monolithique ».

C’est un bon exemple de cas où ce sont les outils qui ont amené un changement d’utilisation en douceur, ce qui n’aurait pu être fait par un changement d’organisation et de process.

Certains partisans de l’«Entreprise 2.0» veulent pousser ce concept beaucoup plus loin. Pour faire simple, Facebook et Twitter sont des outils super géniaux (et surtout particulièrement à la mode en ce moment), il faut à tout prix généraliser et codifier leur utilisation. Ils théorisent donc sur le fait que la prochaine étape est d’avoir des collaborateurs qui communiquent de manière proactive, informent leurs collègues de ce qu’ils font et à quoi ils réfléchissent, en utilisant des canaux de micro-information propres à l’entreprise.

La sous-communication

A contrario, un bon nombre de méthodes d’organisation personnelle obligent à fermer les vannes de l’information entrantes. Qu’il s’agisse du téléphone (toujours laisser le répondeur gérer les appels), des emails (à ne lire qu’une à deux fois par jour) ou des réunions (à éviter comme la peste), l’idée est la même : Ce sont des sources de distraction qui empêchent de se concentrer sur les tâches qui réclament notre attention. Éliminer les sources de distraction permet donc, par un effet mécanique, de consacrer plus de temps à faire du travail « utile », et donc de devenir plus productif.

Présentation de FineFS au Forum PHP Paris 2009

AmauryÉvénementsUn commentaire sur Présentation de FineFS au Forum PHP Paris 2009

Je serai présent les jeudi 12 et vendredi 13 novembre prochains au Forum PHP, qui est une importante manifestation organisée par l’AFUP (Association Française des Utilisateurs de PHP). J’y présenterai FineFS, le système de fichiers redondé sous licence libre que je développe au sein de mon entreprise, et dont j’ai…

Lire la suite

Pensées sur le vif : les enseignements du milieu hospitalier

AmaurySans catégorie4 commentaires sur Pensées sur le vif : les enseignements du milieu hospitalier

Vous avez remarqué que je n’ai pas posté de nouveaux billets sur ce blog depuis quelque temps. L’explication simple : ma femme a accouché il y a 2 semaines d’une petite fille prématurée (elle s’appelle Ania et c’est le plus beau bébé du monde), ce qui chamboule beaucoup de choses. L’explication longue : j’ai plusieurs billets en cours d’écriture, mais avec cette naissance je n’ai pas trouvé le temps de continuer leur rédaction.

Le monde hospitalier

Il n’empêche que la situation m’a fait remarquer certaines choses. La première, c’est que le personnel hospitalier est vraiment en sous-effectif. Quand une sage-femme vous explique qu’elle aurait dû terminer son service à 15h00, et que son mari ne va pas être content parce qu’elle reste jusqu’à 21h00 pour la troisième fois de la semaine, on relativise beaucoup ce que les informaticiens subissent en période de rush (je rappelle au passage que la plupart des informaticiens ont le statut de cadre et trouvent ça normal ; pensez-vous que les sage-femmes aient ce statut ?).

Ensuite, la rétention d’information est une vieille habitude qui est toujours bien vivace. Mais le plus étonnant, c’est que tout le monde ne la pratique pas. Pour être clair, tant que ma femme était hospitalisée et qu’elle subissait des examens, il était impossible d’avoir la moindre information. Qu’est-ce qui cloche exactement ? Pourquoi une nouvelle prise de sang, qu’est-ce qui a été trouvé dans la précédente ? Quels sont les risques ?
Chaque nouveau médecin n’apportait aucune information, à part le fait qu’il faille faire de nouveaux examens. Le top du top, c’est le soir où un médecin est venu, a pris une feuille de résultats, nous a dit « Je vais chercher les autres résultats et je reviens » ; 45 minutes après, une infirmière nous a rapporté la feuille de résultats, en nous disant que le médecin était parti.

Choisir un nom d’entreprise, de produit, de projet

AmauryCréation d'entreprise3 commentaires sur Choisir un nom d’entreprise, de produit, de projet

Choisir un nom est souvent une étape bizarre. On a envie de trouver le bon nom, celui qui reflétera au mieux l’énergie et l’ambition qu’on place dans notre nouveau « bébé », qui sera le plus attractif, qui sonne le mieux à l’oreille…

Oui mais voilà, des fois on a beau se creuser la tête, il n’y a rien qui nous vient à l’esprit naturellement. Et pendant qu’on passe du temps à chercher, on risque de bloquer l’avancée du projet ; comme le nom apparaît partout, il est difficile de démarrer sans. Alors parfois on finit par prendre un nom à la va-vite, le moins mauvais qu’on avait trouvé, au risque de se le trainer pendant un bon bout de temps.

Dans le titre de ce billet, j’ai listé trois types de noms : celui qu’on veut donner à une entreprise, à un produit ou à un projet. Il y a de subtiles nuances entre chaque.

Entreprises

Un nom d’entreprise doit être à la fois parlant et facile à retenir, tout en étant assez générique pour ne pas limiter le champ d’activité. Idéalement, il faut prévoir un nom qui sonne agréablement dans toutes les langues, ou tout au moins les marchés qu’on souhaite attaquer (et l’anglais désormais incontournable).

Prenons l’exemple de Motobecane, dont le nom est quand même très connoté « 2 roues » et « franchouillard » ; ils ont fini par changer pour un nom plus neutre (MBK). Par contre, Peugeot produit aussi bien des voitures que des scooters, des vélos et des perceuses.

Une marque pourra être connue et reconnue comme telle, mais cela pourra prendre du temps. Si elle réussit à se faire connaître, son nom facilement identifiable lui permettra de se démarquer des autres. Consécration suprême − et dangereuse ! − il pourrait être utilisé comme nom commun (comme Frigidaire ou Kleenex).

Produits

Un nom de produit peut avoir de multiples facettes.

Et si Gordon Ramsay était informaticien ?

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

Simple GTD

AmauryOrganisation personnelle7 commentaires sur Simple GTD

Je vous ai déjà fait une introduction à la méthode GTD (Getting Things Done) de David Allen. C’est une méthode d’organisation personnelle très efficace, mais qui réclame une discipline et une rigueur constantes, qui peuvent être usantes à la longue.

Je suis tombé il y a quelques temps sur un article très intéressant du site WebWorkerDaily, qui présente une alternative simplifiée. Cette alternative ne concerne que la partie de « tri » des tâches. Il semblerait qu’elle soit extraite du livre Les 7 habitudes de ceux qui réalisent tout ce qu’ils entreprennent de Stephen R. Covey.

Le tri de tâches GTD

Souvenez-vous, voici les étapes imposées par le GTD, pour trier les informations entrantes (et j’ai déjà pas mal simplifié les choses) : Getting Things Done - déroulement

Le tri de tâches simplifié

Maintenant, l’alternative évoquée sur WebWorkerDaily propose de trier les tâches suivant 4 possibilités simples :

  • UI : Urgent – Important
  • NUI : Non Urgent – Important
  • UNI : Urgent – Non Important
  • NUNI : Non Urgent – Non Important

La R&D : pour ne pas confondre développement et veille techno

AmauryOrganisation d'équipeLaissez un commentaire sur La R&D : pour ne pas confondre développement et veille techno

Il y a quelques temps, je vous ai parlé de la veille technologique. Je vous ai expliqué en quoi c’est un élément important de nos vies professionnelles.

Je voudrais cette fois-ci vous mettre en garde contre une dérive finalement assez commune chez les jeunes développeurs, qui est d’utiliser les projets professionnels comme un terrain de jeu pour réaliser leurs expérimentations. Ensuite nous réfléchirons aux moyens de canaliser la fougue qui conduit à ces dérapages.

Les expérimentations au boulot

Il y a quelques années, alors que j’étais chef de projet, un de mes développeurs – un prestataire externe, en fait – avait demandé une demi-journée de congé pour assister à une conférence organisée par Google France. J’étais content de voir qu’il prenait à coeur sa veille technologique.
À son retour, je lui ai évidemment demandé de me faire une présentation rapide de ce qu’il avait vu. Il s’agissait des premières versions des toolkits de Google, et ça avait l’air vraiment intéressant.

Nous étions alors en train de démarrer un nouveau projet, et ce développeur était en charge de certaines spécifications techniques. Quand j’ai vu dans ses specs qu’il envisageait d’utiliser les technologies Google qu’il venait d’entrapercevoir, j’ai eu une petite discussion avec lui.

Le message tient en 2 points :

  • Bien qu’absolument nécessaire, la veille technologie est une démarche personnelle. C’est à chacun de se trouver ses propres petits projets qui lui permettront de tester de nouvelles technos ou de nouveaux outils.
  • Un projet mené au sein de l’entreprise répond à des contraintes contractuelles et financières. Vouloir y glisser des technologies qui ne sont encore qu’à l’état de bêta, ou qu’on ne maîtrise absolument pas, est une erreur assez grave.

Canaliser et organiser

Il n’empêche qu’il n’est pas logique d’inciter à la veille tout en la réprimant dans le cadre de l’entreprise. L’entreprise a certains devoirs de formation vis-à-vis de ses employés, il faut s’en occuper de manière raisonnée et planifiée.

La refactorisation

AmauryOrganisation d'équipe6 commentaires sur La refactorisation

La refactorisation est un exercice qui devrait être maîtrisé par tous les développeurs, encadré par tous les chefs de projets et encouragé par tous les directeurs techniques.

Le refactoring, qu’est-ce que c’est ?

Derrière cet affreux anglicisme se cache le fait de réécrire du code qui a déjà été développé. Le but n’est donc pas d’ajouter de nouvelles fonctionnalités, mais plutôt d’assurer un suivi de l’existant, de faire un ménage qui en facilitera la maintenance.

Nous nous sommes tous retrouvés un jour ou l’autre devant des bouts de code sans queue ni tête, manifestement écrits à la va-vite, ne respectant aucune norme, avec une documentation périmée, sans commentaire, ou truffés de code mort. À chaque fois, nous sommes horrifiés. Dans le meilleur des cas, on se souvient des raisons historiques qui ont conduit à cela (« Ah oui, ça date du projet X, qu’on avait dû faire à toute vitesse il y a 2 ans ») ; dans le pire des cas, on va retrouver le responsable de cette horreur pour lui passer un savon.

Mais la bonne attitude, c’est d’organiser l’amélioration de ce code. Il faut garder en tête qu’on ne travaille pas continuellement sur les mêmes fichiers. Ce qu’on est en train de développer un jour sera utilisé pendant des mois voire des années sans qu’on revienne dessus. Mais au fil du temps, le code ancien devient « friable » : chaque correction de bug devient plus délicate et sujette aux bugs de régression ; chaque ajout de fonctionnalité prend de plus en plus de temps et devient plus difficile.

Je vais faire un parallèle avec la construction immobilière. Quand on construit une maison, on commence par faire les fondations, puis on monte les murs extérieurs, puis le toit et enfin les cloisons intérieures. Quand on développe un logiciel, c’est un peu la même chose ; chaque développement, chaque ajout de fonctionnalité, s’appuie sur des objets ou des librairies qui doivent rester fiables dans le temps. Il faut donc pouvoir revenir à tout moment sur n’importe quel bout de code, accéder à sa documentation, lui ajouter de nouvelles capacités, voire résoudre des bugs qui ne s’étaient encore jamais déclarés.
Parce que le jour où vous faites tomber des cloisons, vous ne devez pas devoir refaire les murs extérieurs ; et si vous ajoutez une étage à votre maison, vous devez pouvoir faire confiance à la chape de béton de vos fondations.

Comment s’y prendre

On peut découper un refactoring en 4 étapes précises. Les trois premières sont importantes et nécessaires, alors que la dernière est à mettre en oeuvre si le besoin s’en fait sentir uniquement.