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

編輯導讀：在進行需求調研之后，就要對這些需求進行分析。?將需求落實到紙面上，再將它細化成具體的流程、功能、權限等。本文作者總結了自己的工作方法和工具，與你分享。

16年入行產品，從產品小白到助理到專員到產品經理，一路走來，遇到過苦難挫折，但也收獲了方法，提升了能力。從事產品工作以來一直在乙方工作，做過政務項目，也做過B端產品。通過幾年的工作總結出了一些可復用的工作方法與工具，希望分享出來能夠幫助到入行不久或想要入行的朋友們，也希望經驗豐富的朋友們能夠多多指教。

首先介紹一下我從事工作的背景：主要負責G端項目需求調研、產品設計、系統培訓、優化迭代工作。我將工作流程分為七個階段進行簡單介紹：需求調研、需求分析、產品設計、開發測試、上線試運行、項目結項、上線運行。本篇文章將介紹第二個階段需求分析。

第一階段文章需求調研篇：http://www.aharts.cn/pmd/4597524.html

需求分析階段我們需要做的工作是：

• 整理并理解客戶需求，與客戶確認需求；
• 將客戶需求轉換為產品需求，包括確定功能信息機構，業務流程等；
• 評估需求價值，確定設計方案；

需求分析階段我們的產出物是：

• 需求確認單；
• 業務流程圖；
• 狀態圖；
• 功能結構圖；
• 信息結構圖；
• 權限表；

需求分析階段我們的工作流程是：

一、分析前-確認需求

需求分析前最重要的工作就是確認需求，將需求落到紙面上。做G端項目，需求變更的頻率一直是居高不下，為了盡量減少變更，我們分析前需要再次進行確認，并讓客戶簽字。簽字的最大好處就是讓其重視起來，檢查自己提出的需求是否合適。進行需求調研時大多是聊天的形式，所以客戶說出需求并不完全準確。當你拿著一沓需求確認單，讓他簽字時，他就會非常認真的查看，這個時候往往會發現很多需要增減的需求。

以下是我司采用的需求確認單，僅供參考。

對于涉及業務較廣的項目，建議每個業務塊采用一份需求確認單。

二、分析中-流程、功能、信息、權限

1. 分析需求，梳理業務流程

因G端項目大多業務流程化較重，所以每次進行需求分析我都會從業務流程入手。需求調研時我們已經了解了業務的整體流程，但其中的細節還需繼續深挖，尤其是一些異常分支。

最近接觸的一個項目管理項目中，客戶給到的需求是：“對于不是我們單位管理的項目，需要進行項目登記，我們審核通過后，要在項目庫可以看到。有的項目可能在提交給我們審核前會內部先審一下，這個在平臺中也要提供?！?/p>

注：客戶的單位屬于該平臺的運營方。

根據客戶的描述我們可以很迅速的畫出以下流程圖，有時甚至可以直接在現場和客戶確認。

上圖確實可以將客戶的需求表述清楚，但還沒完全轉換為產品需求，在梳理一個流程時我們需要知道誰在什么時候做什么事情，對應的就是用戶角色、節點、操作。為了完善這三個元素，我們又畫了如下流程圖。

這個流程圖可以明確表達出某個用戶角色在某一節點需要做什么樣的操作。這樣就可以了么，不，還沒有結束。因為它只表達出了正流程，并沒有表達出在“審核”節點和“審批”節點若沒有通過該如何處理。這個時候我們就會發現審批不通過駁回時可以逐級駁回也可以駁回起點，兩種方式均可行，那么該采用哪種方式呢？這時我們就要回歸業務，與客戶溝通他們實際的業務都是怎樣處理的。雖然我們在需求分析前已經和用戶確認需求了，但那時確認的都是整塊的業務需求，并不細致，在實際分析的過程中遇到問題也需要及時與客戶溝通。

??這里需要強調一點，我們遇到問題時，不要每個小問題都去找客戶確認，可以將一類業務的問題收集起來，一起與客戶確認。如果總是因為一個小事情就去找客戶，時間長了他會很煩的，這對我們后續開展工作非常不利。

和客戶確認后，實際業務中，只要申請不符合標準都會駁回給申請人，那么完整的流程圖如下：

至此項目登記的流程圖梳理完成。

涉及審批流的業務自然離不開狀態，每次梳理完流程圖之后我都會直接將狀態圖一并完成。所謂狀態圖就是描述一條業務數據從開始到結束經歷的不同狀態，還以項目登記為例，其狀態圖如下：

2. 分析需求，梳理項目功能架構

當業務流程清晰之后，功能架構就很容易梳理了。首先，需要根據業務流程拆分功能模塊，由以上流程的出項目登記模塊有：新增申請、提交申請、審核申請三大功能，既然有新增就要有刪除、編輯。所以項目登記的功能結構圖如下：

以上示例中只是某個系統的一個小模塊的功能架構，一整個系統的架構就是要將每個小業務模塊的架構整合起來再加上基礎支撐模塊，如：個人中心，消息管理等。

3. 分析需求，梳理項目信息架構

完成了功能架構接下來就是信息架構啦，日常工作中很多小伙伴都將信息架構和功能架構放到一起，我最初也是適用的這種方法。信息架構和功能架構拆開或是合并只是工作習慣不同，大家可以適情況而定。我是感覺將其分開更清晰，方便查缺補漏，所以會分開來搭建功能架構和信息架構。在G端工作中信息架構重要的組成部分就是甲方爸爸給到的業務申請單，所以大家在調研時一定要記得要一份線下的業務申請單哈。項目登記信息架構如下（只是作為示例參考，實際信息架構要比這多很多）：

4. 分析需求，梳理權限表

G端業務還有一個特點就是涉及部門較多，一個流程可能涉及7，8個部門，每個部門的職責又相同，這個時候清晰的權限劃分就顯得尤為重要。經歷過多個政務項目后，我也總結出了一個比較通用的權限表分析給需要的伙伴。

圖1為模塊權限表，可以用來表示某角色是否可以使用某模塊。

圖2為操作-狀態權限表，可以表示某角色在某狀態下是否可以進行某操作。對于涉及狀態多、角色多、操作多的業務，這種權限表可以很清晰的表示出來并且不會遺漏。

三、分析后-整理分析材料

當我們完成需求分析工作后，還有一項工作就是整理材料，同步給項目組成員。許多大型項目涉及人員較多，產品小組就會超過3個人，這個時候同步需求材料就變得尤為重要。當負責每個業務的產品都完成需求分析后，需要將分析材料同步到在線協作文檔中，做到實時同步，當然這期間若業務間有數據交換的要及時溝通，并且得有一個產品負責人掌控全局，了解每塊業務的關鍵節點。

本文由@與爾同愁 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議