タイムラインの管理

13 人のプロダクトリーダーのアプローチを使用して、ユーザーが現実的なプロジェクトタイムラインを設定し、達成できるようにサポートします。

サポート方法

ユーザーがタイムラインに関するサポートを求めた場合:

1. 文脈を理解する - 期限の性質（外部への約束、内部目標、人為的マイルストーン）、作業の段階、タイムラインプレッシャーの原因について質問する
2. 問題を診断する - これが見積もりの問題、スコープの問題、注意散漫の問題、または非現実的なステークホルダー期待なのかを判断する
3. 適切なフレームワークを適用する - 状況に応じて、フェーズベースのコミットメント、ヒルチャート、またはアーリーシッピング戦略を使用するよう支援する
4. 健全な習慣を構築する - 一度限りの修正ではなく、持続可能なタイムライン習慣に向けて指導する

中核原則

本当の期限を P0 として扱う - 他に何も重要ではない

Nan Yu: 「期限を本当にするための唯一の方法は、それを P0 の問題として本当に真摯に受け止めることです。他のすべてはそれと比較して重要ではなくなる必要があります。」期限が多すぎてはいけません。重大な外部イベント用に予約し、設定後はチームを他のすべての注意散漫から保護します。

遠い納期ではなくフェーズにコミットする

Annie Pearl: 「私たちはコントロール下にある日付へのコミットに移りました。発見作業へのコミットができます…十分な発見をしていない 6 ヶ月後のプロジェクトについてのコミットメントを作成するのではなく。」作業を発見、ソリューショニング、構築、ローンチに分割します。ソリューショニングが完了してからのみエンジニアリング納期を提供してください。

アーリーシップ、残り時間で反復する

Nan Yu: 「私たちはほぼ見積もりを行いません。私たちがすることは、できるだけ早くシップすることです。時間の 10% で動作するものがあれば、残りの時間を反復するか磨くかを決めるのに費やすことができます。」見積もりを前面に負荷をかけるのではなく、「はい」または「いいえ」のシップ可能な状態にすばやく到達することに焦点を当てます。

ヒルチャートを使用して不確実性を追跡する

Jason Fried: 「プロジェクトはより丘のようなものです。左側はまだ進行中です。仕事が頂上に到達したら、そこから下り坂です - 純粋な実行です。」作業を丘として視覚化します。左側は発見、右側は実行です。上り坂の側に留まっているアイテムは、期限を逃す高リスクです。

モメンタムを作成するために期限を製造する

Laura Modi: 「あなたの仕事はただ人々をモメンタムで進め続けることではありません。あなたの仕事はモメンタムを作ることです。時にはそれが製造される必要があります。」任意の期限とローンチ日を設定して進捗を強制します。マイルストーンを使用して過度な完璧化を防止します。

見積もりの隠れたパディングに異議を唱える

Dylan Field: 「タイムラインが第一原則から十分に理由付けられておらず、意図的に追加されたパディングがある場合、実際にどのくらい長くかかるかについての仮定を理解する必要があります。」「なぜ」と質問して、隠れた制約または不要なパディングを明らかにします。第一原則から仮定を検討します。

計画性バイアスを考慮する

Nir Eyal: 「タスクは人々が見積もるよりも 3 倍長くかかります。何かに 5 分間取り組んでからメールと通知を受け取ると、実際にどのくらい時間がかかったかを追跡することはありません。」注意散漫なしに、あなたが言ったことをしたかどうかで生産性を測定します。タイムボックスを使用して、実際の期間についてのフィードバックループを作成します。

延長を要求しない

Seth Godin: 「プロフェッショナルは延長を要求しません。なぜなら、プロフェッショナルは予期しなかったことが起こることを理解しているからです。」期限と予算をハード制約として扱います。予期しない事態に対処するために延長なしで計画にバッファを組み込みます。

週次 RAG ステータスで確認する

Brian Chesky: 「すべてのプロジェクトを緑、黄色、または赤でスコアリングするヘッドプログラムマネージャーがいました。毎週作業をレビューして、何か起こっていなければ、会議を止めて『なぜこれが起こっていないのか?』と聞きました。」プログラム管理を昇格させます。シンプルな RAG ステータスと週次レビューを使用して、問題を早期に特定し、ブロック解除します。

AI タイムラインは不均等であることを予想する

Aparna Chennapragada: 「最初のデモまでの時間ははるかに短いですが、完全な展開までの時間はより長くなるでしょう。不均等なケイデンスがあります。」プロトタイピング用に短いインナーループをプランして、スケーリングのアウターループに大幅な時間を割り当てます。デモとシップ可能な製品の間のギャップについての期待を管理します。

ユーザーを支援するための質問

• 「これは外部への約束ですか、それとも内部目標ですか?それを逃すと何が起こりますか?」
• 「作業はどのフェーズにありますか - 発見、ソリューショニング、または構築?」
• 「『動作バージョン』をまだシップしていますか、それともチームはまだ進行中ですか?」
• 「この見積もりのパディングはどこにありますか?どのような仮定が組み込まれていますか?」
• 「あなたの時間のうち、実際にはどの程度が集中した作業ではなく会議と注意散漫に費やされていますか?」
• 「競争している『P0 期限』が多すぎますか?」

指摘する一般的な間違い

• 発見完了前に日付にコミットする - スコープしていないものは見積もりできません。遠い納期ではなくフェーズにコミットします
• 多くの高優先度期限 - すべてが P0 であれば、何もありません。本当の期限は重大な外部イベント用に予約します
• 見積もりを前面に負荷をかけるのではなくアーリーシップ - 動作バージョンにすばやく到達し、残り時間を反復に使用します
• 計画性バイアスを無視する - タスクは注意散漫のため見積もるより 3 倍長くかかります。タイムボックスして実際の集中した作業を測定します
• 延長を要求する - プロフェッショナルは予期しない事態を説明します。タイムラインを延長するのではなくバッファを構築します

深掘り

13 人のゲストから 14 の洞察すべてについては、references/guest-insights.md を参照してください

関連スキル

• Scoping and Cutting
• Prioritizing Roadmap
• Running Effective Meetings
• Planning Under Uncertainty