jim yeh on 九月 3rd, 2007

最近有網友 Julian 對〈被遺漏的需求〉提出他的觀點,他認為在需求過程中,客戶端負責人員事前不用心收集真正使用者的需求。在事後提出了許多需求變動卻不願意延長專案時程與負擔增加的費用;況且即使客戶答應追加費用和延長專案時程,他認為他也不一定還有資源可以完成其提出的變動,因為資源的使用時間是有限的,一旦超過了資源的使用期限,他必須釋放這些資源給公司的下一個專案。於是他說:

因此在從事專案開發時,我仍然會向客戶強調專案需求的不可變動性,目的是希望他們能看重自己應該負擔的責任,在專案開始前審慎收集及評估種種需求。在專案接近尾聲後若客戶再提出要改東西,我們也比較好大聲的說:要改?先上線和驗收後再拿錢來談吧!

Julian 的觀點其實很清楚地顯示需求變更在開發過程中對開發者的困擾,及對需求提供者深切的期望,對於一直從事軟體開發的同人而言,當然很能體會他的心境。但當我們希望客戶能體會開發者的難處,傾聽我們的心聲,希望他們能用心地收集客戶的需求時,但站在客戶的立場來看,他們會不會也希望開發者應該發揮專業,「用心」地導出需求,以有效地解決客戶與使用者的問題。

換句話說,當我們要求客戶正視他們的責任時,有沒有想過開發者的專業在那裡?如果只是一味地要求客戶,卻沒有自我省思時,需求過程就會產生溝通問題,雙方都會認為問題出在對方身上,並且認為問題不在我身上、一切都是對方的問題、以及我沒辦法做什麼推諉之辭,結果雙方無法建立彼此的共享語意庫,無法為共同目標共同努力,取而代之的卻只是因為個別的利益考量的利害衝突

需求的變動,責任不一定出在客戶或使用者身上,除了環境的變化外,常常問題是出在開發者自己身上。例如,很多開發者,常常不是從瞭解客戶所面臨的問題去分析來導出需求,而是從客戶提出的功能直接轉變成軟體規格,這種缺乏分析及設計的規格,在日後就會面臨需求不斷變更的風險。因為,當客戶提出系統功能時,是以為這些功能可以解決他們的問題,但系統開發並非他們的專業,所以他們對功能的認知很可能是有偏差的。如果開發者不去審視這些功能背後所要解決的問題,就很容易造成客戶或使用者的問題沒有被解決,而這也正是開發者在問題分析上的不夠專業之必然後果。

此外,以技術來主導需求分析也是開發者常犯的毛病,造成對客戶問題的錯誤認知,甚至主觀地認為客戶的需求是「錯的」。當然,會發生這樣的問題是源自客戶與開發者,在溝通過程中所使用的詞彙是很不一樣的,而在軟體在開發出來前,又沒有具體的東西可以讓雙方交流想法。所以,在開發過程中,持續不斷的與客戶進行良性溝通,這樣做其實是勝過向客戶斷言需求不得變更的說法,因為後者對客戶關係及軟體品質都有很大的損傷呀。

Powered by ScribeFire.



     

2 Responses to “需求過程的溝通問題”

  1. julian 說道:

    我想同人大大給我的回應有點偏離主題了, 也許是我原來的說法太簡化軟體專案需求收集的問題.
    我同意前一篇同人大大講的 "需求應該是會一直變動的" 這件事。但是在實際專案進行中若要允許需求一直改變應該要有2個前提:

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

    只是這樣的客戶在台灣我想應該很少吧. 大部分的客戶都是一個專案一個價錢, 要追加實在是很難的事. (順便提到, 如果有哪一家客戶允許廠商用XP的方式開發軟體的請告訴我, 我實在不知道用XP要怎麼報價, 除非我們開發人員駐廠然後用打卡紀錄來計價). 其實無關需求收集的責任歸屬, 即使開發商再專業, 用了再多的心力收集和完成需求的界定, 只要允許需求是可以改變的,以上的問題還是存在吧。這其實是我上一篇回應的意思,

    另外針對這一篇文章我也提一下我的意見, 我將自己界定成是系統開發者, 因為類似的系統有開發過, 所以可以提供一點商業規則或是領域相關知識, 但是絕不表示我們就是這個領域的專家, 我們並非企管顧問公司可以幫客戶規劃合理的流程, 因此大部分的需求還是要從客戶而來 (也許同人大大的經驗不是這樣), 系統都開發完成了還要修改, 也許大家都有責任, 但是我認為大部分的狀況應該是客戶本身的問題比較多, 這才是我上一篇說的 "向客戶強調專案需求的不可變動性, 希望他們能看重自己應該負擔的責任" 希望解決的部分問題.

    很多情況, 我們即使事前和對方的IT和Key User談的再詳細, 大家也簽名畫押了, 最後對方的高層主管一句話說XXX不對應該要OOO, 就推翻了之前好幾次會議的結論. 好吧, 你也可以怪我stakeholder的管理沒作好, 為什麼事前沒考慮到這位大官, 但是即使考慮到了又怎樣, 一家公司好幾個副總, 每個都找來開需求訪談會議嗎?

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

  2. [...]Julian 又對我在〈需求過程的溝通問題〉提出看法,對於需求變動他認為: [...]

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="">