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 !

Des retards dans les délais de livraison d'un projet ? Oui, mais à qui la faute ?
Une étude en recherche la cause

Le , par Stéphane le calme

23PARTAGES

7  1 
Il arrive parfois en entreprise que les délais de livraison d’un projet de développement ne soient pas respectés. Lorsqu’il faut en trouver la cause, il est parfois plus facile de désigner du doigt l’apparente lenteur des développeurs. Mais est-ce que ces « développeurs lents » sont vraiment la raison pour laquelle le projet a pris du retard ?

Sprintly, spécialiste de la gestion produit, voudrait y répondre à la lumière de la quantité de données sur le temps de chaque cycle de développement qu’il a récoltées via son application phare. Il fait le suivi du temps qu’il faut pour achever différentes tâches (tests, bugs, …) ainsi que de différentes tailles de projets (S, M, L, XL). Alors qu’elles sont ses observations ?

Tout d’abord, les billets de données montrent que les développeurs qui se servent du système utilisent relativement le même temps dans le cycle : 75% des 147 494 éléments qui ont été à la fois acceptés et validés ont été commencé et achevé en 175 heures en moyenne.

Ensuite, il remarque que la plupart des variabilités sont observées avant que le billet n’ait commencé : c’est à ce stade que les intervenants essaient de trouver des spécifications et établissent une priorisation du travail. Dans le modèle de Kanban, cette période correspond au temps de réaction (la quantité de temps qui s’écoule entre la création du billet et le moment où il devient une priorité). Pour rappel, Kanban est une méthode de gestion des connaissances relatives au travail, qui met l’accent sur une fourniture ponctuelle de l’information aux membres de l’équipe de sorte à ne pas les accabler. Dans cette approche, le processus – dès la détermination des tâches, jusqu’à la livraison au client – est affiché pour que les participants puissent le voir, et que les membres de l’équipe puissent tirer du travail de la file. Sprintly remarque que beaucoup de temps est perdu à cette étape.


Ensuite il apparaît que les équipes ont du mal à faire la transition entre les étapes « fait » et « testé et prêt à être déployé » comme le suggère le graphique plus haut au niveau du temps passé sur « Completed to Accepted ». Alors si vous avez l’impression que le travail de votre équipe n’est pas assez rapide, il est fort probable que vos développeurs ne sont pas à blâmer. Mais alors qu’elle pourrait en être la cause ? Un petit indice : votre processus.

Bien écrire les spécifications est important, car comment un développeur pourrait-il commencer à travailler sur une fonctionnalité s’il ne la comprend pas au départ ? A ce propos, sur StackExchange, l’utilisateur eagerMoose partageait son expérience en disant « la plupart du temps, il s’avère que ceux qui ont écrit les spécifications n’ont pas pensé à la chose en profondeur et c’est souvent quand nous commençons le design et le développement que commencent les ennuis puisque de nombreuses spécifications semblent avoir des lacunes ». Il n’est pas rare de voir que les intervenants ne se sont pas vraiment penchés sur la fonctionnalité eux-mêmes. Un développeur doit comprendre POURQUOI un utilisateur a besoin de cette fonctionnalité, ce qu’elle est censée faire, mais également comment elle sera employée. D’ailleurs, Sprintly a utilisé cette philosophie lorsqu’il a proposé son outil de gestion de projets. En utilisant le formulaire ci-dessous qui répond au ‘pourquoi’ et ‘comment’, Sprintly pense qu’une direction spécifique sera maintenue pour une fonctionnalité spécifique.


La seconde plainte qui revient le plus parmi les développeurs est le fait que les décideurs changent souvent les spécifications une fois que le travail a commencé. Sprintly y voit un symptôme d’une mauvaise planification des fonctionnalités avant de leur insertion dans la roadmap. Pour éviter cette situation, Sprintly propose d’utiliser des maquettes interactives avant que le développement à proprement parler ne débute.

Pour Sprintly, le changement de contexte peut également expliquer les retards pris dans vos projets. Il identifie deux formes :

  • le développeur a réalisé 50% de la tâche A quand vous vous rendez à son bureau pour lui demander de changer de tâche et faire plutôt la tâche B
  • le développeur a réalisé 50% de la tâche A quand vous lui demandez de faire AUSSI la tâche B


« Le problème vient du fait qu’en tant que manager, vous assignez à vos développeurs de nouvelles tâches alors qu’ils sont en plein milieu d’une autre. Si vos priorités sont toujours en train de changer, cela entraînera de gros coûts pour votre équipe » explique Sprintly.

D’ailleurs Joel Spolsky, un programmeur et écrivain américain auteur de Joel on Software, en parlait dans son blog : « la vraie leçon qu’on peut en tirer est que vous ne devriez jamais laisser les gens travailler sur plus d'une chose à la fois. Assurez-vous qu'ils savent de quoi il s’agit. Les bons managers voient leur responsabilité dans le fait de supprimer les obstacles afin que les gens puissent se concentrer sur une chose et vraiment le faire. En cas d'urgence, pensez à voir si vous pouvez gérer vous-même avant de déléguer à un programmeur qui est profondément immergé dans un projet ».

