Discussion :

[mlstage]

Avant-projets d'études (AVP) : Causes des dysfonctionnements pas la méthode des 5P

Bonjour à tous,

Je suis en période de stage et je travaille sur les AVP.
J'ouvre cette discussion afin d'obtenir de l'aide de par votre expérience à tous.

En effet, j'ai déjà réalisé une courbe pareto sur les dysfonctionnements que j'ai pu trouver et à présent je souhaite réaliser une courbe pareto sur les causes de ces mêmes dysfonctionnements.
Pour trouver les dysfonctionnements, j'utilise la méthodes des 5P. Cependant, pour certains d'entre eux (ci-dessous) je ne cerne pas réellement le périmètre de la cause.

Les dysfonctionnements étant :

Pourquoi la réponse du CDC ne correspond pas aux envies du client ?
Pourquoi la prise en compte de la stratégie technique, financière et commerciale est elle mauvaise ?
Pourquoi la détermination de la faisabilité technique et des caractéristiques techniques de l’AVP est elle mauvaise ?
Pourquoi avons-nous une mauvaise adéquation CAO / Croquis ?
Pourquoi l'estimation du temps de l’AVP est-elle mauvaise ?
Pourquoi le cadrage technique des croquis est-il mauvais ?
Pourquoi le rangement des AVP est-il désordonné ?
Pourquoi passe-t-on trop de temps sur l’AVP ?

Je ne cherche pas forcément des réponses, mais peut-être des exemples types que vous avez pu rencontrer qui me guideraient sur la résolution de mon problème. (un fil conducteur)
Vos réponses peuvent être très vastes comme très ciblées, j'essayerai de me débrouiller avec l'aide que vous m'apporterez.

Merci par avance,
mlstage

[Saverok]

Pourquoi la réponse du CDC ne correspond pas aux envies du client ?

Je pense qu'il faut recentrer la question sur "qu'est ce que l'envie" ?
C'est une question plus de philo et de psycho que d'info et pourtant, quand on c'est répondre à ça on comprend tout le problème.

L'envie est quelque chose de changeant car extrêment influençable :
- liée aux évolutions interne de l'entreprise
- liée aux marchés
- liée à la concurrence
- liée aux rencontres suites aux appels d'offre
etc.

Le CDC est figé dans le temps alors que les envies évoluent.

Pourquoi la prise en compte de la stratégie technique, financière et commerciale est elle mauvaise ?

Remporter un appel d'offre, c'est la course à l'échalotte à celui qui proposent le plus pour le moins cher.
On arrive forcément à des propositions séduisantes pour le client mais totalement irréaliste techniquement.
Mais l'important pour le prestataire info est de remporter le contrat car une fois engagé, le client a peu de porte de sortie (en tout cas, pas sans pertes ni fracas).
Personnellement, je n'ai jamais vu un projet sans avenant...

Pourquoi la détermination de la faisabilité technique et des caractéristiques techniques de l’AVP est elle mauvaise ?

La réponse est la même que pour la première question : le besoin du client évolue.

[Laurent 1973]

Dans les analyses d'avant-vente, le client/utilisateur a tendance à mélanger le Why, le What et le How.

Je m'explique.

Le Why, le "Pourquoi", c'est le besoin réel de notre client.
C'est là que ça problématique métier prend ton son sens.
C'est sur ce point que l'on devrait s'appuyer pour définir un cahier des charges

Le What, le "Quoi", c'est le résultat que l'on va obtenir afin de répondre au Why.
Est-ce que cela sera une nouvelle procédure d'organisation?
Est-ce que cela sera un simple outil papier-crayon?
Est-ce que cela sera un petit outil informatique? ou un gros outil informatique?
...
Déjà, sur cette question, le client a déjà un avis et bride ses possibilités.

Le How, le "Comment", répond techniquement et organisationnellement à la mise en œuvre du What pour répondre au Why.
Dans ce cas, nous retrouvons par exemple un choix technologique comme un langage, un environnement de développement, des framework mais aussi le nombre d'équipe, de développeur et un fonctionnement de suivie de projets (cycle V, Scrum, Kanban, ...)
Et là, encore, notre client viens imposé du How sans le justifier par un Why (genre: utilisation d'Oracle DB sans justification de besoin technique spécifique à cette SGDBR)

Petite anecdote illustrant cela.

Sur l'accompagnement d'un remplacement du logiciel, on analysait avec un client les manques du nouveau système.
Là, le client demande un export MS-Excel avec tout une liste de colonnes très précises.
Cette demande nous paraissait assez surprenante dans le contexte de l'application (scientifique)
Finalement, cette demande n'était pas un Why, mais un mélange de What (un export) et d'How (Excel)

En discutant mieux, on s'est aperçu que le besoin du client est de pouvoir afficher une courbe spécifique mais précise de résultat.
Leur ancien logiciel ne proposait pas ce type de courbe par contre il proposait un export Excel avec plein de données.
Notre client avait mis au point une super macro Excel pour transformer ces données en la courbe qu'il voulait.
Comme pour lui, il travaillait comme cela depuis très longtemps, il n'imaginait pas de pouvoir avoir son besoin directement inclus dans le logiciel.

Finalement, on lui a proposé sa courbe spécifique, plus simplement et qui couvrait bien mieux son besoin.
=> Ce client était formaté dans son contexte professionnel pour ne pas distinguer son Why décorrélé du What et du How associé.

Voilà, un point qui peux être une cause de dysfonctionnements pour recueillir un ensemble de besoin réel.

[el_slapper]

Plus généralement : parce que les êtres humains sont des systèmes limités, et que l'anticipation qu'ils peuvent produire ne couvre généralement pas l'ensemble du spectre réel du projet.

[Matthieu Vergne]

Un problème de la méthode des 5P est que c'est avant tout du retrospectif : tu es capable de dire pourquoi c'est arrivé parce que c'est effectivement arrivé, et donc dans le cas qui t'intéresse c'est arrivé pour une raison précise qu'il te faut identifier, consécutivement pour chaque niveau supplémentaire de P. Il te faut donc des cas concrets, et pas seulement ça mais il te faut suffisamment d'infos sur ces cas concrets pour obtenir la réponse à chacune des questions. Typiquement, si tu n'as accès qu'à un résumé/compte rendu d'un cas, je m'attends à ce que tu sois capable d'avoir de l'ordre de 1 ou 2 P, mais très rarement 5. Par ailleurs, il est aussi possible de pousser bien au delà de 5, ce qui peut être nécessaire pour les cas les plus complexes.

Pourquoi la réponse du CDC ne correspond pas aux envies du client ?

Pourquoi ? A B ...

A) Parce que le CdC a été mal interprété.
Pourquoi ? C ...

