在大型 ERP 專案開發時，有多個子團隊，每個子團隊有多位工程師。昨日和某個子團隊的專案經理聊天時，我強調專人負責各層開發的重要，也就是 DB、Business、UI 各有不同工程師負責，橫向分割工作，而不是一個工程師負責一個功能，DB、Business 和 UI 通通一個人包了，變成直向分割，其要點如下：
每個工程師熟悉的技術不同，UI 需要 Ajax、Web、ASP.NET，中間層熟 Web Service、Domain Know How、DB 層熟 T-SQL 與資料庫物件撰寫。讓每個人專精自己的技術，但不必學其他用不到的技術。
一層由一個人或一群人負責，可避免重複開發。因為若我寫 UI，call 我寫的 Business service，再 call 自己寫的預存程序，其間一定會藏有許多自己開發上便宜行事的作法，但不利於別人呼叫。因此兩個人有功能近似的需求時，會自己寫自己用的 Service 或 Stored Procedure，而不去嘗試重複使用別人已經開發的。因為找別人開發過的近似功能很麻煩，且若不合用，對方也不見得會幫我改。到最後，DB 內一大堆近似的預存程序、檢視、函數，中間層服務有一大堆近似的類別、方法。若商業邏輯層或資料庫層都是專人寫，則該人可以防止重複開發。
各團隊模組間，其商業邏輯或開發技術的交流較為單純，比較能有跨團隊的橫向溝通，而不會彼此功能牴觸卻不知道。
每一層呼叫另一層時，就在建立標準與除錯，因為某甲呼叫某乙寫的服務時，就會要求標準化，並替商業邏輯除錯，而非某乙任意寫作。以後在模組間互相呼叫時才有可能。
若個人開發各自功能，好像找一群人來建房子，甲負責廚房、乙負責浴室、丙負責客廳、丁負責臥室…結果每個人都砌了牆、開了門…但彼此的門對不太上，從客廳要進臥室時，一開門就撞牆了，因為兩個門沒有標準。我們應該要甲負責整地、乙負責砌磚、丙負責水電、丁負責裝潢…等等。
該專案經理反問，這樣不好管，團隊的默契也難以養成。以往哪項功能沒寫出來，盯那個人即可，現在某甲說某乙沒寫，某乙說某丙沒寫。我建議是應該形成團隊壓力，讓大家知道團隊進度是卡在哪層的服務，在等哪個人。
而團隊開發默契本來就是需要時間培養，分層負責開發初期的確較為混亂，不容易立刻讓高手一下子就做好單支從頭到尾可測試的功能，但長期而言，分工才能培養專精人才，有了合作默契與慣例後就不會混亂。
專案經理也強調組織的配置是工程師 Pool，所以隨時調配任一工程師可獨立完成整個功能。我的建議是變成多個專業人才 Pool，就這個例子而言，是劃分成 UI、AP Service、DB Pro 三個 Pool，若哪個子團隊缺哪層的工程師，就由專業 Pool 調配。
最後，他雖然沒有接受我的建議，但有溝通總是好的。開發模式與文化的轉變比導入新產品和技術還難。