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

本篇文章作者分享了2B類項目的產品分析流程，介紹如何系統地做產品設計與分析。

眾所周知，企業級的2B項目涉及到的業務復雜，模塊繁多，那么此類項目要如何去系統地做產品設計與分析呢？

本文會把我在學習和工作中習得的2B類項目的產品分析流程分享給大家，希望能給大家帶來一些啟發。

序：由業務驅動的需求思想

在面對2B類型的項目中，核心是要具備業務驅動需求的思想，能準確識別出客戶/用戶的問題級需求。

有時，企業級的利益相關者提出的一些所謂“需求”都是一些方案級別的，比如：“幫我們做一個平面圖的展示功能”、“協助制作一個詳細數據的報表”、“這個界面增加一個查詢工具”等等，這些都是客戶/用戶提出的方案，有時照客戶/用戶的意思做出來也未必能夠解決他們的實際問題。

而問題級需求則是站在客戶/用戶的角度展開的。要通過客戶/用戶訪談，澄清方案級需求背后的問題本質，深入了解此問題是在什么使用背景下發生的，并在這些的基礎上，提出準確的解決方案。

比如上述“幫我們做一個平面圖的展示功能”的需求，其本質可能是客戶/用戶在某些特殊情況下才遇到的問題，通過了解該問題，可能只需提供一個查詢分組功能就能輕松解決。

一、項目目標分析

項目目標是2B類項目的靈魂，是對于各干系人價值的一種體現，只有前期明確了解項目的目標/愿景，項目才能走在正確的道路上。

（一）問題訪談

通過與各利益相關者/干系人訪談，了解他們對項目的預期和現狀之間的差異，就可以定義出項目要解決的“問題”。

在該階段，通常會有兩種情況：外部觸發的和內部提出的。

1. 外部觸發

此類是項目項目的發起人因為受到外部的一些因素而提出的一個項目，此時通常只是有一個宏觀的大方向，但具體的要解決的問題不夠清晰。對于此類項目，我們要明確識別產生該項目的觸因，并且選擇出相應的策略。

比如，老板去參加了一個研討會，會議上看到了其他企業做到的成果，回來會要求我們做一套達到國內領先水平的某某系統。

這種情況是典型的外部觸發——參考觀察引起的項目目標，此時我們應該盡量還原領導觀察的內容，讓老板分享會議的收獲給我們，使問題場景化，以便理解他的目標。

上述是通過參考觀察其他項目產生的需求，有時還會遇到競爭對手的新動向引出的項目升級。比如，企業高層看到了競爭對手的項目有了某某功能，也會要求自家的項目做同樣的功能等。

此時，可能并沒有梳理出清晰、完整的思路。我們要做的就是幫助他們提供一份競品分析，通過競品分析使其找到此次項目改進的要點。

2. 內部提出

有時項目的起源是企業內部的發起人，其考慮到了目標與現狀的差異。針對此種情況，最有效的方式就是訪談，還原表象、分析原因、共商決策。

（二）定義問題

通過上一步的有效訪談，接下來就要清晰的定義要解決的問題。

有效的描述一個問題，要從其業務態、客觀性和匹配性去把握。從業務的角度去闡述問題，而不是系統的角度，讓讀者可以從實際業務角度更好的理解問題。

同時描述問題時避免主觀因素，要盡量從客觀的角度出發，不評判、不推斷，只闡述問題本身。匹配性則指的是問題的闡述要與讀者（高層）的關注視角相匹配，比如經營方向、管理模式和業務模式等方面。

比如，業務態描述：“當前借助系統生成的數據報表，存在業務相關數據不一致的現象?！笨陀^性描述：“當前操作流程下，不按找流程操作的現象時有發生，如未按時間規定上傳報表、未接到上層數據就產出報表等。”

（三）分析問題并確定解決方案

當我們清晰地定義了問題，就可以對問題原因進行分析，然后制定相應的解決方案。此時制定的解決方案是一個概括級的，并不是要展示出解決方案的細節。

在此階段，要一句話闡述出解決方案，一般會采用“措施+效果”的結構。比如：“基于XXX問題，為企業增加XXXX系統?！?/p>

了解了項目的目標/愿景，我們大體知道了要做一個什么項目，接下來就要去明確都有哪些人去用這個項目——干系人。

