Discussion :

[sidewolf]

Depuis le temps que tous les développeurs de ce forum réclamaient un article à charge sur les managers, en voilà un beau

Blague à part, je suis plutôt en phase avec l'étude qui est une excellente occasion de replacer le rôle et les missions du manager de projet
On a souvent tendance à limiter la visions des missions du CP à la gestion de l'équipe (le terme "gestion de ressources" qui fait hurler les développeurs) alors que c'est très réducteur
Le manager de projet gère un projet dans son ensemble et la gestion de l'équipe de développement en est un aspect mais au final, très faible en ratio temps par rapport à tout le reste
D'expérience, hors cas particuliers, une équipe de développement est assez autonome à partir du moment où elle est bien constituée (bon équilibre entre les débutants et les expérimentés. Équilibre qui varie en fonction de la difficulté du projet).
Un manager de projet est là pour absorber tout les "à côté du dev" : gérer la hiérarchie, gérer le client, gérer les autres équipes (infra, sécu, etc.)
En pratique, un manager de projet passe 2x plus de temps à gérer le client qu'à s'occuper de l'équipe de développement

Qu'un client ne sache pas précisément ce qu'il veut est normal et même logique sinon pourquoi ferait il appel à nous ?
S'il fait appel à des ressources externes c'est justement parce qu'il n'a pas les compétences en interne tant en conduite de projet, qu'en conception et en réalisation
Le client fait appel à nous pour avoir des conseils
Nous devons être force de proposition
Nous devons cadrer le client et avoir constamment un regard critique sur l'intégralité des éléments du projet. Pour rappel, un regard critique, c'est une prise de recul. Ce n'est pas systématiquement négatif, bien au contraire.

Dire "oui amen" à tout est un profond signe de totale incompétence et de manque de personnalité.
Le client a besoin qu'on lui dise non.
Bien sûr, il y a la forme et cela s'apprend avec le temps et c'est un apprentissage très douloureux mais nécessaire.

Dans la forme vous avez raison, mais dans le fond, c'est autre chose. Pourquoi me diriez-vous ? Car il serait réducteur de faire une généralité des clients ou des demandeurs. J'ai vue certains entreprises ne maîtrisant pas leur domaine fonctionnel, d'autres ne maîtrise pas ni le fonctionnel ni la technique à cause de l'externalisation du service informatique. Toutefois, vous n'agissait plus en tant que force de proposition, ni en tant qu'expert, mais en tant que producteur d'une demande pas toujours calibrée, pas toujours étudiée, pas toujours clairement définie.

[sidewolf]

Ce qui est frappant dans cette analyse et dans vos commentaires c'est que vous avez tous raisons et pourtant on se retrouve presque toujours hors délai sur des projets informatiques.

Avec mes 11 ans d'expérience, j'ai pu me rendre compte de plusieurs paramètres qui peuvent également expliquer (sans doute pas tout expliquer mais il s'agit sans doute de vecteurs non négligeable dans le cycle de vie d'un projet)

