最近更新: 2007-03-13

甲方、end-user 與需求落差

Tags: 軟體工程

Alex Yin 在《請使用者也參與軟體專案, CMMI-ACQ》中回應:「正確而言並不適合將使用者與甲方畫下等號。現有的軟體工程在IEEE-STD-12207的Acquisition Process就是敘述甲方(軍備局)的activity。」純粹從 PM 的角度來看,確實在發出採購案前,甲方內部應先進行一套評估流程。但甲方內部流程並非我關注之事。我是一個 programmer ,所以我關心的是已進行採購且軟體專案開始實施的狀況,而且基於 Agile methods 強調使用者參與的精神,我更注重使用者在軟體開發的活動中扮演了什麼角色?

在契約書中,甲方指採購軟體需求的公司、組織,不等於 end-user ,但意義上包含 end-user。所以在我們這些軟體開發者眼中,「甲方」和使用者同義;當甲方提出需求變更時,我們總是說使用者又要改功能了...

但是甲方不等於 end-user 其實也是一種問題。我在《Bug 數量與軟體品質控制》的回應中提到我觀察的一種現象:「甲方接口單位通常是甲方的 MIS ,通常跟乙方一樣是資訊科班出身,但依我側面了解,國內資訊教育對「資訊軟體的生產過程」這方面的知識可說是付之闕如,也難怪甲方無法參與開發流程,甚至參與後反而成為專案的阻力。」

上面提的是我先前在軟體服務公司工作時的經驗。我現在的工作是在百貨流通業公司的資訊部門當 MIS 人員,但也負責針對公司內部的需求撰寫程式。換句話說,我現在是甲方的採購單位,我評估 end-user 的需求並決定要外包或自製、或經教育訓練解決。但我必須承認,就算在同一間公司中,我和 end-user 對需求內容之認知還是有落差。碰到這種情形,自製軟體還可以立即修正;如果是外包軟體,那問題就大了: end-user 不認為軟體符合他們的需求,所以大老闆就不願意驗收付款。

樂多舊網址: http://blog.roodo.com/rocksaying/archives/2846619.html