二、各類干系人角色的分析

對于大多數2B類項目/項目而言，都會涉及到各種干系人角色，他們會有不同的需求點、關注點，因此識別與分析各干系人要素是十分重要的。

（一）各干系人的識別

要分析各干系人角色的需求，首先要準確識別出各干系人。我們首先要收集企業的組織架構，根據項目的目標把所有涉及的部門都標識出來，每個部門及各分支機構的的負責人就是主要的干系人，有時企業的副職負責人也會是相關干系人。

另外，涉及到項目風險的角色，也會是項目的相關干系人，比如：項目對一類客戶/用戶產生負面的影響，此類客戶/用戶也是干系人。

（二）各干系人的分析

識別出了項目設計的各干系人，接下來就要分析出他們對于項目的需求點和關注點。我們首先要選擇出各干系人，如果一類干系人有很多位，就要選擇出一個干系人代表，我們要確切的了解他的職業角色和工作聯系信息，做到對每一類干系人都了若指掌。

在這里，分析干系人最常用的方式還是訪談。根據干系人的具體工作主題分解、工作階段分解去了解其在項目中的需求點與關注點，明確他們在項目中的位置。我們可以從兩個角度出發：一是他們希望項目解決什么問題、提供什么業務支持；二是他們希望避免出現什么樣的負面影響。這樣就能完成比較立體的干系人分析。

現在，我們也明確了各干系人通過項目可以完成哪些工作了，接下來我們就要去拆分一下這個大項目了——業務模塊分解。

三、業務模塊的分解

2B類的項目有時很復雜，會涉及到不同的業務，為了控制其分析的復雜度，我們通常會先將其分解成更小的部分，在這里推薦根據業務來進行劃分。通常采用的策略如下：

1. 按業務職能分解

對于管理業務的項目，最典型的業務子模塊劃分就是按照業務職能進行的。在劃分之前，可以先繪制出與其相關的組織架構圖，然后根據組織/部門之間的關系，劃分出各個業務子模塊即可，部門職能最典型的是產（生產/產出）、銷（銷售）、供（供給/供應）、管（管理）四部分。

如下圖體檢中心的項目系統劃分：

2. 按項目、服務分解

此時可以梳理出業務結構樹，然后以不同的項目/服務作為劃分的線索。比如，項目中涉及到不同的審批類型，而此時不同的干系人需要在不同的類型中扮演不同的角色，此時就應按照項目/服務進行劃分“資金審批”“物資審批”“行政類審批”等。

3. 雙維度分解

對于一些更加復雜的系統，有可能需要采用上述雙維度進行劃分，先用其中一個維度做一級劃分，再用另一個維度做二級劃分。

比如，對于一個醫院系統，可以先通過項目/服務劃分，將其劃分成門診、住院、體檢等子模塊，再在各子模塊中利用職能分解對其進行二次劃分。

通過對項目的分解，我們有效的將項目劃分成了一個個小的模塊。接下來，就要整理出各業務模塊之間的業務關系和服務關系，可考慮的維度如下：

• 本子模塊需要其他模塊提供什么服務？
• 本子模塊能夠為其他模塊提供什么服務？
• 這些服務由誰負責提供？
• 這些接口哪些是現有的？哪些需要開發/修改？

好了，已經得到了不同的業務子模塊，接下來就要對各個模塊進行業務流程的分析了——業務流程的分析。

四、業務流程的分析

（一）識別出相關的業務流程

2B項目的核心價值之一就是支持業務，而業務支持的核心是對業務流程的設計、固化、優化和重構。所以，識別出項目的相關業務流程是很關鍵的。

1. 什么是業務流程

業務流程是項目的核心，任何一款項目都有自己的業務流程（不管2B還是2C）。在2B類的項目中，業務流程尤為重要。業務流程通常是一個多人協作的過程，而且需要一定的有效規則進行控制，才能達到預期的效果。

如何才能有效識別出項目中的業務流程呢？企業或組織的核心價值在于響應外部客戶/用戶的服務請求，通過一系列的協作滿足其服務請求，為客戶/用戶帶來價值，同時為企業/項目帶來價值。

