怎麼管

在大型 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 調配。

最後,他雖然沒有接受我的建議,但有溝通總是好的。開發模式與文化的轉變比導入新產品和技術還難。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: