發現我回 13 樓的朋友回錯了。他的意見根本不是針對本篇文章來做討論，而是依據其它平台對我個人的主觀印象，做出沒有事實根據的人身攻擊。對這種沒有意義的批評，我根本沒有回應的必要。

13 樓的朋友，如果表達意見跟你不一樣的看法，就叫好辯，那也沒什麼好回應的。因為那代表跟你是無法就事情來討論的，你只會對不同意見的人貼標籤。

至於 12 樓的朋友，有沒有矛盾，如果你看懂了我的文章的話，相信不致有這樣的誤解。最後階段才加入 feature 不等於就是沒有做到早期發現，早期治療，反之亦然，即使做到早期發現，早期治療，仍舊不能保證最後階段可以不用加 feature。兩者沒有絕對的因果關係，把兩者混為一談是忽略了軟體專案的複雜性與多變化，而且問題多半發生團隊之間沒有充分有效溝通。尤其是對於堅持一定不能加 feature 的人，更是讓人難以溝通而對達成專案成功無益。

而對於您情緒反應的留言，本人不予置評。

inpines兄，怎麼從funp一路打到zd來了？真是好辨的傢伙

不知道inpines兄是不是作者?
如果是，請您再回頭看一看您之前寫的"總是要到驗收前，才會發現程式品質有問題？"
不知道這二篇文章有沒有衝突?
在最後階段才加入的feature如何作到您所說的早期發現、早期治療?和提早驗證?
您要不要就最後階段才加的feature如何作正確的驗證，再寫一篇精彩的文章?
有空的話要不要順便再寫一篇如何在幾十個字的短篇文字中看出一個在怨天尤人?

科學的求真不是憑感覺，而是根據事實與邏輯來推論事物的真相。信仰是不是個人情感因素？當然是，因為你把形成背後信仰的來源隱藏起來了，只因為你相信你的經驗，而你之所以選擇相信是因為個人情感而非事實與邏輯，否則大可以把推論過程交待出來而非談信仰。

事實上，個人經驗往往是人類理性的有限性的一大來源，你相信你經歷的，卻忽略了對你未經歷而別人經歷的不同事物是無知的。來自個人經驗的信仰是否為情感因素？這是無庸置疑的，而且就算你的信仰來自其它非經驗的來源的信仰也是個人情感因素。

每個人都有信仰，我的不會比別人的更高尚，但也絕不會更低下。它們代表不同價值觀的差異，但卻無法用我的信仰來證明別人是錯的，反之亦然。

因此，即使面對我敬重的深林也一樣，人權不因他的無端恐懼就要靠邊站，而是要相互對話，但談論焦點不應從信仰為出發點，而是必須從理性開始，以找到情感與理智的交界。

所以，在談論理性的事物我不會談信仰，而是談論據；以往對此議題的討論我都是有論據的，此文只是根據這些論據加以進一步整理我的完整觀點，而本文的所有觀點都可以在過去的討論內容中發現其踪跡，只是更加強的論述脈絡及實例說明。如果你在過去的討論看不到這些觀點，我想只能怪你自己把自己陷於人身攻擊的討論風格而無法自拔。

尤其是閣下用來扭曲喲哪桑學長與我的想法用的觀念偷換，加上對我的背景、信仰作沒有根據的嘲諷與攻擊，使人不得不懷疑你總是認為「天下烏鴉皆如我」呀。

科學的求真不是憑感覺，而是根據事實與邏輯來推論事物的真相。信仰是不是個人情感因素？當然是，因為你把形成背後信仰的來源隱藏起來了，只因為你相信你的經驗，而你之所以選擇相信是因為個人情感而非事實與邏輯，否則大可以把推論過程交待出來而非談信仰。

事實上，個人經驗往往是人類理性的有限性（ 連結 ）的一大來源，你相信你經歷的，卻忽略了對你未經歷而別人經歷的不同事物是無知的。來自個人經驗的信仰是否為情感因素？這是無庸置疑的，而且就算你的信仰來自其它非經驗的來源的信仰也是個人情感因素。