1 - L'expression du besoin n'est pas toujours formulé par écrit. (Le cahier des charges, les spec non plus)
2 - Vos interlocuteurs en charge de la demande ne sont pas toujours disponibles.
3 - Le mode forfait présente est généralement sous évalué (et difficile une fois le projet signer de voir votre client en exposant un mauvais chiffrage du projet)
4 - le chiffrage justement est souvent sous évalué car le projet est souvent calculé sur le temps de conception et de développement, mais il manque très souvent 20% de temps pour les phases de recettes.
5 - la politique commerciale est souvent celui qui pose les jalons dans un projet informatique souvent au détriment de l'expertise de l'équipe qui sera en charge du projet (ex : commercial demande à l'équipe de projet : combien de temps pour réaliser ce projet ? L'équipe dit : avec tous paramètres pris en compte, et que tout soit au verts, ils faut X jours (et nous savons tous que les paramètres ne sont pas toujours au verts, certains passent même du vert au rouge : effets de bord pour ne citer que celui la) Le commercial lui fait sa mayonnaise pour "gagner le marché" puis dit : le client à un budget de de Y€ ca représente (Y/X) = Z€ en coût journalier... Toutefois Z€ ne permet pas d'être rentable pour la boite informatique. En conséquence pour qu'elle le soit, et en règle général, le commercial demande de réaliser le projet en X-Lambda jours

Infaisable pour d'équipe de projet, et souvent nous voyons des équipes travaillant 9h, 10h, 12h par jours (et très souvent ces heures supplémentaires ne sont ni payés ni récupérés) mais si nous évaluons 12h sur une journée de 8h, vous avez passé 1H et demi ... Mais sur le plan comptable de votre entreprise est notifié 1 jour...
Et malgré cela le projet dépasse la durée calculé par votre commercial (ou votre responsable) car l'étude ne tiens pas compte non plus de la baisse de rendement d'un développeur lié à la fatigue physique et mental, occasionné par la pression, le stress, les heures supplémentaires.

6 - Très souvent dans les SSII, nous sommes également confronté à un problème de compétence non pas à cause des développeurs eux-mêmes, mais à cause des responsables qui vont placer un collaborateurs le qualifiant d'expert dans le domaine alors qu'il n'a que 3 semaines d'expériences dans la techno... (forcément que le rendement de ce collaborateur sera moindre qu'un collaborateurs avec 10 ans d'expérience et une vrai étiquette d'expert sur le front). Pourquoi cette méthode ? simplement pour réduire un maximum les intercontrats, très répandus en SSII (ou ESN).

7 - La formations des collaborateurs : Absence ou quasi absence de politiques de formations, elle à un double effet : En formation le collaborateurs ne rapporte pas d'argent à sa société car elles n'est pas en prestation de service et donc pas facturé, MAIS en plus le collaborateurs coûte de l'argent à sa société, puisqu'une formation coûte de l'argent... (Et bien souvent on laisse un collaborateur en intercontrat et on va lui demander de monter en compétence par lui même, en autonomie, car ça coûte moins cher, cependant ça ne fera pas de lui un expert)

Voilà selon moi, les points en plus des votre qui justifie très souvent un retard dans les délai de livraison d'un projet informatique

[Jitou]

Il ne faut pas oublier qu’avant d'arriver dans l'escarcelle du développeur le besoin du client passe dans beaucoup de mains. Je rajouterai aussi que trop souvent le chef de projet et non technique et sa traduction du besoin ne permet pas par la suite d'implémenter judicieusement le besoin spécifique demandé par le client. Donc le développeur se retrouve finalement en bout de chaîne or la seule personne qui a réellement besoin de comprendre les demandes du client n'a pas participé ni à l'élaboration du besoin ni à sa traduction en terme de composants techniques.

Je constate que d'année en année le rôle du développeur a été réduit à sa plus simple expression: la réalisation alors que dans le même temps les couches intermédiaires entre le client et lui ont été densifiée massivement. Je le constate sur tous les projets depuis 5 ans au moins. Il y a maintenant une telle distance entre le client et le développeur qu'il y a finalement très peu de chance que ce qui sera livré correspondra au besoin exprimé par le client ...

Après on ira convaincre le client que c'est bien de cela dont il avait besoin et que ses demandes s'inscrivent dans une démarche d'évolution plus globale du SI qui lui échappe totalement blah blah ...

Pour résumer:

Le Client soumet un pb de gestion
=> le MOA imagine ce qu'il faudrait changer du point de vue du fonctionnel (expression de besoin) pour résoudre le pb et fourni une liste d'exigences
=> le chef de projet formalise plus le besoin en terme de fonctions logicielles (use case UML) et liste des composants techniques à réaliser (les specs techniques détaillées)
=> le développeur commence à développer sans véritablement comprendre la finalité ni le contexte métier ...

Comme déjà souligné, viens aussi s'ajouter des difficultés supplémentaires comme les changements de priorité ou de scope de dernière minute, le manque de visibilité sur les impacts des modules adjacents etc ...

Les seules fois où j'ai vu un projet fonctionner et donner entière satisfaction au client dans les délai impartis et en générant une rentabilité maximale pour le prestataire, c'est lorsque le développeur était celui qui recueille le besoin du client. Le développeur en étant confronté au métier comprends les tenants et aboutissants des demandes du client et sait du coup ce qui est important pour la personne qu'il a en face (en terme d'ergonomie, de fonctionnalité etc ...) et sais ce qui serait plus pertinent en terme de composants techno pour mieux répondre à la demande et cela il s’en souviendra au moment d’aligner les première lignes de code. Je ne parle même pas de la motivation et la responsabilisation du développeur qui participe grandement à sa réactivité et sa productivité.

Le client quant à lui sait que toutes ses demandes seront prises en compte car il a en face de lui une écoute attentive qui fera attention au moindre détail y compris les plus anodins, la plupart du temps les moins coûteux à réaliser et qui bien souvent sont la clé de la satisfaction du client.

Je ne dis pas qu’il faut supprimer toutes les couches intermédiaires mais au moins réfléchir à rapprocher le développeur du client car tout le monde y gagnerait !
;)