也就是說，業務流程的起點就是這些外部服務的請求。企業中每個成員的工作都是屬于某個流程的，而且會是多個流程。我們應該尋找其源頭，即服務請求，這樣也就識別出了業務流程。

尋找到源頭只是起步，因為業務流程是要有一個合適的結束點的。這個結束點體現在服務請求從提出到滿足的全過程，也就是要判斷這個服務請求是否被滿足或被拒絕。同時，也要考慮業務流程的邊界，不要跨越到未涉及的業務域或者是系統未關注的部分。

2. 如何識別出業務流程

在實踐中，我們需要對各個業務子模塊逐一進行業務流程的識別。我們可以按照一定的順序去操作，一般會通過先外部（外部客戶/用戶請求）后內部（內部員工請求）的順序進行，具體步驟如下：

（1）識別出外部引發的主、變、支流程，先識別出由外部客戶/用戶的服務請求，大部分業務流程會來自外部。

在此階段，要明確子模塊有哪些外部的客戶/用戶以及其他部門的員工會發起服務請求。在此基礎上，識別出主業務流程：主服務請求；主服務請求的變體流程：變體業務流程；支撐業務流程：更好服務客戶/用戶的輔助支持業務。

比如一個酒店住宿系統，主業務流程就是“辦理住宿流程”，變體業務流程是“換房流程、續費流程”，支撐業務流程是“投訴流程、房內消費流程、行李寄存流程等”。

（2）識別出內部引發的主、變、支流程，有些服務請求是由內部員工發起的，如審批流程，還有的會在特定時間、特定狀態下發起的，因此內部請求要作為補充。

在此階段，要明確有哪些內部員工會發起流程，以及有哪些特定時間或狀態下會引發的流程。將員工最核心的業務請求識別為主業務流程，將業務訴求的變體識別為變體業務流程，將輔助支持業務識別為支撐業務流程。

（3）識別管理流程，有一些業務流程是為了實現控制、監督和管理，要單獨識別。

管理流程的識別通常會是一個難點，比較好的方式就是通過與客戶/用戶溝通交流獲得。在此階段，要注意幾個維度的思考：是否需要業務的審批控制流程；是否需要人、財、資源的管控流程；進度及異常的控制。

（4）判斷業務流程優先級，對業務流程做優先級判斷，有利于做出合適的迭代計劃。

業務流程是系統項目交付的最小單元，只有實現了完整的業務流程支持，對客戶/用戶來說才是有增量價值的。在識別完所有的業務流程之后，應對其進行優先級判斷以支持項目迭代。這里推薦從是否為主營業務與發生頻率高度兩個維度進行分析：

（二）業務流程的分析

在識別出業務流程之后，就要對每一個業務流程進行分析，繪制業務流程圖。

在分析之前，需要掌握兩個關于業務流程的關鍵點:

1. 業務流程是分級的

1. 組織級流程：展現各部門間的協作，以部門為泳道/職能帶區，讀者對象一般是管理視野。
2. 部門級流程：展現崗位間的協作，以具體崗位為泳道/職能帶區，與部門協作無關。
3. 個人級流程：定義崗位的操作規程，通常沒有泳道，盡量細化具體流程。
4. 子流程：個人級流程如果過于復雜，可繼續拆分子流程。

層級關系：組織級流程>部門級流程>個人級流程>子流程。

2. 業務流程的八要素

五個基本要素（分工，活動，協作，產物關系，分支）

分工（各部門、崗位間的分工）是流程中極其重要的要素，當一個流程中有了分工，就必然會將前一個人負責的事拆成一系列更小的、相對獨立的工作任務，這就是“活動”。

當我們分析分析一個業務流程時，首先要明確出整個流程中涉及哪些分工、每個角色負責執行什么活動，然后選擇合適的流程圖將其表示出來。當然，這些活動之間不是相互獨立的，它們之間存在順序執行、并行執行以及異常執行多種可能，這就是“協作關系”，在流程圖中就是各個活動之間的連線。

而且協作過程不是一成不變的，還需要根據實際情況進行處理，這就是流程中的“分支”。這也是流程圖中的一個重要因素。

最后，在協作過程中，各分工之間需要傳遞工作產物（數據），管理者可能會制定一些表單、數據表，這就是“產物關系”。在流程圖中通常是數據流或文檔等形式。