每個人都有信仰，我的不會比別人的更高尚，但也絕不會更低下。它們代表不同價值觀的差異，但卻無法用我的信仰來證明別人是錯的，反之亦然。

因此，即使面對我敬重的深林也一樣，人權不因他的無端恐懼就要靠邊站，而是要相互對話，但談論焦點不應從信仰為出發點，而是必須從理性開始，以找到情感與理智的交界（ 連結 ）。

所以，在談論理性的事物我不會談信仰，而是談論據；以往對此議題的討論我都是有論據的，此文只是根據這些論據加以進一步整理我的完整觀點，而本文的所有觀點都可以在過去的討論內容中發現其踪跡，只是更加強的論述脈絡及實例說明。如果你在過去的討論看不到這些觀點，我想只能怪你自己把自己陷於人身攻擊的討論風格而無法自拔。

尤其是閣下用來扭曲喲哪桑學長與我的想法用的觀念偷換（ 連結 ），加上對我的背景、信仰作沒有根據的嘲諷與攻擊，使人不得不懷疑你總是認為「天下烏鴉皆如我」呀。

感謝同人兄總算走出人身攻擊的口水戰風格, 以自己的思維理論直接討論此議題.
但是有句話的著眼點我不瞭解其來源:
“個人信仰本身也是出自個人情感因素”
想請問上面對個人信仰的來源的定義在哪個典故論文可以拜讀? 這個定義還真是第一次聽說呢!
想必那是同人兄自己面對自己的信仰(占星, 佛學…)來源所產生”天下烏鴉皆如我”的想法吧?

我的個人信來是出自個人經驗的堆切與累積, 或是說是經驗法則的歸納, 但決不是您所說的情感因素. 您這個論點一破, 其餘所說皆無立論之處.

我常想, 歷史為何只能證明”人無法從過去歷史學得教訓”? 原來原因就是不肯重視經驗與教訓, 如此而已.

剛好日前拜讀兄台討論華岡之狼的文章, 論到”過去犯錯不代表未來仍會犯錯”, 光是這個論點, 就足以代表對經驗的不夠尊重與輕視.

整個社會不用學到教訓? 只要仰賴犯錯的人是否學到教訓?

不過那篇文章在此討論就會離題很遠了.

我主要想說:
“個人信仰本身也是出自個人情感因素”
這只是兄臺一己之見罷了…

好吵喔 XD

腦袋清靜一下！

片面的文字無法交代清楚事情的來龍去脈，文字所留下的空白自然會讓人有無限的想像空間。

重要的是，

接觸任何的事物都要儘可能先排除掉所有的預設立場才可能看清楚事情的本質，

所有的溝通都需要回到溝通各方對彼方先發起同理心，

事情才不會落入雞同鴨講的「無限迴圈」，

我們的生命才不會白白的浪費……

"大概是您沒有作過軟體PM的經驗或是您經驗過的案子太少，所以才沒有遇過這種情況，類似情況有經驗的PM應該都遇過，不然就真的是我寫的太爛了你看不懂"

說我沒作過軟體PM的經驗或是經驗過的案子太少顯然不是事實。事實上我當然有遇到你說的情況，但我不會讓你這樣這樣怨天尤人，而是想辦法解決問題。而且我的解決方式更不是強制對方不能夠改feature，而是靠理性溝通來商討出因應之道，但卻不會缺少對問題的評估以認識現況。

至於你說你寫得太爛讓別人看不懂，這倒是有可能的一件事。

覺得很奇怪，許多人碰到和自己不一樣的看法，就著墨在人的批評上，而不能就事情進行理性的觀念溝通，這對我而言是不可思議的一件事。我當然不會相信這樣的人PM可以做得多好，因為他連專案管理最重要的溝通都學不會。