[kilroyFR]

Chez nous le pb c'est en partie du fait que les prestataires ne sont interessés que par la techno (le metier ils s'en tapent completement).
Du coup ils se font plaisir a faire du code beau, refactoring a gogo, defaire/refaire parce qu'une nouvelle brique logicielle vient de sortir etc. et quand il faut livrer un logiciel qui remplisse des fonctions... ben ca le fait mal ou ca le fait pas.

Les CDP et autres subissent (un peu la fuite en avant - dire d'arreter mettrait encore plus en peril le projet).
Au bout de 25 ans d'informatique je me rends compte que c'est le pb des informaticiens - ils se generent du boulot et oublient l'essentiel quelques fois.

[Guikingone]

Au fond, on touche une partie sensible de l'informatique, peut-on réellement développer un projet en respectant les délais ? Non.

J'ai récemment été confronté au soucis du projet qui part mal, l'idée de base semble bonne, on soumet l'idée, on propose d'y travailler afin de présenter un truc intéressant puis se dresse une muraille de problème.

Premièrement, le projet n'est pas défini correctement, on balance une idée dans le vent, sans réelle but si ce n'est poussé le dév (ma personne) a ajouter des bouts de concept par ci par là en précisant que de toute façon, rien n'est pressé.

Deuxièmement, on commence à t'affecter à des tâches qui n'ont ni queue ni tête et qui bloque le développement du projet, au fond, tu passe plus de temps à faire tout sauf avancer sur le projet.

Troisièmement, on te bloque l'accès à certaines données/applications de développement, tout simplement parce que les infras ne veulent pas tester tel ou tel produit (SharePoint pour ne citer que lui), on bride volontairement certains projets et je trouve cela honteux ...

Dernièrement, le projet sombre dans l'oubli et tu continue sur tes tâches sans queue ni tête, peut-être qu'un jour, il refera surface et sera confié à quelqu'un d'autre, sais t-on jamais ?

Au fond, la faute n'est pas à tel ou tel personne mais plus à un ensemble de circonstances et personnes qui ne veulent pas se donner les moyens d'y arriver sans rejeter la faute sur des tiers.

[Saverok]

Au fond, on touche une partie sensible de l'informatique, peut-on réellement développer un projet en respectant les délais ? Non.

Tout dépend la taille du projet
Fort heureusement, il y a des tas de projets qui sortent dans les délais
Regarde un peu toutes les opérations marketing associées à un portail web et/ou à des applications mobiles

De même, je bosse actuellement sur des applications magasin qui impliquent la mobilisation d'énormément de monde et pas uniquement des ressources IT.
Ne pas être au rdv, n'est même pas concevable (formation du personnels, pub, logistique, etc)

Faut pas trop généraliser non plus
On parle surtout des projets qui vont mal et on ne s'attarde pas assez sur ceux qui vont bien
Cela donne une vision assez négative de la situation

Après, je partage ton point de vu sur les situations décrites (notamment au niveau des équipes sécu avec qui j'ai dû batailler plusieurs mois pour ouvrir une connexion VPN avec le SI d'un prestataire...)

[LeclercqBertrand]

Moi j'aurai commencé cet article en disant "Il arrive parfois en entreprise que les délais de livraison d’un projet de développement soient respectés", tant la tenue des délais est un évènement d'une rareté exceptionnelle, attribuable au hasard et non à la logique.

Nul besoin d'outils d'analyse pour déterminer les causes :
1) Le responsable métier ne comprend pas pourquoi il faudrait écrire un cahier des charges puisque selon lui il a déjà tout expliqué dans un mail.
2) Le chef de projet passe plus de temps à expliquer pourquoi il est en retard plutôt qu'à le résorber
3) Les architectes prennent un plaisir malsain à complexifier l'architecture technique et fonctionnelle
4) Les développeurs errent dans les bureaux à la recherche des spécifications du projet
5) La machine à café est tout le temps en panne

