本文作者結(jié)合自己的實踐經(jīng)驗，分享了To B軟件產(chǎn)品設計在產(chǎn)品研發(fā)階段的相關工作，并對各個環(huán)節(jié)需要注意的問題進行了分析總結(jié)，供大家一同參考和學習。

產(chǎn)品研發(fā)階段可以說是最考驗產(chǎn)品經(jīng)理協(xié)調(diào)溝通能力的時候，因為在這個階段，產(chǎn)品經(jīng)理的主要工作都在嘴上，跟研發(fā)大佬要人、要排期；跟所有研發(fā)團隊的每個人對需求、回答問題；跟測試團隊的每個人對需求、回答問題；跟市場團隊溝通市場預熱活動……這個階段的產(chǎn)品其實最像是打雜的~~~ 好多產(chǎn)品也是栽在這個階段。既然都是口頭工作，接下來咱們聊聊這里面的一些我認為還算有效的工作方法和技巧。

產(chǎn)品研發(fā)流程通常是按照技術(shù)選型、功能開發(fā)、功能測試這幾個階段來執(zhí)行的，大部分企業(yè)有專業(yè)的項目經(jīng)理來負責排期和盯進度，我們公司沒這個條件，都是由產(chǎn)品直接跟技術(shù)對接的，幸虧我是研發(fā)、項目經(jīng)理、產(chǎn)品的轉(zhuǎn)型路徑，還能勉強Hold住。所以，我會在介紹各項工作內(nèi)容的過程中穿插一些項目管理的東西，我的工作方法真的不一定適合所有人，大家批判的看吧，以參考為主。

一、總體溝通

能進入這個階段，就說明你負責的產(chǎn)品的市場機會（MRD）已經(jīng)得到了公司大佬的認可了，有了大佬這顆大樹，你就可以開展后面的活動了。首先要做一次整體的溝通，這個溝通一定要開會，參會人員包括：

• 技術(shù)組的老大（一般是技術(shù)總監(jiān)，根據(jù)實際情況來，一般得是給你安排人、排期的人），
• 產(chǎn)品這邊的相關人員（一般產(chǎn)品總監(jiān)得參會，得跟技術(shù)總監(jiān)那邊的大佬Level對等）
• 團隊人員都叫過來（我們一般這個時候還沒有正式開始，所以只安排了二級Leader）
• 市場相關人員
• 銷售相關人員

大家開個會統(tǒng)一一下意見，這個會主要從以下幾個方面給大家做個介紹：

1. 產(chǎn)品整體情況（從MRD里面撈干的說）
2. 各主要功能的開發(fā)時間評估
3. 各功能模塊優(yōu)先級
4. 本期準備開發(fā)的功能
5. 預計的開始時間和上線時間

開這個會的目的有幾個，一方面跟大佬們統(tǒng)一意見，讓大家了解即將開始研發(fā)的產(chǎn)品內(nèi)容已便于大佬們（或者安排下面人）構(gòu)思產(chǎn)品整體框架；最重要的是跟各部門大佬們混個臉熟，以后找他們的時候，不會一臉懵逼的想這哥們兒是誰。

開會的時候一般會記錄會議紀要，各大佬的提出的問題一定要記著，會上能回答的就會上回答（要在會議記錄里面體現(xiàn)），會上不能回答的，要做個QAList，會后研討解決了，通過郵件發(fā)給提出問題的大佬，同時抄送參會的其他人員，如果還有追加問題，也都通過QAList統(tǒng)一做記錄、跟蹤，所有大佬提出的問題一定都要有響應、有回答，直到對方滿意為止。

這樣做的目的是要讓流程閉環(huán)，不要遺留任何問題到后面的階段，一旦遺留了問題，這個問題一定會變成一個巨大的坑，越是小問題，越會在項目即將結(jié)束的時候爆發(fā)出來，影響越大。很多公司都有相關的系統(tǒng)，我們沒有，所以QA是我自己用Excel維護的，大概是這樣的：

• 引入階段：這個時候你就要寫XXXX年XX月XX日項目溝通會
• 當前階段：那就是立項階段
• 問題描述：直接從會議紀要里面摘，千萬別改，就是原來的問題
• 提出人：提問題的人的名字
• 目標解決日期：預計你要那天解決
• 解決人：這個問題要誰來解決，要有具體的人
• 解決方案：預計這個問題應該怎么解決，主要描述思路和方案
• 實際解決日期：提出方案是啥時候提出來的
• 狀態(tài)：Open、Close兩個狀態(tài)，Open就是還沒解決，Close就是已經(jīng)解決了；
• 確認：OK、NG兩個狀態(tài)，OK就是提出人對解決方案滿意，NG就是不滿意。

