Les exigences idéales reviennent

Dans les parties passées

Dans la première partie, j'ai annoncé une série d'articles sur le travail de l'analyste dans l'avant-projet. Il répertorie les problèmes, les solutions et les principes dont vous devez vous souvenir lors du démarrage d'un projet informatique.

Dans la deuxième partie, j'ai parlé des problèmes fréquents de l'avant-projet.

Dans le dernier article, nous avons discuté de la première partie des principes de base:

• La conception de systèmes informatiques et la classification des produits informatiques.
• Niveaux du modèle en V et cycle de vie du système.
• Un regard sur le système comme un actif financier.

Dans cette note, nous terminerons par une description du «comment faire», pour discuter davantage de ce qu'il faut faire si cela ne fonctionne pas correctement.

Ce que vous apprendrez de cette note:

• Au cône des phases d'incertitude et de conception.
• À propos du fonctionnement de l'évaluation.
• Sur l'étendue complète des tâches de la phase d'avant-projet et les valeurs réalisées en même temps.
• Comment obtenir suffisamment de ressources pour un avant-projet.

Si vous ne voulez pas attendre les prochaines parties du cycle, vous pouvez regarder la vidéo de mon rapport, sur la base de laquelle cette série d'articles est écrite.

Cycle de vie du système et cône d'incertitude

Le cône d'incertitude est l'un des concepts centraux de la conception et de la gestion de projet moderne. L'essence du concept: moins nous avons d'informations, plus grande est l'incertitude qui peut s'exprimer sous la forme d'une répartition des termes et du coût du projet.



Chaque phase de construction d'un système supprime une partie de l'incertitude. Lorsque vous passez par des phases typiques d'un projet, l'incertitude diminue de façon exponentielle:

• Lorsque nous avons une idée exprimée dans un mémoire d'une demi-page, la répartition des coûts et des retours peut atteindre plusieurs ordres de grandeur.

• Lorsqu'il y a des besoins commerciaux, tandis que le plan d'affaires ou le modèle d'affaires est développé, nous réduisons la dispersion des coûts / retour sur commande.

• Pour réduire davantage la propagation, vous devez prendre des décisions clés sur l'apparence et la conception du système. Cette étude réduit l'écart de moitié. Malgré le fait que l'écart est toujours important, une analyse de la relation entre les rendements et les coûts donne la décision principale - si nous allons construire un système ou chercher quelque chose de plus rentable.

• En spécifiant les conditions dans lesquelles le système sera construit (qui le fera et dans quel délai), nous pouvons réduire la répartition des coûts à des valeurs qui peuvent être utilisées par les méthodes de gestion de projet, la constitution de réserves et la gestion des risques. Les conditions spécifiées sont enregistrées dans l'énoncé des travaux.

• Seule la conception technique fournit une estimation presque précise avec une erreur acceptable pour l'entreprise.

Ce qui en découle:

• Du point de vue de l'allocation des ressources, nous devons avoir le temps de réduire le projet avant d'avoir dépensé une part importante des coûts s'il a cessé d'être rentable. Les phases allant du dossier à la conception technique devraient occuper une petite fraction du coût total du système.

• Vous devez également comprendre que vous ne pouvez pas proposer une idée et fixer immédiatement le coût. Quand on vous dit qu’il y en a 20 millions ici et c’est sûr, n’ayant qu’un bref - ne le croyez pas, ce n’est pas le cas.

• Les exigences commerciales et le développement conceptuel doivent être effectués, car ils éliminent l'incertitude, mais cela peut ne pas se poursuivre si le projet ne démarre pas. Par conséquent, les phases devraient être aussi bon marché que possible, mais elles devraient lever l'incertitude de manière qualitative.

Comment fonctionne l'évaluation?

Il existe une idée fausse commune qui empêche le lancement normal des travaux d'avant-projet: si nous ne pouvons pas fournir rapidement une évaluation précise, nous ne devrions pas du tout nous soucier des exigences. Ce n'est pas vrai. La somme d'estimations inexactes, plus précisément, est un fait de la théorie des probabilités.



Dans ce cas, l'étude de pré-conception devrait donner une division du système et du plan de travail en plusieurs dizaines de parties comparables, et l'évaluation de chaque partie devrait être effectuée par analogie ou par une méthode plus précise. La somme des notes aura un écart plus petit que chaque note individuelle.
Si la qualité de l'étude conceptuelle ne nous permet pas d'obtenir une division du système en parties acceptables pour l'évaluation, alors nous ne réduisons pas la dispersion de l'évaluation et il est inutile de se connecter à une telle étude.

