jim yeh on 九月 4th, 2007

Julian 又對我在〈需求過程的溝通問題〉提出看法,他認為需求可以改變應該基於兩大前提,亦即:

  1. 客戶同意專案時程或是時程內的完成工作項目也要可以隨需求一起變動。
  2. 客戶同意專案費用也可以隨需求一起變動。

Julian 用了一些經驗來指出開發者對於允許需求變動會遭遇的困難,最後對於需求變動提出他的結論:

需求應該要可以變動,但是前提是客戶夠好可以負擔多出的時程和費用;如果不行,就要向客戶強調一個穩定的需求對專案能否順利完成的重要性,並盡可能的防止變動的發生。誰叫顧客永遠是對的,開發廠商永遠是被坳的哪一方。

同人認為 Julian 說的都是實情,開發者常會覺得很無奈,有很多事看起來是「形勢比人強」的問題,所以要讓專案順利進行下去,不得不採用權宜之計。但變動真的可以防止嗎?軟體專案的實情常會顯示著一個現象,你愈不讓客戶變更需求,客戶就愈會去變更需求。

為什麼會有這種結果呢?因為甲乙雙方的利益不相容,會讓雙方不斷地嘗試增加或減低資訊不對稱的現象,因而造成彼此相互鬥法的動態系統。但如果變更無法避免,那麼要客戶負擔因變更而多出來的成本及時程是可能的嗎?同人認為要視甲乙雙方所簽訂的合約類型而定,從 Julian 的回應看來,我想他所做的專案都是 fixed-price 或 lump-sum 合約而不是 T&M (time and material) 合約。

本來專案合約的類型就不是開發者可以決定的,而是軟體公司與客戶高層間的協議,然而如果開發者如果清楚合約類型的不同,與成本風險息息相關,或許就更可以不去抱持不必要的期望,也就不會有那麼多的抱怨了,至少抱怨的對象可以換一下。;^)

fixed-price 合約就是所謂的總價合約,意指買方只會依據當初協議好的固定價格來支付金額,如果合約沒有額外的獎勵或補償條款,那麼賣方將不會得到更多的酬勞,總價合約專案的成本風險本來就是賣方支付,這對客戶沒什麼好抱怨的,而是應該問公司高層,為什麼這個有成本風險的專案要用固定賣價的總價合約。

所以關於 Julian 所言的前提 2,如果是總價合約,其實是不會成立的,因為這將會違背合約內容;如果是 T&M 合約,才能成立,因為這種合約的賣價是視開發者花費的時間及花費的資源而定,所以對買方有較高的成本風險,通常用在複雜度較高的專案。

同人與那位專案經理所談的專案,就是採用 T&M 合約的軟體專案,而且相當湊巧的是此專案正好是用敏捷開發方法來開發軟體,雖不敢說是完全採用 eXtreme Programming,但我們的開發方法得確是參考 XP 精神所規劃出來的,在這個專案中同人深刻地體會到,允許需求變動與否,不在於方法論本身,而是如何適度與客戶溝通,掌握敏捷與紀律的平衡。至於成本計價的問題根本不用開發者費心,專案的行政支援會盡心來打理一切。

至於 Julian 所說的前提 1,以總價合約來看,如果變更衝擊到專案範疇,那麼可以與賣方協調修改合約,如果沒有,延期所增加的成本必須由賣方自行吸收。當然,T&M 合約變更後對專案的範疇、時程及成本之三重限制是由買方負擔。在此附帶提一點,客戶支付的價格與開發成本應該分開來看,請參考〈專案成本估算之軟體價格的迷思〉,所以變更所增加的成本並不一定就應該反映在軟體價格上,尤其是在總價合約專案中,這種現象更是明顯。

由上可知,Julian 提出的兩大前提,純粹是以開發者身處組織的利益來考量需求變更。但站在客戶的角度不見得會認同這樣的看法,專案的合約是由甲乙雙方協議具有法律的效力,它也專案很重要的限制之一,因此當用合約限制來看時,會發現以這兩大前提來看變更管理其實是不能讓甲乙雙方有一致性的觀點的,而有過於片面性的缺點。換言之,專案不能只站在開發者的角度來思考問題。

同人在此必須要澄清一個觀念,客戶可以提供他們的領域知識及現場作業知識,但那些知識並不是軟體需求(requirements),而是只能顯露出他們對系統的需要(needs),需要是抽象而片斷的,本身是非結構化的,而可用的軟體需求卻必須是具體而完整一致的,具備結構化的特性。

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

同人認為,開發者不應該只專注在 coding 上,自許為知識工作者,你的知識不是只有程式設計而已,而是要花足夠的時間在問題領域的分析上,才可能為客戶設計出可以解決他們問題的軟體,這才是開發者真正的專業所在呀。

當然,同人可以體會開發者希望"客戶夠好"的渴望,但我更相信,要讓客戶夠好,開發者也應該展現出足夠的專業,良性的溝通是雙向的,在希望客戶為我們著想的同時,我們是否真的願意多花一點時間問自己:"客戶真正需要的什麼,我是不是遺漏了什麼,我如何能創造客戶的價值?"。

一旦開發者願意自我反省,思考以上問題時,思想將會反映在行為上,客戶將會感受到你的專業與誠意,彼此才會有良好的互動,否則雙方的立場永遠是對立的,相互抗衡的後果將不會有贏的一方。彼此相互信任才能讓專案有好的開始,此時,我們才會看到,客戶與開發者的目標原來就是一致的,讓專案成功共創雙贏,大家其實都是對的,只是我們是否願意退一步,反省看清楚我們原來所看不到的事物。

Powered by ScribeFire.



     

One Response to “合約與需求變更”

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="">