Discussion :

[el_slapper]

Le truc, c'est que dans de très grandes organisations, il est interdit de communiquer avec les utilisateurs finaux. Avec un but louable : éviter que l'utilisateur ne dérange le développer tous les 4 matins avec des appels insensés. J'ai eu le coup une fois, une utilisatrice dans la mouise, impossible de comprendre son problème d'après les description de l'assistance, alors j'appelle.....moralité, le problème venait de ce que son câble réseau était foireux(pas ma partie, je fais du logiciel), et surtout, à chaque fois qu'elle avait un souci informatique, hop, c'était pour ma pomme. Toujours hors de mon sujet, évidemment, mais ça, impossible pour elle de le comprendre : "vous êtes de l'informatique, c'est vous que ça concerne"!

A BNPP, il y avait des milliers d'agents qui utilisaient mes transactions. Et ils se parlaient entre eux. Si l'un d'entre eux avaient eu mes coordonnées, fini, terminé, j'aurais passé mon temps à faire le boulot de l'assistance. D'ou l'utilité, malgré tout, d'une MOA. Evidemment, je suis conscient du fait que celà éloigne la conception du besoin réel utilisateur.....

[B.AF]

La boite que tu cites est un cas que je connais TRES bien.

Mais là, le problème est un problème de support, pas de projet.

Le but n'est pas si louable, car si tu regardes bien, le principe était surtout de centraliser les demandes.

Dans les grandes organisation, les DSI pensent (à tort ou à raison) que leur pouvoir réside dans leur capacité à instaurer n go between entre l'utilisateur final et le dev.
Mais c'est surtout une mesure politique.

Un DSI ou un chef de projet qui part sur une réunion produit ou dev sans le développeur concerné par le sujet, c'est plutôt un problème politique qu'un contrainte organisationnelle.

La vraie version est que c'est une dérive du "on ne vous autorise pas à dire que vous savez".

Après il y a des cas drôles comme toi, mais comme je dis aux DSI de mes clients; si je ne peux pas connaitre le point de vue de l'utilisateur final, alors je n'ai aucun problème, puisque je ne fais rien.

[souviron34]

Avec un but louable : éviter que l'utilisateur ne dérange le développer tous les 4 matins avec des appels insensés.

Le but n'est pas louable

Il l'est si c'est pour du support.

Il ne l'est pas pour ce qui est du développement.

Une équipe de développement devrait pouvoir être interrompue tous les 4 matins par un utilisateur disant : "cette nuit j'ai pensé à ce cas-là. Faudrait aussi le prendre en compte"... (bon j'exagère pour tous les 4 matins, mais il y a (un peu) de ça).
(si il faut 1 ou 2 ans à l'équipe de dév pour faire une conception correcte de son boulot, pourquoi l'utilsateur devrait-il être restreint à une période de "réflexion/conception" de son métier qui soit juste le temps du cahier des charges ??? Lui aussi a le droit d'aller dans un "schéma de pensée" et s'apercevoir que ce n'est pas forcément le meilleur. Ou de découvrir "un nouvel aspect" auquel il n'avait pas encore pensé))

Mais ceci évidemment est extrêmement facilité dans une organisation basée sur une approche "User Centered"....

Et je reviens à ce que je disais plus haut : d'où l'effroyable "gap" entre besoins et résultats dans la très grande majorité des grosses boîtes qui ne fonctionnent pas comme ça...

[rakakabe]

Et je reviens à ce que je disais plus haut : d'où l'effroyable "gap" entre besoins et résultats dans la très grande majorité des grosses boîtes qui ne fonctionnent pas comme ça...

Grosses Boites ? Meme dans une petite boite c'est toujours le cas, en particulier lorsque le client est Monsieur le Chef (superieur)

[el_slapper]