B) Parce que le client a mal formalisé son besoin.
Pourquoi ? E ...

C) Parce que le cahier des charges est trop approximatif et laisse donc trop de marge d'interprétation.
Pourquoi ? D F ...

D) Parce que l'information disponible au moment de la rédaction n'était pas suffisante pour préciser davantage.
Pourquoi ? E ...

E) Parce que les personnes impliquées dans la rédaction du CdC n'avaient pas l'expertise suffisante dans les domaines concernés.
Pourquoi ? ...

F) Parce que les personnes impliquées dans la rédaction du CdC n'ont pas eu le temps d'aller plus en détails dans leur analyse.
Pourquoi ? ...

On peut développer encore longtemps, et cela bien au delà de 5. Et tu peux grosso modo répondre la même chose pour toutes tes questions :

Pourquoi la prise en compte de la stratégie technique, financière et commerciale est elle mauvaise ?
Pourquoi la détermination de la faisabilité technique et des caractéristiques techniques de l’AVP est elle mauvaise ?
Pourquoi avons-nous une mauvaise adéquation CAO / Croquis ?
Pourquoi l'estimation du temps de l’AVP est-elle mauvaise ?
Pourquoi le cadrage technique des croquis est-il mauvais ?
Pourquoi le rangement des AVP est-il désordonné ?
Pourquoi passe-t-on trop de temps sur l’AVP ?

Manque de compétence -> embaucher, former, déléguer à un sous traitant plus compétent.
Manque de temps -> être plus flexible sur les délais (agile), être plus flexible sur le produit fini (accepter du partiel), embaucher plus de monde par contre n'est pas forcément une bonne idée (nécessite du temps et des ressources pour les intégrer au travail, mais aussi pour les manager en plus du reste de l'équipe).
Oubli -> formaliser/automatiser les procédures.

Je te conseil de te documenter sur l'ingénierie des exigences (Requirements Engineering en anglais), vu que l'alignement entre le produit et le besoin du client est justement le point central de ce domaine. Par exemple, comme Laurent 1973 le mentionne, il est rare que le client dise effectivement son besoin, mais davantage la solution qu'il imagine pour y répondre. De ce fait, il est important de se demander pourquoi le client veut telle ou telle fonctionalité, de façon à comprendre le besoin réel du client (comme les 5P, mais appliqué au produit, et surtout on ne se limite pas à 5). Cela à mené à développer des méthodes dites "orientées objectifs" (goal-oriented), et notamment des approches utilisant des modèles telles que Kaos, i* et ses nombreux dérivés, etc.

Je te recommande de voir certains articles génériques qui décrivent le domaine, comme celui-ci, celui-ci et celui-là, mais aussi des artcles plus récents pour des perspectives spécifiques :

• Exigences et pratiques agiles : http://ieeexplore.ieee.org/xpl/login...0071%26tag%3D1
• Catégories d'exigences : http://dl.acm.org/citation.cfm?id=1662636.1662637
• Exigences et respect des lois : http://eprints-phd.biblio.unitn.it/230/
• Parallèle entre évolution logicielle et évolution des exigences : https://tspace.library.utoronto.ca/handle/1807/32707
• Systèmes de recommendations liés aux exigences : http://ieeexplore.ieee.org/xpl/artic...number=6225965
• Priorisation des exigences de manière semi-automatique : http://ieeexplore.ieee.org/xpl/login...mber%3D6249686
• Exigences formalisées pour identifier des incohérences : http://www.sciencedirect.com/science...50584912001255
• Exigences en tant que connaissances tacites : http://ieeexplore.ieee.org/xpl/artic...number=6636709

Si les techniques développées ne sont pas forcément ce qui t'intéresse, les références qu'ils citent et les problématiques qu'ils développent devraient te permettre d'avoir une vision plus riche du sujet.