You On Web | Le Développement Web au service des performances de votre entreprise
href="http://www.youonweb.be">You On Web | Le Développement Web au service des performances de votre entreprise
Getting Real : comment s'organiser pour réussir et gérer un projet, une équipe de façon concrète et réaliste

Getting Real : comment s'organiser pour réussir et gérer un projet, une équipe de façon concrète et réaliste

Posté le 31 mars 2016 dans Général

J'ai lu beaucoup de livres ; j'en lis encore beaucoup et je sais que d'autres m'attendent encore.  Mais certains livres, aussi minimalistes qu'ils peuvent l'être ont un impact différent.  Certains livres ont une portée, une raisonnance particulière ; un petit quelque chose qui vous insuffle un changement.  Une révélation.

C'est le cas de Getting Real.  Ce livre électronique, écrit par l'équipe de 37Signals est disponible gratuitement en téléchargement.  Ce livre est en Anglais.  Dans cet article, avec l'accord des auteurs, je vous propose un résumé en Français de tous les concepts de cette méthodologie.

Qu'allons-nous voir ensemble ?

  1. Au fond, c'est quoi Getting Real ?
  2. Le point de départ
  3. Restez petit
  4. Priorités
  5. Sélection fonctionnelle
  6. Processus
  7. L'organisation
  8. L'équipe
  9. Design des interfaces
  10. Code
  11. Des mots, rien que des mots, toujours des mots
  12. Tarification et inscription
  13. Promotion
  14. Support
  15. L'après lancement
  16. A vous maintenant !

Au fond, c'est quoi Getting Real ?

Getting Real est plus qu'une simple méthodologie de travail en équipe, c'est une philosophie.  Les principes résumés dans ce livre sont ceux qui ont guidé l'équipe de 37Signals depuis sa création en 1999 et grâce auxquels des logiciels en ligne tels que Basecamp ou encore Highrise ont vu le jour.

C'est donc une manière de concevoir des logiciels bien que tout ce qui est évoqué peut être appliqué à d'autres types de business.

Etre dans la réalité

Le Principe Premier de Getting Real est simplement d'être constamment dans la réalité et de bypasser tout ce qui représente la réalité.

Plutôt que de perdre du temps à représenter la réalité pour la comprendre et l'analyser, Getting Real propose simplement de créer cette réalité.

Avec Getting Real, on se concentre sur ce que l'utilisateur va voir et utiliser.  On va, par exemple, débuter le travail de développement par les interfaces et construire tout le logiciel autour de ces interfaces.

Concevoir l'interface dans un premier temps permet d'être dans le concret, dans la réalité.  Alors qu'une analyse ne constituera que l'illusion d'un accord, un écran constituera la réalité.

Viser moins plutôt qu'en vouloir toujours plus

L'autre idée derrière Getting Real est d'apprendre (à tous les niveaux) à se concentrer sur moins plutôt qu'en vouloir toujours plus.

Plutôt que de vouloir à tout prix faire plus que la concurrence, Getting Real préconise d'en faire moins mais de le faire bien.

Getting Real is Less!

Dans cet article, je vous propose de découvrir les différents concepts de cette philosophie.  Pour respecter la philosophie du livre, je vais volontairement me caler sur la structure de celui-ci.

Le point de départ

Construire moins

Deuxième principe évoqué pour Getting Real : Getting Less ! Ne pas vouloir absolument en faire plus que la concurrence mais penser au contraire à développer une solution simple.

Pour cela, il suffit de se concentrer à résoudre un problème réel et concret.  Ne pas sombrer dans l'abstrait ou la lourdeur !

Gardez ceci en mémoire :

  • Moins de code
  • Moins de fonctionnalités
  • Moins d'options

Quel est votre plus gros problème ?

Un bon point de départ est de développer une solution pour soi-même en premier lieu.  Développer une application web qui va permettre de résoudre un problème personnel.

Il est évident que vous n'êtes pas le seul à avoir ce problème ! Si vous arrivez à résoudre votre problème, de manière simple et efficace, vous pouvez être certain que votre application résoudra le problème d'autres personnes.

Autofinancez-vous

Pour rester dans la réalité, penser à vous auto-financer dans un premier temps.  Le problème d'une start-up est qu'elle va passer du temps à chasser les investissements.

Non seulement, elle perd du temps dans le développement de sa solution mais elle perd également pied avec la réalité en ayant la possibilité de dépenser l'argent des autres !

Un financement extérieur ne doit pas être vu comme un Plan B mais comme un Plan Z.  Les contraintes financières forcent la créativité.

Délai & Budget fixe, Scope flexible

Tordons immédiatement le cou à un mythe : il est tout simplement impossible de développer une application web en respectant tout à la fois le budget, le planning et le scope du projet ! Un de ces piliers en souffrira irrémédiablement et bien souvent, ce sera la qualité de votre projet.

Dans la philosophie Getting Real, il est conseillé de fixer la date à laquelle le projet doit être lancé et quel budget peut être accordé à ce projet.  Marquez cela d'un fer rouge et ne dérogez en aucun cas à cela.

Si l'objectif ne semble pas atteignable, n'augmentez ni le budget, ni le planning mais réduisez simplement le scope de l'application.

Launching something great that’s a little smaller in scope than planned is better than launching something mediocre and full of holes because you had to hit some magical time, budget, and scope window. Leave the magic to Houdini. You’ve got a real business to run and a real product to deliver.

Comment travailler ?

  1. Fixer de vraies priorités
  2. Etre réaliste dans ses attentes
  3. Etre flexible

Ayez un ennemi

Bien entendu que d'autres ont déjà développé un outil semblable au vôtre.  Sachez-le, prenez-en conscience et mettez-vous en compétition !

Il ne faut pas avoir peur de ses ennemis.  Il faut seulement les connaitre et savoir ce qu'ils font.  Mettez cela en compétition face à ce que vous ne faites pas !

Oui, misez sur ce que vous ne faites pas et non sur ce que vous faites.  Proposer un logiciel simple qui répond à un problème concret est beaucoup mieux que vouloir absolument proposer toutes les fonctionnalités de tous les outils concurrents.

