读书笔记2

第八章 需求分析

8.1 软件需求

①获取和引导需求：软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求；需求还可以来自各种管理机构；需求不仅来自外界，还可以来自软件企业本身；需求还可以来自技术团队本身；有些需求的目的是要更好地了解用户的行为和需求。

②分析和定义需求

③验证需求

④在软件产品的生命周期中管理需求

8.2 软件产品的利益相关者

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

几种常用的用户调研方法：焦点小组、深入面谈、卡片分类、用户调查问卷、用户日志研究、人类学调查、眼动追踪研究、快速原型调研、A/B测试

8.4 竞争性需求分析的框架——NABCD模型

1. N（Need，需求）

你的创意解决了用户的什么需求？这个需求可以是明确的、公开的（例如：希望能上网玩三国杀）也可能是说不清道不明的，例如——以前没人说：嗯，如果我能找到这样一个网站，我可以去偷菜，就好了……我们要充分了解用户的痛苦，他们对已有软件、服务不满意的地方。

2. A（Approach，做法）

好，你找到了需求，下一步怎么办，得看看你有什么招数，特别是独特的招数，来解决用户的痛苦。你不能说我会C++，所以我一定可以写好这个软件。你得有独特的办法，例如，有人脸识别技术，会做超大规模的数据处理。那你（你的团队）会什么呢？只会冒泡排序？这些招数不光是技术上的，也可以是商业模式上的（例如，我们第一个做众包的服务）、地域的（例如，我们对本市的公交线路很熟）、人脉的（例如，我们认识很多大学生）、行业的（例如，我们有地图测绘行业的资质），或者是成本上的（例如，我们能找到更便宜的资源来维护网站）。

3. B（Benefit，好处）

这时候你已经有了独特的做法，那你这个产品/服务会给客户/用户带来什么好处呢？如果用户已经有一个解决方案（例如用户已经在用QQ聊天），那你的新的聊天软件具体有哪些好处，能让用户离开现有产品，使用你的产品呢？这还有一个用户迁移成本的问题——用户要花费多少精力、时间、金钱才能得到你的产品的好处？如果你要求用户必须有8GB内存、最好的显卡、10Mbps以上的宽带连接，才能使用你的“更好的”视频聊天工具，那么会有多少用户愿意支付这个成本呢？

4. C（Competitors，竞争）

竞争对手也没有闲着，这个市场有多大，目前有多少竞争者在瓜分，你了解么？你的产品如果不是最先进入某个市场的，你还能赢么？先进入市场的产品，有所谓的先发优势（FirstMover Advantage，FMA），当然也有劣势。后面进入市场的产品，有种种不利的因素，但是也有后发优势（Second Mover Advantage，SMA）。

5. D（Delivery，推广）

在实际项目中经历多次的NABC之后，许多人意识到这个框架还应该加一个元素D：Delivery。怎样把你的创新产品交到用户的手中？例一，你想到了一个好主意，建一个比hao123更好的导航页面！我们姑且认为NABC都没问题，那如何把这么好、这么简单的产品交到（Deliver）用户手中呢？例二，你想到了一个手机的应用，NABC都不错，那如何把产品交到千万个用户手中呢？

8.5 功能的定位和优先级

杀手功能、外围功能、必要需求、辅助需求

我们以一个英汉词典软件为例子来说明。

杀手功能：OCR文字识别技术，可以在屏幕上取词解释，拥有独家权威词典，等等

外围功能：良好的界面设计，在各个平台上都能运行

必要需求：单词短语释义的准确性（如果达不到这一点，用户就不会来使用）

辅助需求：可以做各种皮肤（这也许能让一些用户更喜欢这个软件，但不是决定因素）

这四个象限能让软件团队清楚地看到自己感兴趣的功能处于什么地位，有了这些分析，我们就可以决定怎么处理不同类型的功能。 重要的是，不要把资源平摊到所有象限中，而是倾斜到可以产生差异化和独特用户价值的地方。

8.7 分而治之（Work Breakdown Structure）

一个团队项目要在一段时间内完成诸多任务，满足用户的需求，实现团队的目标，同时还希望项目能维持良好的技术架构，以便持续开发，千头万绪，从哪里入手？WBS就是一个例子

WBS通常从最终的产品开始，一层一层往下，把大型交付件（Deliverable）分割为小型、具体的交付件。这样的分割可以持续下去，直到WBS的使用者（开发团队、接收方）达到共识。从数据结构方面来看，WBS分割的结果是一棵树。所有子节点都最终有一个根节点。每个节点描述的是要交付的产品或文档，而不是开发团队的努力或花费（各个叶节点的成本可以作为次节点的属性展现出来）。做好WBS的几个要点：

