tKaap Blog

Beaucoup de chose sur le feu, mais nous voici de retour. Pour ce premier billet, j’ai décidé de m’attacher à la construction d’une gestion de projet viable pour tKaap. Et je viens justement de terminer la lecture d’un bouquin très enrichissement sur le sujet : Getting Real, écrit par la startup qui est à l’origine du projet Basecamp, 37Signals.

En couplant avec le billet issu de mon blog personnel, j’ai retenu 24 recommandations qui me semble pertinente pour notre projet. Cela ne veut pas forcément dire que nous suivrons l’ensemble de ces recommandations à la lettre. Par contre, nous en appliquerons certaines et en adapterons d’autres le moment venu. Il sera aussi possible que l’on soit amené à créer notre propres règles en fonction de nos divers besoins et expériences.

Nous partirons donc sur une gestion de type agile pour conserver une flexibilité et une réactivité accrue toute au long du projet. Si vous avez d’autres idées ou d’autres sources pour qu’on assure, n’hésitez pas à nous les soumettre.

Recommandation n°1 : Au lieu de faire une chose de plus, faites une chose de moins. Au lieu de faire une solution complexe, faites en une de simple.

Recommandationn n°2 : Les contraintes force la créativité.

Recommandationn n°3 : Plus vous êtes léger, plus le changement est facile. L’entreprise légère aura deux métros d’avance alors que l’entreprise plus lourde en sera encore à s’interroger sur la ligne à emprunter. Tout l’argent, tout le marketing, toutes les équipes du monde ne vous achèteront pas la souplesse d’être petit.

Recommandation n°4 : Gardez l’équipe aussi petite que possible. La loi de Metcalfe, qui dit que « la valeur d’un système de communication croit avec le carré du nombre d’utilisateurs de ce système » comporte un corollaire en ce qui concerne les équipes de projet : l’efficacité d’une équipe est approximativement inverse au carré du nombre de membres de cette équipe.

Recommandation n°5 : Que représente votre application ? De quoi s’agit-il ? Avant de commencer à concevoir ou à coder vous avez besoin de savoir le but de votre produit — la vision.

Recommandation n°6 : Au début ignorez les détails. Les détails se révèlent par l’utilisation de ce que vous construisez. Vous allez vous apercevoir de ce qui a besoin de plus d’attention. Vous allez sentir ce qui manque.

Recommandation n°7 : Concentrer-vous sur l’essentiel. Travaillez du plus grand au plus petit. Ne sur-construisez pas. Créez une très bonne application ensuite souciez vous de ce qui doit être fait une fois qu’elle devient un grand succès.

Recommandation n°8 : Si vous essayez de plaire à tout le monde, vous n’allez plaire à personne. Reconnaissez pour qui votre application est réellement faite et concentrer vous à leur plaire. Ne courtisez jamais du monde qui ne sera jamais heureux.

Recommandation n°9 : Les employés ont besoin d’un temps ininterrompu pour mener les tâches à bien. Les moments d’isolement déclenchent les vrais progrès.

Recommandation n°10 : Réduisez le nombre de réunion. Célébrez les petites victoires. La chose la plus importante dans le développement d’application, c’est la motivation.

Recommandation n°11 : Les petites équipes ont besoin de personnes pouvant porter plusieurs casquettes. Vous aurez besoin de designers sachant écrire et de développeur qui comprendront le design.

Recommandation n°12 : Embaucher quelqu’un qui est excité d’imaginer construire ce que vous construiser. Quelqu’un qui déteste ce que vous détestez. Quelqu’un qui est très heureux de monter à bord de votre train.

Recommandation n°13 : Si vous devez décider entre un petit nombre de personnes qui conviennent à un poste, toujours engager le meilleur rédacteur. Etre un bon rédacteur, c’est plus que des mots. Un bon écrivain sait communiquer et rend les choses faciles à comprendre.

Recommandation n°14 : Créer l’interface avant de commencer à programmer. Ce que vous vendez c’est ce que les gens voient. Si vous contentez de pondre une interface à la fin du projet, les lacunes apparaitront.

Recommandation n°15 : Oubliez les spécifications formelles. Elles vous force à prendre des décisions importantes trop tôt dans le projet. Aller au delà de la phase de spécification et vous conserverez la flexibilité du changement.

Recommandation n°16 : Faites qu’il soit aussi facile que possible de s’inscrire – et de se désinscrire – à votre application.

Recommandation n°17 : Pour pour faire monter la mayonnaise, prévoyez un lancement hollywoodien : 1) Aguicher, 2) Montrer en avant-première, et 3) Lancer sur le marché. Le nom c’est l’hameçon. Donner à votre application un nom facile à retenir.

Recommandation n°18: Le meilleur moyen de connaître les forces et les faiblesses de votre logiciel, c’est encore d’écouter les utilisateurs. Vous et votre équipe devriez savoir ce que vos clients disent. Il n’y a pas de substitue aux vrais utilisateurs qui utilisent votre application en condition réelles. Obtenez de vrai feedback. Ensuite, optimisez en fonction de cette information.

Recommandation n°19 : Publiez les mauvaises nouvelles pour vous en débarrasser. Si quelque chose va mal, dites-le. Même si vos clients ne s’en étaient pas aperçus.

Recommandation n°20 : Un blog ne fait pas que montrer que votre application est vivante, cela rend votre entreprise plus humaine. N’hésitez pas à conserver un ton amical et personnel.

Recommandation n°21 : N’utiliser pas la « béta » comme bouc-émissaire. Les version bétas privées sont utilies, les bétas publiques sont une connerie. Si ce n’est pas assez bon pour le public, ne le mettez pas entre les mains de vos clients. N’attendez pas que votre produit atteigne la perfection. Ce moment n’arrivera pas. Prenez la responsabilité de ce que vous mettez en ligne. Poussez le et appelez-le version.

Recommandation n°22 : Attendez que les réactions épidermiques aux changements s’atténuent avant d’agir. Rappelez-vous également que les réactions négatives sont presque toujours exprimées plus fortement et avec plus de passion que les réactions positives.

Recommandation n°23 : N’en rajoutez pas pour le plaisir d’en rajouter. C’est comme ça que les applications deviennent boursoufflées. Il n’y a pas besoin de survendre en ajoutant de plus en plus de fonctions, il suffit que vous fournissiez un service dont la valeur soit constante.

Recommandation n°24 : Voyez Flickr. Au début, c’était un jeu multi-joueurs en ligne appelé le Jeu Sans Fin. Ses concepteurs se sont vite rendu compte que ses fonctions de partage de photos constituaient un produit plus crédible que le jeu lui-même (qui fut en définitive abandonné). Soyez prêts à admettre vos erreurs et à changer de cap. Ayez l’esprit surfer. Surveillez l’océan. Trouvez où les grosses vagues déferlent et agissez en conséquence.