Vouloir développer une application web qui répond aux besoins de tout le monde est IMPOSSIBLE.  Au final, vous risquez de développer une application qui ne répond aux besoins de personne.

Cela ne doit pas être une corvée

En aucun cas ! Jamais ! Le développement de votre application ne doit pas devenir une corvée pour vous.

Il est primordial de conserver un enthousiasme débordant pour elle.

Restez petit

Moins gros

Ne devenez pas un paquebot qu'il est difficile de faire changer de cap.  Restez une barque facile à manoeuvrer.

Plus vous serez léger (à tous points de vue), plus vous pourrez évoluer rapidement en dépensant moins d'énergie !

Diminuez le coût du changement

Restez flexible en réduisant les coûts nécessaires au changement.  Le changement doit être et rester votre ami.  C'est ainsi que vous pourrez changer / évoluer plus vite que vos concurrents et gagner la bataille.

Les 3 Mousquetaires

Getting Real préconise de petites équipes soudées pour travailler sur un projet.  L'équipe idéale pourrait être composée de 3 personnes :

  • 1 développeur
  • 1 designer
  • 1 personne pouvant jongler de l'un à l'autre

Bien entendu, cette équipe de 3 personnes est à adapter à votre situation et votre projet.  L'idée est d'avoir une équipe pluri-disciplinaires où chacun peut être amené à reprendre le travail de l'autre pour booster la créativité et les échanges.

Enfin, plus l'équipe est petite, plus la communication est facilitée.

Embrassez les contraintes

Accepter les contraintes.  Ne voyez pas les contraintes comme des ennemis.  Au contraire, laisser les limitations vous guider vers des solutions créatives et novatrices !

Soyez vous-même

Une erreur fréquente est de vouloir paraitre plus grand qu'on ne l'est.  Au contraire, cultiver votre différence et criez haut et fort que vous êtes une petite équipe soudée, flexible et enthousiaste !

Profitez de ce rang de petite équipe pour cultiver une communication plus personnelles et amicales.  Votre communication en sera soulagée et simplifiée.

Priorités

Quelle est LA grosse idée ?

Plutôt que de se perdre dans l'écriture d'une analyse fonctionnelle bien souvent inutile, concentrez-vous sur la définition claire et simple du concept de votre application.  Quel est LE concept de votre application ?  Il s'agit du one-point vision !

Ce principe, cette vision, vous devez tout le temps l'avoir en tête.  Cela doit vous servir de guide durant tout le process de développement.

Cette vision doit être brève.  Elle doit tenir en une phrase.

37Signals donne les exemples suivants :

  • Pour Basecamp, la vision est Project management is communication
  • Pour Backpack, la vision était Bring life’s loose ends together

En ayant cette vision à l'esprit constamment, chaque décision que vous prendrez au sujet de votre outil s'appuiera sur elle ! 

Ignorez les détails au début

Work from large to small

Trop souvent, on a tendance à s'occuper des détails immédiatement, en début de projet.  C'est une erreur.  Travailler les détails en début de projet amène surtout de la stagnation.

Il ne faut pas viser la perfection directe de votre produit.  Ne perdez pas des heures à travailler sur des points de détails.  Travaillez à sortir quelque chose de fonctionnel et revenez sur les détails par la suite.

C'est un problème quand c'est un problème

Combien de temps perdez-vous à vous pencher sur des problèmes qui n'en sont pas encore ?

Combien de temps perdez-vous à envisager des risques qui ne se sont pas produits et ne se produiront probablement jamais ?

Arrêtez et penchez-vous sur un problème uniquement lorsque celui-ci se présente à vous !

Dans leur ebook, 37Signals explique que lorsqu'ils ont lancé Basecamp, le système permettant de faire la facturation mensuelle n'était pas encore prêt.  Mais ce n'était pas un problème puisque la facturation des premiers inscrits allaient seulement débuter 30 jours après leur inscription.

Ils se sont donc penchés sur le développement de cette partie après le lancement en sachant qu'ils avaient 30 jours pour faire face à ce problème.

Engagez uniquement les bons clients

Oui certaines personnes trouveront que votre application est nulle et qu'elle ne sert à rien.  Bonne nouvelle : cela vous évite de devoir accueillir tout le monde et de devoir répondre aux besoins de tout le monde.

Concentrez vous et votre marketing sur les bons clients, ceux qui ont le même problème que vous et qui seront contents d'avoir une solution simple et efficace pour y répondre.

Les autres ? Dirigez-les vers la concurrence et laissez à celle-ci le soin de répondre à leurs attentes !

La scalabilité ? Plus tard !

Votre application ne devra pas répondre immédiatement à des millions d'appels par jour ! Alors ne vous prenez pas la tête avec cela dès le lancement (pire : avant le lancement).

Travaillez sur ce problème lorsqu'il est sur le point de se présenter ; pas avant.

Une application, une opinion

Il est important de toujours garder le cap.  Souvenez-vous de la vision de votre application et gardez cette vision en tête à chaque instant.

Il est important de ne pas vouloir à tous prix répondre à toutes les demandes provenant des clients.  Nous verrons par la suite que c'est même tout le contraire !

Sélection fonctionnelle

Demi vaut mieux que moitié pourri

Il est préférable de développer un demi-produit qui déchire plutôt qu'un produit complet mais banal ou semi-pourri !

Interpellant ? Et pourtant bien réel.

Mettez tous vos efforts à coller uniquement à l'essentiel.  Prenez une feuille et notez tout ce que vous pensez que votre application doit faire.  Coupez maintenant cette feuille en 2 et vous serez proche de la réalité.

Cela n'a tout simplement pas d'importance

Oui on vous dira que votre produit doit répondre à ceci ou à cela.  Oui on vous dira que votre application serait mieux si elle faisait ceci ou cela.

Ceci n'a aucune espèce d'importance ! Collez à l'essentiel et uniquement à l'essentiel.  Restez focus sur cela et balayez tout le reste.

Simplement.

Commencez par NON

Dites NON.  Simplement.  Directement.  Quand un client vous demande quelque chose, une nouvelle fonctionnalité, une adaption, un changement : commencez par dire NON.