• 保证所有子节点覆盖了全部父节点包含的内容
• 保证各个子节点不要相互覆盖

叶子节点要保证足够小，能在一个里程碑中完成。在通常的软件项目中，叶节点的成本最好不要超过两周。如果团队成员从常理出发，认为叶节点不宜再分下去，那就可以停止

从结果（Outcome）出发构建WBS，而不是从团队的活动（Action）出发

第九章 项目经理

9.1PM是啥

软件团队里除了能写代码、测试代码和画图做设计的成员，还有一类角色，不做上面这些事情但也很重要，我们叫他们项目经理——PM

PM的M就是Manager，但是P有这几种：Product Manager、Project Manager、Program Manager，在不同的行业和公司，他们的作用各不相同。接下来介绍的是项目经理——Program Manager

• Product Manager：产品经理——正确地做产品
• Project Manager：项目经理——正确地做流程
• Program Manager：微软的职位名称
  
  微软产品团队三足鼎立的角色分配就是PM、开发、测试。PM负责除产品开发和测试之外的所有事情。从某种意义上说，是前面两种角色的综合。微软通常有专门的产品策划（Product Planner），他们和市场部门的专职人员一起，负责产品的长期发展和市场推广

9.4 PM 的能力要求和任务

能力要求：

1. 观察、理解和快速学习能力——PM要能够在一个新的领域中很快上手

2. 分析管理能力
每天项目中发生的事情千头万绪，PM要能够分析出重点，找到优先级，做判断、做决定……一个项目和一个人一样，每天都会碰到各种问题：

• 重要而紧急的
• 网站崩了！
• 程序员小飞突然提出离职！
• 重要而不紧急的
• 按照流量和内容的发展趋势，三个月后，目前的架构似乎撑不住，但是现在还凑合……
• 程序员们都不写文档，他们三个月前说等忙过之后会写的，但是……
• 不重要而紧急的
• 老板的老板问到了项目的进度！要写一个PPT，向若干人征求意见，并及时得到反馈
• 不重要且不紧急的
• 领导想召开全公司大会，要表演节目……

3. 一定的专业能力
如果一定要说专业能力的话，PM的专业就是理解和表达，你能否理解不同人的心理、需求和言外之意？你能否借助文字、图表、草图，甚至代码来清晰准确地表达自己的想法？PM通常也能写代码，能玩转Excel、PPT、Visio、甘特图，会PS，有文字功底，写的博客有人爱读，反正，总得有几招绝活吧！不用说还要有大量的阅读，对IT行业、用户心理、社会都要有广泛的了解

4. 自省的能力
一个PM做第一个项目时可以拍脑袋定工期，拍胸脯打包票，最后拍屁股走人（谁没年轻过呢），但是失败之后要有自省和自我改进的能力

第十章 典型用户和场景

10.1 典型用户和典型场景

①怎样定义典型用户？

我们首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。

• 受欢迎的典型用户——指那些按设计者的期望使用系统的用户，如“网站的购物者”
• 不受欢迎的典型用户——指那些有不正当目的的用户，如在一个房地产业主论坛中滥发房屋中介广告的用户——这些用户也许在别的系统中（如房屋中介论坛）是受欢迎的

典型用户只是我们的设想，还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户

②从典型用户到场景

有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。

③场景怎么写？

• 首先针对每一个场景，设计一个场景入口（描述场景如何开始）
• 接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）
• 然后给场景划分优先级，按优先级排序写场景

④场景之间如何区分呢？

• 找到这个场景的特殊之处，对于共同的流程可以一笔带过，重点描述场景中特殊的因素
• 把场景组织成一个故事，这样就能把一个完整的用户与系统交互的流程记录下来，以后进行产品演示或验收都可以以此为基础

10.2 用例

和典型人物、典型场景的方法类似，用例（UseCase）也是很常用的需求分析工具。用例有这样一些 基本元素：

• 标题：描述这个用例要达到的目标
• 角色（Actor）：和软件系统交互的角色，例如用户，其他实体，甚至时间（在描述一些和时间相关的场景时有用）
• 主要成功场景（Main Success Scenario）：一系列步骤描述角色是怎样和系统交互，从而达到目标的
• 步骤（Step）：描述每一步的交互（例如一套正常的ATM取款流程）
• 扩展场景（Extension）：描述一些扩展的交互，例如一些意外情况（例如取款时账户余额不足）

