Réponse.

Historiquement, l'évaluation de l'effort était basée sur des évaluations d'experts ou par analogie avec des projets précédents. Dans un contexte de temps et d'informations limités, l'analyste système est contraint de travailler avec des exigences de haut niveau, floues, rencontrant souvent des lacunes et des attentes démesurées.

Problème : l'incertitude entraîne des risques de sous-estimation, des conflits avec le client et l'équipe technique, ainsi qu'un dépassement de budget. L'évaluation est très compliquée en raison des changements dans les données de base après la signature du contrat.

Solution :

Utiliser des techniques de décomposition des exigences et des tirages rapides (planning poker, taille de T-shirt)
Identifier et documenter toutes les hypothèses et limitations
Tenir un protocole des questions et des zones inconnues
Inclure une marge de risque (coefficients d'incertitude/buffers)
Le plus important - fixer les critères d'achèvement (Done) et les conditions limites

Caractéristiques clés :

Artefacts courts : scénarios de haut niveau, user stories, diagrammes C4
Visualisation des principaux flux de valeur
Accent sur les prototypes et les wireframes pour parvenir plus rapidement à un accord

Questions pièges.

Peut-on effectuer une évaluation sans risquer la qualité, si les exigences ne sont pas encore complètement clarifiées ?

Non, toute évaluation à ce stade devra être marquée comme préliminaire avec enregistrement des risques et des réserves. Sinon, la responsabilité du dépassement de budget incombera à l'exécutant.

Faut-il inclure dans l'évaluation uniquement les objets clairement définis par le client ?

Non. Tout ce qui n'est pas défini est évalué via un "buffer d'incertitude" ou des Story Points spéciaux pour des clarifications futures ; il est important de préciser : « les autres exigences sont hors évaluation ».

L'analyste système doit-il participer à la préparation du TCO (coût total de possession) ?

Oui, l'analyste forme les données de base - la liste des exigences, le répertoire des scénarios, les zones de risque, les contraintes, ce qui est crucial pour un calcul correct du TCO.

Erreurs typiques et anti-patrons

Évaluation du projet "de façon brute" sans tenir compte des zones d'incertitude
Ignorer les changements possibles après le démarrage de la mise en œuvre
Ne pas enregistrer les hypothèses et les limitations par écrit

Exemple de la vie

Cas négatif : L'analyste système a accepté les exigences du manager "telles qu'elles sont", les a évaluées rapidement, sans entrer dans les détails et sans examiner les limitations et les zones cachées.

Avantages :

Rapide, pratique pour le client

Inconvénients :

Dépassement de budget, mécontentement du client et de l'équipe
Refactorisation des solutions et les délais sont en "urgence" dès le début

Cas positif : L'analyste a conduit une session de travail avec les principaux parties prenantes, a même travaillé sur les exigences générales, a dressé une carte des zones d'incertitude, a indiqué les hypothèses, a introduit une réserve.