Discussion :

[Alec6]

Bonjour,

me voilà parachuté du role d'ingénieur à celui de chef de projet (et architecte), avec sur les mains 3 projets en mode start up depuis quelques mois.

J'ai du mal à m'organiser: ce qui a été dit, ce qui doit etre fait, ce qui est abandonné, pour plus tard, testé, livré etc... J'ai l'habitude de piloter depuis les spec jusqu'aux tests.. mais pas de plus haut, ou je me rend compte qu'il faut également savoir piloter les clients, qui eux meme ne savent plus trop ce qu'ils veulent ou est en cours.

J'aurai donc besoin de conseils très pragmatiques sur la façon dont je dois gérer l'amont puis l'aval. Je ne pense pas avoir besoin d'une méthode lourde dans un premier. J'irais ensuite explorer la lourde documentation sur le sujet pour améliorer les points qui me semble utile d'améliorer.

Merci.

[souviron34]

embauche (temporairement) quelqu'un qui s'y connait

[Nebulix]

... il faut également savoir piloter les clients, qui eux meme ne savent plus trop ce qu'ils veulent ...

Je n'ai jamais été dans ta situation exacte, je te donne un avis "naïf".
J'ai constaté très souvent, dans tous les domaines, que les gens qui formulent une demande sont souvent incapables de la formuler correctement voire même qu'ils ne savent pas vraiment ce qu'ils veulent !
Il faut prendre le temps et les moyens nécessaires pour éclaircir la demande et donc satisfaire le vrai besoin.
Il arrive aussi, malheureusement, que la satisfaction du besoin n'entraine pas celle du demandeur.
Peut-être vaut-il mieux garder une part d'obscurité et de magie ?
(à voir sur des forums spécialisés)
Bon courage et bonne année

[lepinekong]

Bonjour,

me voilà parachuté du role d'ingénieur à celui de chef de projet (et architecte), avec sur les mains 3 projets en mode start up depuis quelques mois.

J'ai du mal à m'organiser: ce qui a été dit, ce qui doit etre fait, ce qui est abandonné, pour plus tard, testé, livré etc... J'ai l'habitude de piloter depuis les spec jusqu'aux tests.. mais pas de plus haut, ou je me rend compte qu'il faut également savoir piloter les clients, qui eux meme ne savent plus trop ce qu'ils veulent ou est en cours.

J'aurai donc besoin de conseils très pragmatiques sur la façon dont je dois gérer l'amont puis l'aval. Je ne pense pas avoir besoin d'une méthode lourde dans un premier. J'irais ensuite explorer la lourde documentation sur le sujet pour améliorer les points qui me semble utile d'améliorer.

Merci.

Conseil très pragmatique: mode Agile genre scrum, une feuille excel pour lister les besoins (product backlog), prioritiser avec le client (product owner), discuter avec les développeurs la liste des tâches afférentes pour une implémentation sur une période (sprint) de genre 2 semaines avec pour objectif de considérer comme fini que les tâches réellement terminées (aka testées), livrer au client pour test, corriger, et recommencer (cycle pdca de Deming dont je parle sur mon site).

[welcome_59]

voire même qu'ils ne savent pas vraiment ce qu'ils veulent !

Ils savent très souvent ce qu'ils veulent, mais ils ne savent pas qu'ils le savent.

Il arrive aussi, malheureusement, que la satisfaction du besoin n'entraine pas celle du demandeur.

C'est souvent le cas lorsque l'on a baclé l'analyse des besoins. On a trop souvent tendance à confondre demande et besoin. Le travail d'analyse des besoin doit être soigné pour entre autres:

• Faire ressortir ce qui est réellement un besoin
• identifier ce qui relève du cadre du projet
• identifier ce qui peut être facilement satisfait dans le cadre des activités et des processus réguliers du travail du demandeur (pour exemple, lors d’une précédente expérience, il m’est arrivé de résoudre un problème en modifiant deux lignes dans une procédure de l’entreprise, alors que certains pensaient modifier un logiciel pour y parvenir)
• Ce qui est prioritaire
• ...

Ce travail demande d'y consacrer le temps nécessaire, et doit impérativement se faire en étroite collaboration avec le client/demandeur. Le chef de projet doit disposer des compétences techniques et humaines (lui-même ou son équipe) pour faire ce travail.

Un client m'a dit une fois:

Ne me demandez pas ce dont j'ai besoin, je ne le sais pas. Faites-moi plutôt des propositions et je vous dirai si ça me convient.

Pour moi un client dans cette situation n'a pas besoin d'un projet. Le client doit rester dans son rôle de porteur du besoin, du problème, etc. Le rôle de la technique d'analyse sera de lui faire dire ce qu'il ne sait pas qu'il sait.

Tu ne vas pas chez le médecin pour lui demander de te suggérer une douleur afin de pouvoir tesoigner.

Si ton projet est complexe (solution à développer complexe et coûteuse, beaucoup d'intervenant, enjeux très important), je te conseille de prendre le temps de bien définir et cadrer ton projet et de soigner l'analyse des besoins: c'est fondamental et indépendant d'un référentiel quelconque; c'est une question de bon sens. Une analyse des risque n'est pas toujours superflue en fonction du projet. Ce n'est pas le formalisme utilisé qui est important, l'important c'est de le faire et de le faire bien.

[babynus]

Salut,

Un conseil : trace tout.
Ca te permet de garder un historique de ce qui s'est passé pour éviter de te trouver en porte-à-faux face à une situation qui se dégrade.

C'est d'ailleurs la base d'un syystème qualité :
- écrire ce que l'on va faire (des specs !)
- faire ce que l'on a écrit (ça parait évident)
- écrire ce que l'on a fait (c'est trop souvent oublié, mais c'est indispensable pour comprendre ultérieurement le pourquoi du comment)

Pour ça deux choix :
Soit des tableaux de bord sous Excel : c'est super efficace tant que tes projets ne sont pas trop gros (<=3ETP)
soit tu t'outille

Personnellement, j'en suis venu à développer mes propres outils.
J'en suis à la seconde génération.
Tu peux aller voir sur http://projector.toolware.fr (2nde génération) et http://deltaprod.toolware.fr (1ere génération) pour jeter un oeil.
Ca peux aider et c'est gratuit.

Bonne continuation.
Babynus
Modérateur du site http://www/toolware.fr.

[miss_kamelia]

merci pour les infos les amis

[hegros]

C'est d'ailleurs la base d'un syystème qualité :
- écrire ce que l'on va faire (des specs !)
- faire ce que l'on a écrit (ça parait évident)
- écrire ce que l'on a fait (c'est trop souvent oublié, mais c'est indispensable pour comprendre ultérieurement le pourquoi du comment)

Ce n'est pas vraiment cela. La roue du succès d'un système de qualité c'est

1/Planifier ce que l'on va faire(plan)
2/Faire ce que l'on a planifier(do)
3/Vérifier ce que l'on a fait(check)
4/Améliorer ce que l'on a fait(improve)

Tu as donc homis la planification, la vérification et l'amélioration.

[souviron34]

Tu as donc homis la planification

omis

ps: juste pour info, hein ?