产品研发流程大体分为:立项阶段、设计阶段、开发阶段、测试阶段、上线阶段、运营阶段。
主要分为需求搜集和PMO(或产品委员会)立项。需求搜集阶段可以很长,包括如下内容:
如果是从0到1或者彻底重构的产品,要先进行BRD的输出。包括整体行业的分析,到竞争对手分析,再到roadmap和对应资源匹配。用BRD进行宣讲,才能向上申请资源进行立项。
然后,可能是MRD的输出或者拆解执行。MRD在很多公司会以年度规划的形式提前进行输出,主要是产品roadmap和进度计划。到了某个立项阶段,会根据市场、战略、竞品、技术、渠道等情况,调整版本实现的功能模块以及优先级。当然,还有最重要的项目里程碑计划。
最终输出物基本是立项报告,然后邀请PMO或产品委员会进行立项评审。
主要分为需求池和PRD两大块:
基于立项阶段的MRD、上版本遗留问题和运营反馈的问题,列出概要清单。
然后召集项目成员,进行概要评审。这个评审一般是可行性、优先级以及成本的评审。评审通过的功能,细化成功能清单。
也存在研发业务背景较弱,概要已经要很细,功能清单要更细,以评估合适的工作量。上述的一个概要,需要拆成:
主要输出物是原型和需求规格说明书,部分小版本甚至不输出需求规格说明书,业务流程、页面流程、交互说明和异常处理都会在原型上体现。
B端比较重视文档,在部分敏捷开发的C端,原型也是以逐个拆解的线框图为主。
这样有以下好处:
绘制原型之前要进行整体的业务建模,力求梳理清楚全部的业务流程和必要信息。
在绘制草图时,要多和UI设计师交流,找到更合适的呈现形式。
在原型评审的时候,先介绍这些流程,再看具体的原型页面。原型评审结束,前端研发可以开始部分页面的UI开发,UI设计师准备视觉界面的输出。
需求规格说明书,需要拆分各业务领域进行输出。一个产品一个需求规格说明书,整个文档会非常的大。加上大量的修订和批注,产品人员维护起来很痛苦。编写需求规格说明书期间,要保持和架构师(开发经理)的沟通,在文档中完善业务逻辑。为了保障文档质量,目前文档是基于用例的形式编写的:
这样能更好的和测试进行沟通,减轻测试用例输出的工作,更专注于自动化测试。
需求规格输出完成,需要进行需求评审。由于内部项目动辄3个月,这个会议至少需要1-2小时。拿着几十上百页的文档过,开始还好,半小时后大家就注意力涣散了。
目前使用PPT进行需求评审,只关注业务流程和关键因素,反馈效果很好:
具体文档可以回去后进行查看,配合项目管理工具登记具体的问题,产品人员进行修复。
主要是进行项目的计划排期,不展开讲。内部有开发经理角色,可以将这个任务交给开发经理。
如果不是第一个大版本,基本是业务时序图、数据结构的设计。由研发输出,测试、产品进行评审。
该阶段事情最为繁杂的,包括但不限于:
主要有以下工作:
发布运营阶段很重要,工作也比较零散:
B端客户一般有定制化诉求,会以项目交付的形式进行落地。并且公司内部要求每个版本有验证客户,完善产品到实施的知识转移。工作流程如下:
整个大流程里面,产品经理可能会在涉及以下工作: