封面故事
導入企業應用系統的敏捷思維
2018 8月 90
前往目錄
叡揚導入敏捷開發至今超過十年,叡揚第一個導入敏捷開發的產品團隊主管楊東城回憶;最初導入時,難免會有上級希望插單或要求更巨細彌遺的計劃等情況

記得早期剛訂中華電信 ADSL 時,有一次送了 500 元的點數,可用來折抵隨選影片的看片金。那段時間家裡多了一個共同話題,每到假日家人就會討論,今天要看哪部電影,同時會從各方面的影評來決定哪一部最值得看。那少少的 500 元點數,伴我們家 人度過好幾個充實的週末,一同欣賞了許多的好片。

 
由於這個經驗,前一陣子家裡續訂 ADSL 時,剛好有個促銷方案,就同時加購了 199 電影台,可在該電影頻道無限次數的選看,想說這樣最省事,家人不需協調時間,或討論那一部是好片,任何人任何時候,想看那一部就可以看那一部。
結果一段時間之後我發現,自從做了這個改變,我在家裡看到好電影的機率降低了。有好幾次難得的週末,卻因為少掉了先前的家庭會議,心中沒有一個好片清單,雖說不好看可以隨時換,但最終常一無所獲。原本一個看起來 是「零成本」的選擇,最後反而變成是最花時間成本的。
 

專案不延誤

唯有需求深化權衡取捨

這個發生在我自己身上的故事,感覺在白天的工作中也似曾相識。企業、機關導入典型的應用系統,如公文、HR、ITSM 等,會不會也有前述所謂「零選擇成本」反而是最花時間成本的情況呢?讓我們一起來看看。
 
首先,一個典型的專案,開案前通常會有個需求建議書(Request For Proposal,RFP),嘗試詳盡說明這個專案的需求。然而對於一個如前所述的典型應用系統而言,通常會看到兩種現象:
● 現象1:在 RFP 當中,十之八、九都是共通的,因為它的主業務流程,大都有一定的規範可循。
● 現象2:對於企業或機關所獨有的作業需求, 在 RFP 中不容易詳述,因為深淺程度唯有進行到需求訪談階段,才有可能深入了解。
 

 
 
這兩個現象所說明的是,即使是對於一個很成熟的應用系統,RFP 上所能夠描述的需求「深度」,也是非常有限的。
 
其次,一個典型的專案計價模式,通常是根據此 RFP 來估價,一旦案子成交,就以此做為預算的上限。而專案進行的風險,往往也就由此開始 -- 希望以固定的預算,來滿足「深度」不甚明確的需求。其所衍生的問題,大致可從底下幾個層面來探討:
● 就企業或機關而言:預算已經框列,必須在此預算內完成專案。
● 就廠商而言:需求範圍大致了解,但相對 「深度」卻所知有限。各家廠商依此 RFP 所估的成本差異不會太大,因為如前所述,一個成熟的應用系統,八、九成的功能都是一樣的。真正有差別的,是在那另外的一、兩成,也就是企業或機關所獨有的作業細則,而偏偏這一部份,又不是現階段所能夠了解的。
 
在此情況下,一旦訪談時才發現需求「深度」 和原本認知有很大差異,雙方的困擾就開始了。原本專案成功的三要素 – 需求、時程、預算,很容易因為其中需求的「深化」,而連帶造成專案時程的延後,和預算的超支。而偏偏 「深化」的需求卻又是最難取捨的,因為這不僅牽涉到現行作法,更有許多是該企業或機關所獨有的作業規範,不容易改變,即使希望改變,也不是少數人能夠決定的。
 
至此,問題的源頭似乎已經清楚,可是如何改善好像還不明朗。能不能在諸多「深化」的需求當中,權衡取捨,使得專案能夠在原本有限的預算和時程之內順利完成,似乎成為專案能不延誤最有希望的解方。
 

企業和機關與資訊廠商雙贏契機 代表使用者成關鍵

記得以前上過的管理課程,當有一堆 issue 要排優先順序時,如果請大家各自去排高、中、 低,結果很容易發現,排完之後幾乎全都是 「高」的,因為每一個人都覺得他自己所提的是最重要的。可是如果換個方法,比如說每一個人固定有 100 點,可以把它分配給各個議題,分完為止,則相對重要性很快就顯現出來。這就很像前面所提 500 元看片金的例子, 在資源有限的情況下,往往更能做出最佳的選擇。
 
同樣的觀念,對照到我們今天的專案情境當中,問題似乎更為清楚了:
(1) 首先,「深化」的需求往往來自不同的部門,或是不同的個人,如果是個別去詢問,每 一個需求可能都是很重要,都是不可缺少的,造成需求取捨困難。
(2) 有些需求,不同事業單位所提出來,在作法上是不一致的,可是,為了都能滿足,所以就開發出「兵分多路」的作法,如 A 事業單位走 A 作法,B 事業單位走 B 作法,結果在 一套系統中多了許多的條件判斷,除了多出開發和測試時間之外,更同時增加了系統的複雜度和維護困難度。
(3) 這些不一致的作法,原本是作業合理化首先要面對的,可是因為大家沒機會聚在一起, 也就失掉這個可以改善原有作業流程的機會了。
 
設想另一種作法,我們把一個專案的預算分成幾部份:
● 產品授權費:主要為滿足 RFP 中八、九成的共通需求。
● 導入服務費:屬於非開發性質的工作,如教育訓練、輔導上線等。
● 需求深化與客製調整準備金:採取類似前述 500 元看片金的觀念,在固定額度之內,做為專案進行中可能衍生「需求深化」之用。
 
除此之外,專案團隊中,使用者代表也是非常關鍵,因為在這樣的運作模式中,所有需求深化與客製調整,都在同一桶預備金中, 使用者代表要能夠充分代表各部門,將需求和預算做最有效的取捨運用。同時能夠以階段上線為彈性目標,在主要業務流程已能滿足的情況下,先行上線讓使用者熟悉,並繼續收集使用者意見,等一段時間之後,再整體評估各項改善意見的可行性和優先順序,
 
持續優化系統。此點也正呼應敏捷式系統開發 模式的幾個基本原則:
● 原則1:透過及早並持續交付有價值的軟體,來滿足客戶需求。
● 原則2:敏捷流程掌控變更,以維護客戶的競爭優勢。
● 原則3:面對面的溝通是傳遞資訊效果最佳的方法。
● 原則4:持續追求優越的技術與優良的設計,以強化敏捷性。
● 原則5:保持精簡原則,善用方法讓待辦需求的取捨最佳化。
● 原則6:...
 
取其精華,善加運用,尤其在保持需求精簡和功能價值最大化這點上,如能做到適切的取捨,相信將為專案成功(如期、如質、如預算),帶來更大的保障,也為企業和機關與資訊廠商帶來雙贏的契機。