Gardez à l'esprit que chaque fois que vous dites OUI pour un changement ou une nouvelle fonctionnalité, c'est comme si vous adoptiez un enfant.  Pendant des années, vous allez devoir en assumer toutes les responsabilités.

Ne soyez donc pas un yes-man mais rendez, au contraire, compliqué et difficile la demande d'ajout d'une nouvelle fonctionnalité.

Ne tenez pas une liste de demandes de changements.  Cela ne sert à rien.  Si une nouvelle fonctionnalité est véritablement attendue par vos clients, elle reviendra tellement souvent que vous l'aurez naturellement en tête.

Voici le cycle conseillé pour chaque demande fonctionnelle réalisée :

  1. Dites non !
  2. Continuez à dire non tant que le besoin ne devient pas réellement présent
  3. Forcez cette fonctionnalité à prouver son utilité ; challengez-là !
  4. Si le challenge n'est pas relevé, oubliez la demande et dites non à nouveau
  5. Si la demande passe ce cap, faites des schémas sur papier
  6. Quand un accord est trouvé sur les schémas, créez les design
  7. Quand un accord est trouvé sur les design, codez la fonctionnalité
  8. Testez, adaptez ... Testez, adaptez ... Testez, adaptez ...
  9. Vérifiez si les FAQ ou autres textes d'aide doivent être modifiés
  10. Adaptez la présentation du produit (si nécessaire)
  11. Adaptez la présentation marketing (si nécessaire)
  12. Adaptez les termes de la licence produit (si nécessaire)
  13. Vérifiez qu'aucune promesse produit n'est brisée
  14. Lancez
  15. Retenez votre souffle

Vous voyez maintenant tout ce que cela implique d'accepter une nouvelle fonctionnalité ? Alors, réfléchissez-y bien à 2 fois avant de dire oui !

Les coûts cachés

Comme nous venons de le voir, accepter une nouvelle fonctionnalité dans votre application engendre de nombreux coûts cachés.

Etudiez donc tous ces coûts cachés avant d'accepter une nouvelle fonctionnalité.

Pouvez-vous l'assumer ?

Assurez-vous également de pouvoir gérer ce que vous allez créer.  Prenez le temps de réfléchir si ce que vous êtes sur le point de mettre en ligne est correctement dimensionné par rapport à votre équipe.

Exemple : lancer une application multilingues peut induire un support en plusieurs langues ou du community management en plusieurs langues.  Avez-vous vraiment la capacité de gérer cela ici et maintenant ? Non.  Alors contentez-vous d'une seule langue.

Solutions humaines

Laissez de la place pour l'humain dans votre application.  Appliquez-vous à développer une application générique, une solution générale pour laisser à chacun le soin d'être créatif dans l'exploitation de la solution et l'adapter à sa situation.

Il est inutile et lourd de vouloir répondre à tous les cas d'utilisation possibles.  C'est surtout impossible.  Alors n'essayez pas de le faire.

Concentrez-vous à régler le problème de base et laissez chaque utilisateur être créatif pour adapter la solution à sa situation.

Oubliez les demandes d'ajouts fonctionnels

Rappelez-vous ce que nous avons dit un peu plus haut : commencez par dire NON à chaque demande d'ajout fonctionnel !

Lisez les demandes qui rentrent, ne les prenez pas en compte et jetez-les.  Tout simplement.  Rien ne sert d'en faire une liste.

Vous apprendrez à considérer uniquement celles qui reviennent très fréquemment.  Et elles reviendront tellement souvent que vous les aurez bien à l'esprit.  Pas besoin de les noter.

Inversez la vapeur

Inversez la tendance des sondages d'opinions.  Au lieu de demander aux utilisateurs ce qu'ils voudraient voir apparaitre dans votre application, demandez-leur ce qu'ils voudraient voir disparaitre.

Aidez-vous de ce feedback pour vous recentrer encore plus sur l'essentiel.

Processus

La course à l'appli qui tourne

Ceci doit être votre Priorité n°1 : arriver au plus vite à une solution vivante, qui tourne et qui est opérationnelle !

Votre seule obsession doit être d'arriver à cela.  Uniquement à cela.  Vous verrez que cela vous incitera à vous concentrer sur l'essentiel, à être dans la réalité, à oublier les détails.

Lancez et répétez

N'espérez pas avoir quelque chose de parfait dès le premier round.  Une application web se construit au fur et à mesure, à force d'itérations.

De l'idée à son implémentation

Concrètement, quelles sont les étapes préconisées par la philosophie Getting Real pour développer une application web ?

Elle sont au nombre de 4.

  1. Brainstorming durant lequel vous demanderez à chacun de venir avec ses idées.  Que voulez-vous que le projet fasse ? Contentez-vous de répondre aux grandes questions, n'entrez pas dans le détail.  Déterminez votre backlog produit à la fin de ce brainstorming.
  2. Passez immédiatement à la réalisation de Sketches, de maquettes réalisées rapidement sur papier.  Le but est de traduire le concept et les idées en interfaces réelles et concrètes.  Travailler sur papier permet de faire facilement des expérimentations sans perte de temps.
  3. Quand vous êtes d'accord sur l'étape précédente, créez des écrans HTML pour avoir une version concrète de la 1ère fonctionnalité ; celle qui est jugée comme LA Priorité n°1.  Au final, vous devez donc avoir une version HTML / CSS de cette fonctionnalité, accessible par toutes les personnes impliquées dans le projet.
  4. Commencez à Coder.  Quand tout le monde est d'accord sur le rendu de l'interface HTML / CSS pour la 1ère fonctionnalité, commencez à coder celle-ci.  Restez flexible : peut-être que ce travail induira des changements.  Acceptez-les.

Revenez ensuite dans ce cycle itératif (troisième et quatrième étape) pour la 2ème fonctionnalité et ainsi de suite jusqu'à ce que votre backlog soit vidé ou jusqu'à ce que :

  • votre date de lancement est atteinte
  • et/ou votre budget est épuisé

Oubliez les préférences

Evitez au maximum le piège des configurations laissées au libre arbitre du client.  Cela ne fait qu'alourdir les interfaces et le code ! Plus vous offrez de possibilités de préférences, plus vous devrez coder des préférences.

