Dans cet article , il expose sa vision d'un modèle économique simple :
Les entreprises de petite taille peuvent grâce au web, rayonner autant qu'une grosse entreprise. Mais elles ne doivent pas tomber dans le piège de la dispersion: Il faut rester sur son coeur de métier. Et il est étonnant de voir des start-up ne sachant pas exactement quel est leur coeur de métier. Si ton voisin vend la même chose que toi moins cher et arrive à payer ses factures, alors tu es très mal.
Il faut se consacrer sur ses produits et non pas chercher à faire 'à tout prix' plaisir aux utilisateurs pour qu'ils achètent ces produits.
Pour faire connaitre son produit , l'entreprise à deux alternatives: dépenser de l'argent ou partager largement ses connaissances sur le produit.
Cette illustration est tirée du blog : creating_passionate_users
Ainsi d'après lui, l'utilisateur est balancé entre avoir plein de fonctionnalités et pourvoir se servir d'un produit basique, simple d'emploi.
Les développeurs cherchent à sortir le produit qui tue: avec des tonnes de fonctionnalités, capable de s'adapter à tous les usages.
C'est une erreur, l'utilisateur au fond de lui souhaite ne pas se poser des questions ni être confronté à un écran rempli de case à cocher d'option.
C'est pour cela que Rails est le framework le moins paramétrable de sa catégorie, ce n'est plus un défaut, c'est une qualité. Il est prêt à l'emploi tel quel. Rien n'empêche l'utilisateur averti de modifier le comportement, mais sans utiliser une interface graphique d'administration.L'utilisateur doit faire confiance au développeur pour se voir proposer la meilleure composition en fonction de l'utilisation.
Concernant la conduite de projet.
David préconise des cycles de 3 semaines avec une équipe réduite. Une application utilisable doit voir le jour à la fin de ce délais. Puis, les décideurs et les commanditaires doivent se poser la question: est ce qu'on injecte des ressources pour une nouvelle fonctionnalités et repartir pour 3 semaines ou doit on tout arrêter et se contenter de ce résultat ?.
Concernant les spécifications détaillées.
Vouloir décrire dans un document le fonctionnement complet d'une application est illusoire et dangereux. Illusoire car, personne n'est capable ne visualiser et d'imaginer une application tel qu'elle sera dans 6 mois. Dangereux parce qu'il est très facile de modifier quelques lignes dans un document sans mesurer les conséquences sur le développement, si les spécifications sont figées, on assistera à un effet tunnel et l'application ne correspondra plus au besoin réactualisé.
Voir le post dans son contexte d'origine http://germanlinux.blogspot.com/
Aucun commentaire:
Enregistrer un commentaire