Discussion :

[Michael Guilloux]

Étude : 50 % des projets de développement d'applications se soldent par un échec
cela est-il dû à la lenteur des codeurs et la dette technique ?

Si une entreprise peut se permettre de démarrer de nouveaux projets informatiques chaque année, garantir leur succès est une chose qui est bien moins évidente. Pour réussir, un projet doit en effet respecter des contraintes de coût, de délai et de qualité (respect des exigences définies par le cahier de charges). Mais dans la pratique, il est difficile de voir un projet respecter ces 3 critères, et les meilleurs projets sont ceux qui arrivent à terme avec un écart relativement faible par rapport à ces critères.

Plusieurs études ont été menées sur la réussite des projets informatiques, et la plupart s'accordent sur le fait qu'une bonne partie (parfois la majorité) des projets informatiques se soldent par un échec. Précisons que la notion d'échec ici signifie que soit le projet n'est jamais lancé ; soit il est lancé, mais n'est jamais terminé ; soit il est terminé, mais ne répond pas aux besoins exprimés par les utilisateurs. C'est cette définition d'échec qui a été utilisée dans une étude menée par IDG (International Data Group) pour la plateforme de développement low-code Appian.

Pour cette étude, plus de 500 décideurs et responsables IT issus d'entreprises de plus de 1000 employés ont été interrogés. Précisons que plus de la moitié des répondants étaient des employés dits de niveau C (CIO, CTO, CSO). L'étude montre que les grandes entreprises aux États-Unis et en Europe (Allemagne, Espagne, France, Royaume-Uni) adressent chaque année à l'IT en moyenne 180 demandes de nouveaux projets (développement d'applications, améliorations ou autres). Ce qui, selon IDG, indique que ce type de demande monte en flèche au niveau mondial. Par région, les entreprises européennes font beaucoup plus de demandes que leurs homologues US. Le nombre de demandes de nouvelles applications ou améliorations chaque année s'élève à 150 en moyenne pour une entreprise US, contre 230 pour une entreprise de la zone EMEA (Europe uniquement).

Toutefois, le résultat le plus frappant de l'étude est que 50 % de toutes les nouvelles demandes de développement d'applications se soldent par un échec. Dans les détails, l'étude révèle que 15 % de ces projets ne sont jamais lancés, 15 % ne sont jamais terminés et 20 % sont livrés, mais ne répondent pas aux besoins de l'entreprise.

Aux États-Unis, le département Marketing est plus susceptible que les autres départements de demander de nouvelles applications, tandis que dans la zone EMEA, c'est le département Ventes qui est le plus gros demandeur d'applications.

Quelles sont les causes d'un tel taux d'échec ? Dans ce qui ressemble à une tentative de désigner des responsables, le rapport indique que « les services informatiques ont du mal, ou n'arrivent pas, à répondre aux besoins évolutifs de l'entreprise, principalement en raison de la lenteur du codage et des problèmes liés à la dette technique. » La dette technique, définie comme le coût implicite du travail supplémentaire lié au choix d’une solution facile immédiate au lieu de la solution appropriée de long terme, « représente une partie majeure du problème », peut-on lire dans le même rapport.

D'après l'étude, si les équipes IT passent 50 % de leur temps à coder de nouvelles applications et améliorations, elles prennent environ 40 % du temps consacré au développement pour gérer la dette technique. La dette technique a donc un impact considérable sur les entreprises. En effet, pour 55 % d'entre elles, la dette technique augmente les coûts opérationnels. 52 % des répondants estiment aussi que la dette technique fait que le développement d'une fonctionnalité simple prend plus de temps que prévu. Jusqu'à 47 % estiment encore que la dette technique réduit les performances et l'évolutivité des applications, alors que pour 37 % des personnes interrogées, cela rend plus long le temps nécessaire pour mettre une application sur le marché. Enfin, 17 % des répondants estiment que la dette technique empêche les améliorations de l'expérience client. Seuls 5 % des entreprises disent ne pas avoir expérimenté de dette technique.

Pour ce qui est des sources de la dette technique, aux États-Unis, ce sont les décisions IT (47 %) et la pression de livrer les applications (43 %) qui sont le plus souvent pointées du doigt. En Europe, c'est plutôt la mauvaise documentation des exigences des projets (42 %).

Sources : Appian, Infographie de l'étude, Détails de l'étude

