Suite de la chronique [Part 1] postée ici
STAFFING
- Hire Less and Hire Later : Ne recrutez pas tout de suite. Avez-vous vraiment besoin de recruter ? Que se passera t-il si vous ne recrutez pas ? Intégrer de nombreux employés dans une culture cohérente est difficile et génère de la complexité (communication, vision partagée, etc...). Prenez du temps. Si vous devez absolument recruter, vous devez savoir exactement de qui vous avez besoin, comment l'introduire et la mission qu'il doit mener. Lancez une période de collaboration "Test" avant de valider le recrutement.
- Get Well Rounded Individuals : Embauchez des généralistes plutôt que des spécialistes. Les petites équipes ont besoin de personnes polyvalentes. Vous avez besoin de développeurs qui comprennent le design, et capables de communiquer avec les clients. Tout est question de flexibilité et d'adaptation rapide.
- Wordsmiths : Embauchez des gens à l'aise à l'écrit, capable de transmettre leurs idées clairement et rapidement par email. Des gens qui savent comment communiquer et se faire comprendre facilement.
INTERFACE DESIGN
- Interface first : Designez l'interface en premier, sur papier ou sous forme de maquette HTML. . L'interface est votre produit. Vous donnez naissance à un "objet" réel que les gens peuvent comprendre. Votre produit à t-il du sens, est t-il facile à utiliser ? Vous pouvez le savoir avec de vraies maquettes.
CODE
- Less Software : Gardez votre code le plus simple possible. Limitez les fonctionnalités, ne tentez pas de répondre à tous les problèmes. Trouvez des solutions, transformez les problèmes difficiles qui demandent beaucoup de codes en problèmes simples qui en demande moins. Cette démarche permet de construire des produits plus facile à comprendre et à utiliser.
WORDS
- There's Nothing Functional about Functional Spec : N'écrivez pas de specifications. Elles ne reflètent pas la réalité. Dessiner, construire et utiliser sont réalité.
- Tell me a Quick Story : Si vous devez expliquer un concept ou une nouvelle fonctionnalité, écrivez une courte histoire, dans un langage naturel. Décrivez l'idée générale et accompagnez la avec des écrans. N'écrivez pas de documents qui ne seront jamais lus. Maquettez et prototypez.
SUPPORT
- Answer Quick : Soyez disponible et réactif face aux retours clients. Même si vous ne pouvez pas fixer le problème immédiatement, réagissez, montrez que vous êtes à l'écoute. Une excellente manière de se différencier de vos concurrents.
- Tough Love : Soyez capable de dire non à vos clients. Vos utilisateurs n'ont pas toujours raison concernant l'ajout de nouvelles fonctionnalités. Préservez la pertinence et la simplicité de votre application en sachant dire NON.
POST-LAUNCH
- Issue a major uptate 30 days after launch : Maintenant que vous pouvez vous baser sur les retours réels de vos utilisateurs, lancer une nouvelle versions. Montrez que vous écoutez, que vous êtes réactif et faites à nouveau parler de vous.
- Beware the Bloat Monster : Gagner en maturité ne veut pas dire gagner en complexité. Résistez à la tentation d'ajoutez toujours plus de fonctionnalités. Il arrive un moment ou la bonne décision est de faire vivre le produit comme il est.
Critique :
Ce livre s'adresse à ceux qui veulent faire plutôt que dire.
Getting Real va droit au but, écrit dans un style direct et efficace, à l'image de sa personnalité.
Ce livre se lit rapidement et arrivée dans les dernières pages, on brûle d'une seule envie : EXECUTER.
Car les enseignements de Getting real se résume à cela : Exécuter, avec passion et entouré des bonnes personnes.
Je le recommande à tous les web entrepreneurs, et plus généralement à tous les porteurs de projets, car les conseils peuvent s'appliquer à d'autres domaines que le développement d'applications web.
Et la première partie de la chronique ici
Comments