論產(chǎn)品經(jīng)理的自我修養(yǎng)

很多PM在需求評審時只告知要做什么，而不說明為什么要做。是啊，程序猿負(fù)責(zé)實(shí)現(xiàn)功能就好了，說其他的有什么用？然，這種想法是絕對錯誤的，大家同屬一個Team，一定要讓每一個人都明確目標(biāo)，同時也明確自己的努力可以向目標(biāo)邁進(jìn)一步。
而且，經(jīng)驗(yàn)豐富的程序猿會想到功能可能的延伸方向，提前做好可擴(kuò)展性。


不要強(qiáng)行評估工作量
即使是技術(shù)出身的PM，也不要強(qiáng)行去評估工作量并確定工期。切記，專業(yè)的事兒交給專業(yè)的人去做。

盡量別改需求
對產(chǎn)品來說，改需求是一句話的事兒；對技術(shù)來說，改需求可能意味著代碼廢棄、框架重構(gòu)...簡單說來就是通宵兩天寫的幾千行代碼沒用了。。所以，承接第1條，別YY需求，所有的需求都從產(chǎn)品目標(biāo)&用戶需求的兩個層面去考慮周全，避免在開發(fā)的過程中改需求。

及時反饋結(jié)果
功能上線后，達(dá)成的效果要及時反饋給程序猿（挑好的說），雖然大部分程序猿并不關(guān)心運(yùn)營指標(biāo)，但自己的努力取得了很好的效果，他們還是很高興的。同時，也會建立程序猿對PM的信心，信任PM的眼光，由此形成良性循環(huán)，溝通上會更加順暢。

把握好"度"
其實(shí)很多同學(xué)都缺乏這個，怎么講呢，舉個簡單的例子：需求會后定好了上線時間，但是在測試過程中發(fā)現(xiàn)一個BUG影響很大，難以解決，怎么辦？逼開發(fā)通宵加班解決BUG？講道理你沒錯，確定好了時間就一定按照時間節(jié)點(diǎn)走，但這類難以預(yù)見的問題影響開發(fā)進(jìn)度，該怎么辦呢？
所謂的把握好"度"，所謂的人情世故，大概這樣吧...