Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Programmation : 7 choses que votre patron est censé savoir à propos du développement de logiciel
Selon un blogueur

Le , par Michael Guilloux

21PARTAGES

13  0 
Si le programmeur est au centre du développement de logiciel, le projet peut toutefois faire intervenir d’autres métiers qui doivent collaborer pour sa réussite. Malheureusement, de tous les acteurs qui interviennent dans le projet, excepté le développeur lui-même, personne ne connaît vraiment les réalités du terrain. Chaque décision prise à quelque niveau que ce soit et chaque acteur intervenant dans le projet peuvent avoir un impact majeur sur la qualité du produit final. Pour éviter ce problème, un bloggeur du nom de John Sonmez a dressé une liste de sept réalités que tout superviseur de développeur est censé savoir à propos du développement de logiciel. Le premier point concerne la dette technique.

La dette technique est le premier facteur de ralentissement du projet

Dans un projet, un développeur peut être poussé à coder de manière non optimale (non-respect de la conception logicielle, non-respect des règles de codage, etc.) pour aller plus vite, à la demande de son patron ou pour respecter un planning trop serré. Cela induit des coûts supplémentaires dans le futur (un peu comme des intérêts). En voulant aller vite, les développeurs contractent en effet une dette technique qu’ils doivent rembourser tout au long de la vie du projet sous forme de temps de développement de plus en plus long et de bugs de plus en plus fréquents. Au final, la contrainte d'aller vite n'a réussi qu'à ralentir le projet.

Soit on fait de la qualité, soit on va vite ; on ne peut pas poursuivre les deux objectifs à la fois

Cette deuxième réalité a un point commun avec la première. Sonmez estime que le développeur n’a pas le choix lorsqu’on lui demande d’accomplir dans un bref délai une certaine tâche. Lorsqu’il est sous pression, le développeur utilise certains raccourcis et le résultat est un travail bâclé, un grand désordre parfois. Il laisse en plus une dette technique pour tous ceux qui devront poursuivre le projet. Pour éviter ce problème, le bloggeur suggère de montrer au patron que « vous pouvez le faire soit bien, soit rapidement », avec par exemple des statistiques ou études officielles à l’appui.

Un meilleur équipement est l'investissement le moins cher à la productivité

Le matériel est l’un des meilleurs investissements pour le programmeur, même si cela lui permet de gagner seulement une demi-heure de travail par jour. Malheureusement, beaucoup de patrons négligent encore cela selon Sonmez. Pour ne pas que sa productivité soit remise en cause, le bloggeur estime que le développeur doit insister sur la nécessité d’avoir du matériel performant, ou si possible chercher un autre emploi où son manager sera plus avisé à ce sujet.

Les nouvelles technologies ne sont en général pas aussi risquées que certains le pensent

De nombreuses entreprises restent attachées à leurs vieilles technologies estimant qu’il est risqué d’adopter les plus récentes, mais elles n’ont pas toujours raison. Dans le cas d’un framework ou d’une bibliothèque par exemple, une ancienne version peut introduire certaines vulnérabilités. Passer aux nouvelles technologies peut donc être le choix le plus judicieux.

« Certains développeurs peuvent réellement produire moins que 0 code »

Dans une équipe, les compétences varient d’un développeur à l’autre, mais les membres de l’équipe doivent se compléter et faire en sorte que chaque ligne de code écrite par chacun d’entre eux puisse permettre de résoudre un problème, pas d’en créer un autre de plus. Certains développeurs peuvent être d’une incompétence qui saute aux yeux. Dans ce cas, notre bloggeur suggère qu’il faut le faire savoir au patron, sinon l’incompétence du collègue pourrait être considérée comme la vôtre également.

Les estimations sont inutiles

Une chose que Sonmez croit et qu’il estime que même les meilleurs managers pourraient ne pas savoir, c’est que les estimations qui se projettent au-delà de deux heures dans le futur sont sans valeur. Il explique cela par le fait que presque chaque projet représente un territoire pratiquement inexploré, et que l'imprévu peut se produire à tout moment. Si les superviseurs veulent toutefois faire des estimations, les développeurs devraient soit tenter de les convaincre que cela n’est pas utile, soit insister sur un découpage très fin des tâches de sorte que les estimations ne couvrent que de courtes périodes.

