reunion de specification

Spécifications fonctionnelles: La validation

Publié le

Après une plus ou moins longue phase de spécifications fonctionnelles, vous avez pondu seul (comprendre sans le client) une doc de spécifications fonctionnelles et vous n’avez qu’un seul but: Que le client le signe!

Et là, je vous dit Attention aux fausses idées !

Déjà, ne vous croyez pas intouchable avec ce document. Bien souvent, le prestataire se cache derrière ces spécifications. Il a tendance à braquer ce document tel un arbitre de foot avec son carton rouge: c’est écrit dans les spécifications vous l’avez signé, l’affaire est clos…

Il n’est pas rare d’avoir un client qui signe ce document sous la contrainte, ou pire pour cacher son incompétence. Ce dernier point n’est pas péjoratif, il est important de vérifier si votre interlocuteur possède les qualifications requises pour réaliser cette tâche.

Je préconise la mise en place, systématique, d’un atelier de relecture des spécifications avec le client.

Publicités

Les jalons d’un projet informatique

Publié le Mis à jour le

Voici en détail les jalons d’un projet informatique de développement côté prestataire.

  • Réunion de lancement
    Le démarrage officiel du projet, sous forme d’une réunion où l’ensemble des participants au projet (le comité projet) sont conviés. La réunion est orchestré par le chef de projet (ou directeur) et se déroule généralement en trois phases (les présentations (société, personnes et projet) , le déroulement du projet et le planning).
  • Validation des spécifications
    La première phase du projet est constituée des spécifications techniques et fonctionnelles. Leurs validations par les deux parties (client et prestataire) sont contractualisées au travers d’un document de spécifications. Cette étape démarre le processus de production côté prestataire, et, bien souvent une clé de facturation.
  • Validation de la charte graphique
    En parallèle des spécifications, la charte graphique est générée. Il est impératif d’arrêter une version afin de l’intégrer dans le développement, un procès-verbal acte ce travail.
  • Installation en pré-production
    Début de la Vérification Aptitude du Bon Fonctionnement officialisé par le procès-verbal de livraison. Le livrable est installé sur l’environnement de pré-production.
  • Validation de la VABF (Vérification d’Aptitude du Bon Fonctionnement)
    Au terme de la phase de recette, le client est satisfait (sisi cela arrive !) du livrable et valide la recette en signant le procès-verbal de recette. La recette est un temps fort du projet, elle doit être bien cadrée et délimitée dans le temps.
  • Installation en production
    Détermine le passage du projet de la recette à la production. En terme de phase de projet on passe de la VABF à la VSR. Attention, il ne faut pas confondre avec la mise en production effective du projet par le client. Avant cette ouverture, il est nécessaire d’effectuer certaines tâches, comme un accompagnement et une saisie d’information initiale.
  • Validation de la VSR (Vérification du Service Régulier)
    Il faut s’assurer que le livrable est procure un service régulier dans les conditions normales d’exploitation. Des tests de montée en charge peuvent être exécutés.
  • Fin de la garantie
    La période de garantie n’est pas obligatoire, mais très souvent présent dans un projet au forfait. La fin de cette phase met un point final au projet. Il peut s’étendre par un contrat de tiers maintenance applicative.

Gestion de projet – étape #2: Les spécifications fonctionnelles

Publié le Mis à jour le

La phase de spécification permet de décrire le besoin fonctionnel (également technique) dans le but d’élaborer un projet.

C’est le temps fort du projet vis à vis du client, le moment où vous devez démontrer vos talents d’homme communiquant. A ce stade du projet, il est impératif que vous ayez une parfaite connaissance du projet – vous avez lu et relu le CCTP -, et vous avez déjà quelques idées de réponse à apporter, voir pourquoi pas,  des pistes d’amélioration.

Il faut absolument déjouer les pièges, tout de suite !
Après il sera trop tard pour revenir en arrière et le client acceptera moins facilement ce changement. Non pas qu’il faille répondre « NON » à toutes les demandes, qu’elles soient implicite ou non au cahier des charges – Là n’est pas la question -. Mais plutôt d’atteindre le même résultat par un chemin plus simple ou bien de démontrer que la fonction demandée n’est pas réellement utile.

«  Souvenez vous, les solutions les plus simple sont toujours les meilleurs « .

Votre rôle sera surtout de vous assurez que ce qui a été vendu (voir sous-vendu) est finalement réalisable. Pour éviter les risques et les surprises, je conseil au chef de projet d’être présent dans le projet dès la phase d’avant vente.

Gardez en mémoire que seulement 45% des fonctionnalités demandées sont réellement utilisées.

Afin d’éviter tout malentendu sur ces fameuses fonctionnalités, je vous conseille de les illustrer au maximum par des schémas. Pour expliquer une solution attendue, une copie d’écran ou un croquis vaut tous les longs discours. Et si vous en avez la possibilité, appuyez votre discours par une démonstration.