產(chǎn)品經(jīng)理如何抓住程序員的心

產(chǎn)品經(jīng)理（Product Manager）是任何新創(chuàng)產(chǎn)品的關鍵角色，他定義了產(chǎn)品的需求規(guī)格，找出產(chǎn)品的價值所在。而一個成功的產(chǎn)品代表結合了好的產(chǎn)品需求規(guī)格，以及能夠依據(jù)這個需求規(guī)格實作出來的工程團隊。我們說產(chǎn)品經(jīng)理負責產(chǎn)品原型設計，而開發(fā)團隊負責整個產(chǎn)品的開發(fā)，兩者缺一不可。由此可知產(chǎn)品經(jīng)理與程序員團隊之間的關系有多么重要。

為了幫助產(chǎn)品經(jīng)理與程序員團隊的合作更緊密，一起打造更好的產(chǎn)品，以下幾點是我的建議：

1.定義清楚這個產(chǎn)品

這是最基本也是重要的，重要的事情說三遍：「定義產(chǎn)品」、「定義產(chǎn)品」、「定義產(chǎn)品」，為什么這么根本的事情還作不好呢？很多時候是組織的問題，沒有人專職負責，例如：

產(chǎn)品經(jīng)理就是老板。但是老板太忙了，只定義了核心需求，而沒有定義細節(jié)規(guī)格。于是程序員就得自己腦補，最后做錯了被罵又重做。

銷售客服來兼職產(chǎn)品經(jīng)理。銷售很了解如何告訴世界這個產(chǎn)品有多棒，但是卻不一定能夠發(fā)現(xiàn)需求并定義清楚這個產(chǎn)品，這兩者的技能是不一樣的。并且很容易發(fā)生傳聲筒現(xiàn)象，直接把單一客戶的需求告訴程序員，而非經(jīng)過一致的產(chǎn)品思考規(guī)劃以及使用者體驗設計。

我們會在之后的文章繼續(xù)探討什么是好的規(guī)格文件。它代表了使用者應該要有什么體驗、產(chǎn)品有哪些功能和行為，以及功能的開發(fā)優(yōu)先級。除了基本的用戶需求，也應包含產(chǎn)品框架界面流程和關鍵的測試案例。

2.建立良好的溝通渠道

就算規(guī)格寫的再清楚，開始實作之后就會有一堆問題冒出來。如果沒有人可以問或是等不到產(chǎn)品經(jīng)理的回復，開發(fā)人員就會開始腦補這個功能，硬著頭皮繼續(xù)做下去（然后又做錯了被罵，需要重做）。或是就停下來，找其他低優(yōu)先的事情來做。無論怎樣都是很大的浪費。

建立一個良好的溝通渠道，讓程序員可以很快地跟產(chǎn)品經(jīng)理問到答案。這里如果整個項目開發(fā)有專業(yè)的項目經(jīng)理負責，溝通會變得流暢許多。

3.不要負責項目管理

如果沒有專職的項目經(jīng)理（Project Manager），那么產(chǎn)品的開發(fā)者必須親自來負責項目進度。不要讓產(chǎn)品經(jīng)理去兼項目管理。項目管理的重點在于執(zhí)行及發(fā)布產(chǎn)品、協(xié)調(diào)開發(fā)、測試與營運團隊。讓產(chǎn)品經(jīng)理來做很大程度上會造成兩方關系的緊繃，壓榨程序員的故事不斷真實上演，就是因為由不了解軟件工程的人負責項目管理所導致的。

在知名的Scrum敏捷軟件開發(fā)方法中就提到：產(chǎn)品經(jīng)理決定作什么，讓整個程序開發(fā)團隊決定如何做及可以做多少。

4.不要告訴程序員開發(fā)團隊怎么做，告訴他們要做什么

很多產(chǎn)品經(jīng)理喜歡把需求描述成解決方案，指定了一個不可行或者是成本效益很低的作法，而不是告訴程序員他們想要達到的目標，或是想要解決的問題根本是什么。

F-16是史上最成功的戰(zhàn)斗機之一，在一開始設計的要求是需要超過兩馬赫的速度，首席設計師問了美國空軍為什么飛行速度這么重要，答復是「飛機必須可以從戰(zhàn)斗中逃脫」。最后的設計并沒有超過兩馬赫，但是卻可以讓飛機很敏捷的逃脫，透過了無框的坐艙、抬頭顯示器，讓飛行員有更好的視野。可傾斜的座位降低了重力影響。飛行控制桿是安裝在右手邊上，而非傳統(tǒng)的在兩腿之間，用來輔助在高G值時轉彎。這些設計不但也能達成設計目標，更降低了生產(chǎn)成本。

這個問題其實不只產(chǎn)品經(jīng)理，工程師本身也常犯這個錯誤，常常可以在討論區(qū)看到有人問「請問這個指令X怎么用」，然后底下的討論怎樣都無法完全解決他的問題，直到有人問「為什么你需要這個X？」，他回答「因為他要做Y功能」，大家恍然大悟用X來解決根本是錯的，應該用指令A就可以很簡單的解決了。

在大多數(shù)的情況下，程序員比產(chǎn)品經(jīng)理更清楚知道哪個實作方案最適合。

5.相信程序員專業(yè)性

產(chǎn)品經(jīng)理負責產(chǎn)品的專業(yè)體驗，而工程團隊負責如何正確的構建產(chǎn)品。相信程序員的專業(yè)，就是讓開發(fā)團隊可以實行任何他們認為建構一個有質(zhì)量產(chǎn)品需要的作法，例如撰寫自動化測試、面對編程、建構CI持續(xù)整合環(huán)境，Code Review代碼復審等等。這些工作雖然不直接與產(chǎn)品需求相關，卻對工程質(zhì)量有很大的影響。這些事情現(xiàn)在不做，在項目開發(fā)幾個月之后，很快就會吞噬整個項目進度和質(zhì)量。

以上五點可以幫助產(chǎn)品經(jīng)理和程序員開發(fā)團隊更愉快的合作，但是請記得無論開發(fā)團隊再優(yōu)秀，如果產(chǎn)品經(jīng)理無法定義出一個值得建造的產(chǎn)品，一切也是枉然。