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. Je confirme la même impression : puissant ! J’en suis personnellement à la 60è page et n’attends qu’une chose : avoir le temps de le finir. Cet ouvrage donne plein de bons principes pour lancer et gérer un projet. Reste à être dans la même configuration que cette agence pour les appliquer ! Pour l’instant, je ne rajouterai qu’un point : s’entourer de personnes aux nombreux talents. « Le livre ultime du développeur pragmatique »… je dirais plutôt « Le livre ultime de l’entrepreneur / directeur de projet / chef de projet/ ergonome / éditorialiste / directeur de création / directeur artistique / webdesigner / développeur / flasheur / développeur / architecte / etc. ».

  2. Concernant « Le livre ultime du développeur pragmatique », en tant que développeur également, je vous conseille plutôt de commencer par lire : « The Pragmatic Programmer: From Journeyman to Master« . Ca date de 1999, mais ca reste complétement d’actualité !

  3. Cette structure est certes séduisante, mais comme Fred le précise, dans une start-up ! Elle est en revanche inapplicable déjà dans une web agency qui a un peu de bouteille (et donc quelques développeurs à son actif). Toutefois je retiens le principe rappelé (qui devrait être fondamental dans TOUS les projets quels que soient leurs fondements et leur cycle de vie) de conserver coûte que coûte la date de lancement prévue quitte à faire la sourde oreille aux demandes d’évolution et réduire le périmètre fonctionnel. Hélas, mille fois hélas on s’en éloigne à la vitesse V dès que les projets dépassent quelques mois.homme ! db

  4. Il ne faut cependant pas oublier un facteur important : derrière ces sociétés se cache en général une poignée de véritables petits génies de l’informatique. Si ces méthodes fonctionnent avec eux, il convient de vérifier aussi si elles restent opératoires avec une équipe de développeurs au potentiel plus modeste. Si on appliquait aveuglément ce que Paul Graham écrit (Hackers and Painters), on se mettrait tous à développer nos application en LISP … Mais, à mon avis, cette solution ne peut fonctionner qu’avec une équipe de développeurs sortant de Standfort ou du MIT.

  5. Wow, moi qui croyait que nos méthodes étaient un peu bizarres, les voila qui deviennent (presque) web 2.0 (à part le respect des délais initiaux, là, on a pris du retard :-( Belle trouvaille, je file sur Amazon acheter ce livre :-) Thanks

  6. Je suis d’accord à 100% sur les points suivants : > 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 > Ne pas faire de réunion (« la réunion, une alternative pratique au travail » comme disait je sais plus qui). Ou alors, la faire debout, vous verrez, ça va plus vite… Pour le reste, j’attendrai d’avoir lu… :) Merci pour cette référence bibliographique.

  7. Histoire d’apporter un peu d’eau à ce moulin et à la question est ce que ça marche, je peux juste vous dire que le projet de l’observatoire des présidentielles 2007 a été mené exactement comme décrit ici sauf sur un point : tout cela fonctionne sans être forcément dans le même bureau ni d’ailleurs sans forcément travailler aux mêmes moments de la journée (msn + mail + forum assurant la communication synchrone ou asynchrone selon les besoins). On pensait qu’on travaillait un peu n’importe comment, on est heureux d’avoir obtenu le label web2.0 :). Une chose est sûre cela fonctionne et cela permet d’avancer réellement rapidement, l’observatoire présidentielle s’est monté en 2 mois sachant que les trois membres principaux (chef de projet, designer et développeur) faisaient cela sur leur temps libre… Merci 37signals de nous redonner notre fierté :) :) :)

  8. Merci pour ces suggestions de lecture, dans le post comme dans les commentaires… y a t il des versions francophones de ces choses ? Getting Real The Pragmatic Programmer: From Journeyman to Master Ou/et autres… merci d’avance

  9. je n’ai as encore lu le bouquin mais je suis complet raccord avec la philo de Jason Fried (et j’utilise ses outils basecamp et backpack tous les jours). Petit commentaire sur: ne plus utiliser de storyboard ou wireframe mais passer directement au prototype… En tant que Designer Interactif, mes meilleurs outils reste le papier et le crayon. Ce n’est pas parce qu’on fait partie d’une SmallTeam qu’on doit se passer de conceptualiser une idee sur un paperboard (Draw, draw and draw again…). Pour preuve un papier de 37signals Autre lien – une prez de Jason again (bonne intro à ses idées) – How to Make Big Things Happen with Small Teams

  10. j’ai déjà eu l’occasion de travailler comme décrit dans la méthode et c’est génial. C’est extrêmement dynamique, efficace et les résultats sont très bons. Etant donné que le projet est dans la tête de 3 personnes, pas besoin de documentation. Mais on comrprend vite quelle est la limite de ce genre de méthodologie dans des plus grandes structures. Par contre, il y a moyen de découper un projet entier en sous modules dans lequel on applique ce genre de méthode. Le prototype clickable est toujours mieux que les wireframe, c’est évident… mais c’est la rolls royce de la conception ;-)

  11. Il y a juste un truc avec lequel je ne suis pas d’accord c’est de ne pas prendre en compte les demandes d’évolution ! Ca me paraît contraire justement au coté XP « équipes super dynamiques ». Qu’on ne rajoute pas les demandes supplémentaires avant que la 1ere version soit en ligne, OK. Mais qu’on refuse de s’adapter aux évolutions du marché/client/concurrents le plus tôt possible me semble contre-productif. Je trouve ca plus applicable sur chaque petit tronçon de projet. Mais au début de chaque tronçon, j’adhre à l’idée de le re-concevoir en tenant compte des nouvelles contraintes et besoins…

  12. 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 Pas vraiment surprenant : c’est l’histoire de Microsoft.

  13. Merci d’avoir recommander mon post « Getting Real, notes de lecture » et merci surtout de m’avoir fait découvrir cette publication de 37signals! Après plus de 7 ans de gestion de projet, ce fut pour moi un vrai bol d’oxygene… une vision nouvelle, simpliste et véritablement pragmatique… De là à l’appliquer tout de suite, cela semble difficile. Par contre l’utilisation de certains éléments comme la simplification des spécifications fonctionnelles ou de la méthodologie de travail peuvent être mis en place.

  14. Je ne vois rien de bien révolutionnaire dans tout ça. Un grand nombre de pratiques (reduire le fonctionnel pour garder une date, pas de réunions, prioritisation très radicale des évolutions, donner plus de valeur au vrai code qu’à toutes sortes de documentations, « Do The Simplest Thing That Could Possibly Work », …) sont mise en avant depuis plusieurs années par les méthodes agiles. Il n’y a donc rien à ce que cela fonctionne ! Bien au contraire ! Une chose me chagrine dans ce que j’ai pu lire (je précise que je n’ai pas lu le livre en question, juste des résumés et critiques) : la faible emphase sur les aspects de test (quoi de pire que d’introduire des bugs dans quelque chose qui marche bien ?) En ce qui concerne le « pas plus de 3 personnes par équipe (1 concepteur / designeur, 1 développeur, 1 qui encadre les 2 précédents) », je reste très sceptique : comment une personne peut elle progresser dans son « art » si elle ne travaille pas au contact de personnes qui pratiquent le même art ? A ce sujet, je conseille la lecture de l’excellent « Software Craftsmanship » de Pete McBreen.

Laisser un commentaire