Et vous ?

Que pensez-vous des résultats de l'étude ?
Quels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?
En tant que développeur, gérer la dette technique fait-il partie de votre quotidien ? Combien de temps y accordez-vous en moyenne dans la semaine ?

[Ryu2000]

Pour réussir, un projet doit en effet respecter des contraintes de coût, de délai et de qualité (respect des exigences définies par le cahier de charges).

Je suis contre le concept de "cahier des charges" pour les projets informatique.
Il faut trouver d'autres solutions.
Le client n'exprime pas correctement son besoin, les développeurs comprennent mal le besoin du client, le besoin du client évolue, etc.
Il faut faire du développement agile, il faut avoir des réunions régulière avec le client pour qu'il puisse guider la direction à prendre.

Dans les détails, l'étude révèle que 15 % de ces projets ne sont jamais lancés, 15 % ne sont jamais terminés et 20 % sont livrés, mais ne répondent pas aux besoins de l'entreprise.

Ça il faudra s'en rappeler : 20% des projets livrés ne répondent pas aux besoins de l'entreprise.
Ça veut dire que c'est hyper commun qu'une entreprise paie des développeurs pendant longtemps pour rien du tout.

Il y a des développeurs qui ont travaillé pendant des années, pour rien.

[blbird]

Personnellement, au niveau des grandes entreprises, ce qui est le plus impactant pour les nouvelles ou les modifications d'applications existantes, ce sont les délais demandés par les métiers.

Très souvent ces délais sont ridiculement faibles comparé aux temps de développement. Dernièrement, dans une grande entreprise, le métier m'a expliqué que 90 jours de charges de développement d'un nouveau projet informatique c'était beaucoup trop, ils le voulait fini en moins d'un 1 mois. Leur solution (véridique) : mettre 9 développeurs et c'est fini en 10 jours...

[Ryu2000]

mettre 9 développeurs et c'est fini en 10 jours...

C'est comme la blague du chef de projet qui pense qu'en mettant 9 femmes il peut avoir un bébé en 1 mois.

[redcurve]

Avec des délais qui ne correspondent à rien, une organisation des entreprise datant du 19ème siècle, des décideurs qui ne savent rien etc. oui le taux d'échec est nécessairement faramineux.

[mister3957]

Pour moi la principale cause est la course au moins cher / au plus rapide, sinon c'est le concurrent qui choppe le projet.

Alors pour rentrer dans les exigences clientes, dans les bons chiffres qui vont bien lors d'une réponse à appel à projet, les commerciaux sortent des trucs de leurs chapeaux, enquillent leurs primes et ensuite les pilotes / techs se débrouillent avec ce qu'ils ont.

Du coup on met moins de bonhommes, et on en met des pas chers, on limite fortement la préparation au projet et donc son pilotage dans l'ensemble et puis il n'y a plus qu'à presser les devs comme des citrons avec objectif "le bouton il faut qu'il marche". Et si ça foire, c'est à cause d'eux.

Par ailleurs il y a encore beaucoup trop cette mentalité "le client est roi" qui fait qu'on lui laisse trop de pouvoir dans le pilotage (alors que l'on est sensé lui vendre ça aussi, ainsi que l'accompagnement et de la conduite du changement).

Parfois lorsque ça ne correspond pas au besoin, ça peut venir également du client, ils ont des gugusses aussi de leur côté qui sont bien éloignés des utilisateurs finaux. Donc la maîtrise d'ouvrage comme la maîtrise d'oeuvre sont bâclées, d'ailleurs les frontières ne sont pas claires dès le départ.

Pour des projets internes, c'est pareil, sauf que le client ce sont ces fameux "mecs du conseil".

L'agilité c'est bien mais peu comprennent ses rouages et très très peu y sont formés, c'est souvent pour faire effet de mode c'est tout mais dans le fond les roadmaps sur des années sont bien là, et à respecter car déjà vendues. Ça arrange bien les "chefs", on a posé le déterminisme du cycle en V sans se casser la tête à écrire ces specs barbantes.

Mais du coup c'est pire, les devs doivent avancer à l'aveugle, bouton après bouton, et au moindre sujet de fond qui tombe, ça fait parfois mal, souvent trop mal, et flop ! En général les gens se barrent, et puis on reprend les mêmes "chefs", les mêmes commerciaux, et on revend des trucs, on trouve d'autres petits jeunes et on recommence.

