敏捷开发用户故事系列(四敏捷开发用户故事系列(四-六)六)
敏捷开发用户故事系列之四:优先级排序
优先级排序听起来是一个很简单的工作,一个字段无外乎“重要/一般……”,调整一下然后按排序,就出来了。
但其实里边有不少名堂:谁应该负责排序工作?谁最终拍板?研发因素要不要考虑?需求依赖关系导致的顺序如何处
理?持续交付的考虑?商业决策的考虑?
以下知识与经验,来自于多个来源,主要是部分网上资料、实际项目的访谈,并在自己现在正在做的一个项目中得到
验证。具体应用时,应灵活掌握。
谁负责排序?谁负责排序?
Product Owner负责。
在产品研发环境中,一般是产品经理;在项目开发环境中,一般是项目经理。
作为产品或项目的掌舵人,这个人必须对产品或项目的概貌非常了解,从业务概貌到业务细节,都应该了解。从业务
这一点上说,了解程度要超过研发团队本身。
有些团队把排序工作交给客户,非常不妥。客户任何时候都只是浅层参与,随时可能会懒散、不专心,因此不要尝试
把主动权交给他们。即使此事必须通过客户,也要有内部相应的人加以把控,判断排序的真实性。
谁负责拍板?谁负责拍板?
要想既了解概貌,又了解细节,对产品经理(以下略去项目经理的情况)而言要求过高,这时候一般配备产品总监,
以在更高的层面把控方向。
产品总监的工作更倾向于长远化、市场化、人性化。比如很多消费电子类产品的产品经理负责研究新潮的功能,而产
品总监则负责研究“使用这些功能的新潮的人”。
研发因素的考虑研发因素的考虑
尽管一心一意希望按客户价值排序,但实际情况是往往制约于产品功能的技术实现和依赖关系,不得不做变通。
因此,应该考虑研发团队的介入。
什么?客户,产品经理,产品总监,研发团队……导致谁说了算?说对了,这时候一般需要“产品负责人团队”,即PO
团队。
第一次听到这种团队,是看一个国外游戏团队的开发经验。他们的产品负责人团队,他们引入了自己公司的高层、策
划人员(即需求开发和管理人员)、开发人员、发行商、热心玩家等等,最终工作由主策划(产品经理)汇总。
需求依赖的考虑需求依赖的考虑
其实多数需求依赖都可以被避开,比如没有“删除功能”,在开发的初期,一样可以登录数据库直接暴力删除。
但是这个会带来以后的问题,比如要持续交付,这个让客户怎么用?更深入的问题,下面继续谈。
持续交付的考虑持续交付的考虑
上次在MPD做培训的时候,有人问到一个问题大致如下:“我们是持续交付了,但是刚开始的产品缺胳膊少腿,界面也
不美观,客户看了直摇头,对我们印象很差,该怎么办?”忙了半天才做到持续交付,居然起到反作用。
这里边其实发生的最大的问题是:一定要从客户的角度理解可运行软件和持续交付,而不要从开发角度!
从开发角度看,上了持续集成系统,每天有一个EXE或DLL生成,就可运行了,可持续交付了,其实大错特错。
比如做一个敏捷开发管理软件,从第一分钟,就是可以运行的软件;但估计要做出可以填写、展示用户故事,无论如
何也要到第二周;而要最后卖掉,怎么也得有“用户和权限”这些次要功能。把这些所谓“次要功能”做出来之前就给客
户,而又未能向客户说明,极有可能适得其反。
当然一种做法是:把“登录功能”提前呗,不就从第一天就能真的给客户了?不。
商业决策的考虑商业决策的考虑
作为产品而言,永远应该把最体现差异化价值观的功能置于万事之前,也就是三个月内要决定产品是否值得做,六个
月内决定产品的主要功能及投入多少人力,九个月到一年的时候,就发布了(这里边的时间点仅为举例,需灵活掌
握)。因此千万不要把登录功能这类大路边的功能做在前面,会积压大量资金人力并大大推迟决策点。
比如某家游戏企业,为了能提前获知游戏是否好玩,以平台化的方法做出了很多基本的能登录、能玩、能买卖、有图