三個管理要素（審核、規則、異常）

審核通常對應著審批流程，在分析流程時，應識別出審批內容和審批意圖，這樣才能分析到位，并且在命名時不要采用“崗位名稱+審批”的格式，比如經理審批，科長審批，這樣實在是太含糊不清，應該采用“審批意圖/內容+審批”的格式命名，比如設備選型合理性審批、預算審批、采購渠道審批等，這種命名可以有效的將審批意圖展示清晰。

規則則是流程中涉及到的一些限制性的事務。比如在某種前提下，才能進行某某操作；庫存數小于10時，不能再接受訂單等。

異常比較好理解，在流程執行過程中總有可能出現一些意外，事先要針對其制定一些備案措施。在流程圖中可以附加文字進行說明，如果處理過程復雜，可以另外增加異常流程的流程圖。

3. 業務流程的分析步驟

（1）選擇流程圖的描述方式。

如果我們分析的是業務流程圖，大部分時候我們需要強調的不僅是分工，還包括每個角色所要執行的活動，因此應該選擇泳道圖/活動圖：

如果涉及到的是系統之間的業務流程，如“銀行轉賬”等，這時通常需要強調的是系統之間的交互過程，此時最好采用UML時序圖：

（2）勾勒流程主體。厘清業務流程中的分工、活動、協作、分支、產物關系五要素，搭出流程的主體框架。

在這一步，要注意，分工應平級。要么全是崗位名稱，要么就全是部門名稱，不要混著使用。并且，應該繪制出業務全過程，不要考慮系統的邊界，以免在后續的分析中遺漏。最后，業務流程要從服務請求者開始畫，誰發起的服務請求就從這里開始畫起，保證流程的完整性。

（3）補充管控點。厘清業務流程中的異常、審批、規則。

首先，要和干系人代表就“異?！边M行交流。重點的思考方向是“是否存在完全不能夠按這個業務流程執行的情況？如果存在，應該如何處理？”可以用文字或異常流程圖進行說明。

其次，要把重點放到“審批”上，可以詢問相關干系人“現在有哪些審批點？還有哪些環節存在執行風險？需要增加怎樣的審批流程？由誰進行審批？”等問題。

最后，再沿著流程，思考一下是否需要設置規則?？梢詮南旅鎺讉€角度著手思考，協作間規則：用于控制流程協作的規則，比如“倉庫管理員應該在每月5號前向采購部門上報采購申請訂單”；業務活動執行規則：在執行各個業務步驟時需要遵循的規則，比如“只對有審批蓋章的文件進行處理”；數據規則：針對表單、文檔等生成產物的格式、內容進行限制的規則，比如“金額取小數后兩位”。

（4）分析流程執行過程中的監控需求。從高層管理者的角度，對流程進度、異常等方面的管控、識別，補充一些輔助的相關需求。

在這一步驟中，我們要通過管理者獲得相應的管理需求，可以在進度與效率、執行異常和其他管控三個維度進行收集。

（5）檢查、優化流程。

在完成了業務流程的分析、繪制后，我們要回過頭來，重新跑一遍各個業務流程，看一下是否有可以進行優化的地方。優化的策略如下：

• 清除無效（刪除）。找到流程中浪費的、低效的環節，想辦法清除。
• 簡化高頻（簡化）。對于使用頻率最高的流程進行優化，提升流程效率。
• 整合依賴（組織）。將相互依賴度高的環節整合到一起，提高效率。
• 自動化（轉移）。將人做起來麻煩的事讓機器去做，提示使用效率。

現在，各業務流程已經分析出來了，接下來就要識別出這些流程中存在哪些和項目/產品相關的業務場景了——業務場景分析。

五、業務場景的分析

用例、用戶故事是我們耳熟能詳的需求分析技術。它們的精髓在于“用戶視角、業務場景/使用場景”。要求我們不再關注系統提供什么功能，而是用戶在什么場景下需要項目/產品提供支持。

（一）業務場景的識別

有了對業務流程的分析，識別項目/產品所支持的業務場景將變得很簡單，只要基于流程圖來識別出角色、場景，然后補充一些時間、狀態觸發的場景，最后將其呈現出來即可。

