本文內容包括：產(chǎn)品部以及產(chǎn)品設計崗位的工作范圍與輸出內容、產(chǎn)品團隊的組織結構與崗位職責、產(chǎn)品需求管理的流程、產(chǎn)品工作經(jīng)驗分享等。

產(chǎn)品設計&團隊協(xié)作說明

一、修訂記錄

二、目錄

一、修訂記錄

二、目錄

三、工作范圍與輸出

3.1產(chǎn)品部日常工作

3.2產(chǎn)品設計工作

四、產(chǎn)品團隊

4.1組織結構

4.2崗位職責與工作關系

五、產(chǎn)品需求管理

六、產(chǎn)品工作經(jīng)驗分享

三、工作范圍與輸出

3.1 產(chǎn)品部日常工作

產(chǎn)品設計：

相關輸出：需求規(guī)格說明書、產(chǎn)品交互原型設計文檔（.RP/HTML）、UI圖形原文件

產(chǎn)品開發(fā)階段的溝通：

相關輸出：日報/周報

產(chǎn)品設計相關的市場分析與用戶調查工作：

調查計劃、調查報告

相關評審工作：

相關輸出：需求文檔修訂/評審記錄

3.2 產(chǎn)品設計工作

工作目標：根據(jù)公司產(chǎn)品戰(zhàn)略階段規(guī)劃和可行性研究，明確該階段“產(chǎn)品必須做什么”，對目標系統(tǒng)提出完整、準確、清晰、具體的功能要求。

工作內容包括：需求規(guī)格說明文檔設計、產(chǎn)品交互原型文檔設計、UI設計。

相關輸出：需求規(guī)格說明書、產(chǎn)品交互原型設計文檔（.RP/HTML）、UI圖形原文件。

3.2.1 需求規(guī)格說明

定義：

1. 需求規(guī)格說明書必須清楚的描述軟件的每一個基本需求（功能、設計約束和屬性）和外部界面。
2. 必須把每個需求規(guī)定成能夠通過預先定義的方法（例如分析、演示、檢查、測試等）被客觀地驗證與確認形式。

標準：

在軟件需求分析階段結束后必須由項目組進行軟件需求評審，以確保在軟件需求規(guī)格說明書中規(guī)定的各項需求的合適性。

評審過程一般包括以下五個方面的驗證：

1. 完整性：需求必須是完整的，需求規(guī)格書應該包括產(chǎn)品規(guī)劃書所定義的產(chǎn)品戰(zhàn)略階段需要的每一個功能需求及性能性約定。
2. 一致性：所有需求是一致的，任何一條需求不能與其他需求相互矛盾。
3. 現(xiàn)實性：保證需求設計是用現(xiàn)有的軟硬件技術基本上可以實現(xiàn)的，基本適應公司的開發(fā)技術資源水平的。
4. 有效性：需求正確有效，確實吻合產(chǎn)品戰(zhàn)略方向、市場方向所需，避免做超出市場需求規(guī)劃范圍的無用設計。
5. 可用性：需求說明書必須用清晰易懂的描述語言，邏輯清晰，準確描述每一個需求的細節(jié)。以保障在無人職守的情況下能被產(chǎn)品開發(fā)團隊中的閱讀對象正確理解。

3.2.2 UI設計

輸出：UI設計輸出為符合下述評審要求PNG/JPG/PSD圖形文件，并合理組織輸出相關“Banner”、“層”、“按鈕”等界面元素。

UI設計評審標準：

1. 主題定位：主題表現(xiàn)鮮明，展現(xiàn)產(chǎn)品階段性定位特點，具有適當個性的設計風格，表現(xiàn)手法新穎；
2. 功能容納：所容納功能符合產(chǎn)品需求設計；
3. 布局要求：符合用戶體驗規(guī)則，方便瀏覽和操作；整體布局均衡合理，輕重層次合理，符合產(chǎn)品定位要求；風格一致；
4. 色彩要求：整體色彩要符合產(chǎn)品定位（包括用戶定位與行業(yè)領域），協(xié)調和諧，符合美感；
5. 可修改性：方便進行更新，修改；

四、產(chǎn)品團隊

4.1 組織結構

