大約是在2014年的時候，我參加了人生第一次Business Analyst的面試。

記得當(dāng)時應(yīng)聘的是日立咨詢，上海的一位經(jīng)理電面。他非常職業(yè)地向我詳細(xì)介紹了他們的公司、他們的業(yè)務(wù)、以及這個職位對候選人的期望，然后就開始了對我的面試。

彼時的我還是一個developer的角色，憑著自己對IT項(xiàng)目野蠻又原始的理解，以及對Business Analyst這個頭銜的好奇，便開始了一本正經(jīng)的胡說八道。

面試官問了很多問題，比如新上一個項(xiàng)目，你最看重哪些方面；一個模塊，既可以放在財務(wù)部們，又可以放在市場部門，兩邊都不愿意負(fù)責(zé)，你怎么辦；項(xiàng)目里有五六個總監(jiān)級別的干系人，個個都說自己的需求很重要，你怎么排優(yōu)先級……幾個問題下來，我已經(jīng)被虐得不知東西了。

印象最深的是這樣一個問題：如果你的項(xiàng)目進(jìn)行到后期，客戶說要做變更，你怎么辦？

我當(dāng)時想起了郵件里項(xiàng)目初期各種approve的郵件，便想，這個我可知道：讓客戶找各個領(lǐng)導(dǎo)簽字，走流程，當(dāng)各個領(lǐng)導(dǎo)都能簽署同意，變更才可以實(shí)施。當(dāng)時我的心理是要用繁瑣的流程給客戶設(shè)卡，說罷還為自己的機(jī)智在心里點(diǎn)了個贊。

之所以印象深刻，是因?yàn)樵谥蟮墓ぷ髦械娜辗e月累，我對這個問題有了更多的認(rèn)識。

2017年我加入了ThoughtWorks，在這個敏捷文化濃厚的公司，我在一個PM的分享中，再一次地學(xué)習(xí)到，在敏捷中，需求變更是怎樣操作的。簡而言之，鑒于敏捷中我們有迭代周期，一般是兩周，那么在迭代中，有新的需求產(chǎn)生，如果它優(yōu)先級高于當(dāng)前迭代的任務(wù)，就可以優(yōu)先做新需求，把原計(jì)劃的任務(wù)順延到下個迭代中。我們擁抱變化勝過遵循計(jì)劃，我們的目的是快速響應(yīng)，同時兩周的迭代也讓我們的計(jì)劃更加靈活。事情好像就是很簡單，我所在的大客戶項(xiàng)目里也就是這么操作的。

敏捷里，我們擁抱變化。那么，在敏捷之前，事情是什么樣子的？

2018年初的PMP培訓(xùn)中，我找到了需求變更的標(biāo)準(zhǔn)答案：記錄變更需求——內(nèi)部討論變更影響——征求變更委員會批準(zhǔn)——做好相關(guān)記錄。好像和我當(dāng)年第一次面試的回答沒什么區(qū)別，但步驟更加細(xì)致、結(jié)果更加具體。

但在之后的項(xiàng)目中，我深深體會到了，需求變更，并不是一件讓人欣然向往的事情，它就是一把刺向項(xiàng)目管理的利刃。

我們知道，項(xiàng)目管理中的三大要素就是時間、質(zhì)量和成本。在一個計(jì)劃好項(xiàng)目中，需求變更必然要拉伸成本（需求減少不在討論范圍內(nèi)，實(shí)際上，往往是需求增加的情況多），那么時間和質(zhì)量，在原本穩(wěn)固的三角中，變得搖搖欲墜。

我新接手的一個項(xiàng)目，在交付階段，客戶就沒有底線地加需求，在明確告知上線前一周要code freeze、要做回歸測試的前提下，客戶還在要求加點(diǎn)雜七雜八的東西。聽說在上線的前一天晚上十點(diǎn)多，開發(fā)人員才把購買的功能調(diào)通。當(dāng)然，這樣的客戶自然不肯延期上線。

結(jié)果是什么呢？可想而知，產(chǎn)品上線后各種bug，頁面加載慢、登錄出錯、閃退，用戶的負(fù)面評價紛至沓來……一味地需求變更而不調(diào)整計(jì)劃，最終還是質(zhì)量讓了步。