這個問題列表是要貫穿在整個項目進行過程中的，各個階段提出來的問題都要記錄在這個問題列表中，后面要持續(xù)追蹤，一定要閉環(huán)。

這里舉個例子：比如說研發(fā)大佬提出一個技術(shù)上的問題，可以提出解決方案，但是具體是在研發(fā)階段才能解決，那么狀態(tài)不能是Close，直到研發(fā)的人確認這個已經(jīng)體現(xiàn)在這個階段了，你才能設置成Close，同時發(fā)給提出人讓他來確認。

總體溝通會開完了，你和其他部門的思想也都統(tǒng)一了，研發(fā)那邊會給你安排人（開始至少會安排幾個Leader級別的人），就可以開始下一步的工作了。

二、講解PRD

確定了研發(fā)的人，你首先要做的就是給他們講產(chǎn)品設計，這個階段大家關注的應該就是產(chǎn)品功能實現(xiàn)本身了，你要拿著這一期要開發(fā)的功能列表、優(yōu)先級、PRD來講。一般講解的順序是：

1. 講需求列表和優(yōu)先級，要讓具體研發(fā)的人對產(chǎn)品功能有一個整體上的判斷；
2. 講PRD，讓研發(fā)人員對具體實現(xiàn)有個認識；
3. 講注意事項，比如預計多少用戶啦、預計并發(fā)量啦、客戶環(huán)境情況等等，這些小細節(jié)都是會影響到他們技術(shù)選型工作的。

如果設計的產(chǎn)品功能比較多，建議分開幾次會議講，講完了要讓研發(fā)消化一下，按照我的經(jīng)驗，一般是隔一天講一下，當然有時候研發(fā)那邊沒那么多時間，那就得集中講了，不過集中講內(nèi)容會比較多，效果不太好。

講解的過程中、講解后一般研發(fā)會問很多問題，這個問題也要記錄在項目問題列表里來做整體的追蹤，上面已經(jīng)講過了，這里就不再講了。

注意，研發(fā)人員在考慮問題的時候，會從技術(shù)層面把場景擴大化，那么他們提出來的問題可能是問題，可能是風險。如果識別出來是風險，那就要把問題轉(zhuǎn)為風險管理。我們也沒有風險管理的系統(tǒng)，都是我自己追蹤的，所以做完了大概是這樣子的：

• 風險類別：那就是說什么類型的風險，我一般劃分為資源風險、業(yè)務風險、管理風險和技術(shù)風險；
• 風險來源：就是說風險可能從哪兒來，我一般會劃分為客戶、技術(shù)、工程過程、人力資源、設備；
• 風險描述：說明一下啥風險，一般是可能造成項目延期的，一定是可能造成；
• 風險影響：就是這個風險一旦真的發(fā)生了，可能造成啥影響；
• 風險發(fā)生現(xiàn)象：就是告訴大家怎么判斷風險真的發(fā)生了；
• 跟蹤時間：就是到那天或者什么階段，可以判斷這個風險發(fā)生的可能性沒有了；
• 可能性：發(fā)生可能性大概是多少；
• 風險等級：根據(jù)影響判斷等級，一般是高、中、低，高等級一定要每天都跟蹤；
• 處理放式：就是風險發(fā)生了咋處理，一般包括接受、避免、轉(zhuǎn)移、減緩；
• 應對措施：就是根據(jù)你選擇的處理方式描述你準備咋應對，以最大化降低影響；
• 狀態(tài)：狀態(tài)分為開放、關閉、忽略、轉(zhuǎn)為問題。開放就是還沒發(fā)生，有可能發(fā)生，關閉就是肯定發(fā)生不了了；忽略就是影響不大，發(fā)生就發(fā)生吧；轉(zhuǎn)為問題那就是真他娘的發(fā)生了，已經(jīng)發(fā)生了就不能叫風險了，叫問題，得放到問題列表中去處理解決。

三、技術(shù)選型

給研發(fā)把事兒講明白了，他們就要做技術(shù)選型了，這時候常規(guī)的產(chǎn)品經(jīng)理存在感相當小，因為聽了你也不懂。這時候作為研發(fā)出身的產(chǎn)品的我，優(yōu)勢就體現(xiàn)出來了。我們一般是技術(shù)會根據(jù)需求做好幾個選型方案，做好了要開會給我們講。一般產(chǎn)品需要從以下幾個方面去看技術(shù)選型方面的內(nèi)容：