Les analystes d’affaires et les chefs de projet ont-ils encore leur place dans un projet de développement de logiciel ?

Là où le bloggeur s’est montré radical, c’est au sujet de la place qu’occupent les analystes d’affaires et les chefs de projet dans le développement de logiciel. Sonmez reconnaît avant tout qu’il y a absolument des analystes et chefs de projet efficaces, mais il estime que dans la plupart des cas, ils ne sont pas vraiment utiles. Il voit plutôt ces métiers dans un contexte où « tout le monde faisait du développement en cascade et les développeurs ne parlaient pas aux clients directement » et en plus où on avait « besoin de quelqu'un pour créer un énorme diagramme de Gantt », explique le bloggeur.

Il croit que le métier de business analyst est superflu, dans la mesure où les développeurs devraient parler directement aux clients. Il estime qu'il serait plus avantageux pour le client comme pour le développeur, s'il n'y avait aucun intermédiaire entre les deux parties. Il considère le métier d’analyste comme un métier boiteux qui fait une moitié du travail du développeur, mais qui ne peut pas faire l’autre moitié. En ce qui concerne les chefs de projet, Sonmez pense que les patrons devraient savoir que ceux-ci n’ont pas leur place dans un monde Agile, parce qu’au final, ils finissent par se mettre sur le chemin de tout le monde en voulant se montrer importants.

Source : Simple Programmer

Et vous ?

Que pensez-vous de 7 réalités que les patrons devraient savoir selon le bloggeur ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de _skip
Expert éminent https://www.developpez.com
Le 13/08/2015 à 11:32
Je vais me faire l'avocat du diable parce que pour être moi-même développeur et chef d'équipe, le râbachage de généralités et de stéréotypes sur le développement chez les bloggers me gonfle un peu

J'ai l'impression de relire encore et encore un énième concentré de lieux communs sur la profession. Le développeur, ce grand incompris qui se retrouve à assumer les décisions de supérieurs bornés et incompétents qui se croient à tort plus malins que lui. Ca tourne toujours autour de la même idée, les chefs c'est mal, la hiérarchie c'est mal, <mais insérer une recommandation agile ici> c'est bien... Généralement quand on voit ce genre de pavé, y'a une petite note en bas de page: "Ah et au fait pour savoir comment faut bosser oubliez pas notre super service de coaching Agile à seulement 250$ la demi journée".

Enfin là le profil du mec c'est autre chose
John Sonmez is the founder of Simple Programmer and a life coach for software developers
Ok c'est un coach et il vend des bouquins... A peine différent. Franchement j'aimerais bien que les gars de son genre, les baratineurs et autre consultants agiles laissent un peu les développeurs tranquilles et aillent casser les pieds au monde dans une autre industrie.
Et puis il y a cette remarque :

Citation Envoyé par Michael Guilloux Voir le message

Il croit que le métier de business analyst est superflu, dans la mesure où les développeurs devraient parler directement aux clients. Il estime qu'il serait plus avantageux pour le client comme pour le développeur, s'il n'y avait aucun intermédiaire entre les deux parties. Il considère le métier d’analyste comme un métier boiteux qui fait une moitié du travail du développeur, mais qui ne peut pas faire l’autre moitié. En ce qui concerne les chefs de projet, Sonmez pense que les patrons devraient savoir que ceux-ci n’ont pas leur place dans un monde Agile, parce qu’au final, ils finissent par se mettre sur le chemin de tout le monde en voulant se montrer importants.
Maaaaiis bien sûr, inutiles car forcément des incapables qui se la jouent ... Même si je suis d'accord qu'on peut trouver des cas de chefs de projets ou d'analystes métier complètement nuls et les monter en épingle. Avoir un projet bien dirigé et une bonne analyse des besoins c'est juste au moins aussi important qu'avoir des bons développeurs pour le réaliser. Si on veut faire des généralités on peut aussi ironiser sur le développeur qui écarte toutes les solutions non-code et qui fait passer la technique (code, framework, etc...) au détriment du fonctionnel.

