中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

上一篇?我們圍繞「產品的第一個版本」展開分析，接下來，我們繼續來看下設計確認的過程。

設計確認

首先我們來看下「設計確認」的含義。

「設計確認」包括原型確認和 UI 確認兩大步，這是研發和測試可以開始工作的前提。也就是說，原型和 UI 確認了，研發團隊才能干活。

那產品經理和 UI 確認圖的時候，研發在干什么呢？劃水嗎？

一般來說，「設計確認」提前一兩個開發周期完成，以確保研發工作不會出現斷檔。也就是說，研發在做上一個開發周期的功能時，產品經理和 UI 就要開始下一個周期的「設計確認」。

曾經年少的我認為研發出現斷檔，讓大家在一段忙碌期后休息休息也是好事。直到有一天 Leader 和我核算了一下我們部門的成本，研發斷檔一天的成本是 5k+ （10 個人平均一人一天 500 塊），我才開始認真對待這件事情。關注成本可以說是產品經理的必備技能之一，而這也讓我對一些事情的看法和之前相比有了明顯的不同。

原型確認

「原型確認」就是需要確認原型啦。嗯，這是一句正確的廢話。不過，需要說明的是，這里的「原型確認」是產品經理確認的、并經過評審的下一個開發周期的原型。

為什么需要評審？一方面避免產品經理自嗨，另一方面多方評審可以保證整個團隊在做最重要的事情。誰來參加評審呢？這個每個公司的要求不一樣，一般會有技術、產品、UI 等多方角色參與。

1. 功能打包

對于我們的產品「簡報生成器」來說，由于簡報的信息源因為實現而導致無法讓用戶自定義，導致產品的核心和我們之前所理解的有所不同。所以，我們在做下一期的功能列表的時候，需要重新評估，也就是所謂的「功能打包」。

每個開發周期都是需要重新評估功能列表，重新審視之前的「產品規劃」，以保證下一個開發周期做最正確的事情。因為在產品開發過程中，我們總會遇到一些問題，從而導致周期調整或者功能調整，甚至在上線后也很難保證所有已知的 Bug 都被解決。而這些遺留問題都需要記錄在案，進入功能列表中，以待下個開發周期被選擇或被解決。

由于簡報信息源的問題，導致「簡報生成器」的功能更偏向于簡報的信息展示，信息源的添加需要產品經理提需求，程序去實現，才能保證對應信息可以展示。

因此，「簡報生成器」下一個階段最重要的兩個功能點是：信息源的添加和信息的展示。而不是我們之前規劃的「簡報設置」，甚至說「簡報設置」這一大類都不復存在了。

這么看起來，「簡報生成器」這個產品名字似乎不太合適呢，更準確地叫法應該是「簡報」。相應地，產品的定位也會相應隨之改變，一個提供簡報信息集合的產品。按理說，產品的定位修改后，要重新進行競品分析什么的，這里我們就暫且略過，可能和之前的文章分析內容不太一樣，但是分析的思路和方法是一致的。感興趣的朋友可以翻看之前的文章。

接下來，我們繼續分析：信息源的添加和信息的展示這兩部分。

（1）信息源的添加

首先，信息源的添加是不需要畫原型圖的，只需要產品經理提供信息獲取的規則。那對于「簡報」來說，首先需要提供如下幾類信息：

1. 互聯網產品
2. 開發者資訊
3. 創投 | 融資 | IPO
4. 熱門問答

我們以「互聯網產品」為例，給出具體的信息提取規則。從信息源上來講，「互聯網產品」包括以下幾個類型：小程序、產品文章、iOS 應用、Android 應用、Mac OS 應用、Windows 應用。小程序從「知曉程序」獲取，需要獲取每日最新的小程序名稱及說明。如果你是這么寫規則的，那么你一定會被挑戰。

開發同學：「知曉程序」是個網站吧？我需要全網爬嗎？這個工作量有點大哦…

產品經理 ：當然不是啦，只需要爬取首頁的「最新」，誰讓你全網爬了。

開發同學：那你不說清楚。另外，我怎么知道什么是「每日最新」？

產品經理：點小程序進去，不是有個「發布時間」嗎？它等于「昨天」就是最新的。

開發同學：還要點進去，好吧好吧……那什么是「小程序說明」？

產品經理：就是點進去那個「產品介紹」啊……