J'ai déjà entendu dire "ce qui nous fait gagner de l'argent, c'est pas le projet mais sa TMA". Et j'ai taffé dans une boite où la stratégie était de berner le clients jusqu'à ce qu'il atteigne un point de non retour financier, donc obligé de continuer avec eux, ça fait de la tréso régulière, de la visibilité financière, un monde parfait, c'est génial... jusqu'à ce que le juridique du client s'en mêle, un autre avantage de l'agilité, on ne s'engage pas, c'est parfait.

[Grogro]

Avec des délais qui ne correspondent à rien, une organisation des entreprise datant du 19ème siècle, des décideurs qui ne savent rien etc. oui le taux d'échec est nécessairement faramineux.

Et des subordonnés (cadres intermédiaires, chefs de service, product owners) qui n'osent remonter aucune alerte aux décideurs, aucune information discordante, de peur que la tête qui dépasse se prenne le coup de marteau.

[mister3957]

Et des subordonnés (cadres intermédiaires, chefs de service, product owners) qui n'osent remonter aucune alerte aux décideurs, aucune information discordante, de peur que la tête qui dépasse se prenne le coup de marteau.

L'ingérence.. ça ressemble à un art de vivre dans notre métier.

99% de ce que l'on fait se trouve sous un capot avec 10.000 verrous, donc l'ingérence est ultra propice.

Il n'y a qu'à voir dans l'univers automobile, on peut ouvrir le machin, le décortiquer, l'analyser, ça donne lieu à des études, des magazines papier / émissions de TV, tout est transparent.. sauf lorsque ça touche au numérique, boites noires, donc on en profite pour y mettre des saloperies dedans, on s'en fou y'a personne qui voit.

[sergio_is_back]

Je suis contre le concept de "cahier des charges" pour les projets informatique.
Il faut trouver d'autres solutions.

Ça a au moins le mérite de poser les bases. Mais comme beaucoup je reçois des CDC qui tiennent sur deux pages rédigés à la vite

Le client n'exprime pas correctement son besoin, les développeurs comprennent mal le besoin du client, le besoin du client évolue, etc.

Oui tout ça c'est vrai... Il faut souvent passer beaucoup temps que ce soit au téléphone, sur site avec le client pour bien préciser les limites et tous les aspects...
Cet aspect là n'est pas pris en compte dans un chiffrage souvent et c'est pourtant primordial, plus un CDC est flou et plus il faut chiffrer et vendre de l'analyse et de la gestion de projet
Alors comme souvent ça n'a été chiffré et vendu on évite de perdre du temps avec ça et le projet part en sucette...

Il faut faire du développement agile, il faut avoir des réunions régulière avec le client pour qu'il puisse guider la direction à prendre.

Attention avec le développement Agile j'ai vu certaines boîtes faire tester le soft directement par le client et livrer 10 ou 12 versions dans la semaine avec des bugs d'affichage et même des plantages pur et simples en production dans ces cas c'est du détournement de ressources pur et simple et des pertes d'exploitation pour le client et ça nui à la relation avec celui-ci

[Ryu2000]

Ça a au moins le mérite de poser les bases. Mais comme beaucoup je reçois des CDC qui tiennent sur deux pages rédigés à la vite

D'un côté c'est parfois mieux.
Il faut juste bien comprendre les fonctions principales et commencer par concevoir ça.
Avoir un cahier des charges qui contient trop de petits détails qui ne servent à rien, ça fait perdre du temps... C'est un coup à développer plein de fonctions qui ne servent à rien.

C'est quasi impossible de savoir à l'avance ce qui serait le mieux pour le client dans des années.

Exemple de bon cahier des charges (Citroën 2 chevaux) :

« Faites étudier par vos services une voiture pouvant transporter deux cultivateurs en sabots, cinquante kilos de pommes de terre ou un tonnelet à une vitesse maximum de 60 km/h pour une consommation de tois litres d’essence aux cent. En outre, ce véhicule doit pouvoir passer dans les plus mauvais chemins, il doit être suffisamment léger pour être manié sans problèmes par une conductrice débutante. Son confort doit être irréprochable car les paniers d’oeufs transportés à l’arrière doivent arriver intacts. Son prix devra être bien inférieur à celui de notre Traction Avant »

