Avant, lorsque nous voulions une information, nous devions sélectionner des livres dans les rayons de bibliothèques. Ensuite, en parcourant ces livres, nous pouvions trouver l’information. Idem, pour des vêtements, il fallait parcourir les boutiques en espérant trouver ce qui nous correspondait ou choisir par défaut. Mais aujourd’hui, tout est devenu instantané. Internet est le génie de la lampe. Smartphones et tablettes exaucent nos vœux.
Alors pourquoi ne serait-il pas de même dans notre travail ? Pourquoi certains besoins ne pourraient pas être réalisés rapidement. De nos jours, les équipements informatiques sont 100 fois plus performants qu’il y a 20 ans. Il en va de même pour nos logiciels. Ainsi, dans l’esprit des responsables informatiques, le développement d’outils et de sites se doit d’être plus rapide.
Bien évidemment, les responsables savent que les outils sont plus complexes qu’il y a 20 ans. Mais, pour développer ces logiciels, les méthodes de gestion de projets ont changé. Nous avons déjà parlé de Scrum qui évite l’effet tunnel. À un moment donné, tous les sprints sont réalisés et la version 1.0 est terminée. Pour autant, le client a de nouvelles idées à ajouter à son application.
Les méthodes de développements rapides, couplés à des interlocuteurs qui savent prioriser les besoins permet de répondre rapidement aux attentes du client et des utilisateurs finaux.
Ainsi est né dans l’esprit de nos managers le concept de quick win (QW), la victoire rapide. L’idée est d’ajouter des sprints au logiciel initial. La seconde idée est de prioriser les évolutions qui apportent le plus à l’utilisateur final. Un sprint dure entre 2 et 6 semaines. Ce qui est rapide pour obtenir une nouvelle fonctionnalité sur un logiciel.
Victoire facile, victoire rapide, et tout le monde est gagnant. Le client a les améliorations qui lui semblent importantes. Le chef de projet valorise ses capacités de manager. L’équation semble parfaite dans le monde du développement informatique. Pourtant, il manque plusieurs paramètres importants dans cette équation.
Le premier est de définir ce qu’est un quick win. Pour l’utilisateur, s’il peut limiter les tâches répétitives, c’est mieux. Pour son responsable, et client du prestataire informatique, le QW est tout ce qui permet d’améliorer ou d’évaluer la productivité de ses collaborateurs. Les deux acteurs ont donc une vision assez similaires du QW. Mais aucun des deux ne connaissent le coût des développements.
Passons du côté prestataire. Si le chef de projet à une vision approximative du coût d’un développement, il se repose sur ses analystes pour définir cela. Les sprints précédents permettent de déterminer la vitesse de développement des équipes techniques. Ensuite, il orientera ses clients sur les améliorations à prioriser.
Pourtant, tout ce petit monde oublie que les logiciels s’exécutent dans un contexte informatique. Et seul le développeur sait ce que coûte vraiment une évolution. Mais il n’est pas toujours interrogé. Il faut dire qu’il parle un langage étrange, difficilement compréhensible par les non-informaticiens. Et les analystes ne connaissent pas toutes les subtilités de ce langage.
Pour un développeur, un QW est une évolution facile à coder. Par cela on entend qui n’impacte pas ou peu le cadre technique (framework). Pourtant certaines demandes attendus par l’utilisateur final peuvent avoir des impacts importants sur ce dernier. Ainsi, ce qui semble simple à ajouter pour le client peut remettre en cause le logiciel.
Le code a ses raisons que la raison ignore. Ce qui paraît naturel pour un utilisateur peut se révéler très complexe pour le développeur. Et donc demander beaucoup de temps de développement. Ce n’est plus vraiment quick. Au contraire, une évolution évaluée comme complexe et donc supposée longue à réaliser, pourra se révéler simple à mettre en œuvre pour le développeur parce que déjà traitée sur le framework utilisé.
Les QW seront réellement rapides et efficaces si analystes et chef de projet comprennent correctement le domaine de leurs clients et l’infrastructure mise en œuvre par leurs développeurs.