軟體開發的「已病」和「未病」 - 通達人驛站
2010/8/9

軟體開發的「已病」和「未病」

這一篇文章是我投稿到ZDNet的《軟體開發專案 最怕錯估情勢》一文的原稿。

--東漢.扁鵲 《黃帝八十一難經-七十七難》上說:經言上工治未病,中工治已病者,何謂也?然。所謂治未病者,見肝之病,則知肝當傳之與脾,故先實其脾氣,無令得受肝之邪,故曰治未病焉。中工治已病者,見肝之病,不曉相傳,但一心治肝,故曰治已病也。
中醫理論中肝膽屬木,脾胃屬土,木剋土,當肝膽發生病症時,和脾胃也會有一定的關係。上等的醫生不直接去治肝而是先顧脾胃,不讓脾胃受肝膽牽連,所以稱為治未病;但中等的醫生,不知道肝膽和脾胃互相連結的道理,一昧的治肝,所以稱為治已發生的病症。

常見的專案情況


在過去幾年,筆者有幸以SQA的角色參與數個軟體開發專案。只是通常筆者進入的時機是專案已經如火如荼地「發散」到某種狀態、或是到了快要結案卻又尾大不掉、無法如期結案的時候。

但既然被稱作「專案」,自然有其先天資源、時程、成本上的限制,筆者只能在了解這些問題的前因後果後,將有限的資源瞄準主要的目標,提出立即執行、立刻見效的「治已病」手法,期望能為專案止血。

當筆者累積了夠多的經驗,想要從「中工」升級到「上工」時,筆者卻發現「高估」和 「低估」才是整個專案發散的罪魁禍首。

在進一步討論之前,筆者們先討論另一個組織要把工作完成需要的三個部份:專業能力、流程系統、管理模式。

組織的運作


專業能力會隨著專業領域的不同而不同,也會隨著不同的員工而有所差異;每間公司都有各自跨部門的流程/系統,以有效的動員組織成員,用經濟的方式解決問題;接著,組織要靠管理系統讓這些問題都能有效率地在要求的時間、達成要求的品質。

台灣的公司普遍對人員的要求比重,大約是:專業能力70-80%、流程系統10-15%、管理模式5-10%。換句話說,是比較重視個人的專業表現,相對比較不重視個人在流程系統、管理模式上的表現。所以時常會發現作了很久的RD,只要專業能力的表現不差,通常能升上主管職。

而有制度的的公司,會對加強人員對流程系統、管理模式要求的比重,大約是:專業能力40-50%、流程系統20-30%、管理模式20-30%,而不只是要求專業能力。

因為人才會流動,如果能留下有效率的系統和管理模式,只要選對的人,就能完成要求的事,而且最後變動的輻度會在可接受的範圍。

現在我們把焦點回到前面的「高估」和 「低估」。

「高估」和 「低估」


筆者前面所謂的「高估」,指的是決策者通常會「高估」組織在流程系統、管理模式的能力,以致於在專案計畫階段無法提出實際、具體、準確、考量風險後的專案計畫,以致於專案啟動後實際執行時,才發現以現在組織的運作效能,隨著專案進度不可能如期完成。

而筆者所謂的「低估」,是指決策者通常都會「低估」專案的難度、複雜度、深度,以致於在專案啟動後,隨著越來越了解專案要求,才發現要如期、如質、如成本地完成專案有相當的難度。

探究其原因,可以發現決策者「高估」了組織的流程系統、管理模式能力,「以為」組織已經正確地評估專案,才是後來產生「低估」專案難度的結果。但解決專案只是治「已病」,因為流程系統、管理模式能力不足才是「未病」--問題的真正原因。

而且,這些「未病」通常是組織內沉痾已久的問題,想治療「未病」通常得需要大刀闊斧,甚至不惜傷筋動骨破壞人和,最後還需要一段時間後才能看得出效果。

小結


以現況來看,絕大多數公司都傾向本末倒置地解決「已病」,而非認真解決造成問題的「未病」。所以,「未病」一再成為「已病」,但這些公司卻應接不暇地解決「已病」。

到底有多少的組織決策者真的願意面對「未病」呢?
 Related Posts with Thumbnails 

0 意見 :

張貼留言