Getting Real December 30, 2006
Posted by julien in : J'ai vu / J'ai lu , trackback
Voilà quelques jours que je me suis plongé dans la lecture de Getting Real, le livre de 37signals que j’ai acheté sur Lulu.com (voir ce billet).
Cette société est notamment à l’origine de BaseCamp, un PMS, un outil de gestion de projet collaborative qui a beaucoup fait parler de lui ces derniers temps.
Getting Real présente le cheminement que la société a suivi pour la création de cet outil. En ressort une théorie sur la gestion de projets (au sens large : définition du cahier des charges, développement, recrutements, organisation du travail, …), dont les éléments pris individuellement ne sont en eux-même pas novateurs, mais dont l’ensemble forme un ensemble cohérent qui permet aux auteurs de sous-titrer le livre : The smarter, fastier, easier way to build a successfull web application
.
La théorie est principalement basée sur le LIME, ce qui pourrait se traduire par la proverbe français Le mieux est l’ennemi du bien
, appliquée aux projets de développement Web.
Voilà quelques préceptes glânés au fil de la lecture :
- Dans un projet, mieux vaut fixer les délais et le budget, et s’autoriser une marge au niveau du périmètre. Si l’on court vers le hors-délais ou que le budget risque d’exploser, on est alors amené à réduire le périmètre initialement prévu.
- L’équipe idéale pour démarrer un projet de manière efficace : un développeur, un designer, et un gars qui s’y connait dans les deux domaines (ce qu’ils appellent un sweeper, et qui d’aprés mon expérience de management de designers et de développeurs pourrait aussi s’appeler un Dahu !)
- Ne pas avoir peur de s’imposer des contraintes, et s’en faire alors des alliées pour développer la créativité, pour échapper à ce qu’ils appellent le not enough blues
- Chaque projet doit avoir une tagline, qui le résume en une phrase (la plus courte possible)
- Ignorer les détails dans les premières étapes du projet. Aller du général vers le particulier.
- Faire fonctionnellement simple, minimalistes, en se concentrant sur les items vraiment indispensables. Pour les items accessoires, laisser le client aller vers la concurrence.
Des principes en terme de positionnement et de relation-client :
- Small is beautiful : la petite taille d’une structure est son principal atout : réactivité, souplesse, chaine de décision trés courte. Inutile de vouloir faire passer sa société pour une SSII multinationale.
- Si vous voulez faire plaisir à tout le monde, vous ne ferez plaisir à personne. Définir un utilisateur principal
- Toujours dire non. Dire non à priori à toute demande du client. Une modification d’une fonctionnalité, aussi simple soit-elle, a un coût invisible : procédures de tests, déploiement, … Remarque : cette proposition n’est bien entendu envisageable que dans un cas comme celui de Basecamp, où le client paye quelques dollars pour un service qu’il a pu tester auparavant… Je ne me vois pas avoir une telle attitude avec un client sur un contrat à plusieurs dizaines de ke !
Des principes en terme de process technique :
- Ne se poser les problèmes que lorsqu’ils se présentent. Par exemple, inutile de prévoir d’emblée une ferme de serveurs si un seul suffit dans un premier temps.
- Avoir quelque chose qui marche, et vite, afin d’enclencher une dynamique de développement
- Ne pas proposer de préférences utilisateurs, comme personnaliser le nombre de lignes d’une page de résultats. Elles nécessitent des développements conséquents pour une utilisation par un minimum de clients.
- Faire des tests avec de vrais personnes, et de vraies données. Donner accés à la beta version seulement à un panel d’utilisateurs.
Des principes en terme d’organisation du travail :
- Fuir les réunions comme la peste, y préférer les systèmes de communication modernes : IM, chat, …
Interruption is your enemy
, spécialement vrai dans le monde du développement informatique, où la perte de concentration peut entrainer plusieurs minutes pour se remettre dans le sujet. N’autoriser le dérangement des développeurs (avec des requêtes, etc…) seulement pendant une heure par jour, en début de journée.- Releaser souvent pour célébrer les “petites victoires”. Dans le cas d’une mission de longue haleine, l’interrompre parfois de petits travaux rapides pour avoir l’impression que globalement le travail avance.
Des principes en terme de recrutement :
- L’Open Source est votre première religion. Misez à fond sur les développeurs provenant de ce milieu
- Préferer de bons généralistes qui apprennent vite, à de trés bon spécialistes dans des compétences pointues
- A compétences égales, prendre celui qui est le meilleur rédacteurs (style, orthographe, concision) car c’est celui qui commentera son code comme il le faut, rédigera des emails compréhensibles, en bref sera le plus à même de communiquer et donc d’être efficace dans le travail d’équipe
Que retenir de tout cela ?
Tout d’abord, comme précisé plus haut, les propositions faites par 37signals sont envisageables pour une société qui développe un produit et le met en ligne à destination du grand public, ou tout du moins d’un public large.
Certaines options, comme le Always say no
sont assez provocatrices et non applicables dans le cadre d’un contrat de réalisation d’application classique comme peut réaliser Phoceis.
Toutefois, certaines idées méritent d’être creusées, et je pense que je vais m’en servir dans les mois qui viennent dans certains des projets dont je vais être en charge. En effet, si certaines ne s’adaptent pas au métier de SSII, certaines idées sont intéressantes à mettre en oeuvre dans le cas d’une petite société, pour apporter une réactivité encore accrue (mais est-ce possible ?) et une gestion de projet plus adaptée à la taille de l’entreprise.
Comments»
no comments yet - be the first?