目前的现状：
产品收集业务需求=>整理好=>撰写成详细的文档=>开粗评会议与细评会议。不过目前来说需求评审在细评阶段效率还是不高，仍有优化的空间。需求的不少内容在细评时还需要产品对于开发提出的问题同业务做二次确认，甚至更多。导致被迫超量沟通。这种超量沟通带来的问题是如果在一次再次的细评中开发又提出了新的问题，又可能会轮回。
这会导致几个问题：
1.开发迟迟不能按计划开工，这会对期望的上线时间造成影响，或者被迫压缩开发工期。也会衍生出由于工期不足而产生的质量问题。
2.如果开发提前开工，则可能发生在开发阶段出现需求变动的情况，也同样会产生交付时间与交付质量的问题。进一步会导致开发对需求变动而产生的抵触情绪。
3.需求的不完全明确导致产品同学在评审会上屡屡被怼的情况，这对产品同学很不公平。
4.产品同学花更多时间修改文档，再同步开发，导致不必要的时间成本开支。
5.最后开发做出的结果并不一定完完全全是业务想要的。
产生问题的原因：
1.产品对于需求的收集和转述不可避免会造成信息失真，导致业务与开发的信息不对等。
2.产品同学很难对每个需求都思考的面面俱到。
3.产品同学对需求收集后的技术可行性还需要进一步与开发确认。
4.开发并不一定百分百了解业务的真实意愿。
建议的解决方案：
1.产品同学在与业务收集高优先级需求后，召集业务、产品、核心技术骨干先行碰头，准确了解业务需求与可能产生的漏洞，降低反复沟通成本。
2.开发有责任辅助产品梳理缺陷与漏洞，也有义务准确理解业务需求，并确保需求一次细评并准确传达，降低分歧与不明确的现象出现。
3.也可以降低开发对于不明确的需求，不理解业务需求的吐槽与反感。
以上建议供大家参考，希望能小范围试行效果。
网友评论