构建之法-8-需求分析
需求分析
我敢说，需求分析是最难做好的环节，也是最重要的环节，同时也是最容易被糊弄过去的环节。这个阶段做不好，就相当于在大航航行中丢失了指南针。整个项目么有了目标，没有了规划。所以，我准备把这一节的笔记做详细一些。希望能从这一章里面多学习到一点东西。
8.1 软件需求
在实际工作中，需求的管理是非常重要的。需求可能来自于产品经理的创意，来自于领导的商业计划，来自于用的反馈，需求有优先级之分，需求也有真需求和伪需求，需要验证。如下图：
软件需求
8.2 软件产品的利益相关者
软件产品的利益相关者
最好是让相关角色都能在需求分析阶段有机会提出他们的需求和意见，弄清楚他们“想从软件中得到什么”。
8.3 获取用户需求-用户调研
各种方法在（态度∶行为、定性∶定量）上的分野
用户调研的方法
8.4 竞争性需求分析的框架
分析需求时还要考虑众多的竞争性友商，要做实用并且创新的项目。创新有俩：改良式和颠覆式。so， 如何提出创新的想法，如何证明创新是靠谱的。
- 拍脑袋：嘿，咱们做一个图书拍卖网站怎么样？
- 拍胸脯：没问题的，市面上ASP.NET的书很多，我看两个晚上就能写出一个购物网站。
其结果很可能就是：
拍屁股走人
所以，按部就班地分析需求，然后有条理地说服别人。可以参考NABCD模型：
竞争性需求分析的框架
我们的产品 < 名称 > 是为了解决 < 目标用户 > 的痛苦，他们需要 < Need >， 但是现有的产品并没有很好的解决这些需求。我们有独特的办法 < Approach >，它能给用户带来好处 < Benefit >，远远超过竞争对手 < Competitor >。同时，我们有高效的 < Delivery > 方法，很快的让目标用户知道我们的产品，并进一步传播。
8.5 功能的定位和优先级
功能的定位和优先级
以做一个英汉词典软件为例：
杀手功能：OCR文字识别技术，可以在屏幕上取词解释，拥有独家权威词典，等等。
外围功能：良好的界面设计，在各个平台上都能运行。
必要需求：单词短语释义的准确性（如果达不到这一点，用户就不会来使用）。
辅助需求：可以做各种皮肤（这也许能让一些用户更喜欢这个软件，但不是决定因素）。
资源有限，我们对不同功能有不同的建议
对待不同的功能，投资的效果
8.6 计划和估计
规划和估计
- 目标、估计和决心
目标：表明一个希望达到的状态。例如，软件“五一”之前要投放市场！在建校一百周年之时把我校建成世界一流大学！不论这类目标如何重要，它们未必能够实现。
估计：以当前了解的情况和掌握的资源，要花费多少人力物力时间才能实现某事。
决心：保证在某个时间之前完成预先规定的功能和质量。例如：我们跑步前进，全民炼钢，两年超英赶美！
- 估计时间
Y = X ± X ÷ N //注：Y是实际时间花费。中间的±表明
如果把这个公式展开一下，项目的复杂程度将由下面两个因素决定：
1. 需求的复杂程度：程序员是第几次实现类似的需求？有些外行看起来很复杂难懂的需求（如银行业务流程），如果一个程序员已经做过多次相关的银行项目，其实不像外人看的那么难。
2. 技术的复杂程度：程序员是第几次用这个技术实现？
8.7 分而治之（Work Breakdown Structure）
把看似巨大无从下手的项目逐步分解为可以操作的工作。PM是责无旁贷的领导者。
举个分而治之的例子：
分而治之
- 做好WBS的几个要点：
- 保证所有子节点覆盖了全部父节点包含的内容。
- 保证各个子节点不要相互覆盖。
- 叶子节点要保证足够小，能在一个里程碑中完成。在通常的软件项目中，叶节点的成本最好不要超过两周。如果团队成员从常理出发，认为叶节点不宜再分下去，那就可以停止。
- 从结果（Outcome）出发构建WBS，而不是从团队的活动（Action）出发。
The End
总之，需求分析做的越好，后面项目进展就会越顺利。
