甲方、end-user 與需求落差

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 不認為軟體符合他們的需求，所以大老闆就不願意驗收付款。