mercredi 13 mai 2009

Projet informatique, définition des besoins par la discussion permanente

Tout projet informatique démarre par une phase d'expression des besoins qui sont recueillis auprès des futurs utilisateurs, ou d'un panel (groupe de travail). Ces besoins sont ensuite formalisés sous la forme d'un document de synthèse dit de définition des besoins.

C'est à partir de ce document qu'un certain nombre d'actions vont être conduites pour valider la pertinence, la faisabilité, le dimensionnement budgétaire. Dès lors que ces grandes lignes sont arrêtées, le projet va pouvoir entrer dans une phase de spécifications (détaillées) des besoins qui débouchera sur des choix technologiques, une procédure d'appel d'offres, des développements...etc.

Autant dire que cette phase initiale est primordiale car la moindre fonctionnalité oubliée peut avoir des répercussions très importantes au final. Cette phase est en général réalisée au travers d'interviews, d'ateliers de travail à plusieurs... qu'il faut ensuite synthétiser, valider, amender. Cette période peut générer un volume très important d'échanges (téléphone, emails...) dès lors que les utilisateurs impliqués se prêtent au jeu. Pour autant, hors des exercices imposés d'interviews ou d'ateliers, il n'y a pas forcément une émulation continue autour du sujet. Chacun est à ses tâches. Et il est préférable d'éviter de louper les réunions validant les avancées des travaux car ce sont les seules occasions où l'on peut prendre du recul et intervenir pour faire valoir son point de vue.

Il me semble qu'il serait pertinent d'accompagner cette étape d'un support on-line (une plate-forme conversationnelle) permettant aux acteurs impliqués de pouvoir spontanément mettre en ligne des points, suggestions, idées... qui leur tiennent à coeur et pour lesquels ils souhaiteraient éviter de les oublier en attendant la prochaine réunion physique (d'autant que c'est le genre d'idées qu'on a tendance à noter sur un post-it qui peut rapidement partir à la poubelle lors d'un nettoyage...). Dès lors, tous les participants auraient accès à cette information et pourraient la valoriser (commentaire, vote). L'équipe en charge de la formalisation des besoins disposerait d'apports multiples et divers, valorisés selon l'appréciation des autres utilisateurs. Plus simple dans ce cadre d'intégrer au document final les points importants et d'informer en temps réel les utilisateurs la bonne prise en compte (ou le refus motivé) de telle ou telle suggestion.

Bien entendu, cette étape doit impérativement être strictement limitée dans le temps.
Les solutions existent qui peuvent être opérationnelles en quelques jours à peine.



2 commentaires:

  1. Salut JB,
    Dans l'ensemble des sociétés dans lesquelles j'ai travaillé (de très grosses sociétés), le processus est plus complexe. Il y a la rédaction d'un cahier des charges, suivi d'une étude qui permet à ce moment de définir dans les grandes lignes les solutions et les choix technologiques. Des outils permettent de vérifier qu'aucune exigence du client n'a pas été oubliée. C'est par la suite que les spécifications générales sont élaborées (puis les spécifications détaillées et autres dossiers d'architecture technique ...) et validées par le client. Ce processus permet de ne pas subir l'effet 'tunnel".
    En ce qui me concerne, je demande que le client désigne un référent unique avec qui je puisse dialoguer tous les jours (mail, téléphone, réunion ...).
    L'expérience démontre qu'il faut un mode push, aussi bien côté maitrise d'oeuvre que maitrise d'ouvrage générale (client) et maitrises d'ouvrage associées. Il faut dynamiser les équipes et les responsabiliser.
    Personnellement, je trouve que les outils classiques (mail, téléphone, réunion ...) permettent de remplir la mission confiée par le client. Ce ne sont pas les outils mais le degré d'implication de chacun qui permet la réussite des projets à ce niveau.
    Reste à également à remercier les participants et à les valoriser pour renouveler une nouvelle aventure dans les meilleures conditions.
    Mon récit s'applique sans doute aux grosses structures et tu as sans doute raison si la structure est plus jeune et les projets moins importants.
    Désolé si je suis hors sujet ;-)
    A bientôt !
    Thierry 9149c

    RépondreSupprimer
  2. Salut Thierry (t'as pris un nom bizarre ;-) ça fait plaisir de te lire par ici.
    Pour te répondre : je n'ai pas voulu détailler complètement la chaîne de gestion de projets pour essayer de faire simple. Je comprends ce que tu dis, mais je reste convaincu que c'est une vue côté IT. Cela ne correspond pas toujours à la satisfaction des "End users", surtout quand ils ont un peu de mal à suivre les méthodologies des spécialistes de la formalisation.
    Le fait de pouvoir disposer d'une discussion continue, mais organisée grâce aux nouvelles possibilités de partage et de capitalisation, permet justement à chaque partie de pouvoir se sentir plus à l'aise et facilite l'implication de tous. D'autant qu'on optimise "la somme des parties vaut plus que la valeur unitaire", et que faire reposer l'interface sur un correspondant unique le met forcément dans une situation de responsabilité importante.
    Je pense au contraire que cela présente un intérêt de développer ce genre d'approches dans les grosses structures.

    RépondreSupprimer