作为一名码农，在项目开发过程中经常会涉及到项目的需求变更，变更的理由也是多种多样，总结而来分为外部和内部，从外部讲，例如：为了顺应某行业新的工作操作规范，甲方要求现有项目在工作流程环节上进行局部功能的变更；从内部讲，通过对市场环境的不间断调研和数据分析，公司产品在同类产品竞争中处于不利地位，市场份额日渐缩小，那么我们的产品设计人员会积极行动起来对产品的整个定位和新业务展开新的思考以寻求更加稳健的创新突破口，这就会对项目产生一定的需求变更。
此图是从CSDN社区截取下的，我相信很多看到这个问题的筒靴和我一样，这辈子都会有着不可磨灭的记忆，一种刻骨铭心的痛。
看到这里给自己两分钟的时间思考一下吧，如果是你遇到这样的问题你该怎么解决，其实按照国际上一些项目管理的原理，解决方法已经很明确了，问题是我们如何将其人性化的应用在我们自己的实际工作中，根据项目的本质，所处环境和市场因素因地制宜，找出一套适合自己的解决办法？那么好，我们现在就倒杯咖啡耐心的思考一下… …
现在先看看，帖子下一些具有代表性的声音是什么说的：
第一种现实主义思想：
“不以赚钱为目的的公司不是好公司，不以设发赚钱的项目经理不是好经理“，项目赚钱固然是王道，这种解决方法虽然直截了当，但是对于客户的项目期望却相差十万八千里，你难道不觉得这样会伤害客户的自尊心吗？
第二种杨白劳思想：
“任劳任怨，无所求”这种做法是一个公司最无能的表现（对事不对人，请大家不要误会）
第三种 博弈思想：
第四种 强硬拒绝思想：
右派式的极端主义，我觉得不适合中国国情，你如果在德国那ok,但是在讲面子，讲关系，讲交情的中国，这是万万不行的，你除了会得罪客户外什么也得不到，话又说回来，至于软件可不可用，实不实用不是你说了算，而是甲方是客户，不然你大老远的跑去和甲方谈哪门子需求。
第五种软攻击思想：
在实战中不打常规牌，不战而屈人之兵，这一招对于日理万机的大领导或许很有用，但是你试想一下，在大领导眼皮下配合你们工作的甲方小青年，他能轻易的去糊弄他的领导吗？反过来为了体现自己的尽职尽责和专业性，他会表现的更加卖力，这样的情况我已经体验到无数次，有时候会半夜会主动找你谈需求。
第六种拖延思想：
这种方法非常不可取，还是从我自身的故事说起，在2011年的时候公司承接了一个山东省的医院项目，项目总额大概有五六十万的样子，项目顺利启动，但是当我方研发进行调研的时候发现信息科内部暗流涌动，两位领导意见不合，职场斗争非常激烈，因为甲方时有时无的矛盾，导致项目无法正常开展，这里面还存在一个问题就是销售人员为了拿到单子，居然放开话告诉甲方，只要你们提出的需求我们都能满足，当时坐在会议室里，听着甲方毫无条理的需求，我们通过技术角度解释的时候总是被这句话打压下来，相信那个场合下公司的腰杆哪能挺得直。项目还涉及到其他公司项目的对接，后期因为需求变更的问题，项目一拖再拖，研发人员奔波于北京山东两地，两年的时间都未搞定，本来预期两个月的项目最终以失败告终。
干耗时间，吃亏的永远是我们自己，从事实角度来说很多单位还是喜欢传统人力操作流程，您努力开发出的软件很有可能被流于形式应付检查，他们可能没你着急。
第七种公关思想：
行业内是该潜的潜，该给的要给够，但是你能确保所有客户你都提供一遍？项目的硬性需求还是要有的，不然他拿什么东西来证明他花出去的钱是合理的，有价值的？（是不是有些高级黑，不知道送快递的是不是要来了）。
第八种理性乐观思想：
如何对待需求变更，我们以什么样的态度来对待呢：
1、 变更是不可避免的。
2、 变更必须被管理。
3、 积极发现引起变更的因素，促使变更尽可能早的出现，减低变更带来的风险。
端正了上面的三点态度，那我们回过头来分析一下：
在项目启动时就已经设定好了变更的审批流程，具体图示如下（为了说明问题尽量简单，如有不标准还望指出，谢谢），用户提出需求变更以文档形式交给项目组（小公司估计也没什么委员会），项目核心成员，市场人员等关键干系人进行沟通，对客户提出的需求变更有无触及项目基准和范围基准，如果触及重新估算项目计划，项目成本，项目范围，并估算变更对项目所产生的的影响，预测变更为项目带来的资源，技术等因素的风险。经过对需求变更进行量化的考核，依据合同的标准进行衡量，审批通过的可直接加入项目开发序列，并及时对组织资产文档进行更新，对于审批出现问题的需求，可通过项目启动时规划的风险应对措施和客户进行有效沟通来进行解决。