Sprintly conclut en s’adressant aux managers et leur rappelant que c’est leur devoir de fournir aux développeurs un environnement dans lequel ils peuvent mener à bien leurs tâches. Aussi, avant de diriger vers eux leur doigt accusateur, il leur recommande une petite introspection. Voici quelques astuces qu’il leur fournit pour qu’ils puissent s’assurer de ne pas être le poids mort de leur équipe :

  • aidez votre équipe à comprendre la vision : travaillez de concert avec votre équipe afin de définir une vision commune de la façon dont vous allez rendre meilleure la vie des utilisateurs. Soyez clair sur les résultats dont vos utilisateurs ont besoin. Il est important d'avoir un développeur motivé ; sa passion pour une fonctionnalité peut devenir un moteur important de vitesse.
  • les développeurs doivent avoir la capacité de refuser une tâche en attendant qu’elle soit mieux fournie en détail
  • réduisez les coûts relatifs aux changements : n’interrompez pas vos développeurs ! Avant de leur envoyer un courriel ou faire une requête, évaluez-en le coût sur la productivité


Source : blog sprint.ly, Joel on software, stack exchange

Et vous ?

Vous retrouvez-vous dans ces statistiques ? Partagez-vous ce point de vue ?

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

Avatar de Carhiboux
Expert éminent sénior https://www.developpez.com
Le 24/11/2014 à 16:30
Citation Envoyé par SylvainPV Voir le message
"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...

9  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 22/11/2014 à 23:18
"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 soi-même. C'est tellement plus facile de rejeter sur la faute sur autrui que de reconnaître ses erreurs.
9  1 
Avatar de Michael Guilloux
Chroniqueur Actualités https://www.developpez.com
Le 22/11/2014 à 17:51
Cet article reflète bien la réalité quotidienne de tous les développeurs.
Malheureusement, les managers et les utilisateurs ne savent pas qu'un élément supplémentaire
dans le cahier de charges, alors que le développement est déjà en cours, peut tout chambouler.

Très souvent, ils vous disent :"je veux telle application". Ne les croyez pas! C'est un piège!
Demandez leur pourquoi il leur faut une telle application et vous verrez que ce n'est pas ce dont
ils ont besoin. En général, tout ce qu'ils savent, c'est qu'ils ont un problème, mais la solution
à ce problème, c'est le développeur qu'il a.

Je me suis déjà fait prendre par ce genre de piège, un client qui me dit, voilà je veux une telle
application développée à partir de tel logiciel. Je me jette dans le développement et en cours de route,je me rends compte que ce n'était pas le logiciel adéquat pour développer l'application.

Pour n'avoir travaillé que sur de petits projets, je crois que pour éviter les retards, le développeur doit
aussi jouer le rôle d' AMOA, ça lui évitera de revenir aux spécifications au cours du développement du projet.

Il faut surtout éviter la surqualité, il faut s'en tenir strictement au cahier de charges. Et si l'esprit créatif du client l'emmène à demander de nouvelles fonctionnalités, il faut lui proposer un lot 2, dans lequel vous allez ajouter cette fonctionnalité.
6  1 
Avatar de koyosama
Membre éprouvé https://www.developpez.com
Le 23/11/2014 à 1:05
La encore j'ai l'impression vous parlez tous de projets récents et fait a partir de zéro.
Mais dans la réalité on reçoit aussi des projets réalisés par d'autres (autre entreprise, autre personnes partis entre temps, ...) sans documentation. Et que tu dois continuer un truc qui a la moitie de ton age.

Comme le client était habitue a avoir un certain délai pour ces développements, alors il met les même délais au bout de 10 ans.
Alors que le projet n'est plus maintenable du tout, ...

Toi en tant que développeur, ton chef de projet et même par fois ton commercial , tu subis toute cette politique. Leur dire de complètement changer ne fait pas partis de leur culture d'entreprise.
Apres c'est sure quand ils voient les applications blingue-blingue, ils croient qu'on peut faire pareil a partir de leur existant.

Je pense qu'il faut arrêter aussi cette culture que l'informatique est un coût. On fait partie intégrante des variables de l'entreprise. Nous somme une source d'eau, nous somme vitales pour votre métier. Nous sommes pas une chaise qu'on achète chez Ikea.
5  0 
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 22/11/2014 à 18:27
Il faut également se confronter aux réalités du métier et accepter le fait que tout ne soit pas maitrisable.
Je constate dans mon quotidien de nombreux cas de figures qui rendent difficile le respect de délais :
- Deadline qui se pose selon les désirs du client sans prendre en compte les réalités du projet. Si le projet ne peux pas avancer parce que le client ne fournit pas des éléments ou le feedback en temps et en heure, la deadline ne bouge pas pour autant.
- La réalisation de projet utilisant une technologie peu ou mal connue. L'important est de remplir le carnet de commande, les développeurs trouveront bien le temps de se former sur leur temps libre.
- Le carnet de commande qui d'ailleurs doit être trop rempli plutôt qu'un peu trop peu. Les développeurs n'auront qu'à faire quelques heures supplémentaires gratuites, ils devraient déjà être contents d'avoir du boulot.
- Le quotidien ne s'arrête pas sous prétexte que l'on travaille selon un timing très serré. Il faut bien faire avec les demandes urgentes qui arrivent plusieurs fois par jour, s'occuper du support technique. Chaque client part du principe que l'on donne 100% des ressources sur son projet.
6  2 
Avatar de Zefling
Membre expert https://www.developpez.com
Le 23/11/2014 à 0:48
Citation Envoyé par theMonz31 Voir le message
J'en discutais avec un ami justement mercredi soir...

