上一篇 我們圍繞「產(chǎn)品的第一個版本」展開分析，接下來，我們繼續(xù)來看下設計確認的過程。
首先我們來看下「設計確認」的含義。
「設計確認」包括原型確認和 UI 確認兩大步，這是研發(fā)和測試可以開始工作的前提。也就是說，原型和 UI 確認了，研發(fā)團隊才能干活。
那產(chǎn)品經(jīng)理和 UI 確認圖的時候，研發(fā)在干什么呢？劃水嗎？
一般來說，「設計確認」提前一兩個開發(fā)周期完成，以確保研發(fā)工作不會出現(xiàn)斷檔。也就是說，研發(fā)在做上一個開發(fā)周期的功能時，產(chǎn)品經(jīng)理和 UI 就要開始下一個周期的「設計確認」。
曾經(jīng)年少的我認為研發(fā)出現(xiàn)斷檔，讓大家在一段忙碌期后休息休息也是好事。直到有一天 Leader 和我核算了一下我們部門的成本，研發(fā)斷檔一天的成本是 5k （10 個人平均一人一天 500 塊），我才開始認真對待這件事情。關注成本可以說是產(chǎn)品經(jīng)理的必備技能之一，而這也讓我對一些事情的看法和之前相比有了明顯的不同。
「原型確認」就是需要確認原型啦。嗯，這是一句正確的廢話。不過，需要說明的是，這里的「原型確認」是產(chǎn)品經(jīng)理確認的、并經(jīng)過評審的下一個開發(fā)周期的原型。
為什么需要評審？一方面避免產(chǎn)品經(jīng)理自嗨，另一方面多方評審可以保證整個團隊在做最重要的事情。誰來參加評審呢？這個每個公司的要求不一樣，一般會有技術、產(chǎn)品、UI 等多方角色參與。
對于我們的產(chǎn)品「簡報生成器」來說，由于簡報的信息源因為實現(xiàn)而導致無法讓用戶自定義，導致產(chǎn)品的核心和我們之前所理解的有所不同。所以，我們在做下一期的功能列表的時候，需要重新評估，也就是所謂的「功能打包」。
每個開發(fā)周期都是需要重新評估功能列表，重新審視之前的「產(chǎn)品規(guī)劃」，以保證下一個開發(fā)周期做最正確的事情。因為在產(chǎn)品開發(fā)過程中，我們總會遇到一些問題，從而導致周期調整或者功能調整，甚至在上線后也很難保證所有已知的 Bug 都被解決。而這些遺留問題都需要記錄在案，進入功能列表中，以待下個開發(fā)周期被選擇或被解決。
由于簡報信息源的問題，導致「簡報生成器」的功能更偏向于簡報的信息展示，信息源的添加需要產(chǎn)品經(jīng)理提需求，程序去實現(xiàn)，才能保證對應信息可以展示。
因此，「簡報生成器」下一個階段最重要的兩個功能點是：信息源的添加和信息的展示。而不是我們之前規(guī)劃的「簡報設置」，甚至說「簡報設置」這一大類都不復存在了。
這么看起來，「簡報生成器」這個產(chǎn)品名字似乎不太合適呢，更準確地叫法應該是「簡報」。相應地，產(chǎn)品的定位也會相應隨之改變，一個提供簡報信息集合的產(chǎn)品。按理說，產(chǎn)品的定位修改后，要重新進行競品分析什么的，這里我們就暫且略過，可能和之前的文章分析內容不太一樣，但是分析的思路和方法是一致的。感興趣的朋友可以翻看之前的文章。
接下來，我們繼續(xù)分析：信息源的添加和信息的展示這兩部分。
（1）信息源的添加
首先，信息源的添加是不需要畫原型圖的，只需要產(chǎn)品經(jīng)理提供信息獲取的規(guī)則。那對于「簡報」來說，首先需要提供如下幾類信息：
互聯(lián)網(wǎng)產(chǎn)品
開發(fā)者資訊
創(chuàng)投 | 融資 | IPO
熱門問答
我們以「互聯(lián)網(wǎng)產(chǎn)品」為例，給出具體的信息提取規(guī)則。從信息源上來講，「互聯(lián)網(wǎng)產(chǎn)品」包括以下幾個類型：小程序、產(chǎn)品文章、iOS 應用、Android 應用、Mac OS 應用、Windows 應用。小程序從「知曉程序」獲取，需要獲取每日最新的小程序名稱及說明。如果你是這么寫規(guī)則的，那么你一定會被挑戰(zhàn)。
開發(fā)同學：「知曉程序」是個網(wǎng)站吧？我需要全網(wǎng)爬嗎？這個工作量有點大哦…
產(chǎn)品經(jīng)理 ：當然不是啦，只需要爬取首頁的「最新」，誰讓你全網(wǎng)爬了。
開發(fā)同學：那你不說清楚。另外，我怎么知道什么是「每日最新」？
產(chǎn)品經(jīng)理：點小程序進去，不是有個「發(fā)布時間」嗎？它等于「昨天」就是最新的。
開發(fā)同學：還要點進去，好吧好吧……那什么是「小程序說明」？
產(chǎn)品經(jīng)理：就是點進去那個「產(chǎn)品介紹」啊……
開發(fā)同學：??
額，這下終于明白要把事情說清楚是有多么重要了吧。整理一下，小程序類信息的獲取規(guī)則如下所示：
URL：https://minapp.com/
爬取的內容：首頁里的 Tab 為「最新」的內容，需要爬取對應的小程序名稱、小程序說明、小程序的發(fā)布時間、小程序的 URL。其中完整的小程序說明和發(fā)布時間可通過點擊對應的小程序進入詳情頁查看。
爬取的時間：至少能查到昨天和今天的數(shù)據(jù)即可。
其實，就算你這么寫了，可能還是會被挑戰(zhàn)，比如他們會問我一次爬多久的數(shù)據(jù)啊、爬取的數(shù)據(jù)怎么存儲啊、對爬取的數(shù)據(jù)格式有沒有什么要求啊……問題是列不完的，只能遇到一個解決一個嘍。
剩下的幾類可按照與「小程序」同類的需求描述即可。一般我會把需求寫在 Axure 的頁面里（一般是新建一個頁面，將其命名為「需求規(guī)則描述」），一方面團隊成員不用頻繁切換軟件查看，二來規(guī)則和原型也在一起也方便自己查看。
（2）信息展示
接下來，我們來看「信息展示」這部分。這部分肯定不能只描述需求規(guī)則啦，原型圖肯定是要畫的。
那一般用什么軟件來畫呢？常見的軟件為 Axure。產(chǎn)品新人大多會花很多時間學習軟件的使用，很關注怎么用 Axure 畫出漂亮的界面什么的，卻常常忘記了最重要的一點，工具是用來表達想法的，能熟練使用 Axure 是產(chǎn)品經(jīng)理的必備技能，但不代表熟練使用 Axure 就能成為產(chǎn)品經(jīng)理，大家千萬不要本末倒置。
要畫好「信息展示」的原型，需要了解有哪些信息（和第一步「信息源的添加」息息相關，也可以反過來幫助我們檢驗第一步規(guī)則是否存在缺失），其次是需要展示哪些信息，最后才是怎么展示。這里也可以發(fā)現(xiàn)怎么展示也就是 Axure 畫原型是最不重要的一步，之前的思考分析過程才是最重要的。所以很多人認為產(chǎn)品經(jīng)理就是「畫原型」的，那我只能說「你怕是對產(chǎn)品經(jīng)理有什么誤解」。
經(jīng)過一系列的分析，我把原型圖畫出來了，如下圖所示。當然這里的圖只是其中一個界面，你可不能只給研發(fā)同學一個界面就當作原型圖啊。篩選什么的效果怎么著都得畫出來。
如果你想要和某一個人高效溝通，那你一定要了解對方關注的點在哪里。
那么 UI 關注的點在哪里呢？
對原型圖的顏色、字體、間距、排版、布局等信息 UI 一概不關注，因為產(chǎn)品經(jīng)理給出的這些信息，經(jīng) UI 之手后可能「面目全非」，會更加精致、美觀。
那 UI 到底關注什么？
信息的關聯(lián)性。哪些信息是有關系的，這樣他們設計的時候會考慮將其「放在一起」。
信息的重要程度。哪些信息是需要用戶特別注意的或者說用戶最關注哪些信息，這將意味著他們會出現(xiàn)在界面的哪個位置。
信息的長度或邊界值。哪些信息可能會比較長，這會對頁面的布局以及元素的長度有影響。
特殊狀態(tài)。必填項未填寫時的報錯提示、完成提示等。當然，這里 UI 只負責給出具體的樣式，文案還是需要產(chǎn)品經(jīng)理提供的。
很多時候，UI 可能并不關注產(chǎn)品的業(yè)務邏輯，但是一個優(yōu)秀的產(chǎn)品經(jīng)理還是會為 UI 解釋產(chǎn)品的業(yè)務邏輯，一來了解產(chǎn)品知識會促使 UI 設計出更合理的界面；二來 UI 也可以幫助產(chǎn)品經(jīng)理出謀劃策，也就是俗話說的「眾人拾柴火焰高」，產(chǎn)品設計遇到難點的時候，也多個人可以討論。
和 UI 溝通清楚之后，就是 UI 自由發(fā)揮的時間了。對了，還有一個很重要的點，就是要和 UI 溝通設計完成的 deadline，并及時跟蹤設計進度。請記住，沒有 deadline，基本等于沒有溝通。因為大多數(shù)人的心理就是這樣，你不說什么時候要，那就代表你的事情不著急，我可以無限拖。
（1）PRD（Product requirements document） 文檔
當產(chǎn)品經(jīng)理和 UI 溝通完之后，產(chǎn)品經(jīng)理就可以著手編寫 PRD 了。當然，如果產(chǎn)品經(jīng)理時間足夠，PRD 完成之后再轉交 UI 也是再好不過的事情了。因為溝通之后一些細節(jié)，UI 想要回顧的話，看 PRD 是再好不過的事情了。
關于 PRD，我想到之前文章后「小寶」的留言：「如何產(chǎn)出一份高質量的 PRD？」
當時我的回復是這樣的：
首先，需要明確 PRD 是給誰看的？為什么要寫 PRD？
最后，針對看 PRD 的人，只要他們能理解你要表達的意思，就是一份高質量的 PRD。
至于格式、形式都不是很重要，達到溝通的目的最重要，不要為了寫一份高質量的 PRD 而去寫 PRD 就好。
平時工作中，我會在原型圖的旁邊標注關鍵的點，以最終形成用于團隊成員溝通的 PRD。我基本很少寫十分詳細的 PRD 的文檔，一來長度太長，只有測試會仔細看，開發(fā)大多都不愿意看；二來即使寫了很詳盡的 PRD，團隊之間的溝通過程也是無法避免的。所以，根據(jù)當前團隊成員的習慣，我選擇了在原型圖旁邊標注的方式寫 PRD。
網(wǎng)上有很多大佬會寫很漂亮的 PRD 文檔，我不清楚他們平時工作中是否也是這么寫的，也不清楚與之合作的團隊成員是否真的有耐心讀完這樣的 PRD。我只是覺得，PRD 并不能完全替代溝通的過程。不過，詳盡的 PRD 還是有好處的，用于歸責。如果產(chǎn)品經(jīng)理的 PRD 寫了，研發(fā)最終沒實現(xiàn)，那就可以甩鍋了。但這種情況可以通過項目管理的方式解決。
（2）UI 評審
UI 完成 UI 圖后，產(chǎn)品經(jīng)理一定要參與評審（驗收），以確保 UI 圖完備、準確?！竿陚洹故侵?UI 提供了所有該提供的界面，包括各種特殊狀態(tài)；「準確」是指 UI 圖可以準確表達產(chǎn)品設計的理念和想法。
很多時候，404 界面（以及 403、500 界面）、空頁面、搜不出結果的頁面等 UI 可能會有遺漏，導致不夠「完備」。也有的時候，UI 在設計界面時會偏離產(chǎn)品設計的意圖或者按照自己的想法莫名添加一些需求出來，產(chǎn)品經(jīng)理一定要及時糾正。
比如我們在設計一個數(shù)據(jù)展示界面的時候，UI 加了一個全屏的界面，實現(xiàn)上他跟研發(fā)咨詢過了，可以直接調瀏覽器的全屏接口，然后他就很驕傲的和我講他的設計。
UI 小哥哥 ：我們系統(tǒng)里的數(shù)據(jù)不是太多了嗎，我設計了一個全屏的功能可以全屏顯示數(shù)據(jù)，可以隱藏導航欄和側邊欄，就可以多展示幾列數(shù)據(jù)。
產(chǎn)品經(jīng)理 ：多展示幾列有必要嗎？
UI 小哥哥：有啊，本來放不下的數(shù)據(jù)全屏的情況下都可以展示出來了，橫向滾動條也省了。
產(chǎn)品經(jīng)理 ：那你知道用戶用的都是多大的屏幕嗎？
UI 小哥哥 ：不管他們用多大的屏幕，我都可以支持啊。是不是很厲害。
產(chǎn)品經(jīng)理 ：據(jù)我所知，使用這個系統(tǒng)的用戶都是 1920 的屏幕，完全不存在你說的數(shù)據(jù)展示不完的問題，這樣的話，這個功能似乎沒什么必要呢？
UI 小哥哥：那當我沒說，圖已經(jīng)刪了……
其實還是要看具體的應用場景，在當前場景下的「全屏」功能，展開后其實也沒多幾行數(shù)據(jù)，不太影響用戶查看數(shù)據(jù)。但是如果是在網(wǎng)頁看博客之類的，可以全屏顯示博客內容，不看周圍的廣告，就是一個很好的設計。就是不知道，公司的廣告收入會不會因此而減少。
（3）設計確認階段的產(chǎn)出
設計確認階段會有兩大比較重要的產(chǎn)出：PRD 和 UI 圖。
PRD 可以和原型一起提供，這樣方便團隊成員查看。
UI 圖可以上傳到「藍湖」（常見的設計軟件：Sketch、PS、XD 等軟件藍湖都是支持的），方便團隊成員在線查看，以減少 UI 和研發(fā)設計圖不統(tǒng)一的情況出現(xiàn)，提高雙方溝通的效率。
或許你會說，「產(chǎn)品規(guī)劃」不是已經(jīng)把每個迭代需要做的功能列表確認了嗎？為什么這里又冒出來一個「功能打包」，不是多此一舉嗎？
并不是多此一舉啦。首先，我們做的每個決定都是基于現(xiàn)有的認知信息之上的，當我們做「產(chǎn)品規(guī)劃」時也是如此，我們盡可能做出最優(yōu)的決策。但是隨著產(chǎn)品的不斷迭代、用戶的不斷增加，可能導致之前的「產(chǎn)品規(guī)劃」不再適應當前的產(chǎn)品版本。
換句話說，之前覺得很重要的功能，現(xiàn)在變得無關緊要；之前覺得可有可無的功能，現(xiàn)在成了必不可少的功能。這就要求產(chǎn)品經(jīng)理在每個版本開始的時候，重新審視「產(chǎn)品規(guī)劃」，合理地做「功能打包」，給出當前版本最適合開發(fā)的功能列表。
可以這么理解，「產(chǎn)品規(guī)劃」是產(chǎn)品的長期規(guī)劃，需要好幾個產(chǎn)品版本逐漸去迭代實現(xiàn)，而「功能打包」是包含在「產(chǎn)品規(guī)劃」內的，是當前產(chǎn)品版本需要實現(xiàn)的功能。
當然或許你會疑惑，為什么產(chǎn)品經(jīng)理在做「產(chǎn)品規(guī)劃」時不能考慮得長遠些呢，讓「產(chǎn)品規(guī)劃」更加不容易「變」呢？
只能說這個要求很難做到，需要你有足夠的「眼界」，預測未來可能會出現(xiàn)什么情況；以及過去做產(chǎn)品的「經(jīng)驗」，能夠判斷這里可能會有什么坑；以及一點點的「運氣」。
之前的文章評論里有人問過這個問題，這里我們來簡單說明下這三者的區(qū)別。
場景：假設你剛收到消息，你的閨蜜一會要來你們家吃飯。
產(chǎn)品經(jīng)理：家庭主廚。
用戶：你的閨蜜。
需求：直接需求是「吃飯」，滿足生理需求。間接需求可能是「來談心（吐槽）」，附加需求可能是「晚上睡這里」。
功能列表：好比冰箱里的食材，有菜、肉、蝦等，對應一個個小的需求。
產(chǎn)品規(guī)劃：好比利用這些食材，可以做是素菜、大葷、小葷、爆炒蝦等。產(chǎn)品規(guī)劃類似一個菜單，規(guī)定了每個菜需要哪些食材，對應需求組的集合。
功能打包：好比關于這一頓飯，因為閨蜜對蝦過敏，蝦肯定不做了。只能素菜、大葷、小葷了，對應當前版本的需求集合。
既然每個版本都需要重新做「功能打包」，那是不是會有一個功能列表，以方便我每次從中「挑選」出最合適的功能列表。嗯，這個東西就是業(yè)內所說的「需求池」。不過「需求池」里不只有「功能列表」，還有上期遺留的 Bug 及用戶反饋等信息。
也就是說，「需求池」和「功能列表」是包含關系，或者你也可以將需求池理解為「動態(tài)變化的功能列表」，這個池子里可以增加新的功能列表，也可以剔除一些功能列表。
一般情況下，我們所說的「功能列表」是第一版時提出的需求的集合，到后期產(chǎn)品迭代、需求發(fā)生改變之后，功能列表也就變成了現(xiàn)在的「需求池」。
一般我會和研發(fā)團隊使用同樣的軟件來管理需求池。比如：我們現(xiàn)在在用 Jira，我就會用 Jira 充當需求池管理軟件，把收到的需求記錄在內，并標注優(yōu)先級、編寫需求描述，以方便團隊溝通。和研發(fā)團隊使用同樣的軟件的好處是不用擔心信息不同步，因為記錄在別的地方研發(fā)不一定會關注，同時產(chǎn)品經(jīng)理也不會忘記更新。
看公司要求以及產(chǎn)品經(jīng)理所負責的產(chǎn)品的難易程度，比如我在工作中遇到的 2B 產(chǎn)品，都是拿著 UI 圖去和用戶評審，而不是需求評審。當然，在 UI 評審之前，產(chǎn)品經(jīng)理已經(jīng)就「產(chǎn)品規(guī)劃」和用戶達成一致。
如果需求需要評審，設計確認的步驟就會調整為如下圖所示。也就是說，UI 溝通會在需求評審之后進行。
下一篇我們將重點關注「研發(fā)測試」過程，敬請期待。
好的，今天這篇文章到這里就結束了，我們的《一個項目帶你走進產(chǎn)品經(jīng)理的世界》系列文章完成進度如下：黃色為當前進度～
聯(lián)系客服