Pour l'avoir vécu, je suis au contraire intimement convaincu que l'accès direct aux développeurs c'est une erreur. Déjà parce que ces derniers ne peuvent pas être tout le temps interrompus par des demandes clients et du support, faut clairement un filtrage en aval et parce que passé le stade de la start up avec 3 clients et 2 développeurs, on sait plus du tout qui fait quoi. Les interlocuteurs se multiplient, se contredisent, plus personne sait ce qui se passe et on perd en visibilité et en productivité. Clairement pour chaque projet, faut une personne qui a la vue d'ensemble, l'historique, qui connaît les contrats et accords passés avec le client sinon on s'en sort plus.
Ca empêche absolument pas le responsable de projet de consulter les développeurs, de prendre renseignements avant d'engager l'équipe. Il peut y avoir des différences de point de vue mais au bout d'un moment si les développeurs veulent absolument tout faire à leur guise parce qu'ils pensent tout mieux savoir et avoir de mauvais dirigeants, ils ont qu'à monter leur propre entreprise et ils comprendront mieux le problème. J'aime pas cette vision du monde victimaire et stéréotypée qui fait penser à la lutte des classes.

Je passe les autres trucs du style, "les estimations c'est de la connerie (bullshit, c'est dans l'article)". C'est clair qu'on préférerait tous avoir des deadlines infinies et ne s'arrêter que quand on a atteint la perfection, seulement les estimations sont nécessaires pour chiffrer les coûts et organiser les ressources et font partie essentielle de la phase de marchandage avec le client. Sans ça point de début, point de fin, c'est moche mais rien ne peut se substituer à cela, tout le monde ne veut pas travailler sur un modèle "pay per use", on doit forcément pouvoir mettre un ordre de grandeur sur ce qu'on investit. Il y a quasiment aucun projet qui peut se faire sans une estimation, ni construction d'immeuble, route, ligne de chemin de fer. Donc c'est pas de la connerie dont on choisit de se passer ou non, c'est un problème.
11  3 
Avatar de grunk
Modérateur https://www.developpez.com
Le 13/08/2015 à 14:19
Citation Envoyé par Saverok Voir le message

Comment être crédible si on ne sait pas estimé son temps de réalisation ?
Sommes nous plus crédible quand on annonce un délais de X semaines et qu'au final on livre en X+n semaines parce que comme à chaque fois on ne peut pas prévoir l’imprévisible.
Perso je suis pas capable d'annoncer un délai réaliste avant d'avoir les mains dans le code depuis un petit moment tout simplement parce que avant je n'ai pas une connaissance suffisante du projet, de sa courbe d'évolution, etc ...
C'est encore plus vrai quand on reprend de l'existant et qu'on va de surprise en surprise au fur et à mesure qu'on s'enfonce dans le code.

Un meilleur équipement est l'investissement le moins cher à la productivité
Un simple SSD pour compiler ca change tout. Sur certains projet c'est pas loin de 5min par compilation. Multiplié par les 10 ou 20 compilation que tu fais par jour ...
7  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 13/08/2015 à 15:44
Citation Envoyé par DarkBakura Voir le message
C'est justement ce dernier point que je voulais souligner avec mon message, plus que le reste. Le développeur n'est pas censé perdre son temps avec les questions clients. Mais dans la théorie (et j'insiste sur le terme), il n'est pas non plus censé être en interaction avec le client dans l'autre sens. Même s'il a des questions, il est censé les poser à son CP qui se chargera de les relayer s'il n'a pas eu d'éléments pouvant y répondre directement.
Après, cela reste de la théorie donc, et tu as tout à fait raison sur ta vision des choses, c'est évident. Il peut être bien plus avantageux de communiquer en direct avec le client pour certains points à risques, pour limiter les problèmes de déformation de l'information ou de négligeances sur certains aspects. Mais si déjà de base le CP sait poser les bonnes questions, cela permettrait de dispenser le développeur de ce genre de souci. Mais avec des si...
Je tiens a préciser: je trouve important que les développeurs soient en discussion avec les utilisateurs (ceux qui utilisent le logiciel), je ne parles pas forcement des clients (ceux qui commandent, qui payent). C'est souvent pas les mêmes et de la même façon que l'on trouve un vision faussée entre (certain) CP et les développeurs, on peut retrouvé la même chose de l'autre coté entre le client (le donneur d'ordre) et les utilisateurs métiers.

