过程改进日记之学习Scrum2010-10-08：尝试需求的头脑风暴

需求的头脑风暴是PM先提出来的，我也很想做这样的尝试，自从参加了产品创新培训后（搜索《产品与服务开发》，L.LBean公司案例），很希望能够有机会尝试一些行动。

在演示会和反思会之后，展开需求讨论的头脑风暴。

考虑到大家未必真的理解头脑风暴的真正含义，于是简单的说了几点规则

步骤

1、 明确主持人和记录者

2、 发散思维，获得尽可能多的线索

3、明确主题，约定时间（一个主题在40分钟左右）

注意事项

1、 鼓励自由畅谈、禁止批评、否定

2、不要局限于技术解决方案的可行性

为避免过于专业，我们选择了一个比较容易理解的需求-“备份恢复”开始，PM介绍需求背景，她的一些策略，以及初期对交互的考虑，完成抛砖引玉的准备，然后等待大家的创意。

我打开Xmind记录。

过程－第一次头脑风暴的不足

通过实践操作，才知道头脑风暴还是很难的， 太棒了，有很大的提高空间

1、 习惯性的批判，所有人都习以为常的批判别人想法，只不过严重程度不同而已，常见的批判包括，

这个是小众需求，意义不大

你说的这个不是备份恢复需要做的

这个功能不是设备上就有的嘛

2、踊跃发言的少数和缄默的少数，中途，忍不住叫停，“ 各位，头脑风暴每个人都应该贡献自己的idea，我现在只看见XX、XXX、XXX在说话啊”，众皆笑，笑完了还是这样，缄默者冒着杀头的风险说一个，然后被习惯性批判消灭:(，继续保持缄默

3、 这不是需求评审，还是中途叫停

“各位，这不是头脑风暴了”

某工程师讶异：“这不就是头脑风暴吗，一直都这么做的啊”

无语“现在的目标是发现更多更好的需求，不是去评审需求”

4、 细节展开太多，有一个好的idea，然后力求展开，最后PM忍不住了，“嗯，够了，我知道了，就先写两个字吧。不需要这么多细节”

5、 强烈的说服欲望，我突然有一个自认为很好的想法，于是，不厌其烦解释他的好处，以及为什么我的想法比别人的更优，自己BS下自己。

结果－收益不明显

头脑风暴大约执行了1小时，发现了一些问题:(,也有一些idea，但总得来说，收效不明显，有价值的信息不多，没有达到预期目标。

性价比相对文档评审更弱。

只能说下，“太棒了！下次可以更好些”