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

大家都在談如何進行需求分析？都有哪些步驟？而本文主要講的是關于需求的前世今生，它從哪里來，到哪里去？

一、需求收集

需求分析的前提是已經存在了需求，那么需求都是從哪里來的呢？我們怎么去收集需求呢？可參考《需淺談需求池管理》中的需求收集。

被動告知需求：

1. 主要業務部門，包括市場部、運營部、財務部、管理層等主要業務部門，需求目的是為了上線某一個新業務或者是新活動，這時候產品要做的是了解新業務或者新活動的內容，梳理出業務流程，整理涉及到的邏輯出demo等等；
2. 客服，需求目的是解決某一類用戶問題，當存在一類用戶頻繁咨詢或投訴這類問題，客服是會把這類用戶問題提交給產品組，產品來評估從業務和產品角度怎么進行優化此類問題；
3. QA，針對于視覺或者交互的細節QA在測試過程中，會遇到一些細節的小問題（主要是歷史遺留），這時候會提交給產品，一般此類需求等級較低；
4. 用戶意見反饋，每月收集整理用戶提交的意見反饋（吐槽或建議），分析用戶吐槽的問題是否具有普遍性還是個例，用戶的建議是否能實現，背后想解決什么樣的問題；

主動收集需求：

1. 競品分析，主要是在研究競品或者同類型產品中，發掘比較好的功能且適用于自己產品（能解決一部分用戶的需求或者能為企業帶了一定的收入）
2. 用戶研究，自己在論壇、貼吧、微博等內容社區，了解社區里那些屬于自己產品的目標用戶或潛在用戶都在吐槽或者期待產品的哪些內容，產品要做的是了解這些問題背后的原因是什么，其次是怎么能解決這些吐槽或者滿足用戶需求。
3. 數據分析，根據用戶的業務數據和行為數據進行分析，挖掘背后可優化的需求點。

二、需求描述

需求是什么？需要進行描述，描述的目的是了解它的前世今生，以后預測未來可能會是什么樣？如：需要簡化乘地鐵流程

現在的樣子

現在的乘地鐵的流程是：先買票，再憑票進站。買票有兩種普遍的方式，一種是地鐵儲值卡，另外一種是買單程票?，F在這兩種方式有什么問題呢？地鐵儲值卡存在著預繳押金且退還押金不便捷，而買單程票的方式一般是在售票機上購買。而售票機僅支持零錢購買且售票機數量較少，熱門地鐵站時常存在排長隊買票。

未來的樣子

根據現在乘地鐵的現狀，可以優化的兩個方面就是簡化買票流程和乘車流程。那么未來乘地鐵可能會是什么樣子呢？

1. 地鐵儲值卡電子化，可在網絡上進行購買地鐵儲值卡，支持押金+余額秒退。簡化購買儲值卡的流程。
2. 乘車碼，可在網絡上購買單程票，支持掃碼進/出站。簡化購買單車票的流程。
3. 人臉識別進/出站，買完車票之后，進/出站不用再進行刷卡或掃碼進/出站，只需要識別乘車人面部即可快速進/出站，簡化進/出站流程。
4. ……

三、需求全景圖

需求全景圖即將需求池內所有需求進行篩選排序，明晰各個需求的優先級，確保呈現出來的一副相對完整的需求全景圖。

企業-用戶獲利四象限

影響企業獲利的因素

• 企業收益，簡單點理解企業收益可以分成兩類，一類是無形的資產，如市場戰略、企業品牌、企業口碑等；另外一類則是有形的資產即存在具體貨幣收入。雖然無形資產最難衡量價值，但是對于企業來說屬于長期收益，重要性不言而喻。
• 企業成本，也可以簡單分成兩類，一類是開發成本，如需求上線前的開發成本，其中技術實現成本占比最大；另外一類為維護成本，需求上線后的維護所花費的成本，其中運營維護成本占比最大。所以在考慮企業成本方面可具體衡量技術實現和運營維護這兩大類成本。

影響用戶獲利的因素

一般都是通過KANO模型（基本型需求、期望型需求、興奮型需求、無差異型需求、反向型需求）來分析用戶需求進行分類和排序，但是在網上看到將KANO模型進行具象化，即用戶對于某一需求評價是怎樣的來進行需求分類和排序。按照用戶評價結果分類的優點是直觀，易于他人對于需求分類及優先級的理解。（出處見知乎better-worse系數值介紹）

注：“你”泛指大多數用戶

如何判斷需求優先級

可以給企業獲利因素和用戶獲利因素進行賦值，然后進行計算。如：

• 企業獲利因素：企業收益（1-10分），企業成本（1-10分）；
• 用戶獲利因素：基本型需求（2-5分）、期望型需求（6-8分）、興奮型需求（9-10分）、無差異型需求（1分）、反向型需求（0-負1）

需求優先級=（（企業收益-企業成本）/企業成本）*用戶獲利值。如果要精細化需求優先級，可將原有基礎上乘以滿足此需求用戶占比，即：

需求優先級=（（企業收益-企業成本）/企業成本）*用戶獲利值*目標用戶占比

四、非功能性需求

非功能性需求基本上包括性能需求、可靠性需求、易用性需求、安全性需求、 運行環境約束、外部接口、可保障性需求等等，其中對于產品來說，比較重要的幾點分別是易用性、兼容性、異常處理、可擴展性。