從產(chǎn)品部門的角度出發(fā)，來理解目前中小互聯(lián)網(wǎng)企業(yè)中的幾大主要任務和相應的職責區(qū)別，涉及產(chǎn)品經(jīng)理、產(chǎn)品設計師、用戶體驗師、視覺設計師四個角色。

另外，前端開發(fā)工程師、測試工程師所屬部門（產(chǎn)品/研發(fā)）會根據(jù)每個公司當前實際情況而定。一般來說，這個順序就是一個產(chǎn)品從規(guī)劃到最終成型的任務流方向，是一個從抽象到具體、商業(yè)到技術的過程。

如上圖所示，中小互聯(lián)網(wǎng)企業(yè)產(chǎn)品團隊基本包括如下角色：

產(chǎn)品經(jīng)理（PM，另一個PM項目經(jīng)理是從技術角度出發(fā)的職位）：Product Manager在產(chǎn)品管理中會涉及整個產(chǎn)品概念、計劃、開發(fā)、驗證、發(fā)布、運營生命周期。

以公司戰(zhàn)略方向為前提條件，核心工作是抓用戶需求、規(guī)則產(chǎn)品，對產(chǎn)品方向的把控，產(chǎn)品的整個生命周期，多條產(chǎn)品線的管理；跟蹤項目流程，推進項目進度，做項目的總體調控，協(xié)調各方資源使用平衡等！

根據(jù)每個企業(yè)業(yè)務的不同，企業(yè)還會針對業(yè)務特殊性設置專業(yè)性產(chǎn)品崗位（例金融產(chǎn)品經(jīng)理）；一個產(chǎn)品，首先由PM來分析細分市場、目標客戶的訴求，規(guī)劃產(chǎn)品的賣點，這個過程通常PD已經(jīng)介入了，這個層面上，商業(yè)問題、業(yè)務邏輯的流暢是思考的焦點。

產(chǎn)品設計師/需求分析師（PD）：Product Design直譯為產(chǎn)品設計師，也可以叫產(chǎn)品規(guī)劃師、需求分析師，是Product Manager的一部分職能。

PD側重于應用的功能設計，將業(yè)務需求轉換成功能需求、產(chǎn)品原型設計（包括交互和基礎UI），負責產(chǎn)品研發(fā)中各崗位對需求理解的一致性（例如與技術團隊中的架構師協(xié)商考慮技術可行性，性價比等），協(xié)助產(chǎn)品經(jīng)理實現(xiàn)產(chǎn)品的定位和協(xié)作項目經(jīng)理做項目進度的推進等。

產(chǎn)品部除了產(chǎn)品經(jīng)理和產(chǎn)品設計師之外最重要的就是UED（User Experience Design）團隊了；UED是進行產(chǎn)品策劃的主力之一，能夠用自己的互聯(lián)網(wǎng)知識來設計出行業(yè)專家想實現(xiàn)的操作，而付諸以商業(yè)營銷。

UED是以用戶為中心的一種設計手段，以用戶需求為目標而進行的設計。設計過程注重以用戶為中心，用戶體驗的概念從開發(fā)的最早期就開始進入整個流程，并貫穿始終。

UED團隊包括：交互設計師(Interaction Designer)、用戶體驗設計師(User Experience Design)、用戶界面設計師(User Interface Design)、視覺設計師(Vision Designer)和前端開發(fā)工程師(Web Developer)等等，企業(yè)會根據(jù)發(fā)展階段和產(chǎn)品的需求來匹配相應的人員崗位。

用戶體驗設計師（UE）：字面為用戶體驗師，可能稱作交互設計師、界面設計師。UE負責產(chǎn)品和用戶交互方面的設計，這方面在技術部門的配合角色是前端工程師（web表現(xiàn)層）。

通常UE拿到case的時候，要做什么功能已經(jīng)決定了，PD與UE要充分溝通，UE必須要了解很多商業(yè)層面的內容，理解功能的商業(yè)價值。

舉個例子，比如：在商業(yè)目的是獲取“注冊用戶數(shù)”的前提下，設計注冊流程是一頁搞定還是分幾個“下一步”，出錯提示是js彈出還是頁面即時判斷……

