Files de priorité pour le travail de traduction

Les files de traduction deviennent politiques dès que le vrai travail de lancement y arrive. Un gros lot semble efficace au départ, mais ensuite quelqu’un a besoin qu’un article urgent, une correction de tarification ou une note de version soit traduit tout de suite.

Si cette petite demande attend derrière des centaines d’éléments de lot, le système est techniquement équitable et opérationnellement erroné.

Tout le travail en file n’a pas la même urgence

Le travail par lots est généralement planifié. Il représente souvent un arriéré, une migration ou un périmètre de lancement connu. Ce travail est important, mais il peut généralement tolérer une progression régulière.

Le travail à entrée unique est différent. Il est souvent déclenché parce qu’une personne regarde une page précise et essaie de terminer une tâche précise.

Cette différence devrait être visible dans la file.

Le mode d’échec

Quand chaque demande de traduction entre dans la même file, les gros lots monopolisent les travailleurs. L’équipe voit des progrès, mais ce sont les mauvais progrès :

• les éléments de migration planifiés continuent d’avancer
• les corrections éditoriales urgentes attendent
• les traducteurs ne peuvent pas valider rapidement une page
• les équipes de lancement commencent à contourner le système

Une fois que les gens pensent que la file est imprévisible, ils cessent de lui faire confiance pour le travail sensible au temps.

La meilleure règle : d’abord les exécutions uniques

Une file de traduction pratique devrait donner la priorité aux exécutions à entrée unique par rapport aux exécutions par lots. Cela ne veut pas dire que les lots n’avancent jamais. Cela signifie que le travail par lots utilise la capacité restante après que le travail direct urgent a eu la possibilité de démarrer.

Cela correspond à la façon dont les équipes travaillent réellement. Une migration d’arriéré ne devrait pas bloquer une correction en production. Un lot de campagne large ne devrait pas bloquer une page unique prête pour révision.

Ce que la priorité devrait protéger

La priorité de la file ne concerne pas seulement la vitesse. Elle protège la confiance.

Quand un utilisateur lance une traduction unique depuis une page de détail de contenu, il s’attend à ce que cette action réponde rapidement. Si elle reste derrière un lot de longue durée, l’interface semble cassée même si les travailleurs font exactement ce qu’on leur a demandé de faire.

Le système doit préserver la relation entre l’intention de l’utilisateur et les progrès visibles.

Comment garder les lots en bonne santé

Donner la priorité aux exécutions uniques ne signifie pas affamer les lots pour toujours. La file a toujours besoin de garde-fous :

• les travailleurs de lots devraient continuer lorsqu’aucune exécution unique urgente n’est en attente
• les nouvelles tentatives devraient conserver la priorité du travail auquel elles appartiennent
• les tâches de push et de publication ne devraient pas être confondues avec la priorité de traduction
• le reporting de progression devrait rendre évident le travail en pause ou en attente

L’objectif n’est pas de punir les lots. L’objectif est d’empêcher les lots de devenir un mur.

À retenir

Les files font partie de l’expérience produit. Si une traduction urgente à entrée unique attend derrière un lot géant, les utilisateurs ne vivent pas un « traitement en arrière-plan ». Ils ont l’impression d’être bloqués.

Les exécutions uniques devraient avoir la priorité parce qu’elles représentent généralement une intention humaine active. Les lots peuvent continuer d’avancer en arrière-plan, mais ils ne devraient pas occuper le début de la file.