註冊 | 登入 | RSS Feeds
ZDNet | Taiwan.CNET.com |

廣告:
專案時間不足 如何達成不可能的任務(下)

留下回應
    
葉木金 2008/03/03 08:11:02 (接前頁)

開發產出與產能之平衡

由此可知,在專案開發時間不足的情況下,生產力迷思下的程式產出,其實多半無法具有實質效用。開發者在龐大時間壓力難有思考的空間,將使他的產能逐漸耗竭殆盡。即使在剛開始,一時滿足了客戶的需要,然而長久下來,卻在無形之中增加了專案的複雜度,最終只會在耗盡開發者的青春與熱情之後,得到專案失敗的苦果。

因此,在專案時間不夠的情況下,要達成不可能的任務必須要提昇軟開發的產能,必須讓開發的產出與產能可以相互配合。

至於如何增進良好設計架構的產能呢?依筆者軟體專案開發的實務經驗來看,關鍵在於必須同時兼顧客戶價值與開發風險。而要做到這一點則必須要讓開發者與客戶充分溝通。

筆者常觀察到許多開發者習慣把客戶提出來的功能直接當做軟體需求規格,卻沒有深入分析客戶真正遇到的問題。他們以為問題領域、業務流程或現場作業等知識是客戶的專業,開發者無從介入,因此往往在不知客戶要求之所以然的情況下,直接把客戶的話轉換成軟體規格。

然而,客戶所知道的並不是軟體需求(requirements),他們對系統的觀點只能顯露出他們對系統的需要(needs)。需要是抽象而片斷的,本身是非結構化的,而可用的軟體需求卻必須是具體而完整一致的,具備結構化的特性。

因此,如果開發者沒有針對客戶需要分析他們的問題,設計解決方案,只是直接把客戶的想法直接轉成軟體規格的話,客戶心中想的那朵雲,隨時都會變幻出各種不同的形狀,需求不斷變動乃是必然。如果開發者沒做適切的分析及設計,只靠技術是很難滿足客戶多變的渴望與需要的。

事實上,軟體開發是知識與腦力密集的工作。自許為知識工作者,重要的不在於產出的數量,而在產出的品質。要讓產出具有足夠的品質,必須要在問題領域的分析投入足夠的時間,才可能為客戶設計出可以解決他們問題的軟體,為客戶創造價值;軟體也才能具備足夠彈性適應客戶千變萬化的需求,有效地降低開發風險。

正確的溝通

於是,當我們用以上的思路來看軟體開發時,縱使專案沒有足夠的開發時間,我們依然要會從客戶的立基點中去思考問題,並從中找出最可行的技術來創造客戶的最大價值。同時,在這樣的情況下,開發者展現了足夠的專業,客戶也會很自然地信任開發者誠意與專業,形成了良性的雙向溝通。

在這種客戶與開發者良性溝通的情況下,客戶可以決定了時程、成本、品質等限制條件,而專案範疇的限制條件則應該由開發者與客戶溝通後依業務需求及技術架構的取捨來決定。

也就是說,客戶提出他的問題、以及希望解決的時限及願意付出的成本。開發者則針對問題分析出需求規格、發展出技術架構,並據此實作出軟體後再交由客戶驗收。然後,客戶再依軟體實際使用狀況予以回饋,開發者再依照客戶的意見反覆地演化系統,使軟體更趨於完善。

理想狀態是,客戶應該優先提出最關鍵及最核心的業務問題,而開發者則必須針對這些問題分析,發展出軟體需求、找出解決問題應採用的技術與方法、優先將最高風險及最核心的架構與程式實作出來。如此客戶最重要的問題可以優先被解決,而開發者也可以針對客戶問題而設計,而不會浪費時間與成本在過度設計上,降低了軟體開發的風險與複雜性,使得產出與產能可以相互配合。

開發產出與產能相互平衡,才不會偏廢於需求面或技術面,使技術可以面對現實地解決客戶的問題。就算開發時間真的不夠,至少也可以用空間換取時間呀。無論如何,客戶至少都會擁有一個可用的系統,而不是一堆無法正常運行的程式碼與文件。

作者目前在某知名公司擔任架構設計工程師,擁有台科大MBA學位,曾參與國內大型專案,並具有專案管理專業證照 (PMP)。在此之前從事資訊科技工作20年,歷任不同IT領域,具有豐富軟體開發經驗。
加入我的圖書館 訂閱關鍵字
加入網路書籤> 加入funP | 加入Google書籤 | 加入Yahoo!奇摩分享書籤 | 加入twitter | 加入facebook | 加入plurk |
友善列印 | 轉寄朋友

icn_balloon_154x48 對本則報導有任何意見或看法嗎?歡迎留言


留下你的意見
會員 * 帳號:
* 密碼:
  1. 欄位可選填,若全不填,則顯示為「匿名」。
  2. 不支援html語法
非會員 姓名:
E-Mail:
Blog:
  重新載入驗證碼
* 驗證碼: 記住我