- De déterminations extérieures :
1.1. L’environnement doit faciliter l’activité
1.2. L’environnement ne doit pas gêner l’activité - De déterminations propres :
2.1. Il faut avoir envie de bosser
2.2. Il faut que ce soit le bon moment
2.3. Il faut savoir ce qu’il y a à faire
2.4. Il faut être « motivé » par le feedback qu’on reçoit
1.1. Un environnement qui facilite l’activité
Par environnement, entendons au sens large tout ce qui m’entoure, avec qui je bosse, avec quels outils, et où je suis installé.
Le meilleur type d’endroit dans lequel j’ai pu faire du développement a été :
- un bureau dédié qui ne soit pas partagé avec des collègues,
- disposant d’une grande fenêtre — en fait une baie vitrée sur deux niveaux donnant sur l’Océan Atlantique,
- travaillant avec une équipe de « smart guys », jeunes ou moins jeunes,
- dans des locaux donnant accès à une bibliothèque interne, à une salle de repos, à des lieux informels de relaxation et de discussion (poufs bienvenus),
- donnant accès à un tableau partagé où chacun peut noter ses idées,
- avec une connexion internet haut débit (si, si, il faut le préciser),
- et un réseau local performant (ou une solution « on the cloud ») pour le partage occasionnel de fichiers — la grande majorité des échanges se faisant par le SCM.
- un fauteuil de qualité (Markus, anyone?),
- une immense table (enfin, à l’époque elle me paraissait immense…),
- deux machines puissantes avec écran et clavier, dont une avec un ecran plat 20’’,
- pour le choix des systèmes d’exploitation, dans l’ordre : MacOS X, Windows 2000, Windows XP, Ubuntu,
- et un téléphone fixe avec haut-parleur, avec accès au national et à l’international.
Divers outils en coulisses qu’on ne présente plus :
- un SCM propre, comme Subversion,
- un wiki propre, comme Confluence,
- une plate-forme de blogging interne (en général, la même plate-forme offre le wiki et le blogging ; c’est le cas de Confluence),
- un bug tracker propre, comme Jira,
- une solution interne de messagerie instantanée, comme Jabber,
- et une plate-forme d’intégration continue propre, comme Continuum.
- Java 5 ou ultérieur,
- Maven 2
- un IDE, comme Eclipse 3.3.2
- une panoplie de navigateurs web, dont Firefox 2.0.0, Mozilla et Opera
- un éditeur de textes, comme TextWrangler, Crimson Editor ou UltraEdit
- YAML, XML, XSLT
Les contre-exemples bien connus sont :
- les framework maisons monolithiques auxquels le legacy est fortement couplé
- les outils maisons difficiles d’utilisation : mal documentés, qui gèrent mal les erreurs, pas ergonomiques, etc.
Attention, ce genre d’initiative freine la productivité non seulement en terme d’outillage pur, mais également en minant la motivation des équipes, car l’image de la boîte renvoyée en interne n’est pas bonne.
Je cite mes outils maison préférés jusqu’ici :
- plugins Maven de génération de code
- outil de rendu dynamique de JSP/JSF sans déploiement (et ne me parlez pas de Tomcat dans Eclipse, ou de JBoss qui redéploie en autonome)
- plugins Maven de tests de design web
1.2. Un environnement qui ne gêne pas l’activité
Il faut laisser la place aux bons points qu’on a vus précédemment d’être utiles.
Ainsi, on évitera, et je parle là de seuils d’acceptabilité :
- le bureau où on est 5 dans lequel parle à voix haute (je rappelle que je parle de développement. De tels bureaux peuvent être utiles pour d’autres choses),
- les open spaces,
- le bureau sans lumière extérieure,
- l’équipe de neuneus (oui, je sais, on est toujours le neuneu de quelqu’un),
- la société qui n’affiche pas un intérêt évident à investir dans des livres, dans des serveurs ou dans des formations,
- l’absence ou la restriction d’accès à internet,
- le poste de travail sous-dimensionné,
- la société où l’on ne peut pas capitaliser la connaissance dans une base ouverte, partagée, pratique d’utilisation et indexée,
- la société où l’on ne communique pas librement (oui, je sais, c’est le Moyen Âge, mais ça existe encore),
- les projets techniques sans phase d’investissement dans l’outillage technique : il faut savoir gérer les effets de seuil.
- les projets Java en-deçà de Java 5
- Bloquer les e-mails entre 8 h 00 et 14 h 00
- Trier ses flux RSS
- Bloquer Skype et Twitter (très difficile) sur certaines plages temporelles
Et la décoration du bureau ? Et la musique ? Et le Feng Shui ? À creuser également…
2.1. Avoir envie de bosser
Bah, ce n’est pas compliqué : il faut et il suffit d’être convaincu du résultat.
2.2. Le bon moment
Entre quatre heures et huit heures du matin, je suis en général trois fois plus rapide et efficace qu’après neuf heures du soir…
À huit heures, c’est le journal…
À midi, la faim se fait sentir, donc je réfléchis mieux…
Après le repas, sans sieste je passe trois heures à ne pas démarrer…
À 18 h 00, ça stagne… Pour baisser en général vers 19 h 00…
À environnement idéal (en dormant au boulot, donc !), je pourrais donner la courbe de productivité suivante :
Noter que je passe sur les problématiques de fatigue installée, de stress, etc. Tout ce qui constitue la moitié basse de la Pyramide de Maslow doit évidemment être réglé.
Cela étant dit, dans une journée la productivité n’est pas constante. Il faut connaître et utiliser les bons moments.
- Il est inefficace de travailler quand le moment « n’y est pas »
- Il est inefficace de ne pas travailler quand c’est le moment
2.3. Savoir ce qu’il y a à faire
La concentration (notions de focus et de flow) est indissociable de la productivité.
À ce titre, il est crucial que la TODO-List, la liste des tâches à faire (par extension, l’ensemble des backlogs de Scrum par exemple) soit claire et affichée. Utiliser un outil informatique ou un cahier ne suffit pas. Pour les tâches du quotidien, un affichage mural est bien plus efficace.
2.4. Être « motivé » par le feedback qu’on reçoit
C’est un point important dans l’efficacité.
D’abord, comment savoir qu’on maintient le cap ? Qu’on a le sens des priorités ? On peut en effet être très concentré, très « productif » sur des menus détails, et laisser tomber des pans de l’activité. Pour cela, la TODO-List, ou les fameux backlogs de la méthode Scrum sont utiles.
En parlant de Scrum, les dailys scrums, lors desquelles toute l’équipe se réunit debout une demi-heure pour présenter les choses faites, le reste à faire et les problèmes rencontrés, représentent un gain redoutable tant pour la productivité individuelle que collective (notion de gel). La productivité en équipe n’est cependant pas le sujet de cet article.
Ensuite, il faut savoir juger ce qu’on produit. C’est aussi une façon de maintenir le cap. Et c’est encore une question de priorités : savoir identifier ce qui est important dans le produit réalisé, afin de se concentrer dessus.
Il s’agit d’un ensemble d’indicateurs, dont aucun n’est à négliger. Ils devraient même à mon sens avoir le même coefficient, avec seuils planchers éliminatoires :
- Les feedbacks des utilisateurs (organiser des démonstrations)
- Les feedbacks des « pairs » (peer reviews) (idem, et rédiger des bilans)
- La qualité interne du produit (audits automatisés réguliers)
Enfin, il y a un feedback capital dans la productivité, c’est celui qu’on apporte soi-même. Passer du temps à bloguer en interne ce qu’on a fait dans la journée, à formaliser telle procédure, tel outil, telles spécifications même incomplètes… Bloguer ses pratiques, bloguer ses configurations, alimenter les bug trackers et les backlogs… On en retire :
- une capitalisation du savoir (non ? Sans blague ?),
- une pratique de la formalisation
- une réflexion en tâche de fond, et une habitude de communiquer,
- un recueil incrémental des problèmes et des solutions
En terme de productivité de développement, c’est utile car on y gagne en recul, donc d’acuité, donc de pertinence… donc de productivité.
On a vu l’importance de la concentration (focus) : il faut donc éviter le trop-plein de feedbacks qui mènent à la distraction voire à la dispersion. C’est tout l’objet de ce point : à mon avis le feedback doit être motivant, bien qu’il soit parfois laudateur ou critique. Motivant, c’est-à-dire qu’on ne doit pas le chercher pour lui-même mais pour l’effet qu’il aura sur l’activité.
C’est aussi pour cela que je parle de « détermination propre » au lieu de « détermination extérieure » pour le feedback : ce qui compte pour la productivité c’est ce que j’en fais moi.
Bonus : 3. Ce qui n’apporte rien
Grande question : que fait-on des outils suivants ? Sont-ils des facilitations de productivité pour le développement ?
- Blogs publics (via des flux RSS)
- Comptes publics de messagerie instantanée (Skype…)
- Facebook (que je ne connais pas assez)
- E-mail
Seulement, en terme de pure productivité, l’élément important est l’acuité. Ainsi, se concentrer quatre heures sur un bouquin ou une doc en ayant éteint tous ces outils, sera plus profitable à un moment donné que fureter sur le même sujet sur internet. Il ne faut pas gérer sa productivité uniformément, mais selon les caps à franchir.
Conclusion
La productivité s’appuie sur un environnement, des outils et des pratiques, et est liée par feedback à la motivation (feedback dans les deux sens). Elle peut être favorisée ou handicapée par la nature de ces différents éléments. Les éléments en gras ci-dessus constituent une check-list empirique d’éléments à prendre en considération.
La productivité se jauge continuellement. Outre la quantité de travail abattue, un signe de bonne productivité et d’efficacité est l’agilité.
Encore une fois, tout cela vaut comme mon avis personnel. Si vous avez des réflexions ou des pointeurs sur le même sujet, je serai heureux d’en discuter.
Aucun commentaire:
Enregistrer un commentaire