用戶界面設計師（UI）：英文直譯為用戶界面，可能也叫界面設計師、視覺設計師，很多工作室簡稱美工，與UE的界限在很多時候是模糊的。到了UI層面，基本是界面的表現(xiàn)，是用戶第一眼看到的效果，比如：配色、頁面結構、按鈕形狀、字體字號等等。

前端開發(fā)工程師（WD）：Web前端開發(fā)工程師（Web Developer）既要與上游的交互設計師、視覺設計師和產(chǎn)品經(jīng)理溝通，又要與下游的服務器端工程師溝通。除了掌握專業(yè)技能（如：頁面效果框架、模板語言、運用輔助工具進行兼容性處理等），網(wǎng)站性能優(yōu)化，有時還需要運用到修圖等各種輔助工具來進行修改處理、以及SEO和服務器端的基礎知識。另外，還需要掌握的理論知識，包括代碼的可維護性、組件的易用性、分層語義模板和瀏覽器分級支持等等。

針對上述人員配置，在產(chǎn)品設計不同階段的人員職責如下表：

4.2 崗位職責與工作關系

產(chǎn)品經(jīng)理（PM）：

負責配合產(chǎn)品部門完成前期產(chǎn)品市場需求、同類產(chǎn)品市場資料的收集，包括：WEB站、HTML5站點和APP。

根據(jù)產(chǎn)品需求，撰寫詳細的產(chǎn)品流程設計文檔、產(chǎn)品界面及原型設計文檔、產(chǎn)品的實施解決方案。

引導交互設計師完成產(chǎn)品的界面設計，協(xié)調開發(fā)人員進行開發(fā)工作，推動及協(xié)調產(chǎn)品的開發(fā)進度，把控項目質量。

跨部門協(xié)調和溝通，推動前端、開發(fā)和運營人員緊密合作達成產(chǎn)品目標。

監(jiān)督產(chǎn)品進度和監(jiān)控產(chǎn)品效果,收集用戶反饋，分析用戶行為及需求，對產(chǎn)品進行持續(xù)的優(yōu)化和改進。

產(chǎn)品設計師（PD）：

1. 配合產(chǎn)品經(jīng)理完成前期產(chǎn)品市場需求、同類產(chǎn)品市場資料的收集；
2. 根據(jù)需求文檔，撰寫詳細的產(chǎn)品流程設計文檔、產(chǎn)品界面及原型設計文檔；
3. 根據(jù)需要與研發(fā)、設計、測試等部門溝通，確保各個協(xié)作部門對產(chǎn)品設計的充分理解；
4. 原型設計工作（建議使用visio，axure等工具完成原型）；
5. 配合產(chǎn)品經(jīng)理和用戶體驗設計師完成產(chǎn)品設計與用戶體驗標準，收集并充分考慮用戶需求和用戶行為，對產(chǎn)品的持續(xù)優(yōu)化改進提出建議，并完成相關工作；
6. 協(xié)同界面設計師完成產(chǎn)品的界面設計，并協(xié)調前端開發(fā)人員完成前端開發(fā)工作，同時需要配合研發(fā)部門進行開發(fā)工作及測試部門完成產(chǎn)品的測試工作；
7. 配合產(chǎn)品經(jīng)理進行數(shù)據(jù)挖掘工作和分析工作，提升整體產(chǎn)品的用戶滿意度。
8. 參與系統(tǒng)功能驗收工作及用戶手冊、新增產(chǎn)品功能培訓資料的編寫。

用戶體驗設計師（UE）：

• 產(chǎn)品創(chuàng)新，界面視覺引導，原型設計，與開發(fā)一起推動設計實現(xiàn)。
• 基于人機交互、圖形化設計、界面設計和其他相關理論，進行設計。
• 畫出不同層次的原型:紙上的，框架的，可交互的網(wǎng)頁（Html），F(xiàn)lash的。
• 生成視覺元素，比如：icon、邊框、用戶控件、窗口規(guī)范、圖形化的布局。
• 同產(chǎn)品設計團隊合作去發(fā)展一些重要附加值的概念，還有修訂產(chǎn)品等。

用戶界面設計師（UI）：