1.?基于流程圖識別角色，明確以下維度：

• 要對這個流程提供支撐，至少要涉及到哪些用戶？
• 對于項目/產品而言，這些用戶扮演的是什么角色？
• 從權限角度如何抽象出這些角色？

2.?基于流程圖識別業務場景。沿著流程過程，對每個活動、分支、判斷點進行分析和思考：哪些業務活動要系統支持、哪些是不分支持，審批點是否屬于系統內，判斷點是否為獨立環節。

3.?補充業務場景。除了由人觸發的業務場景之外，還存在特定時間、特定狀態觸發的業務場景，它們有可能沒有在流程圖中體現出來。因此在完成前兩步之后，還需要花費時間補充出這類易于遺漏的業務場景。

4.?繪制用例圖并概述業務場景。

當所有業務場景都識別出來后，我們可以使用用戶圖來呈現結果，并對涉及的業務場景做一些說明。用例圖中最為核心的就是actor（參與者）與用例。

我想強調一下用例的概念：用例即業務場景（用戶的使用場景），一個完整的業務場景應該是獨立的、可匯報的、可暫停的單元。

用例圖的表示方式如下：

（二）業務場景的分析

1. 概述業務場景

（1）該業務場景中，用戶要實現什么樣的業務目的？

用一句話概述用戶執行該業務場景所要完成的業務目的是什么。要使用用戶語言，重在傳達用戶的意圖。

（2）執行該場景有什么前提條件？結束前需要保證何種狀態？

對于一個業務場景而言，有時是需要執行條件的，有時則是在業務場景執行完成之前必須確保滿足某個狀態。分別稱之為前置條件和后置條件。

前置條件是用戶在執行該業務場景之前，系統/產品需要檢查什么狀態。例如用戶在操作查閱合同報表之前，必須已經上傳該合同信息。

后置條件是用戶在結束該業務場景之前，系統/產品需要檢查以確保什么狀態。例如，在電商網站下單的業務場景，其后置條件是要檢查下單數量要小于庫存數量。

（3）除了場景的執行者之外，還有誰關心它？關心什么內容？

在一個業務場景中，除了執行它的用戶之外，還可能涉及上游、下游、管理者、協作者等其他關心該場景的其他角色。對于一些關鍵的業務場景，還有必要思考他們有什么關注點，是否需要提供一些功能來滿足這些需求等。

2. 細化業務場景的業務步驟

細化業務場景的業務步驟時，可以通過訪談干系人代表、觀察他們的工作、或者直接收集他們的操作規程作為輸入。在執行該過程中，可以思考三個維度：最典型的、用戶預期內的業務步驟時怎樣的；針對各個步驟，有哪些潛在的變化情況；針對各個步驟，有誤異常的情況，異常如何處理。

3. 重復步驟分析困難，導出功能

我們要針對每一步驟與客戶/用戶了解存在的困難、挑戰，然后構思系統的解決方案。在這個步驟中，一般從兩個角度來思考：

• 首先是執行這些步驟時會遇到什么困難，也就是思考“在這個業務步驟、變化及異常情況下會遇到何困難？針對這些困難，系統/產品需要提供什么樣的功能支持”兩個問題。
• 其次，分析是否存在一些關鍵的例外，會帶來執行的麻煩，也就是思考“是否存在不能按以上步驟處理的情況？這種情況需要系統/產品提供什么樣的功能支持？”

4. 識別環境與規則

在分析一個業務場景時，還應該考慮環境、業務特點給系統/產品實現帶來的要求和影響。通?？梢酝ㄟ^以下幾個維度進行：

• 性能相關：主要包括執行該業務場景的人數、典型的業務量、峰值情況的業務量、密度。
• 易用性相關：主要是用戶相關系統的使用經驗，這對于系統易用性設計有著指向性的作用。
• 部署環境相關：說明用戶所在的網絡、軟硬件等相關環境。

5. 分析實現方式，完成初步的交互設計

此時的交互設計不是詳細的交互設計，是初步的交互設計，通常包括以下幾方面的內容：

• 交互過程：界面的跳轉圖，用來表達我們希望系統/產品如何實現該場景的所有業務步驟。
• 靜態快照：即每個頁面上的具體內容，通?？梢允褂眉埫嬖捅磉_。
• 設計說明：針對于每個頁面內容、界面跳轉做一些描述，核心在于說明為什么這樣考慮，以及這是一種建議還是必須如此。