Les phases du projet du point de vue du mode d'évaluation sont les suivantes:

• Lorsqu'une idée est exprimée dans un mémoire d'une demi-page, nous pouvons évaluer par analogie.

• Lorsque nous avons défini les exigences commerciales, le plan d'affaires ou le modèle d'entreprise, nous pouvons mettre en évidence les paramètres clés du système et effectuer une évaluation par analogie à l'aide d'un facteur à grande échelle.

• Le concept se décompose en plusieurs dizaines de pièces et travaux, ce qui permet de résumer les estimations faites par analogie et de calculer le plan de gestion des risques clés.

• Le mandat remplace l'évaluation des parties du système par analogie avec les obligations des fournisseurs par type de travail. Les estimations de pièces faites par analogie sont converties en estimations d'experts. Les risques d'erreur dans l'évaluation sont répercutés sur les fournisseurs.

• La conception technique permet de diviser le système en centaines et milliers de parties, chacune étant évaluée de manière experte ou à l'aide de statistiques sur la mise en œuvre des projets précédents.

Si l'essence décrite ci-dessus n'est pas posée dans le travail de pré-conception, il vaut mieux ne pas le faire. Pour parvenir à une réelle réduction de l'incertitude, il est nécessaire non seulement d'augmenter l'épaisseur du paquet de documentation pour le système, mais également de s'assurer que des exigences et des solutions mesurables et réalisables y sont énoncées.

Une autre idée courante est: «Les exigences commerciales ne doivent pas être mesurables.» Rappelez-vous - c'est un mensonge!

Ce que vous devez réaliser dans l'avant-projet

Dans les parties précédentes, cela a été mentionné en termes de problèmes. Répétez maintenant brièvement les tâches à définir et à terminer dans tout avant-projet:

1. Comprendre le temps et les coûts afin de planifier les coûts et de prendre une décision de départ / non. Il est conseillé de prévoir l'effet et le retour pour accélérer cette décision.
2. Pour vendre le système:
   
   
   • Montrez au client une compréhension de ses objectifs.
   • Montrez aux utilisateurs la solution à leurs problèmes.
   • Terminez avec succès l'appel d'offres pour le budget (il est toujours là).
3. Pour créer une base d'acceptation (un contrat pour le volume et la qualité du résultat est une tâche technique), n'oubliez pas de mettre dans le plan la validation du système résultant du point de vue de la justification pratique des attentes de toutes les parties.
4. Décidez des ressources: types, étapes, échéanciers, volumes de travail et sources de ressources pour confirmer les estimations des interprètes et fixer le coût du système.

Si de telles tâches ne sont pas définies explicitement et que leur solution n'est pas planifiée, il vaut mieux ne pas perdre de temps du tout - ce projet ne peut réussir que par accident.

Pourquoi cela peut ne pas fonctionner (ou ne peut même pas) fonctionner

À la suite de toutes les considérations précédentes, nous avons 3 conditions contradictoires:

1. L'analyse préalable à la conception doit être effectuée rapidement.
2. L'analyse préalable à la conception doit être effectuée à moindre coût.
3. L'analyse de préconception doit être effectuée qualitativement.

Ceux qui connaissent la règle du triangle de conception comprennent que cela ne se produit pas.

Il y a quelques difficultés supplémentaires:

1. L'analyse d'avant-projet peut montrer un faible retour sur la solution proposée, et cela ne sera pas intéressant pour le client et le sponsor.
2. Une analyse d'avant-projet peut augmenter le volume du projet ou le coût total de possession par rapport aux hypothèses initiales, ce qui redeviendra sans intérêt pour le client et le sponsor.
3. L'analyse d'avant-projet peut réduire le volume du projet par rapport aux hypothèses initiales, ce qui n'est souvent pas intéressant pour le contractant externe.

À propos de toutes ces difficultés, je veux que vous et moi comprenions une chose: les problèmes de l'avant-projet sont insolubles si nous ne nous rangons pas du côté du sponsor et ne considérons pas le projet informatique comme un actif financier.

Dans les commentaires sur l'article avant-dernier, l'avis a été exprimé: «L'avant-projet doit être ouvert le plus tôt possible, mais il convient de garder à l'esprit que la portée de l'avant-projet est limitée par son efficacité. Un tel avant-projet est considéré comme efficace, après quoi le projet sera lancé. Il s'agit du principal indicateur clé de l'efficacité de l'avant-projet. » (c) WizardryIB

