产品需求分析的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日迭代）
----完，欢迎怕转---