開發同學：?

額，這下終于明白要把事情說清楚是有多么重要了吧。整理一下，小程序類信息的獲取規則如下所示：

• URL：https://minapp.com/
• 爬取的內容：首頁里的 Tab 為「最新」的內容，需要爬取對應的小程序名稱、小程序說明、小程序的發布時間、小程序的 URL。其中完整的小程序說明和發布時間可通過點擊對應的小程序進入詳情頁查看。
• 爬取的時間：至少能查到昨天和今天的數據即可。

其實，就算你這么寫了，可能還是會被挑戰，比如他們會問我一次爬多久的數據啊、爬取的數據怎么存儲啊、對爬取的數據格式有沒有什么要求啊……問題是列不完的，只能遇到一個解決一個嘍。

剩下的幾類可按照與「小程序」同類的需求描述即可。一般我會把需求寫在 Axure 的頁面里（一般是新建一個頁面，將其命名為「需求規則描述」），一方面團隊成員不用頻繁切換軟件查看，二來規則和原型也在一起也方便自己查看。

（2）信息展示

接下來，我們來看「信息展示」這部分。這部分肯定不能只描述需求規則啦，原型圖肯定是要畫的。

那一般用什么軟件來畫呢？常見的軟件為 Axure。產品新人大多會花很多時間學習軟件的使用，很關注怎么用 Axure 畫出漂亮的界面什么的，卻常常忘記了最重要的一點，工具是用來表達想法的，能熟練使用 Axure 是產品經理的必備技能，但不代表熟練使用 Axure 就能成為產品經理，大家千萬不要本末倒置。

要畫好「信息展示」的原型，需要了解有哪些信息（和第一步「信息源的添加」息息相關，也可以反過來幫助我們檢驗第一步規則是否存在缺失），其次是需要展示哪些信息，最后才是怎么展示。這里也可以發現怎么展示也就是 Axure 畫原型是最不重要的一步，之前的思考分析過程才是最重要的。所以很多人認為產品經理就是「畫原型」的，那我只能說「你怕是對產品經理有什么誤解」。

經過一系列的分析，我把原型圖畫出來了，如下圖所示。當然這里的圖只是其中一個界面，你可不能只給研發同學一個界面就當作原型圖啊。篩選什么的效果怎么著都得畫出來。

2. UI 溝通

如果你想要和某一個人高效溝通，那你一定要了解對方關注的點在哪里。

那么 UI 關注的點在哪里呢？

對原型圖的顏色、字體、間距、排版、布局等信息 UI 一概不關注，因為產品經理給出的這些信息，經 UI 之手后可能「面目全非」，會更加精致、美觀。

那 UI 到底關注什么？

1. 信息的關聯性。哪些信息是有關系的，這樣他們設計的時候會考慮將其「放在一起」。
2. 信息的重要程度。哪些信息是需要用戶特別注意的或者說用戶最關注哪些信息，這將意味著他們會出現在界面的哪個位置。
3. 信息的長度或邊界值。哪些信息可能會比較長，這會對頁面的布局以及元素的長度有影響。
4. 特殊狀態。必填項未填寫時的報錯提示、完成提示等。當然，這里 UI 只負責給出具體的樣式，文案還是需要產品經理提供的。

很多時候，UI 可能并不關注產品的業務邏輯，但是一個優秀的產品經理還是會為 UI 解釋產品的業務邏輯，一來了解產品知識會促使 UI 設計出更合理的界面；二來 UI 也可以幫助產品經理出謀劃策，也就是俗話說的「眾人拾柴火焰高」，產品設計遇到難點的時候，也多個人可以討論。

和 UI 溝通清楚之后，就是 UI 自由發揮的時間了。對了，還有一個很重要的點，就是要和 UI 溝通設計完成的 deadline，并及時跟蹤設計進度。請記住，沒有 deadline，基本等于沒有溝通。因為大多數人的心理就是這樣，你不說什么時候要，那就代表你的事情不著急，我可以無限拖。

（1）PRD（Product requirements document） 文檔

當產品經理和 UI 溝通完之后，產品經理就可以著手編寫 PRD 了。當然，如果產品經理時間足夠，PRD 完成之后再轉交 UI 也是再好不過的事情了。因為溝通之后一些細節，UI 想要回顧的話，看 PRD 是再好不過的事情了。