point barre.

[DotCertis]

En plus des causes évoquées par l'auteur, j'en ajouterais une plutôt propre à la France qui est culturelle et qui n'est pas forcément mauvaise : le choix de la qualité au détriment des délais.
Chez nous la tendance est souvent à minimiser au maximum les risques identifiés quitte à décaler une MEP par exemple, notre fameux "ceinture + bretelle". Au delà des simples développements, on demande aussi aux dévs d'avoir un regard critique, d'être capable de remonter des alertes et si alerte il y a alors il faut prendre le temps de résoudre cela en amont, ce qui forcément prend du temps.
Et ça a du sens par rapport aux attentes des clients et des utilisateurs : une appli livrée en retard sera préférable à une appli pas bien finie. Une appli livrée à temps mais buguée dans sa première version sera très rapidement laissée de côté ou définitivement jugée "pourrie" par les utilisateurs.
Pour avoir bosser avec des Américains ou même des Suédois, la deadline a beaucoup d'importance et assez souvent l'idée est de "tant pis on y va comme prévu, et s'il le faut on blindera post go live" quitte à mettre à plein de ressources après la MEP pour rattraper la situation.

[tpericard]

Bonjour,

En plus de tous les arguments avancés par les uns et autres, pour lesquels j'ai moi même constaté la véracité au cours des projets auxquels j'ai participé, il y a aussi une raison + technique sur le délai repoussé de certains projets : - la composition des équipes de DEV.

Trop souvent dans les SSII il y a des équipes de dev constituées, pour faire baisser les coûts, d'une majorité de purs débutants (soit débutant tout court, soit débutants sur les technos employées) avec un petit nombre de "sachants" confirmés. Et trop souvent les estimations sont faites en ne tenant pas compte de cet aspect.
Mais là encore, ce ne sont pas les développeurs qui sont en cause, mais plutôt les financiers qui sont fautifs de tout retard, en n'accordant pas les moyens humains pour un projet !

Au final le développeur fait en grande majorité tout son possible pour satisfaire la demande des clients, mais il n'est pas un faiseur de miracles pour autant

Et un dernier point qui m'a un peu hérissé, si le développeur doit comprendre la fonctionnalité qu'il a à implémenter, et est en droit d'exiger cette explication, ce n'est pas à lui, sauf cas simples ou très pointus, à discuter avec le client final. C'est le rôle de la maîtrise d'ouvrage (MOA et AMOA).

[qadassi]

Dans un langage plus cru, dans la majorité des projets, le développeur est sous-payé car le projet est lui aussi sous-payé et la concurrence féroce entre les startups ou les majors sur les projets a dépassé la limite de la régulation (sensé protégé le client contre la hausses des prix par cupidité) pour descendre trop bas en mettant le fournisseur à la merci du client!

A ce moment, l'industrie du logiciel glisse de secteur pour devenir l'éternel perdant de tout écosystème: le producteur primaire!

Bref, il faudra découper notre secteur en trois, comme d'habitude:

• Le producteur primaire chargé de fournir des composants indépendants des projets, peut-être open-source peut-être propriétaire, très souvent pour son propre compte puis à partager ou vendre
• L'intermédiare chargé de la transformation et de l'adaptation de ces composants
• Le prestataire capable de connaitre les composants existants et les moyens nécessaires à leurs transformations.

Très peu réfléchissent de cette manière, et j'éviterai les détails supplémentaires pour prouver qu'une mauvaise transmission entre secteur sera catastrophique.

Je prendrais juste l'exemple d'un projet ou j'étais du côté du client et que j'ai intégré en milieu de parcours, pour découvrir que le prestataire qui d'ailleurs sous-traitait, n'avait pas une bonne connaissance des composants existants, et avait conduit à la ruine toute la chaine.

Mon avis personnel est que la solution est entre les mains des intermédiares qui doivent s'imposer devant les prestataires et ainsi équilibrer leurs stupides concurrences qui les poussent à raconter les pires aneries qu'ait connu les marchés.
J'ai essayé de redire une des thèses soutenues par l'article dans d'autres termes, pour renforcer l'argumentation, qui peut-être sera élaboré pour passer de thèse à preuve.