Les cahiers des charges trop précis, les spécifications écrites par des non développeurs trop précises, c'est un enfer.. car au final, si on produit exactement
ce qui s'y trouve, on risque de ne pas satisfaire le client...

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

Si le réalisateur parlait directement avec le demandeur, on aurait surement une meilleure adéquation du logiciel au besoin et par là même, on gagnerait surement
du temps, de l'argent et de l'éfficacité... mais pour celà, il faut faire confiance aux développeurs et supprimés pas mal de poste intermédiaires
J'ai l'impression de voir plus souvent l'inverse : des spécifications pas précises du tout... tellement vague que ça peut-être complètement sujet à interprétation. Puis quand j'ai presque fini qu'on vienne me dire qu'un truc ne correspond pas à ce qui est écrit dans un autre document que je n'avais jamais vu, que le calcul n'est pas celui attendu ou diverses autres raisons qui dépasse mes compétences. Ça devient à faire de la conception, de l'analyse et de la chasse au trésor, mais encore faut-il en avoir le temps. Surtout quand il y a des personnes qui sont normalement là pour faire ça dans la boîte. Et j'ai vécu ce genre de choses dans presque toutes les boîtes dans lesquels je suis passé.

Il y a souvent un manque terrifiant d'organisations. Les priorités qui changent tout le temps. Je commence à bosser sur un truc, on me passe sur un autre en cours de route parce qu'on truc oublié est devenu plus important. Le pire, ça reste d'avoir à générer plusieurs projets exactement en même temps, le meilleur moyen de faire des erreurs. Impossible de vraiment se concentrer sur un seul projet. Puis le pire, c'est que dans le dév, la partie test est souvent complètement oubliée. Faire des tests unitaires, j’aimerai en faire, mais j'ai trop souvent à peine le temps de faire le reste.

J'ai aussi eu le cas du client qui vers la livraison finale du projet se rend compte qu'un élément ne va pas dans la cinématique, alors qu'il a eu au moins 15 livraisons pour s'en rendre compte avant. Comme il y avait un deadline impossible à revoir, à moins de tout revoir, pour une fois le manager a été obligé de dire au client que ça n'aller pas être possible. Oui, parce que si nous voulions faire ce que le client voulait, les dévs pouvaient oublier leurs soirées et leurs week-ends pendant plusieurs semaines. Et à titre perso, je n'aurais pas accepté. Déjà que la boîte ne payait pas les heures sup. (D'ailleurs, ça existe des boîtes d'infos qui les paies ?)

Pour moi, le pire problème reste la mauvaise évolution de la difficulté d'une tâche. Souvent parce qu'il y a des imprévus non maîtrisables (à moins d'être soi-même l'auteur du framework sur lequel on bosse). On pense qu'une chose peut-être réalisée dans la journée... puis on y est encore une semaine après parce qu'on s'e rend compte que le framework ne permettait pas de le faire et qu'il faut trouver des solutions de contournement qui demande une connaissance du fonctionnement du cœur du framework. Un pote m'avait parlait d'un projet où pour rajouter un pauvre bouton pour une action relativement simple, ils y ont passé à plusieurs plus d'un mois. Framework ultra mal documenté, support lamentable (payé une fortune par la boîte), une quantité de code énorme à essayer de comprendre. Le truc avait chiffré à 3 jours, il me semble.

Les erreurs, il y en a tous les niveaux. Mais on oublie souvent que l'informatique c'est pas juste pisser du code sans réfléchir, parce que si ça devient juste ça, je préfère changer de job.
4  0 
Avatar de tpericard
Membre averti https://www.developpez.com
Le 24/11/2014 à 16:13
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).
4  0 
Avatar de dfiad77pro
Membre expérimenté https://www.developpez.com
Le 25/11/2014 à 10:05
Citation Envoyé par sidewolf Voir le message
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.
3  0 
Avatar de landry161
Membre éprouvé https://www.developpez.com
Le 25/11/2014 à 12:08
Citation Envoyé par Carhiboux Voir le message
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.
3  0 
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 23/11/2014 à 8:36
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 même souvent pire.
Un chargé de comm de la boite A contacte le chargé de comm de la boite B qui transmet ce qu'il a compris de ce que le client a compris de la demande à l'équipe technique. Impossible ensuite d'avoir des discussions d'équipe technique à équipe technique
3  1