怎樣将一個之前未接觸過的新業務，轉化為研發可以具體開發的詳細産品方案呢？本文作者對此進行了分析，一起來看一下吧。

一、構建業務模型

怎麼樣将一個idea，商業模式拆解為業務模型，這個在之前的文章中已經有詳細的說明，可以點擊看相關文章：

總體思路是：

1）有一個ideal之後，運用商業運作模型（商業畫布，商業模式運作圖，價值鍊分析）、業務運作模型、财務運作模型能夠将以一個項目的各方面做一個整體的評估；

2）我們進一步運用業務模型的拆解方法，可以拆分出這個事情的核心業務及支撐系統，明白這個事情是如何運作的，關鍵節點是哪些，并據此搭建一個整體性的産品概覽。

但這個産品框架是一個比較粗略的方案，比如之前其它文章畫的同城配送系統的産品整體概覽（已經做過這個系統，然後來寫這篇文章，帶有天然的理解在裡面）。

那怎樣将一個之前未接觸過的新業務轉化為研發可以具體開發的詳細産品方案呢，這其實不是一件簡單的事情，特别是針對複雜系統，平台類産品的時候。

本文不涉及戰略層面的東西，這部分在之前的業務模型拆解中有涉及一部分，另外怎麼樣去找到一個好的需求點，并評估是否可行也不涉及。

我們将文章限定範圍為：産品方向已經确定，業務模式等已确定，我們隻需要把這個業務調研清楚，做産品拆解。這樣将讓我們的精力集中于業務向産品詳細方案的轉化，業務方向一定要确定，然後才去啟動正式的産品詳細方案設計工作，要不然産品方案會無止境地變化，無謂地增加各種成本和打擊團隊的士氣。

二、業務轉化為産品的難點

業務是依托于用戶存在的，這個用戶可能是購買商品的客戶，也可能是公司内部的管理運營人員。

業務就是由用戶發起并執行後有一個結果的活動，這個活動可能是由系統執行，可能由其他人完成，也可能人與系統配合完成。

互聯網和信息技術出現之前，業務基本都是在線下進行，現在越來越多業務實現線上化，有些業務整體都是線上（比如抖音、微信、資訊），O2O業務，傳統行業，制造業等行業還有很多業務是在線下。

無論是怎樣的業務，我們大多以用戶為中心進行設計産品，産品在滿足用戶需求同時，還要讓用戶在使用過程中感到足夠方便和舒适。但另一個方面，滿足用戶的需求不僅僅隻是跟用戶打交道，還面臨着其他一切為滿足用戶需求而提供服務的人員和企業，對于這些衍生需求，也是需要滿足。

這項工作面臨着很多挑戰：

1）沒考慮到非用戶接觸的内部業務産品設計：以用戶為中心的設計，從用戶角度出發的，目标是要讓用戶的體驗好，但可能忽略一些基礎支撐性的業務如何設計。

2）沒考慮業務流程設計：一項業務需要設計流程。比如，一個訂單需要設計用戶下單、确認發貨、物流送貨和用戶簽收等流程。但以用戶為中心的設計，對流程強調得并不多，更多地強調了頁面設計和簡單的交互設計。

3）遺漏大量邏輯：當系統複雜度很大的時候，隻使用流程進行考慮将會很複雜，這将導緻會遺漏很多邏輯，特别是多系統之間的交互。

4）缺乏系統性：平台類型的業務産品設計，需要考慮到各系統之間的交互，比如平台類型的訂單，會涉及用戶、商戶、平台，一筆訂單中由包含商品、優惠、快遞、支付、退款等。很容易對系統考慮不全，導緻架構存在問題。

5）未考慮系統的延展性：隻關注當時當下的問題，沒有考慮到業務發展之後，産品需要怎麼來支持，使得産品系統随着業務發展而需要不斷的重構。

