2 Associés est une agence web de Montréal spécialisée en développement web et mobile, stratégie de contenu SEO, SEM et les technologies langagières.

Vous voulez discuter?

Éléments de réussite et charge de projets Web

2 Associés développement web et mobile à Montréal

En tant que consultant à Montréal, je travaille en moyenne avec un minimum de 4 équipes différentes par année. Parfois plus. Ce que j’en retire comme expérience est non seulement très «réelle» mais également très «différente» d’une équipe à l’autre.

De ces expériences, j’ai vu et vécu toutes sortes de situations. Parfois amusantes et parfois un peu moins. Je ne crois pas qu’il existe une recette ultime pour la réussite de projets Web, mais il existe assurément des recettes qui fonctionnent à peu près toujours, indépendamment de l’expérience des membres constituant cette équipe. Alors aussi bien mettre les chances de notre côté.

La personne en charge du projet se doit d’être en charge du projet

Il y a une différence fondamentale entre gestionnaire de projet et coordonnateur de projet. Je ne veux pas dénigrer le second mais un gestionnaire de projet ne se contente pas de transférer des courriels aux différents intervenants, il fait la gestion du projet, c’est à dire le suivi du projet au quotidien, par une rencontre de 15 minutes type «scrum». Si tout le monde travaille dans différents environnements, faites des «screencasts» de 5 minutes environ (vraiment génial). Il ou elle doit tout savoir sur le déroulement du projet, jusqu’au absence en cas de maladie d’une personne. Trop souvent, le gestionnaire de projet ouvre le site en «staging» la veille d’une présentation client et hop : «Ce n’est pas à mon goût, je pensais que ça serait totalement complété, etc.» Et non, la vie de gestionnaire de projet n’est pas celle du client final. Il faut être au courant pour être en mesure de comprendre et d’expliquer au client, justement.

Le «scrum» meeting, c’est juste avant ou après le diner

Là je risque de vous surprendre mais le seul mandat où les absences au «scrum» meeting, ces rencontres quotidiennes de 15 minutes, étaient les moins fréquentes à été le mandat où les «scrum» étaient tenus à 11h45 ou 13h00. Les «scrum» tôt le matin sont 80% du temps tenus en retard car les membres sont occupés, un peu endormi, doivent régler un truc urgent etc. Pour être franc avec vous, les «scrum» à 9h00 c’est pour forcer les gens à être au bureau à 9h00, point! Revoyez vos politiques. De plus, les «scrum» à 9h00, tout le monde dors par manque de caféine ou ont du mal à se souvenir de ce qu’ils ont fait la veille et ce qu’il feront aujourd’hui! Les «scrum» en fin de journée je n’ai jamais vu ça et honnêtement, je pense que les problèmes seraient similaires à ceux des «scrum» à 9h00.

Une seule et même personne pour gérer les versions de fichiers reçus ou à venir

Celui-là est loin d’être acquis mais tout le monde à déjà vécu avec un dossier contenant des fichiers exemple :

  • 2 final pour révision.doc
  • english final.doc
  • final.doc
  • final2.doc
  • old final.doc
  • v3.doc
  • version4.doc

Une bonne nomenclature de fichiers s’impose car celle-ci n’a pas de sens ici, et pas plus sur un serveur. Il faut que tout soit à un seul endroit accessible par tous, exemple Dropbox, Google Drive ou autre, et mis à jour par une seule et même personne qui archive au fur et à mesure les documents anciens et remplace/renomme les documents reçus. Personne n’a la même nomenclature et parfois elle change en cours de route soit par erreur ou par goût (un beau «Bonjour!» à tous mes amis designers qui réinventent la terminologie «final» avec des «final final 2 bonne version»). S’il faut revenir à une version passée, celle-ci sera dans un dossier _archives (avec un «underscore» à l’avant pour qu’il se retrouve en premier).

Le moins de courriels possible, svp

Tout le monde a déjà vécu une conversation courriel ou le sujet à changé 8 fois… Dois-je continuer? Utilisez une plateforme pour la gestion de vos projets : Basecamp, Producteev, Trello pour ne nommer que ceux-là. Ils sont tous gratuits, à l’essait du moins, et ensuite intégrer en au moins un à vos coûts d’opération et fini la gestion de projet «À-La-Outlook».

«Ce projet est vraiment simple, tu vas voir!»

Les pires projets commencent par «Ce projet est vraiment simple…». Ceux-là, gardez-vous 100% de doute car ce sont souvent les pires. Souvent imaginés à la hâte avec très peu de retour sur la réflexion d’origine. Aucun plan n’existe (car trop simple!) et sont souvent pleins de malentendus en cours de route. Je travaille souvent sur des projets «vraiment simples» pour une journée, une semaine ou plus, je sais de quoi je parle. Pour les projets simple, gardez la facturation simple : À l’heure.

Un plan minimum clair dès le départ

