作者總結(jié)了自己在一個2B產(chǎn)品研發(fā)過程中遇到的幾個坑與大家分享，希望可以給各位帶來幫助。

2B 產(chǎn)品經(jīng)理，特別是創(chuàng)業(yè)公司的 2B 產(chǎn)品經(jīng)理，往往戰(zhàn)斗在和客戶溝通需求的第一線，同時也身兼和組內(nèi)或者公司內(nèi)開發(fā)對接、調(diào)整需求的第一責任人。由于信息在傳播過程中難免會有損失，以及客戶變更需求簡直比女人翻臉還快，所以，研發(fā)過程中如何和需求方（客戶）保持良好溝通以此來保證產(chǎn)品順利交付已經(jīng)是 2B 產(chǎn)品經(jīng)理的生存必備技能之一。

以下幾點是我在上一個 2B 產(chǎn)品研發(fā)過程中遇到的幾個坑，希望可以幫助到正在遇到同樣問題或者可能遇到類似問題的你。

1.畏懼客戶，若不是客戶主動聯(lián)系絕不會主動多問一句

這個簡直可以是 2B 產(chǎn)品研發(fā)過程中的命門死穴般的大忌。為什么這么說，主要是由于 2B 客戶盡管是需求方，但是他們對于自己想要什么，以及能夠提供什么，后期如何配合我們的工作幾乎可以算是一無所知。只經(jīng)過簡單的幾次需求溝通會議，就定下來的需求清單是經(jīng)不起推敲的?；蛟S大流程走下來是沒有問題的，但是諸多細節(jié)都必須和客戶一一對過。

有些產(chǎn)品經(jīng)理生性害羞，有的產(chǎn)品經(jīng)理甚至會覺得客戶三天兩頭改需求真“煩”。對于這些產(chǎn)品經(jīng)理，幾乎可以預(yù)料到在中期交付的產(chǎn)品功能一定和客戶最初所想相差甚遠。如果需求方吹毛求疵起來，少則要增減一些字段。更多的則直接是底層邏輯修改。到時候別說開發(fā)了，估計老板想要掐死產(chǎn)品的心都有了。

比如：在上個項目中我負責的一個 O2O 產(chǎn)品。其中時間控件的設(shè)計需要考慮到該服務(wù)點的承載量。而且作為一個全局控件，在多個頁面以及主功能流程上都有用到。最初需求溝通的時候我僅僅溝通了營業(yè)人員上下班時間。但后來開發(fā)過程中我發(fā)現(xiàn)還需要考慮到節(jié)假日上班時間以及服務(wù)站點的營業(yè)時間。若不是及時溝通，后來要修改的接口數(shù)絕不會少。

2.覺得關(guān)注產(chǎn)品研發(fā)進度是項目經(jīng)理的事情

有的大公司里項目經(jīng)理和產(chǎn)品經(jīng)理之間有明顯的界限，這些公司的項目經(jīng)理往往具備技術(shù)背景并且在公司里有一定的聲望。針對這種情況，產(chǎn)品經(jīng)理其實不必過多過問產(chǎn)品研發(fā)進度，定期和項目經(jīng)理合一下就好了。但是更多時候公司里的項目經(jīng)理不怎么“給力”，或者公司領(lǐng)導(dǎo)直接兼任項目經(jīng)理。這時產(chǎn)品經(jīng)理還是最好跟跟項目進度。畢竟我們是戰(zhàn)斗在第一線的人，面對需求方和老板的隨時發(fā)難，要做到胸中有譜。另外還有一點，就是經(jīng)常和研發(fā)過產(chǎn)品進度，可以幫助我們更好的把控產(chǎn)品研發(fā)新走向，除了額外可以學(xué)到技術(shù)上的零碎東西，有時候還可以替研發(fā)同事們排憂解難。

比如原型上的某個控件開發(fā)難度比較大，及時更換為網(wǎng)上已經(jīng)封裝好的用開源控件，可以節(jié)省下不少人力成本。再比如有時候交互上的一點邏輯調(diào)整可以讓后臺工程師直接減少幾十行的 Code 數(shù)。

3.不和產(chǎn)品的實際使用者確認產(chǎn)品 Demo