Prenez vous-même les décisions et assumez-les ! Choisissez les paramètres pour vos clients et appliquez-les à tout le monde.  Est-ce que donner la possibilité aux clients de choisir le nombre d'items à afficher en homepage apporte une véritable valeur ajoutée ?

Faites le choix et c'est tout.

"Done!"

Cette expression doit devenir un objectif en soi ; votre objectif.  Visez le plus rapidement possible l'atteinte d'un résultat concret.  Visez la résolution de quelque chose pour pouvoir passer à autre chose.

Ne tergiversez pas pendant des heures.  Ne passez pas du temps inutile en discussion.  Prenez une décision et agissez.  Si cette décision s'avère finalement mauvaise, vous pourrez toujours revenir en arrière et en prendre une autre.

Testez dans la réalité

Les meilleurs tests se font dans la réalité.  Dès le début de vos développements, efforcez-vous de tester toutes vos fonctionnalités avec des données réelles.

Vous devez tester l'inscription d'un nouvel utilisateur ? Ne tapez pas n'importe quoi dans les champs mais ressentez ce que l'utilisateur ressentira en remplissant dûment et complètement le formulaire.  Cela vous permettra de comprendre ce que l'utilisateur vivra lors de son inscription et d'améliorer son expérience utilisateur.

De même, oubliez le principe des beta users.  Activez les fonctionnalités beta en live pour qu'elles puissent être testées par de vrais utilisateurs avec de vraies données.

Découpez votre temps

Découpez votre temps.  Découpez vos projets.  Au lieu d'avoir un projet étalé sur 12 semaines, travaillez sur 12 projets de 1 semaine.

Voyez toujours plus petit.  Cela aidera votre cerveau à garder une vue d'ensemble du problème sur lequel vous êtes concentré.

Découpez les problèmes en plus petits problèmes.  Ne travaillez pas sur des tâches qui prennent plus d'une journée mais découpez-les.

L'organisation

Unité

Gardez l'unité autour de vos projets en y travaillant avec des équipes intégrées plutôt que spécialisées.  Ne faites pas travailler le designer seul dans son coin pour ensuite passer la main aux développeurs.

Créer une équipe autour de votre projet et faites que cette équipe collabore sur toutes les étapes du projet.

Etre dans sa bulle

Il est INDISPENSABLE de prévoir du temps où chacun est seul et concentré sur ce qu'il doit faire.  C'est la seule manière de pouvoir avancer concrètement dans le projet.

Prévoyez des zones de temps quotidiennes où aucune interruption  ne soit rendue possible.  Au moins 4 heures par jour en continu devrait pouvoir être planifiées pour ces périodes sans interruption.

Durant ces 4 heures :

  • personne ne doit parler à personne (de quelque manière que ce soit)
  • chacun doit être concentré sur ce qu'il doit produire
  • tout le monde met les questions de côté
  • tout le monde avance

Tous les échanges doivent être prévus en-dehors de cette plage horaire.  C'est totalement possible d'y arriver.  C'est une simple question d'organisation.

Les réunions sont toxiques

Si il est besoin d'une réunion pour discuter du concept, c'est que le concept n'est pas clair !

Travaillez donc plutôt à simplifier le concept pour pouvoir ensuite en discuter par Basecamp, IM ou au pire par email.

Les réunions sont à éviter pour plusieurs raisons :

  • elles coupent la journée de travail
  • elles tournent souvent autour de discussions abstraites et pas autour d'éléments concrets
  • l'agenda est souvent trop vague

Quand une réunion est malgré tout indispensable, gardez ces éléments à l'esprit :

  • prévoir maximum 30 minutes avec un chrono sur la table et quand le chrono sonne, on arrête et on retourne à ce que l'on faisait
  • inviter le minimum de personnes
  • prévoir un agenda très clair de ce qui doit être discuté
  • prévoir la réunion en-dehors de la plage de concentration

Recherchez et célébrez les petites victoires

En développement logiciel, il est primordial de conserver une motivation intacte tout au long du process.  Avoir un long cycle de développement, éloignant trop les périodes de célébrations, est très mauvais pour la motivation.

Il est donc nécessaire de travailler à atteindre rapidement de petites victoires.  C'est bénéfique.  Pour cela, faites en sorte d'avoir des cycles de développement les plus courts possibles.

Si toutefois vous travaillez sur quelque chose nécessitant un cycle de développement plus long, prévoyez une journée par semaine ou tous les 15 jours qui sera consacrée à réaliser un objectif concret pour pouvoir le célébrer.

Posez-vous cette question : que pourrions-nous réaliser et livrer en 4 heures ?

L'équipe

Engagez moins et engagez plus tard

Engager moins et engager plus tard.  Voici le conseil résumé de ce chapitre.  Pour rester agile, le conseil de 37Signals est de ne pas foncer tête baissée dans des engagements trop nombreux et trop rapides.

Plutôt que d'engager quelqu'un de nouveau dans l'équipe, il est préférable de réfléchir à des alternatives, de faire preuve de créativité pour arriver à se passer de l'engagement.

Secouez le cocotier

Pour réaliser un engagement, oubliez les CV's, les recommandations, les lettres de motivation bidons ou encore les exemples de code.

Exigez du concret.  Basez-vous sur du réel.  Faites passer un test réel ; une mise en situation concrète pour valider de manière pragmatique toutes les qualités et compétences de la personne.

Oui vous devez vérifier ses compétences techniques mais vous devez également valider sa capacité à faire face à un problème, à trouver des solutions alternatives, à être créatif.

De l'action, pas de blabla

Mettez donc les mots de côté lorsque vous procédez à un engagement et basez-vous uniquement sur le concret de l'action.

A quoi sert-il que la personne vous raconte qu'elle a déjà réalisé ceci, fait cela, développé tel système ou exploité tel framework ? A rien si cela reste des mots.

Posez-lui moins de questions et entrez vite en action  en lui demandant de développer quelque chose pour vous.  Vous testerez non seulement sa motivation et son enthousiasme mais également ses compétences réelles et concrètes.

Engagez des couteaux suisses

Ne cherchez pas de spécialistes, c'est inutile et arrogant.  Au contraire, cherchez des personnes pouvant endosser plusieurs casquettes.