Le truc, c'est que j'ai eu tendance à alterner entre maintenance & chaud, maintenance évolutive, et nouveau projet(chez ce client et bien d'autres). Donc difficille de jeter l'utilisateur qui appelle pour du support quand de toutes façons le problème va revenir. Seulement, au lieu d'avoir une fiche du support, le vrai, on a 7 coups de fils dans la matinée, à réexpliquer les mêmes choses(en général que l'on regarde et que c'est en cours).....

Là ou je suis maintenant, c'est pareil pour certains collègues, qui se font régulièrement emmerder pour des sujets qui ne sont plus de leur responsabilité depuis des années. Alors ma chef en est à monter à l'assistance(chance, c'est pas loin) pour appeler depuis un numéro anonyme et sous un faux nom.....sinon, fini, terminé, on est marqué au fer rouge.

Et user centered, c'est bien; mais si tu as 7000 agents qui t'ont repéré, tu est mort, vu que chacun aura sa propre idée sur ce que doit faire le logiciel, et surtout contrôler(en fait, rien, ils veulent tous pouvoir tout faire).Donc, il est quand même nécéssaire d'avoir d'autres intervenants(genre le juridique). Histoire de garder la créativité des utilisateurs dans des limites acceptables pour leur employeur.

[souviron34]

Et user centered, c'est bien; mais si tu as 7000 agents qui t'ont repéré, tu est mort, vu que chacun aura sa propre idée sur ce que doit faire le logiciel, et surtout contrôler(en fait, rien, ils veulent tous pouvoir tout faire).Donc, il est quand même nécéssaire d'avoir d'autres intervenants(genre le juridique). Histoire de garder la créativité des utilisateurs dans des limites acceptables pour leur employeur.

D'où la notion d'avoir un Utilisateur Expert, permanent, qui écoute les autres utilisateurs et pondère et décide ce qui est bien ou non

[chaplin]

D'où la notion d'avoir un Utilisateur Expert, permanent, qui écoute les autres utilisateurs et pondère et décide ce qui est bien ou non

Chez moi, c'est ce qui a été décidé puisque la communication était impossible entre le chef et les utilisateurs et la direction. Donc la direction avait désigné des utilisateurs référents pour canaliser les besoins. Tout allait bien jusqu'au jour où le chef avait trouvé un nouvelle techno et il embobiné le médiateur (MOA) en promettant mots et merveilles. Résultat, délais non respectés et le médiateur a fait 3 mois d'arrêt maladie pour dépression. A qui la faute ???

L'utilisateur Expert doit avoir un emploi du temps aménagé pour qu'il puisse se consacré aux besoins sinon il peut se laissé débordé par son travail d'autant plus qu'il est consciencieu.

Avec un peu plus de recul, je m'apperçoit que nos référents métiers ont fait tour à tour une dépression . Le dernier a chutté fin de l'année dernière.

Dans ce cas, une petite équipe d'utilisateurs volontaires et un responsable utilisateur, malgré certaines déconvenues est rudement efficace.

[B.AF]

Dans ce cas, une petite équipe d'utilisateurs volontaires et un responsable utilisateur, malgré certaines déconvenues est rudement efficace.

Je suis assez d'accord, surtout quand tu arrives dans une phase avec "certitudes", que les utilisateurs puissent commencer à mettre les mains dedans et à donner du feedback.

Prendre les feedbacks trop tard où se baser sur un seul utilisateur, c'est un vrai risque.

Il faut forcémment sur ces parties une démarche interactive.

De même moi, je mets à disposition des utilisateurs un forum, avec une partie "boite à idée", histoire de toujours avoir du feedback utilisateur.

[chaplin]

Prendre les feedbacks trop tard où se baser sur un seul utilisateur, c'est un vrai risque.

Oui,

Experience 1 : le chef de projet avait initié un projet et centraliser les demandes en applicant/imposant sont modèle de pensé. Résultat: 3 ans de travail, 150 000 € foutu par la fenêtre et un logiciel utilisé par 2 personnes, d'une complexe et rigide.

Experience 2 : un médiateur désigné qui collectait les besoins chez les utilisateurs. Les résultats étaient pas mal, mais la direction a décidé de figer le projet (c'était pas celui du chef) et démission de la médiatrice.

Experience 3: Un médiateur et un délégué, une équipe d'utilisateurs ainsi que les chefs de service pour des réunions de décision importantes, 2 ans et un projet finalisé.

Après il y a le côté humain, il suffit d'une personne qui a un rôle stratégique dans le projet pour le faire capoté quelques soient les moyens financiers ou humains mis derrière.

EDIT:

La gestion de projet c'est avant tout le bon sens finalement.
...
la plupart des chefs de projets et autre rafales de l'informatique sont pour la plupart des frustrés. ..
Et ça me frustre tout autant d'ailleurs de devoir me supporter un abruti qui fera de la merde sous prétexte de respecter des normes et des méthodes et de caler son chiffrage.
...
Notre métier est dans l'ensemble malade, parce que toutes ces fonctions parasites n'ont fait que renforce la honte de devoir développer.
...
Bref, c'est confus, décousu, c'est très polémique, mais avec l'âge, je me radicalise !!!!!!

Je comprend absolument ta réaction B.AF, en espérant que ce n'est pas partout comme ça.

[souviron34]

Je comprend absolument ta réaction B.AF, en espérant que ce n'est pas partout comme ça.

Malheureusement presque partout..

C'est bien pour ça que certains ici (B.A.F., Garulfo, moi-même, et quelques autres) pondéront largement les élans et "croyances" de certains autres... Et que nous participons et (voir le début du thread) avons donné certains conseils.... "Veni Vidi Vici" comme on pourrait lire dans Asterix...

Rien que sur les projets sur lesquels j'ai travaillé , en 27 ans, environ 250 millions d'euros partis à la poubelle....

Et par conséquent, contrairement à certains critiques, ça n'est pas "être papy" ou "être obsolète" ou "vieux jeu" ou que sais-je encore.. C'est (malheureusement) l'expérience....

[chaplin]

Malheureusement presque partout..
...
Et par conséquent, contrairement à certains critiques, ça n'est pas "être papy" ou "être obsolète" ou "vieux jeu" ou que sais-je encore.. C'est (malheureusement) l'expérience....

Ce qui me dérange souviron, outre le fait qu'on est payé pour faire un job et donc on se la ferme, c'est que ce genre de comportements fait que par rapport à ce qu'on entend sur la crise mondial, en tout cas pour moi m'émeu à peine vu tout ce que j'ai vu en matière de conneries. Faut-il accepté ce genre de comportement ou laissé faire jusqu'à la banqueroute de notre société ?

"Tout le problème de ce monde, c'est que les idiots et les fanatiques sont toujours si sûrs d'eux, tandis que les sages sont tellement pleins de doutes."
(Bertrand Russell / 1872-1970)

Garulfo a de très bonnes lectures en matière d'auteurs.

[souviron34]

Ce qui me dérange souviron, outre le fait qu'on est payé pour faire un job et donc on se la ferme, c'est que ce genre de comportements fait que par rapport à ce qu'on entend sur la crise mondial, en tout cas pour moi m'émeu à peine vu tout ce que j'ai vu en matière de conneries. Faut-il accepté ce genre de comportement ou laissé faire jusqu'à la banqueroute de notre société ?

Non bien sûr..

Et c'est bien pour ça que nous avons eu notre "mini-thread" dans le thead à propos d'UML.. ou des méthodologies...

C'est un combat de tous les jours, contre les oeillères et pour le bon sens...

[elitost]

Salut où en es-tu de ton article, où peut-on le consulter ?

j'en suis au même point que le post précédent ta question manque de temps depuis quelques mois...mais l'offre de reprise de l'article est toujours d'actu

Bonne journée à tous

[woorant]

A un autre niveau, tu peux également jeter un coup d'œil sur certaines parties du recueil ITIL et du modèle CMMI

[olpons]

A un autre niveau, tu peux également jeter un coup d'œil sur certaines parties du recueil ITIL et du modèle CMMI

A ce propos, j'aimerai avoir un avis sur l'utilisation d'ITIL en situation réelle.
Sur quel type de projet peut-on l'appliquer ?
Quels sont les difficultés pouvant être rencontrées, tant sur le plan relationnel au sein de l'équipe que vis à vis du client ?
...

[Furikawari]

A ce propos, j'aimerai avoir un avis sur l'utilisation d'ITIL en situation réelle.
Sur quel type de projet peut-on l'appliquer ?
Quels sont les difficultés pouvant être rencontrées, tant sur le plan relationnel au sein de l'équipe que vis à vis du client ?
...

ITIL ne s'implémente pas au niveau d'une équipe...

[abdeslem]

Bonjour,
je sais que le poste est assez ancien, mais j'ai un peu cherché sur le forum, je n'ai pas trouvé un poste qui traite des "projets de développement web" (et je n'arrive a créer un nouveau poste .... je ne sais pourquoi!!! ).

en réalité, un "Projet web", n'est qu'un héritage de "projet de développement software"............ héritage oui, mais avec des surcharge de spécificités si vous voyez ce que je veux dire......

Ma question est plus spécifique, quel serait les "best practice" dans les projets de développement web (e équipe)??? les meilleurs outils??

[B.AF]

Les logiques restent les même web ou pas web, ça reste du projet.
C'est à dire du bon sens, du suivi, et le sens des réalités.

Après, le web n'introduit rien de spécial.
Chaque projet IT (ERP, Jeux, Web...) ont leurs spécificités, leurs réalités.

Il n'y a pas de bonne méthode. La bonne méthode, c'est l'expérience de trouver l'organisation du travail qui permettra in fine d'avoir la meilleure optimisation entre résultat et ressources. Trop laxiste, c'est du nawak, trop rigoriste, c'est l'ennui et la déprime des équipes.
Pareil pour la techno : avoir une techno connue, qui ne soit une constante sources de remise en question
Pareil pour les tests : ne pas se rendre compte 2 jours avant la fin que les tests existents

Les méthodos projets, c'est comme les langages: tu peux les connaitre, les apprendre, voir penser les comprendre, après s'en servir, c'est comme tout - tu ne peux te servir d'un objet qu'en sachant ce que tu souhaites en faire.

[abdeslem]

merci pour votre réponse!
je tacherais de m'en souvenir!
en réalité, je viens tout juste d'être embauché dans le poste de chef de projet web a plein temps (j'ai eu l'occasion de gérer des sprints autant que "chef de projet" technique, mais c'était flexible, et ça changeais selon les projet..... mais la c mon job a plein temps)
et c'est pour cela que j'essaie de faire des analogies, et d'apprendre aussi vite que possible, les réflexes nécessaires, pour surfer dans les vagues du web en étant efficace.

merci

[chabz]

Oui mais là c'est une question d'apprentissage et de personne.

Mais on ne peut pas demander à quelqu'un qui sort de l'école d'avoir innée la science de la satisfaction d'un client, il ne sait pas ce que c'est.

C'est de l'expérience et de la maturité et aussi une question d'encadrement.

On ne peut pas demander à un développeur qui n'a jamais pu discuter avec un client ou voir la réaction d'un client final à son travail en prendre compte dans son travail quotidien.

Ce n'est pas que la plupart des développeurs ne comprennent pas les clients, c'est que la plupart des organisations empêche le développeur de s'imprégner des attentes du client et qu'ils font ce que d'autres interfaces relatent comme étant le souhait du client.

Bonjour, j'ai suivi la discussion en cours et je tiens à apporter ma petite expérience personnelle. Je suis étudiante ingénieur en technologies de l'information pour la santé. Comme dit dans un post précédent, ma formation n'est pas faite pour que je sois développeur. Elle est faite pour faire le pivot entre les développeurs et les utilisateurs.

On nous a appris à développer, mais on n'est certainement pas les meilleurs pour ça. Mais ce dont on nous a rabâché les oreilles pendant toute notre formation c'est : "des ingénieurs qui nous disent comment faire, y'en a des cars entiers, des ingénieurs qui nous disent pourquoi, c'est ça qu'on veut", on nous a tanné avec les feedback utilisateurs, en nous disant clairement :"on vous empêchera de voir vos utilisateurs finaux, mais c'est à eux qu'il faut parler pour concevoir votre produit", on a dit que ça serait pas facile. Ils nous ont mis en projet, pour découvrir les outils de gestion de projet qu'on avait eu en cours juste avant. Et je peux vous dire que la différence entre la théorie du archi logicielle et la réalité, on sait qu'elle est énorme et encore, nous, nous étions de bonne volonté pour appliquer ce qu'on nous avais enseigné. Mais surtout, dans ces outils de gestion, on nous a fait comprendre que ce n'était que des outils, et que l'important, c'était de savoir où on allait, et être sur que c'est là-bas qu'il faut aller. C'est pour ça aussi qu'on a eu 1/3 de notre formation sur le monde de la santé et sur son informatisation. On doit comprendre et savoir ce que c'est cet univers qui a des besoins très particuliers en informatique. Enfin bref, tout ça pour dire que oui, les écoles d'ingé ne forment peut-être pas les meilleurs chef de projet, mais je sais que ma formation m'a donné tous les outils pour.