敏捷学习：产品待办列表 2016-7-13

 

敏捷学习：产品待办列表 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。

这是组织上的小技巧。