1. 性能以及擴展性：就是你做的技術(shù)方案能不能支撐我預期那么大的并發(fā)量，后續(xù)如果我并發(fā)量更大你還頂不頂?shù)米。?/li>
2. 安全性：就是你做的方案安全性能保證不？用戶信息會不會泄露，有沒有這方面的考慮；
3. 產(chǎn)品自身安全性：就是有沒有可能被盜版；
4. 可定制性：就是如果客戶改需求了，你能不能快速對應；
5. 升級：就是產(chǎn)品有BUG或者有了新特性，咋給人家升級。

一般從這五個方面去問他們，如果某一個方案沒考慮就pass，如果能剩下一個方案，那就選這個；如果一個也剩不下，那就委婉的問問能不能再想想；如果都能剩下（那就是研發(fā)相當牛掰），就讓研發(fā)自己推薦，他們肯定是有一個最滿意的，如果你聽不懂他們說啥你選第二推薦就行（因為他們最滿意的肯定最復雜，別問我咋知道的）。

會后別忘了發(fā)會議記錄，產(chǎn)品提出來的問題也是要做閉環(huán)管理的，研發(fā)那邊也要回答的~ 他們那么忙肯定沒時間嗎，沒關系，這小事兒，產(chǎn)品幫他來管理，時不時去問問就行。

四、研發(fā)階段

都準備好了的話，就進入研發(fā)階段了。這個階段產(chǎn)品通常就是回答研發(fā)爸爸們的問題了，這方面我就不講了，如果你產(chǎn)品設計過程中，都考慮到了，直接能回答最好，一般回答都是告訴他們以下信息點：

1. 這個內(nèi)容是啥樣的；
2. 為啥是這樣的；
3. 實在做不成這樣的話，你說你能做成啥樣的;
4. 那行吧\先這樣吧\那不行，咱要不再商量商量。

進入研發(fā)階段最重要的就是要了解各功能的開發(fā)情況，我們是每天上午開個早會，大概15分鐘，然后記錄整體進度情況。因為我自己希望了解的更精細一點，雖然公司有項目管理的系統(tǒng)，我自己也弄了一個小的進度管理模板來記錄進度信息，精確到天的，類似這樣的：

這里面會把各個功能、團隊、工作內(nèi)容（他們告訴我的）、每天的情況做個記錄。

• StandBy就是還沒開始
• Plan就是計劃開始了
• Doing就是正在做
• OK就是做完了

每天記錄完了跟總體排期去比對，這樣你對整體上線時間就有相對比較精確的了解了。然后按照整體排期來催他們（催的時候千萬帶好小零食、奶茶、咖啡和個人護具）。

一般他們調(diào)完一個功能我們就會上去隨便點點、用用，需求理解上的偏差越早發(fā)現(xiàn)對項目的影響越小。

五、功能測試

我們的測試團隊跟研發(fā)團隊是一個團隊，所以整體過程是一起管理的，不過產(chǎn)品一定要評審測試團隊的測試計劃和測試用例。測試計劃里面重點關注的是測試啟動條件、硬件環(huán)境、時間進度安排；測試用例關注的是測試的點對不對，測試內(nèi)容是不是能覆蓋到功能細節(jié)。還是老規(guī)矩，評審后的問題也要放在問題列表里面做跟蹤。

另外，測試結(jié)束后要求提交測試報告，測試報告應該包括測試用例及測試結(jié)果；測試了幾輪；BUG有沒有收斂趨勢；壓力測試的報告等等。

我之前的公司甚至要根據(jù)代碼行數(shù)來計算用例覆蓋率、BUG殘留率等等品質(zhì)指標，現(xiàn)在好像這么計算的比較少了。

好了，經(jīng)過一段時間的研發(fā)工作后，研發(fā)團隊將給你提交以下幾個成果物：

• 產(chǎn)品包（線上的或者安裝包）
• 產(chǎn)品部署手冊（線下一般有）
• 產(chǎn)品測試報告

拿到這幾個成果物了，我們產(chǎn)品就要開始我們的驗收、市場支持相關的工作了，了解后續(xù)工作，且聽下回分解吧。

#相關閱讀#

市場分析階段：To B軟件產(chǎn)品設計流程總結(jié)

產(chǎn)品設計階段：To B軟件產(chǎn)品設計流程總結(jié)

本文由 @Jimmy.jing 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議