Petite anecdote pour illustrer: il est important d'aller voir ces utilisateurs.

Je travaillait il y a quelque année, pour un éditeur de logiciel dans le domaine de l'analyse chimique.
Nos clients étaient, entre autre, des raffineries en pétrochimie.

On m'avait expliqué que les utilisateurs utilisaient notre logiciel, dans des labos de chimie, pour valider la qualité des carburants à la sortie de la raffinerie.
Et j'ai eu l'occasion de rendre visite à un de ces labos pour une maintenance et j'ai compris beaucoup mieux .....

En résumé: les opérateurs en pétrochimie étaient constamment debout autour de grandes paillasses de chimie où étaient posées des dizaines d'appareils d'analyses.
5 PC étaient éparpillés entres ses appareils, entre 2 machines, un vieux écran 14'' cathodique palot et à peine la place pour le clavier et la souris.
Le principale boulot de ces utilisateurs étaient de préparer des échantillons de produit à analyser, de les mettre dans l'appareil, de cliquer sur un bouton de notre logiciel et d'attendre le rapport dans l'imprimante.

Le contexte d'utilisation était complètement différent de ce que je m'imaginait dans mon bureau, assis derrière mon écran 19''.
Cette visite m'a beaucoup fait comprendre de chose sur comment faire évoluer l'ergonomie de nos interfaces graphiques utilisateurs, l'importance de la souris, des raccourcis clavier, le nombre de clique/validation pour une action ....

J'ai fait d'autre visite chez d'autres utilisateurs, pour divers raison, et j'ai aussi pu constaté d'autres contraintes: déploiement en production, temps de traitement, importance des rapports, contrainte de sécurité informatique, ...
Mais tout cela, sans l'avoir vu sur le terrain, je ne crois pas qu'un CP aurait pu me le faire comprendre correctement.

Donc, amis développeurs, allez rencontrer vos utilisateurs, allez voir comment ils travaillent.

Et puis, c'est plutôt sympa de voir utiliser notre réalisation en vrai
3  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 14/08/2015 à 12:18
Citation Envoyé par Luckyluke34 Voir le message
Ce que dit l'auteur du post, c'est que c'est impossible d'estimer de manière fiable toute tâche de développement dépassant quelques heures. C'est inhérent à la nature de ce qu'on produit. On prend donc le problème par le mauvais bout en forçant les développeurs et chefs de projet à donner des estimations à échéance longue pour satisfaire le client. Un logiciel est un type de produit à part, incomparable à tout ce qu'on a connu jusque là. Il faut inventer de nouvelles façons de le vendre au client.
Oui, on travail sur des produits qui finalement ne seront jamais fini.
On le livre à un moment donné au client, mais on sait que:
  • il reste quelques bugs
  • il manque quelques fonctionnalités
  • tels ou tels interfaces serait à refaire
  • il y a un peu de lenteur dans tels ou tels traitements
  • ...


Contrairement à d'autre industrie, le produit que l'on livre n'est pas fini.
Je dis pas qu'une voiture ou une machine à laver n'a pas de défauts, mais une fois livré, le produit répond correctement à un cahier des charges.
Chez nous ce n'est pas le cas, parce qu'un cahier des charges d'un produit informatique est forcément incomplet et donc sans sens.

Et donc, c'est logique que l'on puisse pas assurer une date de fin d'un produit jamais fini.
Mais on continu de vouloir avoir a tout pris un cahier des charges précis dès le début et une estimation précise pour tous ce rassurer.
Ben ça marche pas en informatique parce que nous ne sommes pas une industrie de production (avec une chaîne de fabrication) mais une industrie de conception (avec des cerveaux)

