PdMがおさえておくスケジュール
iCAREでPdMをしているでんでん(@shogodenden)です。
PdMというとロードマップ作成から仕様決定など、プロダクトに対する意思決定が多いですが、スケジュール管理でつまづいたのでまとめたいと思います。
把握すべきスケジュール
ロードマップ/開発計画
iCAREでは「働くひとの健康を世界中に創る」というパーパスを掲げており、そこに紐づく形でプロダクトがあり、事業計画が作られています。
ここまでは、部長/経営陣以上で作っていますが、
その下のプロダクトロードマップ、開発計画はCOO、CTOと協力してPdMチームで作っていきます。
サンプルですが以下のような感じです。
パーパスから開発計画まで、ここまで単純にまとまってはいませんが、大枠このようなイメージです。
PdMの企画・設計
もちろん機能の企画、設計は少し前から始まっています。
企画の内容はCS・Salesなどの意見を集約したり、お客さんへのヒアリングも含んでいます。
開発計画がスプリントで分割されるなどはありますが、大枠はこんな流れです。
PdMになったころは、この企画~開発のスケジュールをおさえていれば大丈夫と思っていました。
顧客への案内/オンボーディング期間
当たり前かもしれませんが、新機能などはこっそりリリースしても使われません。
CSからお客さんに案内をしてもらい、さらにオンボーディングをすることもあります。
(良い感じに新機能が周知出来て、何も迷わず使いこなせるのが理想ですが、中々そう上手くいかない…)
このあたりから、スケジュールが怪しくなってきます。
開発計画と案内が被っています。案内のタイミングではまだ開発中です。
これでは本番環境で十分な説明ができません。
スコープを減らす
デモ環境で案内する
案内を遅らせる
軽微な追加なら後から別途お知らせする
方法は色々ありますが何かしら調整が必要です。
ロードマップを作成するときに「案内」の工数が予測出来たら良いですが、企画時に厳密な仕様はないので、そこまで予測するのは難しいです。
広報との連携
少し話はそれますが目玉機能などはプレスリリースを打つかもしれません。
これも事前に広報などへの相談が必要です。
営業との連携
営業の人は、受注の数ヶ月前から商談をしていることもあります。
そのとき「商談している今は無いが、今作っている、作ることが確定している」ということがあります。
ないものをあると嘘をつくのはダメですが、お客さんがシステムを使う頃に「何が作られている予定か」は期限を握らない程度に伝えてほしいです。
なので他部署ともロードマップ・開発の計画を共有しておく必要があります。
全体観
全員が全てのスケジュールを把握している必要はないのですが、それぞれのレーンで適切な人と共有できていることが大事だと思っています。
(出来てるかは、まだ怪しいのですが…)
スケジュールのリスクを把握しておく
スケジュールを作っても、実際は様々な理由で遅れます。
(要件不足、手戻り、不具合、差し込みの対応や修正etc…)
この時大事なのは、リスクの予測と優先順位を事前に把握しておくことだと思います。
例えば、
機能A, B, Cを作る予定。
難易度が高いのはBだが(リスク)、優先度が高いのはA, C(優先順位)。
開発の見積もりが外れたり、予定外のトラブルが起こったらBを落としてA, Cだけリリース。
などです。このトラブル時の判断基準があるだけでも違います。
スケジュールは予定なのを伝える
スケジュールは予定です。和訳しただけなのですが、約束でも契約でもありません。
「それでもやりきらねば行けない」という時はありますが、あくまで予定であることは共通認識を持っておかないとトラブルになったりします。
さいごに
PdMはどうしてもプロダクトの戦略や意思決定のイメージが強いですが、
プロダクトのハブになることも大事かなと思っています。
社内に「見える化」出来ていないことも多いですが、何とか整えて行きたいです。
この記事が気に入ったらサポートをしてみませんか？