- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
实践:怎么做好研发阶段的产品工作
本文作者结合自己的实践经验,分享了To B软件产品设计在产品研发阶段的相关工作,并对各个环节需要注意的问题进行了分析总结,供大家一同参考和学习。
产品研发阶段可以说是最考验产品经理协调沟通能力的时候,因为在这个阶段,产品经理的主要工作都在嘴上,跟研发大佬要人、要排期;跟所有研发团队的每个人对需求、回答问题;跟测试团队的每个人对需求、回答问题;跟市场团队沟通市场预热活动……这个阶段的产品其实最像是打杂的~~~ 好多产品也是栽在这个阶段。既然都是口头工作,接下来咱们聊聊这里面的一些我认为还算有效的工作方法和技巧。
产品研发流程通常是按照技术选型、功能开发、功能测试这几个阶段来执行的,大部分企业有专业的项目经理来负责排期和盯进度,我们公司没这个条件,都是由产品直接跟技术对接的,幸亏我是研发、项目经理、产品的转型路径,还能勉强Hold住。所以,我会在介绍各项工作内容的过程中穿插一些项目管理的东西,我的工作方法真的不一定适合所有人,大家批判的看吧,以参考为主。
一、总体沟通
能进入这个阶段,就说明你负责的产品的市场机会(MRD)已经得到了公司大佬的认可了,有了大佬这颗大树,你就可以开展后面的活动了。首先要做一次整体的沟通,这个沟通一定要开会,参会人员包括:
技术组的老大(一般是技术总监,根据实际情况来,一般得是给你安排人、排期的人),
产品这边的相关人员(一般产品总监得参会,得跟技术总监那边的大佬Level对等)
团队人员都叫过来(我们一般这个时候还没有正式开始,所以只安排了二级Leader)
市场相关人员
销售相关人员
大家开个会统一一下意见,这个会主要从以下几个方面给大家做个介绍:
产品整体情况(从MRD里面捞干的说)
各主要功能的开发时间评估
各功能模块优先级
本期准备开发的功能
预计的开始时间和上线时间
开这个会的目的有几个,一方面跟大佬们统一意见,让大家了解即将开始研发的产品内容已便于大佬们(或者安排下面人)构思产品整体框架;最重要的是跟各部门大佬们混个脸熟,以后找他们的时候,不会一脸懵逼的想这哥们儿是谁。
开会的时候一般会记录会议纪要,各大佬的提出的问题一定要记着,会上能回答的就会上回答(要在会议记录里面体现),会上不能回答的,要做个QAList,会后研讨解决了,通过邮件发给提出问题的大佬,同时抄送参会的其他人员,如果还有追加问题,也都通过QAList统一做记录、跟踪,所有大佬提出的问题一定都要有响应、有回答,直到对方满意为止。
这样做的目的是要让流程闭环,不要遗留任何问题到后面的阶段,一旦遗留了问题,这个问题一定会变成一个巨大的坑,越是小问题,越会在项目即将结束的时候爆发出来,影响越大。很多公司都有相关的系统,我们没有,所以QA是我自己用Excel维护的,大概是这样的:
引入阶段:这个时候你就要写XXXX年XX月XX日项目沟通会
当前阶段:那就是立项阶段
问题描述:直接从会议纪要里面摘,千万别改,就是原来的问题
提出人:提问题的人的名字
目标解决日期:预计你要那天解决
解决人:这个问题要谁来解决,要有具体的人
解决方案:预计这个问题应该怎么解决,主要描述思路和方案
实际解决日期:提出方案是啥时候提出来的
状态:Open、Close两个状态,Open就是还没解决,Close就是已经解决了;
确认:OK、NG两个状态,OK就是提出人对解决方案满意,NG就是不满意。
这个问题列表是要贯穿在整个项目进行过程中的,各个阶段提出来的问题都要记录在这个问题列表中,后面要持续追踪,一定要闭环。
这里举个例子:比如说研发大佬提出一个技术上的问题,可以提出解决方案,但是具体是在研发阶段才能解决,那么状态不能是Close,直到研发的人确认这个已经体现在这个阶段了,你才能设置成Close,同时发给提出人让他来确认。
总体沟通会开完了,你和其他部门的思想也都统一了,研发那边会给你安排人(开始至少会安排几个Leader级别的人),就可以开始下一步的工作了。
二、讲解PRD
确定了研发的人,你首先要做的就是给他们讲产品设计,这个阶段大家关注的应该就是产品功能实现本身了,你要拿着这一期要开发的功能列表、优先级、PRD来讲。一般讲解的顺序是:
讲需求列表和优先级,要让具体研发的人对产品功能有一个整体上的判断;
讲PRD,让研发人员对具体实现有个认识;
讲注意事项,比如预计多少用户啦、预计并发量啦、客户环境情况等等,这些小细节都是会影响到他们技术选型工作的。
如果设计的产品功能比较多,建议分开几次会议讲,讲完了要让研发消化一下,按照我的经验,一般是隔一天讲一下,当然有时候研发那边没那么多时间,那就得集中讲了,不过集中讲内容会比较多,效果不太好。
讲解的过程中、讲解后一般研发会问很多问题,这个问题也要记录在项目问题列表里来做
原创力文档


文档评论(0)