我個人覺得讓產(chǎn)品實際使用人員在設(shè)計階段就參與進來是件不錯的事。大家都知道 2B 產(chǎn)品需求對接方往往是企業(yè)管理者，他們往往不實際使用，或者并不是使用產(chǎn)品最多的人。他們最關(guān)心的不是產(chǎn)品性能而是確保產(chǎn)品功能點能夠 Cover 他們的業(yè)務(wù)線，讓投入產(chǎn)出比達到配比最優(yōu)。用戶體驗，產(chǎn)品交互細節(jié)等等對他們來說無所謂。對產(chǎn)品好壞最有發(fā)言權(quán)的人應(yīng)該是產(chǎn)品的最終使用者。因此我們應(yīng)該珍視他們的建議。有時候產(chǎn)品經(jīng)理絞盡腦汁苦思冥想了很久的方案其實是脫離實際業(yè)務(wù)場景的。我們自嗨式的陶醉在某個交互里，但說不定在實際場景中并沒有那么好用，甚至不能用。為了杜絕這種事情發(fā)生，我們應(yīng)該從設(shè)計階段到研發(fā)交付這段時間內(nèi)都不斷的讓產(chǎn)品最終使用者參與進來。

比如，有些時候產(chǎn)品經(jīng)理對實際的業(yè)務(wù)場景并不是十分熟悉，并不能特別好的掌握產(chǎn)品的實際業(yè)務(wù)層級。這個時候”卡片分類法”就派上用場。讓實際使用者來為我們出謀劃策。另外，產(chǎn)品即將交付的時候找來幾個實際使用者做冒煙測試也是不錯的選擇。他們是最熟悉自己業(yè)務(wù)場景的人，幾乎可以測試到所有在實際業(yè)務(wù)中高頻的場景。若真的存在流程問題，我們可以及時調(diào)整優(yōu)化。

4.不重視文檔更新、部門內(nèi)的報聯(lián)商

由于工期短、人手往往短缺、資源不足這樣的現(xiàn)狀下導(dǎo)致2B 產(chǎn)品需求變更非常頻繁，每一次更改都需要更新文檔。但忙起來常常容易遺忘掉，從而釀成許多不應(yīng)該犯的錯誤。很多時候和客戶溝通后，我們更改了原型上的一處小細節(jié)，并且通知了我們自以為會影響的開發(fā)，但這中間總會遺漏一些人。并且在研發(fā)后期極易出現(xiàn)扯皮。

比如測試驗收的時候發(fā)現(xiàn)界面多處對不上。移動端同事說：“我就是按照原型開發(fā)的”，然后打開了手頭兩個月前你發(fā)給他的原型，但測試手頭的原型是你昨天發(fā)給他的最新版，其中就頁面層就有至少 20 多出的細小修改。這部分的人力成本誰來 Cover 呢？這個鍋恐怕最后還是會讓產(chǎn)品背。

好的需求文檔管理方式有很多種，我就不班門弄斧了。自己常用方法是最簡單的一種：每次更改原型后都會郵件發(fā)送整個項目人員。郵件正文中我會簡要標明本次修改點，并明確告知最新文檔的地址。

• 文檔命名方式：產(chǎn)品名稱 + 版本號 + 修改日期；
• 文檔更改記錄：RP 原型文件上有更改記錄、若有其他 PRD 也在表頭首先注明文檔更改的部分

不給對方和自己扯皮的機會，也不會因為自己的失誤、遺漏增加他人的工作量，是我們和開發(fā)之間信任的基石。

5.不做產(chǎn)品復(fù)盤會

但凡渴求進步、蒸蒸日上的公司、項目組都會在產(chǎn)品發(fā)布完畢后開一個小小的產(chǎn)品研發(fā)復(fù)盤會。分析下從立項到結(jié)項這一系列過程中部門的得與失。至于怎么開、開的質(zhì)量如何其實和領(lǐng)導(dǎo)氣質(zhì)有很大關(guān)系。我們作為小小的 PM 有時候想使勁也使不上來。但至少應(yīng)該做好自己的那一份。也就是在產(chǎn)品復(fù)盤會上認真深刻的反思項目中產(chǎn)品層面的得與失。

其中應(yīng)包含的內(nèi)容有：本次研發(fā)過程中產(chǎn)品部門做的好的點，不足的點。對于不足的點盡可能說的細一些，理解的深刻一些，最好可以深挖出不足的深層原因，并提出相應(yīng)的解決對策。只有自己總結(jié)出的足夠深刻的見解才能在腦海中形成記憶。作為產(chǎn)品經(jīng)理應(yīng)該珍惜每一次產(chǎn)品復(fù)盤會的機會。不僅是自己重新審視整個項目從 0 到 1 的機會也是一個自我學(xué)習、迭代的好機會。這次的閃光點就是將來的寶貴經(jīng)驗。這次的失敗之處就是以后重點關(guān)注的內(nèi)容。

本文作者：晞仔（lolitaxi61）個人公眾號：晞仔的生活實驗室

本文由 @晞仔 原創(chuàng)發(fā)布于愛盈利-運營小咖秀。未經(jīng)許可，禁止轉(zhuǎn)載。