C'est un point de vue assez courant chez les chefs de projet, car si quelque chose vous est confié, vous devez vous suicider, évincer une équipe jusqu'à la dernière goutte, tourner les bras vers les fournisseurs avant de casser, violer le client, mais atteindre l'objectif.

En revanche, si le chef de projet ferme son propre projet, il réduira son propre lieu de travail.

La bonne approche consiste à se débarrasser d'un mauvais actif le plus tôt possible. La tâche de l'analyste et du gestionnaire de l'avant-projet est de le faire.

Comment obtenir un budget pour un avant-projet

Afin de suivre la voie d'une élimination constructive et cohérente de l'incertitude autour d'un projet informatique, il est nécessaire de clarifier avec le client et le sponsor la position générale concernant l'attitude envers le projet en tant qu'actif financier.

L'image montre le rapport normal d'incertitude, d'investissement et de rendement.



Tant que l'incertitude est grande, nous devons investir peu et la réduire.

Une fois que l'incertitude avec le ratio investissements / avantages devient un niveau acceptable, vous pouvez investir la majeure partie des ressources pour obtenir un rendement. À la fin de chaque phase, une décision honnête doit être prise: travailler sur le projet ou le clôturer.

Pour ce faire, à la fin de chaque phase, il devrait y avoir une évaluation du ratio des investissements et des rendements au niveau de précision qui est naturel pour la phase actuelle.

Le client doit montrer le niveau actuel d'incertitude, l'évaluation raisonnable actuelle des avantages et des coûts. Si les avantages dépassent le coût, il est logique de discuter de la suppression de l'incertitude.

La rhétorique peut être la suivante: "Nous voyons une prévision des avantages qui dépassent considérablement le coût du système, dépensons une petite fraction de la valeur ou des avantages prévus pour affiner les estimations et décider du démarrage du système."

Mes recommandations (très moyennes) sur le ratio du coût des pièces de l'avant-projet:

• Tout ce qui se passe avant la construction ne devrait pas coûter plus de 10 à 30% du projet.

• Un avant-projet devrait coûter un ordre de grandeur de moins - cela représente 1 à 3% du coût prévu du système.

• Dans les premiers stades, tant qu'il n'y a pas d'exigences commerciales, il peut ne pas y avoir de valeur prédite et doit être repoussé du rendement calculé - vous pouvez prendre 0,1 à 0,2% pour la durée de vie du système sur le budget pour créer des exigences commerciales (en tenant compte du fait qu'il ne démarre pas chaque projet proposé).

Par exemple, si nous vendons un système qui coûte environ 100 millions d'euros (par analogie). Cela a du sens si le retour sur son fonctionnement est d'au moins ~ 300-500 millions, étant donné la faible précision de toutes les estimations.

Dans ce cas, les coûts suivants peuvent être considérés comme normaux:

• Besoins commerciaux - 0,5-1 million de roubles.

• Le concept est de 1 à 3 millions de roubles.

• Projet technique - 10-30 millions de roubles.

Des écarts dans toutes les directions sont possibles ici. Mais le principe général est le suivant: les ressources investies doivent être corrélées avec le profit prévu et la probabilité de sa réception, en fonction du niveau actuel d'incertitude.

Bref résumé

Ici, nous terminons l'examen de l'avant-projet correct et répétons la chose la plus importante:

1. Le projet doit être considéré comme un actif financier risqué.
2. Le niveau d'incertitude doit être connu de tous et discuté entre toutes les parties intéressées.
3. Les coûts d'analyse doivent être liés à l'avantage prévu et à la probabilité qu'il soit reçu.
4. Au cours du développement, il est nécessaire d'atteindre la qualité des exigences suffisantes pour évaluer le coût et les conditions avec la précision inhérente à la phase actuelle.
5. En particulier, les exigences commerciales devraient déjà être mesurables.
6. Il est nécessaire de se souvenir de la liste complète des tâches de la phase d'avant-projet, dont l'omission augmente chacune la probabilité d'échec du projet par ordre de grandeur.

La vie montre que pour diverses raisons, il n'est pas toujours possible de respecter ces principes. Dans certains cas, un projet endommagé avant le lancement peut être enregistré ou au moins légèrement amélioré. Nous en parlerons dans les prochaines parties de la série.