Par contre, on peux annoncer : tel jours je vous livrerai.
Mais on ne peux pas annoncer précisément quoi.
3  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 14/08/2015 à 16:06
Citation Envoyé par _skip Voir le message
Si tu as des travaux à faire faire chez toi, tu demandes un devis, tu demandes combien ça coûte.
Tu te renseignes sur le prix, si le mec te répond "c'est 100 euros de l'heure", ta prochaine question c'est "ok vous pensez que ça vous prendra combien de temps", s'il dit qu'il peut pas trop savoir à vue de nez, tu l'invites à venir constater.
On est en train de comparer des choux et des carottes. Ces travaux n'ont rien à voir avec la complexité d'un système applicatif même de taille moyenne. De plus, les variations du métier du client d'une application à l'autre sont énormes et complexes et les développeurs ne sont à la base pas des professionnels de ce domaine, ils doivent l'apprendre. Si le bâtiment est un métier, le logiciel est un méta-métier avec finalement peu de reproductibilité d'un projet applicatif à l'autre.

De plus, deux grosses forces sont à l'oeuvre dans un projet de développement qui peuvent le faire déraper à tout moment : la complexité technique et le scope fonctionnel. En début de projet, l'équipe de développement peut se targuer de maîtriser la première à fond et le client ou le consultant en définition de besoins faire semblant d'avoir mis l'autre sous cloche mais on sait très bien qu'il n'en est rien, ces bestioles peuvent nous sauter à la tronche à tout moment et on n'y peut rien.

Face à ça, l'idée n'est pas de baisser les bras et dire "ça sera fait quand ça sera fait" mais de découper en plus petites bêtes qu'on ne va ni estimer ni facturer intégralement tout de suite. On va partir sur une première prestation de durée et donc de coût fixe mais dont le scope sera effectivement peu connu à l'avance, pour découvrir le rythme auquel on peut aller, avant d'embrayer sur le reste. Deux principaux avantages : le client a la liberté de décider à n'importe quel moment de ne plus faire ou de faire différemment une feature X non entamée si des découvertes sont faites en chemin (et ça va forcément arriver), et l'équipe de développement va pouvoir affiner son calendrier de réalisation des futures fonctionnalités à mesure qu'elle avance en tenant compte de l'expérience acquise sur les features précédentes.

Pour l'aspect technique, l'idée du POC ou des études géologiques que tu cites correspond exactement à cette approche, mais ça doit être répété pour chaque fonctionnalité dont la solution technique présente des risques et des inconnues, j'ai rarement vu un projet entier qui pouvait être estimé sur la base d'un seul POC.
4  1 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 17/08/2015 à 14:38
La question qui me viens alors: Qu'est ce qu'un chef de projet?

Est-il un référent métier pour le produit que l'on développe?
Est-il un expert informatique qui dirige techniquement le développement?

J'ai l'impression, que la fonction CP est aussi différente qu'il y a de projet.

Un CP qui est un référent pour le client, qui a une vision du produit, qui oriente les choix fonctionnels de l'application, .... est nécessaire pour un développement.
Un CP qui me dit quoi codé et comment et qui passe sont temps à mettre un tableau d'avancement du projet (qui est constamment faux) je trouve ça du gaspillage de nos propres compétences.
3  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 13/08/2015 à 11:17
Citation Envoyé par DarkBakura Voir le message
Comme tu l'as justement souligné, c'est le rôle du chef de projet que de centraliser les questions de son équipe pour les soumettre au client, dont il retournera les réponses. En théorie (même si je suis conscient que dans la pratique il peut y avoir des exceptions), le développeur n'a pas à contacter le client, et doit justement laisser le soin au chef de projet de faire passer ses questions quel que soit le moment du projet. S'il ne le fait pas, alors ce n'est pas "vraiment" un chef de projet, d'où les autres problèmes que tu as dû rencontrer.
Je suis pas tout a fait d'accord avec toi.