6）如果有多人協作同一個系統，很容易由于各自的設計思路不一緻，繪制原型标準不一緻而造成各自閉門造車而最終組裝不上的問題。

那需要怎麼來應對這些問題呢：

1）梳理流程的時候，采取端到端的方法——也即是從一個活動的開始直到最終結果的整個過程，形成閉環，可以跨越多端（用戶端、商家端、平台管理端）、多部門、多操作者，打破産品系統的隔閡和封閉。

2）采用統一的語言體系和标準（如UML，各端口原型及設計标準統一），保證各方的底層設計邏輯、标準、語言統一，這樣設計出的東西才統一。

3）從面向過程的設計轉為面向對象的設計，應對複雜性、平台型項目設計，更系統全面的考慮問題，就需要把UML，DDD思想運用到從業務到産品設計的過程中，讓整個的過程更系統絲滑，實現面向對象，模塊化、模型化的産品設計。

三、以業務為中心的設計

1. 整體思路

下圖為用戶體驗要素的5層框架結構：

1. 戰略層——确定商業目标，産品目标，用戶群體，怎麼賺錢等
2. 範圍層——為産品功能劃定範圍，做哪些功能
3. 結構層——思考産品怎麼做，包括怎麼跟用戶交互，怎麼組織内容（信息架構）
4. 框架層——思考産品怎麼設計，界面設計，導航設計，信息設計
5. 表現層——風格統一，色彩搭配，排版，利用用戶的視覺，聽覺，觸覺，味覺來刺激用戶

普通産品經理做得就是範圍層，結構層，框架層的東西，表現層一般是UI設計師來。

範圍層對應搭産品的框架（功能框架、非功能框架）；

結構層對應做細節（業務流程、業務操作、信息結構）；

框架層對應畫界面（交互設計及更詳細的信息設計，信息設計來源于信息結構），可以表示為如下圖所示：

2. 産品常用的UML圖

我們學習的英語、漢語可以被稱為語言，這個是顯而易見的。我們學習的各種數學符号，也是一種語言，叫數學語言。

怎麼理解數學符号也是一種語言呢？比如，我們可以用漢語說“一加一等于二”，但是在實際做計算的時候，我們還是習慣用“1 1=2”來表達。

兩者的意思是相同的，但用數字表達更高效、更簡潔。

統一建模語言也是語言，該語言可以代替我們的文字描述來表達一項業務，可以對業務進行抽象建模。

建模是對事物的一種抽象表述，其目的是簡化現實。也就是将紛繁複雜的業務，進行抽象，讓業務更清晰，系統的進行呈現，便于理解。通過建模的方式，我們進一步将業務轉化為産品方案。

語言都有語法（使用規則），如英語、漢語等都有語法。數學符号也有語法，如規定加、減、乘、除和括号的用法。UML既然也是語言，那麼就有相應的語法，如規定流程圖的開始和結束怎麼畫、判斷條件怎麼畫等。

在所有的UML圖中，産品經理需要掌握的是用例圖、流程圖、狀态圖、類圖這四種圖。

挑選一個适合的繪制UML圖的工具，将有助于提高工作效率，并展現出專業度。

Microsoft Visio、ProcessOn、億圖圖示等軟件都能繪制UML圖。使用Axure RP軟件既能繪制原型圖，又能繪制UML圖，不用再将UML圖進行轉移。用Axure RP軟件繪制UML圖能節省時間，建議使用該軟件繪制UML圖。

下一篇将介紹具體怎樣将業務轉化為産品的做法。

專欄作家

Markzou，8年産品經驗，人人都是産品經理專欄作家。主要專注于本地生活、O2O、到家服務、新零售領域；曾任職于多家本地生活垂直領域頭部公司，具有豐富的本地生活行業經驗。

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

題圖來自 Unsplash，基于 CC0 協議

該文觀點僅代表作者本人，人人都是産品經理平台僅提供信息存儲空間服務。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部