产品研发阶段可以说是最考验产品经理协调沟通能力的时候，因为在这个阶段，产品经理的主要工作都在嘴上，跟研发大佬要人、要排期；跟所有研发团队的每个人对需求、回答问题；跟测试团队的每个人对需求、回答问题；跟市场团队沟通市场预热活动……这个阶段的产品其实最像是打杂的~~~ 好多产品也是栽在这个阶段。既然都是口头工作，接下来咱们聊聊这里面的一些我认为还算有效的工作方法和技巧。
产品研发流程通常是按照技术选型、功能开发、功能测试这几个阶段来执行的，大部分企业有专业的项目经理来负责排期和盯进度，我们公司没这个条件，都是由产品直接跟技术对接的，幸亏我是研发、项目经理、产品的转型路径，还能勉强Hold住。所以，我会在介绍各项工作内容的过程中穿插一些项目管理的东西，我的工作方法真的不一定适合所有人，大家批判的看吧，以参考为主。
能进入这个阶段，就说明你负责的产品的市场机会（MRD）已经得到了公司大佬的认可了，有了大佬这颗大树，你就可以开展后面的活动了。首先要做一次整体的沟通，这个沟通一定要开会，参会人员包括：
大家开个会统一一下意见，这个会主要从以下几个方面给大家做个介绍：
开这个会的目的有几个，一方面跟大佬们统一意见，让大家了解即将开始研发的产品内容已便于大佬们（或者安排下面人）构思产品整体框架；最重要的是跟各部门大佬们混个脸熟，以后找他们的时候，不会一脸懵逼的想这哥们儿是谁。
开会的时候一般会记录会议纪要，各大佬的提出的问题一定要记着，会上能回答的就会上回答（要在会议记录里面体现），会上不能回答的，要做个QAList，会后研讨解决了，通过邮件发给提出问题的大佬，同时抄送参会的其他人员，如果还有追加问题，也都通过QAList统一做记录、跟踪，所有大佬提出的问题一定都要有响应、有回答，直到对方满意为止。
这样做的目的是要让流程闭环，不要遗留任何问题到后面的阶段，一旦遗留了问题，这个问题一定会变成一个巨大的坑，越是小问题，越会在项目即将结束的时候爆发出来，影响越大。很多公司都有相关的系统，我们没有，所以QA是我自己用Excel维护的，大概是这样的：
这个问题列表是要贯穿在整个项目进行过程中的，各个阶段提出来的问题都要记录在这个问题列表中，后面要持续追踪，一定要闭环。
这里举个例子：比如说研发大佬提出一个技术上的问题，可以提出解决方案，但是具体是在研发阶段才能解决，那么状态不能是Close，直到研发的人确认这个已经体现在这个阶段了，你才能设置成Close，同时发给提出人让他来确认。
总体沟通会开完了，你和其他部门的思想也都统一了，研发那边会给你安排人（开始至少会安排几个Leader级别的人），就可以开始下一步的工作了。
确定了研发的人，你首先要做的就是给他们讲产品设计，这个阶段大家关注的应该就是产品功能实现本身了，你要拿着这一期要开发的功能列表、优先级、PRD来讲。一般讲解的顺序是：
如果设计的产品功能比较多，建议分开几次会议讲，讲完了要让研发消化一下，按照我的经验，一般是隔一天讲一下，当然有时候研发那边没那么多时间，那就得集中讲了，不过集中讲内容会比较多，效果不太好。
讲解的过程中、讲解后一般研发会问很多问题，这个问题也要记录在项目问题列表里来做整体的追踪，上面已经讲过了，这里就不再讲了。
注意，研发人员在考虑问题的时候，会从技术层面把场景扩大化，那么他们提出来的问题可能是问题，可能是风险。如果识别出来是风险，那就要把问题转为风险管理。我们也没有风险管理的系统，都是我自己追踪的，所以做完了大概是这样子的：
给研发把事儿讲明白了，他们就要做技术选型了，这时候常规的产品经理存在感相当小，因为听了你也不懂。这时候作为研发出身的产品的我，优势就体现出来了。我们一般是技术会根据需求做好几个选型方案，做好了要开会给我们讲。一般产品需要从以下几个方面去看技术选型方面的内容：
一般从这五个方面去问他们，如果某一个方案没考虑就pass，如果能剩下一个方案，那就选这个；如果一个也剩不下，那就委婉的问问能不能再想想；如果都能剩下（那就是研发相当牛掰），就让研发自己推荐，他们肯定是有一个最满意的，如果你听不懂他们说啥你选第二推荐就行（因为他们最满意的肯定最复杂，别问我咋知道的）。
会后别忘了发会议记录，产品提出来的问题也是要做闭环管理的，研发那边也要回答的~ 他们那么忙肯定没时间吗，没关系，这小事儿，产品帮他来管理，时不时去问问就行。
都准备好了的话，就进入研发阶段了。这个阶段产品通常就是回答研发爸爸们的问题了，这方面我就不讲了，如果你产品设计过程中，都考虑到了，直接能回答最好，一般回答都是告诉他们以下信息点：
进入研发阶段最重要的就是要了解各功能的开发情况，我们是每天上午开个早会，大概15分钟，然后记录整体进度情况。因为我自己希望了解的更精细一点，虽然公司有项目管理的系统，我自己也弄了一个小的进度管理模板来记录进度信息，精确到天的，类似这样的：
这里面会把各个功能、团队、工作内容（他们告诉我的）、每天的情况做个记录。
每天记录完了跟总体排期去比对，这样你对整体上线时间就有相对比较精确的了解了。然后按照整体排期来催他们（催的时候千万带好小零食、奶茶、咖啡和个人护具）。
一般他们调完一个功能我们就会上去随便点点、用用，需求理解上的偏差越早发现对项目的影响越小。
我们的测试团队跟研发团队是一个团队，所以整体过程是一起管理的，不过产品一定要评审测试团队的测试计划和测试用例。测试计划里面重点关注的是测试启动条件、硬件环境、时间进度安排；测试用例关注的是测试的点对不对，测试内容是不是能覆盖到功能细节。还是老规矩，评审后的问题也要放在问题列表里面做跟踪。
另外，测试结束后要求提交测试报告，测试报告应该包括测试用例及测试结果；测试了几轮；BUG有没有收敛趋势；压力测试的报告等等。
我之前的公司甚至要根据代码行数来计算用例覆盖率、BUG残留率等等品质指标，现在好像这么计算的比较少了。
好了，经过一段时间的研发工作后，研发团队将给你提交以下几个成果物：
拿到这几个成果物了，我们产品就要开始我们的验收、市场支持相关的工作了，了解后续工作，且听下回分解吧。
市场分析阶段：To B软件产品设计流程总结
产品设计阶段：To B软件产品设计流程总结
本文由 @Jimmy.jing 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
关注微信
