本文由作者 無人知曉?發布于社區

前言

從0到1設計一套系統，是一個產品經理成長的必經之路。在過去幾年中，我積累了很多企業內部業務系統從0-1的經驗，本文重點將其進行抽象總結，并總結那些掉進去的坑和是如何解決的。

01

概述

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

1.創業公司業務不完善或者公司有新業務需要支持時；

2.原有的業務模式基本都為線下手工操作；

3.公司原有系統已經不能支持業務發展，且迭代成本已經比較高時；

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

1.公司內部人效的問題；

2.支持公司業務快速的發展。

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

02

需求調研

在現實中，一般都是領導層決定戰略層，決定做還是不做，而由資深的產品經理來落地執行。一般來說我們通常要做的是找到最優路徑，也就是系統設計。而在找到最優路徑之前，有時候需要完成先了解現在的實際情況（A在哪里），以便產品方案不是空中樓閣。

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

1.跟企業內部用戶進行了解；

2.外部調研；

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

1.系統使用方多的時候，內部調研很容易出現多方說法不一致的情況，此時一定要多方汲取意見，多總結思考找到正確的道路；

2.外部調研的時候，其實不在于系統本身和競品對標，而在于商業模式。我們可以與其它人進行交流，也可以通過一些軟件服務商公開的軟件服務，吸收其設計精髓。

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

坑與爬坑：

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

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

3.業務方前后說法不一致：注意產出業務流程圖，并且一定要與實際操作人確認一下。通常如果是戰略項目，一般可能是與業務領導先溝通，然后指派其它同事進行細節溝通。而這個指派人，很可能并不是實際操作人，而是實際操作人的領導。這個時候，注意要和實際操作人的交流和確認。細節會決定成敗。

03

方案設計

找到了A點，知道了B點在哪里，接下來就是要設計最優路徑。這個環節，考驗的是產品經理的設計能力。這其中最終需要產出的就是原型和prd交付開發。為了我們的設想更好的被理解，其實可以借助這些以下這些內容：

1.功能架構圖

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

如果是一個頁面功能很少，基本都是很多后臺交互，可以用我之前下圖的形式來表達。此圖和流程圖的區別在于省略了很多細節，重點表達哪些系統之間有交互，方便更清晰的了解哪些系統間有交互。（此處案例是我之前做項目的時候畫的，人工將系統名稱和交互說明打了碼）

坑與爬坑：

功能架構圖最好是一個完整的構想，然后將本次做和不做的內容通過顏色區分。方便以后迭代。

2.流程圖

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

坑與爬坑：

1.如果是與外部系統交互時，外部系統已經有現成的接口，可在流程圖里說明說的是哪個接口，否則很可能會用錯接口，或者與最初設想有所偏差。

2.流程圖要足夠細！異常情況要考慮清楚，否則就會在異常里了。

3.功能點列表

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

系統

模塊

功能

功能點

功能點說明

優先級

4.原型

原型要把重點內容進行標注，交互要畫出來，不要都是靜態頁面。

坑與爬坑：有時候后臺的開發人員不太會寫太復雜的頁面交互，大多是用現成的控件。所以非必要的復雜交互可以刪除。

5.prd

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

以上都是工具和表現形式，而通過以上工具和表現形式，最重要的是傳達出自己的設計思想和全部的設計細節。在從0-1的設計中，由于細節太多很可能會有一些細節遺漏，所以我自己做了一份產品走查表，用于審閱自己的設計有沒有缺失，此處大家也可以自己做一份屬于自己的走查表。?

04

項目落地

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

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

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

1.開發評估時間過長：在方案設計環節一定要完成好功能點的拆解，這樣在這個環節會更快的完成功能的省略；

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

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

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

5.（此處省略一萬字）

結語

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

↘好文推薦：

所有人問「貼吧之父」俞軍

產品經理邏輯學通識

干貨?|?產品經理要了解的技術類知識

👇歡迎關注：

點個“在看”吧

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的实战总结：我是怎么从0到1做后台业务系统的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。