jim yeh on 八月 27th, 2007

在軟體開發過程中,需求變動往往會令開發團隊十分困擾,即使許多開發團隊在設計前做了許多努力,希望找到軟體的最完整需求,同時要求使用者確認下來,但最後卻還是發現需求變動終究還是不能避免。最近,同人在上班搭公車的時候,遇見了我目前所參與專案的前一任專案經理,他聽別人告訴他專案此階段已近尾聲了,客戶卻還一直在改需求,他向我表示,他很不能理解這樣的狀況。

怎麼現在還再改需求,那這樣向 power user 展示系統請他們提供對系統意見又有何用?

正巧此時他的站到了,必須下車,臨去之前我只得微笑著告訴他:"需求會變動是很正常的一件事",但我從他的眼中看到他疑惑,似乎是認為專案在需求確認後,不應該任由客戶變更需求。

同人可以理解這位長官的看法,站在管理面的觀點,需求變更會對專案造成不小的影響,既然之前雙方已經針對需求做過確認了,就沒有理由讓需求一改再改,不能因為客戶臨時產生一些新的想法,就要迎合他們改變需求。

不過,從另一個角度來思考,要找到軟體所有的需求,是一件很困難的事情。為什麼呢?因為尋找需求就像尋找未被發現的癈墟一樣,當我們找到愈多,我們就愈發現有剩下的沒被我們找到[1]。換句話說,當我們以為我們已經找到了所有的需求時,很有可能是因為還有被遺漏的需求未被發現,直到它們真正被發現為止,我們才有機會了解更完整的需求。

由此可知,在客戶確認需求後,就不讓他們改變需求是多麼難以做到的一件事。所以,在軟體開發過程中,堅持不讓客戶修改需求其實是不切實際的。

當然,我們也不能讓客戶隨意更改需求,擁抱改變不代表我們該接受混亂失序的狀態,而是需要對變更採取必要的管理。管理的目的不是為了防止改變,而是為了防止因為改變而造成系統開發的混亂失序狀態

從許多方面都一致地顯示著,要對變更做好妥善的管理,其實關鍵還是在於溝通上。在專案變更管理方面,必須達成讓改變對達成專案目標有正面的意義的共識、確認造成變更的因素已經發生、以及協助有效管理變更的行為[2]。而軟體敏捷開發方法也強調開發者與客戶必須達成共識,對於會影響正在開發的功能的變更必須延後處理

從軟體開發的現實角度來看,如果要等所有遺漏的需求都被找到了,才可以開始開發軟體的話,我們必須承認那將會是個不能完成的任務,但我們卻也了解到,在某些問題點上,我們可以有信心地說:"我們現在已發現足夠的需求了,以後我們會找到剩下的需求"[3]

所以,難怪 SWEBOK Guide 2004 當中,在需求過程中會特別強調:

需求過程不是軟體生命週期中被分割的前端作業,卻是從專案初始在生命週期中,連續不斷精煉需求的一個過程[4]

因為有遺漏的需求,所以同人才會認為需求會變動是很正常的一件事,開發者對抗它是沒有意義的,去思考如何因應現況才能創造價值,才是共創雙贏的互賴行為呀。

Powered by ScribeFire.



附註  
  1. Dean Leffingwell & Don Widrig(2003), Managing Software Requirements: A Use Case Approach, Second Edition, Addison Wesley.[]
  2. 此為 PMBOK 所認為的一般性變更管理的原則。[]
  3. Dean Leffingwell & Don Widrig(2003), Managing Software Requirements: A Use Case Approach, Second Edition, Addison Wesley.[]
  4. A project of the IEEE Computer Society Professional Practices Committee(2004), Guide to the Software Engineering Body of Knowledge, 2004 Version, IEEE.[]
     

2 Responses to “被遺漏的需求”

  1. julian 說道:

    我是一個從事系統整合專案程式開發的專案經理, 您敘述的有關需求變動與管理的說法我完全可以接受, 但是問題是客戶端負責人員事前不用心收集真正使用者的需求, 事後提出了許多需求變動卻不願意延長專案時程與負擔增加的費用; 況且即使客戶答應追加費用和延長專案時程, 我也不一定還有資源可以完成其提出的變動(時間到了必須釋放這些資源給下一個專案),我想這才是問題所在吧。

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

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