10.3 规格说明书（Spec）

①规格说明书（Specification）简称Spec，分为以下两种：

1. 软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当作一个黑盒子）

2. 软件技术说明书（Technical Spec），又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当作一个透明的箱子）

②写好一个Spec

第一，定义好相关的概念

第二，规范好一些假设（Assumptions）

第三，避免一些误解，界定一些边界条件

第四，描述主流的用户/软件交互步骤

第五，一些好的功能还会有副作用

第六，服务质量的说明

第十一章 软件设计与实现

11.2 图形建模和分析方法

思维导图、实体关系图、Use Case Diagram

11.3 其他设计方法

形式化的方法、文学化编程

11.5 开发阶段的日常管理

第十二章 用户体验

12.1 用户体验的要素

用户的第一印象

从用户的角度考虑问题

软件服务始终都要记住用户的选择（长期的使用只会使软件更好用）

短期刺激 长期影响

不让用户犯简单的错误

注重用户体验和质量

情感设计

12.3 评价标准

对于一个软件的用户界面，我们有没有什么评价标准呢？可以参考费茨法则（Fitts law）、Nielsen启发式评估十条原则以及其他经验。下面是邹欣老师在自身实践的基础上总结的一些原则：

1. 尽快提供可感触的反馈系统状态

2. 系统界面符合用户的现实惯例（Familiarity，Avoid Surprise）

与用户沟通，软件系统要使用用户语言而不是开发者语言，所用的概念要贴近生活实际，而不是用学术概念或开发者的概念。我们说的生活实际，最好是目标用户的实际生活体验。

3. 用户有控制权

操作失误可回退，要让用户可以退出软件（很多软件都没有退出菜单，这是导致用户反感的一大原因）。用户可以定制显示信息的多少，还可以定制常用的设置。

4. 一致性和标准化

在软件中，对同一事物和同类操作的表示用语，各处要保持一致。例如，某词典软件有“帮助用户收集生词并且背诵生词”的功能。这个功能要有明确一致的称呼，不能混杂着叫“单词本”、“生词本”、“Word List”、“Word Book”、“单词文件”……等等。

5. 适合各种类型的用户

6. 帮助用户识别、诊断并修复错误

7. 有必要的提示和帮助文档

不需要文档，用户就能使用自如，当然更好，必要时还可以提供在线帮助。如果软件和用户的工作相关（而不是简单的游戏），那么基本的提示和帮助文档还是很有必要的，而且也要提供便利的检索功能。文档要从用户的角度出发描述具体步骤，并且不要太冗长。

第十三章 软件测试

13.1 名词解释

Bug ：软件的缺陷

Test Case ：测试用例。测试用例描述了一个完整的测试过程，包括测试环境、输入、期望的结果等

Test Suite ：测试用例集。即一组相关的测试用例

13.2 Bug解释与实例

①Bug可以分解为：症状（Symptom）、程序错误（Fault）、根本原因（Root Cause）

症状：即从用户的角度看，软件出了什么问题

程序错误：即从代码的角度看，代码的什么错误导致了软件的问题

根本原因：错误根源，即导致代码错误的根本原因

②Bug例子

症状：用户报告，一个windows应用程序有时会有在启动时报错，继而不能运行

程序错误：有时候一个子窗口的handle有空，导致程序访问了非法内存地址，此为代码错误

根本原因：代码并没有确保创建子窗口，因此子窗口的handle变量有时会在访问时处于未赋值状态（为空），导致出现代码错误

13.3测试方法

①黑箱：指的是设计测试的过程中，把软件系统当做一个“黑箱”，无法了解或使用系统的内部结构及知识。一个更准确的说法是行为测试设计，即从软件的行为，而不是从内部结构出发来设计测试

②白箱子：指的是在设计测试的过程中，设计者可以“看到”软件系统的内部结构，并使用软件的内部结构及知识来选择测试数据及具体的测试方法。

第十四章 质量保障

14.1 软件质量

软件 = 程序 + 软件工程

软件（质量） = 程序（质量） + 软件工程（质量）

14.2 软件质量的保障与软件的测试

软件测试：运用一定的流程和工具，验证软件能实现预先设计的功能和特性，工作的流程和结果通常是可量化的

软件质量的保障工作：软件团队为了让软件达到事先定义的质量标准而进行的所有活动，包括测试工作