需求過程的溝通問題

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

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

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

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

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

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

Powered by ScribeFire.

Please follow and like us:
分類: 專案監控, 溝通, 衝突, 軟體開發。這篇內容的永久連結

在〈需求過程的溝通問題〉中有 2 則留言

  1. 自動引用通知: 同人的生活派對 » 合約與需求變更

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *