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

編輯導語：B端產品相比于C端產品，更為復雜。如何設計好復雜的系統更是讓不少設計師為之頭痛。本文作者根據自己的工作經歷，和大家分享自己在產品設計過程中的一些思考。感興趣的朋友一起來看看吧。

做過B端產品的同學應該都有比較深刻的感受，B端產品不同于C端產品，牽涉的業務流程繁瑣復雜、用戶角色多，且不同角色之間所關注的點不一樣，導致對于同一個系統或者業務流程，描述不一樣需求也不一樣。

而對于復雜的B端系統來說，我們要怎么樣從前期需求獲取、業務梳理、原型設計來完成整個產品的思考和設計。

下面我用最近一個由我主導落地的與司法鑒定相關項目為基礎，用實例和大家分享一下我在產品設計中的思考。

一、充分調研

產品經理工作職責最重要的部分是通過發現問題、提出解決方案、驗證問題，以此來滿足用戶需求。

我國將司法鑒定分為四大類，包括法醫鑒定、物證類、聲像資料類、環境損壞類。

四大分類互不相干跨度非常大，每一大類都有獨有的流程或要求。

而這四大類下又分為18子類，每個子類下又分別有很多分領域，比如“聲像資料類鑒定”分為“錄音鑒定、圖像鑒定、電子數據鑒定”這三個子類。

“電子數據鑒定”又分為“電子數據真實性鑒定”、“電子數據功能性鑒定”、“電子數據存證性鑒定”、“電子數據相似性鑒定”。

面對這種同一行業但具有不同分領域的情況，我們最應該做的不是第一時間和用戶方溝通，考慮到司法行業的特殊性，需要按照嚴格的規章制度來開展業務，不同領域的用戶需求是有差異的。

我選擇首先通過閱讀了解包括《司法鑒定通則》、《司法鑒定執業規范》等章程性文件，作為調研準備的第一步，以此希望能夠對司法鑒定有概括性的認識，同時也希望能夠在不同業務領域中找到共同點。

比如在通用的鑒定流程就包括：

收案登記->受理審核->鑒定實施/補充材料/不予受理->鑒定實施->鑒定復核->鑒定審核（簽發）->文書生成->歸檔。

這就是所有領域司法鑒定的通用流程。

在對整個司法鑒定行業有了整體性、概括性認識后，再去出去和用戶溝通，具有一定行業知識儲備后，后續的溝通才會更加順暢。

我們的用戶包括司法鑒定的主管部門（也就是司法局），四大類司法鑒定領域的用戶，包括機構負責人、鑒定人、鑒定助理、收案登記員、司法鑒定委托人等。

在與用戶溝通時，我更多的處于“多聽少說”的狀態，因為他們是這個行業的專業人員，也是未來系統的真實用戶，他們更加了解自己的行業、崗位，也是最知道自己需求的人。

對于不太善于描述需求的用戶，我們需要以提問的方式來引導用戶，通過“人、事、時間、地點”四要素來描述真實的業務場景和切實痛點。

比如其中一個場景需求痛點就是“鑒定助理（人）在鑒定人完成司法鑒定后（時間），需要在檔案管理室（地點）對案件的檢材、過程資料等進行歸檔（事），但是司法鑒定的周期長，涉及的資料文件多，在歸檔的時候難免出現遺漏或文件丟失的情況?！?/p>

通過前期的充分學習知識、用戶溝通，我們才能地從理解行業知識、業務需求，為我們后期梳理業務流程、角色、架構設計、原型設計夯實基礎。

二、業務聚焦

我們在做產品的時候，最忌諱在最初就貪圖大而全。

B端業務本身業務流程復雜、涉及角色多，如果一開始就奔著滿足所有用戶需求的目標設計、實現，往往會出現一下問題：

• 大而全的版本設計周期、開發周期較長，公司的時間成本、金錢成本高；
• 大而全的版本對于用戶來說學習成本、使用成本較高；
• 若后續需要改動，需要配合改動的子板塊較多，改動起來非常麻煩；
• 市場機會稍縱即逝，太長的研發周期可能會錯過一些機會。

我們需要聚焦在用戶的主線業務、主要需求，以及公司希望在這個場景上希望做出的創新點、優勢上，不要陷入什么需求都可以滿足的陷阱中，在資源有限的情況下我們需要做出取舍。