Ce type de personnalités vous offrira plus de souplesse et d'agilité.  Alors que le spécialiste ne pourra vous aider que dans un domaine précis, un employé multi-disciplinaires sera un véritable couteau Suisse au sein de votre équipe et pourra vous rendre de nombreux services.

Vous ne pouvez pas feindre l'enthousiasme

Si vous hésitez entre deux profils, choisissez celui qui vous parait le plus enthousiaste et le plus motivé ! Il est préférable d'engager un profil moyen mais fortement motivé qu'un profil exceptionnel mais sans réelle motivation.

La motivation et l'enthousiasme pour un projet permettent de soulever des montagnes, de relever des défis et d'aller au-delà des obstacles.

C'est de cela que vous avez besoin !

Engagez de bons écrivains

Pensez également aux compétences annexes lorsque vous procédez à un nouvel engagement.

Autant que possible, veillez à engager des personnes ayant de bonnes compétences en écriture car ces profils sont souvent de très bons communicants.

Rappelez-vous : la gestion de projet est une question de communication ! Avoir de bons communicants au sein d'une petite équipe est un gage de qualité sur le long terme.

Design des interfaces

Interface en premier

Une des bases de la philosophie Getting Real ! Commencez par créer l'interface avant de débuter la programmation.

Design-first mentality VS Program-first mentality

La programmation est la partie la plus lourde d'un développement logiciel.  La plus lourde et donc la plus couteuse en cas de changement d'avis.

Travailler sur le design en premier lieu, d'autant plus si il s'agit de sketches (maquettes faites au crayon sur une feuille), est au contraire très rapide et demande peu d'efforts.  Il sera donc peu onéreux de revoir sa copie de nombreuses fois si cela s'avère nécessaire.

De plus, l'interface est le produit final attendu.  Peu importe le nombre de lignes de code que vous tapez derrière, ce que l'utilisateur verra et utilisera, c'est uniquement l'interface !

Débuter par le design permet de très vite ressentir ce que donnera l'application finale : est-ce que l'application aura du sens ? Est-ce qu'elle sera simple à utiliser ? Est-ce qu'elle résout le problème posé ?

En commençant par le design, on peut rapidement répondre à ces questions et confirmer que l'on est sur le bon chemin.

Design épicentrique

Commencer par le design, c'est bien.  Travailler sur le design central, c'est encore mieux !

Plutôt que de s'attarder à l'ensemble des détails de l'interface, il est préférable de concentrer son attention sur la réalisation des maquettes du centre de l'écran, du coeur du système.  Rien ne sert de s'occuper en même temps de ce qui entoure l'écran (le header, le footer, la sidebar, les couleurs, le logo, ...).

Lorsque la partie principale de l'écran est terminée, on recommence le travail pour le 2ème élément le plus important et ainsi de suite jusqu'à ce que l'ensemble de l'interface soit réalisée.

Pensez aux 3 états

L'erreur souvent commise en développement d'interfaces est de s'attarder uniquement sur la vue en situation normale, quand tout va bien.  Autrement dit, l'écran que l'utilisateur aura sous les yeux quand il n'y a pas d'erreur et que des données sont déjà présentes.

Or, en conception d'interfaces, il est également indispensable de penser aux 2 autres états possibles :

  1. quand l'écran est vide ; autrement dit, quand il n'y a encore aucune donnée
  2. quand une erreur survient

L'état initial

Il est primordial de se pencher sur cet état car c'est la première impression que l'utilisateur aura de votre application.

En effet, quand un utilisateur va commencer à exploiter votre logiciel en ligne, il n'aura aucune donnée.  Ses listes seront vides ; ses écrans n'auront aucune information à présenter ; ses dashboard n'auront pas de graphiques à montrer.

Ne pas penser à cet état de votre interface reviendrait à présenter un écran mal conçu lors de sa première utilisation.  N'oubliez pas que l'on a qu'une chance de faire bonne impression.

Cet état est l'occasion d'insérer quelques explications, quelques tutoriels sur la manière d'utiliser l'application, de faire de l'inline help.

Etre sur la défensive

N'oubliez pas que votre application va générer des erreurs, même temporaires.  Il est donc impératif de réfléchir son design de manière défensive.

Envisagez les erreurs qui pourraient se produire durant l'exploitation de votre application web et voyez comment gérer au mieux ces erreurs au niveau de vos écrans.

Pour cela, il faut simplement penser à l'expérience utilisateur en cas d'erreurs.

Contexte versus Cohérence

La règle générale dans la conception d'interfaces dit qu'il faut être cohérent dans la manière de présenter les choses ; dans la manière de proposer les éléments sur l'interface.

Par exemple : garder le menu au même endroit sur chaque écran.

Toutefois, le contexte passe au-dessus de la cohérence.  En effet, si le contexte le justifie, il peut être tout à fait acceptable de ne pas toujours être cohérent dans son interface si cela apporte plus de sens.

Le meilleur exemple est le tunnel d'achat d'un e-commerce durant lequel, il est totalement acceptable de supprimer tous les éléments présents sur les autres pages comme le menu, le footer ou encore les sidebars dans le but de concentrer l'attention de l'utilisateur sur l'acte d'achat.

Copywriting & Design

Trop souvent on voit des interfaces être pensées et créées en y intégrant du Lorem Ipsum.  C'est une erreur !

Etre attentif au copywriting fait partie intégrante du design des interfaces.  Dès lors, lorsque vous travaillez sur le design de votre interface, faites directement attention au choix des termes (au sens large) qui seront présentés.

Une seule interface

Vous avez des fonctionnalités d'administration ou de super-administration à développer ? Intégrez-les directement dans la même interface !

Ne créez pas une interface séparée dans laquelle vous placerez ces fonctions.  Cela ne ferait que dépenser du temps inutilement.  Directement mais aussi durant tout le cycle de vie de votre application car vous devrez constamment maintenir 2 interfaces différentes.

Code

Moins de fonctionnalités

Gardez votre code le plus simple possible ! Voici comment résumer le concept de Less Software, très important dans la philosophie Getting Real.

Pour conserver un code simple, il est impératif de garder à l'esprit le concept de Less Software : moins de fonctionnalités, c'est moins de code, c'est moins de déchets.

