(oui je sais je fais toujours des têtes bizarres quand je me prends en photo avec PhotoBooth, je prends rendez-vous avec mon psy tout de suite).

Aujourd’hui un livre intéressant pour tous ceux qui manquent un peu de théorie sur la conduite de projet… un petit livre qui s’avale facilement en une heure (une centaine de pages, petit format) et qui traîte de la conduite d’un projet intranet (quelques petites spécificités par rapport à un projet classique mais la méthodo est sensiblement la même).
Pour les chefs de projets fonctionnels confirmés se sera principalement un rappel des méthodes que tout le monde est censé suivre (mais que personne n’a le temps de suivre).

Un bon livre pour introduire la méthodo de suivi de projet.
Et vous c’est quoi votre livre de chevet de chef de projet? (perso j’en ai pas vraiment…)

Lors de la conduite d’un projet, les pièges sont nombreux surtout niveau technique, voici donc une petite liste des écueils connus à éviter à tout prix.

1. Conception fermée
C’est souvent une des difficultés majeurs pour le suivi d’un projet technique. Le projet en cours de route évolu, change, se métamorphose… certains fonctionnalités disparaissent, d’autres apparaissent, des contraintes nouvelles viennent s’ajouter au projet. Tous ces changements doivent pouvoir être pris en compte au fur et à mesure et ne pas être un frein pour le bon déroulement technique du projet. La conception aussi bien de la plateforme de production, que de la base de donnée ou de l’applicatif doit être flexible et ouverte… donnant du champ à des modifications.

2. Outils performants
C’est un des pièges récurrents, principalement dans les grandes structures, trouver des outils performants qui ne freinent pas le développement. Cela peut consister en des machines vieillottes ou qui tombent en panne, des problèmes réseau, des serveurs de l’ère du crétacé… ou simplement des procédures de mise en ligne trop longues qui vous bouffent votre temps de développement.

3. Versionning / sauvegarde
Un de vos soucis (si vous suivez un projet) est de s’assurer de deux choses:
- que des sauvegardes régulières sont faites aussi bien des données que du code source, à des intervalles réguliers, en essayant de varier les supports et en archivant régulièrement (je me souviens plus où j’avais lu ça, mais une étude avait montré qu’environ 20% des boites high-tech fermaient les portes après un accident de matériel faute de vraie politique de sauvegarde).
- que les développeurs ne se marchent pas sur les pieds, et donc utiliser un outil de versionning… éviter les cas classiques, qui sont: pierre enregistre un vieux fichier qu’il avait en local et bousille une semaine de boulot de paul, ou encore pouvoir revenir à une version précédente du code, très très pratique.

4. L’euphorie post-démo
Souvent pour sortir une démo à temps, on est tenté (et certaines fois on a pas trop le choix) de couper dans certaines principes qu’on c’est fixé… on fait des dev un peu plus cradocs, on néglige certaines parties, etc… rien de dramatique en soit, si on redresse au plus vite la situation. Le risque majeur est qu’on ait pas le temps de redresser les petites cochonneries qu’on a pu faire pour que la démo marche et que l’on continue dans cette voix. Pansement sur jambe de bois, sur bout de scotch, sur bout de ficelle et on va à moyen terme dans le mur.

5. Garder le cap
C’est une des tâches les plus dures et c’est un des rôles essentiels du Chef de projet technique: emmener tout le monde dans la même direction, avec le moins d’accrocs possibles, avoir une double vision: macroscopique du projet, mais aussi aller dans les détails du code ou de la conception de données pour que le projet fonctionnellement et techniquement ailles dans la bonne direction.

Il doit certainement ex exister d’autre mais ce sont les 5 principaux écueils à éviter quand on gère un projet technique. Et vous des expériences ou remarques à partager?

[oui c'est bien l'un de nous qui comate pied nu à 6h du matin par terre!]

Voilà après près de 21h de code, debuggage, montage, adaptation presque ininterrompu (on a quand même pris le temps de manger de temps en temps, sans compter les X clopes que je me suis envoyé durant la nuit, je sais c’est pas bien) me revoici de retour à mon poste après quelques heures de sommeil.
La démo était prête le jour dit, donc aujourd’hui à 7h du matin environ… hourra!
Un peu la tête dans le sac (j’ai faillit choisir une autre expression, mais non… restons léger et courtois) mais content d’avoir pu délivrer le résultat attendu (ou presque à quelques iotas près) plus ou moins dans les temps.

[6h30 on est super fresh!]

Mais le propos du jour n’est pas vraiment la nuit passé sur la démo (enfin partiellement en tout cas), mais plutôt sur les derniers jours d’un projet qui sont toujours importantes, stressantes et décicives.

1. Jamais dans les temps
Dans toute ma (longue?) carrière, je n’ai JAMAIS (et là un doute m’assaille, est ce que je suis nul? nan…) rendu un projet dans les temps, jamais. Toujours des fonctionnalités qui viennent s’ajouter, des zones d’ombres pas levées avant le développement du module, des difficultés techniques imprévues, etc… Donc si vous voyez que votre projet du retard, c’est (plus ou moins) normal, pas la peine de stresser outre mesure.