Bref, il faut réhausser les prix pour cause de charge supplémentaire de transformation et raréfaction!

[sidewolf]

Vous savez j'ai croisé un français qui bosse au canada, et chez eux ils y a très peu de SSII ou ESN comme il y a chez nous, car les entreprises n'ont pas confiance en eux. En conséquence, les entreprises préfèrent recruter leur informaticien, et de les faire monter en compétences à la fois sur le plan fonctionnel et sur le plan technique. Ainsi les entreprises conserve une indépendance et une autonomie sur le système d'information.

En france les entreprises ont tendance à vouloir trop externaliser l'activité informatique, ils perdent en autonomie et en indépendance, et quand il y a un projet à réalisé ils sont souvent tributaire de la prestation de service. La multiplication des interlocuteurs génère des réunionites qui pour certaines sont stériles et font perdre du temps.

En plus une prestation de services coûte cher à l'entreprise (entre 350€ jusqu'à 1000€ par jour et par homme) en prenant compte du coût mini ça revient à 7000€ (sur 20 jours ouvrés) pour un prestataire... Et la personnellement, je n'arrive toujours pas à comprendre. un salarié et bien moins chère qu'un prestataire de service (salarié entre 4000 (et même moins) et 6000€ charges comprises, prestataire entre 7000€ et 20 000€)
Bon, je sors du sujet du topic ...

@tpericard : je voulais dire que tu as tout à fait raison, car bien souvent on qualifie souvent un jeune qui sort d'un bac+5 d'expert... Et pour cause, j'ai formé des jeunes diplômés sur le décisionnel, une semaine après, ils sont en clientèle avec l'étiquette d'expert... et on leur dit pour les rassurer : "Rassure toi, tu en sais plus que le client " MDR quand c'est pas le cas, et c'est déjà arrivé

[dfiad77pro]

Vous savez j'ai croisé un français qui bosse au canada, et chez eux ils y a très peu de SSII ou ESN comme il y a chez nous, car les entreprises n'ont pas confiance en eux. En conséquence, les entreprises préfèrent recruter leur informaticien, et de les faire monter en compétences à la fois sur le plan fonctionnel et sur le plan technique. Ainsi les entreprises conserve une indépendance et une autonomie sur le système d'information.

En france les entreprises ont tendance à vouloir trop externaliser l'activité informatique, ils perdent en autonomie et en indépendance, et quand il y a un projet à réalisé ils sont souvent tributaire de la prestation de service. La multiplication des interlocuteurs génère des réunionites qui pour certaines sont stériles et font perdre du temps.

En plus une prestation de services coûte cher à l'entreprise (entre 350€ jusqu'à 1000€ par jour et par homme) en prenant compte du coût mini ça revient à 7000€ (sur 20 jours ouvrés) pour un prestataire... Et la personnellement, je n'arrive toujours pas à comprendre. un salarié et bien moins chère qu'un prestataire de service (salarié entre 4000 (et même moins) et 6000€ charges comprises, prestataire entre 7000€ et 20 000€)
Bon, je sors du sujet du topic ...

@tpericard : je voulais dire que tu as tout à fait raison, car bien souvent on qualifie souvent un jeune qui sort d'un bac+5 d'expert... Et pour cause, j'ai formé des jeunes diplômés sur le décisionnel, une semaine après, ils sont en clientèle avec l'étiquette d'expert... et on leur dit pour les rassurer : "Rassure toi, tu en sais plus que le client " MDR quand c'est pas le cas, et c'est déjà arrivé

La différence entre un prestataire et un interne , c'est que le prestataire on peut le virer quand on veut.
Je pense que c'est une des raisons majeur de l’attrait des SSII pour les entreprises.

[el_slapper]

La différence entre un prestataire et un interne , c'est que le prestataire on peut le virer quand on veut.
Je pense que c'est une des raisons majeur de l’attrait des SSII pour les entreprises.

C'est l'unique, ou presque. Après, on peut avoir besoin de prestataires pour des besoins ponctuels. Mais c'est 10% de l'activité en France.

[Baudis]

La différence entre un prestataire et un interne , c'est que le prestataire on peut le virer quand on veut.
Je pense que c'est une des raisons majeur de l’attrait des SSII pour les entreprises.

