翻訳作業のための優先度付きキュー

翻訳キューは、実際のローンチ作業が入った瞬間に政治的になります。大きなバッチは開始時には効率的に見えますが、その後で誰かが今すぐ1本の緊急記事、1件の価格修正、または1つのリリースノートの翻訳を必要とします。

その小さなリクエストが何百ものバッチ項目の後ろで待つことになれば、そのシステムは技術的には公平でも、運用上は間違っています。

キューに入ったすべての作業が同じ緊急性を持つわけではない

バッチ作業は通常、計画されています。多くの場合、それはバックログ、移行、または既知のローンチ範囲を表しています。その作業は重要ですが、通常は着実な進行に耐えられます。

単発の作業は異なります。多くの場合、誰かが特定のページを見ていて、特定のタスクを完了しようとしているために発生します。

その違いはキューに見える形で反映されるべきです。

失敗パターン

すべての翻訳リクエストが同じレーンに入ると、大きなバッチが作業者を占有します。チームには進捗が見えますが、それは間違った進捗です。

• 計画された移行項目は進み続ける
• 緊急の編集修正は待たされる
• 翻訳者は1ページを素早く検証できない
• ローンチチームはシステムを迂回して作業し始める

いったん人々がそのキューは予測不能だと考えるようになると、時間に敏感な作業のためにそれを信頼しなくなります。

より良いルール: 単発実行を先に

実用的な翻訳キューは、バッチ実行よりも単発エントリーの実行を優先すべきです。これは、バッチがまったく進まないことを意味しません。緊急の直接作業に開始の機会が与えられた後で、残りの処理能力をバッチ作業が使うという意味です。

これは、チームが実際にどのように運用しているかに合致します。バックログ移行が本番修正を妨げるべきではありません。広範なキャンペーンのバッチが、レビュー準備のできた1ページを妨げるべきではありません。

優先度が守るべきもの

キューの優先度は速度だけの問題ではありません。信頼を守るものです。

ユーザーがコンテンツ詳細ページから単発の翻訳を開始すると、その操作が素早く反応することを期待します。それが長時間実行されるバッチの後ろに置かれると、たとえ作業者が求められたとおりに正確に動いていても、UI は壊れているように感じられます。

システムは、ユーザーの意図と目に見える進捗との関係を保たなければなりません。

バッチを健全に保つ方法

単発実行を優先することは、バッチを永遠に飢えさせることを意味しません。キューには依然としてガードレールが必要です。

• 待機中の緊急単発実行がないときは、バッチ作業者は継続すべきである
• リトライは、それが属する作業の優先度を維持すべきである
• push と publish のジョブを翻訳優先度と混同すべきではない
• 進捗レポートでは、一時停止中または待機中の作業が明確にわかるようにすべきである

目的はバッチを罰することではありません。目的は、バッチが壁になってしまうのを防ぐことです。

要点

キューはプロダクト体験の一部です。緊急の単発翻訳が巨大なバッチの後ろで待たされるなら、ユーザーが体験するのは「バックグラウンド処理」ではありません。ブロックされているという体験です。

単発実行は、通常は人間の能動的な意図を表しているため、優先されるべきです。バッチはバックグラウンドで動き続けられますが、列の先頭を占有するべきではありません。