N'oubliez pas que chaque changement mineur ou chaque ajout apporte un effet en cascade au niveau du code.  De plus, doubler la quantité de code ne double pas sa complexité : cela l'augmente de façon exponentielle !

La solution est d'encourager vos développeurs à faire des contre-propositions et à être créatifs.  Pensez également à découper chaque gros problème (demandant beaucoup de codes) en plus petits problèmes (demandant chacun moins de codes) et à vous concentrer sur une solution répondant à 80% du problème avec seulement 20% d'effort.

Optimiser pour le bonheur

Un développeur heureux est un développeur productif ! Et pour qu'un développeur soit heureux, il doit pouvoir évoluer dans un environnement technologique motivant et exaltant.

Choisissez donc des frameworks de développement modernes et sexy qui donnent envie de coder. 

Ecoutez votre code

Ce n'est pas faire preuve de schizophrénie que d'écouter son code parler.  Votre code peut parler : il peut vous apporter des solutions simples à des problèmes que vous pensez complexe.

Pour cela, il suffit de l'écouter et laisser votre code vous guider vers des alternatives.

Gérez vos dettes

Essayez de ne pas payer vos dettes bancaires et vous en subirez rapidement les conséquences.  Soyez dès lors aussi strict dans votre gestion des dettes que vous avez vis-à-vis de votre code.

Il peut parfois être nécessaire de développer un code qui n'est pas 100% correct.  Pour gagner du temps, pour aller au plus vite vers une solution.

Ceci est tout à fait acceptable dès lors que l'on gère ces dettes.  Deux possibilités s'offrent à vous :

  1. payer directement les dettes
  2. noter les dettes dans une facture que vous devrez payer plus tard

Dans tous les cas, ne laissez pas de factures impayées et pensez à toujours payer vos différentes dettes !

Restez ouvert

Ne développez pas une forteresse à laquelle personne ne peut accéder !

Laissez au contraire la possibilité à d'autres développeurs d'exploiter votre logiciel par le biais d'une API.  Laissez également vos utilisateurs accéder à leurs données, à les exporter et les exploiter ailleurs.

Soyez ouverts tout simplement.

Des mots, rien que des mots, toujours des mots

Il n'y a rien de fonctionnel dans une spécification fonctionnelle

Il ne sert à rien de passer son temps à écrire des spécifications fonctionnelles car il n'y a finalement rien de fonctionnel dans une spécification fonctionnelle !

Elles sont simplement fantaisistes ; elles ne reflètent pas la réalité.  Elles ne servent qu'à rassurer en donnant un sentiment, une illusion d'accord entre les développeurs et le client.  Même si chacun lit les mêmes spécifications, chacun les comprend et les interprète différemment.

Mais, même en sachant cela, elles représentent une forme de contrat empêchant toute flexibilité.  Lorsque c'est signé, c'est approuvé se dit-on.  Impossible de faire machine arrière, d'accepter de passer au-dessus même si cela s'avère être la meilleure chose à faire.

L'autre difficulté avec les spécifications fonctionnelles est qu'elles obligent à prendre des décisions complexes et souvent les plus importantes au sujet de l'application au moment où nous avons le moins d'informations.  C'est en effet quand on débute un projet que l'on en connait le moins au sujet de ce projet !

Les spécifications fonctionnelles incitent également à voir trop grand.  Ecrire une fonctionnalité ne coûte rien ; n'engage à rien.  C'est tellement (trop) facile qu'on ne se fixe pas de limite .  On ne pense pas aux difficultés que l'on rencontrera lorsqu'il faudra les mettre en pratique.

Quelles sont les alternatives ?

  • Ecrire quelque chose de plus bref qui tend vers quelque chose de réel
  • Ecrire une histoire d'une page sur laquelle on explique ce que l'application doit faire et si cela prend plus d'une page à expliquer, c'est que quelque chose est trop complexe et qu'il faut simplifier
  • Utiliser un langage simple et direct
  • Il faut s'empêcher de prendre plus d'un jour pour arriver à écrire ce document
  • Entrer ensuite directement dans la phase de conception des interfaces qui est une bien meilleure alternative

Ne générez pas de documents morts

Eliminez toute forme de documents inutiles ! Plutôt que perdre son temps à écrire quelque chose, à tenter de documenter quelque chose, passez à la réalisation !

Faire un mockup pour expliquer quelque chose est souvent plus efficace qu'écrire un long document.

Racontez-moi une petite histoire

Quand vient le moment de décrire les fonctionnalités qui composeront l'application, pensez à écrire une histoire simple pour expliquer cette fonctionnalité.

Comme on le préconise dans les méthodes Agile, faites en sorte que chacune de vos user stories soit écrite de manière simple et humaine ; comme si vous étiez en conversation avec un ami.

Utilisez des mots réels

Cet aspect des choses à déjà été abordé à différente reprise mais il est si important qu'il est nécessaire de le rappeler.  N'utilisez pas de Lorem Ipsum mais exploitez directement de vrais mots !

Il en va de même lorsqu'il est nécessaire d'encoder des informations dans un formulaire.  Empêchez-vous de taper tout et n'importe quoi dans les champs mais efforcez-vous d'indiquer des informations réelles pour ressentir ce que les utilisateurs ressentiront plus tard.

Personnifiez votre produit

Donnez une vrai personnalité à votre produit.  Donnez-lui une âme, une manière d'être.

En traitant votre produit comme une personne, vous accompagnerez chacun des développements de ce trait de personnalité et vous en ferez un produit unique.

Tarification et inscription

Offrez des choses

Pensez à offrir des choses.  N'envisagez pas de développer que des applications payantes.

Ce concept est souvent exploité en web marketing.  Les gourous du web offrent souvent des conseils gratuits, des formations gratuites, des vidéos gratuites à côté de leurs produits payants.

Faites de même.  Envisagez le développement d'une petite application qui répond à un problème simple et offrez purement et simplement l'exploitation de cette application.

Facilement dedans, facilement dehors

Que ce soit la création d'un compte ou la suppression de celui-ci, ces 2 étapes doivent pouvoir être réalisées facilement, simplement et sans aucune douleur.

