「被遺漏的需求」的迴響 http://www.lifeparty.idv.tw/blog/archives/210 君子學以聚之,問以辨之,寬以居之,仁以行之 Sat, 14 Jan 2012 03:40:34 +0000 hourly 1 http://wordpress.org/?v=3.1.1 由：同人的生活派對 » 需求過程的溝通問題 http://www.lifeparty.idv.tw/blog/archives/210/comment-page-1#comment-3518 同人的生活派對 » 需求過程的溝通問題 Mon, 03 Sep 2007 10:21:09 +0000 http://www.lifeparty.idv.tw/blog/archives/210#comment-3518 [...] 最近有網友 Julian 對〈被遺漏的需求〉提出他的觀點，他認為在需求過程中，客戶端負責人員事前不用心收集真正使用者的需求。在事後提出了許多需求變動卻不願意延長專案時程與負擔增加的費用；況且即使客戶答應追加費用和延長專案時程，他認為他也不一定還有資源可以完成其提出的變動，因為資源的使用時間是有限的，一旦超過了資源的使用期限，他必須釋放這些資源給公司的下一個專案。於是他說： 因此在從事專案開發時，我仍然會向客戶強調專案需求的不可變動性，目的是希望他們能看重自己應該負擔的責任，在專案開始前審慎收集及評估種種需求。在專案接近尾聲後若客戶再提出要改東西，我們也比較好大聲的說：要改？先上線和驗收後再拿錢來談吧！ [...] [...] 最近有網友 Julian 對〈被遺漏的需求〉提出他的觀點，他認為在需求過程中，客戶端負責人員事前不用心收集真正使用者的需求。在事後提出了許多需求變動卻不願意延長專案時程與負擔增加的費用；況且即使客戶答應追加費用和延長專案時程，他認為他也不一定還有資源可以完成其提出的變動，因為資源的使用時間是有限的，一旦超過了資源的使用期限，他必須釋放這些資源給公司的下一個專案。於是他說： 因此在從事專案開發時，我仍然會向客戶強調專案需求的不可變動性，目的是希望他們能看重自己應該負擔的責任，在專案開始前審慎收集及評估種種需求。在專案接近尾聲後若客戶再提出要改東西，我們也比較好大聲的說：要改？先上線和驗收後再拿錢來談吧！ [...]

]]> 由：julian http://www.lifeparty.idv.tw/blog/archives/210/comment-page-1#comment-3464 julian Fri, 31 Aug 2007 07:25:20 +0000 http://www.lifeparty.idv.tw/blog/archives/210#comment-3464 我是一個從事系統整合專案程式開發的專案經理, 您敘述的有關需求變動與管理的說法我完全可以接受, 但是問題是客戶端負責人員事前不用心收集真正使用者的需求, 事後提出了許多需求變動卻不願意延長專案時程與負擔增加的費用; 況且即使客戶答應追加費用和延長專案時程, 我也不一定還有資源可以完成其提出的變動(時間到了必須釋放這些資源給下一個專案)，我想這才是問題所在吧。 因此在從事專案開發時, 我仍然會向客戶強調專案需求的不可變動性, 目的是希望他們能看重自己應該負擔的責任, 在專案開始前審慎收集及評估種種需求. 在專案接近尾聲後若客戶再提出要改東西, 我們也比較好大聲的說 - 要改? 先上線和驗收後再拿錢來談吧! 我是一個從事系統整合專案程式開發的專案經理, 您敘述的有關需求變動與管理的說法我完全可以接受, 但是問題是客戶端負責人員事前不用心收集真正使用者的需求, 事後提出了許多需求變動卻不願意延長專案時程與負擔增加的費用; 況且即使客戶答應追加費用和延長專案時程, 我也不一定還有資源可以完成其提出的變動(時間到了必須釋放這些資源給下一個專案)，我想這才是問題所在吧。

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

]]>