Pour tous les projets «moins simples», établissez à rebours : la date de livraison finale, celle de la pré-finale (parce que quelqu’un avant le client lui-même doit valider le travail ne serais-ce que vous-même). Une fois ces dates déterminées, regardez combien de temps il reste entre la date de départ du projet (aka «kick-off») et la date pré-finale et soustraire 20% de temps qui servira à l’assurance qualité et/ou les petits imprévues de parcours (Eh oui, il y en aura!). Le nombre obtenu est le nombre de jour de production réel (selon votre âge, avec ou sans les weekends!). Exemple :

  • Livrable final : 1er juin
  • Pré-final : 25 mai
  • «Kick-off» ou départ : 1er mai
  • Production réel 24 jours moins 8 pour les weekends =  16 jours ouvrables pour le projet
  • 16 jours – 20% = 3.2 jours arrondi à 3 jours pour l’assurance qualité
  • Il reste donc 13 jours de production réel par individu pour ce projet

Donc sur 30 jours (1 mois) il reste moins que la moitié de jours pour produire. Il faudra donc que le projet entre dans 13 jours, quitte à impliquer d’autres personnes, si on vise une livraison dans les temps.

Rehaussez le plan minimum

Une fois le plan minimum clair établie, on doit analyser le projet à faire selon les spécifications fournies. Décomposer les tâches en tâches de 8 heures maximum. Une échelle simple pour l’évaluation des tâches : 1 heure, 2 heures, 4 heures ou 8 heures. Si une tâche prend plus de 8 heures, elle peut assurément être décomposée en 2 tâches ou plus. Ça paraît pire que ça ne l’est réellement. C’est assez rapide de décomposer un projet. Si ça devient compliqué, révisez un peu l’ampleur du projet, c’est souvent signe qu’en y réfléchissant bien, celui-ci va prendre beaucoup plus de temps que prévu. Quand toutes les tâches sont énumérées, on peut les distribuer aux membres de l’équipe et proposer des dates «milestones» intra-projet. Ça aide toute l’équipe à anticiper ce qui doit être livré et ce qui s’en vient.

Toutes les tâches prennent 2 heures

Malheureusement non! Mais une fois sur deux je rencontre ce type de personne qui évalue tout, toujours, au même temps. Qu’il s’agisse de changer une image sur le site ou d’écrire une fonction complexe avec JavaScript, ça prendra toujours 2 heures. Ces personnes sont à surveiller au quotidien. Elles ne sont pas de mauvaise foi mais pour certains, les évaluations… C’est gênant. Comme si c’était inimaginable qu’une tâche puisse prendre 8 heures… Je veux dire, «Come on» je suis plus hot que ça quand même!

Faire des maquettes pour tout, tout et tout

Je sais c’est chiant. Le designer va tellement rouler des yeux qu’il aura mal aux orbites. Dans 100% des projets que j’ai vécu, une page qui a dû être intégrée sans maquette (et je ne parle pas de Responsive Web Design) prend 2 fois plus de temps, au final, à mettre en ligne. Les seuls pouvant dire le contraire sont les designers qui sont également les intégrateurs. S’il s’agit de 2 personnes différentes dans votre entreprise, faites toujours des maquettes pour tout, tout et tout. Pour l’avoir testé plusieurs fois : 1 minute de modification Photoshop/Illustrator prendra 10 minutes en intégration à se rendre en staging.

Abandonnez le Lorem Ipsum dans les maquettes

Les contenus finaux vont être différents alors faites attention avec l’approbation des visuelles sur faux-texte. Par expérience, seuls les «wireframes» peuvent être en faux-texte. Ensuite, à l’étape de la maquette, il faut avoir les textes finaux (une façon détournée de forcer votre client à les produire avant la veille de la mise en ligne). Si vous travaillez sur un visuel bilingue anglais et français, préférez la version française car le compte de mot sera environ 20% plus long. Sinon, certaine page au final pourraient être à refaire à cause du format des contenus exemple : titres avec sous-titre avec un tableau ou une liste numérique non imaginés par le designer va causer des tracas au développeur ou à l’intégrateur, qui sont souvent une autre personne que le designer et/ou moins à l’aise avec la prise de décisions graphiques.

«Freeze!»

Le «code freeze» au minimum 3 heures avant la présentation au client. Sans «code freeze» on se ramasse à faire des correctifs à 14h50 pour la présentation de 15h00 et devinez quoi? C’est à ce moment que la routine de déploiement vous lâche… TOUJOURS! Le client n’a pas plus de temps libres que vous alors soyez respectueux. Au pire, faites un «code freeze» officiel sur votre domaine (exemple http://staging-stable.votredomaine.com) pour le client et continuez à faire des correctifs sur un autre domaine (exemple http://staging.votredomaine.com) et si la routine de déploiement ne vous lâche pas, vous présenterez sur ce domaine… Mais la routine va TOUJOURS vous lâcher.

2 commentaires

  1. Super article Hugues!

    Je n’avais pas du tout pensé à faire les Scrum le midi, peut-être que ça aurait pu être plus productif effectivement! Sinon tous tes conseils sont très d’actualité.

    Good job!

    1. Merci David, c’est très apprécié. Effectivement vous pourriez essayer ça. C’était une suggestion d’une firme Agile chez qui je faisais un mandat et qui avait exigée ça… Moi je suis entré c’était en place mais je voyais que les gens avaient beaucoup plus de choses à dire et c’était frais à leur esprit.

Commentez cet article

Votre adresse courriel ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Articles reliés