Alors que ce concept est souvent mis en pratique pour l'inscription, on voit trop souvent des applications en ligne qui tentent de cacher la possibilité de supprimer son compte.  Cela est souvent rendu compliqué.

Et pourtant, offrir une manière simple et rapide de supprimer son compte est une très bonne manière de construire la confiance avec vos utilisateurs.  D'autant plus si vous leur offrez la possibilité de récupérer toutes leurs données avant de fermer leur compte.

Pour l'inscription, votre formulaire doit être le plus bref possible.  Ne demandez que les informations dont vous avez techniquement besoin pour créer le compte ; rien de plus.

Bien entendu, donnez la possibilité de tester l'application gratuitement et sans devoir donner sa carte de crédit !

Ne jouez pas au lapin idiot

Pas de contrat à long terme ! Les utilisateurs rechignent à s'engager sur la durée.

Offrez simplement un abonnement mensuel avec la possibilité de stopper son abonnement quand on le désire.

Adoucir la nouvelle

Vous devez augmenter vos prix ? Faites-le mais adoucissez cette mauvaise nouvelle en l'annonçant suffisamment tôt sur toutes les pages de votre application.

Donnez également la possibilité à vos clients actuels de bénéficier d'une exemption durant une certaine période.

Promotion

Lancement hollywoodien

Pour lancer votre application, pensez à réaliser un lancement digne d'Hollywood.  Pour cela, il suffit de respecter 3 phases :

  1. Teaser
  2. Preview
  3. Launch

Pensez à faire un teasing quelques mois avant le lancement de votre application.  Commencez simplement en plaçant quelques éléments sur le site comme le logo mais aussi un blog.  Sur celui-ci, vous pourrez expliquer ce sur quoi vous travaillez et vous pourrez également mettre en place une page de capture d'adresses emails.

Quelques semaines avant le lancement officiel, il est temps de vous lancer dans la preview.  Pour cela, placez quelques écrans de la future application pour montrer à quoi celle-ci va réellement ressembler.  Pensez à mettre en avant les fonctionnalités principales.  Tout en continuant à poster sur le blog et inciter les gens à s'inscrire à votre newsletter, vous pouvez également offrir des golden tickets à certaines personnes qui pourront alors tester votre application en avant-première.

Vous avez fait votre launch ; votre application est maintenant en ligne et les gens peuvent s'inscrire.  Pensez bien entendu à prévenir l'ensemble de votre newsletter de ce lancement et lancez votre campagne marketing.

Un site du tonnerre pour votre application

Le lancement, c'est l'occasion de mettre en ligne votre site promotionnel dont l'objectif est de présenter votre produit.

Ce type de site peut être composé de la manière suivante :

  • Une page d'Overview où on explique ce que fait l'application et quels sont les bénéfices de celle-ci
  • Une page offrant une visite guidée (Tour) de l'application afin de guider les gens au travers des différentes fonctionnalités de l'outil
  • Une page offrant des captures d'écrans des fonctionnalités principales voire une vidéo de présentation de l'outil
  • Une page de type manifeste où on peut décrire la philosophie mais aussi la personnalité de l'application
  • Il peut être intéressant d'avoir une page dédiées aux études de cas pour montrer des cas réels et expliquer concrètement les problèmes que cette application peut résoudre
  • Une page de buzz où on va concentrer les avis des clients, les articles de presse et les revues du produit
  • Placer un forum peut être une bonne idée pour permettre de créer une communauté autour de votre produit et permettre aux utilisateurs de s'aider entre eux
  • Bien entendu, offrez une page d'inscription simple et rapide ainsi qu'une page expliquant la tarification
  • Maintenez un lien vers votre blog que vous devez continuer à l'alimenter régulièrement (1 article par semaine est largement suffisant)

Surfez sur la vague

Continuer à maintenir le blog à jour est effectivement important.  Il est souvent moins onéreux et plus efficace de bloguer que de faire de la publicité.

Pensez à ce que le blog ne soit pas uniquement tourné sur vous et sur le produit mais donne aussi des conseils et des astuces sur la problématique autour de laquelle tourne l'application.

Eduquer pour promouvoir

Votre blog peut donc devenir un véritable outil promotionnel en vous positionnant également comme un expert.

Devenez un véritable professeur en donnant des informations régulières et de qualité sur le thème de votre application.

S'alimenter par les fonctionnalités

Profitez de l'arrivée d'une nouvelle fonctionnalité sur votre outil pour générer un nouveau buzz et en parler un maximum autour de vous.

Gardez les yeux ouverts

Gardez les yeux ouverts et pensez à régulièrement vérifier qui a parlé de vous en bien comme en mal.

Rendez-vous sur leur site et remerciez-les d'avoir parlé de votre produit.  Même si le message est plus critique, acceptez-le et répondez simplement aux critiques.

Vendre en interne

Ne passez pas à côté de la possibilité de booster votre clientèle actuelle.  Placez régulièrement des rappels sur la possibilité de passer à un abonnement supérieur en mettant en avant les gains fonctionnels que cela apporte.

Comment vous appelez-vous ?

Pensez bien entendu au nom que vous allez donner à votre application.  Il est plus important que celui-ci soit simple à retenir et à énoncer que de représenter réellement le coeur du système.

Si vous trouvez un nom qui évoque à la fois ce que fait l'application et qui est simple à retenir : bingo ! Si cela n'est pas possible, efforcez-vous de trouver un nom qui sonne bien.

Support

Ressentez la douleur

Il est important que vos développeurs ressentent la peine de vos clients.  Autrement dit, faites-en sorte que les développeurs soient régulièrement en contact avec les clients.  

Une bonne manière de le faire est de ne pas outsourcer votre support mais de le faire gérer par votre équipe de développement.  Ceci permet de bâtir des ponts solides entre vos clients et votre équipe.

Aucune formation

Faites en sorte que votre application ne demande pas de formation pour être prise en main par vos nouveaux clients.  Inspirez-vous d'Apple qui a été le premier à mettre sur le marché un smartphone qui n'était pas accompagné de son manuel de l'utilisateur.

Apple avait tellement travaillé sur l'ergonomie et la facilité de prise en main de son iPhone que tout manuel d'utilisation devenait superflus.