關于 PRD，我想到之前文章后「小寶」的留言：「如何產出一份高質量的 PRD？」

當時我的回復是這樣的：

• 首先，需要明確 PRD 是給誰看的？為什么要寫 PRD？
• 最后，針對看 PRD 的人，只要他們能理解你要表達的意思，就是一份高質量的 PRD。
• 至于格式、形式都不是很重要，達到溝通的目的最重要，不要為了寫一份高質量的 PRD 而去寫 PRD 就好。

平時工作中，我會在原型圖的旁邊標注關鍵的點，以最終形成用于團隊成員溝通的 PRD。我基本很少寫十分詳細的 PRD 的文檔，一來長度太長，只有測試會仔細看，開發大多都不愿意看；二來即使寫了很詳盡的 PRD，團隊之間的溝通過程也是無法避免的。所以，根據當前團隊成員的習慣，我選擇了在原型圖旁邊標注的方式寫 PRD。

網上有很多大佬會寫很漂亮的 PRD 文檔，我不清楚他們平時工作中是否也是這么寫的，也不清楚與之合作的團隊成員是否真的有耐心讀完這樣的 PRD。我只是覺得，PRD 并不能完全替代溝通的過程。不過，詳盡的 PRD 還是有好處的，用于歸責。如果產品經理的 PRD 寫了，研發最終沒實現，那就可以甩鍋了。但這種情況可以通過項目管理的方式解決。

（2）UI 評審

UI 完成 UI 圖后，產品經理一定要參與評審（驗收），以確保 UI 圖完備、準確?！竿陚洹故侵?UI 提供了所有該提供的界面，包括各種特殊狀態；「準確」是指 UI 圖可以準確表達產品設計的理念和想法。

很多時候，404 界面（以及 403、500 界面）、空頁面、搜不出結果的頁面等 UI 可能會有遺漏，導致不夠「完備」。也有的時候，UI 在設計界面時會偏離產品設計的意圖或者按照自己的想法莫名添加一些需求出來，產品經理一定要及時糾正。

比如我們在設計一個數據展示界面的時候，UI 加了一個全屏的界面，實現上他跟研發咨詢過了，可以直接調瀏覽器的全屏接口，然后他就很驕傲的和我講他的設計。

UI 小哥哥 ：我們系統里的數據不是太多了嗎，我設計了一個全屏的功能可以全屏顯示數據，可以隱藏導航欄和側邊欄，就可以多展示幾列數據。

產品經理 ：多展示幾列有必要嗎？

UI 小哥哥：有啊，本來放不下的數據全屏的情況下都可以展示出來了，橫向滾動條也省了。

產品經理 ：那你知道用戶用的都是多大的屏幕嗎？

UI 小哥哥 ：不管他們用多大的屏幕，我都可以支持啊。是不是很厲害。

產品經理 ：據我所知，使用這個系統的用戶都是 1920 的屏幕，完全不存在你說的數據展示不完的問題，這樣的話，這個功能似乎沒什么必要呢？

UI 小哥哥：那當我沒說，圖已經刪了……

其實還是要看具體的應用場景，在當前場景下的「全屏」功能，展開后其實也沒多幾行數據，不太影響用戶查看數據。但是如果是在網頁看博客之類的，可以全屏顯示博客內容，不看周圍的廣告，就是一個很好的設計。就是不知道，公司的廣告收入會不會因此而減少。

（3）設計確認階段的產出

設計確認階段會有兩大比較重要的產出：PRD 和 UI 圖。

• PRD 可以和原型一起提供，這樣方便團隊成員查看。
• UI 圖可以上傳到「藍湖」（常見的設計軟件：Sketch、PS、XD 等軟件藍湖都是支持的），方便團隊成員在線查看，以減少 UI 和研發設計圖不統一的情況出現，提高雙方溝通的效率。

總結

1. 產品規劃和功能打包之間的關系是什么？

或許你會說，「產品規劃」不是已經把每個迭代需要做的功能列表確認了嗎？為什么這里又冒出來一個「功能打包」，不是多此一舉嗎？

并不是多此一舉啦。首先，我們做的每個決定都是基于現有的認知信息之上的，當我們做「產品規劃」時也是如此，我們盡可能做出最優的決策。但是隨著產品的不斷迭代、用戶的不斷增加，可能導致之前的「產品規劃」不再適應當前的產品版本。

