敏捷流程中的产品管理

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

chanpinguanli

对于敏捷开发,讲它的价值、方法的内容已经够多。而对于需求、设计、测试这三个环节,如何适配并融入敏捷开发的流程,却着墨寥寥。本文主要从产品设计及需求表达两个方面,介绍如何在敏捷开发的背景下,保证产品设计不挖坑,并为开发人员提供的高效支撑。文中所述适用于中小规模的团队,产品形态以web端非成熟期产品为最匹配。

1.远粗近细,规划先行

在整个敏捷流程开始之前,应该先检视如下几项:

(1)BRD & roadmap

此时产品团队已经确定了所有大方向,以及达到这些方向的路径。

(2)外部环境中的关键时间节点

此时应该对接下来两次迭代以内的外部环境(如行业周期、市场压力、节假日等运营引爆点)有较为明确的把握,确保版本方向不会受迫产生较大的变动。

(3)需求池

此时可能已经积累有来自各方的需求,以及产品规划中预计要新增的模块。而每次迭代,需求来源都出自这个表格中。

根据以上,首先通过关键时间节点来修正产品roadmap,细化roadmap中距离当前最近的一段时间,颗粒度最细须达到完成一次敏捷开发的所需要的时间。关于最终细化出来的产品路线,产品经理的脑中一定要有非常清晰的节奏,明确每一步的整体目标。完成后,应该明确下一步迭代的两个内容,一是新增哪个模块/栏目,二是优化哪些功能、页面。

对于新增的模块,我们要让它单独进入敏捷开发流程,必须保证它是相对独立的,不会受到另一个未开发模块的牵制。如果不是,那么这些模块应该在同一次迭代中,以最基本(基本到只剩关键流程)的形态同时上线。

2.先加后减,解构产品

确保新增模块的独立性后,就到了产品设计的环节了。对于产品设计经验不是非常丰富的PM来说,此时,一定确保设计环节的完整,需求分析、用户任务和流程设计、产品结构决不能被“敏捷”掉。直接动手做流程和原型,无论时间多紧都不应该,反而会因为挖坑,导致在以后浪费更多的时间去反复填坑。

我在做敏捷设计的时候,倾向于经由完整的设计流程,产出相对完整的产品设计,然后根据敏捷周期,来对产品进行精简。这样不会因为后期丰富该功能时,由于思考不全面和先前没有一个明确的理想解决方案,而推翻重做或者有较大改动;也保证了产品功能拆分后,各个子单元在不同版本迭代完全时的产品一致性。

我们需要对完整稿进行拆分和优先级排序,找出主要流程、关键信息,先保证主线跑通,再考虑提升用户体验的辅助性功能,以及提升用户停留时长或提高转化率的信息丰富手段。

由于这个完整稿,本身就是用来试错的,那么,我们在细化需求的时候,可以先细化主线需求到能够交付开发执行的程度,而对于可能有变动甚至整体舍弃的其他分支,暂时到特性层面就可以了。

基于完整稿,我们可以提出几种拆分方案,在需求评审时,与开发团队讨论确定最终的目标方案。对于该方案,我们需要在方案内的特性中,再次排出优先级。目的是,让开发先做高优先级特性,如果遇到不可预估的困难,可以马上决策并削减优先级低的特性,保证主流程的完成,尽量弱化工程延期的不利后果。

3.简短明了,文尽其用

关于产品设计后的需求表达,我一直以来的原则就是不参考模板,灵活使用。在敏捷开发中,我们通常不可能去写全面啰嗦的PRD,移动端更甚。我的做法是,使用excel做产品backlog,省去所有对开发无意义的描述说明文字,从feature list直接获得。审视自己写下的每一个列首项,是不是对开发有用,省去所有无用项。

如果团队中没有专职测试,甚至可以将测试功能融合进backlog中,仅需增加测试结果与状态两列,而只要需求想的透彻,特性说明完全可以做基本的功能测试用例。

同时,该表格也可以融入项目管理的功能。状态列中,单元格为下拉菜单,分别有待开发、待测试、完成三个状态。

924112-a36bdd26b51303db

backlog表头示例

适合每个团队的文档形式各不相同,有的开发喜欢原型结合文档进行开发,有的喜欢看原型做,文档备查,这些都需要PM提前沟通,了解PRD的用户需求,砍掉无效的工作,制作出适合自己团队的文档形式,并自己保证花在文档上的时间,都是有效的。

 

作者:尘中之光(简书作者)

原文链接:http://www.jianshu.com/p/0127f8f7b3e2

本文由 @尘中之光 授权发布于人人都是产品经理,未经作者许可,禁止转载。

您的赞赏,是对我创作的最大鼓励。

评论( 2

登录后参与评论
  1. 学到了很多新姿势!

    回复
  2. 你好,看玩了你的博客,很精彩,能有你的联系方式多交流交流吗

    回复
加载中