2B产品经理，在研发过程中不容忽视的5大坑

　　作者总结了自己在一个2B产品研发过程中遇到的几个坑与大家分享，希望可以給各位带来帮助。
　　2B产品经理，特别是创业公司的2B产品经理，往往战斗在和客户沟通需求的第一线，同时也身兼和组内或者公司内开发对接、调整需求的第一责任人。由于信息在传播过程中难免会有损失，以及客户变更需求简直比女人翻脸还快，所以，研发过程中如何和需求方（客户）保持良好沟通以此来保证产品顺利交付已经是2B产品经理的生存必备技能之一。
　　以下几点是我在上一个2B产品研发过程中遇到的几个坑，希望可以帮助到正在遇到同样问题或者可能遇到类似问题的你。
　　1。畏惧客户，若不是客户主动联系绝不会主动多问一句
　　这个简直可以是2B产品研发过程中的命门死穴般的大忌。为什么这么说，主要是由于2B客户尽管是需求方，但是他们对于自己想要什么，以及能够提供什么，后期如何配合我们的工作几乎可以算是一无所知。只经过简单的几次需求沟通会议，就定下来的需求清单是经不起推敲的。或许大流程走下来是没有问题的，但是诸多细节都必须和客户一一对过。
　　有些产品经理生性害羞，有的产品经理甚至会觉得客户三天两头改需求真“烦”。对于这些产品经理，几乎可以预料到在中期交付的产品功能一定和客户最初所想相差甚远。如果需求方吹毛求疵起来，少则要增减一些字段。更多的则直接是底层逻辑修改。到时候别说开发了，估计老板想要掐死产品的心都有了。
　　比如：在上个项目中我负责的一个O2O产品。其中时间控件的设计需要考虑到该服务点的承载量。而且作为一个全局控件，在多个页面以及主功能流程上都有用到。最初需求沟通的时候我仅仅沟通了营业人员上下班时间。但后来开发过程中我发现还需要考虑到节假日上班时间以及服务站点的营业时间。若不是及时沟通，后来要修改的接口数绝不会少。
　　2。觉得关注产品研发进度是项目经理的事情
　　有的大公司里项目经理和产品经理之间有明显的界限，这些公司的项目经理往往具备技术背景并且在公司里有一定的声望。针对这种情况，产品经理其实不必过多过问产品研发进度，定期和项目经理合一下就好了。但是更多时候公司里的项目经理不怎么“给力”，或者公司领导直接兼任项目经理。这时产品经理还是最好跟跟项目进度。毕竟我们是战斗在第一线的人，面对需求方和老板的随时发难，要做到胸中有谱。另外还有一点，就是经常和研发过产品进度，可以帮助我们更好的把控产品研发新走向，除了额外可以学到技术上的零碎东西，有时候还可以替研发同事们排忧解难。
　　比如原型上的某个控件开发难度比较大，及时更换为网上已经封装好的用开源控件，可以节省下不少人力成本。再比如有时候交互上的一点逻辑调整可以让后台工程师直接减少几十行的Code数。
　　3。不和产品的实际使用者确认产品Demo
　　我个人觉得让产品实际使用人员在设计阶段就参与进来是件不错的事。大家都知道2B产品需求对接方往往是企业管理者，他们往往不实际使用，或者并不是使用产品最多的人。他们最关心的不是产品性能而是确保产品功能点能够Cover他们的业务线，让投入产出比达到配比最优。用户体验，产品交互细节等等对他们来说无所谓。对产品好坏最有发言权的人应该是产品的最终使用者。因此我们应该珍视他们的建议。有时候产品经理绞尽脑汁苦思冥想了很久的方案其实是脱离实际业务场景的。我们自嗨式的陶醉在某个交互里，但说不定在实际场景中并没有那么好用，甚至不能用。为了杜绝这种事情发生，我们应该从设计阶段到研发交付这段时间内都不断的让产品最终使用者参与进来。
　　比如，有些时候产品经理对实际的业务场景并不是十分熟悉，并不能特别好的掌握产品的实际业务层级。这个时候”卡片分类法”就派上用场。让实际使用者来为我们出谋划策。另外，产品即将交付的时候找来几个实际使用者做冒烟测试也是不错的选择。他们是最熟悉自己业务场景的人，几乎可以测试到所有在实际业务中高频的场景。若真的存在流程问题，我们可以及时调整优化。
　　4。不重视文档更新、部门内的报联商
　　由于工期短、人手往往短缺、资源不足这样的现状下导致2B产品需求变更非常频繁，每一次更改都需要更新文档。但忙起来常常容易遗忘掉，从而酿成许多不应该犯的错误。很多时候和客户沟通后，我们更改了原型上的一处小细节，并且通知了我们自以为会影响的开发，但这中间总会遗漏一些人。并且在研发后期极易出现扯皮。
　　比如测试验收的时候发现界面多处对不上。移动端同事说：“我就是按照原型开发的”，然后打开了手头两个月前你发给他的原型，但测试手头的原型是你昨天发给他的最新版，其中就页面层就有至少20多出的细小修改。这部分的人力成本谁来Cover呢？这个锅恐怕最后还是会让产品背。
　　好的需求文档管理方式有很多种，我就不班门弄斧了。自己常用方法是最简单的一种：每次更改原型后都会邮件发送整个项目人员。邮件正文中我会简要标明本次修改点，并明确告知最新文档的地址。
　　文档命名方式：产品名称版本号修改日期；
　　文档更改记录：RP原型文件上有更改记录、若有其他PRD也在表头首先注明文档更改的部分
　　不给对方和自己扯皮的机会，也不会因为自己的失误、遗漏增加他人的工作量，是我们和开发之间信任的基石。
　　5。不做产品复盘会
　　但凡渴求进步、蒸蒸日上的公司、项目组都会在产品发布完毕后开一个小小的产品研发复盘会。分析下从立项到结项这一系列过程中部门的得与失。至于怎么开、开的质量如何其实和领导气质有很大关系。我们作为小小的PM有时候想使劲也使不上来。但至少应该做好自己的那一份。也就是在产品复盘会上认真深刻的反思项目中产品层面的得与失。
　　其中应包含的内容有：本次研发过程中产品部门做的好的点，不足的点。对于不足的点尽可能说的细一些，理解的深刻一些，最好可以深挖出不足的深层原因，并提出相应的解决对策。只有自己总结出的足够深刻的见解才能在脑海中形成记忆。作为产品经理应该珍惜每一次产品复盘会的机会。不仅是自己重新审视整个项目从0到1的机会也是一个自我学习、迭代的好机会。这次的闪光点就是将来的宝贵经验。这次的失败之处就是以后重点关注的内容。