換句話說，之前覺得很重要的功能，現在變得無關緊要；之前覺得可有可無的功能，現在成了必不可少的功能。這就要求產品經理在每個版本開始的時候，重新審視「產品規劃」，合理地做「功能打包」，給出當前版本最適合開發的功能列表。

可以這么理解，「產品規劃」是產品的長期規劃，需要好幾個產品版本逐漸去迭代實現，而「功能打包」是包含在「產品規劃」內的，是當前產品版本需要實現的功能。

當然或許你會疑惑，為什么產品經理在做「產品規劃」時不能考慮得長遠些呢，讓「產品規劃」更加不容易「變」呢？

只能說這個要求很難做到，需要你有足夠的「眼界」，預測未來可能會出現什么情況；以及過去做產品的「經驗」，能夠判斷這里可能會有什么坑；以及一點點的「運氣」。

2. 功能列表 VS 產品規劃 VS 功能打包

之前的文章評論里有人問過這個問題，這里我們來簡單說明下這三者的區別。

場景：假設你剛收到消息，你的閨蜜一會要來你們家吃飯。

產品經理：家庭主廚。

用戶：你的閨蜜。

需求：直接需求是「吃飯」，滿足生理需求。間接需求可能是「來談心（吐槽）」，附加需求可能是「晚上睡這里」。

功能列表：好比冰箱里的食材，有菜、肉、蝦等，對應一個個小的需求。

產品規劃：好比利用這些食材，可以做是素菜、大葷、小葷、爆炒蝦等。產品規劃類似一個菜單，規定了每個菜需要哪些食材，對應需求組的集合。

功能打包：好比關于這一頓飯，因為閨蜜對蝦過敏，蝦肯定不做了。只能素菜、大葷、小葷了，對應當前版本的需求集合。

3. 需求池管理

既然每個版本都需要重新做「功能打包」，那是不是會有一個功能列表，以方便我每次從中「挑選」出最合適的功能列表。嗯，這個東西就是業內所說的「需求池」。不過「需求池」里不只有「功能列表」，還有上期遺留的 Bug 及用戶反饋等信息。

也就是說，「需求池」和「功能列表」是包含關系，或者你也可以將需求池理解為「動態變化的功能列表」，這個池子里可以增加新的功能列表，也可以剔除一些功能列表。

一般情況下，我們所說的「功能列表」是第一版時提出的需求的集合，到后期產品迭代、需求發生改變之后，功能列表也就變成了現在的「需求池」。

一般我會和研發團隊使用同樣的軟件來管理需求池。比如：我們現在在用 Jira，我就會用 Jira 充當需求池管理軟件，把收到的需求記錄在內，并標注優先級、編寫需求描述，以方便團隊溝通。和研發團隊使用同樣的軟件的好處是不用擔心信息不同步，因為記錄在別的地方研發不一定會關注，同時產品經理也不會忘記更新。

4. 需求不需要評審嗎？

看公司要求以及產品經理所負責的產品的難易程度，比如我在工作中遇到的 2B 產品，都是拿著 UI 圖去和用戶評審，而不是需求評審。當然，在 UI 評審之前，產品經理已經就「產品規劃」和用戶達成一致。

如果需求需要評審，設計確認的步驟就會調整為如下圖所示。也就是說，UI 溝通會在需求評審之后進行。

下一篇我們將重點關注「研發測試」過程，敬請期待。

好的，今天這篇文章到這里就結束了，我們的《一個項目帶你走進產品經理的世界》系列文章完成進度如下：黃色為當前進度～

相關閱讀

一個項目帶你走進產品經理的世界（1）：從收到一個需求談起

一個項目帶你走進產品經理的世界（2）：需求分析

一個項目帶你走進產品經理的世界（3）：從用戶需求到產品功能

一個項目帶你走進產品經理的世界（4）：產品規劃

一個項目帶你走進產品經理的世界（5）第一個版本：MVP ？MDP ？

#專欄作家#

佐珥，微信公眾號：產品碎月（ID：pm_lab），人人都是產品經理專欄作家，專注互聯網產品，樂于通過幽默詼諧、圖文并茂、結合實際的文字分享自己的產品經驗，期望同大家一起快樂成長

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議