“具体”的力量

大部分的需求评审会都是过场，大家下面玩玩手机，产品经理在上面对着需求文档读一遍，再开开心心散会，除了浪费了时间，什么用都没有。这里最大的问题不是参会的人员不负责任，而是需求评审时的方案不够“具体”。

在此之后，我经常提醒自己，对于重要的功能也要尽可能在前期把 Demo 做得具体。最好是动态的，让评审的人可以有真切的体验，把可能的问题都尽早暴露出来。

哪怕没有做成动态的，只是一张张截图，在评审的时候你也可以通过讲故事的方法让它变得具体。比如你可以展示一个界面，边引导大家边说：“现在我是一个从朋友圈打开 xx 的用户，我看到的页面是这个样子。”——这样代入具体场景，才能让大家产生真感觉。

变更时机的选择

最好的变更发生在需求分析过程中，在产品经理脑子里

第二好的时机是在需求文档结束，工程师接手前，这是的修改可能会造成需求分析延期，

在工程师接手后，情况会变得有点复杂，这时的变更就会产生实际的开发成本了，有的变更很小，比如文案之类的，随时发现随时提，提的同时记得改掉文档描述。
稍微大一点的功能，则最好在发现变更后就立即跟开发沟通，去判断合适的变更时机，有时候工程师还没有做到这一部分，那就不会产生什么额外成本，有时候工程师已经做完了，你要比对一下变更的优先级和可能带来的延期再做决定。

如果你的项目组里有专职的 QA，这时候最好也让 QA 参与进来。如果涉及流程和架构上的重大变更，更要立刻与整个项目组沟通，有可能连设计都要推翻重做，

如果项目基本完成开发，箭在弦上准备发布了，这时的态度是应该是能不变就不变，可以先上线，通过运营的手段稳一下线上，然后尽快迭代做修改。

总之，原则就是如果开发接手后有变更的想法，一定尽快跟工程师沟通，不要自己去猜测成本，而是让开发去做判断，然后再综合沉没成本和额外增加的成本去做评估。

让团队能消化需求变更

有时需求变更也有积极意义。因为变更是响应变化，在互联网行业里，每天刀光剑影，瞬息万变，市场上发生的事情传递到产品和服务上，越快越好。

我体验过一个叫作“需求基线”的环节，就是需求确认结束以后大家签字画押，承诺绝对不变，连文档的编辑权限都封存，然后开发才接手，所有需求变更都必须审批到高管，启动一个冗长的评审程序。
这个制度导致的直接结果就是大家开始互相推诿，然后文档变得极其庞杂，效率降低，需求冻结以后，即便发现了问题和错误大家也不乐意提，就眼看着错的做出来了以后再说，整个产品线的节奏越来越慢，士气很快就磨没了。

后来大家慢慢意识到，这个本意用来限制甲乙方权责的流程不该在互联网公司中采用，也就逐渐废掉了。

产品经理脸皮虽然厚，但也是肉做的。如果整个团队都抗拒变更，一出现变更都恨不得把产品经理点了，他们也会慢慢变得保守，变得犹豫拖沓，最终伤害的是整个团队的利益。