敏捷流程中的产品管理

标签: 产品经理 产品管理 敏捷开发 | 发表时间:2016-04-27 03:30 | 作者:Ella
分享到:
出处:http://www.woshipm.com

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

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


人人都是产品经理微信公众号:woshipm,随时随地,学产品、学运营,听讲座。

相关 [敏捷 产品管理] 推荐:

敏捷流程中的产品管理

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

《Scrum敏捷产品管理》读书笔记

- - CSDN博客研发管理推荐文章
提到产品管理,在Scrum中,首先就想到的角色是产品负责人. 因此我们先来看看产品负责人(Product Owner),以及这个角色的特征:. 然后对于大型产品而言,一个产品负责人是不够的,所以存在产品负责人扩展的问题. 对于产品负责人,常见的问题有:. Kano model (卡诺模型)可以帮助我们选择合适的功能,开发出吸引人的产品.

敏捷

- - 人月神话的BLOG
对于敏捷开发,我前面其实已经有很多文章提到了,再次强调下敏捷的核心思想个人理解为三个重要的方面. 其一是需求的条目化并以需求点进行的全程追踪和跟踪;其二是短周期迭代;其三是基于持续集成思想的进度和质量可视化. 对于敏捷开发本身,对于很多内容我仍然坚持自己的观点,具体如下:. 对于大型全新系统的开发,如果是以底层数据为核心的业务系统,则不能单纯的应用敏捷开发.

忘记敏捷

- Guan - 所有文章 - UCD大社区
瓦沙奇山下那段著名的敏捷宣言,至今已近十年. 似乎在不经意之间,敏捷已经被视为 CMM 之后又一次软件开发领域的浪潮,不论业界报道或者坊间传闻,都不约而同地将敏捷视为一个时代的开始,与之同存的是那些未尝或浅尝敏捷者的各种质疑和争论. 当敏捷在介于自发与非自发中间演变成为一种近乎“革命”的运动,围绕在它身边的躁动就不曾停歇,对于细节的争执,对于方法的固执,让我们更多地为敏捷的未来忧心忡忡.

在敏捷

- - 崔凯
这是在 www.scrum.org 网站上轮播的一张图,网站上 SCRUM GUIDES 一栏,详尽的介绍了敏捷开发的方式和方法,有兴趣的可以看一下. 这里仅谈一下 Scrum 怎么玩更舒服. 回到那张图,想玩的舒服,一起聊聊很重要. Scrum 不是定死的一种模式,每个团队有每个团队的玩法. 通过不断的磨合、反思、改进,形成最适合自己团队的模式.

产品管理:用流程规避风险

- Dynamic - 所有文章 - UCD大社区
最近一直在跟的一些项目,过程中出现了一些反复,原因有很多. 深入分析一下问题根结,希望以后能避免. 关键词:产品负责制、确认层级机制、产品脊梁、靠谱. 1、项目初期,产品原则已经开会统一、皆大欢喜,但中期却在产品原则上出现分歧. 甚至在产品面临上线时,还有人为该产品赋予新的定位. 2、产品设计环节中,在产品需求和定位已确认的情况下,纠结在“不符合需求、偏离定位”的设计细节,僵持不下、浪费时间、拖垮精力.

产品管理的前世今生—昨天

- Frank Cai - 《程序员》杂志官网
作为“产品管理的前世今生”系列文章首篇,本文介绍了产品管理体系所依赖的理论基础、所属的学科范畴、经历的阶段以及一些常识性的概念错误. 说到产品管理体系的诞生,问10个产品管理者,会有9个告诉你宝洁的故事. 确实如此,国内几乎所有的产品管理者,不分行业,都无一例外地知道产品管理者诞生于宝洁公司,并以此作为工作的标杆而津津乐道.

产品管理过程的核心管控方法

- - CSDN博客推荐文章
产品管理过程是一个复杂过程,好的管理者都知道如何抽丝剥茧,让复杂的过程简单化. 最近也有很多人问我,我们在产品管理过程中有什么好的思路可以分享. 首先,我相信不同的PM有不同的方法,没有所谓的一定最好,只有通过实际环境使用过才能逐步形成自己靠谱的方法. 抽出一些时间,我把我认为较为有效的经验大致整理了一下分享给大家.

敏捷个人和敏捷开发

- beralee - 博客园-首页原创精华区
    自2001初成立了敏捷联盟到现在10年的推广,敏捷开发已日渐成为当前IT行业软件开发的一种主流方法. 没有银弹,任何方法都不可能解决所有问题,反而方法应用本身还会带来新的问题. 我在今年6月份上海举办的ScrumGathering中进行了一场敏捷个人话题的分享,我说到,想要Doing敏捷并不难,只要花上几天功夫学习敏捷知识之后就可以在小范围团队中去实践了,而要做到真正的Being敏捷则并不容易,而导致并不是真正敏捷的原因中,人是一个主要问题之一,这也是为什么现在敏捷社区中对人开始越来越关注的原因.