Discussion :

[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).

[Carhiboux]

"A qui la faute" n'est certainement pas la bonne question à se poser, ça revient à trouver un bouc-émissaire et à ne pas se remettre en question soit-même. C'est tellement plus facile de rejeter sur la faute sur autrui que de reconnaître ses erreurs.

Entièrement d'accord avec toi. Mais hélas...

[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.

[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.

[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...)

[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

[landry161]

Entièrement d'accord avec toi. Mais hélas...

Actuellement je bosse sur un projet et bientôt je serai a la quatrième étape. Je meurs de trouille.

[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.

[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 !

[Baudis]

J'ai été développeur, chef de projet dans une société de service.
J'ai été chef de projet dans une grosse boite pour des développements interne
Je suis chef de projet dans le même boite mais maintenant les développement sont externe...
J'ai subi des pressions, des demandes de chiffrages des demandes contradictoires de mes clients et de mes chefs de mes clients externes ou internes. J’ai connu d’excellent développeurs, j’en ai connu qui n’étaient pas fait, d’autres pas formés pour ce métier.
En gros j'ai tout vu.

Concernant les problèmes de développement que nous rencontrons aujourd'hui, on peut dire que tout est fait pour se planter:
1- Dans les formations initiales j’ai l’impression que l’accent est mis sur le WEB et qu’on oublie le Temps réel.
2- Chez les gros donneurs d’ordre, on a tendance à oublier l’expérience car on considère qu’il faut que les gens bougent pour évoluer et que demander à un « vieux » ce qu’il veut peut aboutir à une sorte de sclérose. Du coup le cahier des charges, en devient approximatif et le suivi indispensable est sous-évalué donc mal fait.
3- Chez les jeunes informaticiens, je ne sais pas si c’est la conséquence des classes, puis des amphis surchargés, mais plus personne ne pose de question. En cas de problème on fait le canard, on contourne et on continue, quitte à tout refaire, comme si « ne pas savoir » était une marque de faiblesse.
4- Au niveau organisation il me semble que dans les grosses boites d’informatique on en revient à ce que j’ai connu au début de ma carrière : des analystes, des analystes-programmeurs, des programmeurs et des opérateurs de saisie ! On ne les appelle plus ainsi, mais ça revient au même. Le résultat c’est que ceux qui développent, ne connaissent pas le besoin d’origine et ne savent pas comment ce sera utilisé.
5- Les processus mis en place pour s’assurer que la chaine de développement permettra de fournir le bon produit sont rapidement court-circuités car trop lent.
6- Enfin la législation sur le travail qui empêche un donneur d’ordre de monter une équipe hétérogène en sous-traitance interne et de la gérer en direct ne permet pas de monter rapidement en capacité sur les gros projets. Comment, en effet, une seule société Informatique pourrait-elle disposer de toutes les compétences nécessaires et disponibles au jour J sur le bon site ?

[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

[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.

[Matthieu Vergne]

Pour une fois, je vais faire court.

cf. l'ingénierie des exigences.
http://fr.wikipedia.org/wiki/Exigenc...C3%A9nierie%29
http://cms.specief.org/conc/index.ph...des-exigences/
http://www.techniques-ingenieur.fr/f...omplexe-0270/#

Et pour ceux qui sont plus intéressés par les techniques, regarder du côté de i* (i star), Tropos, Kaos et autres techniques de goal modelling.