こちらのイベントに参加してきたので、会の様子と感想を書いていきます。
チェックイン
チェックインとして、「GWにやっていたけどこれまで誰にも話していないこと」を挙げていきました。
読書会なのにチェックインが充実しすぎて、この読書会がゾンビ化しているという説が出ていましたw
重要だけど時間がかかる仕事が見つかった時にどのように対処している?障害リスト的な所に入れて管理している?
Work that you know is important, but is never picked up, gets stuck in the Poverty Trap.
の文脈で、重要だけどふわふわしていて時間がかかるような仕事のハンドリング方法を聴いていきました。以下のような話が挙がっていました。
- 壁に貼ってしまう
- 他の仕事と同じように一元管理している(緊急度・重要度のマトリクスで分類)
- Choir boxに貼っている
- Coaching Actionsってボードに貼っている
- Impact順に並べるようにしている(long term, short termで割れている)
実際に現場でプロダクトの目的を聴く時の質問
Now that you have clarity on the purpose of your product, ask these questions to hunt for your stakeholders:
「このプロダクトの目的は何？」というのを直接聞くと、アイデアを否定されているような感覚を受けてしまうことがあるため、参加者の人がどんな感じで普段聴いているのかな？というのを話していきました。以下のような話が挙がっていました。
- 主語を気を付けるようにしている。「あなたの」アイデアという言い方をしないようにする。物事や状況を主語にする。
- 色々な人に話を聴くようにしている
- 子供になったつもりで無邪気に聴く。(こういう質問がタフクエスチョンになる)
- ストレートに、誰が嬉しいんですか？と聞く。ユーザーが嬉しいのか、開発している企業がどうしてもリリースしたい機能なのかを明確にする
- ユーザに会いに行く
ユーザとの距離
Stakeholder Distance Metric One of the most important ways Scrum Masters can help organizations improve is to create transparency.
ユーザとの距離って近ければ近いほどいい？という話をしていきました。以下のような話が挙がっていました。
- 元々近ければ近いほど良いと思っていたが、最近支援しているチームで、ユーザとDevが近すぎるあまり、Devがユーザに対してコミュニケーションを取りすぎてしまい開発する機能がほとんどなくなってしまうという事例が発生した。(POが機能しなくなった)そこで、適切な距離ってあるのかもなあと思うようになった
- 基本的に近ければ近いほどいいと思っている。毎日ユーザと会話して、ユーザしか絶対分からないフィードバックを貰えている。Devも、ユーザの声を聴くにつれて、もっとユーザのためになるようなプロダクトを作りたい！と思うようになっている。
- 今はPOがめちゃくちゃ頑張っている状態なので、近いほどいいと思っていたが、たしかに近すぎるとその分失われることもあるんだろうな、と思った。
全体を通した感想
今日も本の内容を軸にしつつも、実際に支援をされている現場の話や自分が働いている現場の話を、参加者それぞれで語り合うことができて、とっても楽しかったです。
それぞれの現場のいい話もたくさん聴けて、大満足でした。
