如何讓項目成員儘快熟悉系統業務？

01-21

我們是做行業軟體的，業內有種說法是「業務為王」。我們使用的技術大多是較為成熟的技術，網上資料也是一大堆，因此，項目做成功更多是看業務能力。那麼，如果項目組進入一個新人，如何讓他在最短時間內熟悉系統的業務呢？

可以看下我寫過的一篇文章《談對業務系統的切入》，基本是針對你的問題。

在這裡想談下對於一個原來沒有接觸過的新行業的新業務系統切入的方法，當然談這點的時候首先是需要已有有一定的IT行業其它業務系統的工作經驗，包括業務和技術雙方面的積累，那麼在這種情況下如何快速的切入一個新的業務系統，就需要注意相關的方式和方法方面的問題。

粗粒度的全局了解

接觸一個全新的業務系統，首先要搞清楚這個業務系統主要是支撐什麼樣的業務？而對於支撐的業務本身又有兩個核心內容，即核心的業務流程是如何的？核心的業
務對象模型是如何的？在這個了解清楚後可以繼續了解這個業務系統大致會有哪些核心的業務功能模塊，業務模塊之間的相互關係是如何的？已經如何銜接的。

有時候了解到這個層面可能還不夠，你還需要了解這個業務系統可能是支撐端到端業務流程或共享業務數據的一部分，那麼還需要了解到這個業務系統或支撐的業務在端到端流程中所處的位置，該業務系統和上游業務和下游業務的關係，相互間的協同和介面。

業務系統支撐了什麼樣的業務，存儲了哪些核心業務對象和數據，這是對一個業務系統最基礎的全局理解。

動態了解-流程模型

在對業務系統有了一個全局的理解後，需要開始進一步考慮流程模型方面的內容。注意在這裡指的流程模型不是指工作流或人工審批流模型，而是指業務流程模型。或者說了解業務系統本身在分析設計中所涉及到的業務建模方面的內容。

業務建模或業務流程模型的了解需要解決的問題是，一個業務系統為何會存在這些業務模塊，這些業務模塊之間是如何進行協同來支撐業務流程的。任何業務模塊都會有輸入和輸出，了解清楚業務模塊的輸入輸出後就能夠比較清楚業務模塊之間是如何串接和集成來支撐上層的核心業務的。

如果一個業務系統按SOA思想來建設，你可能會看到有哪些上層的核心業務模塊，核心的領域服務層和底層的數據模型層，核心的業務模塊本身是如何調用核心領
域服務來進行協同和銜接的。只有清楚了業務流程才可能理解清楚業務模塊之間的協同和集成關係，否則你看到的是孤立的業務模塊，業務模塊和業務流程之間出現
斷點而無法真正想清楚業務模塊間如何協同來支撐業務的。

如果一個業務系統本身是流程型的業務系統，這些流程又大量是審批流為主，那麼即使審批流定義再複雜，整個業務系統本身也是簡單的，因為不存在上面所說的大量業務模塊間協同情況。

靜態了解-數據模型

對於一個業務系統的複雜往往體現在兩個方面，一個方面是本身業務模塊間的協同和交互複雜，一個是底層的數據模型和關係複雜。在解決了第一個層面的動態分析問題後，就需要開始考慮第二個層面的數據模型了解層面的問題。

任何業務流程，模塊間動態的協同最終都將持久化到資料庫中，成為資料庫中的數據表和數據表之間的關聯依賴關係，映射關係。業務系統前面談到過或者是以流程
為中心的業務系統，或者是以數據為中心的業務系統，對於數據為核心的業務系統必須理解底層的數據模型。這種數據模型的理解首先是要理解元模型結構，這種結
構不是簡單的單個數據對象，而是多個數據對象之間的關聯關係，映射關係，層次關係等。正是由於數據之間有這些關係，而形成了一個複雜的數據網路。

對於數據模型的理解基本可以分為如下幾種，一種是單對象的結構，包括主從，層次等各種結構；然後才是對象和對象之間的關聯依賴結構，如一對多，多對多結構
等。對於較為複雜的業務系統，你可能還會看到為了保證底層數據模型的可擴展性和靈活性，往往在數據模型層會根據面向對象的思路做進一步的抽象，那麼在這種
情況下還必須等將OO的對象模型和面向結構的資料庫模型共同來參考理解，以分析和了解清楚最終數據存儲的方式，數據存儲後最終呈現的方式。

動靜結合-關鍵業務分析

個人理解，對於新切入一個新的業務系統，如果能夠理解到這一步，基本就可以對一個業務系統有一個比較全面的理解和認識。首先是了解業務流程和模塊間協同，
然後是了解數據模型和數據間關係，最後則是真正的根據核心業務來進一步理解在流程協同過程中最終數據的落地存儲。由動態的業務流程驅動的最終靜態數據的存
儲落地和關係的建立。只有這樣流程和數據的分析最終才會融合為一個整體。

對於關鍵業務的分析你會看到，對於這些關鍵業務需要理解清楚究竟涉及到哪些模塊的協同，在模塊的協同過程中最終會產生哪些核心的數據，或者說會更改哪些核
心數據的狀態或數據間的關係。真正你需要關注的往往不是單個數據對象中某些數據熟悉的變更和修改，而更多的是關注核心業務流程驅動下，數據對象狀態的修
改，數據對象間關聯關係的修改，數據間映射模型的調整等。

對於一個完整的業務系統，按道理只要有基本的數據對象維護功能即可，但是要真正能夠支撐業務，你會看到數據對象中的關鍵屬性，關鍵依賴關係的變更，最終都是由上層的業務模塊和流程來支撐的，那麼你就必須要能夠真正的理解所有的核心業務流程最終對底層數據模型造成的影響。

謝邀，我從管理方面回答一下問題，：

當人面對一個陌生的環境時：希望有好的表現；怕犯錯；過度自信；妄自菲薄等多種表現單發或並髮式的存在。怕問，不知道問什麼，不知道從哪裡開始，不知道問誰，怕別人瞧不起，怕承擔責任，沒有時間，一直在重複簡單勞動。

如何營造一個高效的企業知識傳播的工作環境，是管理者一個很重要的職能。

有沒有一個方便的企業知識管理系統，業務知識是不是能很方便的共享，知識管理系統是不是有人維護，並保持同步。

有沒有師徒關係，讓新人有問題的時候知道找誰問。

有沒有一定的工作壓力，讓新人有不斷學習新的業務知識的動力。

有沒有知識分享的激勵機制，讓老手們樂於分享。

有沒有透明機制，讓新人對業務掌握的水平能呈現在所有的團隊成員面前，有沒有定期檢查機制？

有沒有承諾機制，把學習和卓越作為個人對團隊的承諾。

有沒有定期的業務提升活動，用於團隊的知識水平建設，學習與精研不只是新手的事情。

項目團隊卓越的重要支柱就是學習和交流，不單是新人，不同角色與分工之間的，不同水平層次之間的，上下級之間的，不同部門之間的知識傳播效率和質量很大程度上決定了組織的能力。

這個真的需要嗯，嗯，公司剛好進入新人，可以利用這個模型來操作~

個人對於技術人員的培訓經驗：把業務拆分成：領域模型、領域邏輯、約束、動作。並按照這個順序來培訓。