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

從定義來看，需求分析階段包括：找到用戶-采集用戶需求-深入分析需求-需求工程化表達(dá)。我們以B端產(chǎn)品的CRM系統(tǒng)為例，在需求分析階段，產(chǎn)品經(jīng)理的工作主要包括哪些？

B端產(chǎn)品種類繁多，大體分為對外標(biāo)準(zhǔn)型產(chǎn)品（如釘釘、標(biāo)準(zhǔn)云服務(wù)、身份認(rèn)證接口服務(wù)等）和半（全）定制化開發(fā)型產(chǎn)品（如ERP、CRM、進(jìn)銷存等協(xié)助企業(yè)進(jìn)行人、財、物管理的系統(tǒng)），兩者從工作流程、產(chǎn)品設(shè)計方面有較大差異，為避免歧義，本文所述的B端產(chǎn)品主要指后者。

消費(fèi)級產(chǎn)品普遍是先有產(chǎn)品，才會吸引用戶，帶來收入。因此C端產(chǎn)品經(jīng)理在開發(fā)一款產(chǎn)品前，要考慮清楚產(chǎn)品的商業(yè)模式，包括產(chǎn)品的目標(biāo)用戶的需求及使用場景，推廣模式及產(chǎn)品的盈利模式，調(diào)研市場空間及競品情況，避免開發(fā)出沒有市場的產(chǎn)品。

而B端產(chǎn)品與消費(fèi)級產(chǎn)品不同，B端產(chǎn)品會基于一些通用的組件，根據(jù)客戶特有的需求再定制化開發(fā)一部分功能，此類產(chǎn)品一般是先簽署了訂單合同，再進(jìn)行產(chǎn)品設(shè)計。產(chǎn)品經(jīng)理此時可以不用考慮產(chǎn)品的商業(yè)模式，包括推廣模式、盈利模式、市場空間等因素，可以直接進(jìn)入具體的項目執(zhí)行狀態(tài)。

因此，在商業(yè)模式分析方面，B端C端就已經(jīng)有所不同，C端產(chǎn)品商業(yè)模式分析是重要一環(huán)，決定產(chǎn)品成敗，而B端卻無需執(zhí)行商業(yè)模式分析步驟，直接進(jìn)入需求分析階段。

需求分析百科定義：是開發(fā)人員經(jīng)過深入細(xì)致的調(diào)研和分析，準(zhǔn)確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉(zhuǎn)化為完整的需求定義，從而確定系統(tǒng)必須做什么的過程。

從定義來看，需求分析階段包括：找到用戶-采集用戶需求-深入分析需求-需求工程化表達(dá)。我們以B端產(chǎn)品的CRM系統(tǒng)為例，在需求分析階段，產(chǎn)品經(jīng)理的工作主要包括：

1. 明確干系人；
2. 需求采集；
3. 深入分析需求；
4. 需求整理；
5. 軟件設(shè)計。

一、明確干系人

C端產(chǎn)品經(jīng)理經(jīng)常談及明確目標(biāo)用戶、用戶細(xì)分、用戶畫像等詞匯，在B端產(chǎn)品中，明確干系人工作與C端產(chǎn)品的用戶細(xì)分工作相似，但在B端產(chǎn)品中干系人又不僅是系統(tǒng)的用戶。

1. 干系人種類

干系人主要包括：出資者、使用者、評價者。

出資者通常不是產(chǎn)品經(jīng)理來搞定，由銷售人員或企業(yè)高管來直接對接，出資者在實際執(zhí)行中不會直接向產(chǎn)品經(jīng)理提需求，而是經(jīng)由銷售人員或企業(yè)高管來轉(zhuǎn)達(dá)需求。通常出資者如果有需求的話，也都是定性需求，如系統(tǒng)可以提升業(yè)務(wù)效率、系統(tǒng)安全性應(yīng)該有保障等，很少會出現(xiàn)具體的、定量的需求。

使用者同C端產(chǎn)品的用戶類似，是未來會直接、間接使用系統(tǒng)的人，此處采用的描述是系統(tǒng)而不是軟件，因為如果產(chǎn)品采用私有化部署的方式，干系人中不僅會包含軟件的使用者，還會包含系統(tǒng)的運(yùn)維人員，運(yùn)維人員會提出一些系統(tǒng)的部署、維護(hù)方面需求。

