Conception web 2.0

Je viens d’achever la lecture du dernier livre de 37signals : Getting Real (voir à ce sujet mon précédent billet : Le livre ultime du développeur pragmatique).

Mes premières impressions : Wow ! Ils n’y vont pas par 4 chemins et leur approche de la conception d’applications en ligne est… révolutionnaire.

En substance, voici leur méthode de travail :

  • pas plus de 3 personnes par équipe (1 concepteur / designeur, 1 développeur, 1 qui encadre les 2 précédents) ;
  • ne pas utiliser de spécifications ou cahier des charges (pas assez flexible et apporte plus de contraintes qu’autre chose) ;
  • réduire le périmètre fonctionnel à strict minimum (généralement 1 fonctionnalité) ;
  • ne plus faire de réunions (c’est sûr qu’à 3 personnes dans le même bureau, ça rime plus à grand chose) ;
  • ne plus utiliser de storyboard ou wireframe mais passer directement au prototype…

Plus surprenant encore, leur approche préconise même une organisation contre-nature :

  • conserver à tout prix la date de lancement annoncée, quitte à réduire le périmètre fonctionnel ;
  • ne pas prendre en compte les demandes d’évolution (du moins dans un premier temps) pour ne pas dévier de l’idée initiale ;
  • se concentrer sur une niche d’utilisateurs potentiels…

Même si mes premières réactions étaient plus que mitigées, j’avoue être fortement séduit par ce type d’organisation pour un projet : flexibilité, pragmatisme, rigueur… Quand on voit la qualité de leurs réalisations, on est en droit de se dire que leur approche n’est pas non plus surréaliste.

La question que vous vous posez tous maintenant est la suivante : est-ce valable pour mon projet ? Ce à quoi je n’ai malheureusement pas de réponse. Si vous souhaitez monter une start-up reposant sur un service en ligne novateur alors pas de doute : c’est cette méthode qu’il vous faut. Par contre, si vous évoluez dans un environnement professionnel plus structuré (en gros 99,99% des cas), si vous subissez une forte contrainte de la part des utilisateurs ou des commanditaires (en gros ceux qui financent le projet) ou si vous devez gérer une équipe disparate (plusieurs personnes de sociétés différentes)… ça devient tout de suite plus délicat.

N’étant pas un spécialiste des méthodes agiles, je laisserais les lecteurs concernés s’exprimer (de préférence APRÈS avoir lu le livre).

Je vous recommande également le billet suivant qui parle de ce livre : Getting Real, notes de lecture. Afin, si vous souhaitez approfondir le sujet, je vous conseille de lire le billet suivant sur le prototypage rapide : Ruby on Rails as rapid prototyping tool.

Un commentaire sur “Conception web 2.0

  1. Bon allez, juste histoire d’enfoncer des portes ouvertes, je vous livre un dicton du livre : Mieux vaut une application sans spécifications qui fonctionne plutôt qu’une application très bien documentée qui ne fonctionne pas. Ha ha ha ha ! Qu’est-ce que vous trouvez à redire ? /Fred

  2. « Mieux vaut une application sans spécifications qui fonctionne plutôt qu’une application très bien documentée qui ne fonctionne pas. » Je trouve à redire que d’autres personnes, et non des moindres ont déjà dit la même chose : « we have come to value … Working software over comprehensive documentation » :-)

  3. mais comme une application évolue, ca peut devenir : « L’application sans spécifications a du mal à évoluer alors que l’application bien documenté fonctionne de mieux en mieux » on peut aussi documenter et faire les tests unitaires après que ca marche aussi. Bon, je n’ai pas lu le livre, mais ca doit quand même être difficile d’avoir plusieurs projets à la fois

  4. Je dirige une startup marocaine spécialisée dans les web services, la méthode susmentionnée est plus qu’adéquate dans la mesure où elle permet non seulement de gérer d’une manière pragmatique les projets web mais aussi de réduire considérablement la charge de travail colossal représentée par les cahiers de charge, les story-boards et autres road map. Notre expérience nous a appris combien se resigner à des spécifications techniques et fonctionnelles carrées pourraît se réveler fatal à certains types de projets web. La méthode décrite est la méthode qu’on adopte depuis quelques mois et elle nous a permis de mieux gérer notre portfeuille clients et consacrer beaucoup plus de temps au travail de l’innovation et de la veille technique. C’est, d’ailleurs, notre cheval de bataille pour le projet que nous menons actuellement: http://www.mysteriousproject.com Othmane Boumaalif Directeur developpement SM Web Agency

  5. L’element principal de cette methode, qui je crois ne fait pas parti des methodes agiles, c’est de developper l’interface HTML d’abord, et de faire le code ensuite. (37 signal insiste sur le fait qu’il ne s’agit pas de faire des maquettes, mais bien de faire quelque-chose de fonctionnel). Pour avoir gere des projets web de grande taille (plusieurs mois de dev), je me suis toujours éforcé de passer énormement de temps sur les specifications fonctionelles en demandant expressement de faire abstraction des maquettes… Mais je souscrit a present a l’idee qu’une application web, c’est avant tout une interface et qu’il faut quelque-chose de fonctionnel le plus rapidement possible, quite a ce que derriere, ce soit une coquille vide (utilisation d’interfaces et de mock-objects). Le plus dur etant de justifier ensuite qu’il vous faut 4 mois pour developper l’applicatif reel, alors que ce que le client a sous les yeux ‘fonctionne’… Tout un travail de pedagogie avant, pendant et apres la demonstration de la maquette !

  6. Il est vrai que pour ce genre d’appli web, ce schema est ideal. j’en parle en connaissance de cause. Je crée en ce moment un service web, notre equipe est formée de 3 associés : un dev / un designer / et un designer chef de projet. Un est en france, les deux autres au canada … pas de réunions, pas de wireframe. On a placé une maquette xhtml / css basique qu’on implémente avec le code dynamique au fur et mesure … cela rejoint sur pas mal de points le livre de 37signals ! C’est une méthode de travail assez plaisante, chacun sais ce qu’il a a faire, et les contraintes sont minimes.

  7. Ce genre de livre d’applique à des gens qui connaissent réellement le web. J’ai moi aussi deja travaillé sur ce genre de fonctionnement : une imprimerie en chine, un contenu editorial en inde et une supervision aux us. Apres quelques jours de calages question décalages horaires, on a pu sortir des magasines sans trop de problemes. tout ca avec : langue globbish Skype Ftp Framework minimal Wifi et hop, vous voula projetés dans l’entreprise du futur ! Seulement voila, en france, effectivement, il ya des aberrations : dans les grandes stuctures, skype est bloqué, le ftp parfois passant par des proxies, et le wifi est tres deconseillé, les ordinateurs portables bridés. Quant est ce que les grosses societes cesseront d’utiliser leurs usines a gaz, leur backoffice monstrueux, ou leur site de pilotage surdimensionnés, on en arrivera a travailler mieux et plus vite..

  8. La conception Web 2.0, agile ou non ? Fred Cavazza nous a écrit il y a deux jours un bonne fiche de lecture sur un bouquin traitant de conception web 2.0. Et, d’après ce que j’en lis, beaucoup des points évoqués proviennent nettement des méthodes XP. J’aimerais quand…

  9. Web 2.0 : une approche centrée sur la technologie ? Une chose me frappe avec le phénomène Web 2.0. On parle beaucoup de technologies comme XML, RSS, ou Ajax, ce dernier étant pour moi avant tout un club de foot ;-) Blague à part, je me pose la question suivante. Est-ce que ce sont ces techn

Laisser un commentaire