Oui tout ça c'est vrai... Il faut souvent passer beaucoup temps que ce soit au téléphone, sur site avec le client pour bien préciser les limites et tous les aspects...

Il faut être en contact avec ceux qui utilisent réellement l'outil.
Avoir une réunion 2 fois par mois pourrait être utile.

j'ai vu certaines boîtes faire tester le soft directement par le client et livrer 10 ou 12 versions dans la semaine

D'un côté ça fait gagner du temps sur le test, vu que c'est le client qu'il les fait ^^
Par contre si c'est en production ça craint...

[Doksuri]

Quels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?

les delais trop cours et le manque de reflextion avant le lancement du projet (surtout par les non-dev).
on ne vous consulte pas et un jour : "bon, on va faire le projet X, on a 3 mois" .... au bout d'un moment, on se trouve confronte a un probleme : "mais vous avez pense a X ? et Y ? et pourquoi vous n'avez pas pense a Z ?"
du coup, comme les devs sont deja engages, on trouve des solutions a l'arrache. ce qui amene a la reponse suivante ....

En tant que développeur, gérer la dette technique fait-il partie de votre quotidien ? Combien de temps y accordez-vous en moyenne dans la semaine ?

gerer la dette tecnique est le quotidien... si on prend du debut du codage a la resolution du dernier bug remonte par le client : 50% du temps
exemple : si le dev dure 3mois, on va debugger pendant 3mois (pas a 100% de debug, on va faire d'autres projets en meme temps) mais pendant 3mois, on aura une petite liste de bugs a traiter

[Edrixal]

Que pensez-vous des résultats de l'étude ?

Déjà les 15% qui ne commence jamais son probablement du aux clients qui font une demande mais qui ce rendent compte qu'elle ne rentre pas dans leur budget et la remette donc à plus tard. (dans la boite ou je bosse on à trois projet en attente comme ça depuis le début de l'année.).

Pour le reste, c'est plutôt inquiétant... Mais bon quand je vois que l'un de nos clients à voulut faire appel à une entreprise multi nationale qui avais les moyens de mettre une équipe de 15/20 personnes pour refaire entièrement leur outil principal et que cette entreprise n'a rien été capable de sortir d'autre que des maquettes en presque 2 ans. Sa ne m'étonne guère...

Quels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?

Si je reprend l'exemple cité plus haut, une très très très mauvaise approche du projet. Je ne vais pas entrer dans les détails, mais quant à la première réunion ils ont annoncer qu'ils allaient tout mettre sur un seul écran qui sera modulable, j'ai eu du mal à ne pas exploser de rire. Résultat 2 ans après ils ont décider que finalement ils allais garder une structure plus proche de ce qui existe aujourd'hui, parce qu'il y à énormément de problématique qu'ils n'avais pas pris en compte.

Et oui quand il y à une trentaine de calculateur différent qui ont tous leur particularité et qu'ils peuvent tous évoluer de manière différente c'est une vrais folie que de vouloir tout généralisé...

Après y'a le client aussi, qui ne sais jamais exactement ce qu'il souhaite, et qui oublie toujours ses petits détails qui font qu'un développement simple devient super compliquer et qui double le temps de dev et de recette. Details bien sur qui sont ressortie au premier jours de recettage par le client. Pas avant.

En bref, le travail de chef de projet c'est pas donner à tout le monde, j'ai de la chance de bosser avec des personnes qui préfèrent dire non à un projet qu'ils estime non viable plutôt qu'avec des personnes qui promettent mont et merveille et qui nous foutent dans la merde par la suite. Cette gestion réfléchie fait que nos clients sont content et que nous n'avons jamais eu à livrer avec plus d'un jour de retard. (En même temps en moyenne nos projets sont sur trois mois maximum).

C'est ça là le problème je pense, les décideurs qui aguiche le client en leur promettant un truc parfait en trois semaines alors qu'il faudrait un mois de dev.

En tant que développeur, gérer la dette technique fait-il partie de votre quotidien ? Combien de temps y accordez-vous en moyenne dans la semaine ?

Je répondrais oui sur la maintenance de vieux logiciel. Dans un premier ça représenter 80% des demandes clients, corriger les bugs existants. Avec le temps ça à heureusement diminuer, mais y'a toujours des partie de l'application ou personne ne va et qui remonte de temps en temps un problème "L'autre jour en allant ici j'ai vue un message d'erreur bizarre apparaitre, vous pouvez regardez ça ?" ^^'

