東東推薦：上次后臺設計第一篇文章閱讀量非常高，證明關于后臺設計的文章比較稀缺。干貨繼續來，這是作者的關于后臺設計的第二篇文章，各位看官請笑納。

兩個月下來，第一期的聯運后臺項目也接近了尾聲。趁著這段驗收的時間，溫故而知新，重新出發，看看之前處理不當埋下的坑，以防再次踩坑。

（1）序列圖，主要是關注系統角色之前的交互，關注業務流的整體，可以讓其他人員快速的獲知整體工作流，同時也可以為后臺的角色權限做參考

（2）序列圖由于沒有涉及到細化的分支流程，這樣在前期討論可以讓人們更加關注在主流程本身，而不會陷入在一個異常分支流程中不可自拔，其次返工也是夠快（原諒我是個懶癌，哈哈）

（3）但是，在產出序列圖的時候，更好是對分支流程有所考慮后再進行產出，這樣在后面進行流程圖的產出時，也可以避免考慮不足導致的流程變更

2、流程圖

（1）流程圖，對比序列圖，更加關注的是后臺本身的細分流程，因為流程圖的產出往往是針對開發階段，需要對不同的狀態、不同異常情況進行說明

（2）在進行流程圖的產出時，可以先將部分通用流程統一成一個頁面，然后設定標注規范來處理，其次，將不同業務模塊的流程放在不同的頁面去描述，如果業務模塊間會有交互流程，可以放在通用流程中去描述（業務流程圖的產出是一門學問，可以從軟件設計類的書籍中去了解，最近我也在翻閱類似的書籍~~）

讓團隊理解業務

后臺類產品，往往都是業務驅動類的產品。這樣會導致團隊對于需求的理解上存在一定的難度，在立項會議上，如果沒有將產品的業務流很好的傳遞下去，最終的產品也許無法很好的滿足業務需求。

小結：要解決這個問題，往往是需要產品負責人和項目經理（有些團隊，產品經理也是項目經理）付出一些努力的：

1、立項：立項會議上，先說清楚業務流是怎樣，與團隊在業務方面得到一定的統一，然后再通過業務流進行細分，把需求進行代入其中，而不是將立項會議草草帶過

2、產品與開發過需求前，先把業務說清楚，再說需求，再講解詳細功能點

3、進度會議：在進度會議上，產品要對當前的Demo進行核對，保證方向的正確性，而不只是對當前的進度進行闡述

需求實現程度的把控

需求與實現，理想狀態就是需求文檔的像素級實現。但實際上呢？往往都是需要產品和開發不斷的思維碰撞、文檔不斷的修改，產品出來往往與原需求是有一定差距的。這個對于后臺產品來說，更加如此，這個就需要在驗收時去把控好需求實現的程度。

對于這個問題，如果從最根源的出發，就是與開發過完需求后，盡快的從開發口出得到反饋。不對，很多人可能會覺得這扯遠了。但是，這其實才是保證需求實現的最好方法，就是在一開始就與開發在需求實現上達到一致，這樣開發在設計數據庫時，將能夠把你需要的字段都設計好，防止提測版本與需求差距較大的情況。

對著文檔操作一遍

后臺產品往往都是在Web端去實現的，相對于APP端產品能夠放在手機上去進行實際操作來說，是很抽象的一種存在。之前在產出文檔后，往往是根據產品結構圖對于不同功能點的邏輯進行梳理，覺得沒有問題就收工了。后來發現，這樣的做法還是不夠的，這樣的處理方式往往只是解決了產品的實用性功能。

較好的做法，就是產出文檔后，對著文檔的不同功能點，在腦海中模擬操作一遍，看看這樣的邏輯會對其他功能點產生什么聯系，這樣的邏輯處理對于用戶來說真的夠用了嗎？反復的思考后，覺得沒有問題，這樣產出的文檔會更好。

本文作者：@Yoic；來源：簡書