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

在產品經理的工作中，需求管理無疑是最核心的工作內容之一，但如何做好這項工作呢？筆者將為我們分析個人怎么做中后臺產品需求管理的思路和步驟。

中后臺的產品往往是面向企業(yè)或者組織的產品。在進行需求管理時，除了要關注產品的實際使用者，還需要關注企業(yè)或組織的需求。

我們可以簡單地把所要面對的用戶進行分類：高層領導、中層管理者、普通員工。其特性分別如下：

• 高層領導：關注長遠期產品價值，希望通過產品能夠對公司業(yè)務有整體的了解；
• 中層管理者：關注目標的達成、關心業(yè)務流程的順暢、各個環(huán)節(jié)的職責，希望對團隊中的成員的完成結果有詳細的了解；
• 普通員工：關注自己需要進行的功能操作，及判斷其操作的標準。

我們把需求管理劃分為如下幾個步驟：需求調研、需求分析、需求實現(xiàn)（優(yōu)先級劃分），其他的產品工作環(huán)節(jié)暫且忽略。

一、需求調研

在做需求調研之前，我們一定要確定調研對象，我們可以通過公司的組織架構，對整體的業(yè)務有一個初步的了解。如果已經配合過多次的項目，則要自己整理整體的業(yè)務流程中涉及的用戶。

在確定了調研對象后，需要組織專門的需求調研會議。會議形式可根據(jù)實際情況而定，但一定要通過郵件的形式完成會議邀請和會議紀要。

在需求調研會議上，我們需要對參會人進行一個初步的判斷，有兩個標準：權利和相關度。

• 權力大、相關度高的參會人提出的需求或問題，一定要進行詳細地了解，并記錄清晰；
• 而對于權利大、相關度小的參會人提出的建議，則需要虛心接受，若不能進行實現(xiàn)需要及時說明；
• 對于權利小、相關度高的人需要重點關注，在會后可與其進行更多細節(jié)性的討論；
• 而對于權利小、相關度低的人則充分聽取其意見即可。

以上分類，也是各類用戶的需求產生矛盾時解決問題的標準：第一類人的需求最需求優(yōu)先解決；其次看權利小、相關度大；再次看權利大、相關度??；最后一類視情況進行完成。

在會上，我們要盡可能地引導用戶把需求描述的更準確，可采用如下固定模式：

（1）你們想在有哪些崗位或者角色？

（2）每個角色有負責有哪些業(yè)務？

• 描述下該業(yè)務的流程是要解決一個什么樣的問題？
• 業(yè)務中涉及哪幾個崗位或角色？
• 業(yè)務的步驟有哪些，并簡要描述下。
• 有沒有異常情況，異常情況如何處理？
• 在管理上有沒有什么要求？例如：異常預警；領導查看權限；領導才有的特殊操作；報表。

（3）每個崗位或角色如何進行匯報，有沒有相關的報表格式

二、需求分析

通過以上的相關問題，我們可以清晰地了解到公司業(yè)務的基本情況，而以崗位或角色為切入點進行需求的調研，會十分方便我們后續(xù)進行需求分析。

中后臺產品重業(yè)務邏輯，而業(yè)務邏輯就是通過每一個角色的一個一個操作動作串聯(lián)起來的。

從收集到的需求中，分辨出來哪些步驟或邏輯能夠在系統(tǒng)中實現(xiàn)，哪些不能。這樣，能很好地劃分系統(tǒng)的邊界。

系統(tǒng)最擅長處理計算、存儲、查詢以及跨地域傳輸信息的工作，我們不能把所有的業(yè)務操作都系統(tǒng)化，系統(tǒng)如果管得過細會加重業(yè)務人員的負擔。

在需求分析中，我們首先需要根據(jù)前面所整理的資料按業(yè)務功能建立用例圖，用例圖一般有三種元素：參與者、用例、系統(tǒng)邊界。

用例圖的繪制需要注意一下幾點：

• 以一個解決具體事務的流程為視角，一張用例圖盡量把一個業(yè)務說清楚。
• 用例圖的描述要以用戶的角度出發(fā)。例如：“添加員工信息”對于用戶來講應當是做什么呢——填寫新員工資料；“更新員工信息”對于用戶來講又是做什么呢——更改員工資料；“刪除員工信息”又是什么呢——員工注銷。
• 用例圖也可以有層級，可以有系統(tǒng)級的用例圖，也能有功能級的流程圖。

我們根據(jù)用例圖中定義的角色、操作，通過業(yè)務流程圖按執(zhí)行的時間順序或分角色串聯(lián)起來。

我們需要準確定義順序、分支、循環(huán)等邏輯的判斷標準，使其形成完整的業(yè)務流程。

在業(yè)務流程中，我們需要已明確的圖示來區(qū)分系統(tǒng)完成和線下完成，且設計好從線下到線上、線上到線下的對接功能。

通常這種從虛擬到現(xiàn)實的對接功能，包含：導出、打印、發(fā)送、導入、上傳等。在設計這種功能時需要注意相關的校驗、去重、個性化定制等特殊的需求。

在需求分析階段，我們經常會發(fā)現(xiàn)一些新的衍生需求，這時我們需要快速找到對應的干系人，與其溝通討論。

用戶在未見到系統(tǒng)之前，其提出的需求都有可能把某一些關鍵信息遺漏，有些他們習以為常的常識我們做需求分析的人是不知道的。

由于我們進行完需求分析后可能會發(fā)現(xiàn)有大量的需求要去實現(xiàn)。如果一次把所有的需求都進行實現(xiàn)，我們付出的成本太高，用戶等待的周期過長。而且可能會發(fā)生實現(xiàn)的產品與客戶的期望差距太遠。

為了解決成本、周期、期望的問題，我們需要對需求進行優(yōu)先級劃分，以實現(xiàn)快速迭代逐步交付的目的。

通過快速迭代能夠讓用戶提前接受產品，以矯正前期由于空對空造成的需求缺陷的問題，一般第一個迭代的周期在兩個月之內為正常，后續(xù)的迭代需要維持在2到4周為最佳。

三、如何進行優(yōu)先級的劃分呢？

有一個基本的原則供大家參考：權利大的優(yōu)于權利小的，相關度高的優(yōu)于相關度低的，功能優(yōu)于報表，正常優(yōu)于異常。

如果使用原則是有沖突，則找到實際使用者中的業(yè)務專家，與其確定優(yōu)先級，在匯報該權力大且相關度高的領導。

通過基本原則劃分后，我們還需要組織相關的需求優(yōu)先級確認會議，與相關干系人達成共識，讓其了解迭代計劃的具體情況。

而在每一周，我們均需要對迭代計劃執(zhí)行的情況以郵件的形式進行同步，對于核心干系人則可以在固定周期以匯報的形式同步情況。

本文由 @keeliu　原創(chuàng)發(fā)布于人人都是產品經理?，未經許可，禁止轉載。

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