ロードマップに機能を書くべからず｜小城久美子 / ozyozyo
機能を書くならバックログにまず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。 残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。 こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。 こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。 では、ロードマップがなぜ必要なのかプロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針
権限がほしいなら、意思決定のフロー図を書き出す｜小城久美子 / ozyozyo
3行でまとめる権限をくれ〜と叫ぶより「私はこのフローで意思決定をしようとおもってます」というと、デキるやつっぽくて任せてもらえるよ 創業者から権限をもらえない問題いろいろな企業のプロダクトマネジメントを拝見させていただいて、モノづくりには2つのパターンがあることに気づきました。 1. ロジック後付けセンス型「こういうプロダクトが良いのではないか」というWhatの思いつきをそのまま形にする勢いのある作り方です。最初からぼんやりとターゲットに対する仮説はありますが売れてからのほうが、どうして売れたのかのロジックを強く意識します。 2. ロジックありき戦略型「この課題を解決したい」というWhyがあったうえで、その課題を解決するための最善の手段を探索する作り方です。最初からロジックありきで作り、売れた後にはそのロジックをより強化します。 創業者が 1. ロジック後付けセンス型 で、 任せたい相手に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
