※ 引述《geocube (edwin)》之銘言：
: 小弟最近寫了些文，是針對於公司工程師溝通的時候遇到的問題。
: 有人常覺得工程師很難搞，只是我常常覺得很多時候只是時機不會，
: 想在軟體工作版來問一下，各位覺得還有什麼溝通瓶頸呢?
: 以下附上文章給各位參考。
: 圖文好讀版：http://ppt.cc/Xkcb
你這文章設定的基礎,一來是說自己是企劃,並沒有管理權,二來是假定工程師都是
被管控的單位.
身為一個自認為自主工作的軟體工程人員,簡單說一下我的意見:
1. 想清楚你與工程人員的合作程度,是有沒有必要用到足夠量的溝通:
也就是說,你有沒有必要專程打擾他,只為了問他某一個項目要做多久.
2. 跟上節奏. 你想得很好,工程師進入 coding 模式就很難叫得動,
往往是因為當你打擾他的時候,是讓他停下來,動作或速度慢下來,
表面上是說"工程師的思緒被打斷",但實際上可能是非工程人員沒有跟著
工程的運作,保持同樣的節奏.
工程導向的公司,以工程節奏為主,非工程人員配合工程人員;
服務導向的公司,以企劃節奏為主,非企劃人員要配合動作.
較麻煩的是各自以為有各自的節奏就好,那就不是一個團隊.
3. 拿出你自己的專業,秀給他看,才能讓他相信你:
如果你是PM,我會期待你不會跑來自以為你可以管控我的時間,反而,
假如在工作流程中,因為有一些工作擁擠了,你能夠提出排解工作擁擠的意見,
那麼,我會覺得你夠專業.
而不是一些很遜的傻PM,只會默默修改自己的甘特圖,只會跑來問說,你覺得
哪一件事情要多少時間來做,無法解讀工程人員寫在issue tracking system
上的文字,而且,在事情來不及了只會建議:加班.
如果你是個PM而你來問我某件需求的預期日數之後,沒有回饋任何訊息就跑掉,
那我直覺就是,你可能沒什麼專業. PM的專業在溝通以及專案的運籌,所以,
PM專程來找我講話,最好是能像是在地圖上指出 "我們現在在哪裡,而我們
接下來要往那個方向去" 這樣一種有效又明確的資訊.
至於,如果是問個日期就跑去登記自己的甘特圖,八成都是自以為是專門管理
人的管理者那種PM,專業上沒有比你好,至於管理人管理得多好,就看人了.
我的經驗是,這種PM可能會為了自己的甘特圖的一點點數字,跑來跟你吵架.
4. 不要預設底限或超低底限的答案很糟:
就拿日數來說,跟你說一件事情要六十天,是很糟糕的事情嗎?
提這一點,可能跟前一點重複,這就是你當企劃可以玩專業,展現專業的地方.
什麼樣的預期日數,也許是代表什麼樣的費用,但也可能代表什麼樣的籌碼.
只從時間維度上換算成本,是唯一的決策因素嗎? 而小成本能多聰明地換得
大營收?
一個工程師講出這話,可能不代表他個人的情緒,而是他在狡詐地挑戰你的專業.
因為程式大多是四兩撥千斤,但是許多企劃面的保守牌,穩穩賺或者破盤價,
可能才是隱約地激怒他們的因素.
就這樣子啦,隨便提出零星幾個意見.