談系統開發的分工
SA, SD,SE及DBA, 基本上都是從系統開發工作裡逐漸分工出來的專業職務, 換句話說, 這些工作在過去都是程式師在做。當然, 即使是現在, 還是有很多系統的開發, 是由程式師來完成的, 尤其是一些並不複雜的系統開發, 或簡單修正。
對於一個人或少數幾個人就能做好的工作, 我想並不需要我去把簡單的事情搞的複雜化。我們的焦點還是放在較為複雜, 要求較高的系統上, 也就是需要一個完整團隊去開發的系統。
我誠懇的建議擁有完整團隊, 或是常要用專案來進行開發的組織及部門, 盡早去做好專業分工的工作。這建議的意思是現在的系統開發, 要做的好, 已經不能再認為程式師可以兼任SA, SD或是SE, 然後就機動調配來調配去的。
開發團隊的領導者要盡快的在開發工程師中, 選取適合的人, 開始要求他們專注在各自的領域裡, 做深入的研究和發展。而編程, 將只會是他們在不得已的情況下要去做的事。
這裡所謂的選取合適, 並不是指找比較聰明或是表現優異的, 相反的, 可能還是程式師裡面表現的比較差的, 詳細的條件, 可以看我前一篇文章, 這樣應該有助於部門主管挑選人才。
為什麼要這麼做 ?
因為系統開發工作已經變成了複雜無比的事, 愈是要成員樣樣通, 你的專案就成本愈高, 而且成果難以讓使用者接受。系統開發, 已經成為了另一種生產工作, 以工廠管理的比喻, 就是要開始了流水線生產的概念, 把一整個生產過程拆成合適的小流程, 然後各個流程再組合起來, 就變成了產品, 這樣的好處就是訓練成本下降, 產品品質容易控制, 而且生產速度會更快。
生產方法為什麼要變成這樣 ?
當然是因為需求量大, 傳統的一個師傅帶幾個徒弟的作坊式生產法難以應付了, 才會有了流水線式的工廠生產法了。
系統開發現在也變成了如此。
一個公司裡面的資訊系統需求量其實是很大的。如果要完整的E化, 以現在市場上的產品來看, 雖然貌似完整, 但在實務上卻難以買來即用, 或多或少都要做一些改變或是調整。甚至在一些較為特殊的領域裡, 連現成的產品都沒有, 那更是要動用到系統開發團隊。
即使如此, 隨著資訊化的普及, 大量的使用者已經具備了相當的IT常識, 因此對系統的要求也會日益增高, 系統的強化, 改寫, 甚至是重寫, 也是司空見慣的事。這麼大量的要求下, 公司裡的MIS部門或是專業的外包公司卻難堪的發現, 預算和資源並不會因此而增加, 系統購買及開發, 永遠都被歸類到節流類事務。
在多少IT前輩的努力及奮鬥下, 已經證明了要改變管理層的想法, 要把系統開發從節流類翻身到開源類, 那是屬於登陸火星級的任務, 想想可以, 但現實上就是不行。所以, 回到問題點, 既然預算和資源不會增加, 那就只好降低消耗, 增加生產力了。
基本上, SA, SD及SE的產生, 在一開始, 並不是因應這種需要而來的, 這些專業只是為了方便團隊運作時, 職務上的一種名稱和分工而已, 和我前面談的強化系統開發效率及品質沒有半點關係。
但如今, 這些職務的運用, 已不再只是單純的團隊分工而已了, MIS及軟體開發承包公司應該要深思如何把程式開發導入成為流水線式的開發, 讓開發專案變成一個標準程序, 每一個程序由一個專業分工團隊來做, 然後移交到下一個團隊, 再承接新的系統, 週而復始。
聽起來有點理想化是嗎 ? 但如果說, CMMI能夠落實的單位, 就做得到, 那你還會覺得理想化嗎 ?
當然, 用CMMI來要求, 很多單位是受不了的, 我也覺得只是要讓系統開發分工化, 並不需要這麼麻煩, 一般來說, 只要做到下列數點, 那也能達成前面所提的目標了。
- 建立標準方法, 如客製化開發流程或套裝軟體導入流程
- 使用標準的溝通的工具及流程, 如統一使用UML, 流程中的每一個步驟產出都有標準文件LIST及樣板
- 職務或組織專業分工明確
不多是嗎 ? 但要落實卻不是一天一月的功夫。
首先建立標準方法, 就很不易了。我看過很多PM, 對一些方法論十分不屑, 認為那些都只是一種理論, 拿來寫報告唬人用的。(關於導入方法論, 請自行參考相關文件, 但建議要找近期的, 導入方法不太好找, 但可以在一些知名的IT顧問公司的文件裡找到, 如ACCENTURE, IBM, SAP, ...)
但真的是這樣嗎 ?
當然不是真的。以我多年專案經驗, 我很客觀的說, 除非這個方法論本身有問題, 否則依照方法論去做, 是最好的選擇。嫌方法論麻煩, 覺得過於瑣碎而任意從權的, 通常沒有什麼好下場….(怎麼聽起來好像防治犯罪警語)
方法論裡的東西, 的確是很完整, 要求很細緻的, 但在PM還不能完全熟悉或掌握以前, 還是盡量依方法論的要求去做吧, 雖然會讓你每天頂著熊貓眼, 也會讓你每天被專案成員釘小木人, 但這個經歷是十分值得的, 因為這是未來美好日子的開始, 不只你要被訓練, 連專案成員也要接受磨練的。
完成了這一個階段, 接下來, 就可以為各個階段建立標準的作業流程(SOP)及輸入輸出規範了。
基本上方法論裡, 大多數都只是會標明出該階段裡要達成什麼目標, 但要如何達成及如何與其它單位協調運作, 是不會有什麼說明的。這是因為方法論是一個邏輯上的概念, 而且是泛用的, 但要實作這個方法論, 是要PM及其成員因各自的條件去運用的。之所以要開發單位先去運用方法論, 其實也是為第二階段做一個準備, 這樣才能在第二階段裡產生出正確而且合宜的SOP及文件。
在這個階段裡, 每一個工作都會被定義下來, 每一個流程都有其遵循依據, 而且產出的文件也都有明確的意義及內容和表達方法, 開發流程的標準化, 幾乎都已經完備了。
但不要忘了, 徒法不足以自行, 再良好的流程設計, 都要人來執行的, 當前述的基礎工作完成後, 就要落實在組織上了。也就是最後一步。
這一階段執行時, 主要的工作也就是把相關的職務予以正式化, 比如有SA TEAM, SD TEAM, SE TEAM, 而且明定好各個TEAM的主管, 專業及職掌, 還有PM調用的程序。專業職等的分野, 未來的生涯的規劃等。
現有公司的MIS部門分組或分工法, 基本上是難以應付現在使用者的要求的。很多的MIS主管不斷的在抱怨使用者過於挑剔, 給予的資源不夠, 但卻少有人會去思考組織是不是已經相應的調整, 以適合這樣的環境。
在此, 僅提供個人一得之愚, 希望對一些MIS管理主管或是軟體開發公司有所幫助。
Tools 
Help
