Priorisation (WSJF)

WSJF signifie Weighted Shortest Job First — « le travail le plus court et le plus lourd d'abord ». L'idée derrière est simple et inconfortable : tant qu'une demande attend, elle coûte quelque chose (chiffre d'affaires non facturé, client mécontent, risque qui reste ouvert). Ce coût s'appelle le coût du retard.

Si deux demandes ont le même coût du retard, faites d'abord la moins chère — elle libère la même valeur plus tôt. C'est cela, et seulement cela, que fait le calcul.

Le vrai gain n'est pas dans le chiffre : il est dans le fait de comparer une demande de support et une demande de projet sur la même échelle, au lieu de laisser la priorité à celui qui a crié le plus fort en réunion.

Le WSJF, c'est « le poids du retard divisé par la taille » : ce qui perd le plus de valeur en attendant passe en premier, corrigé par l'effort. Vous indiquez la valeur métier, la criticité temporelle, la réduction du risque et la taille — et le calcul sort tout prêt, avec le détail visible. Cela permet de répondre à « pourquoi CECI avant cela ? » sans débat d'opinions.

Ici, vous attribuez la note de priorité WSJF d'une demande : trois notes de valeur (valeur métier, urgence et risque/porte qu'elle ouvre), l'effort estimé et la justification en texte. Le score est calculé à partir d'elles et c'est lui qui ordonne le backlog noté — du plus élevé au plus bas.

Le WSJF pondère quatre chiffres : la valeur métier (ce que cela vaut une fois terminé), l'urgence (le coût de l'attente — ce qui se perd chaque semaine à l'arrêt), le risque/porte qu'elle ouvre (ce qu'elle débloque ou protège) et l'effort, qui entre comme diviseur. Le score augmente avec les trois premières notes et BAISSE avec l'effort : une livraison précieuse et bon marché monte, une livraison précieuse et chère descend pour plus tard. La justification est le champ le plus lu ensuite : écrivez le pourquoi des notes pour que la priorisation survive à la réunion où elle a été faite.

score = (valeur + urgence + réduction du risque) ÷ effort

Valeur métier — combien l'entreprise gagne (ou cesse de perdre) une fois que cela existe.
Criticité temporelle — combien la valeur diminue si cela tarde. Une fonctionnalité de clôture fiscale livrée après l'échéance ne vaut presque rien ; la même livrée avant vaut tout. Ce n'est PAS « l'urgence de celui qui a demandé ».
Réduction du risque — combien cela fait baisser un risque ou ouvre la voie à d'autres choses. C'est là qu'entre la dette technique que personne ne priorise.
Effort — la taille du travail.

Toutes sur la même échelle de 1 à 10 (ce n'est pas Fibonacci). Chaque note porte la justification de celui qui l'a donnée — la note sans argument est celle que personne ne parvient à défendre la semaine suivante.

Il est calculé à l'enregistrement et n'est qu'en lecture. Si le résultat pouvait être modifié à la main, le calcul deviendrait la décoration de l'opinion habituelle — c'est exactement ce que la méthode existe pour éviter.

La note naît neutre (5 partout). C'est voulu : qui priorise doit se positionner, et sortir du 5, c'est la décision. Le score possible va de 0,300 (tout bas, effort maximal) à 30,000 (tout haut, effort minimal).

Une note par demande : si elle existe déjà, modifiez celle qui existe au lieu d'en créer une seconde. La liste est déjà le backlog priorisé — elle sort triée du score le plus élevé au plus bas.

Dans les trois champs du numérateur — valeur, urgence et risque — une note vide est traitée comme 1, le plancher de l'échelle : c'est prudent, la demande descend.

Pour l'effort, il n'y a pas de plancher, car c'est le diviseur : supposer 1 donnerait le diviseur le plus favorable qui soit justement à ce que personne n'a dimensionné, et la demande la moins renseignée prendrait la tête du backlog. Donc, sans effort, il n'y a pas de score. La demande est enregistrée normalement, apparaît en fin de liste marquée « sans note » et reste en dehors du bloc « prochaines selon le calcul » du radiateur — un élément qui n'est pas entré dans le calcul ne peut pas être présenté comme son résultat.

C'est le comportement honnête : le système n'invente pas une taille à la place de celui qui priorise. Pour que la demande entre dans la file, dimensionnez l'effort de 1 à 10.

Quand vous enregistrez une vue avec le bouton Vues, elle garde quatre choses : le texte de recherche, les filtres appliqués, les colonnes affichées (et leur ordre) et la colonne de tri de la liste. Appliquer la vue restaure tout d'un coup — y compris en réinitialisant le tri et la page où vous étiez, pour que le résultat soit exactement ce que la vue décrit. Les vues enregistrées avant cette version restent valables : ce qu'elles ne gardaient pas ne change tout simplement pas à l'application.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

Un effort vide NE devient PAS 1 : sans taille déclarée, la demande reste sans score et va à la FIN de la liste, marquée « sans note » — au lieu de monter en tête avec un diviseur inventé. L'écran le signale quand cela arrive. C'est un choix délibéré : le système ne devine pas une taille à la place de celui qui priorise, car une demande « ultra-urgente » à l'effort inconnu classée en tête serait un mensonge confortable. Dimensionnez l'effort (1 à 10) pour que la demande entre vraiment dans la file.

Dans le panneau d'activité de l'enregistrement, chaque note propose « Transformer en demande ». Le clic crée un ticket avec le texte de la note, son auteur et le lien vers cet enregistrement — rien n'est ressaisi. Utilisez-le quand la note est une demande d'action (« quelqu'un doit revoir ceci ») ; la note reste où elle était. Le bouton n'apparaît qu'une fois l'enregistrement sauvegardé ; une session en lecture seule (démonstration) n'en crée pas.

Non. Il produit un ordre suggéré et rien n'est réécrit dans la demande — le tableau reste celui de l'équipe. Le rôle du chiffre est d'inverser la charge de la discussion : au lieu de justifier pourquoi une demande devrait monter, il faut désormais justifier pourquoi elle devrait passer devant.

Quand l'équipe n'est pas d'accord avec l'ordre, la discussion utile porte presque toujours sur une note précise (« urgence 9 ? pourquoi ? ») — et c'est là que la méthode se rentabilise.

Non, et mieux vaut ne pas le faire. Notez ce qui est envisagé pour les prochaines semaines. Le radiateur montre combien de demandes ouvertes sont sans note — ce nombre est la mesure du « backlog aveugle », et sert de rappel, pas d'objectif à ramener à zéro.

Ouvrez l'enregistrement et regardez la Chronologie, à droite : elle montre chaque modification sous la forme « d'une valeur à une autre », avec la personne et la date. Quand il y a beaucoup de modifications, utilisez les deux filtres en haut de la chronologie — l'un par champ, l'autre par personne. La recherche se fait dans la base, donc une modification ancienne apparaît de la même façon. Vous pouvez aussi demander à Tenkai : « qui a modifié le contrat 482 ? ».