Ecrire les spécifications d'un projet, ici web, pour le chef de projet n'est pas un exercice facile. Il faut trouver un juste équilibre entre la qualité et la quantité des informations à fournir en prévoyant pour cela de nombreux cas et en envisageant tous les cas que l'on n'a pas pu prévoir. Avant de rédiger ces spécifications techniques et/ou fonctionnelles, il faut auparavant recueillir toute une série d'informations de multiples personnes.

Recueillir ces informations et parfois ces "révélations" demande un certain temps en amont. Voici selon moi quelques éléments qui peuvent permettre de s'assurer de ne rien oublier avant d'écrire le cahier des charges et de répondre ainsi à tous les besoins...

L'effet d'ancrage (ou anchoring bias en anglais) est l'utilisation de valeurs passées dans l'estimation d'une nouvelle valeur. Il a été mis en évidence par Amos Tversky et Daniel Kaheman dans leur article de 1974, "Judgment under Uncertainty: Heuristics and Biases". Il intervient principalement lors d'une estimation numérique lorsque le sujet met en place une heuristique, c'est à dire que la réponse n'est pas connue à l'avance et que la personne conduit un raisonnement.

Par exemple, Tversky et Kaheman ont demandé à deux groupes de personnes d'estimer le nombre de pays du continent africain au sein de l'ONU. Au groupe A, il est demandé si 10% est une valeur inférieure ou supérieure à ce nombre puis le groupe doit fournir son estimation. De même avec le groupe B avec une valeur initiale de 65%. Résultat : le groupe A conclue à 25% et le groupe B à 45%.
Je ne sais pas si vous avez déjà constaté cet effet mais pour ma part je l'ai déjà expérimenté sur les points suivants...

Avoir des idées est une chose, pouvoir ou savoir les réaliser en est une autre. Partant de cette observation Scott Belsky et son réseau Behance ont étudié les meilleurs créatifs afin de savoir comment depuis leur idée de départ, ils avaient su les concrétiser et mener à bien leurs projets. C'est dans son livre "Make Ideas Happen" qu'il expose l'analyse de ses observations.

Ce livre très riche de témoignages de qualité et de conseils pragmatiques alimentera de nombreuses citations sur le site mais ici je voulais revenir sur une méthode décrite et préconisée par Belsky pour ne rien perdre de ses idées. Cette méthode c'est l' "Action method" et celle-ci s'applique particulièrement bien à la gestion de projet.

Elle part du principe qu'un projet s'organise autour de trois éléments principaux :

La gestion des développements postérieurs à la livraison d'un projet est assez problématique et source de conflits entre ses différents acteurs.
Je présente ici deux solutions que j'ai expérimenté et qui ont permis selon moi de solutionner et de faciliter les choses dans la gestion des développements et l'allocation des personnes.

Mais tout d'abord mettons-nous d'accord sur le vocabulaire qui sera utilisé tout au long de cette réflexion:

En dehors de laBonneCitation.com, je suis chef de projet web dans une start-up. Un métier que j'apprends au fil de mes expériences avec au départ une légère formation académique du sujet.

Un métier aussi très concret au jour le jour mais bien difficile à expliquer quand on se voit poser la fameuse question "Mais en fait tu fais quoi ? J'ai pas bien compris...". Pour réponse, redirigez-les vers l'article "Comment parler à un chef de projet" sur le site de Capitaine commerce qui décrit bien ce métier et ses facettes.

Ici, tout autre chose, je tenais à partager les outils pour moi essentiels en management de projet web et que j'utilise tous les jours.