ça c'est une vue de l'esprit ...
Comme on tegiverse au démarrage, en général on commence à la bourre, et "le virer" signifiant du retard, cela suppose d'argumenter, plus le temps passe plus ça devient difficile...
De plus pour pouvoir "argumenter", il faut avoir suivi, le problème c'est qu'à force de sous-traiter on n'a justement plus le potentiel nécessaire pour suivre.

[Saverok]

Vous savez j'ai croisé un français qui bosse au canada, et chez eux ils y a très peu de SSII ou ESN comme il y a chez nous, car les entreprises n'ont pas confiance en eux. En conséquence, les entreprises préfèrent recruter leur informaticien, et de les faire monter en compétences à la fois sur le plan fonctionnel et sur le plan technique. Ainsi les entreprises conserve une indépendance et une autonomie sur le système d'information.

En france les entreprises ont tendance à vouloir trop externaliser l'activité informatique, ils perdent en autonomie et en indépendance, et quand il y a un projet à réalisé ils sont souvent tributaire de la prestation de service. La multiplication des interlocuteurs génère des réunionites qui pour certaines sont stériles et font perdre du temps.

En plus une prestation de services coûte cher à l'entreprise (entre 350€ jusqu'à 1000€ par jour et par homme) en prenant compte du coût mini ça revient à 7000€ (sur 20 jours ouvrés) pour un prestataire... Et la personnellement, je n'arrive toujours pas à comprendre. un salarié et bien moins chère qu'un prestataire de service (salarié entre 4000 (et même moins) et 6000€ charges comprises, prestataire entre 7000€ et 20 000€)
Bon, je sors du sujet du topic ...

Ce sujet est régulièrement abordé sur le forum
En France, le SI a très longtemps été perçu uniquement comme une charge modulable.
Autrement dit, il doit être possible de très rapidement en réduire le coût lorsque l'activité de l'entreprise décroit.
D'où une externalisation massive des ressources IT afin d'avoir cette modularité.
De plus, en France, les charges patronales sont élevées et énormément de dispositifs sont calibrés en fonction de la masse salariale (les fameux effets de seuils)
Externaliser, c'est aussi réduire sa masse salariale...

Je dis cela au passé car les choses commencent tout doucement à changer.
Les entreprises commencent à réaliser que leur métier est de plus en plus porté par le SI et que ce SI, n'est pas juste une charge mais aussi un acteur majeure de leur activité.
De même, grâce au web notamment et au cross canal, le SI est aussi un vecteur d'innovation dans le cœur de métier de l'entreprise ainsi qu'un axe de croissance.
Bref, la perception du SI par les entreprises françaises est en train de changer et cela a pour conséquence une internalisation des ressources IT.
Ce phénomène débute seulement et c'est très timide.
Mais ça vient, petit à petit et c'est amené à s'amplifier avec le temps.

[laloune]

Pour moi, le plus gros soucis est que celui qui réalise n'est pas toujours (voir pas souvent) celui qui va discuter avec la personne qui émet le besoin...

