做软件项目，经常会不断地遇到临时需求变更的情况。
最近就遇到一个，客户过来问公司老板，这个图片能不能换一个，换成我们公司的图片，顺便宣传一番。于是老板来问开发，换个图片难吗，要多少时间，开发人员说没问题，这很简单，几分钟搞定。然后改了没多少时日，客户又提要求了，图片不要了，干脆换成视频吧，视频会动，比图片好。这时候老板又来问开发，开发觉得很难回答了，改成视频可不是换图片那么简单的事，架构全都要变，还要评估下刷新率与显卡水平。但是他难以向老板解释这个事，老板可能还会认为他在找借口。
这类事情在软件项目管理中经常会发生，几乎每次客户或者职能经理看到软件产品，都会各抒己见，希望再加点什么，随之产生了大量的变更需求。这些需求一般都是口头上的，甚至有时候说过算过，不会用文档写下来，对方也不希望走变更流程，觉得直接改改的事，用不着走什么流程。最后，这些变更往往越积越多，成为了项目延期甚至无法交付的最大阻碍。
这个例子的问题在于，项目经理的缺失。
客户对老板提需求，老板直接向开发提需求，需求和开发这对矛盾都集中在了开发人员这里，缺少了项目经理这个中间桥梁，开发人员也缺少了“挡箭牌”，一方面迫于压力不断接受新的变更，另一方面顶住技术实现的困难给自己加工作量，开发人员苦不堪言。
其实一般来说的，多数的工科思维的或者是有点脾气软件开发人员，往往会坚守自己的边界，不喜欢做自己任务范围以外的工作。而难免有些时候，有些开发人员会因为碍于情面，迁就客户，或者是出于对自己能力的自信，轻率地表示“这个好改”。往往是这样的轻率，让客户或者上级认为，加点需求也不是什么难事，似乎就是举手之劳。当客户有了这样的思维倾向，就容易在沟通的时候，忽视了合同的约束力，不断提各种项目范围之外的期望。项目工作量越来越大。
然而，软件的变更成本，往往是无法简单的估量或者推测的。看起来差不多类型的需求变更，却有可能需要付出巨大的工作量。即便是“好改”的变更，也需要占用人力和时间。这就需要专业的项目经理去评估变更代价，并从一开始，就明确对变更的态度。
总结来说，对这类临时需求的变更，可以把握下面几个点：
- 将口头的需求变更落实到书面，确认客户的需求，是真的想改，还是随口一说；是锦上添花，还是非改不可。
- 评价该需求的变更代价，这个需求属于什么等级，值得花多少人力时间成本，又需要花多少人力时间成本。
- 执行需求变更，提交变更申请，走变更流程。
在这个过程中，可能会遇到无法按流程的情况，对方不配合的情况，都很正常。这时候需要灵活的，人性化的处理方式。管理终究是对人的管理，因此，人与人之间的沟通和理解是项目是否能成的关键，项目经理对客户的引导也很重要。
