あるプロジェクト進行をペースメーキングする際に、プロジェクトステータスを検査する問いのセットをもって定期観測するやり方がわりと役立ったのでメモ
(※ここでいうプロジェクトはソフトウェア開発プロジェクトで、チーム内に閉じる程度の小中規模のものを想定している)
問い
- プロジェクトの背景や目的は言語化されているか?
- (プロジェクト進行上の意思決定の土台となるものはちゃんとあるか。eg. 「このprjの本質はxxxだから今回のフェーズではyyyはスコープから外しても」な判断基準の素地)
- テクニカルなドキュメンテーションがされているか?(Design Docs他。非prjメンバが非同期でキャッチアップ可能なドキュメントとして整備されているか)
- 可視化されたタイムラインは?(milestone粒度は可変要素に都度影響されない程度のサイズか。大きすぎず細かすぎないか)
- 「(タイムラインの)これって、具体的に何をするイメージか」(どんな準備が必要になってくるか、プロアクティブな動きとしていつの時点で何が必要になってくるか、イメージもててるか?)
- 進行過程で、milestone自体に過不足は生じてないか?(フェーズの単位で漏れがあるとつらい)
- 現時点における、不安要素(削減しておきたい不確実性/リスク)を挙げるとしたら?
- 直近のmilestoneは?(「ddまでにxxxになっていること」)
- 現況をワンセンテンスで表現すると?(「xxxなコンテキスト下で、yyyな状況」as-is/to-be)
- プロジェクトにおけるおよそのvelocityは?(eg. 単位(チケット|ストーリー)消化あたりの着手からPRマージまでのリードタイム)
- 直近milestoneを守れそうか?
- green/yellow/redでいうと?
- その心は?
- 定性観点(「xxxな不安要素がある/ないから」「なんとなく」)
- 定量観点(「velocityの推移と残タスクから逆算するとxxxだから」)
- (if yellow | red: 何がどうなると、greenに近づくとおもうか?)
- 現時点において、調整/リカバリ/milestone見直しの必要性は?
- (if need: その心は?)
運用と観点
- daily~weekly等で定期観測する
- 基本的に当初想定通りにいかないのが現実
- 中盤に差し掛かるまでに、前半戦でなるたけ不確実性/不安要素となっている部分(=リスク)を削減していくことを意識してみていく
- 確信度が低いところからスタートして徐々に上げていく(上がっていかないのはマズいぞという見方)
- ステータスの変化(green/yellow/red)を捉える
- ステータス遷移の機序(「なにがどうなったからそうなったのか」)を言語化する
- プロジェクトの振り返りのタネ
- ステータス遷移の機序(「なにがどうなったからそうなったのか」)を言語化する
- 「(漫然と)やっていた結果おわりませんでした」はナシ
- 早期検知と調整/リカバリのムーブがないと、信頼を失う
- 信頼がないと、説明責任やそのためコストがのしかかってくる状況(=プロダクトに向き合えないオーバヘッド)を生み出したりする
- 「できなかった」を回避するために見積が保守的になりすぎるのも健全でない(プロダクトが主語になってない)
- 信頼を獲得できるだけのチームcapabilityと得られた信頼を土台に本質に向き合える素地を整えること
- 正直ベースの見積の下、(対処すべき)不確実性に向き合った結果、
- 「(スコープ | デリバリ)調整が必要になった」
- 「youたちがそういうならそうなんだろう」(=説明コスト不要で成立する信頼)
- 正直ベースの見積の下、(対処すべき)不確実性に向き合った結果、
あわせて読みたい