プロダクト・チームのOKRミーティングの雰囲気をコントロールする大切さ、すごく同意する状況報告ミーティングが多すぎると、チームメンバーはどんなに些細なことでも挙げて、自分の存在を正当化するようになる。日常業務については、各チームの選択を信頼しよう。ミーティングの雰囲気をコントロールして、チームメンバー全員がコミットして共通のゴールを達成するために、互いに助け合うようなムードにしよう。2週間以内に設定できなければ、優先事項を見直す必要がある。会社が結束するためのゴールを設定する以上に重要な仕事などない。達成できそうかどうかは、四半期が終わる2週間前にわかるはずだ。最後の2週間にシルクハットからウサギを引っ張り出せるなどと考えてはいけない。限った話ではないですなぁどんな人にも自分と最も近いビジネス領域を重視するバイアスがかかっているからだ。(中略)ほかの機能のほうが価値があると考える人がいる場合、なぜ価値があるのか(仮説)、どれほどの価値を持つ可能性があるか(KR)を単純に話し合えばよい。することで、建設的なコラボレーションが促進される。デザイナーだけでなく、対セールス、対マーケティングチームにも当てはまるように思うアジャイル開発の現場では、開発者が毎週金曜日にデモをするのが定番の儀式となっていたが、デザイナーは開発者ではないので参加できずに不満そうだった。そこで、全従業員にデモを勧めることにした。これが驚くほどの変化を生んだ。人以下での開催を推奨。2時間セッション+30分休憩+2時間セッション。プロダクトのチームメンバーかな)に目標の案を提出してもらう。目標のブレスト:準備しておいた目標を付箋に書き出し、壁に貼る目標のランク付け:議論しながら同じような目標を統合し、上から順に貼ってランク付けする。やっていることに共通しそう。フォーカスの仕方が違う感じ金曜日にウィン・セッション(勝者のセッション)"各チームが見せられるものをなんでも見せ合う"職能またいで実現したいなぁ...こうなったらいいなぁ、という理想(夢に近い...)今週の優先事項:目標に向けてやるべき特に重要な仕事を3~4つ挙げよう。達成できるか話し合おう。今後4週間:チームに知らせるべき今後の予定。メンバーがそれらの予定に貢献したり、準備ができたりする。自信度状況:自信度10分の5を設定したとして、それが上がったか下がったか。:すばらしい結果を目指した歩む一方で守りたいことを2つ選ぼう。失ってはいけないものはなんだろうか。(中略)悪化してきたときに把握して、話し合おう。月曜のコミットメントこの表は、とにもかくにも会話のためのツールだ。達成の自信度が下がっているのはなぜだろうか。手伝える人はいないだろうか。新しい大きなことに取り組む準備はできているか。マーケティング部門は製品部門の計画を把握しているか。従業員を追い込んでいないか。コードで手抜きが蔓延していないか。月曜のコミットメントこのようなセッションには、いくつものメリットがある。メンバー自身が、特別な勝者のチームに属しているような気分になれる。次に、共有できるものをつくることが、チームにとっての楽しみになる。メンバーが勝利を求めるようになる。最後に、会社が各部門の仕事に感謝し、社員が日々何をしているのかを理解するようになる。今四半期に達成できる自信レベルを書く今週予定していた優先タスクと、それらが達成されたかどうかを書き出す来週の優先事項を並べる。レベルにならないようにするリスクや障害があれば挙げるメモ(所感や私信。有用な内容)を添える仕事は雑用のリストではなく、グループ一丸となって共通のゴールに向かうものでなければならない。状況報告メールはこの事実を全員に念押しし、チェックボックス式の思考に陥らないようにするために役立つ。賛否両論ありそうだけど、私はわりと感情移入して読んだ。"口論さえも、前よりはずっと楽にできる"互いに同じゴールを目指してることが理解できているのは、こういう面でも大事。設定されている経営幹部レベルの議論で設定され、丁寧に社内共有された。年度上期の情報で止まってる🤔)日常的に振り返っているかと言われると(私個人は)覚えてもいない状態。設定されているプロダクトオーナーが設定し、各職能チームが確認・微調整して決定した。(プロダクトの)ミッションそのものという感じ。数値化は計測できそうなものになっていて良さそう(売り上げ指標、契約率指標)。開発チームの指標とするものに悩んでいる状態(稼働率を挙げているが、維持の側面が強く、結果的にいまやっているタスクとつながっていない。設定されている正直うまく運用できている感じがせず、悩ましい。絶対ではないが人事評価にも影響するような雰囲気になっているのでアンチパターン感がある導入して浅いので試行錯誤している(目標の修正とかも許容されている)ため、フォーカスできないでいる↓"当然ながら..."とあるが、ギーク寄りなエンジニアは必ずしもそういうポリシーで仕事してない場合があると思う。そのポリシーを自分は「悪」とは判断したくないし、できれば社会的にも許容されてほしい。いうエンジニアはプロダクト・チームのメンバーという立ち位置とは別の場所で活きてくるのではなかろうか?プロダクト・チームの個々の貢献者(エンジニア、デザイナー、プロダクト・マネージャーなど)が、特定のテクノロジーに関する知識を深めるなど個人の成長に関連する目標を多少掲げても、通常は大きな問題にはならない。当然ながらプロダクト・チームへの貢献が最も重要な仕事なので、この仕事を妨げなければ、という条件がつく。プロダクト・チームのOKR出てきたやつアイゼンハワーのマトリックス(重要・緊急性マトリックス)デザイン思考のワークフリーリスティング(ブレインストーミングの手法)アフィニティ・マッピング(内容が似ている付箋紙をグループ化する。ページトップへ移動はてなブログをはじめよう!tmd45さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。