Pourquoi avoir un intermédiaire entre le développeur et l'utilisateur quand on a une question pointu?
Si au contraire ces 2 personnes se parlent (voir même se rencontre sur le lieu d'utilisation) les différents détails ou flou de spécification peuvent être levé bien plus rapidement.

D'avoir un CP ou un responsable quelconque qui face ce travail va forcement filtrer, épurer, simplifier l'information nécessaire (le plus souvent de façon involontaire, un CP est aussi un humain).
Rien ne remplacera le contact direct.

Par contre, là où je te rejoins, les développeurs ne doivent pas être dérangé par le client qui va vouloir tel ou tel correctif/amélioration pour hier ou utiliser le développeur comme hotline de support.
2  0 
Avatar de Anne Au Nîmes
Futur Membre du Club https://www.developpez.com
Le 13/08/2015 à 13:24
Citation Envoyé par Laurent 1973 Voir le message
Je suis pas tout a fait d'accord avec toi.

Pourquoi avoir un intermédiaire entre le développeur et l'utilisateur quand on a une question pointu?
Si au contraire ces 2 personnes se parlent (voir même se rencontre sur le lieu d'utilisation) les différents détails ou flou de spécification peuvent être levé bien plus rapidement.

D'avoir un CP ou un responsable quelconque qui face ce travail va forcement filtrer, épurer, simplifier l'information nécessaire (le plus souvent de façon involontaire, un CP est aussi un humain).
Rien ne remplacera le contact direct.

Par contre, là où je te rejoins, les développeurs ne doivent pas être dérangé par le client qui va vouloir tel ou tel correctif/amélioration pour hier ou utiliser le développeur comme hotline de support.
C'est exactement ce cas de figure auquel je faisais référence. C'est d'autant plus le cas si chez le client tu as également des techniciens, dont les informations transmises ont été épurées par leur hiérarchie, puis encore épurées par la tienne. A la fin il ne te reste que les grandes lignes, et tu es bien content d'avoir les coordonnées du type qui fera l'intégration chez le client, de leur sys-admin, ou de l'utilisateur final.

Bien entendu, il faut que ce contact direct avec le client soit à l'initiative de l'équipe de développement et non l'inverse, car comme tu le dis, tu seras souvent importuné pour faire la hotline.
2  0 
Avatar de astyan42
Membre à l'essai https://www.developpez.com
Le 13/08/2015 à 14:25
Il croit que le métier de business analyst est superflu, dans la mesure où les développeurs devraient parler directement aux clients
Pour être honnête, je suis pas tout à fait d'accord avec ça quand on parle d'une boite qui a une taille respectable. Une équipe, c'est pas que des developpeurs, on a beosin de l'équipe de produit qui saura nous synthétiser les besoins clients, nous définir les priorités en fonction des clients. Sinon tant qu'on y est, pourquoi le développeur ne serait pas aussi commercial ? Pour en revenir au sujet initial, je pense que c'est un métier à part et que a partir d'une certaine taille ce poste devient indispensable.
2  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 14/08/2015 à 11:47
Citation Envoyé par Saverok Voir le message
Comment être crédible si on ne sait pas estimé son temps de réalisation ?
Personnellement, ça me renvoie une image de quelqu'un qui ne maîtrise pas ce qu'il fait.

Je préfère de très loin un développeur moyen mais qui sait me fixer une date de réalisation et la tenir (ou encore anticiper un retard et le remonter à temps) plutôt qu'un cador qui livre ses dev de manière erratique.
Mais tu connais beaucoup de projets dont la date de livraison estimée n'a pas dérivé ? Pas moi.

Selon certaines études, le dépassement de délai moyen pour les projets software était de 74% en 2012. Il y a des précédents absolument désastreux comme healthcare.gov ou ONP en France. Qu'est-ce qui est plus crédible et professionnel ? De donner une date dont on sait qu'elle a de fortes chances d'être complètement fantaisiste, ou de dire "je ne peux pas dire quand le gros problème sera résolu, mais je peux le découper en petits sous-problèmes qui deviendront estimables au fur et à mesure de la réalisation des précédents" ?

Ce que dit l'auteur du post, c'est que c'est impossible d'estimer de manière fiable toute tâche de développement dépassant quelques heures. C'est inhérent à la nature de ce qu'on produit. On prend donc le problème par le mauvais bout en forçant les développeurs et chefs de projet à donner des estimations à échéance longue pour satisfaire le client. Un logiciel est un type de produit à part, incomparable à tout ce qu'on a connu jusque là. Il faut inventer de nouvelles façons de le vendre au client.
3  1