c'est parfois nécessaire je pense... parfois celui qui réalise n'a ni l'envie ni les compétences pour discuter avec les gens du métier. Le développeur s'en fout plus ou moins de savoir ce qu'est l'actif ou le passif, ou le compte de résultat, pour lui il y a des tables, des colonnes et des lignes (c'est caricatural mais c'est l'idée)

selon moi ca devrait être le rôle du CP de faire l'interface entre le client et les développeurs : ou pour les projets plus gros, un CP et un CP technique qui travaillent de concert

après c'est sûr que tout dépend aussi de la taille du projet

[Guikingone]

Je soutient laloune sur sa vulgarisation de la vision d'un tel, on est tous confrontés à ce genre de personne qui ne comprend rien mais qui dirige, avouons-le, 95 % des gens qui commandent ne savent pas diriger ...

[conor]

Ce que je lis dans les posts précédents est le vécu de tout développeur.

Je pense que ce qui pèche c'est le fait que tout le monde s'écrase devant le "client roi" au lieu de discuter (or tout client censé est prêt à écouter et comprendre des arguments). Je m'explique : le client a envoyé le cahier des charges de son projet complet, c'est chiffré, validé et les dév ont démarré. Puis le client demande une modification mineure d'un point de vue fonctionnelle mais qui a un gros impact technique, on lui dit d'accord sans autre négociation et sans rien réétudier des spécs techniques ni du chiffrage (ne surtout pas dire au client qu'on va modifier un budget validé)... et pan!, le mur assuré.

Autre problème que je juge sérieux : les compétences... et oui ! c'est important. J'ai bossé dans des boîtes où les chefs de projet étaient des stagiaires d'écoles de commerce et qui ne connaissaient de l'informatique que leur profil Facebook... Bonjour la cata !

[dba01]

Selon mon expérience personnelle, je vois trois points principaux à surveiller :

1 - La maîtrise d'ouvrage :
Ca a été mon cas durant plusieurs années. Heureusement, j'avais les deux formations. De nombreuses années dans la profession du client, et des expériences personnelles de développements pour des hobbies de loisirs. J'avais donc plus de facilités pour traduire les besoins clients en logique informatique. Il m'est arrivé de faire traîner un client quand je ne parvenais pas à mettre de l'ordre dans mes idées. Mais ensuite, quand j'ai commencé à lancer les développements, c'est rentré comme dans du beurre. Même les évolutions, quand le client a vu ce qu'on pouvait faire et que ça lui a donné des idées, sont passées sans douleurs.
La maîtrise d'ouvrage n'est pas juste une fonction, elle demande des compétences spécifiques. Et l'analyse ne se borne pas à écrire ce que le client a demandé, mais plutôt ce dont le client a besoin. J'ai vu un cas où il fallait même lui expliquer son métier.

2 - La documentation :
Il est bien connu que les docs ont été archivés et que les archives ont été purgées pour gagner de la place de stockage. Donc les seules infos restantes sont dans le code source. Celui-ci doit alors contenir des infos clients, des motifs, des dates, voir parfois des noms, permettant de retrouver pourquoi on a pris telle option, pourquoi tel enregistrement de telle dimension en tel endroit. Dans des systèmes utilisés par plusieurs services voir plusieurs filiales dans le monde, tout modif peut provoquer des catastrophes. J'ai vu des sources contenant bien plus de commentaires que de code réel, mais c'était bien pratique pour intervenir ou évoluer.

3 - Ecoutez-vous les uns les autres :
La machine a café est un outil de travail formidable. On y apprend les obsessions et angoisses des autres. On peut avoir des idées à leur transmettre, des questions idiotes à leur poser. Le coup du document qui descend la cascade, du patron à l'employé, de l'employé à l'analyste, de l'analyste au programmeur, ça plantera toujours. Faut pouvoir remonter, s'expliquer. Ne pas jeter systématiquement en disant que l'autre ne comprends rien : à moins qu'il ne soit complètement débile, il y a sûrement une explication, souvent contournable. Et les mots utilisés n'ont pas toujours la même significations pour l'un et pour l'autre. J'ai vu mon informateuse me poser des questions commerciales. Et le pire, c'est qu'il lui est même arrivé d'avoir raison !
Soyez ouverts, discutez, comprenez, ce n'est pas du temps de perdu.
Vous n'êtes pas des martyrs, les autres aussi ; c'est le commerce !

[dfiad77pro]

3 - Ecoutez-vous les uns les autres :
La machine a café est un outil de travail formidable. On y apprend les obsessions et angoisses des autres. On peut avoir des idées à leur transmettre, des questions idiotes à leur poser. Le coup du document qui descend la cascade, du patron à l'employé, de l'employé à l'analyste, de l'analyste au programmeur, ça plantera toujours. Faut pouvoir remonter, s'expliquer. Ne pas jeter systématiquement en disant que l'autre ne comprends rien : à moins qu'il ne soit complètement débile, il y a sûrement une explication, souvent contournable. Et les mots utilisés n'ont pas toujours la même significations pour l'un et pour l'autre. J'ai vu mon informateuse me poser des questions commerciales. Et le pire, c'est qu'il lui est même arrivé d'avoir raison !
Soyez ouverts, discutez, comprenez, ce n'est pas du temps de perdu.
Vous n'êtes pas des martyrs, les autres aussi ; c'est le commerce !

Tu parles de la machine à café,
quand tu te retrouve avec une bande de beauf non passionnés qui ne parlent que de Foot