截至當前，我們已經完成了業務流程與業務場景的分析，接下來，我們要為以后考慮，通過數據分析可以優化我們的系統/項目，這就要引出接下來的要點——數據指標的識別預分析。

六、數據指標的識別與分析

2B類項目重要的價值之一就是要支持管理，而支持管理的核心就是通過數據指標分析管理系統/產品，和通過數據分析完成后續的項目迭代。準確的識別與分析出數據指標能幫助我們很好的實現支持管理。

識別與分析出數據指標的核心在于：把握用戶想要得到什么信息，明確他的管理意圖是什么。

1. 標識管理者

在這一步驟中，應該首先在子系統模塊尋找到相關的決策層（高管）、管理層用戶，然后在流程層級尋找相關的管理層用戶，最后應該在整個系統層級尋找相關的決策層用戶。

找到了整個系統所涉及的管理者之后，還應該繼續判斷他是屬于哪種類型，比如管理型還是經營型，不同類型的管理者所關注的重點也是不一樣的。企業級2B項目中涉及到的管理者通常有六級：

1. 管理自我型：這一級別準確地說應該是員工，作為一個員工，也應該做好個人的一些管理，比如時間管理、計劃管理等。
2. 管理團隊型：通常負責帶領一支小團隊完成上級交給的任務，比如組長、隊長等都是此類管理者。他們關注團隊管理、人員管理。
3. 管理事務型：項目經理就是典型的這一類管理層。他們將對一件事負責，人、進度、資源都會涉及到。
4. 管理職能型：此類管理層關注于多事務，也會關注人、進度和資源。
5. 管理業務型：他們將涉及經營性指標，更加關注客戶、產品、供應商等經營性主題，對具體的執行性事務關注較少。
6. 管理事業群型：他們將管理多業務，一般對于資本、均衡等方面更加重視，想法會更宏觀，通常他們關注的都是決策相關的內容。

2. 識別管理意圖

標識出所有的相關管理者之后，接下來可以通過訪談，側面了解其職位職責及考核指標，標識出其希望通過項目/產品來實現的管理意圖。

如果是管理型的管理者，建議從管理問題著手，比如事務管理、人員管理、財務管理等方面；如果是經營型管理者，則可以從經營性問題著手，比如客戶、產品、供應商等方面。

3. 分析所需指標

分析數據指標時，可以從正反兩面進行。正面就是要思考分析業務設置合理性需要哪些數據信息，反面就是思考如果業務設置不合理會出現哪些情況，這些情況又可以通過哪些數據反映出來。

比如，業務設置合理性分析就是要看業務的受歡迎程度，比如業務量、利潤等數據，再確定可以通過什么樣的形式去展現這些數據。而業務設置不合理性的分析，就是分析出在項目服務中有哪些反面的指標，比如排隊時間等。

數據指標是介于管理意圖和數據報表之間的斷層，分析出具體數據指標可以有效的連接這個斷層。另外，管理意圖和數據指標之間是多對多的，一種意圖可以對應出不同的數據指標，同時，一個數據指標也可以反饋出不同的管理意圖。

4. 確定實現方式與數據內容

最后就要分析出數據指標展現的實現方式，即分析出數據源是否固定、查詢條件是否固定、數據庫查詢出該指標是否復雜等。

在確定數據內容時需要明確以下幾點：

• 生成數據所需的輸入條件：可以是界面呈現，也可以是基于查詢條件。
• 數據來源：明確該數據是由哪些數據表中獲得的基礎數據，說明要對哪些數據進行統計。
• 數據報表中數據的格式與計算方法：逐一列舉出每個數據項的格式及計算方法。

至此，一個企業級2B項目的分析與設計的流程就差不多了，但是還沒有完，接下來要明確在項目投入使用之后，涉及到的維護性需求——維護性需求分析。

七、維護性需求分析

在維護性需求階段，要拋開功能性思考，識別出有哪些維護性場景，以及維護場景需要提供什么支持。

1. 標識配置性維護場景