評價者主要指會提出一些驗收標(biāo)準(zhǔn)但又不使用系統(tǒng)的人，如法務(wù)、采購、財務(wù)等部門人員，有時他們還會具有一票否決權(quán)。

2. 干系人細(xì)分

對上述三類干系人，進(jìn)行干系人細(xì)分，細(xì)分的方式通常不像C端那樣花俏，通過需求、用戶行為、態(tài)度、價值觀等角度進(jìn)行用戶細(xì)分，B端的干系人細(xì)分方式一般是通過崗位來細(xì)分，如使用者中，銷售經(jīng)理、銷售主管、運(yùn)維人員等。

二、需求采集

C端產(chǎn)品的需求大部分來源于如下途徑：競品分析、用戶訪談、用戶行為觀察、問券調(diào)查、用戶反饋、可用性測試、數(shù)據(jù)分析，其中一些需求采集途徑和B端產(chǎn)品是通用的，如用戶訪談、問券調(diào)查，但也存在不適宜用到B端產(chǎn)品中的需求采集途徑。

例如C端產(chǎn)品利用數(shù)據(jù)分析來進(jìn)行用戶的需求采集，在B端產(chǎn)品中，軟件開發(fā)公司有時是拿不到數(shù)據(jù)的（如私有化部署的系統(tǒng)），沒有辦法去進(jìn)行數(shù)據(jù)層面的剖析。另外更重要的原因是數(shù)據(jù)分析花費(fèi)的人力、時間成本較高，多數(shù)情況下，系統(tǒng)驗收完畢之后，首款已到賬，此時已沒有動力去幫客戶進(jìn)行高成本的數(shù)據(jù)分析，只有客戶提出系統(tǒng)更改需求后才會去進(jìn)行版本迭代。

再例如競品分析，B端產(chǎn)品的競品輕易情況下是試用不到的，即使通過某種途徑試用了競品，不同客戶之間的需求也存在差異，B端產(chǎn)品中，通過模仿競品來設(shè)計產(chǎn)品是輕易走不通的。

B端需求采集途徑

B端產(chǎn)品的需求采集途徑主要包括：干系人訪談、問券調(diào)查、業(yè)務(wù)體驗、原型演示、中期演示等。

干系人訪談配以問券調(diào)查是需求采集的主要途徑，可以是一對一的聊，有時也會采用需求調(diào)研會的方式來進(jìn)行。

業(yè)務(wù)體驗是高時間成本的方法，但也是最好的方法，如果可以把產(chǎn)品經(jīng)理置于業(yè)務(wù)人員的角度去體驗一段時間，一個優(yōu)秀的產(chǎn)品經(jīng)理是完全可以培養(yǎng)出業(yè)務(wù)人員的用戶視角，否則單靠想象讓產(chǎn)品經(jīng)理具備B端業(yè)務(wù)人員的用戶思維，是一個高難度的事情。

原型演示不容忽略，設(shè)計好原型后讓干系人進(jìn)行確定，避免開發(fā)出的產(chǎn)品與干系人設(shè)想的不符。如果有條件可以采用高保真原型，高保真原型可以讓干系人進(jìn)行可用性測試，若只采用線框圖就讓干系人來體驗，在心理層面上，體驗時的重視程度會有所降低。

很多項目在開發(fā)完成之前是有中期演示的，中期演示一來可以讓干系人確保開發(fā)進(jìn)度是如期進(jìn)行中，二來也對產(chǎn)品功能的偏差可以做出及時調(diào)整。中期演示后需要做需求變更是一件高概率事件，干系人在項目開始時往往想不全的全部的需求點(diǎn)，在經(jīng)歷時間的發(fā)酵后，在中期演示后會進(jìn)行添補(bǔ)。

三、深入分析需求

深入分析需求是對干系人的意圖不斷揭示和判斷的過程，雖然是B端產(chǎn)品，但干系人也是真實的實體個人，此時和做C端產(chǎn)品的需求分析類似，用戶在需求采集階段只會告訴你what（即表達(dá)他的需求是什么），有時還會告訴你他所設(shè)想的how（即設(shè)計方案或解決方案），而不會主動告訴你why（即需求的產(chǎn)生原因是什么）。

