PM するときに必ず見返すスライド、ブログ記事
今(2017/02/19)はBtoBで5名～10名程度(時期変動)のプロジェクトマネージャー兼プロダクトマネージャー兼SE,PG,雑用 etc 的なポジションで仕事をしています。折に触れてよく見返すスライド、ブログ記事があるのでまとめておきます。(人におすすめするときに毎回探さなくて良いように)
- 2017/03/05 参考記事を追加しました。
- 2017/03/17 参考スライドを追加しました。
参考スライド
以下、メモ (感想とか、日々の反省とか)
- 全体最適化
- ステークホルダーからの短期的な意見に対して、中長期的な目線を必ず入れること。また、説明し説得すること。
- ともすると自チームの利益だけ考えすぎだが、もっと広範囲で有益であればやる。誰かがやらないといけないことは自分たちでやる。(自分たちが標準になる。結果さえ出せばそれが標準になりうる。)
- 自己組織化チーム
以下、メモ (感想とか、日々の反省とか)
- 問題発見
- チーム、ステークホルダー、ユーザーを常に観察して考え抜くしかないかと
- 対メンバー
- メンバー同士だけで議論できるように持っていく。うまくいっているときは口を出さない。
- コントロールできる対象をマネジメントする
- 文化は結果であり、コントロールできない。日々の小さな意思決定を少しづつ変えていく。
- 心理的安全性と責任
- 無関心領域にいる人をどう引き上げればよいか。。。
- 期待値調整 (フレーミング)
- チーム内もそうだけど、ステークホルダーとの期待値調整も難しい。でもやらないと確実に失敗する。
- 信頼を勝ち取る
- 実績、結果を出さないと得られないけれど。。。
- 指示待ちが得
- 反面教師。待っててもいいマネージャーだと思われてる。
- 逆に一挙手一投足ほうれんそうする人。これも反面教師。
- 良いプロダクトと良いチーム
- 「君のチーム、社内では技術力ある方だけど結果出てないよね」と遠回しに言われたこともある。
不確実さとうまく付きあうサービス開発 // Speaker Deck
以下、メモ (感想とか、日々の反省とか)
- ユーザーを知る
- 行動、価値観、文脈(背景)
- チームで発想する
- 誰とやるか。ステークホルダーを巻き込む。
- サービスのリリースはスタート
- という期待値をステークホルダーと事前に合意しておくこと。スタートだと思ってるのがエンジニアだけだと灰になってしまう。
- 営業組織に影響力がある場合(BtoB)、まずそこにファンになってもらえないと、ユーザーまで届かない。(売れない以前に売ってもらえない。)
- 営業組織への営業力が必要。
- コンパス
- ユーザー(課題)、価値、体験、機能
- 確かめながら作る
- フィードバックが多すぎて納期に間に合わなかったらどうしようという不安との戦い
- 「売れない、売ってもらえない」「ユーザーにガッカリされる」よりは納期が多少遅れて非難されるほうがマシ。(と腹をくくる。程度やケースの問題でもあるが。)
Qiitaの作り方 〜Incrementsのチーム開発とプロダクトマネージメント〜
- 2017/03/17 追記
- OKR (Objectives and Key Results)
- PRD (Product Requirements Document)
- 動画
参考記事
- 書いてある通りにやる。
- 書いてある通りにやる。
- EOGS
- ステークホルダーとのワークショップなどに
- 今どの段階か説明したり、俯瞰的にみて現在置を確認したり
- 戒め
http://blog.yamotty.com/entry/20161228/1482881400blog.yamotty.com
- 売上は全てを癒す
- 戒めその2
- 2017/03/05 追記
- 身につけるべきスキル一覧
- 全然足りて無くて凹みます。また、プロダクトマネージャーの必要性、重要性が分かる資料。(専任が必要)
- 2017/03/05 追記
- 各フェーズ毎の解説
