Tempo Backlog & Roadmapに関するFAQ

Tempo Backlog & Roadmapに関するFAQ

目的

このドキュメントは、Tempo製品のバックログとロードマップのプロセスに関するよくある質問に回答することを目的としています。

スコープ

このドキュメントは、正式な文書化されたプロセスではありませんが、私たちの働き方についての理解を深めることを目的としています。

特定のSOPは、QMSと文書化された品質およびコンプライアンスプロセスを通じて管理されます。

よくあるご質問

機能リクエスト、機能強化の提案、または製品に関するその他のフィードバックを送信するにはどうすればよいですか?

• 機能リクエストの送信

  • 近日公開予定のアイデアポータルで直接送信してください。

  • それまでの間、リクエストをApprenticeチームと共有すると、彼らはあなたに代わってそれをポータルに送信します

• 一般的な製品フィードバックの送信

  • アプリ内リソースセンターのフィードバックと一般的なテンポフィードバックフォーム

  • 

機能リクエストはどのくらいの頻度でレビューされますか?

ローリングベースで、通常はリクエストの緊急性(製造への影響に対するリスク)に基づいています。

アイテムがレビューされると、アイテムは次のいずれかの状態になります。

バックログに追加されたリクエストは、いつ製品ごとに再度レビューされますか?

製品は、ポータルでリクエストの最初のレビューを行い、その後、年間を通じてバックログを常にレビューして、次にテーブルに何をもたらすべきかを決定します。現在、時間ベースのリリースプロセスにより、実際にはこれをより頻度で維持できます。リリース/キャパシティプランニングに至るまでの数か月にわたり、未処理のリクエストを確認し、サポート、QA、デリバリーリード、製品スペシャリスト、営業担当者と会って、現在の優先度レベルを理解します。

どの機能をリリースにするかを決定するには、どのようなことが必要ですか?

時間ベースのリリースプロセスに従っているため、大規模なシナリオ構築と最適化に取り組んでいます。私たちは、今四半期の会社のOKRを取り、「この与えられた時間枠内で、これらの目標に対するインパクトを製品内で最大化するにはどうすればよいか」と自問します。

問題の評価と改良

計画に至るまで、バックログで項目が洗練されると、項目が評価され、次のようなさまざまなデータ ポイントが提供されますが、これらに限定されません。

• アイテムの潜在的な価値スコア

• a 品目の製造リスクスコア

• アイテムの自動生成されたカスタマーリーチメトリクス(リクエストされたアカウントの数、アカウントの状態、オープンリクエストの長さ、配送または販売への影響など)。

遅延コストの見積もり

このデータを活用して、アイテムの推定「遅延コスト」を発掘することを目的としたさまざまな優先順位付けモデルを実行します。ここでは、スコープを特定するために活用したいくつかの例を紹介します。

• アカウントの健康と満足度の最適化

• リーチの最大化と回避策リスクの最小化

• 「見習いにとっての高価値と製造にとっての高リスク」のバランス マトリックス

優先順位付けモデルの結果を統合

さまざまな優先順位付けモデルを実行した結果は、通常、次のようなカテゴリなどの項目のバケットに現れます (7.4 計画の実際の例)。

• 交渉の余地のないブロッカー

• MFGに対する非常に高いリスク

• アカウントの健全性への影響は大きいが、MFG リスクは低い

• 迷惑なKTLO(Keep the Lights On)-iOSオペレーティングシステムのバージョンサポート、セキュリティアップデートなど、ソフトウェア会社としてやらない選択肢はありません

• 戦略的 - 通常、完成後にビジネスに直ちに大きな影響を与えることが期待される項目

• などなど。。。

キャパシティプランニング

そこから、特定のリリースで最も優先度の高いアイテムのみが生成されます。これはまだキャパシティを考慮していないため、キャパシティプランニングが重要になります。次のシナリオ構築では、優先順位付けされた項目のエンジニアリングと QA の作業量の見積もりを、リリースの特定の時間セットの適切なエンジニアリング リソースと QA リソースに対して取得します。これは、コンプライアンス、QA、エンジニアリング、セキュリティ、および製品チーム間の共同作業であり、スコープ オプションを生成します。これらのオプションは、推奨事項とともにApprentice XLT(エグゼクティブリーダーシップチーム)に持ち込まれ、最終レビューが行われます。

説明されているデータと評価によって駆動される柔軟なモデルを使用していることに注意してください。

これにより、Apprenticeの目標を最大化するために、特定のリリースに最も適切な優先順位付けモデルとカテゴリを選択できます。毎回 4 つのステージをそれぞれ通過しますが、各ステージの特定の側面、モデル、カテゴリなどは、そのリリースの現在のビジネス ニーズに合わせて最適化されています。したがって、上記の具体的な例は、毎回使用されるものではなく、プロセスの理解を助けるためのものです。

リクエストがリリースで対処される可能性を高めるにはどうすればよいですか?

これに対する短い答えや直接的な答えはありません。上記のことを踏まえて、定性的、定量的、逸話的なデータを活用して、リクエストの遅延コストを評価し、リリースの影響を最適化します。したがって、項目の優先度を上げる最善の方法は、問題が重要である理由を説明する明確なデータと情報を要求に提供することです。リクエストの遅延コストが高い理由をより深く理解するためにご協力ください。

また、この機能リクエストポータルをユーザーに直接公開することで、このギャップを埋めることにも取り組んでいます。

• すべてのお客様の現在オープンなアイデアをすべてご覧ください(現在、650以上のアイデアをオープンしています)

• 独自のコンテキストを提供して、独自のリクエストを送信します

• 商品が商品に追加するあらゆる質問に答える

• アイテムのライブアップデートを取得する

• 投票、コメント、アイテムに追加された投票に対するフィードバックの提供

機能が部分的に組み込まれたり、最初に要求したものとは異なる方法で組み込まれたりした場合、どのようにコミュニケーションを取りますか?

リクエストポータルの導入により、お客様が考えていることをチケット自体に正確に追加し、中間業者/女性を切り捨てることができることを願っています。

ただし、これを回避するために留意すべきことの 1 つは、要求を設計された機能ではなく問題として組み立てることです。リクエストフォームの仕組みは、設計された解決策ではなく、解決すべき問題を特定することです。製品の目標は問題を解決することであり、その結果、予想とは異なる方法で解決される可能性があります。

その他、考慮すべき点がいくつかあります。

• ポータルでは、通常、製品チームが要求から逸脱した場合に簡単な説明を提供します

• また、1 つの顧客の機能が解決されると、別の顧客が想定していたことに干渉する可能性があることにも留意する必要があります。すべてのお客様がすべての要件を承認してレビューすることは現実的ではないため、これが起こらないことを保証することはできません。

• 過去にクライアントにとって非常に関連性のある機能については、私たちは彼らを改良プロセスに関与させており、時間とリソースが許す限り、フラグが立てられたアイテムについてもそれを継続できることを嬉しく思います。In-Suite Authoring や Batch Parameter Groups などの機能は、この方法で作成された 2 つの機能にすぎません。

• また、ポータルを活用して、機能の概念やスケッチなどに関するフィードバックを求めます。