產(chǎn)品經(jīng)理的本能就是在需求采集和產(chǎn)品設(shè)計時，獲得what后可以繼續(xù)深挖why，進(jìn)而得出how。在此C端產(chǎn)品的需求分析方法論在B端產(chǎn)品中是可以直接借鑒的，如可以運(yùn)用蘇杰的“Y模型”，“5W2H分析法”等需求分析方法論，即如何通過what導(dǎo)出how。

由于B端行業(yè)差異很大，每個行業(yè)、崗位的用戶思維都不是輕易具備的，很難站在干系人的角度思考，所以對于B端產(chǎn)品經(jīng)理來說，學(xué)習(xí)對方工作領(lǐng)域的知識，理解業(yè)務(wù)極其重要，需要具備將對方的語言工程化，將抽象的需求具體化的能力。這一點(diǎn)說起容易，做到還是有一定難度的，可能某個B端5年的產(chǎn)品經(jīng)理，跨行業(yè)后都沒有該行業(yè)內(nèi)1年的產(chǎn)品助理更加懂行，所以通用的需求分析方法論很重要，深入行業(yè)也很重要。

控制需求

C端產(chǎn)品講究按需求的優(yōu)先級排列，排列方式如KANO模型的基本型、期望型、興奮型、無差異型、反向型需求，或四象限法則的緊急重要、緊急不重要、不緊急重要、不緊急不重要。到了B端就沒那么多排列方式了，只有一期，二期，三期可以進(jìn)行爭取，和客戶去提什么是MVP原則，通通不起作用，想把客戶的需求安排滯后，銷售經(jīng)理都不會同意。

B端產(chǎn)品在需求控制方面，需要做到識別錯誤需求和識別超出范圍需求。錯誤的需求包括技術(shù)上無法實現(xiàn)的、邏輯不符的、無實際意義的需求內(nèi)容，避免被干系人的天方夜譚帶跑偏。在判斷需求是否超出范圍，需要先嚴(yán)格執(zhí)行合同或者標(biāo)書中的標(biāo)準(zhǔn)，但有時合同簽署的會比較空泛，就需要在需求采集階段先同客戶共同明確項目目標(biāo)，以目標(biāo)為基準(zhǔn)判斷需求邊界，在客戶提出跨越邊界的需求時及時指明。

四、需求整理

需求整理需要對每一類細(xì)分的干系人，找出一個（覺得有必要可以找多個）最具代表性的人選，進(jìn)行干系人畫像。例如我們采訪了3個銷售經(jīng)理，選擇了一個最具代表的銷售經(jīng)理，將所有銷售經(jīng)理的需求內(nèi)容都整理到該干系人畫像表格內(nèi)。畫像信息可以包括基本信息、干系人關(guān)注信息、其他信息。

（1）基本信息：主要包括崗位、代表、角色、崗位職責(zé)、系統(tǒng)使用頻率、影響程度（對項目的影響程度）、聯(lián)系方式等。

（2）關(guān)注信息：主要包括需求點(diǎn)（可以標(biāo)注需求實際來源）、阻力點(diǎn)（例如領(lǐng)導(dǎo)的需求，加入監(jiān)管功能，對員工來說就是負(fù)需求；業(yè)務(wù)部門的易用性需求，對安全部門可能就是負(fù)需求）、重要程度。

（3）其他信息：包括便于站在干系人角度思考的信息，如教育背景、所學(xué)專業(yè)、對信息化的理解程度等。

示例：

崗位（銷售經(jīng)理）、代表（銷售經(jīng)理A王某）、角色（使用者）、崗位職責(zé)（市場拓展、客戶關(guān)系管理）、系統(tǒng)使用頻率（高）、影響程度（高）、聯(lián)系方式（13988888888）。

需求點(diǎn)1（新增客戶關(guān)系），重要程度（高）。需求點(diǎn)2（避免同一客戶被多個銷售同時聯(lián)系，該需求來源于銷售經(jīng)理B李某），重要程度（中）。

教育背景（大學(xué)），所學(xué)專業(yè)（通信工程），對信息化的理解程度（理解程度較高）。

五、軟件設(shè)計

在軟件設(shè)計方面，B端產(chǎn)品和C端產(chǎn)品的差異性就相對較大了，B端產(chǎn)品不會像C端產(chǎn)品一樣，設(shè)計時講究簡約設(shè)計，讓用戶“不等不想不煩不學(xué)”，花大力氣請UI同事進(jìn)行頁面美化。

