产品研发阶段：To B软件产品设计流程总结

本文作者结合自己的实践经验，分享了To B软件产品设计在产品研发阶段的相关工作，并对各个环节需要注意的问题进行了分析总结，供大家一同参考和学习。

产品研发阶段可以说是最考验产品经理协调沟通能力的时候，因为在这个阶段，产品经理的主要工作都在嘴上，跟研发大佬要人、要排期；跟所有研发团队的每个人对需求、回答问题；跟测试团队的每个人对需求、回答问题；跟市场团队沟通市场预热活动……这个阶段的产品其实最像是打杂的~~~ 好多产品也是栽在这个阶段。既然都是口头工作，接下来咱们聊聊这里面的一些我认为还算有效的工作方法和技巧。

产品研发流程通常是按照技术选型、功能开发、功能测试这几个阶段来执行的，大部分企业有专业的项目经理来负责排期和盯进度，我们公司没这个条件，都是由产品直接跟技术对接的，幸亏我是研发、项目经理、产品的转型路径，还能勉强Hold住。所以，我会在介绍各项工作内容的过程中穿插一些项目管理的东西，我的工作方法真的不一定适合所有人，大家批判的看吧，以参考为主。

一、总体沟通

能进入这个阶段，就说明你负责的产品的市场机会（MRD）已经得到了公司大佬的认可了，有了大佬这颗大树，你就可以开展后面的活动了。首先要做一次整体的沟通，这个沟通一定要开会，参会人员包括：

• 技术组的老大（一般是技术总监，根据实际情况来，一般得是给你安排人、排期的人），
• 产品这边的相关人员（一般产品总监得参会，得跟技术总监那边的大佬Level对等）
• 团队人员都叫过来（我们一般这个时候还没有正式开始，所以只安排了二级Leader）
• 市场相关人员
• 销售相关人员

大家开个会统一一下意见，这个会主要从以下几个方面给大家做个介绍：

1. 产品整体情况（从MRD里面捞干的说）
2. 各主要功能的开发时间评估
3. 各功能模块优先级
4. 本期准备开发的功能
5. 预计的开始时间和上线时间

开这个会的目的有几个，一方面跟大佬们统一意见，让大家了解即将开始研发的产品内容已便于大佬们（或者安排下面人）构思产品整体框架；最重要的是跟各部门大佬们混个脸熟，以后找他们的时候，不会一脸懵逼的想这哥们儿是谁。

开会的时候一般会记录会议纪要，各大佬的提出的问题一定要记着，会上能回答的就会上回答（要在会议记录里面体现），会上不能回答的，要做个QAList，会后研讨解决了，通过邮件发给提出问题的大佬，同时抄送参会的其他人员，如果还有追加问题，也都通过QAList统一做记录、跟踪，所有大佬提出的问题一定都要有响应、有回答，直到对方满意为止。

这样做的目的是要让流程闭环，不要遗留任何问题到后面的阶段，一旦遗留了问题，这个问题一定会变成一个巨大的坑，越是小问题，越会在项目即将结束的时候爆发出来，影响越大。很多公司都有相关的系统，我们没有，所以QA是我自己用Excel维护的，大概是这样的：

• 引入阶段：这个时候你就要写XXXX年XX月XX日项目沟通会
• 当前阶段：那就是立项阶段
• 问题描述：直接从会议纪要里面摘，千万别改，就是原来的问题
• 提出人：提问题的人的名字
• 目标解决日期：预计你要那天解决
• 解决人：这个问题要谁来解决，要有具体的人
• 解决方案：预计这个问题应该怎么解决，主要描述思路和方案
• 实际解决日期：提出方案是啥时候提出来的
• 状态：Open、Close两个状态，Open就是还没解决，Close就是已经解决了；
• 确认：OK、NG两个状态，OK就是提出人对解决方案满意，NG就是不满意。

这个问题列表是要贯穿在整个项目进行过程中的，各个阶段提出来的问题都要记录在这个问题列表中，后面要持续追踪，一定要闭环。

这里举个例子：比如说研发大佬提出一个技术上的问题，可以提出解决方案，但是具体是在研发阶段才能解决，那么状态不能是Close，直到研发的人确认这个已经体现在这个阶段了，你才能设置成Close，同时发给提出人让他来确认。

总体沟通会开完了，你和其他部门的思想也都统一了，研发那边会给你安排人（开始至少会安排几个Leader级别的人），就可以开始下一步的工作了。

二、讲解PRD

确定了研发的人，你首先要做的就是给他们讲产品设计，这个阶段大家关注的应该就是产品功能实现本身了，你要拿着这一期要开发的功能列表、优先级、PRD来讲。一般讲解的顺序是：

1. 讲需求列表和优先级，要让具体研发的人对产品功能有一个整体上的判断；
2. 讲PRD，让研发人员对具体实现有个认识；
3. 讲注意事项，比如预计多少用户啦、预计并发量啦、客户环境情况等等，这些小细节都是会影响到他们技术选型工作的。

如果设计的产品功能比较多，建议分开几次会议讲，讲完了要让研发消化一下，按照我的经验，一般是隔一天讲一下，当然有时候研发那边没那么多时间，那就得集中讲了，不过集中讲内容会比较多，效果不太好。

讲解的过程中、讲解后一般研发会问很多问题，这个问题也要记录在项目问题列表里来做整体的追踪，上面已经讲过了，这里就不再讲了。

注意，研发人员在考虑问题的时候，会从技术层面把场景扩大化，那么他们提出来的问题可能是问题，可能是风险。如果识别出来是风险，那就要把问题转为风险管理。我们也没有风险管理的系统，都是我自己追踪的，所以做完了大概是这样子的：

• 风险类别：那就是说什么类型的风险，我一般划分为资源风险、业务风险、管理风险和技术风险；
• 风险来源：就是说风险可能从哪儿来，我一般会划分为客户、技术、工程过程、人力资源、设备；
• 风险描述：说明一下啥风险，一般是可能造成项目延期的，一定是可能造成；
• 风险影响：就是这个风险一旦真的发生了，可能造成啥影响；
• 风险发生现象：就是告诉大家怎么判断风险真的发生了；
• 跟踪时间：就是到那天或者什么阶段，可以判断这个风险发生的可能性没有了；
• 可能性：发生可能性大概是多少；
• 风险等级：根据影响判断等级，一般是高、中、低，高等级一定要每天都跟踪；
• 处理放式：就是风险发生了咋处理，一般包括接受、避免、转移、减缓；
• 应对措施：就是根据你选择的处理方式描述你准备咋应对，以最大化降低影响；
• 状态：状态分为开放、关闭、忽略、转为问题。开放就是还没发生，有可能发生，关闭就是肯定发生不了了；忽略就是影响不大，发生就发生吧；转为问题那就是真他娘的发生了，已经发生了就不能叫风险了，叫问题，得放到问题列表中去处理解决。

三、技术选型

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!