Partie 2: Vos besoins et SharePoint

Partie 2: Vos besoins et SharePoint


The value of an idea lies in the using of it.

Thomas A. Edison

La première étape dans tout projet, peu importe sa nature, est de définir son utilité en réponse à un ou plusieurs besoins. En effet, si un système ne répond à aucun besoin, alors à quoi peut-il bien servir?

Une gestion de projet sans analyse (source non identifiée)

Cette étape est, à mon sens, la plus importante et ne doit en aucun cas être négligée. Si vous arrivez à identifier précisément le travail à faire correspondant à la réalité des attentes (et donc la résolution du besoin), alors vous aurez complété la moitié de votre projet. Toutefois, il est souvent difficile de formuler un besoin, aussi bien du côté d’un client que d’un fournisseur, car il y a parfois décalage entre ce qui est dit et ce qui est compris. Heureusement, il existe des outils et techniques permettant de réaliser cette étape efficacement.

Situons-nous dans le contexte d’un fournisseur devant répondre à une demande d’un client. La méthode que je présente ici est basée sur les méthodologies agiles, dont il sera important d’en comprendre les concepts. Pour en savoir plus sur la méthodologie agile, visitez le scrum.org.

Qu’est ce qu’un besoin?

Tout d’abord, commençons par résumer ce que représente un besoin dans le cadre d’un système informatique:

Dans le cadre d’un système, un besoin représente la traduction d’une nécessité fonctionnelle constituant un gain relatif pour la personne qui en fait l’expression.

Gardez-cela à l’esprit, lorsque l’on parle de besoin, on parle nécessairement de VALEUR. La valeur peut être soit tout fait objective ou, au contraire, très subjective. Néanmoins, elle doit toujours motiver le besoin. Un besoin n’est lié à AUCUNE technologie. Ce genre d’exercice ne devient donc pas obsolète dès lors que vous changez de technologie. Les solutions peuvent changer, les besoins, eux, restent.

Le besoin et le moyen, l’histoire de SharePoint…

Faisons d’abord un constat : au fur et à mesure des différents projets SharePoint sur lesquels j’ai eu l’occasion de travailler, j’ai souvent constaté que le moyen conditionne le besoin. En effet, certaines personnes réfléchissent inconsciemment de la manière suivante :

« J’ai vu, à un endroit X ou Y, que SharePoint offrait telle ou telle fonctionnalité, il faut donc que je trouve un besoin pour pouvoir l’exploiter »

Une sorte de soulagement de conscience d’avoir utilisé ladite fonctionnalité disons… On peut aisément comprendre cette réaction, car en acquérant SharePoint, on obtient un produit complet avec son lot de fonctionnalités et cela peut s’avérer frustrant de ne pas pouvoir l’utiliser à ses pleines capacités. Un directeur TI n’appréciera pas vraiment que la plupart des possibilités du logiciel qu’il s’est procuré ne soient pas exploitées. Certes, cela ne signifie pas que nous devons nous créer des besoins en fonction de l’outil (ou comment faire rentrer un carré dans un rond).

SharePoint, nécéssairement le bon outil?

Pour comprendre ce phénomène, il est intéressant de se pencher sur la manière dont SharePoint est généralement amené en entreprise. Très souvent, il est issu d’un choix technologique imposé dès le début d’un projet sur la base de grands domaines génériques comme :

  • La gestion électronique de documents
  • La gestion de contenu
  • Les réseaux sociaux d’entreprises
  • Etc.

D’un point de vue macroscopique, SharePoint se positionne comme l’outil idéal dans ces domaines, présentés par l’intermédiaire de plaquettes marketing (Microsoft ou autres firmes expertes), d’articles de blogues, etc., qui vous donnent un aperçu ce de que pourrait vous amener l’outil dans un contexte (trop) souvent générique. Le problème est que ce choix est souvent fait avant même de connaître les besoins réels des utilisateurs. En effet, qui vous garantit que SharePoint est le bon outil pour vos besoins? Pourquoi ne pas utiliser un autre outil, ou même une solution entièrement développée de A à Z? Si vous vous trouvez dans cette situation, vous faites un pari en faisant confiance à ce que vous avez pu voir. Ceci n’est pas nécessairement mauvais, mais il vous faudra observer quelques règles…

Préférez la lecture d’articles orientés « Business » ou présentant des cas d’utilisation pratiques pour vous donner une idée de ce que SharePoint peut accomplir et éviter les mauvaises surprises ;).

SharePoint + vos besoins = compromis

Il faut bien comprendre que le choix de SharePoint peut aussi bien vous faire gagner du temps que de vous en faire perdre. Tout est une question de besoins. En effet, SharePoint, à l’inverse de solutions entièrement personnalisées (où le choix d’une technologie en début de projet avant même l’analyse de besoins n’impactera que très peu la réalisation), ne pourra répondre à 100% de vos besoins. Il sera question alors de compromis.

