大约是在2014年的时候，我参加了人生第一次Business Analyst的面试。
记得当时应聘的是日立咨询，上海的一位经理电面。他非常职业地向我详细介绍了他们的公司、他们的业务、以及这个职位对候选人的期望，然后就开始了对我的面试。
彼时的我还是一个developer的角色，凭着自己对IT项目野蛮又原始的理解，以及对Business Analyst这个头衔的好奇，便开始了一本正经的胡说八道。
面试官问了很多问题，比如新上一个项目，你最看重哪些方面；一个模块，既可以放在财务部们，又可以放在市场部门，两边都不愿意负责，你怎么办；项目里有五六个总监级别的干系人，个个都说自己的需求很重要，你怎么排优先级……几个问题下来，我已经被虐得不知东西了。
印象最深的是这样一个问题：如果你的项目进行到后期，客户说要做变更，你怎么办？
我当时想起了邮件里项目初期各种approve的邮件，便想，这个我可知道：让客户找各个领导签字，走流程，当各个领导都能签署同意，变更才可以实施。当时我的心理是要用繁琐的流程给客户设卡，说罢还为自己的机智在心里点了个赞。
之所以印象深刻，是因为在之后的工作中的日积月累，我对这个问题有了更多的认识。
2017年我加入了ThoughtWorks，在这个敏捷文化浓厚的公司，我在一个PM的分享中，再一次地学习到，在敏捷中，需求变更是怎样操作的。简而言之，鉴于敏捷中我们有迭代周期，一般是两周，那么在迭代中，有新的需求产生，如果它优先级高于当前迭代的任务，就可以优先做新需求，把原计划的任务顺延到下个迭代中。我们拥抱变化胜过遵循计划，我们的目的是快速响应，同时两周的迭代也让我们的计划更加灵活。事情好像就是很简单，我所在的大客户项目里也就是这么操作的。
敏捷里，我们拥抱变化。那么，在敏捷之前，事情是什么样子的？
2018年初的PMP培训中，我找到了需求变更的标准答案：记录变更需求——内部讨论变更影响——征求变更委员会批准——做好相关记录。好像和我当年第一次面试的回答没什么区别，但步骤更加细致、结果更加具体。
但在之后的项目中，我深深体会到了，需求变更，并不是一件让人欣然向往的事情，它就是一把刺向项目管理的利刃。
我们知道，项目管理中的三大要素就是时间、质量和成本。在一个计划好项目中，需求变更必然要拉伸成本（需求减少不在讨论范围内，实际上，往往是需求增加的情况多），那么时间和质量，在原本稳固的三角中，变得摇摇欲坠。
我新接手的一个项目，在交付阶段，客户就没有底线地加需求，在明确告知上线前一周要code freeze、要做回归测试的前提下，客户还在要求加点杂七杂八的东西。听说在上线的前一天晚上十点多，开发人员才把购买的功能调通。当然，这样的客户自然不肯延期上线。
结果是什么呢？可想而知，产品上线后各种bug，页面加载慢、登录出错、闪退，用户的负面评价纷至沓来……一味地需求变更而不调整计划，最终还是质量让了步。