2. Eviter le stress non productif
C’est sans doute une des clefs pour boucler un projet… c’est l’ultime conseil que je pourrais donner, ne vous auto-stressez pas avec des angoisses de dernière minute non productive, du type le serveur qui plante et qui veut pas re-démarrer. Calmez vous (et les gens autour de vous), allez faire un tour, buvez un coup, fumez une clope (ou mâchez un cheawing-gum)… revenez serein (même si c’est pas complètement le cas) et résolvez le probème calmement. Souvent du stress vient plus d’erreurs que vous devrez corriger par la suite. Prenez les problèmes dans l’ordre de façon méthodique, même si tout le monde stresse et s’énerve, cri ou pleure… restez serein et concentré sur votre task-list.
Surtout lors du débuggage final, vous trouvez de temps en temps des effets de bord (qui pour une bonne partie se corrigent d’eux même après avoir fixé les principaux bugs déjà listés), ne vous jetez pas dessus, notez les et suivez calmement votre tasklist, sinon vous risquez de vous disperser et de passer encore plus de temps dessus.

3. Se concentrer sur l’essentiel
Vous ne pourrez pas livrer toutes les fonctionnalités à la date prévue? pas un drame… concentrez vous au maximum sur le coeur de votre projet, les fonctionnalités à très forte valeur ajoutée. Si le reste passe à l’ouest, pas grave, vous aurez peut être un peu de temps pour vous y atteler, quand l’essentiel sera réglé.

4. Redimensionner le résultat au besoin
N’hésitez pas à zapper certaines fonctionnalités pour les inclures dans une livraison suivante. Mieux vaut un projet réduit mais bien fini, qu’un produit bordélique, plein de bugs et baclé.

5. Les merdasses de dernière minute
Gardez vous un peu de temps pour parer aux éventuelles merdasses qui ne manquent pas d’arriver, surtout si vous partez pour un environnement hostile (une démo chez un client). Prévoyez un ordinateur de secours si le votre tombe en rade, une sauvegarde sur DVD ou bien un accès via le web… ou suivant les cas, quelques heures pour assurer une mise en ligne correcte (on sais jamais ce qui peut arriver aussi bien à l’export qu’à l’import). C’est souvent les dernières heures qui sont les plus cruciales, qui font que votre travail de quelques semaines/mois seront évalués à leur juste valeur (ou pas).
Prévoyez donc une marge confortable pour tout ce qui peut arriver dans les dernières heures et ne mettez pas en ligne à la dernière minute, prévoyez une mise en ligne intermédiaire quelques heures avant (ce qui vous permettra de voir éventuellement si la mise en ligne est rapide ou si elle nécessitera plus de travail).

[le dernier transfert de la base de donnée en local sur le laptop de mon boss, qu'on a du refaire trois fois!... à 6h43 la dernière ligne droite (on voit d'ailleurs les pieds du comateux en bas de la photo à gauche...)]

Et vous, des anecdotes/histoires de finalisation/mise en ligne de projet?

Tous les développeurs le savent, le pire du travail est le debuggage, en particulier sur les différentes plateformes et navigateurs disponibles sur le marché. Ne serais ce que pour un montage HTML propre, vous allez devoir tester tout cela sur les différentes version d’Internet Explorer, mais aussi les principaux navigateurs disponibles tel que Firefox, Opéra et Safari.
Vous pouvez toujours tenter d’émuler certains OS à partir d’un Mac et de faire tourner les différents navigateurs en utilisant Parallels ou VMWare, mais pour les autres plateformes (Linux et PC) vous allez devoir acheter/emprunter une machine ou alors vous tourner vers des services en ligne qui proposent un “aperçu” du rendu dans divers navigateurs.

WebWorkerDaily nous fournit une liste de 7 services de test navigateurs forts utiles… petit résumé
- IE NetRender comme son nom l’indique rendu pour les version 5.5, 6 et 7 d’Internet Explorer (pour les Linuxiens et les amateurs de Pomme)
- BrowsrCamp rendu de votre site pour les différents navigateurs disponibles sous Mac. Screenshot sur Safari gratuit, ou vous pouvez prendre la main sur 11 navigateur différents (via un VNC) à partir de 3$ pour 2 jours.
- BrowserShots sans aucun doute le plus impressionnant, vous donnant la possibilité de captures d’écran sur plusieurs dizaines de navigateurs sous Linux, Mac et Windows. Seul problème, sa popularité et donc le temps nécessaire pour générer vos screenshots. Vous pouvez souscrire à un abonnement qui vous coûtera 15$ par mois pour vous propulser en haut de la queue de rendu de screenshots…
- BrowserCam vous permet de tester votre site sur différents navigateurs pour les trois OS, la premier jour est gratuit, ensuite c’est 20$ par jour ou 400$ par an. C’est le seul service qui offre le rendu sous BlackBerry ou WindowsMobile.
- Litmus Couvre la majorité des navigateurs Windows (de IE5.0 à l’alpha de Firefox 3) et devraient bientôt inclure la plateforme Mac. Résultats disponibles via screenshots, mais avec module de bugTracking, gestion des versions, et URL privées pour partager vos résultats avec votre équipe. 30 jours de démo disponible, après c’est entre 39 et 129 €
- BrowserPhoto censé faire des tests sur les 3 plateformes sur pleins de navigateurs mais aucune info vraiment précise. Les prix varient de 15$ pour une journée à 150$ pour un an.
- BrowserPool prenez le contrôle d’un Mac, Linux ou Windows via VNC. Les prix commencent à 30€ par mois, mais avec des versions de navigateurs qui commencent à dater un peu.

