产品研发体系中的需求承接与输出

　　近日，W公司的运营总裁（兼管部分产品输出）对忠哥大吐苦水，感慨研发团队无法按时将运营和产品输出的需求转化为研发成果，总是在执行过程中会出现各种各样的问题和障碍，研发人员抱怨需求不明确，变化太大老是返工，产品与测试人员疲于奔命，应付各种产品障碍的局面，于是，我俩深聊了一次，问题浮出水面。

　　W公司在产品需求的交接过程问题如下：

　　　　1.产品需求输出以页面为主，缺乏总体的需求愿景介绍，需求的提出以运营总裁为主，开发人员甚至设计需求的产品经理都未能理解该需求的意义，研发成果的可用性大幅度降低；

　　　　2.运营输出的表达缺乏规范，与产品管理模块划分有关，研发人员鉴别产品bug耗费较多精力；

　　　　3.研发人员对产品理解力缺失，究其根由，是产品理念输出时，产品经理采用了灌输方式的的产品需求输出，多数开发人员未能理解产品需求，机械式研发，返工量巨大。

　　理想的产品研发体系中，承接产品研发需求的理想职位是产品经理，实际研发中，人们总是希望产品经理和研发负责人可以理解，设计并沟通所有的产品细节，所有需求经过他们的设计与架构体系建设，并推进实现，但往往不尽如人意。实际研发过程，由于经验或精力或投入度方面的原因，产品经理没能把产品需求设计到足够的关键细节，就产生了需求的盲点，研发人员产生负面反馈的可能性很大，研发负责人也有同样的问题，如果在产品需求细节投入精力过多，自然无从处理架构问题，况且需求量大到一定程度，精力也无法保证。

　　在W公司中，产品经理经验尚浅，研发人员业务理解较少，普遍未找到产品的感觉，但研发人员积极性可以，未出现怠工情况。

　　针对W公司的情况，以如下对策实施解决：

　　　　1.设立明确的产品模块概念，建立统一的运营沟通名词与概念，便于需求的准确沟通传达；

　　　　2.增加产品需求愿景看板，分两部分展示，展示除当前开发任务之外，产品1-3个月之内规划发布的需求，以及产品3-12个月内的规划目标，无论是产品经理或是研发人员都有统一明确的愿景目标；

　　　　3.产品理念，产品需求输出方式变更，改为用户用例讲解方式，有点类似敏捷开发中的userstory，又有点像传统开发过程中的测试用例，代入感较强的产品沟通方式，需求承接人（研发，测试甚至是产品）的理解难度大幅下降。

　　产品需求的输出与承接，是产品研发的关键工作，决定着需求落地的精度与效率，定好需求管理规划的同时，长征已经成功了一半。

　　愚者，共勉！