敏捷学习:产品待办列表 2016-7-13
现在,健康类的App很火。有那么一个机会,让你给健身的人定制一个App,给你8个开发人员,你该怎么办?
有这个一次会议。一个产品经理(PO,Product Owner)对这个有点“不太靠谱”的想法,把这男男女女的8个人,拉在了一起。一张口,就说,大家多少,对这个产品,都知道点了。咱们一个一个来说说自己的想法吧。某某某,你先说说,你想咋做吧。
于是Blablabla,我得预约教练啊,我想知道离我最近得是那个健身房啊,我得跟踪我身体状况啊,最好有个分析啊,一个人没动力,约个伴啊。
PO就在一边说,嗯,这个想法不错,我记下来。这个我也是这么想的。不过要是做这个,得先有基础数据吧,有依赖关系,回头这个功能点等那个基础数据的功能好了,再加上。
这一边互相附和的精彩的不行不行的时候,其他人呢,其他人呢?
一脸茫然的有。看手机的有。画漫画的有(回头再说这个,人家还真不是走神,是干“正事”。)
这个会开的成功么?很显然,是失败的。
为什么啊?这首先,我们要看看这个会议的目的(或者说主题)是什么。
大家能猜的出来,在Scrum里面,PO参加的会是产品待办列表(PB,Product Backlog)梳理会。
很明显,待办列表,还是没搞清楚,这个列表不在PO的脑子里,也不在开发人员的脑子里,完全“动态”的,更透彻一点的话说,东一榔头西一棒槌。
会议的效果没达到。
这是我今天参加的敏捷社区活动中的一个实践环节,我就是那个虚拟产品的PO。
活动的导师,说了一句话,8个人,能做很多的事情。如果这么糊涂的开会,假设浪费了一个小时,乘以8,实践上,就是浪费了8个小时。
开这个会的目的是梳理产品的待办列表,咱们先看理想的输出,应该是什么样的。
首先,肯定是个list(列表)。每一个Item(项),描述一个点。这个点,应该达到什么要求呢?
得有恰当的细节。太细,就会导致开始讨论,这个做不了啊,我得查查能不能这么实现啊,必须得有基础数据啊,或者,用户不这么用吧?太粗,回头都想不起来当初说啥了,那可能不行。这个得花工夫。
动态的,这个好理解,咱得以后能改啊。这不,都敏捷了啊,好多事,都是逐渐搞清楚的。
可估算的,这个有两个含义,一个是对于客户来说,值不值,一个是工作量。
还有一个重要的方面。这些点,得是有顺序的。这个排序的依据,可以有很多依据,可以是优先级,也可以是工作量,可以是逻辑顺序,更多的可能是大家争论的结果,也有可能遇到了一个强势的PO,他就这么定的。
再回过头来,我们看看这个失败的梳理会,讨论每一个可能的“点”的时候,几乎,都没有注意到这四个特性。
一个有效的梳理会,要求PO,多加练习,开会之前,要有一个预稿(最起码,脑子里面得有个一二三),讨论每一个item的时候,都在某个程度上适可而止。
从另一个角度来,一个“发散”的会,基本上离失败也不远了。
最后,我们从参会的人数上来看,如果会议的性质,不是传达信息的话,那么需要考虑参会的人数。
根据人员数,团队,划分三个不同的复杂度,3个人及以下的,直接说就行了。5个人以上的,需要降低复杂度,分组。人员最好维持在5个人以下,做一个Task。
这是组织上的小技巧。