B端產(chǎn)品經(jīng)理在經(jīng)歷了和干系人的若干次“美好”溝通之后，交互上能把尼爾森十大可用性原則都遵循了，就算是有良心的產(chǎn)品經(jīng)理或UE設(shè)計師了。界面美化方面，B端產(chǎn)品多數(shù)情況下都是在套用模板，很少會動用UI設(shè)計師來定制化界面風(fēng)格。

B端的軟件功能設(shè)計，本質(zhì)上就是對數(shù)據(jù)的輸入、加工和輸出的過程，操作上通常是在圍繞數(shù)據(jù)的“增刪改查”來進(jìn)行，再配以相應(yīng)的規(guī)則和約束條件。在軟件需求說明書中，產(chǎn)品經(jīng)理會以模塊用例和原型的方式進(jìn)行表達(dá)。

模塊用例一般包括背景描述、用戶、前置條件、后置條件、主場景、擴(kuò)展場景、規(guī)則等內(nèi)容。

5.1 背景描述

背景描述是不用多說的內(nèi)容了，無論B端產(chǎn)品還是C端產(chǎn)品，為什么要增加一個功能，即使是拍腦袋想出來也需要給出一個合理的解釋。可采用“用戶-需求-收益”的模板來描述背景，例如作為銷售主管，希望添加銷售機(jī)會管理模塊，這樣就可以動態(tài)分配銷售機(jī)會給有具備優(yōu)勢的銷售經(jīng)理。

5.2 用戶

用戶是指具有操作特定模塊權(quán)限的人員，一般會用有UML的用例圖來表達(dá)。例如：CRM系統(tǒng)中，銷售主管具有銷售機(jī)會管理權(quán)限，而銷售經(jīng)理沒有該權(quán)限。

5.3 前置條件

前置條件指需要滿足什么條件下，用例才可以被執(zhí)行。

例如，銷售主管分配銷售機(jī)會的前置條件為“存在未分配銷售機(jī)會的客戶”，如果添加這個前置條件，就表明系統(tǒng)對“已分配銷售機(jī)會的客戶”，銷售主管不可以再進(jìn)行分配銷售機(jī)會操作；如果不添加這個前置條件，就表明銷售主管可以對所有客戶分配銷售機(jī)會。不添加這個前置條件的不好之處在于，如果銷售主管已分配某客戶給銷售經(jīng)理A，幾天后又重新分配給銷售經(jīng)理B，若銷售經(jīng)理A未及時查看系統(tǒng)，會存在兩個銷售經(jīng)理同時在聯(lián)系同一客戶的情況。

若一個系統(tǒng)為不可采用游客方式訪問的系統(tǒng)，只有登錄后才可以進(jìn)行所有的操作，那么“已登錄”可以不用寫到前置條件中。

5.4 后置條件

后置條件是指用例執(zhí)行結(jié)束后的系統(tǒng)狀態(tài)，系統(tǒng)會有哪些變化。例如，銷售主管在完成指定客戶分配后，該客戶狀態(tài)需要從未分配變更到已分配，對應(yīng)的銷售經(jīng)理賬號下，跟蹤客戶的數(shù)量需要相應(yīng)增加。

5.5 主場景

主場景是軟件的主要執(zhí)行流程，也見稱為“基本路徑”。根據(jù)二八法則，主場景數(shù)量雖然會少于擴(kuò)展場景的數(shù)量，但主場景的使用率一般會占到80%以上。例如新增客戶關(guān)系中，主場景就是按照規(guī)則將客戶關(guān)系輸入完整，點(diǎn)擊保存按鈕。其中客戶關(guān)系輸入的內(nèi)容可以采用原型展示，也可以在“5.7規(guī)則”中描述。

5.6 擴(kuò)展場景

擴(kuò)展場景是主場景之外的分支，也見稱為“擴(kuò)展路徑”。例如在用戶登錄中，主場景是用戶輸入用戶名、密碼，點(diǎn)擊登錄，驗證成功，進(jìn)入系統(tǒng)。擴(kuò)展場景是如果用戶密碼輸入錯誤，或者用戶忘記密碼的處理流程。

5.7 規(guī)則