• 易用性，就拿to C的產品來說，新需求上線可能會更改老用戶原有的操作習慣，所以頁面上的蒙層指引顯得尤為重要，另外是對于客服來說，需要給到相關上線需求的操作文檔，以便客服能熟知后就解決用戶反饋的問題。
• 兼容性，若某一需求只針對于APP產品，那么需要考慮到的兼容性可能有兩個方面，一方面是平臺的兼容性，另外一方面是APP新老版本的兼容性。舉例，新版APP將上線掃碼購買地鐵票的需求，那么在其他平臺如PC、H5、小程序等平臺的商城中則不能顯示地鐵票，不然沒法進行掃碼購買。另外對于老版APP而言，因為之前無掃碼功能，則在老版APP商城中也不應該出現地鐵票。
• 異常處理，即出現異常后系統該如何提示，并處理？前期需要確認幾點，一、什么情況下會出現異常？二、異常提示樣式是怎樣的？toast還是dialog等樣式？三、異常提示內容是什么？四、多個環節中某一環異常，那整個流程是繼續還是停止？
• 可擴展性，上線時類型只有一種，但是上線后可能會存在多種類型，那么APP頁面樣式是否能支持自適應？
• 運行環境約束，最常見的是移動網絡和wifi之間是否會進行區分，如網易云音樂，在移動網絡打開APP則顯示我的音樂，在wif情況下打開APP則顯示發現音樂；另外還有摩拜掃碼取車，可以使用網絡請求也可以使用藍牙請求，移動網絡和藍牙同時打開時，優先運行哪種環境，這些都需要額外進行說明。

五、需求分解

需求分解可以通過用戶故事來進行內容分解，用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：

1. 角色：誰要使用這個功能。
2. 活動：需要完成什么樣的功能。
3. 商業價值：為什么需要這個功能，這個功能帶來什么樣的價值。

還是原來的例子，簡化地鐵乘地鐵流程

故事一：

角色：使用地鐵儲值卡乘地鐵的用戶

活動：可在線上進行地鐵儲值卡的充值以及購買

商業價值：減輕地鐵售票員的工作量以及方便用戶購買和充值地鐵儲值卡

故事二：

角色：使用地鐵單程票乘地鐵的用戶

活動：可在線上進行單程票的購買

商業價值：減少地鐵售票機投放以及方便用戶購買單程票。

故事三：

角色：刷卡進/出站的用戶

活動：可在進/出站進行識別人臉，允許已買票的用戶進行刷臉進/出站

商業價值：減少用戶刷卡進/出站操作以及緩解進/出站擁堵情況

故事四……

將一個需求按照不同場景來描述用戶故事，從而將原始需求進行一步步分解，一方面是將需求細化，另一方面是需求拆解成較多可落地的方案。

六、細化用戶故事

一個好的用戶故事應該遵循INVEST原則：

• 獨立性（Independent）— 要盡可能的讓一個用戶故事獨立于其他的用戶故事。
• 可協商性（Negotiable）— 一個用戶故事的內容要是可以協商的，用戶故事不是合同。
• 有價值（Valuable）— 每個故事必須對客戶具有價值（無論是用戶還是購買方）。
• 可以估算性（Estimable）—開發團隊需要去估計一個用戶故事以便確定優先級，工作量，安排計劃。
• 短?。⊿mall）— 一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。
• 可測試性（Testable）—一個用戶故事要是可以測試的，以便于確認它是可以完成的。

細化用戶故事的目的滿足小步快跑，快速迭代?？焖俚畲蟮膬烖c是及時的用戶反饋，這樣可以快速的調整產品的方向和驗證產品的合理性，減少風險。也就是說真正的迭代必須把每一個迭代周期的成果交給用戶，而且每次的成果都是完整可用的。快速迭代往往會注重當前用戶故事實現，最合理的應該是分解已知所有用戶故事，進行相關規劃后，再針對某一用戶故事的快速迭代。確保后續用戶故事的上線不存在推翻已有的架構，造成開發資源的浪費。

七、需求表達

在需求表達過程中，包括產品團隊內部，公司內部（產品和開發、運營、QA等），公司外部（產品和客戶）進行需求的傳遞，需求的交流和分析，需要將需求準備的表達出來，以便對方可以進行很好的理解。需求表達的方式有很多，excle、word、ppt、視頻、demo原型等，目的是通過某一種或多種表達方式，將需求完美、準確的表達呈現給用戶，以致于用戶能很好地理解需求。

八、測試上線

一般都有專門的QA團隊來進行需求測試，而產品測試的目的，主要是有兩點，

• 確認異常問題是否存在，如果你在上線前擔心某種異常情況的發生，那么它就更有可能發生（墨菲定律）。所以在上線有必要主動去測試所擔心的異常情況，確認它是OK的，做到心中有數。
• 操作體驗，上線前的對于功能的僅僅局限于理解層面，上線前可以通過demo測試，去真實的體驗操作，，一方面是確保前期的需求表達內容均已實現，另外一方面是將前期需求未表達到的細節點進行優化處理。

以上是基于自己對需求分析的想法，可能存在一定的局限性，僅供參考，歡迎大家多交流學習！

#專欄作家#

董小白，人人都是產品經理專欄作家。喜歡研究各類好玩好用的APP，關注出行、電商等領域；擅長整理和分析APP亮點功能設計。

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

題圖來自 unsplash