雞同鴨講，不知道3樓在回什麼?大概是您沒有作過軟體PM的經驗或是您經驗過的案子太少，所以才沒有遇過這種情況，類似情況有經驗的PM應該都遇過，不然就真的是我寫的太爛了你看不懂

3樓打錯字：應該是專案經理要有接受昨非今是的勇氣。

我想對於二樓情緒性的留言，實在是想不予置評。從我的專案經驗來看，我深知同樣的做法在不同的專案限制與假設的情況下，對錯不能一概而論，所以在了解別人專案的內情之前，切不應妄下斷語。當然，您可以有不同的偏好與選擇，但我也只有送您一段莊子秋水篇的話。

以物觀之，物貴而相賤。以物觀之，則貴賤不在己。以道觀之，則物無貴賤。

或許您總是認為只有自己的做法才是對的，而不曾了解別人說的事情，選擇活在自己的洞穴中。但我們也只能說：對與錯不是你說得算。

不是很了解一樓想要表達的意思，進行專案評估不是為了保證未來不會有問題，而是讓我們避免對專案現況的無知與偏見，以進行理性溝通的準則。

事實上，沒有任何方法可以證明未來某個feature會不會出現問題，但PMBOK對於變更管理的三個原則教我們的是對現況的需要來規劃、執行與控制。如果專案沒有PDCA的過程，也沒有理性溝通與問題解決的支持，這樣對於整個專案而言，是不會有可信度的。

因為那只是某個專案利害關係人陷於自己立場的偏見，跟feature的先後順序一點關係都沒有，否則很多舊feature不都是被新feature所取代嗎？更何況專案經理要有接受昨是今非的勇氣呀。

個人認為如果不能揭露太多工作細節那就別將這件是貼上網討論
既然貼上網讓人討論就別怪外人不懂內情
不然隨便寫寫我也會

「我昨天殺人了,不過我沒有錯,只是你們都不懂內情,就這樣,掰掰」

"換屁股　我也換了腦袋"從頭看到尾本來就是一個很標準的錯誤示範不論最後是否順利結案都一樣
要嘛提出有助於專案管理上好理由所以同意修改
要嘛承認自己當初只是自認為是中華小廚師身負打敗黑暗料理界的責任
而且相信最後大家都會過著幸福快樂的日子所以同意修改
(原作中提到:因為剛接下這專案時的願景與理想而同意修改)


還扯一堆什麼邏輯的謬誤
「個人信仰本身也是出自個人情感因素，那麼為什麼別人的情感不理智，而我們的情感卻是理智了呢」
這句話聽起來就只是 "嘎嘎嘎" 的鴨子叫
我是不會像你這麼會修飾用詞
倒是希望你這位專家能照著"換屁股　我也換了腦袋"這篇原文描述評心而論
別址什麼沒有證據可以證明該作者不是用感情衝動來管理專案
這裡又不是法院

要知道網路上什麼人都有
不是個個都笨蛋
專家們作評論還請誠懇一點
不需要用太多力氣在製造文章中的細微複雜邏輯(鴨子叫)
不然只是砸了自己的招牌而不自知

(不過我是很期待你能把 "即將進入beta階段還因為剛接下這專案時的願景與理想而同意修改" 這件事掰成專案管理上的好決策好教材啦
這樣以後我想改就改還能拿你這篇來當擋箭牌)

不知道有沒有這樣的經驗，一個feature在專案的最後階段才發現有重大的問題，一陣人仰馬翻的加班修改測試除錯再測試再除錯...，最後因為時程己到緊要關頭，只能保証不會出大問題但是不保証沒問題，客戶雖不滿意但最終也只能同意暫且這樣出貨...
即使真的蒐集了專案的資料，並加以評估，但是真的可以保証在專案後期加入的feature未來沒有問題嗎?我想只要有人的因素在裡面，誰都沒有辦法保証吧!
當然也可以說初期就定下來的feature也沒有辦法保証，但是至少它還經過了N百次長時間(專案期間)的測試，至少可信度是會比末期才新加入的feature高吧