1. 根據(jù)產(chǎn)品需求，對產(chǎn)品的整體美術風格、交互設計、界面結構、操作流程等做出設計。
2. 負責項目中各種交互界面、圖標、LOGO、按鈕等相關元素的設計與制作。
3. 能積極與開發(fā)溝通，推進界面及交互設計的最終實現(xiàn)。
4. 負責軟件界面的美術設計、創(chuàng)意工作和制作工作。
5. 對現(xiàn)有應用產(chǎn)品頁面進行優(yōu)化，使用戶操作更趨于人性化。

前端開發(fā)工程師（WD）：

1. 根據(jù)公司需求進行UI設計；
2. Web前端表現(xiàn)層及與前后端交互的架構設計和開發(fā)；
3. 配合后臺開發(fā)人員實現(xiàn)產(chǎn)品UE及UI頁面結構的代碼編程及腳本編碼；
4. Web新技術調研和資訊整理;

五、產(chǎn)品需求管理

1. 需求收集來源（常用方法）

• 用戶調研：用戶調研是通過問卷調查、用戶訪談、行業(yè)數(shù)據(jù)報告等手段來收集需求的方式。
• 競品分析：競品分析是找到同類競爭產(chǎn)品，深入體驗競品功能，為產(chǎn)品設計及需求收集尋求思路。
• 頭腦風暴：對主題進行討論，涉及人員（例如：產(chǎn)品經(jīng)理、設計師、運營、市場、銷售，開發(fā)等）
• 用戶反饋：用戶反饋是產(chǎn)品在測試階段或正式發(fā)布后，我們會收到很多的用戶反饋。
• 數(shù)據(jù)分析：數(shù)據(jù)分析在產(chǎn)品上線后，就可以收集到產(chǎn)品的相關數(shù)據(jù)了。

2. 需求分析和篩選

需求收集以后，PM將對收集進來的備選需求，進行分析和篩選。

• 篩掉明顯不合理的需求
• 需求分析：需求從哪里來，目標用戶是誰？有多少人有這樣的需求？這個需求緊迫嗎？用戶的痛點是什么？使用場景是什么？（用產(chǎn)品之前／后）怎么驗證需求是否解決與解決效果？

3. 需求的減法

產(chǎn)品理念，少即是多（輕量化產(chǎn)品）；其實，有時候決定不做什么往往比決定做什么更加重要。產(chǎn)品的需求可以說是無上限的，大量的堆積需求，會使得產(chǎn)品非常臃腫，而且毫無特色，而需求的過多，還會導致工期過長，拖慢了產(chǎn)品推出市場的進度，對產(chǎn)品百害而無一利。

4. 需求的優(yōu)先級排列

通過需求分析評估和篩選了哪些需求該做，哪些需求不該做，對于決定要做的需求，由于數(shù)量過多，不可能全部都在同一時間全部開發(fā)完畢。這個時候，就需要產(chǎn)品經(jīng)理對所有的需求來定義一下優(yōu)先級，優(yōu)先級高的需求優(yōu)先研發(fā)，優(yōu)先級低的需求延遲研發(fā)。

從0到1的打造一款產(chǎn)品，是沒有相關的運營數(shù)據(jù)作為支撐的。這個時候，大部分在定義需求的優(yōu)先級時，我們一般通過需求對用戶的重要性和緊迫性來判斷。我們可以參考KANO模型。

KANO模型是用來進行判斷需求重要性的一條非常有用的法則。KANO模型定義了三個層次的用戶需求：基本型需求、期望型需求和興奮型需求。

基本需求是必須具備的，即使不說也應該做到，這部分需求一般是產(chǎn)品初期需要做的功能；期望型需求是用戶期望的，用戶能夠較清晰地知道的。而興奮型需求是超出用戶預期的，用戶不知道有這方面的需求，如果提供，用戶滿意度會更高。

一般情況下，用戶需求的重要性依次為：基本型需求→ 期望型需求→ 興奮型需求。

考慮完了需求的重要性問題，接下來考慮需求的緊迫性問題。

通常情況而言，基本型需求的重要性最高，且也最緊迫，所以基本型需求的優(yōu)先級默認是最高的。如果公司其它部門，如運營、市場、銷售等部門業(yè)務需求的迫切需要，會同時研發(fā)一部分期望需求（重要不緊急）和興奮型需求（緊急不重要）。

