大約是在2014年的時候，我參加了人生第一次Business Analyst的面試。
記得當時應聘的是日立咨詢，上海的一位經理電面。他非常職業地向我詳細介紹了他們的公司、他們的業務、以及這個職位對候選人的期望，然后就開始了對我的面試。
彼時的我還是一個developer的角色，憑著自己對IT項目野蠻又原始的理解，以及對Business Analyst這個頭銜的好奇，便開始了一本正經的胡說八道。
面試官問了很多問題，比如新上一個項目，你最看重哪些方面；一個模塊，既可以放在財務部們，又可以放在市場部門，兩邊都不愿意負責，你怎么辦；項目里有五六個總監級別的干系人，個個都說自己的需求很重要，你怎么排優先級……幾個問題下來，我已經被虐得不知東西了。
印象最深的是這樣一個問題：如果你的項目進行到后期，客戶說要做變更，你怎么辦？
我當時想起了郵件里項目初期各種approve的郵件，便想，這個我可知道：讓客戶找各個領導簽字，走流程，當各個領導都能簽署同意，變更才可以實施。當時我的心理是要用繁瑣的流程給客戶設卡，說罷還為自己的機智在心里點了個贊。
之所以印象深刻，是因為在之后的工作中的日積月累，我對這個問題有了更多的認識。
2017年我加入了ThoughtWorks，在這個敏捷文化濃厚的公司，我在一個PM的分享中，再一次地學習到，在敏捷中，需求變更是怎樣操作的。簡而言之，鑒于敏捷中我們有迭代周期，一般是兩周，那么在迭代中，有新的需求產生，如果它優先級高于當前迭代的任務，就可以優先做新需求，把原計劃的任務順延到下個迭代中。我們擁抱變化勝過遵循計劃，我們的目的是快速響應，同時兩周的迭代也讓我們的計劃更加靈活。事情好像就是很簡單，我所在的大客戶項目里也就是這么操作的。
敏捷里，我們擁抱變化。那么，在敏捷之前，事情是什么樣子的？
2018年初的PMP培訓中，我找到了需求變更的標準答案：記錄變更需求——內部討論變更影響——征求變更委員會批準——做好相關記錄。好像和我當年第一次面試的回答沒什么區別，但步驟更加細致、結果更加具體。
但在之后的項目中，我深深體會到了，需求變更，并不是一件讓人欣然向往的事情，它就是一把刺向項目管理的利刃。
我們知道，項目管理中的三大要素就是時間、質量和成本。在一個計劃好項目中，需求變更必然要拉伸成本（需求減少不在討論范圍內，實際上，往往是需求增加的情況多），那么時間和質量，在原本穩固的三角中，變得搖搖欲墜。
我新接手的一個項目，在交付階段，客戶就沒有底線地加需求，在明確告知上線前一周要code freeze、要做回歸測試的前提下，客戶還在要求加點雜七雜八的東西。聽說在上線的前一天晚上十點多，開發人員才把購買的功能調通。當然，這樣的客戶自然不肯延期上線。
結果是什么呢？可想而知，產品上線后各種bug，頁面加載慢、登錄出錯、閃退，用戶的負面評價紛至沓來……一味地需求變更而不調整計劃，最終還是質量讓了步。
