🌟
プロジェクト憲章とインセプションデッキのハイブリッドなテンプレートを作ってみた
背景
これまでの仕事(プロジェクトマネジメントやプロダクトマネジメント)の経験で、新しいプロジェクトや新しいサービスを立ち上げるときにそのキックオフの重要性は痛いほど理解しており、チームの目的や目標のベクトルをそろえようとプロジェクト憲章やインセプションデッキを使って、これまでやってきました。
昨日、ふとこれらをハイブリッドにしたほうが表現しやすいのではと思い、テンプレートを残す目的も兼ねて、この記事を書きます。
なお、このフォーマットはPDK(Project/Product Design Knowledge)と名付けました。
名前の由来は、自動車のポルシェにPDK(ポルシェ・ドッペル・クップリング)という技術があり、そこから命名させていただきました。
解決したかったこと
インセプションデッキのフォーマットはとても気に入っているのですが、プロジェクトの性質によってはこのフォーマットがあわないケースもあります。具体例では、インフラ環境を刷新したいといったプロジェクトがあるとしたら、「パッケージデザイン」や「エレベーターピッチ」のフォーマットは不要になります。一方で「やらないことリスト」や「トレードオフスライダー」はプロジェクト性質問わず有用なので、インセプションデッキのこういった部分だけ抜き出して、プロジェクト憲章とマージしてしまえば汎用的なフォーマットにできると思いました。
目的
(プロジェクトの目的、新サービス/新機能の目的を書く)
目標
(プロジェクトの目的、新サービス/新機能の目標を書く)
マイルストーン
(リリース予定日などの主要なマイルストーンを書く)
前提条件
(プロジェクトの目的、新サービス/新機能の前提条件を書く)
制約条件
(プロジェクトの目的、新サービス/新機能の制約条件を書く)
想定されるリスク
| 項目 | インパクト | 背景 |
|---|---|---|
| A | ★★★ | 項目とインパクトの背景を書く |
| B | ★★ | 項目とインパクトの背景を書く |
| C | ★ | 項目とインパクトの背景を書く |
やらないことリスト
| 項目 | やる / やらない / あとで決める | 理由 |
|---|---|---|
| A | やる | やると決めた理由 |
| B | やらない | やらないと決めた理由 |
| C | あとで決める | あとで決めると決めた理由 |
トレードオフ・スライダー
典型的なフォース
| max | >>> | >>> | >>> | min | 項目 |
|---|---|---|---|---|---|
| ○ | 機能をぜんぶ揃える（スコープ） | ||||
| ○ | 予算内に収める（予算） | ||||
| ○ | 期日を死守する（時間） | ||||
| ○ | 高い品質、少ない欠陥（品質） |
上記以外で重要なこと
| max | >>> | >>> | >>> | min | 項目 |
|---|---|---|---|---|---|
| ○ | アクセシビリティ | ||||
| ○ | i18n | ||||
| ○ | 多要素認証 |
ステークホルダー
| 役割 | 氏名 | 強みや期待すること |
|---|---|---|
| PdM | Aさん | エンジニア出身のPdMで、テクノロジー領域も詳しい。 |
| デザイナー | Bさん | グラフィックデザインからUIデザインまで幅広く行える。 |
| エンジニア | Cさん | フロントとバックエンドを一通り開発できる。 |
| 運用責任者 | Dさん | 社内の運用に熟知しており、かつ運用設計も行える。 |
何がどれだけ必要なのか
(この計画を行う上で必要な、人数や予算など必要なものを書く)
Discussion