Travaillez donc sur la simplicité ! Eventuellement, vous pouvez avantageusement remplacer la documentation par des mécanismes d'inline help et/ou la mise en place d'une section FAQ.

Répondez rapidement

Rappelez-vous que fait est mieux que parfait.  Au niveau du support également ! Efforcez-vous de répondre rapidement à toutes les demandes arrivant au support.

Même si la première réponse donnée n'est pas parfaite.  Soyez transparent avec votre client.  Expliquez-lui que des recherches complémentaires doivent être effectuées pour répondre complètement à sa question mais que vous êtes déjà en mesure de lui dire que ...

Gardez à l'esprit que cela vous permet d'être réactif et proche de vos clients.  Cela humanise votre support.

L'amour vache

Tenez-vous prêt à répondre NON à vos clients.  C'est normal.  Surtout si la demande de celui-ci concerne l'ajout d'une nouvelle fonctionnalité.

Rappelez-vous ce que nous avons déjà vu ensemble.  Répondez simplement non et passez à autre chose.

Abemus Forum

Nous avons déjà évoqué la nécessité de mettre un forum à disposition de vos clients.

En plus de donner un sentiment concret d'ouverture, ceci est une bonne manière de permettre à votre communauté de s'entraider et donc de vous décharger d'une partie du travail de support.

Publiez vos fiasco

N'essayez pas de cacher quelque chose qui n'a pas fonctionné ou un bug qui est apparu.  Même si personne ne l'a remarqué !

Soyez transparent sur l'ensemble et annoncez clairement le problème, ce que vous avez fait pour y remédier et les éventuelles conséquences.

L'après lancement

1 mois pour s'améliorer

Donnez-vous un délai de 30 jours pour sortir une nouvelle version majeure après le lancement initial.

Cela vous permet de montrer que les choses bougent tout en vous offrant l'opportunité de refaire du buzz.

Il y a un autre avantage à cela.  En effet, en sachant que vous sortirez une nouvelle version dans le mois suivant le lancement, vous pouvez vous rassurer sur le fait de sortir une v1 plus légère en terme de fonctionnalités.

Plutôt que de retarder le lancement de 1 mois, vous lancez plus rapidement votre produit en programmant dès le départ un nouveau lancement 1 mois après.

Ecrivez encore et toujours

Ne vous arrêtez pas de bloguer et de communiquer après le lancement.  Au contraire !

Pensez à régulièrement expliquer ce sur sur quoi vous travaillez et les évolutions qui arriveront bientôt.  Profitez également de votre blog pour poster des nouvelles FAQ's, des how-tos ou des trucs et astuces.

Bref, soyez actif !

Beta aux oubliettes

Oubliez la notion de version Beta.  Lancer une version beta d'une application est souvent une excuse.  C'est pouvoir sortir le joker version beta si quelque chose venait à ne pas fonctionner correctement !

Préférez à nouveau la transparence.  Acceptez l'idée de sortir quelque chose d'imparfait que vous pourrez améliorer par la suite.

Ayez conscience des points faibles et annoncez-les.  Annoncez aussi le calendrier endéans lequel vous planifiez les améliorations.

Tous les bugs ne sont pas nés égaux

Tout d'abord, restez zen.  Toutes les applications présentent des bugs.  Dès lors, ne paniquez pas si un bug est découvert dans votre application.

Ne vous sentez pas non plus obligé de corriger tous les bugs dès leur apparition.  Clairement, tous les bugs ne sont pas égaux.  Certains demanderont une résolution immédiate de votre part ; d'autres pourront attendre.

Il est indispensable, ici aussi, de travailler sur la priorité et non sur l'urgence.  Ne réagissez jamais dans l'urgence mais prenez le temps d'analyser posément la situation avant de modifier tous vos plans.

Naviguez à travers la tempête

Chaque changement que vous apporterez à votre application comporte le risque d'amener des réactions très fortes.  Très vives.

Attendez que la tempête passe avant de réagir.  Résistez à l'envie de réagir en plein coeur de la tempête.  Laissez le temps au temps.  Attendez que les réactions épidermiques - après l'introduction d'un changement - s'estompent.

Lorsque les choses se seront calmées, prenez le temps d'analyser calmement toutes les réactions et prenez vos décisions de manière concrète et pragmatique.  Surtout pas de manière émotionnelle !

Rangez vos oeillères

Gardez du temps pour faire de la veille concurrentielle.  Pensez à régulièrement vous tenir au courant de ce que fait la concurrence, de la manière dont leur produit évolue.

Résistez à la tentation

Lorsque votre produit deviendra mature.  Lorsqu'il aura séduit un certain nombre de clients.  Lorsqu'il commencera à compter parmi les autres applications.  Surtout : résistez à la tentation de devenir plus compliqué !

Gardez toujours à l'esprit tous les concepts de Getting Real.

Surfez sur la vague

Surfez sur la vague.  Restez flexible.  Soyez toujours ouvert au changement.

Il arrivera peut-être un moment où vous devrez prendre une décision importante : celle de changer radicalement de cap.  Ne soyez pas fermé à cette idée.  Acceptez-là.

Si vous avez appliqué tous les concepts de cette méthodologie, vous serez suffisamment ouvert et léger pour aborder un tel changement de cap de manière sereine et positive.

A vous maintenant !

Voici qui termine cet article très imposant.  Je suis ravi d'avoir pu partager avec vous cette philosophie, ce concept de travail.  J'espère que ce résumé vous a inspiré autant que le livre m'a inspiré.  J'espère que j'ai pu vous convaincre des bienfaits d'appliquer cette méthodologie à votre manière de travailler.

Je suis certain que chaque entreprise peut retirer quelque chose de positif de ces principes.  Je suis tout aussi convaincu que des choses étonnantes peuvent survenir dans votre organisation si vous appliquez cette philosophie au quotidien.  Et pas besoin de développer des applications pour cela !

Avec un peu d'imagination et de bon sens, vous pourrez adapter cette méthode à votre réalité.

Si vous souhaitez aller plus loin, contactez-nous et voyons comment nous pouvons vous aider à intégrer cette méthode de travail à votre entreprise.

Retour au blog

Partager