产品经理怎么改需求，才不会被研发“砍死”？(2)

注：很对团队都是用邮件来同步、保存需求，在项目管理过程中很容易出现需求文档版本混乱的问题。工欲善其事，必先利其器，产品经理都应该在团队中推动建立一套好的需求文档管理系统，例如 GIT 就非常好。

无论是正式或者非正式的，我们有必要将需求变更的情况告知相关同事，包括需求方、研发同事。

尤其是测试的同事，很多时候在讨论需求时，开发或多或少会参与，但往往测试的同事直到发现实现和需求不一致时，才知道需求变更了。这也会带来他们的重复工作和测试质量的降低。

我们需要至少说清楚两件事：

（１）阐明需求变更的原因

如果是自己的锅，请主动的背起来。如果是老板的锅，请充分沟通理解之后，也主动的背起来，不让自己变成老板的传声筒。背的时候，注重对变更价值的陈述，让相关人都能明确变更的意义。人人都希望自己做的事情是有价值的，描述清楚变更的价值，有助于后续工作的开展。

（２）明确新的项目排期

对于研发的同事，项目排期是否变化决定了大家阶段性的工作压力。如果争取到了变更需求的开发时间，大家可以保持工作节奏，以相对轻松的状态应对变化。如果项目排期无法改变，需要大家加班的话，也请备好零食饮料，全程陪同。

对于需求方，原有的计划可能有一系列后续工作，如果需求变更会导致项目延误，需要告诉后续同事注意调整工作计划。同时这也是再一次告知需求方这是我们团队为需求变化买的单，未来需要更加审慎。

注：如果老板是需求方，最后评估下来需要调整当前项目，特别是影响到其他项目的排期，需要做好向上管理的工作。因为层级之间往往存在信息不对称，对于整体项目的优先级判断可能会出现不一致，要及时沟通。

很多同学害怕被同事 K 而不敢做需求变更，尤其是一些设计初期没能考虑到的细节问题，研发一旦做出来之后，产品同学发现了也不敢提出修改，放弃了对产品体验的有效把握。

这种情况，我个人有个习惯是在每次研发前跟研发的同事约定一个产品体验变更期。当产品初版出来之后，我会集中把产品从头到尾感受一遍，找出体验上的细节问题。有了事前的沟通和项目排期，大家对体验修改的容忍度也会高一些。

也有的同学对其他人拍过来的需求来者不拒，全部都找研发同事改掉，而自己对于修改的原因和程度并不了解。久而久之，这样的修改程度会让研发团队疲于奔命，也把自己变成了需求方和研发团队之间的传话筒，丧失团队信任。需要回归原点，从用户需求出发，判断需求变更的价值。

有时候我们会因为排期已定，担心影响上线时间，连真正的问题也放过了。事实上，对于互联网研发项目，排期更多起的是参考作用，帮助衡量项目的进展情况。即使真的有重大不能延缓的项目，像618，双十一这类大促活动，我们也需要根据上线后的影响来决定是否修改，而不是仅凭排期做事。

最后，奉上不会被砍死的需求变更 32 字口诀：

目标出发，衡量价值，判断时机，做好沟通；

不怕质疑，不甘传声，灵活应对，顺理成章。

作者：蔡沁宇，公众号：勰门歪道（xmwd-666）

文章作者系 @蔡沁宇 未经许可，禁止转载。

（编辑：ASP站长网）