《构建之法》阅读笔记三

第九章 项目经理

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 软件质量的保障与软件的测试

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

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

第十五章 稳定和发布阶段

15.1 从代码完成到发布

 

第一步：开发者提交参加会诊的Bug和修改方案，以及伙伴测试结果。开发者必须向与会者报告的是：

• Bug是什么
• 危害是什么，如果不修复，有何后果
• 用户会有什么变通办法
• 是否经过代码复审，是否经过伙伴测试

第二步：会议决定是否同意修改方案
决定哪些缺陷必须现在就进行修复，哪些可以推迟到下一个里程碑。会诊应该对每一个修复选择下列处理方式。

• Must——必须修复，缺陷很严重，修复方案可行，相关的测试都通过
• More Info——需要更多的信息
• No——不能接受，可能是推到下一个里程碑，可能是提出的解决方案不符合要求
• Like——可能，不一定必须修复，但是解决方案相对比较安全。在更复杂的项目中，可以考虑引入这一个中间的状态“Like”（在相对简单的系统中，这个选项可以不用）。如果在今天的会诊中有“Must”，那么处于待命状态的“Like”修复就可以一起集成到代码库中。如果没有“Must”级别的修复，那么“Like”级别的修复就只能处于“待命”状态，直到以后出现了“Must”级别的修复为止

第十六章 IT行业的创新

影响产品竞争的各种因素

• 产品行业的因素
  这是影响产品发展的最重要的因素，2012年流传着一句俗话——“站在风口上，连猪都可以飞起来”，就是说明产业发展的成长期（竞争产品少，市场空间大，用户容忍度强）能给产品提供巨大的助力。相反，如果是在一个产业的衰落期进入这个产业（例如，在2008年做小灵通手机业务，在2013年进军网络团购市场，等等），那么就会面临巨大的发展阻力。
• 公司和市场因素
  公司在目前目标用户中的品牌号召力如何？公司的现有市场能力如何？现有的市场能力能帮助打开新的领域么？从传统的产品开发角度来看，“市场”总是在产品之后才出现，而且和“产品开发”似乎没有直接的联系。但是从长期来看，产品的质量就是最有效的市场能力，产品经理往往就是市场经理。
• 团队执行因素
  根据产品特性的不同（基础软件、企业管理软件、行业通用软件、办公软件、互联网服务软件、移动应用软件等），商业模式不同，团队的战略也会不一样。在正确的时间，有正确的产品，却执行了错误的策略，或者不能做出决定，那么产品也会失败。执行力的一个有效衡量标准是一个决定需要多少次会议才能达成。一些团队对市场展现的机会往往陷入过度的分析和评价，力争要弄清所有情况再动手，最后的结果是动不了手。这是“分析麻痹”（Analysis Paralysis）。
• 产品的价值因素
  产品给用户带来什么价值，这是和“软件工程”最相关的内容。考虑新产品或产品的新功能时，团队要问：我们给用户带来了什么价值，这个产品是提供了独家的价值，还是“人有我也有”的价值？这个价值足以让本产品和目前市场上已有的产品区分开么？我们怎么能进一步放大产品差异性？让我们越来越领先，或者让用户觉得我们很领先？我们是否在非差异化功能上花费了太多时间和资源？

第十七章 人、绩效和职业道德

①RASCI模型

R：Responsible，负责把具体事情做好

A：Accountable，对任务负全责，有批准的权利

S：Support，对任务提供支持，辅助任务的完成

C：Consulted，咨询，拥有完成项目所需的信息或能力的角色

I：Informed，知会者，应该事后及时通知结果的角色

②团队合作的阶段：

（1）萌芽阶段，就像小苗破土而出，柔弱但充满希望

（2）磨合阶段，就像一个人的青少年时期，充满了对个人、同伴和团队的疑惑和冲突

（3）规范阶段，从磨合阶段毕业，进入规范阶段的团队，成员们意识到光争吵时没有用的，大家还是要协同作战

（4）创造阶段，经历了萌芽、磨合、规范阶段，现在团队终于可以创造一些有意义的东西

③不管从事哪一个职业，不管你是属于哪个岗位上的，都必须具有职业道德，软件工程师同样也需要

 

后记和个人感想

这本书的作者邹欣老师在微软公司工作，他在整本书中把对软件构建的方方面面都写得很清楚，包括需求，设计，开发，测试，项目管理......甚至国内很多公司都无法做到像书中说的流程那么全面和到位。作者的思路很清晰，文字也很有趣，让人欲罢不能。全书都有很大的参考价值，至少对于我目前这样的状态的程序员来说，了解自己要怎么做，做的方向比要做什么更重要，本书提供了很多建议和方法，比如PSP（Person Software Process，在我看这本书之前，完全没有听说过PSP这个东西，），也由此了解到作为一个软件工程师，任务清单里面不仅只有要编好程这一项而已，还有计划，需求，测试，评估工作量等能力需要刻意培养。

这本书最具特色的一个地方是把很多生涩难懂的概念用学生之间对话的诙谐幽默、生动风趣的场景来展现了出来，甚至还加入了一些电影中的经典台词、一些足球术语和篮球明星的专属名词，让我这个电影迷足球迷篮球迷一边读一边大呼过瘾，更开心的是学习到了很多知识，尤其是在软件工程项目开发过程中的许多技巧和需要注意的问题。例如在第五章讲解软件团队模式的时候用足球队的守门员、前锋、中场和后卫来类比，非常容易理解，不仅有趣而且易懂；再比如在第八章的需求分析中的人类学调查的讲解中，利用一个软件工程课上的同学的顿悟生动形象地讲解了人类学调查这个晦涩难懂的知识点。这本书还创造了很多有趣的人物形象：老成的项目带头人阿超、知识总是马马虎虎掌握的果冻、爱好丰富的小飞和产品经理小李，每个人物都很饱满，读这本书的时候也很容易让我这个读者产生代入感，读起来自然又快又让我印象深刻。