Le blog de Phil

J'habite Malakoff, la plus belle ville du monde

Les projets informatiques sont toujours en retard ? Il est temps d’expliquer que ce n’est pas toujours la faute des développeurs

Puisque que l’on parle en ce moment, sur mon blog, des problèmes d’économies, de retards temps et coût, et de rationalisation des dépenses (notamment pour Malakoff), je vais me permettre d’élargir le problème au secteur privé, et notamment celui de l’informatique.

 

Effectivement, j’ai pris grand plaisir à lire un article sur Developpez.com, « Des retards dans les délais de livraison d’un projet ? Oui, mais à qui la faute ? »

L’article se fait l’écho d’une étude sur le sujet.

 

L’introduction met en avant que si un projet informatique est en retard, on pense que c’est évidemment la faute du développeur.

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 ?

Or, l’étude n’arrive pas à la même conclusion.

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

Et de continuer ce qui un jour ce doit d’être fait :

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.

Mieux, on a l’anecdote suivante :

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.

 

Bref, les projets informatiques sont souvent mal spécifiés, donc ils sont livrés en retard, et on désigne à la vindicte populaire les développeurs comme bouc-émissaire.

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é

Bien spécifier un projet, c’est le cadrer et s’assurer de le livrer à temps et dans les coûts. Ou au pire, de limiter les dépassements.

 

Notons que c’est aussi une question de qualité du code.

Dans le livre « Tout sur le code », il est écrit qu’un code de bonne qualité passe par une bonne construction en amont.

Publicités

24 novembre 2014 - Posted by | Informatique | , , ,

Un commentaire »

  1. Dans la même veine, j’avais trouvé un article qui faisait un parallèle intéressant : http://www.rocketprojet.com/succes-projet-cahier-des-charges/

    Le prédicat de départ est un quidam non-technique qui vient voir l’IT avec une demande farfelue : « Je veux une maison comme celle de Michael Jackson. », et la suite de l’article imagine ce que pourrait donner le projet. L’image est bien trouvé et je m’en sers maintenant dans mes réunions clients lorsque je reçois des demandes… « exotiques ».

    Commentaire par Eva | 13 octobre 2016 | Réponse


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :