プロダクトオーナーの考えるべきところ - kawaguti’s diary

プロダクトオーナー(PO)の考えるべきところ、もしくは「はまりがちな罠」について、いくつかのトピックを思いつくまま書き出してみました。悩めるPOさんの手助けになれば幸いです。 序盤戦、中盤戦、終盤戦の戦略 一番美味しいアイデアがでる可能性に備えるために 引き継ぎにはコストがかかるので人を追加すると遅くなる システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない あ、よければアギレルゴの認定スクラムプロダクトオーナー研修もご検討ください。著名な講師が通訳付きで教えてくれます。 1. 序盤戦、中盤戦、終盤戦の戦略 「序盤で基礎を作って、作るスピードが上がってきたら、重要なところを作り、最後はウリになるものを作りこんでリリースする。」一見、良さそうに見える戦略ですが、これは結構危うい計画になりがちです。ユ

[saiid]

“作り手には完全情報を提示し、顧客には順を追ってストーリーを提示するように心がけましょう。開発者をびっくりさせても儲かりません。” これは金言過ぎる

[ledsun]

“「手順は引き継げるが、スキルは引き継げない」です。スキルを引き継ぐためには、作業の背景にある判断基準を学ぶ必要があり、すべてをドキュメント化することは難しい領域です。”

[s_ryuuki]

「手順は引き継げるが、スキルは引き継げない」です。スキルを引き継ぐためには、作業の背景にある判断基準を学ぶ必要があり、すべてをドキュメント化することは難しい領域です。

[snaflot]

“序盤は動くこと、中盤は役に立つこと、後半は問題が出ないことを確認する必要があるかなと思います”

[dr_paradi]

「やるべきことを見える化して、序盤は動くこと、中盤は役に立つこと、後半は問題が出ないことを確認する必要があるかなと思います。」わかる～でも文中にもあるけど後半戦になると違う価値仮説になってたりもする

[shibainu1969]

「このプロダクトにとって何が重要で、何が重要でないか」を判断するのが難しいと思う。「なんとなく、そのとき考える」基準のプロダクトばかり見てきた。

[sytkm]

うむ。

[P_taka]

メモ

[Shinwiki]

「べき」とかいうやつは全部無視でいいと思うの

[OrientHistory]

”一番賢くなっているのは、時系列的には最後だからです。おそらく、今日思いついたアイデアよりも最良のものを明日思いつきます。ですので、私たちは常に変化に適応できるようにしたい。”

[sezemi]

問題検証や価値検証は終わってる前提なのかな

[door-s-dev]

3以降はプロジェクトマネージャーの仕事ってイメージだった。そういえばスクラムって人的リソースのマネジメントに関する記述あったっけ