Le besoin doit conditionner le moyen, jamais l’inverse. Intervient alors une zone d’équilibre qui représente les compromis faits entre les possibilités de l’outil et vos besoins réels. Voici une illustration de cette zone d’équilibre. Le but est de se trouver aux alentours du croisement entre ce que SharePoint peut faire et ce que vous avez réellement besoin.

 Si vous apportez beaucoup de modifications à l’outil de base par des développements personnalisés, c’est peut-être que SharePoint n’est pas le bon système ou que vous ne traitez pas le besoin fondamental en arrière.

 En revanche si vous vous efforcez d’utiliser toutes les fonctionnalités de SharePoint, alors peut-être vous détournez-vous de vos besoins réels et êtes-vous en train de développer une solution non-adaptée.

Zone d'équilibre Besoins/Moyens

De mon avis personnel, une des raisons de la non-adoption de la plateforme par les utilisateurs est souvent liée à une implémentation trop éloignée de la réalité de leur travail quotidien. Il y a souvent une grosse différence entre les plaquettes commerciales de Microsoft™, les articles de blogs théoriques et la réalité des utilisations de l’outil dans le milieu professionnel. En résumé, voici en quoi devrait idéalement consister les étapes d’un projet SharePoint:

Processus idéal de gestion de projet avec SharePoint

SharePoint et le mode « patch »

Comme nous l’avons vu précédemment, le choix technologique, bien qu’il ne doive pas être effectué à cet instant, est très souvent imposé en début de projet, encore plus avec SharePoint.

Avant la réalisation, il est très rare qu’un client vous arrive avec déjà un carnet de produit priorisé et des besoins formalisés. La plupart du temps, il vous arrive avec une liste de « Quoi», sans le « Qui» ni le « Pourquoi» :

Par exemple, voici des requis pour le projet « Mon super Intranet »

  • Bottin d’entreprise
  • Petites annonces classées
  • Le mot du président
  • Moteur de recherche
  • Bilinguisme
  • Site de gestion des projets
  • Etc…

On constate qu’il est impossible de donner ça tel quel à une équipe de réalisation sous peine de grosses divergences d’attentes…

Note   Ceci est un cas extrême.

Voici un exemple d’étapes d’un projet avec SharePoint que l’on rencontre fréquemment :

Processus réel de gestion de projet SharePoint

On observe généralement deux phases distinctes:

La pré-livraison

Intervenant pendant la réalisation du projet.

La liste des fonctionnalités données est souvent trop floue et bien souvent orientée vers la technique. L’équipe de développement doit donc :

  • Régulièrement demander au client des précisions sur la fonctionnalité à implémenter (fonctionnement, détails, etc…) ce qui entraîne des allers-retours très couteux en temps (surtout si le client est peu disponible).
  • Implémenter la fonctionnalité selon ses propres choix fonctionnels, le risque étant que celles-ci ne correspondent pas au besoin.

La post-livraison

Intervenant après la livraison du projet.

Les fonctionnalités ne correspondent pas à la réalité des utilisateurs. Ici, deux causes possibles :

  • Les fonctionnalités n’ont pas été assez détaillées par le client et les choix de l’équipe de développement ne correspondent pas aux attentes des utilisateurs.
  • Les utilisateurs eux-mêmes n’ont pas étés impliqués suffisamment dans le processus de développement. Manque de feedback pour ajuster les besoins et donc obligation de corriger.

Il sera donc indispensable d’appliquer des « patchs » successifs d’améliorations pour correspondre à la réalité d’utilisation ou aux spécifications.

Une question de point de vue…

Mais soyons réalistes: plus les entreprises sont volumineuses, plus les habitudes de gestion ont la vie dure. Il peut donc sembler utopique de supposer un changement radical de processus ou de méthodologie. Toutefois, il est possible de trouver une alternative entre la vision idyllique et la réalité du déroulement d’un projet SharePoint. Cependant, il va falloir batailler quelque peu ;).

Ne nous le cachons pas : faire une bonne définition de besoins prend du temps, beaucoup de temps, et celui-ci n’est souvent pas inclus dans les budgets. De même, cela demande beaucoup d’implication du coté de votre client.

Il va donc falloir lui expliquer plusieurs choses :

  • Qu’il faudra reprendre du temps au début de son projet pour « reformater » ses besoins en quelque chose de plus exploitable pour les équipes de développement. Tout le temps requis pour faire cela sera pris sur le temps de réalisation potentiel inclus dans son budget si il ne l’a pas prévu.
  • Que lui ou ses équipes devront être disponibles et impliqués pour définir les besoins et en expliquer le fonctionnement.
  • Que le temps alloué à cet exercice permettra de réaliser une solution qui répondra PRÉCISEMENT à ses besoins impliquant moins de modifications futures et une meilleure vision globale. Le temps « perdu » au début vous fera au final économiser.

Asini, une gestion de projet alternative peut exister:

Processus alternatif de gestion de projet SharePoint


1 comment

Add yours

+ Leave a Comment