Même si pour un vrai débuggage (genre javascript bien violent) il est indispensable d’avoir une machine (même émulée) et le navigateur sous la main, ce genre de site peut faire l’affaire pour valider un montage HTML.
Personnellement et après test, mon préféré reste BrowserShots, un peu long, mais vu le nombre de navigateurs dispo… pour des utilisateur régulier cela pourrait mériter de payer les 15$. (vous pouvez aller voir les rendus de TDW sous pleins de navigateurs rigolo ici)

Et vous c’est quoi votre méthode? votre outil de prédilection?

C’est sans doute une des tâches les plus dure à effectuer pour un manager ou un entrepreneur: savoir choisir les bonnes personnes pour construire son équipe (et accessoirement mener à bien son projet). Le recrutement n’est pas une science exacte (loin de là d’ailleurs… sinon ça se saurait), mais voici quelques conseils vu de l’intérieur pour pouvoir construire une équipe harmonieuse et productive.

[petit aparté: je prends comme principe que c'est pour monter une équipe sur le long terme et non pour un projet ponctuel ou répondre à une demande pressante, là les besoins sont beaucoup plus "terre à terre"]

1. Trouvez la personnalité
C’est à mon sens une des clefs du recrutement: trouvez une personnalité qui s’adapte bien aux personnes déjà présente dans votre équipe. Si toutes les personnes de votre équipe s’entendent bien, que tout le monde vit dans une bonne ambiance, le travail n’en sera que facilité, vous n’aurez plus (ou pas, en tout cas moins) de problème de lutte de pouvoir.
N’hésitez pas donc à faire participer la plus grande partie de l’équipe aux entretiens de recrutement, si vous en avez la possibilité et le temps.

2. Le chemin plus que le but
Le plus souvent on cherche un “développeur senior machin” ou encore un “chef de projet avec expérience dans X”, mais bien souvent le chemin et les expériences donnent souvent plus d’information sur la personne que son “titre”. Autodidacte, cours du soir, travail à l’étranger, évolution dans les divers entreprises, souvent le chemin donne beaucoup d’informations intéressantes. Plus qu’un développeur sénior, c’est son parcours pour arriver à ce poste qui en dit souvent long sur la personne.

3. Variez les horizons
N’hésitez pas à combattre vos préjugés (même si vous vous en défendez) et à donner leur chance à des personnes d’horizons divers, cela ne fera qu’enrichir votre équipe, lui donnera une nouvelle dimension. Cela veut aussi bien dire, engager un tatoueur comme graphiste (je prends un exemple extrême je sais), un développeur bulgare (même si il n’y a aucune équivalence de son diplôme et que tout ses sites réalisés sont en cyrillique et donc vous n’y comprenez rien), etc…

4. Des compétences redondantes
N’hésitez pas à doubler les compétences (surtout les plus critiques) pour plusieurs raisons.
- A poil: ne vous retrouvez pas tout nu, parceque votre développeur star c’est fait la malle pour aller pointer dans une SSII
- Quatre Yeux plutôt que Deux: je sais que c’est idiot à dire, mais bien souvent deux personnes valent mieux qu’une, même pour des niveaux qu’on pourrait qualifier d’inégaux (je le dis tout le temps mais c’est vrai, j’apprends autant au contact d’un stagiaire que le contraire… j’apprends des nouvelles fonctions, des méthodes que je connaissais pas et bien souvent l’approche est diamétralement opposée)

5. Peu de spécialiste (en tout cas pas tout de suite)
N’engagez pas d’ultra spécialiste, mais plutôt des gens aux compétences multiples et/ou adaptables. En cas de changement d’orientation (technique ou autre) ou de changement d’équipe vous devez être capable d’adapter la fonction de chacun et c’est beaucoup plus simple avec des généralistes (rien n’empêche de former les personnes sur des technos ultra spécifiques).

6. Peu mais bien
Engagez peu, mais bien… attendez, testez, validez, n’hésitez pas à éclaircir les zones d’ombres, les non dits. Rien n’est pire que de s’apercevoir au bout de quelques semaines/mois qu’on c’est trompé, c’est frustrant et embêtant aussi pour le recruteur que pour le salarié.

Voilà mes conseils, qui sont je le sais hautement utopique (en ces temps de disette de Travailleurs Du Web) pour construire votre équipe idéale. Et vous vous avez des conseils, des anecdotes?