Hier, sur le Site Du Zero, J’ai lancé un recrutement de developpeur(s) pour le projet Def-webCreator. Comme je suis très investi dans le Def-Blog, il ne me reste plus de temps pour me consacrer à cet outils qui pourrait pourtant nous faire gagner un temps incroyable sur nos projets web. J’ai pour le moment eu la réponse de deux developpeurs qui ont l’air serieux mais ce recrutement me force à apprendre de nouvelles choses : Le management d’un projet par équipe. Jusqu’à présent, mon équipe se constituait de mon frangin Sharky (graphiste) et de ma copine Jenn (rédactrice) qui excelent chacun dans leur domaine. Aujourd’hui je me voit constituer une nouvelle équipe pour un nouveau projet et la percpective d’avoir de nouvelles têtes m’excite et me fait peur à la fois. Bah oui, c’est si facile de foirer un projet…

J’en ai donc profité pour me renseigner et j’ai découvert un livre vraiment super, Getting Real.
Ce bouquin en ligne et gratuit est écrit par la société 37 signals qui possèdent notamment les services TadaList et BaseCamp (des services de todo list et de gestion de projets)

Le site tkaap.com à fait une synthèse des recommandations principales du livre pour concevoir son projet web. Je vous les copie-collent directement ici en remerciant tkaap.com pour ce travail.

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 boursouflées. Il n’y a pas besoin de sur-vendre 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.

(Pour ceux que ça intéresse vraiment, je vous invite à continuer avec cet article aussi très intéressant.)

Tweeter

gestion

projets

Sur le même sujet

Le point sur mes derniers projets

Un Dashboard de statistiques et metriques sur Windows Phone

Ajouter le bouton « J’aime » de Facebook sur votre navigateur

Boston GM