Après sur la maintenance des logiciels que j'ai produit, il y à très peut de dette techno, souvent c'est le client qui revient nous dire "Ca bug, il faudrait que dans le ce cas précis ça fasse comme ça !" sauf que ce cas particulier n'avais jamais été évoquer au cours de nos discutions et recettage. De ce fait je ne vois pas ça comme un bug mais plus comme une demande d'évolution.
Après comme je l'ai dit plus haut, je suis dans une boite ou on préfère ne pas avoir un contrat trop borderline plutôt que d'accepter un truc que l'on sera obliger de bâcler pour le livrer à temps.

[Matthieu76]

En tout cas j'ai l'impression que le problème viens très rarement des développeurs. C'est plus un problème incompréhension entre le business et les responsables IT.

[el_slapper]

Il arrive que les développeurs ne soient pas au niveau. Ca s'est vu. Mais les contraintes idiotes sont quand même une source d'échec importante. Avec aussi la taille du projet. Plus il est gros, plus il risque de se bananer(d'ou le découpage en lot chez les gens sérieux, qui peut même être poussé jusqu'à l'agile, dans certains cas).

J'ai vu beaucoup de projets se vautrer, mais les seuls auquel j'ai participé était et de loin les deux plus gros de tous ceux sur lesquels j'ai bossé, et dans les deux cas, des décisions du grand chef sont responsables.

1. un projet de 5000 jours, 1200 déjà consommés, un premier lot déjà prêt, un ROI estimé de 18 mois sur l'élimination de la dette technique, le le PDG coté client qui décide d'annuler ce projet(et plein d'autres) pour faire un cadeau aux actionnaires.
2. un projet de 60 personnes sur 18 mois pour refondre un référentiel client. Les specs ont deux ans d'âge, et ne correspondent donc plus à la réalité du terrain, mais on a interdiction de les adapter : le vice-président coté client a signé avec son sang, et il refuse toute adaptation pour des motifs aussi futiles que "ça ne marchera jamais". Accessoirement, il y avait des choix techniques aberrants en termes de performances qui auraient pu planter à eux seuls le projet. 6 ans plus tard, ils n'avaient toujours pas eu l'occasion de le faire. Projet mis à la benne et recommencé avec une autre solution(dont je ne sais rien de plus).

50% de projets plantés, ça me parait énorme, mais si ils ont fait un filtre préliminaire sur la taille et ignoré tous les projets de 100/200 jours que j'ai toujours vu finir à peu près correctement, soudain, ça devient réaliste, à mon sens.

Le meilleur chiffre de l'étude, c'est quand même 40% des couts générés par la dette technique. Genre de chiffre qu'il faudra que je ressorte. Parce-que souvent on m'a demandé de faire "vite et mal, on s'en fout", de la part de gens qui passent leur temps à beugler contre les couts de maintenance. Il est arrivé que je prenne, hélas, des raccourcis, mais j'essaye d'éviter autant que je peux. Et pas seulement au niveau du code. La doc et essentielle aussi. Je n'oublierais jamais ce jour de 2012 ou j'ai sauvé mes fesses grâce à une personne qui en 1995 avait pris la peine d'imprimer tous ses mails avant de partir à la retraite. Au milieu de ces 300 pages, j'ai trouvé la réponse à ma question(et je me suis arrangé pour que le code devienne auto-documenté, comme ça, si on perd la relique, yaka lire le code).

J'entends souvent "mais pourquoi tu te fais chier à mettre tout ça dans des fonctions alors qu'un bête copier-coller marche aussi bien". J'ai une réponse, maintenant : "pour ne pas perdre 40% de mon temps en dette technique".

[sirthie]

Je suis contre le concept de "cahier des charges" pour les projets informatique.

Ne pas oublier que le cahier des charges offre une certaine protection juridique aux parties contractantes, je suppose d’autant plus importante qu’il est détaillé. En cas de suppression de celui-ci, il faudrait trouver autre chose pour le remplacer.

Le client n'exprime pas correctement son besoin, les développeurs comprennent mal le besoin du client, le besoin du client évolue, etc.
Il faut faire du développement agile, il faut avoir des réunions régulière avec le client pour qu'il puisse guider la direction à prendre.

Je dois avouer qu'en matière de conception web, je suis tombé sur des clients, au moins des clients néophytes ne sachant pas exprimer leur besoin voire attendant de leur prestataire qu’il leur révèle leur besoin, genre : “Vous savez très bien ce qu’il me faut”, “Tous nos documents sont à votre disposition” (des rapports d’activité annuels !), etc. Alors, des fois, faut pas trop compter sur le client. Souvent, aussi, il faut lui faire comprendre que son désir ne correspond pas nécessairement à son besoin, et lui démonter quel est ce besoin.

Allez, un lien :
La solitude de l’architecte d’information

[JCD_31]

Chez nous, nous avons tout ce qu'il faut pour réussir un projet :

- Un directeur qui ne parle que de délocaliser la production parce que c'est trop cher
- Un "manager" qui donne l'impression d’être un technicien que l'on a catapulté manager et qui n'a aucune espèce d'idée de ce qu'il fout là (et qui passe plus de temps à faire de la veille techno que des trucs de manager)
- Un "architecte" arrogant et incompétent qui ne manquera pas de te rabaisser à la moindre occasion ("mais tu sais pas ça ? mais t'es un gros nul ! ")
- Un commercial. Tout est dans ce mot.
- Un chef de projet interne. Bon, ok, rien à dire sur celui là, il tient la route et il est compétent.
- Une "responsable projet" hystérique et intrusive qui n'a que les mots "marge", "estimation", "reste à faire" et "points de fonction" à la bouche.
- Des développeurs juniors découvrant ce monde merveilleux, jetés comme des Hobbits en Mordor.
- Des développeurs séniors qui se cassent parce qu'ils en ont assez ce cette merde
- Et moi, entre deux eaux, assez blasé de la vie pour m'en frangipaner de tout ça, et qui ne regarde que la somme inscrite en bas de son bulletin de paie en fin de mois et qui se dit qu'il devrait changer de métier.

[pmithrandir]

Je pense que les résultats de cette étude sont logique, et que paradoxalement, ils explore une solution assez hazardeuse.(temps de codage et dette technique)

la différence USA / Europe s'explique pour ma part par l'avance considérable sur 2 pooints qu'ont les USA :
- l'agilité d'entreprise, l'écoute de toutes les idées, la hierarchie plus accessible, etc...
- la possibilité d'embaucher et de se passer de prestataire. (donc d'etre vraiment agile)

Quand on peut mettre toutes les personnes du projet autour de la table, parce qu'ils sont tous salariés de la boite ca va plus vite que si on doit faire un cahier des charges, un appel d'offre, un engagement forfaitaire, etc...

[el_slapper]

(.../...)la hiérarchie plus accessible, etc...(.../...)

ça, c'est un sujet énorme en soi. Je suis au CHSCT, alors j'entends parfois des histoires assez édifiantes. Entendu juste hier, un exemple; deux programmeurs se sont fait refourguer un projet merdique, non documenté, avec forte pression pour livrer. A la mi Juillet, la chef va les voir :

_Bon, ben on en a besoin pour fin Juillet. Donc vous aurez fini.
_Hein? Quoi? mais même fin Septembre, c'est impossible, vu tout ce qu'il reste à faire, et toute la dette technique à travers laquelle nous nageons!!!(notons que la chef comprend le terme de dette technique).
_Je m'en fous que ça soit impossible. Pensez que c'est possible, et vous allez y arriver. Allez, juste un dernier effort!!!

Résultat, fin septembre, le projet a été classé "non prioritaire". Toujours pas fini. Parmi les deux programmeurs, la dame multiplie désormais les arrêts maladie, et le monsieur a frôle le burnout. Je le soupçonne de préparer son départ pour ne pas finir comme la dame. Cela surprendra-t-il quelqu'un?

(et on est une bonne boite; j'ai vu tellement pire ailleurs...)

[Ryu2000]

Je m'en fous que ça soit impossible. Pensez que c'est possible, et vous allez y arriver.

Les chefs, les commerciaux et les managers n'ont aucune idée de ce qui est réalisable et peuvent promettre n'importe quoi...
Parfois la paroles des développeurs n'est pas pris en compte.

[pmithrandir]

C'est toute la différence entre être agile... et faire de l'agile.

On commence en général par le second... mais si on évolue pas rapidement vers le premier, on a pas obtenu 90% des bénéfices.