我的应对客户常变更需求策略

上头派来一个任务，让我接手a同事的一个半年都没上线的一个功能的项目，主要原因是客户客户经常变更需求，导致项目难易落地或频繁修改。

给B端客户做产品，由于市场环境以及企业客户自身的一些原因，需求难免会变更，如果无法有效处理这些需求，会导致客户不满、项目延期，对团队无疑是打击和消耗。如果客户频繁变更需求，我们可以采取以下措施。

1、明确游戏规则
项目变更要在开始就要向客户宣导，打预防针，让客户理解变更控制的重要意义，而不是做到一半的时候，引起客户的投诉和纠纷。

2、合同约束
与客户签订合同时，可以对变更需求的情况做约束。提出需求变更的时间、哪种变更可接受、哪种变更不可接受、如果非得变更需求，是否需要加价？

3、建立变更流程
审批环节——审批人员——审批事项
将客户下达变更流程规范化，杜绝张嘴就来的非紧急、非合理、非必要的“三非”需求；是留下书面证据，为今后可能的成本变更和索赔准备好依据。凡未履行审批程序的“变更”，都当做无效变更。书面材料也是逼迫人思考的一个过程，防止出现拍脑袋的变更。

3、 评估需求变更的性价比
需要将需求变更产生的成本和收益告知双方领导，一般成本包含开发成本、时间成本、沟通成本等。最好能量化，明确告知用户那些需求变更需要收费，那些可以免费变更，防止用户无感知，随意变更。

4、变更的影响
需求变更会导致项目延期、开发士气低落，甚至是额外的收费
如果客户认为需求变更是必须的，就会接受这些代价。如果客户认为需求变更虽然有必要但是可以暂缓，双方签署备忘录，留待以后解决。
如果客户认为需求变更可有可无，多数情况下会取消。这个协商的过程一定要有，最后的结论最好有邮件发出来，或者走上面的变更流程。但是这些变更的代价一定要跟客户提前说，这样防止后面扯皮，说你没有提前告知。
这样既可防止用户频繁变更需求，也可以告诉用户不是所有的需求都需要立即修改。
一般来说，涉及核心业务的变更需求需要立即做，非紧急需求可待功能完善后再做。

5、评审后再干
让整个项目团队，包括上至老板、直到程序员，也包括外部的客户，都认同、理解并遵守一个基本原则，那就是程序员不直接接受任何非PM的需求，不接收任何非经过评审的需求——所有未经过评审的需求，只可讨论，不可执行。

6、控制节奏
遇到需要变更的需求，先分析下放进需求池，每一周或者每两周可以集中研究处理。不要让频繁变更的需求影响到整体项目的开发节奏。比如可以向用户提交一份各阶段需求变更的完成计划，注明需求提出人，提出时间，需求变更成本、是否收费、收费金额、是否确认变更，变更开发进度、预计完成时间等。

7、及时汇报
对于变更的需求要及时告诉领导，这样领导可以知道项目延期的原因，不会责怪团队，在和对方领导沟通的时候心里有底。团队负责人可以以日报、周报、月报的方式向领导汇报。可以以邮件或者定期的项目汇报会的形式告知，这个可以根据领导的喜好和项目的节奏自行决定采用的形式。

产品经理作为引路人，尽可能的让不确定性的因素，变为确定的，可被执行的流程、方案。