本文作者結合自己的實踐經驗，分享了To B軟件產品設計在產品研發階段的相關工作，並對各個環節需要注意的問題進行了分析總結，供大家一同參考和學習。
產品研發階段可以説是最考驗產品經理協調溝通能力的時候，因為在這個階段，產品經理的主要工作都在嘴上，跟研發大佬要人、要排期；跟所有研發團隊的每個人對需求、回答問題；跟測試團隊的每個人對需求、回答問題；跟市場團隊溝通市場預熱活動……這個階段的產品其實最像是打雜的~~~ 好多產品也是栽在這個階段。既然都是口頭工作，接下來咱們聊聊這裏面的一些我認為還算有效的工作方法和技巧。
產品研發流程通常是按照技術選型、功能開發、功能測試這幾個階段來執行的，大部分企業有專業的項目經理來負責排期和盯進度，我們公司沒這個條件，都是由產品直接跟技術對接的，幸虧我是研發、項目經理、產品的轉型路徑，還能勉強Hold住。所以，我會在介紹各項工作內容的過程中穿插一些項目管理的東西，我的工作方法真的不一定適合所有人，大家批判的看吧，以參考為主。
一、總體溝通能進入這個階段，就説明你負責的產品的市場機會（MRD）已經得到了公司大佬的認可了，有了大佬這顆大樹，你就可以開展後面的活動了。首先要做一次整體的溝通，這個溝通一定要開會，參會人員包括：
- 技術組的老大（一般是技術總監，根據實際情況來，一般得是給你安排人、排期的人），
- 產品這邊的相關人員（一般產品總監得參會，得跟技術總監那邊的大佬Level對等）
- 團隊人員都叫過來（我們一般這個時候還沒有正式開始，所以只安排了二級Leader）
- 市場相關人員
- 銷售相關人員
大家開個會統一一下意見，這個會主要從以下幾個方面給大家做個介紹：
- 產品整體情況（從MRD裏面撈乾的説）
- 各主要功能的開發時間評估
- 各功能模塊優先級
- 本期準備開發的功能
- 預計的開始時間和上線時間
開這個會的目的有幾個，一方面跟大佬們統一意見，讓大家瞭解即將開始研發的產品內容已便於大佬們（或者安排下面人）構思產品整體框架；最重要的是跟各部門大佬們混個臉熟，以後找他們的時候，不會一臉懵逼的想這哥們兒是誰。
開會的時候一般會記錄會議紀要，各大佬的提出的問題一定要記着，會上能回答的就會上回答（要在會議記錄裏面體現），會上不能回答的，要做個QAList，會後研討解決了，通過郵件發給提出問題的大佬，同時抄送參會的其他人員，如果還有追加問題，也都通過QAList統一做記錄、跟蹤，所有大佬提出的問題一定都要有響應、有回答，直到對方滿意為止。
這樣做的目的是要讓流程閉環，不要遺留任何問題到後面的階段，一旦遺留了問題，這個問題一定會變成一個巨大的坑，越是小問題，越會在項目即將結束的時候爆發出來，影響越大。很多公司都有相關的系統，我們沒有，所以QA是我自己用Excel維護的，大概是這樣的：
- 引入階段：這個時候你就要寫XXXX年XX月XX日項目溝通會
- 當前階段：那就是立項階段
- 問題描述：直接從會議紀要裏面摘，千萬別改，就是原來的問題
- 提出人：提問題的人的名字
- 目標解決日期：預計你要那天解決
- 解決人：這個問題要誰來解決，要有具體的人
- 解決方案：預計這個問題應該怎麼解決，主要描述思路和方案
- 實際解決日期：提出方案是啥時候提出來的
- 狀態：Open、Close兩個狀態，Open就是還沒解決，Close就是已經解決了；
- 確認：OK、NG兩個狀態，OK就是提出人對解決方案滿意，NG就是不滿意。
這個問題列表是要貫穿在整個項目進行過程中的，各個階段提出來的問題都要記錄在這個問題列表中，後面要持續追蹤，一定要閉環。
這裏舉個例子：比如説研發大佬提出一個技術上的問題，可以提出解決方案，但是具體是在研發階段才能解決，那麼狀態不能是Close，直到研發的人確認這個已經體現在這個階段了，你才能設置成Close，同時發給提出人讓他來確認。
總體溝通會開完了，你和其他部門的思想也都統一了，研發那邊會給你安排人（開始至少會安排幾個Leader級別的人），就可以開始下一步的工作了。
二、講解PRD確定了研發的人，你首先要做的就是給他們講產品設計，這個階段大家關注的應該就是產品功能實現本身了，你要拿着這一期要開發的功能列表、優先級、PRD來講。一般講解的順序是：
- 講需求列表和優先級，要讓具體研發的人對產品功能有一個整體上的判斷；
- 講PRD，讓研發人員對具體實現有個認識；
- 講注意事項，比如預計多少用户啦、預計併發量啦、客户環境情況等等，這些小細節都是會影響到他們技術選型工作的。
如果設計的產品功能比較多，建議分開幾次會議講，講完了要讓研發消化一下，按照我的經驗，一般是隔一天講一下，當然有時候研發那邊沒那麼多時間，那就得集中講了，不過集中講內容會比較多，效果不太好。
講解的過程中、講解後一般研發會問很多問題，這個問題也要記錄在項目問題列表裏來做整體的追蹤，上面已經講過了，這裏就不再講了。
注意，研發人員在考慮問題的時候，會從技術層面把場景擴大化，那麼他們提出來的問題可能是問題，可能是風險。如果識別出來是風險，那就要把問題轉為風險管理。我們也沒有風險管理的系統，都是我自己追蹤的，所以做完了大概是這樣子的：
- 風險類別：那就是説什麼類型的風險，我一般劃分為資源風險、業務風險、管理風險和技術風險；
- 風險來源：就是説風險可能從哪兒來，我一般會劃分為客户、技術、工程過程、人力資源、設備；
- 風險描述：説明一下啥風險，一般是可能造成項目延期的，一定是可能造成；
- 風險影響：就是這個風險一旦真的發生了，可能造成啥影響；
- 風險發生現象：就是告訴大家怎麼判斷風險真的發生了；
- 跟蹤時間：就是到那天或者什麼階段，可以判斷這個風險發生的可能性沒有了；
- 可能性：發生可能性大概是多少；
- 風險等級：根據影響判斷等級，一般是高、中、低，高等級一定要每天都跟蹤；
- 處理放式：就是風險發生了咋處理，一般包括接受、避免、轉移、減緩；
- 應對措施：就是根據你選擇的處理方式描述你準備咋應對，以最大化降低影響；
- 狀態：狀態分為開放、關閉、忽略、轉為問題。開放就是還沒發生，有可能發生，關閉就是肯定發生不了了；忽略就是影響不大，發生就發生吧；轉為問題那就是真他孃的發生了，已經發生了就不能叫風險了，叫問題，得放到問題列表中去處理解決。
給研發把事兒講明白了，他們就要做技術選型了，這時候常規的產品經理存在感相當小，因為聽了你也不懂。這時候作為研發出身的產品的我，優勢就體現出來了。我們一般是技術會根據需求做好幾個選型方案，做好了要開會給我們講。一般產品需要從以下幾個方面去看技術選型方面的內容：
- 性能以及擴展性：就是你做的技術方案能不能支撐我預期那麼大的併發量，後續如果我併發量更大你還頂不頂得住；
- 安全性：就是你做的方案安全性能保證不？用户信息會不會泄露，有沒有這方面的考慮；
- 產品自身安全性：就是有沒有可能被盜版；
- 可定製性：就是如果客户改需求了，你能不能快速對應；
- 升級：就是產品有BUG或者有了新特性，咋給人家升級。
一般從這五個方面去問他們，如果某一個方案沒考慮就pass，如果能剩下一個方案，那就選這個；如果一個也剩不下，那就委婉的問問能不能再想想；如果都能剩下（那就是研發相當牛掰），就讓研發自己推薦，他們肯定是有一個最滿意的，如果你聽不懂他們説啥你選第二推薦就行（因為他們最滿意的肯定最複雜，別問我咋知道的）。
會後別忘了發會議記錄，產品提出來的問題也是要做閉環管理的，研發那邊也要回答的~ 他們那麼忙肯定沒時間嗎，沒關係，這小事兒，產品幫他來管理，時不時去問問就行。
四、研發階段都準備好了的話，就進入研發階段了。這個階段產品通常就是回答研發爸爸們的問題了，這方面我就不講了，如果你產品設計過程中，都考慮到了，直接能回答最好，一般回答都是告訴他們以下信息點：
- 這個內容是啥樣的；
- 為啥是這樣的；
- 實在做不成這樣的話，你説你能做成啥樣的;
- 那行吧\\先這樣吧\\那不行，咱要不再商量商量。
進入研發階段最重要的就是要了解各功能的開發情況，我們是每天上午開個早會，大概15分鐘，然後記錄整體進度情況。因為我自己希望瞭解的更精細一點，雖然公司有項目管理的系統，我自己也弄了一個小的進度管理模板來記錄進度信息，精確到天的，類似這樣的：
這裏面會把各個功能、團隊、工作內容（他們告訴我的）、每天的情況做個記錄。
- StandBy就是還沒開始
- Plan就是計劃開始了
- Doing就是正在做
- OK就是做完了
每天記錄完了跟總體排期去比對，這樣你對整體上線時間就有相對比較精確的瞭解了。然後按照整體排期來催他們（催的時候千萬帶好小零食、奶茶、咖啡和個人護具）。
一般他們調完一個功能我們就會上去隨便點點、用用，需求理解上的偏差越早發現對項目的影響越小。
五、功能測試我們的測試團隊跟研發團隊是一個團隊，所以整體過程是一起管理的，不過產品一定要評審測試團隊的測試計劃和測試用例。測試計劃裏面重點關注的是測試啓動條件、硬件環境、時間進度安排；測試用例關注的是測試的點對不對，測試內容是不是能覆蓋到功能細節。還是老規矩，評審後的問題也要放在問題列表裏面做跟蹤。
另外，測試結束後要求提交測試報告，測試報告應該包括測試用例及測試結果；測試了幾輪；BUG有沒有收斂趨勢；壓力測試的報告等等。
我之前的公司甚至要根據代碼行數來計算用例覆蓋率、BUG殘留率等等品質指標，現在好像這麼計算的比較少了。
好了，經過一段時間的研發工作後，研發團隊將給你提交以下幾個成果物：
- 產品包（線上的或者安裝包）
- 產品部署手冊（線下一般有）
- 產品測試報告
拿到這幾個成果物了，我們產品就要開始我們的驗收、市場支持相關的工作了，瞭解後續工作，且聽下回分解吧。
#相關閲讀#市場分析階段：To B軟件產品設計流程總結
產品設計階段：To B軟件產品設計流程總結
本文由 @Jimmy.jing 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議