在上圖中我列出了司法鑒定的通用流程，我將其作為最小可行產品的業務流程。

司法鑒定過程中不同人需求不同。

比如主管部門能夠實時了解管轄范圍內鑒定機構鑒定情況、鑒定人希望能夠通過系統減少重復操作、收案登記員希望能夠更快更好地完成歸檔認為等等。

且整個司法鑒定流程中所涉及的操作、文書附件不計其數。

但部分操作和文書在實際業務過程中使用到的次數較小，所以在最開始梳理業務流程的時候，我選擇性的忽略。

其次由于在這個行業已經有類似競品，我通過使用分析后，了解到他們更多地將系統聚焦在日常的鑒定過程中。

而近年來隨著司法行業大整頓，各大司法機構需要進行重新評審，評審的內容主要是對鑒定文書等資料進行檢查、考核，對平日里對文書不重視的機構，面對這樣嚴格的評審往往會出現應接不暇的情況，可能會被停業整頓，甚至吊銷執照。

所以我們在解決通用業務流程的基礎上，將系統進一步聚焦在“文書評查”板塊，也作為我們產品的一大亮點。

最后如果在業務聚焦時團隊內部舉棋不定，可以選擇最簡單的方式，選擇優先聚焦在“買單用戶”的需求上進行設計實現。

類似釘釘的“買單用戶”是老板，實際使用用戶是員工，老板最大的需求就是能夠實時監督員工、管理員工，以更高效的方式完成工作，所以也才有了釘釘最開始的版本。

三、主線流程和角色梳理

在B端業務中，完成一項任務問題需要執行很多操作，但并非所有的操作都是主線業務流程和關鍵節點。

我認為主線業務流程是完成任務的最短路徑，最短路徑中的操作就是關鍵節點，操作是由人完成的，所以關鍵節點上的人就是關鍵角色。

比如司法鑒定的主線流程和節點包括：

前期技術服務（預檢）——>受理審批——>鑒定實施——>文書出具——>鑒定收尾。

其中涉及到的角色包括收案登記員、鑒定助理、司法鑒定、技術負責人，不同的業務流程由不同的角色參與并完成任務。

我們以上我們通過”人+事“的方式，梳理主線流程和關鍵角色是為了大致了解不同角色職責與執行任務順序，進而抽象出業務規則和流程。但這樣的結果還是非常粗曠，不足以作為我們產品涉及的依據，我們需要進一步梳理。

四、業務流程細化

一條主線業務往往會有很多分支任務，這些任務也是完成主線業務的必要條件，所以我們還需要進一步細化主線業務；其次每一次操作必定伴隨著信息的輸入和輸出，所以我們還需搞清楚完成操作的前提條件和產出數據；最后在主線業務流程外，還有很多異常流程也需要我們注意。

比如上圖是對審查受理階段進行了細化，在流程上審查受理又需要分為”收案登記“、”初始審核“、”審批受理“、”辦理手續“四個步驟，同時可以看到我在表格中添加了另外三列，包括輸出文書、必要程度以及備注。上一個操作的輸入作為下一個操作的輸入，每個步驟的邏輯順序是不可改變的；”必要“操作是主線業務的進一步細化，”可能“操作”是異常情況的標注。備注里是一些補充說明。

以這樣的方式我們就把復雜的業務通過“時間順序”對應”事“，”事“對應”人“，”人“對應”操作“、”操作“對應”輸出“的邏輯梳理出來，這樣能夠更加清晰把握業務脈絡。

五、產品功能架構設計

產品功能架構是對業務流程和操作的抽象成功能板塊，主線業務梳理（總）——>業務流程及角色細化（分）——>產品功能框架設計（總），我們距離產品原型設計，就只差一步了。

其實在前面的流程梳理過程中，根據”人+事+邏輯順序“的方式產品框架已經顯露出來了，再加上一個完整業務系統的常見功能就組成了我們的產品框架。

六、結語

業務是單純的，其本質就是為解決問題，但人往往是復雜的，在不了解事情本質的情況下容易將簡單問題復雜化。

產品經理是否厲害不在于把系統設計得多么復雜、多么高大上，而在于能夠以最簡單的方式解決用戶需求。

大道至簡，繁在人心。

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

題圖來自 Pexels，基于CC0協議。