关于需求分析,你不能不知道的4个必杀技:捡金子+ Warroom作战室+情节串联板+Build构建 (2/2)

产品需求分析的4个必杀技:捡金子+ Warroom作战室+情节串联板+Build构建
     结合本人在华为6年的软件开发和产品管理经验,同时借鉴阿里巴巴(淘宝)、Google(Chrome)、HP(打印机)、微软(MSN)相关产品的需求文档分析,发现要搞定软件产品需求,必须要掌握4个必杀技:
1)捡金子:搞定市场需求,实现神经末梢与大脑的联通

2)Warroom:作战室,汇总各种情报、信息,形成产品的特性清单和卖点
3)情节串联板:用最直观,傻瓜都能看懂的方式,明确需求是什么
4)Build:构建,考虑需求轻重缓急、资源投入,分批推出功能,实现测试、开发协同

 

1、 捡金子:去伪存真的过程

2、 Warroom(作战室):汇集想法,确定卖点

http://blog.sina.com.cn/s/blog_81427a800101eif5.html

3、 情节串联板:图形化展现需求内容

眼见为实,耳听为虚;理解不一致,表达不清晰是需求分析中最常见的问题,如何将需求表达清楚,进而让团队形成一致的理解呢?只有两种方式:表格化 or 图形化,表格化就是结构化,图形化就是形象化,类似我们小时候看的连环画,图形+文字描述,清晰直观;需求定义类似导演拍电影,场景、人物、情节一体化,情节串联板就有此神奇魔力,但使用时需核心注意如下1点:

1) 图形化展现+关键注意点描述

Google Chrome需求情节串联板(节选):图形化、情景化展现客户的需求


 

青铜器软件的情节串联板:连环画模式,展现功能的全过程(软件安装需求节选)


 

第一步


 

第二步


 

第三步


 

第四步


 

第五步

4、Build构建:分批实现需求、分批提交需求、分批验证需求、分批发布需求

传统的产品开发是瀑布的、串行的,开始时,开发工程师忙的半死,测试工程师反而在哪傻等,真正到提交测试时,也离计划发布日期没有几天了,狂加班也搞不定呀,怪不得大家一致认为测试人员最大的素质要求是:身体一定要好。什么事情都不能压缩,唯有测试时间总被压缩,验证总是不充分,例外发布基本正常化。基于Scrum敏捷开发理论,开发和测试是并行的,形成相对完整的Product Backlog(通俗讲就是需求规格清单)后,需要制定Build计划,确定每次迭代的Sprint Backlog(通俗讲就是每次提交测试团队的需求清单),开发人员在完成下一个迭代功能开发的同时,测试人员对上次迭代的内容进行全面验证测试,避免傻等,从而及时发现问题,及时修正,软件的质量能快速提高,Build构建计划时,需要关键注意如下2点:

1)   需求的实现次序很有讲究:需要充分考虑关联性,避免新加功能时,把以前测试稳定的东西推到重来,从而切实减少重复测试;

2)   2+1模式:两个大迭代后一个小迭代,实现BUG清零,激烈的战斗间歇进行代码走查,对软件质量会有大的帮助。

IBM某产品Build计划:有软件的地方就有Build,即使嵌入式软件也如此


 

青铜器软件的Build计划:采用每双周一迭代模式 (B1115,11月15日迭代)



—-完,欢迎怕转—

 

 5 total views,  1 views today

页面下部广告