規(guī)則是指用例用到的業(yè)務(wù)規(guī)則、邏輯算法等，例如在搜索查找客戶時，模糊查找的規(guī)則是什么。

5.8 非功能性需求

非功能性需求是指產(chǎn)品為了滿足用戶的業(yè)務(wù)需求而必須具備的除功能之外的特性，其和功能性需求是相輔相成的。非功能性需求是軟件產(chǎn)品的必備部分，但非功能性需求卻常常被忽視。

有些非功能性需求產(chǎn)品經(jīng)理和開發(fā)人員會達(dá)成一種默契，即使不提明確的需求內(nèi)容，也會按照大家的共識來開發(fā)交付。但如果客戶有特別強(qiáng)調(diào)或產(chǎn)品經(jīng)理認(rèn)為有必要特別提出的非功能性需求，需要定量、詳細(xì)地描述出來，不可出現(xiàn)理解偏差或模糊性描述。

非功能需求中，常見的錯誤就是模塊性描述，例如采用定性描述，寫高易用性、高安全性類似的描述。其二常見的錯誤是無根據(jù)定量，拍腦袋寫標(biāo)準(zhǔn)，例如所有查詢請求需要在3秒內(nèi)響應(yīng)完成。

在定義非功能需求時，可以套用SMART原則，即有具體明確的指標(biāo)（Specific），指標(biāo)是可測試，可證明，可以衡量的（Measurable），目標(biāo)是可以達(dá)到的（Attainable），與功能性需求具有一定的相關(guān)性，可以說明問什么會存在這個非功能性需求(Relevant)，明確的截止期限（Time-bound）。

按照卡爾·魏格斯在《軟件需求》中的定義和劃分方式，非功能性需求分為外部質(zhì)量需求和內(nèi)部屬性需求，具體描述如下：

（1）外部質(zhì)量

• 易用性：當(dāng)在某時某地需要系統(tǒng)服務(wù)時，系統(tǒng)服務(wù)能夠被有效訪問的程度；用戶對系統(tǒng)的學(xué)習(xí)、記憶和使用的難易程度；
• 可安裝性：正確安裝、卸載和更新安裝應(yīng)用的難易程度；
• 完整性：防止系統(tǒng)數(shù)據(jù)錯誤以及數(shù)據(jù)丟失的程度；
• 互操作性：系統(tǒng)與其他系統(tǒng)或者其他組件互聯(lián)或者交互數(shù)據(jù)的難易程度；
• 性能：系統(tǒng)響應(yīng)用戶輸入或者其他事件的快慢程度以及可預(yù)見性；
• 可靠性：在故障發(fā)生之前，系統(tǒng)正常運(yùn)行時間；
• 健壯性：系統(tǒng)如何應(yīng)對非預(yù)期的操作；
• 安全性：如何防止系統(tǒng)被破壞性損壞；
• 防護(hù)性：系統(tǒng)如何阻止對應(yīng)用及其數(shù)據(jù)的未授權(quán)訪問。

（2）內(nèi)部屬性

有效性：系統(tǒng)使用計算機(jī)資源的效率；

可修改性：維護(hù)、修改、改進(jìn)以及重構(gòu)系統(tǒng)的難易程度；

可移植性：使系統(tǒng)能夠在其他操作環(huán)境中運(yùn)行的難易程度；

可重用性：在多大程度上能夠把組件使用在其他系統(tǒng)中；

可擴(kuò)展性：隨著用戶數(shù)量、事務(wù)、服務(wù)器或者其他擴(kuò)展，系統(tǒng)能夠隨之適應(yīng)的難易程度；

可驗證性：開發(fā)和測試能夠?qū)浖M(jìn)行驗證以查看軟件是否已正確實現(xiàn)的便利程度。

寫在最后

關(guān)于需求文檔的編寫，在實際工作中，不同團(tuán)隊會有適合自身的特定模板，有的團(tuán)隊要求細(xì)節(jié)描述詳細(xì)，有的項目團(tuán)隊可能要求描述簡單即可。其實文檔的內(nèi)容和模板都不是主要的，表達(dá)清晰、無模糊性、可做出來才是項目的首要任務(wù)。每種編寫規(guī)則都無所謂對與錯，適合團(tuán)隊的方式才是最好的。

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

題圖來自 Unsplash，基于CC0協(xié)議