「PM只會出張嘴、改需求…」從RD抱怨文，談產品經理該做的事

這種思維的好處，除了讓RD感受到「參與感」，甚至是「英雄感」，而非「社畜感」，讓他們認知到自己的專業能力，才是實現這個願景的重要工具，也可以讓RD從他的角度，提出其他可行的解法。

甚至一個團隊合作了一段時間，有了默契，並累積了一些對客戶的認知，有時RD會記得之前聽過的客戶需求，有機會就在程式裡加入一些優化（那時做為PM會超驚喜！）或是會主動與PM討論解法，這些都能讓整個團隊更進步，也更團結。

反過來講，也有些PM會覺得，RD為什麼總是一個口令一個動作，很多顯而易見的設計，沒有講就不做，遇到也不會主動問PM，或是任何事情都要文件定義得清清楚楚才要開工，按表操課。

事實上，肯按表操課還是好的，慘的是文件最後寫得落落長，但根本沒人看。

其實我認為PM也可以思考，是不是雙方的溝通與合作模式，讓PM少了「為什麼要這麼做」的溝通，習慣讓RD「做就對了」。一旦習慣了這種「接單生產」的合作模式，怎麼能期待對方有對產品的熱情與ownership，主動「多做一步」呢？

或是RD吃過虧，「有私下答應過」的功能沒做到，被PM拿出來highlight變羅生門，久而久之就會要求什麼都先更新文件以自保。

這種「公事公辦」，都是雙方合作缺乏互信以及默契的結果，帶來的結果其實是一種資源的浪費，這當然雙方都有責任，要公事公辦也不是不行，但這樣的結果PM一般會比較痛。

所以，雖然初期的溝通與互信的建立很花時間，但我認為PM最重要的「做事」，應該就是在溝通中搞定多方，而這也跟PM的專業能力有關──如何挖掘真正的「Why」，並傳遞價值、激發熱情，是要有深刻洞察才做得到的。

抱怨２：需求一直改一直改，schedule卻沒變

其實我認為這個問題背後的問題，是資訊不透明。PM沒真正搞懂需求是什麼，心中也沒有商業價值判斷，就很容易變成傳聲筒，擋不住客人或老闆的要求。

不過反過來我也必須說，奢望需求一旦確定下來都不會改的人，跟要求程式寫好測過就要沒bug，是一樣的天真呀……

即使「改需求」難以避免，但PM還是有些能控制的方向，減少「人禍」造成的需求變更。