Fine Media, l’entreprise que j’ai co-créé et dont je suis le directeur technique, est à la recherche d’un développeur web. Présentation de l’entreprise Nous sommes éditeurs de sites web. Notre activité principale porte sur les sites Ooreka, qui sont un ensemble de plus de 420 sites de niche, sur des sujets…
Recrutement : Développeur principal PHP 5
Le poste de développeur n’est plus à pourvoir. Merci à tous ceux qui m’ont envoyé un CV. Par contre, nous sommes à la recherche d’un administrateur système, n’hésitez pas à postuler. Un billet inhabituel aujourd’hui : Fine Media, l’entreprise que j’ai co-créé et dont je suis le directeur technique, est à…
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.
Test Driven Development
Je vous parlais récemment des tests unitaires. Je vous parlais entre autre de la difficulté d’imposer la discipline nécessaire à la réalisation de tests unitaires corrects et de leur maintien opérationnel.
Il existe une méthode de travail qui permet de forcer l’écriture des tests unitaires (tout au moins au début des développements). Il s’agit des développements guidés par les tests (ou Test Driven Development en anglais).
Cette méthode est toute simple à comprendre : Avant d’écrire un bout de code, on commence par écrire les tests qui vont vérifier la conformité du code.
Prenons l’exemple d’un code orienté objet. Imaginons que nous nous préparons à écrire une nouvelle classe.
- On modélise l’objet, donc on connait ses méthodes publiques. On sait quelles entrées doivent produire quels résultats.
- On écrit des tests pour vérifier les méthodes de l’objet.
- On écrit le squelette de l’objet, avec juste les déclarations des méthodes.
- On exécute les tests unitaires, qui tombent évidemment en échec.
- On écrit le code de l’objet, en vérifiant que les tests passent un à un.
L’avantage avec cette manière de faire, c’est qu’au moment où le code est écrit, on est quasi-certain qu’il est conforme au comportement qu’on attend de lui. Pour peu qu’on ait pris soin de lancer régulièrement les tests unitaires au cours du développement, le code est rapide à valider.
Par contre, il va sans dire que si le TDD permet d’avoir des tests unitaires corrects pour de nouveaux développements, le problème reste entier pour l’évolution de code existant. La vigilance habituelle reste donc de mise, pour que les tests ne prennent pas la poussière. Mais il est possible de respecter cette démarche pour toutes les évolutions de code : On commence par modifier les tests unitaires existants, ou les compléter ; puis on effectue les développements qui valideront ces tests.
Mon expérience
Le TDD est ce que je qualifierais de vraie fausse bonne idée. En fait, j’ai vu plusieurs fois le même cheminement intellectuel être suivi par des équipes qui mettaient en place cette méthode :
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.
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.
Échelle différente, problèmes similaires
Une des choses que j’ai apprises au fil des années et des expériences professionnelles, c’est que les problèmes rencontrés sont globalement les mêmes quel que soit le niveau où l’on se situe. Ce n’est qu’une question d’échelle.
Prenons l’exemple qui nous intéresse particulièrement : la gestion de projet.
- Un développeur éprouve souvent des difficultés à faire son travail dans de bonnes conditions. Ce qu’on lui demande de faire est très imprécis. Il a beau essayer de faire du mieux qu’il peut, ses supérieurs trouvent toujours quelque chose à lui reprocher (ce n’est pas fait assez vite, ce n’est pas fait assez bien, ce n’est pas fait dans le bon ordre…).
- Un chef de projet s’arrache régulièrement les cheveux. Il a plusieurs projets à gérer simultanément, chacun étant classé « haute priorité ». Les demandes des clients sont systématiquement incomplètes. Les développeurs ne sont pas disciplinés et font ce qu’ils veulent quand ils le veulent.
- Un directeur technique doit réussir à trier les différents projets, les affecter aux chefs de projets, suivre de près leur évolution. Il enrage souvent de ne pas avoir les remontées d’informations nécessaires pour anticiper les problèmes, de devoir pallier à la non-organisation de l’ensemble de ses collaborateurs et de passer plus de temps à « résoudre » et « corriger » qu’à « préparer » et « produire ».
Je ne vais pas expliquer maintenant comment il faut s’organiser pour gérer les projets (il y aura plusieurs autres billets sur ce blog à ce sujet). Mais ne voyez-vous pas qu’il y a des tendances qui sont les mêmes ?
Je vois 3 choses fondamentales :
- L’information entrante : Elle n’est jamais satisfaisante. Si ce sont des spécifications, fonctionnelles ou techniques, elles sont incomplètes. Si c’est une liste de tâches à réaliser ou un ordre de mission, il n’est pas suffisamment clair. La question reste « Qu’est-ce que je dois faire ??? » (et par ricochet quand on doit gérer une équipe : « Qu’est-ce que je dois déléguer ? »).
- L’organisation : Principalement, cela consiste à savoir qui fait quoi, et dans quel ordre. Et parce qu’elle est – à tort – considérée comme uniquement personnelle, l’organisation est souvent laissée à l’écart des processus globaux de gestion des projets. C’est une erreur, car c’est là que se joue la productivité des collaborateurs d’une entreprise.
- L’information sortante : Il n’y a jamais de situation réellement insoluble en entreprise. Mais c’est par la qualité de nos remontées d’information que les problèmes pourront être anticipés, que les projets vivront correctement dans la durée, que nous devenons acteurs au lieu de spectateurs.
Ces trois points restent immuables, quels que soient votre poste et vos responsabilités.