« Demande de fonctionnalité!!! »
C’est souvent le cri de guerre que les ingénieurs logiciels utilisent pour minimiser l’urgence du problème d’un client. Après tout, il n’y a pas le temps d’ajouter de nouvelles fonctionnalités lorsque nous regardons le journal des bogues sans fin qui nous fait face.
Pour les ingénieurs logiciels américains, la différence entre un bogue et une demande de fonctionnalité est limpide. Un bogue est un écart entre le fonctionnement réel du code et la façon dont notre code était destiné à fonctionner. Une demande de fonctionnalité nécessite un nouveau code pour satisfaire une requête qui ne peut pas être traitée par la base de code actuelle.
Ce genre de processus de réflexion nous amène toujours à la question plus générale de la façon dont un logiciel comme DoneDone devrait être utilisé. Votre organisation devrait-elle utiliser un type de logiciel pour enregistrer les bogues, un autre type de logiciel pour gérer les tâches à venir et un autre type de logiciel pour suivre les demandes de fonctionnalités ?
Nous dépensons beaucoup d’énergie mentale à essayer de passer au crible les problèmes enregistrés par un client ou un client, en essayant de déterminer si nous jetons un problème dans le compartiment « bogue » ou le compartiment « demande de fonctionnalité ». Pour le travail de conseil, lorsque nous travaillons sur un accord prédéfini sur le comportement du logiciel, cela a du sens. Les demandes de fonctionnalités peuvent nécessiter des frais supplémentaires.
Mais, quand il s’agit simplement de la pratique pure de la construction de bons logiciels, en particulier si nous travaillons sur nos propres produits, à quel point devrions-nous nous soucier de catégoriser un problème de cette façon?
Nous laissons les aspects techniques (et techniques) nous gêner pour résoudre les problèmes.
Robert Martin (alias Oncle Bob) parle beaucoup du logiciel. Il considère le Web comme un simple mécanisme de livraison et rien de plus. Ce n’est pas l’expérience de l’utilisateur final et ce n’est pas le but du logiciel. C’est tout simplement un petit détail stupide. Pourtant, lorsque nous programmons, l’architecture de nos applications est trop entièrement influencée par le fait qu’il s’agit d’une application Web.
De la même manière, et si nous considérions le terme que nous utilisons pour « une chose qui doit être faite » comme un détail stupide?
Du point de vue de la personne enregistrant cette « chose », est-ce vraiment important pour elle qu’elle demande une nouvelle fonctionnalité plutôt que de découvrir un bug? Elle veut juste que son problème soit résolu par un autre être humain, et de préférence, de savoir quand son problème pourrait être résolu.
Vous pourrez peut-être voir la technicité plus clairement si nous quittons le monde du logiciel. Quand le plombier vient réparer la douche qui fuit, j’imagine que vous ne vous souciez pas des détails. Si la pomme de douche a été mal installée (bug) ou si le joint est cassé (bug) ou s’il manquait du ruban en téflon dans un tuyau bon marché (fonctionnalité), tout ce qui vous importe est de savoir combien de temps il faudra pour réparer et combien vous serez facturé.
Bug ou demande ? C’est les deux. Et ça n’a pas d’importance.
La semaine dernière, Nous sommes Mammouth a publié Kin, un outil logiciel de ressources humaines pour les petites entreprises. Kin vous offre un moyen simple de suivre les demandes de congés de chaque employé. Une chose que Kin ne fait pas en ce moment est de distinguer les week-ends et les jours fériés des jours de travail. Donc, si vous souhaitez prendre un congé d’une semaine complète pendant Thanksgiving, vous devez saisir manuellement le nombre d’heures que vous demandez.
L’équipe a déjà reçu quelques demandes pour que Kin effectue ce suivi automatiquement. En fait, c’est dans la file d’attente de publication. Mais, lorsqu’il est connecté, quel que soit l’endroit où il est connecté, l’équipe Kin devrait-elle le considérer comme un bogue, une demande de fonctionnalité, une tâche ou une tâche à faire?
En appelant mon oncle Bob intérieur, ma réponse est simple: Peu importe comment vous classez la demande. C’est juste un détail stupide.
Cela ne veut pas dire que nous ne devrions pas le classer du tout. L’équipe Kin peut marquer le problème sous « demande de fonctionnalité » et travailler d’abord à résoudre les problèmes plus critiques (comme un utilisateur avec un problème d’autorisation). C’est bien et dandy, et une approche valable.
Cependant, ce serait une erreur de supposer automatiquement que toutes les requêtes de fonctionnalités que nous appelons sont moins urgentes que toutes les requêtes de bogues. Cela fait du détail plutôt mineur de la façon dont nous classons le problème la pièce maîtresse lorsque nous le résolvons. Ça ne devrait pas être comme ça. En fin de compte, toutes ces demandes sont simplement des choses qui doivent être résolues.
Que la technicité soit le détail stupide
À cette fin, l’étiquette que nous donnons à toutes ces demandes est largement sans importance. Ce qui compte le plus, c’est que quelqu’un s’occupe d’eux et il y a une idée générale du moment où ces demandes seront traitées. Ce qui compte le plus, c’est que 33% plus d’utilisateurs bénéficieront de l’élément A par rapport à l’élément B. Quel que soit le type d’élément A ou d’élément B, l’élément A est plus précieux à traiter. C’est tout. Rien de plus.
Ainsi, la prochaine fois que vous passerez trop de temps à catégoriser les tâches, les bogues, les demandes de fonctionnalités et les tâches, n’oubliez pas d’oublier les détails techniques. Ce ne sont que des détails stupides.
Créez un compte DoneDone en 30 secondes. Vous voulez en savoir plus par Ka Wai Cheung? Le nouveau livre de Ka Wai sur le programmeur moderne, le Code du développeur, est disponible en eBook et en version imprimée. Vous pouvez le suivre sur Twitter @developerscode.