中台系統，業務流程

事項梳理過程

1 一個比較大的系統到底是怎樣從使用者（甲方）提出需求，到受理方進行需求的拆解，梳理和與使用者進行需求确認，溝通然後跟蹤，進入開發階段。

2 系統太大牽扯到的原型就是了解不清了：使用者需求确認時需要做原型，每一個版本需要進行疊代，一個開發的完成流程可能會拆解為幾部分。

3 那就先說一下為什麼需要做一個中台系統?

中台系統其實就是起一個轉接的作用。做一個比較：

如果不做中台系統：

按照之前學習的開發模型，瀑布或者是靈活之類的，我們需要去梳理需求，流程，程式員需要梳理代碼，也别是比較複雜的業務設計需要大量的時間進行了解，很是浪費時間。

如果有中台系統：

中台系統有可能隻會在特定的企業使用。舉個例子；一個公司不管是出于某種目的需要做一個餐廳管理系統A，暫且這樣命名；之後又需要做一個餐廳管理系統B或者是更多的餐廳管理系統，但是他們在某些業務方面或者是技術實作方面是相似的，也就是說如果是完全分開做這些東西會多耗費大量的時間，那麼就會有比較niu的某些人幹脆做一個平台系統，能夠支撐其他開發人員進行業務系統的開發，這個平台就是中台系統。用技術人員的話說就是能夠按照開發人員的需求進行自主配置使用者的需求，然後自動生成一個餐廳管理系統。

心得體會

從背景開發人員轉到梳理人員我認為其實就是一個從程式員轉到需求分析的角色，這也解決了我很多問題。

1 上學期間老師為什麼頻繁讓我修改界面，雖然他和功能并沒有太大關系。（從一個不是很懂得使用者觸發，無外乎功能和美觀，深入就是使用者體驗）

2 為什麼有些東西就是無法跟别人解釋的通？可能這就是科班出身的優勢：1 有的時候一個名詞需要解釋很久。 2 程式員或者是開發者不關系業務怎樣，直接了當的說你想要怎樣的功能，說了一堆真的不了解。

3雖然這段時間并沒有學習技術問題，不僅是公司的需要吧，自己也是從另一個角度了解了開發。