构建之法 第八章 需求分析

其实这是“啃硬骨头”的第一步，就是如何从“茫茫”中锁定需求相关方、挖出来需求的方法论

1.挖取需求

1. 获取和引导需求。需求不仅是来自外界，甚至也可以来自技术成员团队内部；
2. 分析和定义需求。主要是对需求进行量化；
3. 验证需求。
4. 在软件产品的生命周期中管理需求
   • 需求不一定只在初期才有；在中后期的时候可能因为外界环境变化甚至是成员自身水平变化而出现新的需求

2.软件产品的利益相关者

1. 最终用户（使用软件的人）
2. 顾客（购买软件的人）
3. 监管部门

3.获取用户需求的方法

1. 焦点小组（focus group）：找到一群用户的代表，加上利益相关者来讨论用户想要什么

2. 深入面谈（in-depth interview）:采取一对一的采访方式，着重探究用户在使用的时候有哪些困难 【以下方法我认为可以看做是进行需求分类的方法】

3. 卡片分类（card sorting）：将杂乱无章的需求分条目地写到卡片上，然后对这些卡片进行讨论、归类甚至排序

4. 人类学调查（ethnographic study）：和目标用户“同吃同住同劳动”——以便真正理解用户有什么需求、为什么用户有这些需求

4.竞争性需求分析（以说服别人）

以NABCD模型为例 1. N——NEED需求 2. A——APPROACH做法 - 有什么（独特的）做法去解决用户的困难 3. B——BENEFIT好处 - 特别注意用户迁移成本的问题。指的是用户要得到我们所做的软件带来的好处，需要花费多少时间、金钱甚至精力（去转移使用） 4. C——COMPETITORS竞争 5. D——DELIVERY推广

5.功能定位和优先级

【酒香也怕巷子深。对自己的产品有着清楚的功能定位——或者知道如何表述这种功能，是很重要的一个“让酒走出去”的手段】

要把用户从竞争对手那里吸引过来，团队自己的产品要有一个差异化的焦点，在这个焦点上，我们的团队能做得比别人好10倍，高一个数量级。 于是我们有了两种不同类型的功能：杀手功能（core）/外围功能（context） 还有另外一种划分：必要需求/辅助需求

6.分而治之

WBS通常从最终的产品开始，一层一层往下，把大型交付件（deliverable）分割为小型、具体的交付件（从结果出发，而不是团队的活动）