您的位置:首页 > 其它

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

2010-10-15 13:15 441 查看
需求的头脑风暴是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,但总得来说,收效不明显,有价值的信息不多,没有达到预期目标。

性价比相对文档评审更弱。
只能说下,“太棒了!下次可以更好些”
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