在做需求的時候，可以嘗試著用KANO模型進行需求的優(yōu)先級排序，但是重要的是結合當時的互聯(lián)網(wǎng)發(fā)展狀況及背景進行分析。

六、產(chǎn)品工作經(jīng)驗分享

如何做到與各部門高效協(xié)作?

• 所有人員無論是哪個部門的，都應該對產(chǎn)品的認識是一致的;
• 產(chǎn)品的每一階段的目標必須清楚;
• 避免大多的零散文檔，盡量使用高保真的原型;
• 每個人的職責必須明確;
• 敏捷開發(fā);

如何保證產(chǎn)品在開發(fā)過程中功能的加減?

• 在做之前明確3個點：這個版本哪些功能要做?這個版本哪些功能不做?在實現(xiàn)此版本的過程中每個階段哪些功能要完成(上線)?
• 如果有新功能可以放在下一個版本中評估;

高保真原型的好處是什么?

• 節(jié)省時間，在互聯(lián)網(wǎng)快速敏捷的開發(fā)過程中，以詳細的產(chǎn)品設計文檔為主先行的方式，進行需求描述，表達已不能直接滿足當下互聯(lián)網(wǎng)需求的高頻變化（因從產(chǎn)品經(jīng)理編寫發(fā)布，到已項目開發(fā)設計相關人員，閱讀都存在大量時間耗費，有時還不能直接理解）；現(xiàn)以高保證交互原型為主，文檔為輔的輸出方式成為行業(yè)通行表達方式。
• 有了高保真原型圖則不一樣，與最終實際效果一致，開發(fā)人員等項目相關人員看一眼基本全明白了，而且大家看到的最終東西都是一樣的，這是文字無法表達的。
• 可提前做用戶測試（適用于2B產(chǎn)品），提前拿給客戶預演驗證產(chǎn)品的靠譜性，降低產(chǎn)品上線后的風險。
• 缺點是耗時較長，前置條件需具備充足項目周期，否則采用中或低保真原型處理。

產(chǎn)品計劃要做到多細?

• 根據(jù)所屬產(chǎn)品的特性來分解任務（每周/每日/工時等），常見產(chǎn)品計劃能分解到每天，主要是能了解每日的進度，關鍵節(jié)點的跟進協(xié)調。
• 簡單清晰，重要的任務節(jié)點控制好，高頻和開發(fā)人員保持溝通。

產(chǎn)品經(jīng)理和項目經(jīng)理的區(qū)別是什么?

產(chǎn)品經(jīng)理：核心工作是抓用戶需求、設計產(chǎn)品、產(chǎn)品生命周期把控。

項目經(jīng)理：確定產(chǎn)品能按計劃開發(fā)&通過內測，順利部署/發(fā)布上線。

開發(fā)人員知道產(chǎn)品背景有什么好處?

• 目標清楚，避免陷入思維死角，不必對需求產(chǎn)生過多疑問糾結于沒有必須糾結的細節(jié)點。
• 可以提供更好的技術實施解決方案，必須開發(fā)人員是最了解技術的。

產(chǎn)品開發(fā)的周期如何評估?

• 在明確的需求的前提下，開發(fā)人員給出的開發(fā)時間之后進行評估。因為在開發(fā)過程中會有很多意外的風險點因素發(fā)生，例如：常見的溝通時間、會議時間，產(chǎn)品BUG測試延誤等。
• 如時間充裕的情況下，用開發(fā)人員給出的時間乘以1.5倍左右作為心里預估時間，具體協(xié)商得到開發(fā)周期預估時間節(jié)點后，再調整產(chǎn)品開發(fā)計劃。
• 如時間周期有限，則橫向評估可用資源，預留必要的項目質量時間。

例如：評估需求任務能分解至的最小單元、評估任務工作周期所預留的最遲時間節(jié)點，與現(xiàn)有各崗位人力數(shù)和消化能力配比、評估風險點占比等都是影響項目關鍵時間節(jié)點的因素。在所羅列的橫向資源清單下，評估的風險點會相對更清晰，逐一有效的平衡掉因時間原因導致的過剩任務量堆積，或凸顯的較為明確的風險點。

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

題圖來自Unspalsh, 基于CC0協(xié)議