《构建之法》第8、9、10章读书笔记及读后感

第八章：需求分析

软件需求

人们（用户）的需求五花八门，作为一个软件团队要准确而全面地获取这些需求主要有以下四个步骤：

1. 获取和引导需求。这一步骤也被叫做“需求捕捉”。软件团队需要为用户着想，设身处地，为用户引导出需求。
2. 分析和定义需求。从各个方面获取的需求进行规整，定义需求的内涵从各个角度将需求量化。
3. 验证需求。软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。
4. 在软件产品的生命周期中管理需求。

对软件的需求，也可以从不同角度做以下的划分：

1. 对产品功能性的需求
2. 对产品开发过程的需求
3. 非功能性需求
4. 综合需求

软件产品的利益相关者

很多人或机构都是某个软件的利益相关者，软件团队在分析软件需求时要考虑如下这些利益相关者：

1.  用户（或称最终用户）
2. 顾客（或称客户）
3. 市场分析师
4. 监管机构
5. 软件工程师

获取用户需求——用户调查

以下是几种常用的用户调研方法：

1.焦点小组

2.深入面谈

3.卡片分类

4.用户调查问卷

5.用户日志研究

6.人类学调查

7.眼动跟踪研究

8.快速原型调研

9.A/B测试

竞争性需求分析的框架：1.N（需求） 2.A（做法） 3.B（好处） 4.C（竞争） 5.D（推广）

第九章：项目经理

PM指的是项目经理

 Product Manager:产品经理——正确地做产品。

 Project Manager：项目经理——正确地做流程。

Program Manager：微软职位名称。

微软PM的来历

大部分公司的项目经理叫Project Manager，微软的经理叫做Program Manager。微软曾经是一个创业公司，两个创始人都是开发人员，招聘的新成员也大多是像他们一样的开发人员。查尔斯.西蒙尼超级程序员于1981年加入微软公司，并实施MP和SP改革，目的在于减少交流成本，实际上由于没有人想做SP，所以这次改革不了了之。后来，贾伯.布鲁门萨尔的程序员提出了Program Manager（PM）这一头衔，并成为了微软第一个PM。PM的出现让负责一个功能的开发/测试人员和相关的PM紧密合作，再有PM代表这一小组去和别的小组或客户打交道，大大降低了交流的成本，有专人负责开发/测试以外的许多事务和项目进行管理，让开发人员专注于技术方面的工作，实践也证明了这种改革利大于弊。

PM做开发和测试之外的所有事情

PM最大、最独特的贡献是带领团队达成最重要的目标，并保持团队的平衡。

牛人主导的项目，往往会大起大落；PM主导的产品中，"不犯大错“成了一个特点。

PM的能力要求和任务

1. 观察、理解和快速学习能力
2. 分析管理能力
3. 一定的专业能力
4. 自省的能力

第十章：典型用户和场景

 典型用户可包括以下内容：

1. 名字（越自然越好）
2. 年龄（不同年龄和收入的用户有不同的需求）
3. 收入
4. 代表的用户在市场上的比例和重要性（比例大不等同于重要性高，如付费的用户比例较少，但是影响大，所以更重要）
5. 使用这个软件的典型场景
6. 使用本软件/服务的环境
7. 生活/工作情况
8. 知识层次和能力
9. 用户的动机、目的和困难
10. 用户的偏好

注意：团队做出来的软件不是为所有人服务的，要非常明确地定义谁是我们的用户

定义了最初的典型用户后，我们还要和这些典型的用户代表交流，理解用户，理解他们的工作方式和需要，然后再修改，细化典型用户。

用例：（很常用的需求分析工具）

使用用例的原则：

1. 通过讲简单故事来传递信息
2. 保持对全系统的理解
3. 关注用户的价值
4. 逐步构建整个系统，一次完成一个用例
5. 增量开发，逐步构建整个系统
6. 适应团队不断变化的需求

总结：读完这几章内容，发现软件需求分析很关键，它指引着团队要开发怎样的软件，如果分析错误将会花费工程人员大量的时间纠正项目，并重新工作，加大开发的难度。因此要把握好、准确而全面地获取用户的需求信息。PM做开发和测试之外的所有事情，带领团队达成最重要的目标，并保持团队的平衡，让开发人员专注于技术方面的工作。所以，我觉得PM的改革措施具有历史性意义，值得去借鉴。

《构建之法》第8、9、10章读书笔记及读后感

原文：http://www.cnblogs.com/57rongjielong/p/5526580.html