場景：
昨天部門經理會議上，部門經理z談到了專案e目前上線後，使用者提出的需求變更，其他談到了某個功能n，說起該功能的變更需要耗時3人天工作量。
從部門經理z談的內容，我覺得聽不出來為何此項變更需要3個工作人日，要求由專案e的需求人員g扮演業主使用者zj，對同一專案組內負責開發同事l的工作量估計進行審核。以此為抽查檢查點，看需求變更的工作量估計。
分析：
業主itc同事在評判工作量的時候，很多情況下，不會檢查專案project中的每乙個wbs、task的資源投入、工作量以及成本，但是業主同事基本上一定會採用抽檢的方式對一些wbs、task的投入進行核查，並且提出一些質疑。
如果在這乙個質疑的過程中，他每提出的乙個質疑，你都能夠給出明確合理的理由，往往他就會開始信任你的判斷。反之，在這個質疑過程中，你的解釋如果沒有原則，總是說是這塊的工作量很大，技術上很難實現的原因，這樣的解釋就會讓業主同事生疑！當然在這個過程中，如果你能體現出對業務理解的熟練，指出業主方同事在業務方面遺漏或者欠缺的地方，那麼你的解釋會更加有說法力。
工作中需要的這些能力，不是等到業主來質疑我們的工作量評估的時候，才匆忙去解釋或者學習如何找原因；也不是等到我們開發的同事無法按時完成任務的時候，才匆忙給業主解釋原先的工作量估計得太少了。（以前可有不少這樣的例子）
因此在部門經理會中，安排專案組同事內部的自查，可以達到：
訓練專案組能夠養成自我檢查、做好準備、相互補位的習慣。找乙個接觸業主最多的同事來扮演業主，真正業主提出質疑的時候，才能從容面對。
從乙個小功能開始去學習如何準確地估計工作量，從日常工作中去訓練，養成有理有據的工作量解釋，當真正面對實戰、面對業主、面對管理者的時候，你才能夠很清楚、很坦然地知道自己的底線。
破除可能的誤區：等著重新開始乙個全新的大專案，或者乙個大的模組，就會進行準確的工作量估計。
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...
需求變更的煩惱
客戶今天要求變更需求，加某某功能，這個應該不難吧，某某公司的產品都有這個功能的。客戶的需求一直在變，煩惱。開始是需求不明確，客戶都不知道要做成什麼樣，只有乙個大概的粗略的描述。等到大樓蓋好了，給客戶，卻發現大樓應該是這樣那樣的。客戶方和開發方在一起 workshop 還好，如果分開在兩地就更糟糕。永...
我的需求變更
最近好累啊，不停的在變更我所寫的需求說明書，覺得自己不想是個有思想的動物，只是在按照他人的想法在不停的修改，修改。回頭想起來，自己是不是乙個有想法的人呢？似乎又沒有辦法完全的回答，對於目前所處的這個領域我覺得自己真的是缺乏很多的知識，拼命的在補充自己，但是似乎沒有辦法在短時間內完全的掌握現在的工具，...