這個Topic有趣的點在於
身為一個PM或是決策者，怎樣把事情的前因後果跟怎麼處理問題
講給"聽不懂的人"聽，而讓他可以用自己的想法參與討論甚至決策
很多人不懂這塊，所以稍微解釋給各位了解。
如果是以一般的日常事務來說，可能一個突發事件
或許你可以把它當成一個Project Charter，然後引申成為所謂的User Story
問題1:
你要如何把所謂的Project Charter轉譯成大家聽得懂的User Story?
舉個例子，你要怎樣把客戶的需求或是問題，轉成RD聽得懂的語言寫成ARD/PRD?
問題2:
當寫成所謂的ARD/PRD要做相關的Scoping Call的時候，你要怎樣把客人的意思
正確的傳達，並驗證內容來完善客戶的要求?
問題3:
在遇到開發困難的時候，你怎樣站在RD的角度與客戶溝通縮小中間的誤差?
特別是以客人聽得懂的語言來解釋你技術上的困難?
問題4:
在做內外協調的時候，你要怎樣把目前的方針與方案擬定好?
讓所有人都可以on the same page往同一個目標邁進?
這些完全都脫不開一個點，你要會說故事。
說故事這個問題點不在於怎樣講得天花亂墜
而是在於你是否會善用對方聽得懂的語言
或許有人會問，都是講中文或是英文哪有什麼問題
沒有，這問題學問可大著。
客人很多時候其實是不懂技術的
你要怎樣讓客人就算不懂技術也會知道問題在哪
其實姑且不說客人，你團隊內其實也不是每個人都懂技術
你要擬定應對計畫的時候很多時候也要清楚地讓不懂的人也能參與討論
剛從技術職轉PM相關職務的人，一開始經常會有像下面的問題
從頭到尾講天書...講一堆技術，然後說不清楚問題跟需要的時間跟資源
那個基本上就是幹話，沒有解決問題跟方向，講這些真的都是浪費時間
說故事的能力不外乎讓大家都清楚問題的狀況
另一方面也是避免討論過於發散，能讓問題更集中在要討論的事情上。
算是基本功，但問題是很多人根本不會去練的一塊。

技術職轉PM一開始的問題就是太RD thinking,但久了自然能抓到怎麼把故事說好。但 若是純PM要夾在RD與Non-RD之間，恐怕還是得在技術上下苦工

技術職跟客人導向又是另一個故事...