編輯導語：産品經理在日常工作中，經常會遇到從0-1的項目，在面對這類項目時，需要産品經理全程進行執行和落地，所以團隊的協作以及整個流程的把控是非常重要的；本文作者分享了關于怎麼從0-1做後台業務系統，我們一起來了解一下。

從0到1設計一套系統，是一個産品經理成長的必經之路。

在過去幾年中，我積累了很多企業内部業務系統從0-1的經驗，本文重點将其進行抽象總結，并總結那些掉進去的坑和是如何解決的。

一、概述

企業内部系統如果需要從0-1設計，一般是如下場景：

• 創業公司業務不完善或者公司有新業務需要支持時；
• 原有的業務模式基本都為線下手工操作；
• 公司原有系統已經不能支持業務發展，且叠代成本已經比較高時；

而我們要解決的問題一般在于：

而想要做到以上兩點，其實和用戶側從0-1的本質沒有區别。但是在各個環節還是有所差異，接下來進行細節的介紹。

二、需求調研

在現實中，一般都是領導層決定戰略層，決定做還是不做，而由資深的産品經理來落地執行。

一般來說我們通常要做的是找到最優路徑，也就是系統設計；而在找到最優路徑之前，有時候需要完成先了解現在的實際情況（A在哪裡），以便産品方案不是空中樓閣。

無論是起點還是最優路徑，重點在于要了解業務流程。我們有兩個途徑：

而這兩個途徑都有其困難點：

• 系統使用方多的時候，内部調研很容易出現多方說法不一緻的情況，此時一定要多方汲取意見，多總結思考找到正确的道路；
• 外部調研的時候，其實不在于系統本身和競品對标，而在于商業模式。我們可以與其它人進行交流，也可以通過一些軟件服務商公開的軟件服務，吸收其設計精髓。

完成以上調研後，關鍵需要産出業務流程圖。如果比較複雜，可以用泳道圖，如果流程比較簡單，可以直接用ppt表達即可。

坑與爬坑：

1）業務方口徑不一緻：多聽多想多總結，并且與多方說清楚；

2）全新系統完全沒想法：拆解其它家系統理解其設計思路并找到優缺點。

3）業務方前後說法不一緻：注意産出業務流程圖，并且一定要與實際操作人确認一下。

通常如果是戰略項目，一般可能是與業務領導先溝通，然後指派其它同事進行細節溝通。而這個指派人，很可能并不是實際操作人，而是實際操作人的領導；這個時候，注意要和實際操作人的交流和确認（細節會決定成敗）。

三、方案設計

找到了A點，知道了B點在哪裡，接下來就是要設計最優路徑，這個環節，考驗的是産品經理的設計能力，這其中最終需要産出的就是原型和prd交付開發。

為了我們的設想更好的被理解，其實可以借助這些以下這些内容：

1. 功能架構圖

功能架構圖，可以很好的幫助大家理解系統都包含哪些功能模塊，和哪些系統可能有交互；如果是一個工具型項目，可以采用我之前我畫過的發票系統的案例。

如果是一個頁面功能很少，基本都是很多後台交互，可以用我之前下圖的形式來表達。

此圖和流程圖的區别在于省略了很多細節，重點表達哪些系統之間有交互，方便更清晰的了解哪些系統間有交互（此處案例是我之前做項目的時候畫的，人工将系統名稱和交互說明打了碼。）

坑與爬坑：

功能架構圖最好是一個完整的構想，然後将本次做和不做的内容通過顔色區分，方便以後叠代。

2. 流程圖

流程圖常見的就是泳道圖。但是有時候用泳道圖表達感覺比較重的時候，其實也可以用時序圖來表達；此處在網上随便找了個時序圖，感興趣同事可以自行去查看。

坑與爬坑：

• 如果是與外部系統交互時，外部系統已經有現成的接口，可在流程圖裡說明說的是哪個接口，否則很可能會用錯接口，或者與最初設想有所偏差。
• 流程圖要足夠細！異常情況要考慮清楚，否則就會在異常裡了。

3. 功能點列表

如果系統細節太多，一定要有功能點列表，此處不止方便下遊同事理解，也方便自己查看設計疏漏。

系統模塊功能功能點功能點說明優先級

4. 原型

原型要把重點内容進行标注，交互要畫出來，不要都是靜态頁面。

坑與爬坑：

有時候後台的開發人員不太會寫太複雜的頁面交互，大多是用現成的控件。所以非必要的複雜交互可以删除。

5. prd

有些觀點認為在原型上的标注能夠代替prd,但我認為還是值得花時間去認真寫；此處将幫助自己再次檢驗在有限的時間裡自己的方案還有沒有疏漏，而且是交付下遊的重要憑證。

以上都是工具和表現形式，而通過以上工具和表現形式，最重要的是傳達出自己的設計思想和全部的設計細節。

在從0-1的設計中，由于細節太多很可能會有一些細節遺漏，所以我自己做了一份産品走查表，用于審閱自己的設計有沒有缺失，此處大家也可以自己做一份屬于自己的走查表。

四、項目落地

從0-1的系統設計，找到了最優路徑隻是萬裡長征的第一步，接下來的落地過程才是一腦門官司。前面的設計做的越完善，在落地過程中就會越少問題。

此環節如果想要更順利，我的經驗是需要和開發負責人配合緊密，更大的去促使開發負責人的發揮能動性。而為了我們的設想能更好的落地，産品經理最好不要當甩手掌櫃，越深的參與越能讓系統的實現和自己的設想偏差越小。

相信大家在這個環節都被遇到過很多坑，不一一言表，此處說幾個重要的地方怎麼避免：

1）開發評估時間過長

在方案設計環節一定要完成好功能點的拆解，這樣在這個環節會更快的完成功能的省略。

2）在開發過程中加人

此項是項目管理中應該避免的，但是有些時候為了趕工期确實會存在這樣的情況。這個時候産品經理最好主動給新進入人員講解背景和需求，不然此處會是一個出現問題的點。

3）開發過程中發現産品細節疏漏：挺起胸膛，這是産品争取但是不能完全避免的，所以發現記得加，在修改的地方标注上改動和日期。如果影響了工期，記得要評估好為什麼會影響，看是不是确定一定要影響。

4）驗收環節發現系統實現與設計偏差過大：這個環節再發現就搞不赢了，一定要在前期開發設計的時候參與開發方案的評審，以及在測試初期看一下開發實現，避免出現這個情況。

五、結語

業務系統的設計最重要的是符合并引導公司内部運營需要，能節省業務操作，并且能支持業務擴展；所以系統設計更多的需要我們理解商業模式和業務模式，依靠我們的邏輯思維能力，找到屬于我們的最優路徑。

本文由 @舉個栗子 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

,

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

查看全部