runaround’s diary

なんとなく、つれづれ

プロダクトオーナーの現場　を聞いてきたよ

お勉強

devlove-kansai.doorkeeper.jp

めっちゃ楽しみにしてましたー。
お二方共にとても優しい口調だけど、割とぶっちゃけてて楽しませていただきましたw

今日は社内でPDMやPJMのお話を聞く機会もあったので、すごくタイミング良かった。


5月以降も面白そうなタイトルが並んでるDevLove関西さん。


なんかまだまだ実感わかないですね、平成終わっちゃうの。


初めて来させていただきました。とても素敵なオフィスです。


来場者、プロダクトオーナーさんが殆ど居なかったらしく・・・。（登壇者さんは手をあげてたけど）
ダイアログでお話させていただいた方はゲーム会社のエンジニアリングマネージャーさんでした。

私はエンジニアなんですが、プロダクトオーナーさんに恵まれております。現在も。
でもってプロダクトオーナーさんがどんなことを考えてお仕事されているのか知りたい！


まずは弊社のかなこさんが登壇されました。

グループは違うけれど同じフロアで働いています。ちょくちょくお話もさせていただいてますー。







私が前にいたチームではプロデューサーさん1人が事業と話したり、お金の管理もしておられました。
得意な方は良いのでしょうが、得意不得意があるだろうしやっぱり分けたほうがいいのでしょうかね・・・。

役割を分けるにあたってのメンバーへの説明はどうしたんだろう？と思ったら・・・



コード書いているよりドキュメント書いている時間が長いのが辛い、って言うのもあるのかな・・・。
あと見積もりがタイトなのでドキュメント書くのを省いたらもっと余裕出るのに・・・って思いもあったみたいで。
気持ちはわかるんだけれど・・・改修案件の場合、コード修正なんて数行のみ、
調査やテストケース、リリースドキュメント作成がほぼ大半ってよくあることなんだけどなぁ。
もちろん書きすぎのドキュメントよりは明確で適度なボリュームがいいけどね。


ふりかえりの空気が凍ったりどんよりしているチームにはぜひやってほしい手法です。

https://www.instagram.com/p/Bwb0ejiJ3UP/
良かったポイント#DevKan

このサポーターを得るって言うのは社内の別のグループ、改善グループのサポートだったんですね。




このあたりから質疑応答タイム。








次はスクラムマスターとしてプロダクトオーナーさんを支援したお話。


そうかー、アジャイルしか知らないって人もいるだろうなぁ・・・。




ユーザーストーリーマッピングでてんやわんやした話がかなり面白かったw
慣れないうちは色んな気づきや失敗があってw







旦那さんを置いてひとり旅。いいなぁ。
あ、うちは旦那居ないですが。ぶらぶらひとり旅はしたいなー。

ペアプロしてると気づくんですよね。
教えてる、と思ってても教えられてる。とか。
やっぱお互いリスペクトだよねー。
上に見たり下に見たりしない。


プロダクトオーナーさんとエンジニアが楽しく前を向いて開発するには・・・。
私は普段専門用語ではないわかりやすい言葉で話す、を心がけてます。
コードを見せる、も極力しない。
読めない文字の塊見せてもストレスしかないわけで。
英語がスラスラと読めなかった学生時代、英語長文を目にした時のイライラを思い出すとわかりやすいかも。