產(chǎn)品設(shè)計&團(tuán)隊協(xié)作說明
?
??
文檔密級：內(nèi)部
文檔編號：CP-10-2016
文檔版本：v1.0
文檔狀態(tài)：發(fā)布
發(fā)布日期：2016/10/8
?
擬制?????楊?焦???????日期??2016/10/8
審核????????????????日期
批準(zhǔn)????????????????日期
湖南XX網(wǎng)絡(luò)科技有限公司
--------------------------------------------------------------------------
目錄
--------------------------------------------------------------------------
l 產(chǎn)品設(shè)計
相關(guān)輸出：需求規(guī)格說明書、產(chǎn)品交互原型設(shè)計文檔（.RP/HTML）、UI圖形原文件
l 產(chǎn)品開發(fā)階段的溝通
相關(guān)輸出：日報/周報
l 產(chǎn)品設(shè)計相關(guān)的市場分析與用戶調(diào)查工作
調(diào)查計劃、調(diào)查報告
l 相關(guān)評審工作
相關(guān)輸出：需求文檔修訂/評審記錄
工作目標(biāo)：根據(jù)公司產(chǎn)品戰(zhàn)略階段規(guī)劃和可行性研究，明確該階段“產(chǎn)品必須做什么”，對目標(biāo)系統(tǒng)提出完整、準(zhǔn)確、清晰、具體的功能要求。工作內(nèi)容包括需求規(guī)格說明文檔設(shè)計、產(chǎn)品交互原型文檔設(shè)計、UI設(shè)計。
相關(guān)輸出：需求規(guī)格說明書、產(chǎn)品交互原型設(shè)計文檔（.RP/HTML）、UI圖形原文件。
3.2.1需求規(guī)格說明
??定義：
1.需求規(guī)格說明書必須清楚的描述軟件的每一個基本需求（功能、設(shè)計約束和屬性）和外部界面。
2.必須把每個需求規(guī)定成能夠通過預(yù)先定義的方法（例如分析、演示、檢查、測試等）被客觀地驗證與確認(rèn)形式。
??標(biāo)準(zhǔn)：
在軟件需求分析階段結(jié)束后必須由項目組進(jìn)行軟件需求評審，以確保在軟件需求規(guī)格說明書中規(guī)定的各項需求的合適性。評審過程一般包括以下四個方面的驗證：
1.完整性
需求必須是完整的，需求規(guī)格書應(yīng)該包括產(chǎn)品規(guī)劃書所定義的產(chǎn)品戰(zhàn)略階段需要的每一個功能需求及性能性約定。
2.一致性
所有需求是一致的，任何一條需求不能與其他需求相互矛盾。
3.現(xiàn)實性
保證需求設(shè)計是用現(xiàn)有的軟硬件技術(shù)基本上可以實現(xiàn)的，基本適應(yīng)公司的開發(fā)技術(shù)資源水平的。
4.有效性
需求正確有效，確實吻合產(chǎn)品戰(zhàn)略方向、市場方向所需，避免做超出市場需求規(guī)劃范圍的無用設(shè)計。
5.可用性
需求說明書必須用清晰易懂的描述語言，邏輯清晰，準(zhǔn)確描述每一個需求的細(xì)節(jié)。以保障在無人職守的情況下能被產(chǎn)品開發(fā)團(tuán)隊中的閱讀對象正確理解。
3.2.2 UI設(shè)計
? 輸出：UI設(shè)計輸出為符合下述評審要求PNG/JPG/PSD圖形文件，并合理組織輸出相關(guān)?“Banner”、“層”、“按鈕”等界面元素。
? UI設(shè)計評審標(biāo)準(zhǔn)：
1.主題定位：主題表現(xiàn)鮮明，展現(xiàn)產(chǎn)品階段性定位特點，具有適當(dāng)個性的設(shè)計風(fēng)格，表現(xiàn)手法新穎；
2.功能容納：所容納功能符合產(chǎn)品需求設(shè)計；
3.布局要求：符合用戶體驗規(guī)則，方便瀏覽和操作；整體布局均衡合理，輕重層次合理，符合產(chǎn)品定位要求；風(fēng)格一致；
4.色彩要求：整體色彩要符合產(chǎn)品定位（包括用戶定位與行業(yè)領(lǐng)域），協(xié)調(diào)和諧，符合美感；
5.可修改性：方便進(jìn)行更新，修改；
從產(chǎn)品部門的角度出發(fā)，來理解目前中小互聯(lián)網(wǎng)企業(yè)中的幾大主要任務(wù)和相應(yīng)的職責(zé)區(qū)別，涉及產(chǎn)品經(jīng)理、產(chǎn)品設(shè)計師、用戶體驗師、視覺設(shè)計師四個角色，另外前端開發(fā)工程師、測試工程師所屬部門（產(chǎn)品/研發(fā)）會根據(jù)每個公司當(dāng)前實際情況而定。一般來說，這個順序就是一個產(chǎn)品從規(guī)劃到最終成型的任務(wù)流方向，是一個從抽象到具體、商業(yè)到技術(shù)的過程。
如上圖所示，中小互聯(lián)網(wǎng)企業(yè)產(chǎn)品團(tuán)隊基本包括如下角色：
l 產(chǎn)品經(jīng)理（PM，另一個PM項目經(jīng)理是從技術(shù)角度出發(fā)的職位）：Product Manager在產(chǎn)品管理中會涉及整個產(chǎn)品概念，計劃，開發(fā)，驗證，發(fā)布，運(yùn)營生命周期。以公司戰(zhàn)略方向為前提條件，核心工作是抓用戶需求、規(guī)則產(chǎn)品，對產(chǎn)品方向的把控，產(chǎn)品的整個生命周期，多條產(chǎn)品線的管理；跟蹤項目流程，推進(jìn)項目進(jìn)度，做項目的總體調(diào)控，協(xié)調(diào)各方資源使用平衡等！根據(jù)每個企業(yè)業(yè)務(wù)的不同，企業(yè)還會針對業(yè)務(wù)特殊性設(shè)置專業(yè)性產(chǎn)品崗位（例金融產(chǎn)品經(jīng)理）；一個產(chǎn)品，首先由PM來分析細(xì)分市場、目標(biāo)客戶的訴求，規(guī)劃產(chǎn)品的賣點，這個過程通常PD已經(jīng)介入了，這個層面上，商業(yè)問題、業(yè)務(wù)邏輯的流暢是思考的焦點。
l 產(chǎn)品設(shè)計師/需求分析師（PD）：Product Design直譯為產(chǎn)品設(shè)計師，也可以叫產(chǎn)品規(guī)劃師、需求分析師，是Product Manager的一部分職能。PD側(cè)重于應(yīng)用的功能設(shè)計，將業(yè)務(wù)需求轉(zhuǎn)換成功能需求、產(chǎn)品原型設(shè)計（包括交互和基礎(chǔ)UI），負(fù)責(zé)產(chǎn)品研發(fā)中各崗位對需求理解的一致性（例如與技術(shù)團(tuán)隊中的架構(gòu)師協(xié)商考慮技術(shù)可行性，性價比等），協(xié)助產(chǎn)品經(jīng)理實現(xiàn)產(chǎn)品的定位和協(xié)作項目經(jīng)理做項目進(jìn)度的推進(jìn)等。
l 產(chǎn)品部除了產(chǎn)品經(jīng)理和產(chǎn)品設(shè)計師之外最重要的就是UED（User Experience Design）團(tuán)隊了；UED是進(jìn)行產(chǎn)品策劃的主力之一，能夠用自己的互聯(lián)網(wǎng)知識來設(shè)計出行業(yè)專家想實現(xiàn)的操作，而付諸以商業(yè)營銷。UED是以用戶為中心的一種設(shè)計手段，以用戶需求為目標(biāo)而進(jìn)行的設(shè)計。設(shè)計過程注重以用戶為中心，用戶體驗的概念從開發(fā)的最早期就開始進(jìn)入整個流程，并貫穿始終。UED團(tuán)隊包括：交互設(shè)計師(Interaction Designer)、用戶體驗設(shè)計師(User Experience Design)、用戶界面設(shè)計師(User Interface Design)、視覺設(shè)計師(Vision Designer)和前端開發(fā)工程師(Web Developer)等等，企業(yè)會根據(jù)發(fā)展階段和產(chǎn)品的需求來匹配相應(yīng)的人員崗位。
l 用戶體驗設(shè)計師（UE）：字面為用戶體驗師，可能稱作交互設(shè)計師、界面設(shè)計師。UE負(fù)責(zé)產(chǎn)品和用戶交互方面的設(shè)計，這方面在技術(shù)部門的配合角色是前端工程師（web表現(xiàn)層）。通常UE拿到case的時候，要做什么功能已經(jīng)決定了，PD與UE要充分溝通，UE必須要了解很多商業(yè)層面的內(nèi)容，理解功能的商業(yè)價值。舉個例子，比如在商業(yè)目的是獲取“注冊用戶數(shù)”的前提下，設(shè)計注冊流程是一頁搞定還是分幾個“下一步”，出錯提示是js彈出還是頁面即時判斷……
l 用戶界面設(shè)計師（UI）：英文直譯為用戶界面，可能也叫界面設(shè)計師、視覺設(shè)計師，很多工作室簡稱美工，與UE的界限在很多時候是模糊的。到了UI層面，基本是界面的表現(xiàn)，是用戶第一眼看到的效果，比如配色、頁面結(jié)構(gòu)、按鈕形狀、字體字號等等。
l 前端開發(fā)工程師（WD）：Web前端開發(fā)工程師（Web Developer）既要與上游的交互設(shè)計師、視覺設(shè)計師和產(chǎn)品經(jīng)理溝通，又要與下游的服務(wù)器端工程師溝通，除了掌握專業(yè)技能（如：頁面效果框架、模板語言、運(yùn)用輔助工具進(jìn)行兼容性處理等），網(wǎng)站性能優(yōu)化，有時還需要運(yùn)用到修圖等各種輔助工具來進(jìn)行修改處理、以及SEO和服務(wù)器端的基礎(chǔ)知識；另外，還需要掌握的理論知識，包括代碼的可維護(hù)性、組件的易用性、分層語義模板和瀏覽器分級支持等等。
?
針對上述人員配置，在產(chǎn)品設(shè)計不同階段的人員職責(zé)如下表：
? 產(chǎn)品經(jīng)理（PM）：
1.?負(fù)責(zé)配合產(chǎn)品部門完成前期產(chǎn)品市場需求、同類產(chǎn)品市場資料的收集，包括WEB站、HTML5站點和APP。
2.?根據(jù)產(chǎn)品需求，撰寫詳細(xì)的產(chǎn)品流程設(shè)計文檔、產(chǎn)品界面及原型設(shè)計文檔、產(chǎn)品的實施解決方案。
3.引導(dǎo)交互設(shè)計師完成產(chǎn)品的界面設(shè)計，協(xié)調(diào)開發(fā)人員進(jìn)行開發(fā)工作，推動及協(xié)調(diào)產(chǎn)品的開發(fā)進(jìn)度，把控項目質(zhì)量。
4.跨部門協(xié)調(diào)和溝通，推動前端、開發(fā)和運(yùn)營人員緊密合作達(dá)成產(chǎn)品目標(biāo)。
5.監(jiān)督產(chǎn)品進(jìn)度和監(jiān)控產(chǎn)品效果,收集用戶反饋，分析用戶行為及需求，對產(chǎn)品進(jìn)行持續(xù)的優(yōu)化和改進(jìn)。?
? 產(chǎn)品設(shè)計師（PD）：
1. 配合產(chǎn)品經(jīng)理完成前期產(chǎn)品市場需求、同類產(chǎn)品市場資料的收集；
2. 根據(jù)需求文檔，撰寫詳細(xì)的產(chǎn)品流程設(shè)計文檔、產(chǎn)品界面及原型設(shè)計文檔；
3. 根據(jù)需要與研發(fā)、設(shè)計、測試等部門溝通，確保各個協(xié)作部門對產(chǎn)品設(shè)計的充分理解；
4. 原型設(shè)計工作（建議使用visio，axure等工具完成原型）；
5.配合產(chǎn)品經(jīng)理和用戶體驗設(shè)計師完成產(chǎn)品設(shè)計與用戶體驗標(biāo)準(zhǔn)，收集并充分考慮用戶需求和
用戶行為，對產(chǎn)品的持續(xù)優(yōu)化改進(jìn)提出建議，并完成相關(guān)工作；
6. 協(xié)同界面設(shè)計師完成產(chǎn)品的界面設(shè)計，并協(xié)調(diào)前端開發(fā)人員完成前端開發(fā)工作，同時需要配
合研發(fā)部門進(jìn)行開發(fā)工作及測試部門完成產(chǎn)品的測試工作；
7.配合產(chǎn)品經(jīng)理進(jìn)行數(shù)據(jù)挖掘工作和分析工作，提升整體產(chǎn)品的用戶滿意度。
8. 參與系統(tǒng)功能驗收工作及用戶手冊、新增產(chǎn)品功能培訓(xùn)資料的編寫。
? 用戶體驗設(shè)計師（UE）：?
1.產(chǎn)品創(chuàng)新，界面視覺引導(dǎo)，原型設(shè)計，與開發(fā)一起推動設(shè)計實現(xiàn)。
2.基于人機(jī)交互、圖形化設(shè)計、界面設(shè)計和其他相關(guān)理論，進(jìn)行設(shè)計。
3.畫出不同層次的原型:紙上的，框架的，可交互的網(wǎng)頁（Html），F(xiàn)lash的。
4.生成視覺元素比如icon,邊框，用戶控件，窗口規(guī)范，圖形化的布局。
5.同產(chǎn)品設(shè)計團(tuán)隊合作去發(fā)展一些重要附加值的概念，還有修訂產(chǎn)品等。
? 用戶界面設(shè)計師（UI）：?
1.根據(jù)產(chǎn)品需求，對產(chǎn)品的整體美術(shù)風(fēng)格、交互設(shè)計、界面結(jié)構(gòu)、操作流程等做出設(shè)計。
2. 負(fù)責(zé)項目中各種交互界面、圖標(biāo)、LOGO、按鈕等相關(guān)元素的設(shè)計與制作。
3. 能積極與開發(fā)溝通，推進(jìn)界面及交互設(shè)計的最終實現(xiàn)。
4. 負(fù)責(zé)軟件界面的美術(shù)設(shè)計、創(chuàng)意工作和制作工作。
5. 對現(xiàn)有應(yīng)用產(chǎn)品頁面進(jìn)行優(yōu)化，使用戶操作更趨于人性化。
? 前端開發(fā)工程師（WD）：?
1.根據(jù)公司需求進(jìn)行UI設(shè)計；
2.Web前端表現(xiàn)層及與前后端交互的架構(gòu)設(shè)計和開發(fā)；
3.配合后臺開發(fā)人員實現(xiàn)產(chǎn)品UE及UI頁面結(jié)構(gòu)的代碼編程及腳本編碼；
4.Web新技術(shù)調(diào)研和資訊整理;
1.需求收集來源（常用方法）
用戶調(diào)研：用戶調(diào)研是通過問卷調(diào)查、用戶訪談、行業(yè)數(shù)據(jù)報告等手段來收集需求的方式。
競品分析：競品分析是找到同類競爭產(chǎn)品，深入體驗競品功能，為產(chǎn)品設(shè)計及需求收集尋求思路。
頭腦風(fēng)暴：對主題進(jìn)行討論，涉及人員（例如：產(chǎn)品經(jīng)理、設(shè)計師、運(yùn)營、市場、銷售，開發(fā)等）
用戶反饋：用戶反饋是產(chǎn)品在測試階段或正式發(fā)布后，我們會收到很多的用戶反饋。
數(shù)據(jù)分析：數(shù)據(jù)分析在產(chǎn)品上線后，就可以收集到產(chǎn)品的相關(guān)數(shù)據(jù)了。
2.需求分析和篩選
需求收集以后，PM將對收集進(jìn)來的備選需求，進(jìn)行分析和篩選。
1、篩掉明顯不合理的需求
2、需求分析：
l 需求從哪里來，目標(biāo)用戶是誰？
l 有多少人有這樣的需求？這個需求緊迫嗎？
l 用戶的痛點是什么？使用場景是什么？（用產(chǎn)品之前／后）
l +1 怎么驗證需求是否解決與解決效果？
3、需求的減法
產(chǎn)品理念，少即是多（輕量化產(chǎn)品）；其實，有時候決定不做什么往往比決定做什么更加重要。產(chǎn)品的需求可以說是無上限的，大量的堆積需求，會使得產(chǎn)品非常臃腫，而且毫無特色，而需求的過多，還會導(dǎo)致工期過長，拖慢了產(chǎn)品推出市場的進(jìn)度，對產(chǎn)品百害而無一利。
3.需求的優(yōu)先級排列
通過需求分析評估和篩選了哪些需求該做，哪些需求不該做，對于決定要做的需求，由于數(shù)量過多，不可能全部都在同一時間全部開發(fā)完畢。這個時候，就需要產(chǎn)品經(jīng)理對所有的需求來定義一下優(yōu)先級，優(yōu)先級高的需求優(yōu)先研發(fā)，優(yōu)先級低的需求延遲研發(fā)。
從0到1的打造一款產(chǎn)品，是沒有相關(guān)的運(yùn)營數(shù)據(jù)作為支撐的。這個時候，大部分在定義需求的優(yōu)先級時，我們一般通過需求對用戶的重要性和緊迫性來判斷。我們可以參考KANO模型。
KANO模型是用來進(jìn)行判斷需求重要性的一條非常有用的法則。KANO模型定義了三個層次的用戶需求:基本型需求、期望型需求和興奮型需求?；拘枨笫潜仨毦邆涞?，即使不說也應(yīng)該做到，這部分需求一般是產(chǎn)品初期需要做的功能。期望型需求是用戶期望的，用戶能夠較清晰地知道的。而興奮型需求是超出用戶預(yù)期的，用戶不知道有這方面的需求，如果提供，用戶滿意度會更高。一般情況下，用戶需求的重要性依次為：基本型需求→ 期望型需求→ 興奮型需求。
考慮完了需求的重要性問題，接下來考慮需求的緊迫性問題。通常情況而言，基本型需求的重要性最高，且也最緊迫，所以基本型需求的優(yōu)先級默認(rèn)是最高的。如果公司其它部門，如運(yùn)營、市場、銷售等部門業(yè)務(wù)需求的迫切需要，會同時研發(fā)一部分期望需求（重要不緊急）和興奮型需求（緊急不重要）。
在做需求的時候可以嘗試著用KANO模型進(jìn)行需求的優(yōu)先級排序，但是重要的是結(jié)合當(dāng)時的互聯(lián)網(wǎng)發(fā)展?fàn)顩r及背景進(jìn)行分析。
1. 如何做到與各部門高效協(xié)作?
* 所有人員無論是哪個部門的，都應(yīng)該對產(chǎn)品的認(rèn)識是一致的;
* 產(chǎn)品的每一階段的目標(biāo)必須清楚;
* 避免大多的零散文檔，盡量使用高保真的原型;
* 每個人的職責(zé)必須明確;
* 敏捷開發(fā);
2. 如何保證產(chǎn)品在開發(fā)過程中功能的加減?
* 在做之前明確3個點：這個版本哪些功能要作?這個版本哪些功能不作?在實現(xiàn)此版本的過程中每個階段哪些功能要完成(上線)?
* 如果有新功能可以放在下一個版本中評估;
3. 高保真原型的好處是什么?
* 節(jié)省時間，在互聯(lián)網(wǎng)快速敏捷的開發(fā)過程中以詳細(xì)的產(chǎn)品設(shè)計文檔為主先行的方式進(jìn)行需求描述表達(dá)已不能直接滿足當(dāng)下互聯(lián)網(wǎng)需求的高頻變化（因從產(chǎn)品經(jīng)理編寫發(fā)布到已項目開發(fā)設(shè)計相關(guān)人員閱讀都存在大量時間耗費，有時還不能直接理解）;現(xiàn)以高保證交互原型為主，文檔為輔的輸出方式成為行業(yè)通行表達(dá)方式；
* 有了高保真原型圖則不一樣，與最終實際效果一致，開發(fā)人員等項目相關(guān)人員看一眼基本全明白了，而且大家看到的最終東西都是一樣的，這是文字無法表達(dá)的；
* 可提前作用戶測試（適用于2B產(chǎn)品），提前拿給客戶預(yù)演驗證產(chǎn)品的靠譜性，降低產(chǎn)品上線后的風(fēng)險；
*缺點是耗時較長，前置條件需具備充足項目周期，否則采用中或低保真原型處理。
4. 產(chǎn)品計劃要作到多細(xì)?
* 根據(jù)所屬產(chǎn)品的特性來分解任務(wù)（每周/每日/工時等），常見產(chǎn)品計劃能分解到每天，主要是能了解每日的進(jìn)度，關(guān)鍵節(jié)點的跟進(jìn)協(xié)調(diào);
* 簡單清晰，重要的任務(wù)節(jié)點控制好，高頻和開發(fā)人員保持溝通;
5. 產(chǎn)品經(jīng)理和項目經(jīng)理的區(qū)別是什么?
* 產(chǎn)品經(jīng)理：核心工作是抓用戶需求、設(shè)計產(chǎn)品、產(chǎn)品生命周期把控;
* 項目經(jīng)理：確定產(chǎn)品能按計劃開發(fā)&通過內(nèi)測，順利部署/發(fā)布上線;
6. 開發(fā)人員知道產(chǎn)品背景有什么好處?
* 目標(biāo)清楚，避免陷入思維死角，不必對需求產(chǎn)生過多疑問糾結(jié)于沒有必須糾結(jié)的細(xì)節(jié)點;
* 可以提供更好的技術(shù)實施解決方案，必須開發(fā)人員是最了解技術(shù)的;
7. 產(chǎn)品開發(fā)的周期如何評估?
* 在明確的需求的前提下開發(fā)人員給出的開發(fā)時間之后進(jìn)行評估，因為在開發(fā)過程中會有很多意外的風(fēng)險點因素發(fā)生，例如常見的溝通時間、會議時間，產(chǎn)品BUG測試延誤等;
* 如時間充裕的情況下用開發(fā)人員給出的時間乘以1.5倍左右作為心里預(yù)估時間，具體協(xié)商得到開發(fā)周期預(yù)估時間節(jié)點后，再調(diào)整產(chǎn)品開發(fā)計劃；
*如時間周期有限，則橫向評估可用資源，預(yù)留必要的項目質(zhì)量時間；
例如：評估需求任務(wù)能分解至的最小單元、評估任務(wù)工作周期所預(yù)留的最遲時間節(jié)點與現(xiàn)有各崗位人力數(shù)和消化能力配比、評估風(fēng)險點占比等都是影響項目關(guān)鍵時間節(jié)點的因素；在所羅列的橫向資源清單下評估的風(fēng)險點會相對更清晰，逐一有效的平衡掉因時間原因?qū)е碌倪^剩任務(wù)量堆積或凸顯的較為明確的風(fēng)險點。