對于企業級2B項目，第一種典型的維護場景就是各種配置，用來應對變化帶來的影響。那么，標識配置性維護場景應該從變化入手。系統通常會遇到以下幾方面的變化：

• 用戶群變化：使用項目/產品的用戶發生改變，比如他們的職位發生改變，他們的權限發生改變等。因此，要想維護用戶、維護角色、維護權限，就需要一些相應的配置功能。比如，功能權限、數據范圍權限、分配權限的權限。
• 流程變化：企業流程會根據自身發展過程中關注點的改變而不斷進行調整，以滿足階段性的管理目標。因此，如何應對流程的變化帶來的影響，是需要提前考慮的。
• 數據變化：隨著企業業務的壯大，會需要在項目/產品中引入更多的數據項或更多的數據細節。因此，應該提前考慮如何應對未來增加的數據或數據構成的調整與變化。
• 法規變化：企業在經營過程中，有時會涉及法律法規的要求，而法律法規會在一定的時間周期內變更或出臺新的條例。因此也需要考慮當法規變化時，如何有效應對。

因此，在該階段，應該列舉出項目/產品生命周期中可預見的變化，通過配置功能提前應對。

2. 標識項目運行階段的維護場景

項目在運行過程中，要確保其安全、可靠、穩定的運行。此方面，可以從正常和故障兩方面進行分析。

• 正常時：系統正常運行時，要對運行狀態進行監控，通過服務、網絡通信、數據庫等方面進行運維。
• 故障時：在系統出現故障時，需要及時有故障排查、故障修復等措施的支持。

3. 其他維護場景

除了上述的維護之外，還包括以下其他維護場景：

• 系統初始化：在項目第一次運行時，需要提供什么樣的初始化配置，安裝什么工具等。
• 系統升級：在系統升級時需要提供什么樣的支持，比如自動化升級、版本檢查升級等。
• 系統遷移：每次系統升級時，是否需要進行數據遷移等。

維護性需求可以幫助項目/產品有效的應對待維護性場景，接下來，還需要明確一些項目的非功能性需求——非功能性需求分析。

八、非功能性需求分析

非功能性需求可以為業務提供穩定、可靠、易用的支持，因此非功能需求也是不可小覷的。

1. 標識非功能需求

非功能性需求包括但不限于：安全性、可靠性、易用性、高并發、可維護性、可移植性等。關于非功能需求的詳細描述，大家可以參考《一文讀懂，產品需求的科學化挖掘流程》這篇文章關于非功能需求的介紹，在這里就不再贅述了。

2. 重要性排序

對于非功能去求重要性的排序，可以通過“威脅影響度”和“出現頻率”進行判斷。

• 威脅影響度：生命攸關>造成經濟損失的>造成小損失的>操作不便的。
• 出現頻率：出現頻率可分為三級，經常出現、偶爾出現、低頻率出現，可分別賦予不同權重。

不同的維度可以交給不同的人/團隊，然后將結果相乘，根據最后的結果排序，找到最重要的非功能需求。

3. 制定對策

對于以上找出的非功能性需求，我們要找到相應的對策去避免其發生，是采用技術手段還是通過優化業務去完善等。

4. 驗證矛盾并解決

在實際給出的對策中，有時會產生一些矛盾。比如，驗證碼與用戶體驗之間的矛盾，這時我們就要去衡量，是否可以有更高效的方式？比如，拖拽圖形驗證。再或者，為了系統的性能，不得不犧牲一些用戶體驗。

至此，整個項目/產品的設計分析流程就結束了。在整個過程中，業務規則會一直貫穿其中，深入理解業務才是最重要的核心。

九、總結

我們來總結一下，涉及到的整個流程如下：

項目目標分析——各類干系人角色的分析——業務模塊的分解——業務流程的分析——業務場景的分析——數據指標的識別與分析——維護性需求分析——非功能習慣需求分析

這個流程不一定適用于所有項目，活學活用，希望能給你帶來一些啟發~

#專欄作家#

流年，人人都是產品經理專欄作家?；ヂ摼W產品設計師，4年互聯網產品設計經驗。擅長用戶體驗設計，喜歡鉆研需求功能背后的技術實現方式；在成為綜合型產品設計師的道路上不斷努力前進！

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

題圖來自 Unsplash ，基于 CC0 協議