后臺設計(二):聯運后臺項目小結
東東推薦:上次后臺設計第一篇文章閱讀量非常高,證明關于后臺設計的文章比較稀缺。干貨繼續來,這是作者的關于后臺設計的第二篇文章,各位看官請笑納。
兩個月下來,第一期的聯運后臺項目也接近了尾聲。趁著這段驗收的時間,溫故而知新,重新出發,看看之前處理不當埋下的坑,以防再次踩坑。 這個名詞也許對于大多數的產品經理來說,是很少接觸的一個名詞。在接觸后臺產品之前,一直做的是工具類的應用,架構不算復雜,而且模塊劃分清晰,開發、設計、運營日常都會使用,對其中的一些產品術語會有所了解,因此,在日常的溝通上沒有專門的術語表(or項目詞典),都不會有太大問題。 但是,這次的后臺項目,一是聯運后臺是業務導向的產品,除了產品,其他人其實對于聯運后臺的相關詞匯及業務了解不多,二是聯運后臺,往往是多個后臺同時進行開發,涉及的人員跨團隊、跨部門。由于以上兩個原因,在項目一開始的時候,沒有及時的產出術語表,出現了 開發閱讀文檔時對需求產生錯誤的認知、測試在進行測試用例的撰寫時產生了對業務的疑惑等問題,無形中增加了溝通成本。 小結:從上述可得,術語表其實不僅僅是提供團隊溝通效率的工具,在針對業務類型的產品,術語表還可以充當業務說明的角色。因為術語表中往往會涉獵到業務上的專業名詞,在這種時候,可以將相關的業務進行說明,降低溝通成本,將業務需求更好的傳遞下去。 從之前的小結中,我也提到了業務流程圖是作為工作流設計的基礎。經過這次項目后,發現業務流程圖其實還可以細分為 序列圖、流程圖: 1、序列圖 (1)序列圖,主要是關注系統角色之前的交互,關注業務流的整體,可以讓其他人員快速的獲知整體工作流,同時也可以為后臺的角色權限做參考 (2)序列圖由于沒有涉及到細化的分支流程,這樣在前期討論可以讓人們更加關注在主流程本身,而不會陷入在一個異常分支流程中不可自拔,其次返工也是夠快(原諒我是個懶癌,哈哈) (3)但是,在產出序列圖的時候,更好是對分支流程有所考慮后再進行產出,這樣在后面進行流程圖的產出時,也可以避免考慮不足導致的流程變更 2、流程圖 (1)流程圖,對比序列圖,更加關注的是后臺本身的細分流程,因為流程圖的產出往往是針對開發階段,需要對不同的狀態、不同異常情況進行說明 (2)在進行流程圖的產出時,可以先將部分通用流程統一成一個頁面,然后設定標注規范來處理,其次,將不同業務模塊的流程放在不同的頁面去描述,如果業務模塊間會有交互流程,可以放在通用流程中去描述(業務流程圖的產出是一門學問,可以從軟件設計類的書籍中去了解,最近我也在翻閱類似的書籍~~) 后臺類產品,往往都是業務驅動類的產品。這樣會導致團隊對于需求的理解上存在一定的難度,在立項會議上,如果沒有將產品的業務流很好的傳遞下去,最終的產品也許無法很好的滿足業務需求。 小結:要解決這個問題,往往是需要產品負責人和項目經理(有些團隊,產品經理也是項目經理)付出一些努力的: 1、立項:立項會議上,先說清楚業務流是怎樣,與團隊在業務方面得到一定的統一,然后再通過業務流進行細分,把需求進行代入其中,而不是將立項會議草草帶過 2、產品與開發過需求前,先把業務說清楚,再說需求,再講解詳細功能點 3、進度會議:在進度會議上,產品要對當前的Demo進行核對,保證方向的正確性,而不只是對當前的進度進行闡述 需求與實現,理想狀態就是需求文檔的像素級實現。但實際上呢?往往都是需要產品和開發不斷的思維碰撞、文檔不斷的修改,產品出來往往與原需求是有一定差距的。這個對于后臺產品來說,更加如此,這個就需要在驗收時去把控好需求實現的程度。 對于這個問題,如果從最根源的出發,就是與開發過完需求后,盡快的從開發口出得到反饋。不對,很多人可能會覺得這扯遠了。但是,這其實才是保證需求實現的最好方法,就是在一開始就與開發在需求實現上達到一致,這樣開發在設計數據庫時,將能夠把你需要的字段都設計好,防止提測版本與需求差距較大的情況。 后臺產品往往都是在Web端去實現的,相對于APP端產品能夠放在手機上去進行實際操作來說,是很抽象的一種存在。之前在產出文檔后,往往是根據產品結構圖對于不同功能點的邏輯進行梳理,覺得沒有問題就收工了。后來發現,這樣的做法還是不夠的,這樣的處理方式往往只是解決了產品的實用性功能。 較好的做法,就是產出文檔后,對著文檔的不同功能點,在腦海中模擬操作一遍,看看這樣的邏輯會對其他功能點產生什么聯系,這樣的邏輯處理對于用戶來說真的夠用了嗎?反復的思考后,覺得沒有問題,這樣產出的文檔會更好。 本文作者:@Yoic;來源:簡書術語表
業務流程圖的細化
讓團隊理解業務
需求實現程度的把控
對著文檔操作一遍
謝謝,收獲很大