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

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

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

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

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

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

一、总体沟通

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

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

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

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

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

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

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

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

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

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

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

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

二、讲解PRD

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

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

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

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

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

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

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

三、技术选型

给研发把事儿讲明白了,他们就要做技术选型了,这时候常规的产品经理存在感相当小,因为听了你也不懂。这时候作为研发出身的产品的我,优势就体现出来了。我们一般是技术会根据需求做好几个选型方案,做好了要开会给我们讲。一般产品需要从以下几个方面去看技术选型方面的内容:

  1. 性能以及扩展性: 就是你做的技术方案能不能支撑我预期那么大的并发量,后续如果我并发量更大你还顶不顶得住;
  2. 安全性: 就是你做的方案安全性能保证不?用户信息会不会泄露,有没有这方面的考虑;
  3. 产品自身安全性: 就是有没有可能被盗版;
  4. 可定制性: 就是如果客户改需求了,你能不能快速对应;
  5. 升级: 就是产品有BUG或者有了新特性,咋给人家升级。

一般从这五个方面去问他们,如果某一个方案没考虑就pass,如果能剩下一个方案,那就选这个;如果一个也剩不下,那就委婉的问问能不能再想想;如果都能剩下(那就是研发相当牛掰),就让研发自己推荐,他们肯定是有一个最满意的,如果你听不懂他们说啥你选第二推荐就行(因为他们最满意的肯定最复杂,别问我咋知道的)。

会后别忘了发会议记录,产品提出来的问题也是要做闭环管理的,研发那边也要回答的~ 他们那么忙肯定没时间吗,没关系,这小事儿,产品帮他来管理,时不时去问问就行。

四、研发阶段

都准备好了的话,就进入研发阶段了。这个阶段产品通常就是回答研发爸爸们的问题了,这方面我就不讲了,如果你产品设计过程中,都考虑到了,直接能回答最好,一般回答都是告诉他们以下信息点:

  1. 这个内容是啥样的;
  2. 为啥是这样的;
  3. 实在做不成这样的话,你说你能做成啥样的;
  4. 那行吧\先这样吧\那不行,咱要不再商量商量。

进入研发阶段最重要的就是要了解各功能的开发情况,我们是每天上午开个早会,大概15分钟,然后记录整体进度情况。因为我自己希望了解的更精细一点,虽然公司有项目管理的系统,我自己也弄了一个小的进度管理模板来记录进度信息,精确到天的,类似这样的:

这里面会把各个功能、团队、工作内容(他们告诉我的)、每天的情况做个记录。

  • StandBy就是还没开始
  • Plan就是计划开始了
  • Doing就是正在做
  • OK就是做完了

每天记录完了跟总体排期去比对,这样你对整体上线时间就有相对比较精确的了解了。然后按照整体排期来催他们(催的时候千万带好小零食、奶茶、咖啡和 个人护具 )。

一般他们调完一个功能我们就会上去随便点点、用用,需求理解上的偏差越早发现对项目的影响越小。

五、功能测试

我们的测试团队跟研发团队是一个团队,所以整体过程是一起管理的,不过产品一定要评审测试团队的测试计划和测试用例。测试计划里面重点关注的是测试启动条件、硬件环境、时间进度安排;测试用例关注的是测试的点对不对,测试内容是不是能覆盖到功能细节。还是老规矩,评审后的问题也要放在问题列表里面做跟踪。

另外,测试结束后要求提交测试报告,测试报告应该包括测试用例及测试结果;测试了几轮;BUG有没有收敛趋势;压力测试的报告等等。

我之前的公司甚至要根据代码行数来计算用例覆盖率、BUG残留率等等品质指标,现在好像这么计算的比较少了。

好了,经过一段时间的研发工作后,研发团队将给你提交以下几个成果物:

  • 产品包(线上的或者安装包)
  • 产品部署手册(线下一般有)
  • 产品测试报告

拿到这几个成果物了,我们产品就要开始我们的验收、市场支持相关的工作了,了解后续工作,且听下回分解吧。

#相关阅读#

市场分析阶段:To B软件产品设计流程总结

产品设计阶段:To B软件产品设计流程总结

 

本文由 @Jimmy.jing 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

随意打赏

提交建议
微信扫一扫,分享给好友吧。