Xiaowu/20230505 (#792)

* update

* update

* update

* update

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第7章 - 需求分析/7.0 需求分析.md

@@ -14,3 +14,5 @@
 - 《实战需求分析》，杨长春，清华大学出版社
 - Difference Between Aggregation and Composition, https://techdifferences.com/difference-between-aggregation-and-composition.html
 - 秋千图，https://www.businessballs.com/treeswing.htm
+
+- Requirements Engineering Course，http://requirementsengineeringcourse.blogspot.com/2012/02/essential-software-requirement-chapter_2993.html

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第7章 - 需求分析/7.3 第1步：需求层次分析.md

@@ -8,7 +8,7 @@
 - 用户需求
 - 功能需求
 
-<img src="img/Slide9.SVG"/>
+<img src="img/Slide10.SVG"/>
 
 图 7.3.1 需求层次分析
 
@@ -27,13 +27,13 @@
 
 我们把这种需求叫做**业务需求**（因为需求来自业务管理者）或**客户需求**（客户代表一个法人或者一个企业，并非指某个具体的人）。
 
-<img src="img/Slide10.SVG"/>
+<img src="img/Slide11.SVG"/>
 
 图 7.3.2 第一层次：业务需求
 
 业务需求（Business requirement）标志组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
 
-业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档，但是这类文档超出了本书的讨论范围。
+业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档，这类文档超出了本书的讨论范围。
 
 - 来源：投资人、负责人、管理者、市场营销部门、产品策划部门等等，非直接用户。
 - 内容：说明需求的背景原因、系统目标、战略理念，描述了为什么要开发一个系统，即希望达到的目标。
@@ -54,7 +54,7 @@
 
 我们把这种需求叫做用户需求，因为需求来自直接用户。读者可能会觉得会奇怪：难道校长合教务处主任不是用户吗？-- 他们是用户，但他们更多的时候是客户。用户与客户的区别在本节最后一个部分讲解。
 
-<img src="img/Slide11.SVG"/>
+<img src="img/Slide12.SVG"/>
 
 图 7.3.3 第二层次：用户需求
 
@@ -71,7 +71,7 @@
 
 第三层次的需求，有些直接来自用户，更多的来自需求分析人员的需求分析结果。
 
-<img src="img/Slide12.SVG"/>
+<img src="img/Slide13.SVG"/>
 
 图 7.3.4 第三层次：功能需求
 
@@ -87,9 +87,11 @@
 
 ### 7.3.2 需求来源
 
+#### 1. 需求来源
+
 从上面的故事中，虽然所有的“需求”都是从客户的语言文字描述中得到的，但其实是有背后的领域知识的。更进一步地，我们可以挖掘整理出真正的需求来源，如图 7.3.5 所示。
 
-<img src="img/Slide13.SVG"/>
+<img src="img/Slide14.SVG"/>
 
 图 7.3.5 需求的来源
 
@@ -125,15 +127,15 @@
 - 质量需求是客观存在的，软件产品也只有服从。
 - 只有市场需求是丰富多彩、富于变化的，所以需求的演进与引导都是从用户、客户、产品人员而来的。
 
-笔者从长期的软件工程实践中发现，需求的演进动力，往往不是来自用户的，而是来自产品团队的。原因有几个方面：
+笔者从长期的软件工程实践中发现，需求的演进动力，往往不是来自用户的，而是来自产品团队的。来源有几个方面：
 
-- 对现有产品的附加功能
-- 技术创新带来的新功能
-- 多个产品的融合
+- 对现有产品的附加功能。
+- 技术创新带来的新功能。
+- 多个产品的融合。
 
 所以，需求的引导也一般是由产品团队来完成的。就如同前面的一个故事中讲到的，用户需要快马，福特就制造了汽车。在福特那个年代，养马当然比买车便宜，但是现在养马反而是件奢侈的事情了，养马的需求从快速通行的需要变成了财大气粗的任性。
 
-#### 客户和用户的区别
+#### 2. 客户和用户的区别
 
 在日常生活中我们经常混用“客户”和“用户”这两个词汇。希望读者在学习完需求分析后能够有个明确的认识。在软件工程需求分析中：
 

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第7章 - 需求分析/7.6 第4步：非功能性的需求分析.md

@@ -13,37 +13,29 @@
 我们先只看左侧分支，可以得到四个公式：
 
 $$
-需求 = 功能需求 + 非功能需求 \tag{7.6.1}
+需求 = 功能性的需求 + 非功能性的需求 \tag{7.6.1}
 $$
 
-在工程实践中，功能需求占的比重很大，但是非功能需求也是非常重要的组成部分，而且这些非功能需求不能满足的话，更有可能造成整个项目的失败。所以我们有了公式 7.6.1。
+在工程实践中，功能性的需求占的比重很大，但是非功能性的需求也是非常重要的组成部分，而且这些非功能性的需求不能满足的话，更有可能造成整个项目的失败。所以我们有了公式 7.6.1。
 
 $$
-功能需求 = 主要功能需求 + 辅助功能需求 \tag{7.6.2}
+功能性的需求 = 业务需求+用户需求+行为需求 \tag{7.6.2}
 $$
 
-$$
-主要功能需求 = f(业务需求)+g(用户需求) \tag{7.6.3}
-$$
-
-$$
-辅助功能需求 = 日志统计 + 可访问性 \tag{7.6.4}
-$$
-
-公式 7.6.3 的含义是，我们用一种方法 $f()$ 来分析业务需求，用另一种方法 $g()$ 来分析用户需求，最后可以得到主要功能需求。
+注意，式 7.6.2 中的“行为需求”既“功能需求”，但是和“功能性的需求”不是一码事。
 
 
-而公式 7.6.5 则说明了非功能需求的组成：
+而公式 7.6.3 则说明了非功能性的需求的组成：
 
 $$
-非功能需求 = 模糊需求 + 质量属性 + 约束条件  \tag{7.6.5}
+非功能性的需求 = 模糊需求 + 质量属性 + 约束条件  \tag{7.6.3}
 $$
 
-接下来我们了解一下非功能需求的各个组成部分。
+接下来我们了解一下非功能性的需求的各个组成部分。
 
 ### 7.6.2 模糊需求（Overall Requirements）
 
-模糊需求一般在业务需求层次提出，常见的就是三个字：快、好、省。所以，**也可以把它看作业务需求的一部分**。面对这种需求，我们的策略就是尽量量化它，把它转化成可以操作的功能需求或质量需求。
+模糊需求一般在业务需求层次提出，常见的就是三个字：快、好、省。所以，**也可以把它看作业务需求的一部分**。面对这种需求，我们的策略就是尽量量化它，把它转化成可以操作的功能需求或质量需求。如图 7.6.2 和式 7.6.4 所示。
 
 
 <img src="img/Slide24.SVG"/>
@@ -52,7 +44,7 @@ $$
 
 
 $$
-模糊需求 = 快 + 好 + 省 \tag{7.6.6}
+模糊需求 = 快 + 好 + 省 \tag{7.6.4}
 $$
 
 对于业务级投资人、负责人等领导来说，预期的质量需求就是三个字：快、好、省。这和当年的“多快好省”经济发展总路线如出一辙，实践证明是不能兼顾的。
@@ -83,12 +75,12 @@ $$
 
 ### 7.6.3 质量属性（Quality Attribute）
 
-质量属性包含很多内容，我们将会在后面的章节中专门介绍，在本节中可以用公式 7.6.7 和图 7.6.3 来简单表述。
+质量属性包含很多内容，我们将会在后面的章节中专门介绍，在本节中可以用式 7.6.5 和图 7.6.3 来简单表述。
 
 ISO 的质量属性定义是：
 
 $$
-质量属性=功能性+可靠性+易用性+效率+可维护性+可移植性 \tag{7.6.7}
+质量属性=功能性+可靠性+易用性+效率+可维护性+可移植性 \tag{7.6.5}
 $$
 
 
@@ -160,19 +152,18 @@ $$
 
 ### 7.6.4 约束条件（Constraint）
 
+约束条件可以用图 7.6.4 和式 7.6.6 来描述。
 
 <img src="img/Slide26.SVG"/>
 
 图 7.6.4 约束条件
 
-
-
 $$
 \begin{aligned}
 约束条件=& 甲方约束（资源） \\
 +& 乙方约束（开发） \\
 +& 环境约束（技术） \\
-+& 领域约束（业务） \tag{7.6.8}
++& 领域约束（业务） \tag{7.6.6}
 \end{aligned}
 $$
 

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第7章 - 需求分析/7.8 需求技术分析 1：用户模型.md

@@ -13,7 +13,7 @@
 
    首先要确定系统的边界，把待建系统看作一个黑盒子，绘出系统上下文图。
 
-2. 寻找功能点
+2. 寻找用例
 
    - 在需求调研时，每个参与者都会描述自己要做的事情，叫做用例，把参与者和几个用例联系起来建立用例图。
    - 有紧密联系的用例可以组织在一起形成子系统，有可能的话，我们尽量把这些子系统也发掘出来，并规划它们的边界。

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第7章 - 需求分析/7.9 需求技术分析 2：结构模型.md

@@ -10,6 +10,8 @@
 
 图 7.9.1 结构模型
 
+步骤如下：
+
 1. 发现类和对象
 
    从参与者和待建系统中发现类和对象，定义类和对象的模型。

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.0 需求管理.md

@@ -2,22 +2,16 @@
 
 <img src="img/Slide1.SVG"/>
 
-
-
+需求分析并非需求阶段最终的任务，最难以把握的其实是本章中讲述的需求管理。本章先用著名的 KANO 模型来分析用户满意度，然后用马斯洛理论讲述了竞争策略与商业软件定位，接下来讲述了需求的正常变更与非正常变革，最后讲述了项目经理的职责，以及需求规格说明书的内容。
 
 <img src="img/Slide2.SVG"/>
 
 
-
-
 ### 参考资料
 
-- [1] KANO用户满意度模型 https://en.wikipedia.org/wiki/Kano_model
-- [2] KANO分析模型 https://baike.baidu.com/item/KANO%20%E6%A8%A1%E5%9E%8B/19907824
-- [3] https://www.jianshu.com/p/9fa5abc666f7
-- [4] https://www.zhihu.com/question/27855883/answer/133766533
-- [5] 马斯洛理论 https://www.simplypsychology.org/maslow.html
-- [6] 百度百科《今日头条》https://baike.baidu.com/item/%E4%BB%8A%E6%97%A5%E5%A4%B4%E6%9D%A1/4169373
-- [7] 《构建之法》，邹欣，人民邮电出版社
-- [8] 《刷新》，萨提亚·纳德拉
-- [9] 王佳亮，http://www.woshipm.com/pmd/4196067.html
+- KANO用户满意度模型 https://en.wikipedia.org/wiki/Kano_model
+- KANO分析模型 https://baike.baidu.com/item/KANO%20%E6%A8%A1%E5%9E%8B/19907824
+- 马斯洛理论 https://www.simplypsychology.org/maslow.html
+- 百度百科《今日头条》https://baike.baidu.com/item/%E4%BB%8A%E6%97%A5%E5%A4%B4%E6%9D%A1/4169373
+- 《构建之法》，邹欣，人民邮电出版社
+- 《刷新》，萨提亚·纳德拉

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.1 KANO模型.md

@@ -1,125 +0,0 @@
-## 8.1 KANO模型
-
-KANO$^{[1]}$ 模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户功能分类和优先排序的有用工具，以分析用户功能对用户满意的影响为基础，体现了产品功能和用户满意之间的非线性关系。图 8.1.1 展示了这种模型。
-
-
-<img src="img/Slide3.SVG"/>
-
-图 8.1.1 - KANO 模型
-
-
-原文中使用了 Quality 这个词，即产品的品质。很多资料中都有不同的翻译，笔者认为翻译成“功能”比较符合软件行业的概念，当然 KANO 模型是通用的用户满意度模型，不是为软件行业定制的。表 8.1.1 是笔者的理解。
-
-表 8.1.1 - KANO 模型的五类功能定义
-
-|类|原文|中文|用户要求|
-|--|--|--|--|
-|1|Attractive Quality|惊喜型功能，兴奋点|快上线，麻利儿的|
-|2|One-dimensional Quality|期望型功能，痒点|点个赞，越多越好|
-|3|Must-be Quality|基本型功能，痛点|别废话，必须可用|
-|4|Indifferent Quality|无差异功能，尿点|无所谓，放那儿吧|
-|5|Reverse Quality|反向型功能，吐槽点|窝心呀，赶紧撤掉|
-
-以上类别是从好到坏（对用户来说）排列的。
-
-### 8.1.1 惊喜型功能
-
-又称兴奋型、魅力型功能，指不会被用户过分期望的，或者是用户没有想到的功能。
-
-比如 Edge 浏览器在打开 PDF 格式的文件时，会自动在上方出现一个功能条，内含放大、缩小、旋转、全屏、朗读、画笔、高亮、删除、打印、保存等一系列操作 PDF 文档的功能，相当于内置一个基本的 PDF 阅读器软件，这是一个非常好的功能。
-
-再比如 Windows 10 的人脸识别登录功能，不用记密码了，安全性也更高了，防止密码泄露。
-
-
-<img src="img/Slide4.SVG"/>
-
-图 8.1.2 - 惊喜型功能
-
-
-图 8.1.2 左侧子图是 Edge 浏览器内置的 PDF 阅读器功能，可以做标记并保存；右侧的子图是 Windows 10 的人脸识别登录选项的设置。
-
-对于惊喜型功能，随着满足用户期望程度的增加，用户满意度也会急剧上升，但一旦得到满足，即使表现并不完善，用户表现出的满意状况则也是非常高的。反之，即使在期望不满足时，用户也不会因而表现出明显的不满意。
-
-比如，人脸识别功能可能会比较慢，十次里有一次不能正确识别，但这不会带来用户的不满，最多会自嘲地说一句“先进的技术还是不可靠呀”，然后会继续尝试登录。
-
-惊喜型功能往往是以技术导向为主的功能，即计算机科技水平的发展会实现以前人们不曾/不敢想到的功能。
-
-### 8.1.2 期望型功能
-
-也称为意愿型功能，是指用户的满意状况与功能的满足程度成比例关系的功能，此类功能得到满足或表现良好的话，用户满意度会显著增加。当此类功能得不到满足或表现不好的话，用户的不满也会显著增加。
-
-比如初期的 Power Point 中的图形绘制功能，让用户可以方便地绘制自己想要的图形，以丰富演示稿的视觉效果。不但基本图形数量众多，还有线型选择、颜色填充、平面旋转、立体化等多种效果。
-
-随着版本迭代，Power Point 中又增加了 SmartArt 图形功能，提供了一系列的视觉表现形式，原本枯燥的文字信息列表，可以变成生动的结构化图形，让用户有耳目一新的体验，最关键的是它可以帮助用户传达给听众更准确的、容易记忆的信息，对商业演讲或者学校教学很有帮助。
-
-
-<img src="img/Slide5.SVG"/>
-
-图 8.1.3 - 期望型功能
-
-
-图 8.1.3 展示了 SmartArt 图形功能，本书中的 PPT 就使用了这个功能，非常方便，并且可以充分表达笔者的意图。
-
-这些不断进化的功能，会持续地提高用户对 Power Point 的满意程度。相反，如果不提供这些功能，用户会转而选择其它产品。
-
-### 8.1.3 基本型功能
-
-也称为必备型功能、理所当然功能，是用户对产品或服务的基本要求。是用户认为产品“必须有”的属性或功能。当其不满足用户功能时，用户很不满意；当其满足用户功能时，用户也可能不会因而表现出满意。
-
-
-<img src="img/Slide6.SVG"/>
-
-图 8.1.4 - 基本型功能
-
-
-如图 8.1.4 左侧子图所示，在 Word 编辑器中绘图成为了一种基本型功能，当年的 Word 还只能编辑文字，现在可以做到图文并茂。虽然很多人不需要画图，大概只有 20% 的用户需要此功能，但是如果缺失此功能，会带来强烈的不满，即使是那些不需要画图的用户也会说“Word 连图都不能画”。
-
-如图 8.1.4 右侧子图所示，Excel 中的表格数学计算，提供了非常多的公式、函数，这也是 Excel 当初占领市场的基础。假设它提供了其它 1000 多个函数，但是没有提供计算方差的函数，那么用户会抱怨；反过来说，它提供了计算方差的函数，用户会认为这是应该具备的功能，并不会因为有了这个函数就给微软写感谢信。
-
-### 8.1.4 无差异功能
-
-也称为无所谓型功能，不论提供与否，对用户体验无影响。
-
-
-<img src="img/Slide7.SVG"/>
-
-图 8.1.5 无差异功能
-
-
-我们以 Word 为例，用三个例子来说明：
-
- - Word 中提供了一个 Wikipedia 功能，其实就是 APP 内搜索，在不离开 Word 的情况下，可以在 Wikipedia 上搜索名词并以友好格式返回。如图 8.1.5 所示。
-
- - Word 支持了一个开放的 Blog 博客协议，可以把 Word 文档上传到 cnblogs.com 即时发布。
-  
- - Word 提供了一个 Transform 功能，可以把 Word 文档发布为一个网页。
-
-在网页开发和使用如此便利的今天，这几个功能都显得有点儿多余了，即使没有它们的存在，用户还是会继续使用 Word 来写文档。
-
-### 8.1.5 反向型功能
-
-又称逆向型功能，指引起强烈不满的功能，因为并非所有的消费者都有相似的喜好。许多用户根本都没有此功能，提供后用户满意度反而会下降，而且提供的程度与用户满意程度成反比。
-
-- 公共交通 APP
-
-  笔者乘城铁上下班，使用手机 APP 亿通行的二维码方式进出检票口。有那么一段时间，这个亿通行忽然做起广告来了，而且把广告做到了二维码前面，也就是用户必须先看广告，关闭它，再扫二维码。
-
-  于是检票口前面堆满了人：因为广告需要下载时间，城铁站里信号不好，半天下载不出来；然后还需要关闭广告，很多人是单手操作手机，手指头够不着关闭按钮。
-
-  笔者怒不可遏地在 APP 里提交了一条反馈，表达了强烈的不满。好在这种“逆天”的功能很快就取消了，不知道是不是因为 APP 的开发商收到了很多负面反馈。
-
-- CSDN 博客网站
-  
-  CSDN 是一个非常好的网站，大家可以在这里学习交流知识。但是其中有两个特性，笔者感到不满意，如图 8.1.6 所示。
-
-  一是在浏览时，经常弹出登录提示窗口，其实是一个假窗口（浮层），上面没有关闭按钮，好像要强制用户登录似的（其实只要用鼠标点击周围阴影处就可以关掉这个浮层）。
-
-  二是在窗口右侧，经常会有动态广告出现，五张图片来回换，造成视觉干扰，使得用户无法专心读博客内容。
-
-
-<img src="img/Slide8.SVG"/>
-
-图 8.1.6 - 反向型功能
-
-
-归纳起来，没有人会傻到做反向型功能来恶心用户。所有的反向型功能，都是由于经济利益问题造成的，想放广告挣钱，必然会影响用户体验。

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.1 KANO模型与用户满意度.md

@@ -0,0 +1,277 @@
+## 8.1 KANO 模型与用户满意度
+
+### 8.1.1 KANO 模型
+
+KANO 模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户功能分类和优先排序的有用工具，以分析用户功能对用户满意的影响为基础，体现了产品功能和用户满意之间的非线性关系。图 8.1.1 展示了这种模型。
+
+<img src="img/Slide3.SVG"/>
+
+图 8.1.1 KANO 模型
+
+
+因为 KANO 模型是通用的用户满意度模型，不是为软件行业定制的，所以原文中使用了 Quality 这个词，即产品的品质。很多资料中都有不同的翻译，笔者认为翻译成“功能”比较符合软件行业的概念。表 8.1.1 是笔者的理解。
+
+表 8.1.1 KANO 模型的五类功能定义
+
+|类|原文|中文|用户要求|
+|--|--|--|--|
+|1|Attractive Quality|惊喜型功能，兴奋点|快上线，麻利儿的|
+|2|One-dimensional Quality|期望型功能，痒点|点个赞，越多越好|
+|3|Must-be Quality|基本型功能，痛点|别废话，必须可用|
+|4|Indifferent Quality|无差异功能，尿点|无所谓，放那儿吧|
+|5|Reverse Quality|反向型功能，吐槽点|窝心呀，赶紧撤掉|
+
+以上类别是从好到坏（对用户来说）排列的。
+
+#### 1. 惊喜型功能
+
+又称兴奋型、魅力型功能，指不会被用户过分期望的，或者是用户没有想到的功能。
+
+比如 Edge 浏览器在打开 PDF 格式的文件时，会自动在上方出现一个功能条，内含放大、缩小、旋转、全屏、朗读、画笔、高亮、删除、打印、保存等一系列操作 PDF 文档的功能，相当于内置一个基本的 PDF 阅读器软件，这是一个非常好的功能。
+
+再比如 Windows 10 的人脸识别登录功能，不用记密码了，安全性也更高了，防止密码泄露。
+
+
+<img src="img/Slide4.SVG"/>
+
+图 8.1.2 惊喜型功能
+
+
+图 8.1.2 左侧子图是 Edge 浏览器内置的 PDF 阅读器功能，可以做标记并保存；右侧的子图是 Windows 10 的人脸识别登录选项的设置。
+
+对于惊喜型功能，随着满足用户期望程度的增加，用户满意度也会急剧上升，但一旦得到满足，即使表现并不完善，用户表现出的满意状况则也是非常高的。反之，即使在期望不满足时，用户也不会因而表现出明显的不满意。
+
+比如，人脸识别功能可能会比较慢，十次里有一次不能正确识别，但这不会带来用户的不满，最多会自嘲地说一句“先进的技术还是不可靠呀”，然后会继续尝试登录。
+
+惊喜型功能往往是以技术导向为主的功能，即计算机科技水平的发展会实现以前人们不曾/不敢想到的功能。
+
+#### 2. 期望型功能
+
+也称为意愿型功能，是指用户的满意状况与功能的满足程度成比例关系的功能，此类功能得到满足或表现良好的话，用户满意度会显著增加。当此类功能得不到满足或表现不好的话，用户的不满也会显著增加。
+
+比如初期的 Power Point 中的图形绘制功能，让用户可以方便地绘制自己想要的图形，以丰富演示稿的视觉效果。不但基本图形数量众多，还有线型选择、颜色填充、平面旋转、立体化等多种效果。
+
+随着版本迭代，Power Point 中又增加了 SmartArt 图形功能，提供了一系列的视觉表现形式，原本枯燥的文字信息列表，可以变成生动的结构化图形，让用户有耳目一新的体验，最关键的是它可以帮助用户传达给听众更准确的、容易记忆的信息，对商业演讲或者学校教学很有帮助。
+
+
+<img src="img/Slide5.SVG"/>
+
+图 8.1.3 期望型功能
+
+
+图 8.1.3 展示了 SmartArt 图形功能，本书中的 PPT 就使用了这个功能，非常方便，并且可以充分表达笔者的意图。
+
+这些不断进化的功能，会持续地提高用户对 Power Point 的满意程度。相反，如果不提供这些功能，用户会转而选择其它产品。
+
+#### 3. 基本型功能
+
+也称为必备型功能、理所当然功能，是用户对产品或服务的基本要求。是用户认为产品“必须有”的属性或功能。当其不满足用户功能时，用户很不满意；当其满足用户功能时，用户也可能不会因而表现出满意。
+
+
+<img src="img/Slide6.SVG"/>
+
+图 8.1.4 基本型功能
+
+
+如图 8.1.4 左侧子图所示，在 Word 编辑器中绘图成为了一种基本型功能，当年的 Word 还只能编辑文字，现在可以做到图文并茂。虽然很多人不需要画图，大概只有 20% 的用户需要此功能，但是如果缺失此功能，会带来强烈的不满，即使是那些不需要画图的用户也会说“Word 连图都不能画”。
+
+如图 8.1.4 右侧子图所示，Excel 中的表格数学计算，提供了非常多的公式、函数，这也是 Excel 当初占领市场的基础。假设它提供了其它 1000 多个函数，但是没有提供计算方差的函数，那么用户会抱怨；反过来说，它提供了计算方差的函数，用户会认为这是应该具备的功能，并不会因为有了这个函数就给微软写感谢信。
+
+#### 4. 无差异功能
+
+也称为无所谓型功能，不论提供与否，对用户体验无影响。
+
+
+<img src="img/Slide7.SVG"/>
+
+图 8.1.5 无差异功能
+
+
+我们以 Word 为例，用三个例子来说明：
+
+ - Word 中提供了一个 Wikipedia 功能，其实就是 APP 内搜索，在不离开 Word 的情况下，可以在 Wikipedia 上搜索名词并以友好格式返回。如图 8.1.5 所示。
+
+ - Word 支持了一个开放的 Blog 博客协议，可以把 Word 文档上传到 cnblogs.com 即时发布。
+  
+ - Word 提供了一个 Transform 功能，可以把 Word 文档发布为一个网页。
+
+在网页开发和使用如此便利的今天，这几个功能都显得有点儿多余了，即使没有它们的存在，用户还是会继续使用 Word 来写文档。
+
+#### 5. 反向型功能
+
+又称逆向型功能，指引起强烈不满的功能，因为并非所有的消费者都有相似的喜好。许多用户根本都没有此功能，提供后用户满意度反而会下降，而且提供的程度与用户满意程度成反比。
+
+- 公共交通 APP
+
+  笔者乘城铁上下班，使用手机 APP 亿通行的二维码方式进出检票口。有那么一段时间，这个亿通行忽然做起广告来了，而且把广告做到了二维码前面，也就是用户必须先看广告，关闭它，再扫二维码。
+
+  于是检票口前面堆满了人：因为广告需要下载时间，城铁站里信号不好，半天下载不出来；然后还需要关闭广告，很多人是单手操作手机，手指头够不着关闭按钮。
+
+  笔者怒不可遏地在 APP 里提交了一条反馈，表达了强烈的不满。好在这种“逆天”的功能很快就取消了，不知道是不是因为 APP 的开发商收到了很多负面反馈。
+
+- CSDN 博客网站
+  
+  CSDN 是一个非常好的网站，大家可以在这里学习交流知识。但是其中有两个特性，笔者感到不满意，如图 8.1.6 所示。
+
+  一是在浏览时，经常弹出登录提示窗口，其实是一个假窗口（浮层），上面没有关闭按钮，好像要强制用户登录似的（其实只要用鼠标点击周围阴影处就可以关掉这个浮层）。
+
+  二是在窗口右侧，经常会有动态广告出现，五张图片来回换，造成视觉干扰，使得用户无法专心读博客内容。
+
+
+<img src="img/Slide8.SVG"/>
+
+图 8.1.6 反向型功能
+
+
+归纳起来，没有人会傻到做反向型功能来恶心用户。所有的反向型功能，都是由于经济利益问题造成的，想放广告挣钱，必然会影响用户体验。
+
+
+### 8.1.2 满意度分析
+
+#### 1. 用户满意度的五种级别
+
+对任何事物的好坏的判断，用户的态度一般不是非此即彼的0/1问题，而是有一个过渡。在微软面试中，要求面试官给“Hire”或“No hire”，但有时候太难选择了，所以会出现一个“Weak hire”的选择，尽管不是官方要求的。
+
+由于笔者喜欢流行音乐（还在微软内部组建了一支乐队），所以经常看一些音乐节目，如《歌手》、《乐队的夏天》。节目组通常让普通观众选择“是否喜欢一个歌手或一支乐队”，其实这非常的不合理。观众并非总是理智的，往往凭借一些非常奇怪的原因决定“喜欢”还是“不喜欢”，比如“我不喜欢那个贝斯手的发型”，这就偏离了比赛的本来用意。
+
+但是另一方面，在《乐队的夏天》中，节目组会给专业乐迷五分制的投票权力。同理，在调查用户的满意度时，一般也会使用五种级别作为一个平滑过渡的设计。图 8.1 就是五种级别和对应的口语化形象描述。
+
+
+<img src="img/Slide9.SVG"/>
+
+图 8.1.7 满意度级别
+
+
+在使用 KANO 模型时，一般采用调查问卷的形式，即正反两个方向的问题：
+
+- 正向问题 A：如果Word可以保存为PDF格式，用户的感觉是什么？
+- 反向问题 B：如果Word不能保存为PDF格式，用户的感觉是什么？
+
+我们在表 8.1.7 中记录下这两个问题的答案，一个是第 2 行，一个是第 5 行。
+
+表 8.1.7 - A/B 两个问题的答案
+
+|级别|描述|正向问题 A|反向问题 B|
+|:--:|--|:--:|:--:|
+|1|太激动了||
+|2|比较不错|$\sqrt{}$|
+|3|说不上来||
+|4|不怎么样||
+|5|太差劲了||$\sqrt{}$|
+
+然后我们在图 8.1.8 中的坐标（2，5）做一个标记，表示问题 A 和问题 B 的交点位置。
+
+
+<img src="img/Slide10.SVG"/>
+
+图 8.1.8 KANO 模型中的类别判别方法
+
+
+
+#### 2. 定性分析
+
+再进一步，通过对问题 A 和 B 的分析，结合上一节所述的产品的五类功能，我们认为“Word 可以保存为 PDF 格式”这个功能是一个期望型功能。这样，就可以得到一个功能的分类了。
+
+为什么定位为“期望型”功能呢？我们看看“期望型”功能的定义：
+
+*也称为意愿型功能，是指用户的满意状况与功能的满足程度成比例关系的功能，此类功能得到满足或表现良好的话，用户满意度会显著增加。当此类功能得不到满足或表现不好的话，用户的不满也会显著增加。*
+
+再看一下本例：
+
+- 问题 A 的用户反馈是“比较不错”，即“此类功能得到满足或表现良好的话，用户满意度会显著增加”；
+
+- 问题 B 的用户反馈是“太差劲了”，即“当此类功能得不到满足或表现不好的话，用户的不满也会显著增加”。
+
+正反两个方面的回答完全符合期望型功能的定义。
+
+通过对不同的问题得到的交点位置做分析，我们可以得到图 8.1.9 中所有25个交点所属的功能分类。
+
+
+<img src="img/Slide11.SVG"/>
+
+图 8.1.9 功能类别坐标
+
+
+可以看到：
+- 中间有两个红色的“惊喜型”；
+- 右上角是绿色的“期望型”；
+- 右侧有两个蓝色的“基本型”；
+- 对角线上有三个黄色的“无差异型”；
+- 左下角是一堆“反向型”。
+
+以此方法，我们就得出了每个功能所属的分类。
+
+还有几个问号所处的位置，是不可能出现的分类。比如左上角的那个问号，相当于问：
+- A-如果有功能F，用户满意吗？用户答“太激动了”；
+- B-如果没有功能F，用户满意吗？用户答“太激动了”。
+
+从逻辑上分析，如果问题 A 得到肯定的回答，那么不可能也会对问题 B 有肯定的回答。其它几个问号都是类似的情况。
+
+不同的人对图中交叉点的位置所属的类型持有不同的观点，见图 8.1.10。
+
+
+<img src="img/Slide12.SVG"/>
+
+图 8.1.10 其它分类标准
+
+
+#### 3. 定量分析
+
+KANO 图还可以有定量分析，但是需要大量的调查问卷数据，比较难以实现，所以我们在此只是讲解一下定量分析的结论：四区域分类法。至于定量分析的过程，有兴趣的同学可以参考相应的资料$^{[2]}$。
+
+关于“四区域分类法”，在很多资料中，包括笔者给的参考资料中，有的写四象限法，有的写四分位法，这都是错误的命名。我们先解释四区域法的分析过程，后面再说上面两种叫法为什么是错误的。
+
+笔者发现，即使不计算 better-worse 系数$^{[2]}$，也可以得到同样的结果：在图 8.1.9 中，各个区域有明显的分割线：
+
+- 首先，我们不考虑问号的情况，因为它无意义；
+- 其次，我们不考虑反向型的功能，因为它比较容易分辨；
+- 在惊喜型和期望型之间，有一条竖的分割线；
+- 在期望型和基本型之间，有一条横的分割线；
+- 把无差异型的范围稍微缩小一些。
+
+然后我们可以得到一个四部分的区域图，如图 8.1.11 所示。
+
+
+<img src="img/Slide13.SVG"/>
+
+图 8.1.11 四区域法
+
+
+四个图中的坐标轴的含义是相同的：
+
+- 横坐标：不提供某个功能时，用户会的不满意程度，从左到右增加，用线 B 的长度表示；
+- 纵坐标：提供某个功能时，用户的满意程度，从下到上增加，用线 A 的长度表示。
+
+1）惊喜型功能
+
+处于左上角的区域。
+
+- 当提供此功能时，A 的长度显著增加，表示满意度剧增；
+- 当不提供此功能时，B 的长度没有显著增加，表示没有很大的不满意。
+
+2）期望型功能
+
+处于右上角的区域。
+
+- 当提供此功能时，A 的长度显著增加，表示很满意；
+- 当不提供此功能时，B 的长度显著增加，表示很不满意。
+
+3）基础型功能
+
+处于右下角的区域。
+
+- 当提供此功能时，A 的长度没有显著增加，表示满意度不高；
+- 当不提供此功能时，B 的显著增加，表示有很大的不满意。
+  
+4）无差异功能
+
+处于左下角的区域。
+
+- 当提供此功能时，A 的长度没有显著增加，表示满意度不高；
+- 当不提供此功能时，B 的长度没有显著增加，表示没有很大的不满意。
+
+我们再回过头说说上面提到的两种错误叫法：
+
+- 四象限法：象限是指平面直角坐标系上，由横纵坐标轴所分割的四个区域，以零点为中心。我们所面对的问题虽然是处于平面直角坐标系上，但是零点在左下角，四个区域都是在第一象限。
+
+- 四分位法：四分位是统计学的一个名词，是指处于一维坐标上的数据中，处于 25% 分位和 75% 分位的数值。我们所面对的问题是一个二维平面上的分类问题，不能使用四分位的叫法。

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.10 需求规格说明书.md

@@ -1,96 +0,0 @@
-## 8.10 需求规格说明书
-
-### 8.10.1 需求规格说明书的来源
-
-需求规格说明书（SRS，Software Requirement Specification）。
-
-我们在第六章讲到过需求层次和非功能需求的分析，这些其实就是需求规格说明书的素材来源。用图 8.10.1 来表示。
-
-
-<img src="img/Slide33.SVG"/>
-
-图 8.10.1 - 需求规格说明书的来源
-
-
-在微软，通常把需求规格说明书称作Functional Spec（Specification，规格说明书）、Feature Spec。因为这是 PM 需要完成的工作，所以经常叫做 PM Spec。
-
-需求规格说明书是需求分析阶段完成后的输出。如果我们只关心最后阶段的需求文档的产生的话，那么图 8.10.2 可以很好地示意。
-
-
-<img src="img/Slide34.SVG"/>
-
-图 8.10.2 - 需求文档的产生
-
-
-### 8.10.2 需求规格说明书的模板
-
-#### 1. Assumption/Background 假定和背景
-
-在需求规格说明书中，首先要简单讲解一下项目或产品的大概背景。可以分成两种情况：
-
-1. 独立的软件，从零开始开发。这种情况可以简单说一下需求背景，比如：
-   
-   *我们发现大部分研究员都是用 Edge 浏览器和 OneNote（微软办公套件中的一个产品）进行阅读和做笔记，非常不方便，所以想开发一款二合一的软件产品，既能够浏览，也能够做笔记。*
-
-2. 在已有软件上增加功能。这种情况需要简单描述一下已有软件的大概情况，再说一下新增功能，比如：
-
-   *我们发现大部分研究员都是用 Edge 浏览器和 OneNote 进行阅读和做笔记，非常不方便，所以想在 Edge 浏览器上开发一个扩展插件，来解决做笔记的需要。*
-
-#### 2. Goal/Non-Goal 目标和非目标
-
-仍然沿用读论文工具的例子：
-
-*Goal：解决 PDF 的标记问题。*
-
-*Non-Goal：不准备支持 Word 文档格式，不支持触摸输入。*
-
-#### 3. Persona/Scenario 典型用户与场景
-
-有了典型用户后，就要把该用户“放进”具体的应用场景中。Scenario 的意思，就是要把用户放进一个真实的故事片段中，来检验其可行性。
-
-比如前面所述的木头与神经网络课程的故事，用典型用户木头（老师）和毛毛（学生）作为故事的主角，串连起了两个故事片段，在故事中提及了大量的电教课程细节，都可以使用微软提供的技术方案来解决。
-
-反过来看，就是Surface Hub、Azure、OpenPAI 等设备、服务、软件，都应该提供什么功能，才能满足大学电教课程的需要。设计人员坐在办公室冥想是想不出来的，必须到教学现场观察一下上课的情况，才能够设计出相应的产品，然后再泛化。用故事场景（即Scenario）的形式来描述，就是还原现场的一种有效方法。
-
-#### 4. Feature/Function list 特性与功能列表
-
-Function 和 Feature 不是同一层意思：
-
-||Feature 特性|Function 功能|
-|--|--|--|
-|定义|产品或服务可以完成的任务、目标|可以实现某一功能的工具、方法|
-|组成|产品、服务、任务、流程、计算、系统、应用、文档、组件、机器，等等|窗口、按钮、菜单、列表、图形、声音、视频、卷滚条，等等|
-|举例1|该软件可以完成统计样本方差的任务|点击按钮 A 打开窗口后选择菜单 B 可以计算样本方差|
-|举例2|使用微信可以与其它人通信|点击“发送”按钮可以发送信息|
-
-所以，Spec 既要有功能（Function）列表，又要有特性（Feature）列表。功能列表通常由用户指定，而特性列表则由 PM 在需求分析的基础上给出，要具体到软件界面元素，比如是选择菜单还是点击按钮，出现的是一个数据列表框还是条形图，等等。
-
-#### 5. Condition/Performance 条件和性能
-
-一般指运行环境的要求或者限制，以及在这一运行环境下的系统性能指标。比如：
-
-*本软件要求在 Windows 10 操作系统上运行，可以管理多达 32 个类别和每个类别中最多 1024 篇论文。要求显示屏物理分辨率至少为 1920x1080。*
-
-*推理子系统的性能要求在20毫秒以下。*
-
-*网站允许200个用户并发，每个用户的响应时间为50毫秒。*
-
-#### 6. UI/UX 用户界面与交互
-
-复杂软件的用户界面和交互，是需要 Designer 参与的，会提供全套的界面元素设计和交互设计。如果是简单的功能，PM 可以根据以有的界面元素直接给定。
-
-比如，软件在某一时刻要弹出一个消息，那么消息框的大小、颜色、文字、位置，都可以参考软件已有的消息框设计直接给出，就不用通过 Designer 了。
-
-在需求阶段，可以给用户提供一个界面草稿，比如：这个 APP 的界面打算设计成左右分屏的，就像 Outlook 那种三级窗口的形式，功能按钮都在左边栏，阅读区在左侧主屏，辅助区在右侧小屏。一些细节的设置用对话框的形式展现。
-
-#### 7. Schedule/Plan 计划和日期
-
-给出项目的几个关键点，如：
-
-|时间|成果|解释|
-|--|--|--|
-|Week 2|Feature Spec|提交需求文档并评审|
-|Week 4|Design Spec|提交设计文档并评审|
-|Week 9|Code Complete|编写代码结束|
-|Week 10|ZBB ( Zero Bug Bounce )|没有新Bug再出现|
-|Week 12|Release|发布|

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.2 满意度分析.md

@@ -1,150 +0,0 @@
-## 8.2 满意度分析
-
-### 8.2.1 用户满意度的五种级别
-
-对任何事物的好坏的判断，用户的态度一般不是非此即彼的0/1问题，而是有一个过渡。在微软面试中，要求面试官给“Hire”或“No hire”，但有时候太难选择了，所以会出现一个“Weak hire”的选择，尽管不是官方要求的。
-
-由于笔者喜欢流行音乐（还在微软内部组建了一支乐队），所以经常看一些音乐节目，如《歌手》、《乐队的夏天》。节目组通常让普通观众选择“是否喜欢一个歌手或一支乐队”，其实这非常的不合理。观众并非总是理智的，往往凭借一些非常奇怪的原因决定“喜欢”还是“不喜欢”，比如“我不喜欢那个贝斯手的发型”，这就偏离了比赛的本来用意。
-
-但是另一方面，在《乐队的夏天》中，节目组会给专业乐迷五分制的投票权力。同理，在调查用户的满意度时，一般也会使用五种级别作为一个平滑过渡的设计。图 8.2.1 就是五种级别和对应的口语化形象描述。
-
-
-<img src="img/Slide9.SVG"/>
-
-图 8.2.1 - 满意度级别
-
-
-在使用 KANO 模型时，一般采用调查问卷的形式，即正反两个方向的问题：
-
-- 正向问题 A：如果Word可以保存为PDF格式，用户的感觉是什么？
-- 反向问题 B：如果Word不能保存为PDF格式，用户的感觉是什么？
-
-我们在表 8.2.1 中记录下这两个问题的答案，一个是第 2 行，一个是第 5 行。
-
-表 8.2.1 - A/B 两个问题的答案
-
-|级别|描述|正向问题 A|反向问题 B|
-|:--:|--|:--:|:--:|
-|1|太激动了||
-|2|比较不错|$\sqrt{}$|
-|3|说不上来||
-|4|不怎么样||
-|5|太差劲了||$\sqrt{}$|
-
-然后我们在图 8.2.2 中的坐标（2，5）做一个标记，表示问题 A 和问题 B 的交点位置。
-
-
-<img src="img/Slide10.SVG"/>
-
-图 8.2.2 - KANO 模型中的类别判别方法
-
-
-
-### 8.2.2 定性分析
-
-再进一步，通过对问题 A 和 B 的分析，结合上一节所述的产品的五类功能，我们认为“Word 可以保存为 PDF 格式”这个功能是一个期望型功能。这样，就可以得到一个功能的分类了。
-
-为什么定位为“期望型”功能呢？我们看看“期望型”功能的定义：
-
-*也称为意愿型功能，是指用户的满意状况与功能的满足程度成比例关系的功能，此类功能得到满足或表现良好的话，用户满意度会显著增加。当此类功能得不到满足或表现不好的话，用户的不满也会显著增加。*
-
-再看一下本例：
-
-- 问题 A 的用户反馈是“比较不错”，即“此类功能得到满足或表现良好的话，用户满意度会显著增加”；
-
-- 问题 B 的用户反馈是“太差劲了”，即“当此类功能得不到满足或表现不好的话，用户的不满也会显著增加”。
-
-正反两个方面的回答完全符合期望型功能的定义。
-
-通过对不同的问题得到的交点位置做分析，我们可以得到图 8.2.3 中所有25个交点所属的功能分类。
-
-
-<img src="img/Slide11.SVG"/>
-
-图 8.2.3 - 功能类别坐标
-
-
-可以看到：
-- 中间有两个红色的“惊喜型”；
-- 右上角是绿色的“期望型”；
-- 右侧有两个蓝色的“基本型”；
-- 对角线上有三个黄色的“无差异型”；
-- 左下角是一堆“反向型”。
-
-以此方法，我们就得出了每个功能所属的分类。
-
-还有几个问号所处的位置，是不可能出现的分类。比如左上角的那个问号，相当于问：
-- A) 如果有功能F，用户满意吗？用户答“太激动了”；
-- B) 如果没有功能F，用户满意吗？用户答“太激动了”。
-
-从逻辑上分析，如果问题A得到肯定的回答，那么不可能也会对问题B有肯定的回答。其它几个问号都是类似的情况。
-
-不同的人对图中交叉点的位置所属的类型持有不同的观点，见图 8.2.4。
-
-
-<img src="img/Slide12.SVG"/>
-
-图 8.2.4 - 其它分类标准
-
-
-### 8.2.3 定量分析
-
-KANO 图还可以有定量分析，但是需要大量的调查问卷数据，比较难以实现，所以我们在此只是讲解一下定量分析的结论：四区域分类法。至于定量分析的过程，有兴趣的同学可以参考相应的资料$^{[2]}$。
-
-关于“四区域分类法”，在很多资料中，包括笔者给的参考资料中，有的写四象限法，有的写四分位法，这都是错误的命名。我们先解释四区域法的分析过程，后面再说上面两种叫法为什么是错误的。
-
-笔者发现，即使不计算 better-worse 系数$^{[2]}$，也可以得到同样的结果：在图 8.2.3 中，各个区域有明显的分割线：
-
-- 首先，我们不考虑问号的情况，因为它无意义；
-- 其次，我们不考虑反向型的功能，因为它比较容易分辨；
-- 在惊喜型和期望型之间，有一条竖的分割线；
-- 在期望型和基本型之间，有一条横的分割线；
-- 把无差异型的范围稍微缩小一些。
-
-然后我们可以得到一个四部分的区域图，如图 8.2.5所示。
-
-
-<img src="img/Slide13.SVG"/>
-
-图 8.2.5 - 四区域法
-
-
-四个图中的坐标轴的含义是相同的：
-
-- 横坐标：不提供某个功能时，用户会的不满意程度，从左到右增加，用线 B 的长度表示；
-- 纵坐标：提供某个功能时，用户的满意程度，从下到上增加，用线 A 的长度表示。
-
-#### 惊喜型功能
-
-处于左上角的区域。
-
-- 当提供此功能时，A 的长度显著增加，表示满意度剧增；
-- 当不提供此功能时，B 的长度没有显著增加，表示没有很大的不满意。
-
-#### 期望型功能
-
-处于右上角的区域。
-
-- 当提供此功能时，A 的长度显著增加，表示很满意；
-- 当不提供此功能时，B 的长度显著增加，表示很不满意。
-
-#### 基础型功能
-
-处于右下角的区域。
-
-- 当提供此功能时，A 的长度没有显著增加，表示满意度不高；
-- 当不提供此功能时，B 的显著增加，表示有很大的不满意。
-  
-#### 无差异功能
-
-处于左下角的区域。
-
-- 当提供此功能时，A 的长度没有显著增加，表示满意度不高；
-- 当不提供此功能时，B 的长度没有显著增加，表示没有很大的不满意。
-
-我们再回过头说说上面提到的两种错误叫法：
-
-- 四象限法：象限是指平面直角坐标系上，由横纵坐标轴所分割的四个区域，以零点为中心。我们所面对的问题虽然是处于平面直角坐标系上，但是零点在左下角，四个区域都是在第一象限。
-
-- 四分位法：四分位是统计学的一个名词，是指处于一维坐标上的数据中，处于25%分位和75%分位的数值。我们所面对的问题是一个二维平面上的分类问题，不能使用四分位的叫法。
-

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.2 竞争策略与软件定位.md

@@ -0,0 +1,240 @@
+
+## 8.2 竞争策略与软件定位
+
+### 8.2.1 需求定位与实施策略
+
+根据 KANO 模型，我们得到了四个区域的功能划分，这其实和传统的“紧急/重要四象限法则”是同一个道理。
+
+
+<img src="img/Slide14.SVG"/>
+
+图 8.2.1 需求定位与实施策略
+
+
+#### 1. 惊喜型功能
+
+人无我有。
+
+惊喜型功能属于不紧急但重要的。“不紧急”指的是在商业利益上，该类功能目前还不是主力创收来源，但是放眼未来的赢利点，实现差异化优势，它们却是最重要的。
+
+佛教中有个说法叫做“顿悟”，就是忽然发明/发现了一个新功能，但实际上是不可能有顿悟的事件发生的，历史上所有的发明/发现，都是水滴石穿、集腋成裘的结果。宋词中的名句：“崆峒访道至湘湖，万卷诗书看转愚。踏破铁鞋无觅处，得来全不费功夫。” 很多人只看到了“不费功夫”，却没有看到“踏破铁鞋”。
+
+惊喜型功能，是建立在对产品的熟悉、对技术的追求基础上的，厚积薄发，才有可能出现一个突破。比如 Windows Hello face（人脸识别）登录技术，是建立在以下技术基础上的：
+
+- 高分辨率摄像头，并且是双通道，可以识别景深；
+- 人脸数字化特征提取技术；
+- CPU 的高速计算能力。
+
+可以看到，其中有硬件、软件、算法的多方面结合，才能实现这个功能。
+
+【最佳实践】在这类功能上的投入力度建议：20%。
+
+#### 2. 期望型功能
+
+人有我优。
+
+期望型功能属于紧急且重要的，这是软件产品的核心竞争力所在，需要花大力气来做，并保持行业领先。
+
+在微软必应搜索产品的开发上，必应团队为了从谷歌的搜索市场中抢到份额，先是经历了痛苦的“基本型”功能的开发，当时讲的最多的一句话就是“fix the gap”，即弥补差距。到了后来，系统逐步完善，也积累了一定的用户量，产品团队改变了关注焦点，口号变成为“钢需、痛点、海量”，即解决用户的真正需求。
+
+钢需、痛点，这两个衡量点都容易理解，“海量”的意思是用户量，由于必应搜索的用户量是千万级别的，所以如果一个功能不能满足百万级别以上的用户，这个功能就不要考虑花资源去做了。
+
+【最佳实践】在这类功能上的投入力度建议：30%。
+
+#### 3. 基本型功能
+
+人有我有。
+
+基本型功能属于紧急不重要的。不重要不代表不做，而是说赶紧做完后，就不要再费心思考虑它们了。
+
+不同的软件的基本功能都有不同的定义，这主要取决于“业界”的共识，即你的产品和其它竞争对手的产品所共有的功能。如果有新加入的竞争者，它也必须实现这些基础功能才能站稳脚跟。
+
+对于这个类别的功能，我们主要以低成本维持为主，不需要超过竞争对手的品质。比如，Chrome 浏览器可以容纳4096个网页收藏，那么 Edge 浏览器非要容纳8192个网页收藏也没什么意义，因为没有用户需要那么多网页收藏。
+
+【最佳实践】在这类功能上的投入力度建议：45%。在完成基本功能后，应该把人力投入到期望型功能上。
+
+#### 4. 无差异功能
+
+人有我无或人无我无。
+
+最简单的就是无差异功能了，属于不紧急不重要。
+
+这类功能，如果已经存在了的话，就放在那里不要动了吧，两个原则：
+
+1. 只要它不影响新功能实现，或者说和新功能没有矛盾；
+2. 它还能正常工作，不会被某一次的软件更新破坏掉。
+
+这也是满足一些老用户的需要，向后（低版本）兼容。如果通过统计发现使用率太低了，那就可以干脆去掉了。使用率需要通过两方面来衡量：
+
+1. 百分比，比如低于0.01%，即万分之一；
+2. 同时，低于一个绝对值，比如每个月仅有100次使用。
+
+这二者缺一不可，因为用户群总数是未知的，千万级的总用户量，即使是万分之一，用户量也还是客观的。如果总用户量少，每个月100次造访使用量（unique user）也是客观的，我们不能丢失掉这100个用户。
+
+【最佳实践】在这类功能上的投入力度建议：小于5%。
+
+### 8.2.2 竞品分析
+
+#### 1. 目的
+
+做竞品分析的目的有三：
+
+1）学习领域知识
+
+   在微软，一个刚刚入职的 PM，领导往往让其做一个与本团队相关的产品竞品分析，这对于刚进入一个领域的新手来说，是一个快速学习领域知识的良好途径。
+
+   木头在做手机浏览器时，团队中的一个年轻的 PM 就被分配了一个任务：了解一下市面上所有的手机浏览器，做一个详细的分析。这位兄弟花了两周的时间，列了一张巨大的表格，把一些市场份额较大的品牌都列在里面，如：UC浏览器、QQ浏览器、360浏览器、夸克浏览器、百度浏览器、火狐浏览器、搜狗浏览器，等等。这张表为我们排出上百个功能的优先级起到了很大的参考作用。
+
+2）寻找功能灵感
+
+   与其闭门造车苦思冥想一个新功能，不如出去走访客户，或使用一下竞争对手的产品，获得些灵感。
+
+   木头在研究如何给必应搜索的广告商实现评分和推荐系统时，自然而然地去研究了一些谷歌的广告系统，一个合作的 PM 在谷歌搜索上注册了一个广告商账号，每月花几个小钱，了解谷歌的评分机制。最后得到的结论很让人失望：谷歌的评分机制是基于规则的静态算法，并没有多么高深。这也和广告商对于这种机制的负面评论相吻合。
+
+   于是木头得到了灵感：我们为必应做一个基于统计的动态算法，可以让最终用户、广告商、必应搜索三方的盈利达到平衡。由于本项目还处于研发初期，一些细节还不方便透露。
+
+3）监视竞争对手
+
+   一个惊喜型功能刚刚上线两周，其竞争对手也推出了类似的功能，使得惊喜型功能变成了期望型功能。这种竞争关系在国内市场屡见不鲜。软件产品的功能一般没有可以注册专利的点，模仿也不违法，这也迫使产品团队尽量找一些技术门槛高的功能做。
+
+#### 2. 方法
+
+有很多模型和理论可以帮助大家做竞品分析，比如波特五力模型、BCG Matrix、STP理论、德尔菲法、5W2H分析法、SWOT等。利用这些分析方法进行全面研究，同时还要依赖于大量的数据，往往都已经上升至一个公司的战略层面。
+
+
+<img src="img/Slide15.SVG"/>
+
+图 8.2.2 竞品分析
+
+
+一种朴素的定性分析方法如图 8.2.2 所示，图中用三个圆示意出了用户需求、我方产品、竞争产品的关系：
+
+- 要发挥的是我方优势
+- 要避免的是无用功能
+- 要弥补的是未满足的需求
+- 要追赶的是对方优势
+- 要保持的是平手部分
+
+Cortana 发展到现在已经不是什么秘密了，木头还曾经参与过 Windows Cornata 的开发工作，PM 们也曾经做过竞品分析。当时的竞争对手有Apple Siri、Google Now、Baidu Duer等等。
+
+我们以 Cortana 竞品分析为例，简述一种详细的但是便于理解和操作的方法，可以从以下几个方面着手：
+
+1）竞品基本信息，包括产品简介、进化过程、应用平台、用户评价、市场份额，等等。如图 8.2.3 所示。
+
+
+<img src="img/Slide16.SVG"/>
+
+图 8.2.3 竞品基本信息
+
+
+2）功能列表，一般是取所有竞品的功能合集作为基线，在某竞品的相应列上打勾，表示有此功能。如图 8.2.4 右下角的子图。
+
+
+<img src="img/Slide17.SVG"/>
+
+图 8.2.4 竞品分析
+
+
+3）用户界面与交互，列出主要功能的界面，并指出该界面上存在的优缺点，提醒我方产品注意的地方。如图 8.2.4 右上角的子图。
+
+4）总结和建议，以产品形态、推广方法、竞争策略等为主要内容。如图 8.2.4 左下角的子图。
+
+
+### 8.2.3 软件的定位
+
+马斯洛需要层次理论（Maslow's Hierarchy of Needs）是关于需要结构的理论，传播较广。马斯洛（1968）认为，人的需要由五个等级构成：生理的需要、安全的需要、归属与爱的需要、尊重的需要、自我实现的需要。
+
+在软件上，这个理论可以确定软件的市场需求定位，从而确定使用人群、软件功能、市场运营策略等等。
+
+比如木头在城铁上观察到的大众使用手机应用软件的情况，可以大致对应到不同等级的需求层次上，如图 8.2.5 所示。
+
+<img src="img/Slide18.SVG"/>
+
+图 8.2.5 软件产品定位
+
+
+#### 1. 生理的需要（Physiological Needs）
+
+传统的生理（生存）需要有：食物、水、空气、衣服、睡眠、温暖、居所等。
+
+在物质生活不再匮乏的今天，软件产品提供的网络小说、视频，实际上是为了满足现代人类的精神生活。这种精神生活并不是需求层次的提高，只是生理需求的扩充而已。
+
+- 我已经吃饱了喝足了，我需要快乐；
+- 我不满足于每天两点一线的生活，我想猎奇；
+- 我厌烦我身边的人和事，但又不能摆脱，我想拥有别样的生活。
+
+于是，网络小说和电视剧、短视频，就可以用来满足这些需要，因为它们提供了虚拟的现实、别人的生活、平行的空间，软件使用者（即读者）既可以从上帝视角观察别人的生活，也可以假设自己是主人公来体验别人的生活。
+
+微软的 HoloLens 软硬件产品，以虚拟现实的技术和形式，用视觉带领用户进入一个崭新的世界，从更高的体验层次满足用户的生理需要。
+
+#### 2. 安全的需要（Safety Needs）
+
+传统的安全需要，是人们需要稳定、安全的生活环境，受到保护，有秩序，避免焦虑、恐惧等负面情绪产生。
+
+新闻就是新近发生的具有异常性的真事，而微博是自媒体的一种，也可以归结到新闻类别中。人需要包括新闻在内的各种讯息，来完善知识与智力结构，调整行为，适应社会变化，这是一种安全的需要。而出于精神生活需要去看新闻，猎奇、探索、求知欲，实际上属于较低层次的生理需求。
+
+所以，新闻实际上人类被动补充知识的一种手段，以便可以更“安全”地生活和工作。大家都不喜欢看新闻联播了，但是又需要看新闻，所以“今日头条”便推出了个性化新闻服务。
+
+基于个性化推荐引擎技术，根据每个用户的兴趣、位置等多个维度进行个性化推荐，推荐内容不仅包括狭义上的新闻，还包括音乐、电影、游戏、购物等资讯。
+
+对每条信息提取几十个到几百个高维特征，并进行降维、相似计算、聚类等计算去除重复信息；对信息进行机器分类、摘要抽取，LDA主题分析、信息质量识别等处理。
+
+根据人的特征、环境特征、文章特征三者的匹配程度进行推荐。实时推荐，0.1秒内计算推荐结果，3秒完成文章提取、挖掘、消重、分类，5秒计算出新用户兴趣分配，10秒内更新用户模型。
+
+根据用户所在城市，自动识别本地新闻，精准推荐给当地居民。可根据用户年龄、性别、职业等特征，自动计算并推荐其感兴趣的资讯。
+
+从本质上来说，上学读书受教育也是一种安全的需要。木头的同事中有很多孩子家长，一般都会在“微信家长群”里，同事 C 的两个孩子，第一个是儿子，第二个也是儿子。群里经常会有些家长说“我们家孩子上某某补习班”之类的消息，于是其它家长纷纷效仿。按 C 的话说：“人家孩子都参加了，你不参加的话就觉得不安全。”
+
+#### 3. 归属与爱的需要（Belongingness and Love Needs）
+
+传统的归属与爱，就是于其它人建立感情的联系或关系，如团队、朋友、爱情。
+
+Nobody is a island（没有人是一座孤岛），这是玄学派英国诗人约翰$\cdot$多恩的诗，用比喻的方法生动地描述了人类的社会和情感需要。
+
+微软的虚拟人工智能小冰，从具有感情色彩的聊天开始，吸引了无数宅男的目光和时间，对话轮数平均可以到达30轮以上。
+- 2014年5月29日，小冰正式推出第一代产品，以对话式聊天机器人形式迅速积累训练数据。
+- 第二代产品完成了跨平台部署的交互架构。
+- 第三代产品将交互从文本扩充至多模态，进一步积累多模态训练数据。
+- 第四代小冰开始，交互总量稳居全球第一并保持至今，同时发布了全双工语音交互感官。
+- 第五代小冰采用 Dual AI 战略，大幅度扩展跨平台覆盖的规模，至 20 余个主流平台，并成为中国市场上涵盖了华为、小米、OPPO、Vivo 等智能手机及硬件的唯一的跨平台人工智能。
+- 第六代小冰完成了框架迭代目标。
+- 从第七代开始推出各类框架工具，以帮助创建第三方人工智能产品，并承载其各类交互。
+- 第八代小冰已经创造了 118 万的虚拟男友。
+
+微信的日活跃用户数已经到达 10 亿了，朋友圈、群消息、私聊，每天收割着无数人的时间和感情投入。发朋友圈其实就是一种试图获得归属与爱的行为，与大家分享自己的心情和经历，希望获得朋友的点赞。
+
+木头曾经总结过点赞行为的动机，并发布在朋友圈里：
+
+- 点赞是一种义务。
+- 及时点赞是一种美德，好评是一种艺术，差评是一种亲密。
+- 给好图点赞是一种本能，给好文点赞是一种修养，给好友点赞是一种友谊，给好心情点赞是一种理解。
+- 给无聊贴点赞是一种幽默，给普通贴点赞是一种鼓励，给高级贴点赞是一种欣赏，给每个贴都点赞是一种寂寞。
+- 给木头的贴点赞是一种智慧。
+
+此贴获得 100 多赞！
+
+#### 4. 尊重的需要（Esteem Needs）
+
+传统的尊重需要，就是自尊和希望受到别人的尊重。
+
+女孩子在淘宝上买衣服，已经不是生理需要了，她们并不缺衣服，她们需要的是穿在自己身上能让别人夸赞的衣服，以此得到满足感。但是自尊到了极限就是虚荣，当有人挎着 LV 的包包每天在上下班高峰狼狈地挤地铁时，我们只能感叹 LV 已经走下神坛了。最关键的是，LV 的包包在设计时都没有拉链，包里面装的东西一览无余，最高兴的是小偷儿。
+
+在软件设计上，商家想方设法展示衣服的美丽（卖家秀），然后又根据大数据（购买行为）推荐各种相关产品。
+
+男人在穿衣打扮这方面一般没有什么追求，却又有展示个人性格与见解的需求。但同时，有些人的创作能力有限，平时在工作生活中窝窝囊囊，但又想获得存在感和尊重：我写不出来大段的文章来，但写一句话的评论总可以吧？于是在微博、微信公众号、论坛上，各种奇葩的评论层出不穷，骂人说脏话的是一种低级的表现，没有脏字但是句句诛心的是一种高级的表现。
+
+以现在的 NLP（Natural Language Processing，自然语言处理）技术来说，智能地屏蔽这些评论并不是什么难事，但是那些软件厂商不愿意投入精力去做，反而会觉得有这些奇葩的评论会吸引更多的人来观看。
+
+#### 5. 自我实现的需要（Self-actualizaiton Needs）
+
+自我实现本来就是一种高层次的需求，所以在软件行业只是形式上的不同而已。
+
+别小看打游戏，克服里面的重重困难过关斩将，实际上是一种自我实现的需要，这比看科幻小说电视剧高一个层次，因为用户亲身参与了。这些游戏玩家，为了实现更高层次的自我，还会花钱买装备，所以软件游戏成为了最容易赚钱的行业。
+
+互联网还有一个 1:99 定律，就是在每 100 个人里，只有 1 个人创作，其它的 99 人只是观众。对应到各种软件中，这一个人就是微博的博主、公众号的博主、网络小说的作者等等。他们的自我实现方式就是创作。
+
+虽然比例悬殊这么大，但是中国人口多，那么创作者就多，所以就会有一个很好的生态环境来支持微博、公众号、网络小说的运营，稍微加点儿广告，就会有很好的收入。
+
+也有在朋友圈实现自我的，比如发自己拍摄的美图和长文、自己做的短诗等等，偶尔也会有自己写歌作曲的，这大大降低了自我实现的门槛，所以朋友圈里色彩缤纷。而观众都是朋友，所以不会有攻击诋毁的评论出现，相对安全。
+
+而抖音和微信短视频的出现，更是激发了公众的“创作”欲望，因为视频比文字、诗歌、音乐等更容易生成，再配上一段平台提供的音乐就会更加有模有样。视频的分类（从难到易）大致有：知识类、才艺类、搞笑类、新闻类、生活类。

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.3 竞争策略.md

@@ -1,139 +0,0 @@
-## 8.3 竞争策略
-
-### 8.3.1 定位与实施策略
-
-根据 KANO 模型，我们得到了四个区域的功能划分，这其实和传统的“紧急/重要四象限法则”是同一个道理。
-
-
-<img src="img/Slide14.SVG"/>
-
-图 8.3.1 - 需求定位与实施策略
-
-
-#### 惊喜型功能
-
-人无我有。
-
-惊喜型功能属于不紧急但重要的。“不紧急”指的是在商业利益上，该类功能目前还不是主力创收来源，但是放眼未来的赢利点，实现差异化优势，它们却是最重要的。
-
-佛教中有个说法叫做“顿悟”，就是忽然发明/发现了一个新功能，但实际上是不可能有顿悟的事件发生的，历史上所有的发明/发现，都是水滴石穿、集腋成裘的结果。宋词中的名句：“崆峒访道至湘湖，万卷诗书看转愚。踏破铁鞋无觅处，得来全不费功夫。” 很多人只看到了“不费功夫”，却没有看到“踏破铁鞋”。
-
-惊喜型功能，是建立在对产品的熟悉、对技术的追求基础上的，厚积薄发，才有可能出现一个突破。比如 Windows Hello face（人脸识别）登录技术，是建立在以下技术基础上的：
-
-- 高分辨率摄像头，并且是双通道，可以识别景深；
-- 人脸数字化特征提取技术；
-- CPU 的高速计算能力。
-
-可以看到，其中有硬件、软件、算法的多方面结合，才能实现这个功能。
-
-在这类功能上的投入力度建议：20%。
-
-#### 期望型功能
-
-人有我优。
-
-期望型功能属于紧急且重要的，这是软件产品的核心竞争力所在，需要花大力气来做，并保持行业领先。
-
-在微软必应搜索产品的开发上，必应团队为了从谷歌的搜索市场中抢到份额，先是经历了痛苦的“基本型”功能的开发，当时讲的最多的一句话就是“fix the gap”，即弥补差距。到了后来，系统逐步完善，也积累了一定的用户量，产品团队改变了关注焦点，口号变成为“钢需、痛点、海量”，即解决用户的真正需求。
-
-钢需、痛点，这两个衡量点都容易理解，“海量”的意思是用户量，由于必应搜索的用户量是千万级别的，所以如果一个功能不能满足百万级别以上的用户，这个功能就不要考虑花资源去做了。
-
-在这类功能上的投入力度建议：60%。
-
-#### 基本型功能
-
-人有我有。
-
-基本型功能属于紧急不重要的。不重要不代表不做，而是说赶紧做完后，就不要再费心思考虑它们了。
-
-不同的软件的基本功能都有不同的定义，这主要取决于“业界”的共识，即你的产品和其它竞争对手的产品所共有的功能。如果有新加入的竞争者，它也必须实现这些基础功能才能站稳脚跟。
-
-对于这个类别的功能，我们主要以低成本维持为主，不需要超过竞争对手的品质。比如，Chrome 浏览器可以容纳4096个网页收藏，那么 Edge 浏览器非要容纳8192个网页收藏也没什么意义，因为没有用户需要那么多网页收藏。
-
-在这类功能上的投入力度建议：15%。
-
-#### 无差异功能
-
-人有我无或人无我无。
-
-最简单的就是无差异功能了，属于不紧急不重要。
-
-这类功能，如果已经存在了的话，就放在那里不要动了吧，两个原则：
-
-1. 只要它不影响新功能实现，或者说和新功能没有矛盾；
-2. 它还能正常工作，不会被某一次的软件更新破坏掉。
-
-这也是满足一些老用户的需要，向后（低版本）兼容。如果通过统计发现使用率太低了，那就可以干脆去掉了。使用率需要通过两方面来衡量：
-
-1. 百分比，比如低于0.01%，即万分之一；
-2. 同时，低于一个绝对值，比如每个月仅有100次使用。
-
-这二者缺一不可，因为用户群总数是未知的，千万级的总用户量，即使是万分之一，用户量也还是客观的。如果总用户量少，每个月100次造访使用量（unique user）也是客观的，我们不能丢失掉这100个用户。
-
-在这类功能上的投入力度建议：小于5%。
-
-### 8.3.2 竞品分析
-
-#### 目的
-
-做竞品分析的目的有三：
-
-1. 学习领域知识
-
-   在微软，一个刚刚入职的 PM，领导往往让其做一个与本团队相关的产品竞品分析，这对于刚进入一个领域的新手来说，是一个快速学习领域知识的良好途径。
-
-   木头在做手机浏览器时，团队中的一个年轻的 PM 就被分配了一个任务：了解一下市面上所有的手机浏览器，做一个详细的分析。这位兄弟花了两周的时间，列了一张巨大的表格，把一些市场份额较大的品牌都列在里面，如：UC浏览器、QQ浏览器、360浏览器、夸克浏览器、百度浏览器、火狐浏览器、搜狗浏览器，等等。这张表为我们排出上百个功能的优先级起到了很大的参考作用。
-
-2. 寻找功能灵感
-
-   与其闭门造车苦思冥想一个新功能，不如出去走访客户，或使用一下竞争对手的产品，获得些灵感。
-
-   木头在研究如何给必应搜索的广告商实现评分和推荐系统时，自然而然地去研究了一些谷歌的广告系统，一个合作的 PM 在谷歌搜索上注册了一个广告商账号，每月花几个小钱，了解谷歌的评分机制。最后得到的结论很让人失望：谷歌的评分机制是基于规则的静态算法，并没有多么高深。这也和广告商对于这种机制的负面评论相吻合。
-
-   于是木头得到了灵感：我们为必应做一个基于统计的动态算法，可以让最终用户、广告商、必应搜索三方的盈利达到平衡。由于本项目还处于研发初期，一些细节还不方便透露。
-
-3. 监视竞争对手
-
-   一个惊喜型功能刚刚上线两周，其竞争对手也推出了类似的功能，使得惊喜型功能变成了期望型功能。这种竞争关系在国内市场屡见不鲜。软件产品的功能一般没有可以注册专利的点，模仿也不违法，这也迫使产品团队尽量找一些技术门槛高的功能做。
-
-#### 方法
-
-有很多模型和理论可以帮助大家做竞品分析，比如波特五力模型、BCG Matrix、STP理论、德尔菲法、5W2H分析法、SWOT等。利用这些分析方法进行全面研究，同时还要依赖于大量的数据，往往都已经上升至一个公司的战略层面。$^{[9]}$
-
-
-<img src="img/Slide15.SVG"/>
-
-图 8.3.2 - 竞品分析
-
-
-一种朴素的定性分析方法如图 8.3.2 所示，图中用三个圆示意出了用户需求、我方产品、竞争产品的关系：
-
-- 要发挥的是我方优势
-- 要避免的是无用功能
-- 要弥补的是未满足的需求
-- 要追赶的是对方优势
-- 要保持的是平手部分
-
-Cortana 发展到现在已经不是什么秘密了，木头还曾经参与过 Windows Cornata 的开发工作，PM 们也曾经做过竞品分析。当时的竞争对手有Apple Siri、Google Now、Baidu Duer等等。
-
-我们以 Cortana 竞品分析为例，简述一种详细的但是便于理解和操作的方法，可以从以下几个方面着手：
-
-1. 竞品基本信息，包括产品简介、进化过程、应用平台、用户评价、市场份额，等等。如图 8.3.3 所示。
-
-
-<img src="img/Slide16.SVG"/>
-
-图 8.3.3 - 竞品基本信息
-
-
-2. 功能列表，一般是取所有竞品的功能合集作为基线，在某竞品的相应列上打勾，表示有此功能。如图 8.3.4 右下角的子图。
-
-
-<img src="img/Slide17.SVG"/>
-
-图 8.3.4 - 竞品分析
-
-
-3. 用户界面与交互，列出主要功能的界面，并指出该界面上存在的优缺点，提醒我方产品注意的地方。如图 8.3.4 右上角的子图。
-
-4. 总结和建议，以产品形态、推广方法、竞争策略等为主要内容。如图 8.3.4 左下角的子图。

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.3 需求的正常变更.md

@@ -0,0 +1,250 @@
+## 8.3 需求的正常变更
+
+需求的正常变更包括四种形式的变化：漂移、演进、引导、推荐。
+
+先说明一下“需求演进”和“需求引导”的区别：
+- 需求演进是来自用户的，主要是解决一些痛点，实现基本型和期望型功能；
+- 需求引导是来自产品团队的，主要是实现一些新颖的想法，实现期望型和惊喜型功能。
+
+
+### 8.3.1 需求漂移
+
+需求漂移，准确地说是需求的类别漂移，是指同样一个功能，在不同场合会有不同的理解、效果、满意度，这是由于“场合”对该需求的偏好影响。
+
+
+<img src="img/Slide19.SVG"/>
+
+图 8.3.1 需求类别漂移
+
+
+#### 1. 因使用者而异
+
+由于教育水平、工作性质、年龄阶段等的差别，人们的需求各不不同。
+
+比如我们上面举的关于 Word 的三个看似无用的功能的例子，也许有的人没有浏览器使用基础（比如一些老人），这些功能对他们来说就有很大的帮助。因为这些软件都有 Telemetry（日志）机制，所以可以知道有多少人还在使用这些看似“过时”的功能，所以也就没有取消掉。
+
+再比如手机上的计算器功能，如果是科技工作者使用，希望有乘方、开方、对数、指数等功能；如果是普通老百姓使用，那么有加减乘除就足够用了，功能多了反而容易按错键。
+
+#### 2. 因为文化差而异
+
+在中国的即时消息通信软件中，各种搞笑的表情包被广泛使用，有些甚至是需要付费购买的。表情包通常是漫画形式的，体现出创作者的别具匠心。
+
+微软的 Teams 团队协作软件功能强大，其中的消息模块也有发送 GIF 表情包的功能。但是由于是美国文化，表情包都是那种电影里截出来的人物表情片段，中国人使用起来觉得特别别扭，所以在 Teams 日常通信中，笔者及其它同事们都很少使用 GIF 表情包。
+
+#### 3. 因产品地位而异
+
+SmartArt 对 Power Point 这个产品本身来说，开发者要持续对这个功能的维护，比如增加更多的组合图形，是一种期望型功能。但是对于其它竞争者来说，没有这个功能的话，就根本别想进入市场了，那么这个功能就会变成基本型功能。
+
+所以对于后来者、竞争者来说，用户对它们的要求是必须提供惊喜型功能，或者提供很多期望型功能，才有可能后来居上。
+
+#### 4. 因时间而异
+
+即使是惊喜型功能，在经过一段时间的使用后，新鲜感会消失；或者随着竞争对手也跟风推出类似的功能，变得不那么吸引人。
+
+比如 Windows Hello 人脸识别登录功能，在刚刚随着 Windows 10 发布时，大家觉得特别的高科技，配合着 Surface Book 的时尚感，使得 Windows 10 很快普及。所以它属于惊喜型功能。
+
+但是一段时间过后，假设没有这个功能了，用户会觉得不方便，它就会退化为期望型功能。
+
+### 8.3.2 需求演进
+
+需求总在持续地演进，所以软件开发团队需要持续调研功能，产品需要持续迭代，与时俱进才能赢得用户。
+
+木头用开发手机浏览器的经历，来推演一下当年浏览器领域的需求演进过程。图 8.3.2 展示了木头在前四周的学习过程。
+
+
+<img src="img/Slide20.SVG"/>
+
+图 8.3.2 需求演进
+
+
+微软在 IE 落伍后尝试继续自研内核，开发基于 EdgeHTML 渲染内核和Chakra JS 解析引擎的 Edge 浏览器，而且继续绑定在 Windows 10 上发布。但是一些问题依然存在：性能，兼容性，扩展插件，更新频率等。所以在 2017 年的时候，微软想尝试一下使用 Chromium 内核开发浏览器。为了保险起见，微软决定先让中国的开发团队在手机上开发移动端浏览器，先试试水，如果成功的话，再在桌面端更新浏览器内核策略。于是，木头所在的团队接受了这一“光荣”的任务。
+
+#### Week 1（第一周）
+
+在这之前，浏览器对于木头来说，就是日常使用，没有仔细研究过功能、架构、竞品等等。所以，在第一周（Week 1），木头认为浏览器就是“浏览器”本身的字面意思。所以，哥儿几个每个人都分到了一个 Android 手机，又把一个台式机装成 Ubuntu 16.0，下载了 Chromium 的代码后，编译出一个浏览器来，安装到 Android 手机上。成果如图 8.3.3 所示。
+
+
+<img src="img/Slide21.SVG"/>
+
+图 8.3.3 搭建开发环境
+
+
+
+恍惚间有一种大功告成的感觉，但是，这仅仅是一个开始，后面的几周是疯狂学习浏览器知识的日子，就如同当年开发第一个浏览器的先行者们那样，不断探索这个产品的奥秘。
+
+#### Week 2（第二周）
+
+木头使用着自己编译出来的浏览器，仔细端详着手机屏幕，忽然发现原来浏览器是由“地址栏”和“窗口”两部分组成的！所以，我们至少应该有两个模块，才能实现完整的浏览器功能：
+
+1）地址栏，用于输入网址，我们称之为输入模块；
+2）窗口，用于显示网页，我们称之为显示模块。
+
+虽然地址栏很窄，但很重要。在手机上，由于屏幕小，有时候甚至是要隐藏地址栏的。
+
+至于显示网页的功能吗，当然是由 Chromium 提供的渲染引擎（Render Engine）完成的，这也是浏览器的核心。
+
+#### Week 3（第三周）
+
+木头使用着初步演进后的浏览器，刚开始还洋洋自得：输入输出都有了，很完备。但是很快就发现了新的需求，如表 8.3.1 和 8.3.2 所示，并且随着这些功能的加入，以前的输入和显示“模块”要升级为“子系统”了。
+
+表 8.3.1 输入子系统的改进
+
+|功能|描述|
+|--|--|
+|合法性验证|随着测试次数的增加，在地址栏里输入的网址越来越不规范，HTTP GET 经常会出错。那我们就加入一个网址合法性验证的功能吧，避免错误的网址传到后端。|
+|自动补全|“https://www.microsoft.com”这个网址太长了，每次都需要输入得很准确才能正常工作。能不能在输入“www.m”以后，自动补全为“www.microsoft.com”呢？|
+
+表 8.3.2 显示子系统的改进
+|功能|描述|
+|--|--|
+|页面卷滚|页面内容很多，手机屏幕小，绝大多数网页显示不下，那就只好加一个卷滚功能了。|
+|刷新单页|有时候由于网络原因，造成页面加载不畅，css没有下载完整，页面乱七八糟的。所以增加一个刷新功能吧。|
+
+经过第三周的探索，我们浏览器已经演进为一个较为人性的“成品”了，但是距离“产品”还差得很远。
+
+#### Week 4（第四周）
+
+在经过前三周的摸索后，到了第四周，木头已经懂得了需求不断演进的趋势，变得小心翼翼了。果然，经过一段时间的使用，又发现了很多新功能，可以让输入和显示两部分演进得更加完善。表 8.3.3 和 表 8.3.4 列出了新的功能。
+
+表 8.3.3 输入子系统的完善
+
+|功能|描述|
+|--|--|
+|容错|输入“http://”时，由于手机键盘小，每次都会打成“htp:/”，我们需要地址栏模块可以认识这个常见的“错误”。|
+|Cookie|每次登录网页都需要重新输入用户名和密码，烦死了。增加一个 Cookie 功能来替我们节省些时间。|
+|关键字搜索|如果输入的是一个关键字，比如“azure”，这个浏览器能不能智能地懂得我们是想搜索“azure”这个名词呢？|
+|历史网址重现|以前输入过“www.microsoft.com”，也输入过“www.mail.163.com”，能不能在用户输入“www.m”后，自动显示一个下拉列表，列出以上两个网址供用户选择呢？|
+|二维码扫描|手机摄像头可以扫描二维码形式的网址，这个也可以算作输入模块的一个功能吧。|
+|语音输入|手机话筒可以接收语音，识别为关键字，然后进行搜索或者浏览，当然也算作输入模块的功能。|
+
+表 8.3.4 显示子系统的完善
+
+|功能|描述|
+|--|--|
+|页面缩放|在手机屏幕上可以看清更小的细节，或者看到网页的全局。|
+|页内搜索|搜索页面文本内的关键字。|
+|回到顶部|一键即可回到页面顶部，重新浏览。|
+|起始页|展示新闻，或者常用网址，当然还可能有广告。|
+|显示多页|同时浏览多个页面，可以切换。|
+|导航|在当前页前进、后退，通过缓存看网页。|
+
+### 8.3.3 需求引导
+
+#### 1. 微信支付的需求是怎么来的？
+
+支付是电商平台的重要组成环节，所以说是淘宝促成了支付宝的诞生，是钢需，可以说是理所当然的。但是微信定位在通信上，为什么会有支付的需求产生呢？
+
+在微信支付存在之前，只有支付宝和银行可以支付，而且银行系统死守传统观念，不注重服务质量。
+
+仔细看一下微信中的其它业务点：
+- 公众号打赏
+- 表情商店的付费表情包
+- 在线游戏充值
+- 朋友圈转账还钱
+
+需要支付时，堂堂的腾讯微信 APP 总不能要求用户用阿里的支付宝吧？所以产生了微信支付的需求。
+
+最开始，微信支付采取了简单的方式——直接绑定银行卡，但是在体验上存在两个问题：
+
+- 验证码问题，当时快捷支付的使用流程是用户输入密码然后接收验证短信，输入验证码完成支付。用户希望去掉短信验证这个环节。
+- 密码问题，当时支付工具的支付密码普遍采用英文数字混合的形式，张小龙希望能够像 ATM 一样使用六位的数字密码。
+
+在产品团队的努力下，这两个需求得以实现。也正是因为这两项优化，微信支付变得流程简短、操作便捷。
+
+实际上，微信支付的需求有两层：
+1）能够支付。
+2）快捷支付。
+
+第一层是基本型功能需求，第二层是期望型功能需求。微信在保证了平台业务发展的同时，也满足了用户的需求。
+
+#### 2. 微信红包的需求是怎么来的？
+
+腾讯年初八“刷红包”的传统，每年发“开工利是”时，会在红包中随机放入不同金额的现金，这种不确定性让领红包的人充满期待，也引起了相互比较，产生话题性。
+
+腾讯联合创始人 Tony 将一些微信团队成员拉进了一个微信群，希望能够依托微信群，趁着春节做一个红包产品，能够让用户感到惊喜和好玩，在收到红包之后也能情不自禁地参与到发红包的行列中，让红包像击鼓传花一样传起来。于是，“拼手气红包”便这样诞生了。
+
+起初，微信红包是一个H5产品，使用公众号向用户推送领取通知。为了让用户体验更好，张小龙提出把微信红包做成原生功能。他希望通知用户的行为不通过公众号推送这种比较重的模式，转而采用群内通知，既不打扰用户，又不割裂产品体验。随着产品交互的调整和央视春晚“摇一摇”活动的进行，微信红包迅速向三四线城市下沉，用户活跃度显著提升。
+
+如果用 KANO 模型来分析，“微信红包”是一个惊喜型功能。它的来源并非是最终用户提出的，而是产品团队提出的，这是惊喜型功能的一个重要特征。
+
+#### 3. 支付宝的社交功能是怎么来的？
+
+从阿里的角度来看，如果微信做支付是合理的，那么支付宝做社交就没有什么不合理的。人们既然能在聊天的时候花钱，那么为什么不能在花钱的时候聊天呢？
+
+阿里选择支付宝做社交功能，是因为在其所有产品中，支付宝是最有可能的入口，无需被“购物”、“电商”的概念绑架。这也证明了笔者在前面对“我们是否要做旺信 UWP 的质疑”，阿里自己都不看好旺信，微软为什么还要去做？
+
+但是，“在花钱的时候聊天”这件事儿，不是用户的真实需要，而是支付宝产品团队臆想出来的，试图引领、教育用户的行为。从社交到支付的需求引导，是自然发生的，是一种依赖增加；而从支付到社交的“引导”，是一种信任崩塌。
+
+<img src="img/Slide22.SVG"/>
+
+图 8.3.4 需求引导
+
+同样的两件事，有一个先后发生的条件，如同概率论中的条件概率公式：
+
+$$
+P(AB) = P(A) \cdot P(B|A) \tag{8.3.1}
+$$
+$$
+P(BA) = P(B) \cdot P(A|B) \tag{8.3.2}
+$$
+
+其中：
+- $P(A)$ 表示聊天需要的概率
+- $P(B)$ 表示支付需要的概率
+- $P(AB)$ 表示聊天和支付同时需要的概率
+- $P(A|B)$ 表示在支付时去聊天的需要（后面的 B 表示条件）
+- $P(B|A)$ 表示在聊天时去支付的需要（后面的 A 表示条件）
+
+可以推断，没有人会在支付时去聊天，所以$P(A|B)$会非常小，尽管$P(B)$很大（使用支付宝的人很多），但是两者的乘积$P(BA)$会很小，即在支付宝中加聊天是行不通的。
+
+支付宝团队看到了公式 8.3.1 的成功（即微信上加支付的成功），并且主观地认为$P(AB) == P(BA)$，因此推论$P(A|B)$也可以成功。
+
+有一个类似的故事是这样的：
+
+```txt
+信徒：“我可以在祷告时吸烟吗？”
+神父：“不可以！这是对神的不敬。”
+
+信徒：“那我可以在吸烟时祷告吗？”
+神父：“可以！这是对神的无时无刻的挂念。”
+```
+
+### 8.3.4 需求推荐
+
+一个大家都知道的例子是“纸尿裤和啤酒”的故事，并不是“多喝啤酒会需要纸尿裤”，而是“去超市买纸尿裤的男人通常会顺便买啤酒”。图 8.3.5 左侧子图表明，“啤酒”和“纸尿裤”没有直接联系，而是通过“男人”联系起来的。
+
+<img src="img/Slide23.SVG"/>
+
+图 8.3.5 需求推荐
+
+
+#### 1. 乐器的例子
+
+木头喜欢音乐，经常买一些乐器，10孔的布鲁斯口琴就买了三把（C调，E调，G调）。可是每次再登录淘宝或者京东时，给木头推荐的还是各种品牌的口琴，很无语。用户一旦下单了，系统能监控到下单动作，就不要再推荐类似商品了。
+
+那么买完口琴后，系统应该推荐什么呢？根据木头的音乐爱好者的身份，应该推荐：
+
+1）谱架，因为吹口琴需要看谱子；
+2）麦克风和音响：没有音响系统，口琴的声音是没有感召力的，高灵敏度麦克风也很重要；
+3）电子琴和吉他：在吹奏乐器的鄙视链上游，是键盘乐器和弹拨乐器，电子琴比较容易学，吉他配口琴特别好听。
+
+这比那个“啤酒和纸尿裤”的例子更具有专业知识性。图 8.3.5 右侧下方的子图说明了依赖本领域知识而得到的推荐顺序。
+
+#### 2. 外卖的例子
+
+疫情期间，自己做饭太烦了，难免要点一些外卖。木头今天点了宫保鸡丁，系统明天还推荐宫保鸡丁；木头今天点了米饭炒菜，系统明天还推荐米饭炒菜。是想让用户吃腻为止吗？
+
+让木头斗胆来建议一下一个好的外卖推荐系统应该怎么做。衡量饮食的参数要分几个方面：
+
+1）口味，酸辣咸甜苦淡；
+2）主食，米饭面条饺子；
+3）食量，半斤还是四两；
+4）偏好，肉菜主食比例；
+5）价位，温饱还是饕餮；
+6）营养，蛋白纤维碳水。
+
+图 8.3.5 右侧上方的子图说明了这些参数。
+
+有了以上这些指标，在按照星期循环和早中晚饭推荐，可以做到精准推送了。尤其是“营养”因素，还没有任何系统做到，而且用户往往是偏食的，只吃几种口味的菜，对于营养均衡极为不利。尤其是晚上十点钟以后点外卖的，应该提高价格并加以警告，因为对人的作息时间是极为不利的，吃完立刻睡觉，很可能造成食管胃酸回流。
+
+有可能是电商和外卖系统的用户黏度足够好，不愁用户群，所以大家都还没有开发出有 AI 或专家参与的推荐系统来，这会是一个商机吗？

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.4 需求的漂移与演进.md

@@ -1,123 +0,0 @@
-## 8.4 需求的漂移与演进
-
-### 8.4.1 需求漂移
-
-需求漂移，准确地说是需求的类别漂移，是指同样一个功能，在不同场合会有不同的理解、效果、满意度，这是由于“场合”对该需求的偏好影响。
-
-
-<img src="img/Slide18.SVG"/>
-
-图 8.4.1 - 需求类别漂移
-
-
-#### 因使用者而异
-
-由于教育水平、工作性质、年龄阶段等的差别，人们的需求各不不同。
-
-比如我们上面举的关于 Word 的三个看似无用的功能的例子，也许有的人没有浏览器使用基础（比如一些老人），这些功能对他们来说就有很大的帮助。因为这些软件都有 Telemetry（日志）机制，所以可以知道有多少人还在使用这些看似“过时”的功能，所以也就没有取消掉。
-
-再比如手机上的计算器功能，如果是科技工作者使用，希望有乘方、开方、对数、指数等功能；如果是普通老百姓使用，那么有加减乘除就足够用了，功能多了反而容易按错键。
-
-#### 因为文化差而异
-
-在中国的即时消息通信软件中，各种搞笑的表情包被广泛使用，有些甚至是需要付费购买的。表情包通常是漫画形式的，体现出创作者的别具匠心。
-
-微软的 Teams 团队协作软件功能强大，其中的消息模块也有发送 GIF 表情包的功能。但是由于是美国文化，表情包都是那种电影里截出来的人物表情片段，中国人使用起来觉得特别别扭，所以在 Teams 日常通信中，笔者及其它同事们都很少使用 GIF 表情包。
-
-#### 因产品地位而异
-
-SmartArt 对 Power Point 这个产品本身来说，开发者要持续对这个功能的维护，比如增加更多的组合图形，是一种期望型功能。但是对于其它竞争者来说，没有这个功能的话，就根本别想进入市场了，那么这个功能就会变成基本型功能。
-
-所以对于后来者、竞争者来说，用户对它们的要求是必须提供惊喜型功能，或者提供很多期望型功能，才有可能后来居上。
-
-#### 因时间而异
-
-即使是惊喜型功能，在经过一段时间的使用后，新鲜感会消失；或者随着竞争对手也跟风推出类似的功能，变得不那么吸引人。
-
-比如 Windows Hello 人脸识别登录功能，在刚刚随着 Windows 10 发布时，大家觉得特别的高科技，配合着 Surface Book 的时尚感，使得 Windows 10 很快普及。所以它属于惊喜型功能。
-
-但是一段时间过后，假设没有这个功能了，用户会觉得不方便，它就会退化为期望型功能。
-
-### 8.4.2 需求演进
-
-需求总在持续地演进，所以软件开发团队需要持续调研功能，产品需要持续迭代，与时俱进才能赢得用户。
-
-木头用开发手机浏览器的经历，来推演一下当年浏览器领域的需求演进过程。图 8.4.2 展示了木头在前四周的学习过程。
-
-
-<img src="img/Slide19.SVG"/>
-
-图 8.4.2 - 需求演进
-
-
-微软在 IE 落伍后尝试继续自研内核，开发基于 EdgeHTML 渲染内核和Chakra JS 解析引擎的 Edge 浏览器，而且继续绑定在 Windows 10 上发布。但是一些问题依然存在：性能，兼容性，扩展插件，更新频率等。所以在 2017 年的时候，微软想尝试一下使用 Chromium 内核开发浏览器。为了保险起见，微软决定先让中国的开发团队在手机上开发移动端浏览器，先试试水，如果成功的话，再在桌面端更新浏览器内核策略。于是，木头所在的团队接受了这一“光荣”的任务。
-
-#### Week 1（第一周）
-
-在这之前，浏览器对于木头来说，就是日常使用，没有仔细研究过功能、架构、竞品等等。所以，在第一周（Week 1），木头认为浏览器就是“浏览器”本身的字面意思。所以，哥儿几个每个人都分到了一个 Android 手机，又把一个台式机装成 Ubuntu 16.0，下载了 Chromium 的代码后，编译出一个浏览器来，安装到 Android 手机上。成果如图 8.4.3 所示。
-
-
-<img src="img/Slide20.SVG"/>
-
-图 8.4.3 - 搭建开发环境
-
-
-
-恍惚间有一种大功告成的感觉，但是，这仅仅是一个开始，后面的几周是疯狂学习浏览器知识的日子，就如同当年开发第一个浏览器的先行者们那样，不断探索这个产品的奥秘。
-
-#### Week 2（第二周）
-
-木头使用着自己编译出来的浏览器，仔细端详着手机屏幕，忽然发现原来浏览器是由“地址栏”和“窗口”两部分组成的！所以，我们至少应该有两个模块，才能实现完整的浏览器功能：
-
-1. 地址栏，用于输入网址，我们称之为输入模块；
-2. 窗口，用于显示网页，我们称之为显示模块。
-
-虽然地址栏很窄，但很重要。在手机上，由于屏幕小，有时候甚至是要隐藏地址栏的。
-
-至于显示网页的功能吗，当然是由 Chromium 提供的渲染引擎（Render Engine）完成的，这也是浏览器的核心。
-
-#### Week 3（第三周）
-
-木头使用着初步演进后的浏览器，刚开始还洋洋自得：输入输出都有了，很完备。但是很快就发现了新的需求，如表 8.4.1 和 8.4.2 所示，并且随着这些功能的加入，以前的输入和显示“模块”要升级为“子系统”了。
-
-表 8.4.1 - 输入子系统的改进
-
-|功能|描述|
-|--|--|
-|合法性验证|随着测试次数的增加，在地址栏里输入的网址越来越不规范，HTTP GET 经常会出错。那我们就加入一个网址合法性验证的功能吧，避免错误的网址传到后端。|
-|自动补全|“https://www.microsoft.com”这个网址太长了，每次都需要输入得很准确才能正常工作。能不能在输入“www.m”以后，自动补全为“www.microsoft.com”呢？|
-
-表 8.4.2 - 显示子系统的改进
-|功能|描述|
-|--|--|
-|页面卷滚|页面内容很多，手机屏幕小，绝大多数网页显示不下，那就只好加一个卷滚功能了。|
-|刷新单页|有时候由于网络原因，造成页面加载不畅，css没有下载完整，页面乱七八糟的。所以增加一个刷新功能吧。|
-
-经过第三周的探索，我们浏览器已经演进为一个较为人性的“成品”了，但是距离“产品”还差得很远。
-
-#### Week 4（第四周）
-
-在经过前三周的摸索后，到了第四周，木头已经懂得了需求不断演进的趋势，变得小心翼翼了。果然，经过一段时间的使用，又发现了很多新功能，可以让输入和显示两部分演进得更加完善。表 8.4.3 和 表 8.4.4 列出了新的功能。
-
-表 8.4.3 - 输入子系统的完善
-
-|功能|描述|
-|--|--|
-|容错|输入“http://”时，由于手机键盘小，每次都会打成“htp:/”，我们需要地址栏模块可以认识这个常见的“错误”。|
-|Cookie|每次登录网页都需要重新输入用户名和密码，烦死了。增加一个 Cookie 功能来替我们节省些时间。|
-|关键字搜索|如果输入的是一个关键字，比如“azure”，这个浏览器能不能智能地懂得我们是想搜索“azure”这个名词呢？|
-|历史网址重现|以前输入过“www.microsoft.com”，也输入过“www.mail.163.com”，能不能在用户输入“www.m”后，自动显示一个下拉列表，列出以上两个网址供用户选择呢？|
-|二维码扫描|手机摄像头可以扫描二维码形式的网址，这个也可以算作输入模块的一个功能吧。|
-|语音输入|手机话筒可以接收语音，识别为关键字，然后进行搜索或者浏览，当然也算作输入模块的功能。|
-
-表 8.4.4 - 显示子系统的完善
-
-|功能|描述|
-|--|--|
-|页面缩放|在手机屏幕上可以看清更小的细节，或者看到网页的全局。|
-|页内搜索|搜索页面文本内的关键字。|
-|回到顶部|一键即可回到页面顶部，重新浏览。|
-|起始页|展示新闻，或者常用网址，当然还可能有广告。|
-|显示多页|同时浏览多个页面，可以切换。|
-|导航|在当前页前进、后退，通过缓存看网页。|
-

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.4 需求的非正常变更.md

@@ -0,0 +1,323 @@
+## 8.4 需求的非正常变更
+
+### 8.4.1 非正常变更的故事
+
+以下故事从若干真实案例改编而成，图 8.4.1 展示了这一过程。
+
+
+<img src="img/Slide24.SVG"/>
+
+图 8.4.1 需求恶行变更
+
+
+
+#### 1. 第一次会晤
+    
+客户（甲方）心中对要做的软件并没有很细致的预期，所以第一次见面时，客户会说：“我们就做一个管理软件，很简单！” 
+   
+乙方需求调查人员心想：“原来你们还都没有想好。”
+   
+双方老总边喝茶边聊合作前景，很高兴。
+   
+【最佳实践】甲方如果软件意识淡漠的话，很难主动提出需求。
+
+#### 2. 第二次面谈
+   
+但是当软件公司（乙方）提出更多的疑问后，客户会迫使自己仔细想一想要做什么，第二次会说：“我们要做一个囊括全公司的业务流程管理软件，包括部门 A，部门 B，部门 C。” 
+
+乙方的需求调研人员驻场两周后，回去加班加点地做需求整理。
+
+双方老总边喝咖啡边聊行业趣闻，很高兴。
+
+【最佳实践】需求调研的目的，就是帮助甲方提出他们的真实需求。
+
+#### 3. 第三次谈判
+   
+在乙方整理出了基本的需求列表后，拿给甲方看。客户数了数功能列表条目的个数：“一共只有50条吗？咱们可是要有 100 万的合同呀！每条就 2 万块钱！太贵了！咱们再加 20 条功能，然后签合同。” 
+   
+乙方需求调查人员才明白：“原来客户是按功能个数算钱的，早知道我就把它们拆分得细细的！”
+
+双方老总签了合同，边喝酒边聊国际形势，很高兴。
+   
+【最佳实践】客户不会懂得软件的价值，把功能列表写的细一些总是没有坏处的。
+
+#### 4. 原型开发结束
+
+客户在这期间看了一下别家的产品，觉得：“我们也应该有那家软件公司的产品的几个功能，领导很喜欢。没有的话第一期的预付款就成问题了。”
+
+双方老总握手寒暄了一下，就各自离开了。
+
+乙方设计人员回去和需求人员讨论到半夜，感觉还是要先攻克几个技术问题，才能继续做设计、开发工作。
+   
+【最佳实践】原型要尽早提交给客户，以免在以后的开发中出现很大的修改。竞争对手的信息调研，乙方要提前帮助甲方完成。
+
+#### 5. 第一期产品交付
+      
+客户找了各个部门 10 几个人来一起看，你一句我一句地提意见：
+   
+   - “界面感觉和想象的不一样，我这眼睛不好，这里字体能不能大一些？”
+     
+     *注：软件界面上所有字体都是标准的，牵一发而动全身。*
+
+   - “哟，这个功能 A 都可以用计算机代替呀，那太好啦！我们还有另外两个功能 B 和 C 应该也可以这么做吧？这个咱们补上！”
+
+     *注：用户受到启发了，新需求呈井喷式涌现。*
+
+   - “这里的日期是自动生成的吗？那不行，有时候我们会晚几天才填写资料，但是时间必须是任务分配下来的时间。”
+  
+     *注：不正规的工作习惯导致的需求变化。*
+
+   - “我们这个单据不是给一个领导看的，是要给多个领导审批的，这个要流程必须有。”
+
+     *注：当时只说要给领导审批，没说是几个领导。*
+
+甲方提出一堆修改意见，忘记了前面的合同条款，开发人员忙着记录，密密麻麻记了两页纸。
+
+双方老总打电话通了个消息，说公司有事脱不开身，没有见面。
+   
+#### 6. 后期产品维护
+   
+客户翻了翻合同条款：“哈哈，幸亏我这里写了个三年质保！那个什么，我们有个部门 D 和部门 E，也要纳入到这个系统中。” 
+   
+双方老总这次干脆就没出现。
+
+最后乙方公司被拖垮了，入不敷出；给甲方提供的软件在凑合使用了一年后，跟不上数字化转型的大趋势了，不得不换掉，又找了另外一家软件公司合作。
+
+【最佳实践】质保不等于新需求。两败俱伤的做法是双方要尽力避免的。
+
+### 8.4.2 需求变更在微软
+
+#### 1. 自主产品部门
+
+需求变更在国内的软件公司是司空见惯的，但是在微软，对于需求变更是严格控制的。当然微软主要是做自己的产品，为最终用户服务，而不像小软件公司是为企业客户服务。所以在微软，是不会发生图 8.4.2 所示的情景的，但那却是一般的中小型软件公司，包括国内的大型软件公司的通病。
+
+
+<img src="img/Slide25.SVG"/>
+
+图 8.4.2 需求恶性变更带来的灾难
+
+
+1）Office 产品
+
+在 Office 团队，以桌面版为例，一般是制定一个为期三年的开发计划，在开始前几个月内，这三年内的所有新特性（Feature）都要确定好，就不许再随便改动了。即使发生以下两种情况也是如此：
+
+- 发现有些特别好的特性没有加入到计划中。这种情况，需要等下一个三年才可以有机会加入。
+- 发现有些特别糟糕的特性已经开始开发了。这种情况，即使那个特性很糟糕，也要维持，下一个三年才有可能去除。
+
+2）Windows 操作系统
+
+在 Windows 团队，以 Windows 10 为例，制定为期半年的开发计划，所有的新功能都是精挑细选。加上计划阶段，实际的开发时间只有三至四个月，后面要留出两至三个月做集成、测试、稳定，表现不好的功能会被去除掉。
+
+通常情况是 10 个 Feature 有可能被去掉了 7 个，只有 3 个 Feature 最终 Release。这期间绝不会有新功能加入的机会。
+
+3）云端产品
+
+比如 Bing 和 Azure，会自由一些，因为云端发布的特性决定了其实时性，所以有了新的功能可以随时加入。
+
+#### 2. 企业服务部门
+
+木头采访了一位在微软中国 GSMO（Global Sales, Marketing and Operations，销售市场和服务）部门工作的朋友大淘（网名），以下是他们的对话记录。
+
+
+木头：你们最近还要经常访问客户场吗？
+大淘：是呀！项目到了最后阶段了，在赶 DDL（Dead Line，最终期限）。
+
+木头：那我们长话短说吧。我就想知道你遇到过这种情况没有：客户的需求变来变去，最后造成灾难的事情。
+大淘：我觉得这在企业服务部门比较容易常见，对于这种甲乙方的关系，签订合同之后，有可能合同里边没有写得特别的明确。有可能甲方在中后期会提出一些要求，就是揪合同里边的字眼。所以要对合同里边的项目条款定得非常的清晰，边缘也要非常的清晰。
+
+木头：你能举一个具体的例子吗？
+大淘：项目里边一个最简单的例子，合同里说要做一张表，展现一个条形图。实际的过程中，客户在第一天的时候要一个红色的条形图，第二天可能又会改蓝色的，第三天可能觉得条形图不好，要求会变成饼图。不断的去改，不断去添加。
+
+木头：这么小的功能点在合同里肯定写不全呀？不过这种级别的问题也不会造成灾难，还好。
+大淘：造成灾难的情况没有见过，微软的项目经理都会把控这个范围，会允许有小的改动，但是整体上不会变，否则造成客户因为这个事情而不验收。可能有边界不清晰的时候，基本上都不会有灾难。但是其他小的软件厂商没有这种把控的话，可能会造成严重的灾难。
+
+木头：那么你们遇到的最麻烦的事情是什么呢？
+大淘：比如原定10月1号要上线，但是我的测试一直都没有通过，用户这边的测试没有通过，那有可能就要拖，拖到客户验收为止，可能到10月30号啊，这是一种情况。另一种情况是你上线了之后，客户不讲理，尾款会拖着付。
+
+木头：原因是什么呢？
+大淘：造成这个的原因有几个阶段：最开始售前去卖这个方案的时候，把这个事情说成了一辆宝马车，然后那客户听了感觉很开心，觉得什么都可以实现；后来项目经理介入开始做项目的时候，项目经理会把它说成一辆摩托车，客户觉得能接受，就是开起来风大些，戴个风镜还能接受；最后，开发人员做出来的是辆自行车，这个时候客户就很不满意了，因为这个期望是不断降低的。画个图的话就像图 8.4.3 那样。
+
+
+<img src="img/Slide26.SVG"/>
+
+图 8.4.3 预期与交付的差距
+
+
+木头：哦！那是因为大家理解不一致吗？
+大淘：前期为了投标，一般情况下销售人员肯定会把产品说成像宝马车，然后在项目经理介入的时候，一般可能会把预期稍微低一点，比如他说成了一辆自行车，那最后交付出来发现是一辆摩托车，用户的最后的满意程度可能会提升一些。当然风镜还要免费送，哈哈！
+
+木头：那么如何避免呢？
+大淘：整体上我觉得还是不同职位之间的协调，是前面的销售，中间的项目经理，或者说产品经理和开发，再到客户四个方面的协调。再就是时间点和范围要非常的清楚，一般项目前面会陈述范围在哪儿？它包括什么东西不包括什么东西，那它包括到什么程度？这个东西要写的非常清楚，我觉得基本就是这些。
+
+
+### 8.4.3 需求变更控制
+
+
+<img src="img/Slide27.SVG"/>
+
+图 8.4.4 需求变更控制
+
+
+#### 1. 基本教育
+
+售前人员要进行基本的客户教育。需求变更的原因是双方造成的，乙方需要对甲方进行一些基本软件知识的教育。
+
+1）软件知识
+   
+   客户总会说：“如果是硬件也就算了，你们这个不就是代码吗？为什么不能改？”
+   
+2）开发流程
+
+   甲方对软件开发流程不了解，会有疑问：“上次原型提供得挺快的呀，这次怎么要花这么长时间？”
+   
+3）知识产权
+   
+   有些模糊知识的甲方会问：“不就是训练一个什么 AI 模型吗？我听说有个 PyTorch 就专门干这个的，而且还不要钱，你们这个怎么花这么长时间，价格还很贵？”
+
+4）变更过程
+   
+   乙方对甲方的需求没有给与必要的控制管理，任由新需求滋生。乙方需要让甲方明白：需求变更的代价很大。
+
+#### 2. 合同控制
+
+市场部门负责合同控制。
+
+1）明确细节
+   
+   合同越细，将来的纠纷越少。比如上面提到的一些反例：
+   - 界面颜色、字体大小
+   - 图的形状、颜色、尺寸
+   - 功能点的细节描述，如输入、输出、动作
+   - ......
+
+2）确定边界
+
+   - Goal/Non-Goal，目标和非目标
+   - 软件维护升级的范围
+   - 与外部系统交互时双方的职责
+   - ......
+
+3）培训与文档
+   
+   - 如何正确地使用
+   - 如何解决简单故障
+   - 系统架构讲解
+   - 输入输出细则
+   - ......
+
+#### 3. 流程控制
+
+项目经理或者开发经理要进行需求变更流程控制。
+
+1）建立标准
+      
+   需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（用户参与评审），可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。
+
+2）制订流程
+
+   制订简单、有效的变更控制流程，在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。
+
+3）成立小组
+   
+   成立项目变更控制小组，负责裁定接受哪些变更，由项目所涉及的多方人员共同组成，应该包括甲方和乙方的决策人员在内。
+
+4）严格执行
+   
+   需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。
+
+   何为“相当级别”？即，看看变更是界面级别的，还是模块级别的，或是系统级别的？变更太大的话，还要牵涉到费用问题。
+
+### 8.4.4 避免非理性需求
+
+非理性需求往往表现在三个方面，用公式 8.4.1 来表示：
+
+$$
+非理性需求=\begin{cases}
+关系与利益 \\
+行业与对手 \\
+个人与团队
+\end{cases} \tag{8.4.1}
+$$
+
+
+对于这三方面处理不好的话，就会造成非理性的需求，进而产生非理性的行为。尽管你正确地做事了，但是没有做正确的事。Do right things, rather than do things right。 图 8.4.5 中把非理性需求分成了三类：关系和利益、行业与对手、个人与团队。
+
+<img src="img/Slide28.SVG"/>
+
+图 8.4.5 非理性需求举例
+
+#### 1. 与用户的关系利益
+
+**“用户提到的需求我都做。”**
+  
+甲方的需求是无边无际的，需要管理、引导、限制。
+  
+木头经历过的一个简单例子就是：当 Windows 10 刚刚走向市场时，为了营造良好的生态环境，微软花重金在各个国家寻找合作伙伴，让它们在 Windows 10 上，包括当时还存在的 Windows Phone，做商业软件，比如阿里的淘宝 App。木头是 UWP（Universal Windows Platform）版淘宝 App 的缔造者。
+
+淘宝方要求不仅要做淘宝 App，还要做旺信 App 的 UWP 版本。市场人员为了拿下订单，很爽快地答应了这个要求。但是作为长期在一线战斗的木头看来，旺信 App 根本不会有什么用户的，原因很简单：1. 微信霸占着自由通信市场；2. 淘宝已经内置旺信的部分功能，以便买家与卖家通信。
+
+事实证明木头的观点是正确的，旺信 UWP App 的用户量少的可怜。但更可怜的是我们的开发人员，5个人花了四个多月的时间，非常辛苦。如果用这些资源来丰富淘宝 UWP App 的功能，将会是一个不同的局面。
+
+#### 2. 与老板的关系利益
+
+**“老板说啥就做啥。”**
+  
+如果老板代表用户的最终利益，这是成立的，否则你可以站在用户利益的角度来和老板讨论问题。
+
+在微软，老板更多地是一个 People Mananger（管人的），他/她可以分配工作，但是更多地要由 PM 或相关角色来决定做什么。
+
+#### 3. 直接的金钱利益
+
+**“这个还在赚钱，我要做。”**
+  
+赚钱的东西当然要做，但是也要有一部分力量去研究新产品。如果你有开拓精神和能力，（公司）应该（安排你）去挣明天的钱。
+
+微软在鲍尔默时代，全力投入在 Windows、Office，如果用足球场做比喻的话，这二者处于前锋的位置，冲锋陷阵，是微软财务报表的主要贡献者。但是，大家也看到了微软股票的低迷，从投资者角度看，微软的赚钱手段太少了。
+
+当时，Bing Search（必应搜索）算是一个新生的产品，因为微软看到谷歌在搜索上大赚其钱，眼红了。在沈向洋博士的带领下，必应搜索终于能在美国市场可以与谷歌搜索分庭抗礼了。
+
+到了萨提亚时代，一本《刷新》（英文名称为 Refresh）的书阐明了 CEO 的新思想，微软放弃 Windows Phone，大力投入 Azure 云。Mobile First, Cloud First（移动为先，云为先）的战略使得微软有了新的利润增长点，股票价格也是一路飘升。
+
+从组织结构上也可以看出，Windows 的明星光环已经暗淡，在足球场上处于后卫的位置，当然后卫也很重要。但是 Windows Team 内部的一些陈旧的做派实在是不能被木头所认可，但也许那就是 Windows 的产品风格吧？
+
+#### 4. 未来的金钱利益
+
+**“别人做这个赚钱，我们也做。”**
+  
+前面说到微软是看到谷歌搜索赚钱了，所以才做的必应搜索，整个公司为这个战略投入了几千人的大团队，幸好成功了，否则微软会彻底被互联网抛弃。
+
+但是，虽然同样有 Android 和 iPhone 做样板，Windows Phone 却失败了，原因很多，另文说明。只能说，别人在赚钱的东西，自己再去做不一定赚钱。
+
+
+#### 5. 关于竞争对手
+
+**“全面赶超竞争对手，每个功能都全面提高；我要做到行业最好。”**
+  
+如同需求竞争策略一节中讲到的，要把需求细分，有的努力，有的维持，有的不做，君子有所为有所不为。
+
+#### 6. 关于行业市场
+
+**“这个做的人太多，我不做；这个做的人太少，我不做。”**
+  
+前者通常是对的，避免市场的激烈竞争。后者也通常是对的，避免没有市场。另一方面考虑，做的人多，也许是因为新兴市场需求旺盛。在已经有很多人铺好路的情况下，不妨去分一杯羹。做的人少，也许是行业刚刚兴起，正是占领市场的良好时机。
+
+此时要依靠决策人的智慧。
+
+#### 7. 个人主义
+
+**“我觉得爽, 我就做这个功能；这个功能太简单了，我不想做。”**
+  
+个人能力与团队需要吻合时，当然可以勇挑重担，在微软，这通常叫做 align，个人兴趣与团队利益的 align。领导通常会照顾到个人的特长与兴趣，而不是乱分配任务。但是这种文化不代表你可以任性。
+
+木头有一次听到朋友抱怨：有一位老兄，在微软是个 Senior Level，出去后晃了几年，再回来后弄了个 Principle Engineer 职位。朋友给他安排了一个工作，过了两周和他检查进度，结果这位老兄说：那个太容易了，我没有做。当时朋友就想骂人。也许这位老兄有一些 Research 的经验，没有兴趣在 Engineer 上。
+
+另外一种常见的情况是，我们会听到一些刚刚走出校门的学生兵说：这个太容易，我不想做。新到一个公司，都要从简单的事情做起，证明自己的能力，获得同事的信任，然后才有资格去挑挑拣拣。
+
+#### 8. 团队惯性
+
+**“我来的时候，大家就做这个产品了；我们已经在这个行业很久了，要坚持。”**
+ 
+微软 CEO 萨提亚在《刷新》一书中强调了 Growth Mindset（成长性思维）的重要性：“我们必须以客户为中心。我们的业务核心就是要保持好奇心，以及保持用伟大技术满足客户未能表达的和未被满足的渴望。”
+
+在一个公司或一个行业时间太长，会有一种厌倦，或者是跳不出固有思维模式，成长性思维就是帮助我们保持好奇心和创新精神。微软每年在全球范围的 Hackathon 活动就孕育出了很多好的想法，最终形成新产品或者已有产品中的令人兴奋的新特性。
+

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.5 PM 项目经理.md

@@ -1,16 +1,16 @@
-## 8.9 PM 过程经理
+## 8.5 PM 过程经理
 
-### 8.9.1 PM 的定义
+### 8.5.1 PM 的定义
 
-PM（Program Manager）是微软的工作职位，在其它公司大概都有Product Manager（产品经理）和Project Manager（项目经理），微软的Program Manager（过程经理，只能这么翻译了，也有叫程序经理的）可以用公式 8.9.1 来理解：
+PM（Program Manager）是微软的工作职位，在其它公司大概都有Product Manager（产品经理）和Project Manager（项目经理），微软的Program Manager（过程经理，只能这么翻译了，也有叫程序经理的）可以用公式 8.5.1 来理解：
 
 $$
-PM=产品经理+项目经理 \tag{8.9.1}
+PM=产品经理+项目经理 \tag{8.5.1}
 $$
 
-我们来用表 8.9.1 来简单对比一下三者的区别：
+我们来用表 8.5.1 来简单对比一下三者的区别：
 
-表8.9.1 - 产品、项目、过程经理的区别
+表8.5.1 产品、项目、过程经理的区别
 ||产品经理|项目经理|PM|
 |--|--|--|--|
 |中文名称|产品经理|项目经理|过程经理|
@@ -19,20 +19,20 @@ $$
 
 那么微软的 PM 的工作内容是什么呢？我们用章节中的内容来解释一下：
 
-- 第五章的全部工作
-- 第六章的需求逻辑分析
-- 第七章的全部工作
-- 其它一些工作
+- 第六章的全部工作；
+- 第七章的第 1~4 步工作；
+- 第八章的全部工作；
+- 其它一些工作，比如和开发经理共同讨论产品方向，有产品经理的部分角色。
 
-其中第六章的需求技术分析部分，一般由开发人员完成，便于分析、设计、开发三者有较强的延续性。
+其中第七章的需求技术分析部分，一般由开发人员完成，便于分析、设计、开发三者有较强的延续性。
 
 
 <img src="img/Slide29.SVG"/>
 
-图 8.9.1 - PM 在团队中作用
+图 8.5.1 PM 在团队中作用
 
 
-在微软，PM 的比例大概为 15% 左右，即开发人员和 PM 的比例大概为 5:1 左右。PM 平时的工作关系网大致如图 8.9.2 所示。
+在微软，PM 的比例大概为 15% 左右，即开发人员和 PM 的比例大概为 5:1 左右。PM 平时的工作关系网大致如图 8.5.2 所示。
 
 - 左侧的市场、销售、客户、用户很好理解，提供产品的说明；
   
@@ -45,23 +45,23 @@ $$
 
 <img src="img/Slide30.SVG"/>
 
-图 8.9.2 - PM 的工作关系
+图 8.5.2 PM 的工作关系
 
 
 
 
-### 8.9.2 PM 的关键成果（Key Results）
+### 8.5.2 PM 的关键成果（Key Results）
 
-关键成果就是工作内容产出。前三个工作内容集中在产品和服务上，如图 8.9.3 所示。
+关键成果就是工作内容产出。前三个工作内容集中在产品和服务上，如图 8.5.3 所示。
 
 
 <img src="img/Slide31.SVG"/>
 
-图 8.9.3 - 产品和服务
+图 8.5.3 产品和服务
 
 
 
-#### 产品和服务定义（Product and Service Definition）
+#### 1. 产品和服务定义（Product and Service Definition）
 
 - 特性设想
   
@@ -78,14 +78,14 @@ $$
 
 这确实是传统的 Windows 向 AI 迈进的理想路线，很多 Windows Team 内部的人看完这个 Demo 后觉得“太酷了，等不及上线了！”。但是它有三个致命的问题：
   
-1. 这个 Feature 的需求确实是客观存在的，只是需求的重要程度不能确定，是不是钢需？或者只是万分之一发生概率的需求？
-2. 这个 Feature 所对应的 Scenario 是有问题的，用户本来可以做原生的文字或图片拷贝粘贴，不需要强迫用户做像素级的操作。
-3. 这个 Feature 的定位有问题，它应该存在在应用中，如浏览器，而不是 Windows 操作系统里。
+1）这个 Feature 的需求确实是客观存在的，只是需求的重要程度不能确定，是不是钢需？或者只是万分之一发生概率的需求？
+2）这个 Feature 所对应的 Scenario 是有问题的，用户本来可以做原生的文字或图片拷贝粘贴，不需要强迫用户做像素级的操作。
+3）这个 Feature 的定位有问题，它应该存在在应用中，如浏览器，而不是 Windows 操作系统里。
 
   在这个真实的故事里，可以商榷的地方真的很多，这提醒我们的 PM，特性要从用户角度出发，满足需求真实、场景合理、有竞争力等几个条件。
 
 
-#### 产品和服务设计（Product and Service Design）
+#### 2. 产品和服务设计（Product and Service Design）
 
 - 特性说明书（Feature Spec）
   
@@ -101,16 +101,16 @@ $$
 
 这个非常难做到，原因是：
 
-1. 这是一个系统级别的快捷键，需要注册到 Windows 的底层注册表里，由系统管理和监控，而Windows Team的人对这种新的快捷键的注册非常的谨慎，
-2. Windows 目前还没有组合快捷键的情况，所以没有基本的代码逻辑可以参考，一不小心会影响系统性能；
-3. 这种组合键一般在应用内使用，比如Visual Studio Code里的Ctrl + K F，关闭文件夹，就是按 Ctrl+K，松开 K，再按 F。
+1）这是一个系统级别的快捷键，需要注册到 Windows 的底层注册表里，由系统管理和监控，而Windows Team的人对这种新的快捷键的注册非常的谨慎，
+2）Windows 目前还没有组合快捷键的情况，所以没有基本的代码逻辑可以参考，一不小心会影响系统性能；
+3）这种组合键一般在应用内使用，比如Visual Studio Code里的Ctrl + K F，关闭文件夹，就是按 Ctrl+K，松开 K，再按 F。
 
 木头和其他开发人员就这个问题和 PM 讨论了很多次，PM 固执地认为，这些技术问题都可以解决，而且这个快捷键的设计是影响用户体验的关键，不能使用其他替代方案。大家弄得很不愉快，最后由于技术条件限制，没有实现。
 
 还有一个在坊间广为流传的故事：PM 要求一款手机应用的屏幕主颜色，能够根据手机保护套的颜色自动变化。PM 想象的实现的具体方式是“在用户对着镜子使用手机的时候，手机自动拍照并识别镜中的手机保护套的颜色”。
 
 
-#### 产品和服务所有权（Product and Service Ownership）
+#### 3. 产品和服务所有权（Product and Service Ownership）
 
 - 质量意识
   
@@ -124,19 +124,19 @@ $$
   
   定期使用自己的产品/服务来彻底理解它，并发现改进它的方法。正所谓己所不欲勿施于人，自己都不用的东西，怎么能说服别人用呢？
 
-质量意识和管理行为不仅仅是 PM 的工作，而是全体团队成员的职责，在前面介绍开发工程师岗位时，也提到了这一点。
+【最佳实践】质量意识和管理行为不仅仅是 PM 的工作，而是全体团队成员的职责，在前面介绍开发工程师岗位时，也提到了这一点。
 
 
-后三个工作内容重点在团队和流程上，见图 8.9.4。
+后三个工作内容重点在团队和流程上，见图 8.5.4。
 
 
 <img src="img/Slide32.SVG"/>
 
-图 8.9.4 - 产品和服务
+图 8.5.4 产品和服务
 
 
 
-#### 顾客服务生命周期（Customer Lifecycle）
+#### 4. 顾客服务生命周期（Customer Lifecycle）
 
 - 工具和资料
   
@@ -146,10 +146,10 @@ $$
   
   为内部相关人员和合作伙伴提供产品演示和培训。
 
-这是针对已有产品提供的一些资料，与市场销售人员配合，从客户角度来阐述他们的痛点和我们的解决方案。
+【最佳实践】这是针对已有产品提供的一些资料，与市场销售人员配合，从客户角度来阐述他们的痛点和我们的解决方案。
 
 
-#### 软件工程生命周期（Engineering Lifecycle）
+#### 5. 软件工程生命周期（Engineering Lifecycle）
 
 - 执行
   
@@ -163,9 +163,9 @@ $$
   
   参与设计评审、代码评审、测试计划评审。
 
-PM 并不是写完 PM Spec 就没事儿了，后面一系列的工程环节都需要参与，以随时了解进度、风险、变动等等。尤其是都最后阶段，还有 Bug Triage 的任务，来决定哪些 Bug 是必须修复的，哪些不是必须的。
+【最佳实践】PM 并不是写完 PM Spec 就没事儿了，后面一系列的工程环节都需要参与，以随时了解进度、风险、变动等等。尤其是都最后阶段，还有 Bug Triage 的任务，来决定哪些 Bug 是必须修复的，哪些不是必须的。
 
-#### 高效团队（Effective Team）
+#### 6. 高效团队（Effective Team）
 
 - 协作
 
@@ -187,5 +187,5 @@ PM 并不是写完 PM Spec 就没事儿了，后面一系列的工程环节都
   
   对如何在团队内开展良好工作的方法给与反馈。通常 PM 或受到或愿意参加更多的培训，来提高团队合作的技巧。
 
-上面这些条目中，PM 需要和 Dev Lead/Manager 合作来完成的，因为能当上 Dev Lead/Manager 的人也是有足够能力的，PM 得到这些人的支持会事半功倍。
+【最佳实践】上面这些条目中，PM 需要和 Dev Lead/Manager 合作来完成的，因为能当上 Dev Lead/Manager 的人也是有足够能力的，PM 得到这些人的支持会事半功倍。
 

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.5 需求的引导与推荐.md

@@ -1,127 +0,0 @@
-## 8.5 需求的引导与推荐
-
-先说明一下“需求演进”和“需求引导”的区别：
-- 需求演进是来自用户的，主要是解决一些痛点，实现基本型和期望型功能；
-- 需求引导是来自产品团队的，主要是实现一些新颖的想法，实现期望型和惊喜型功能。
-
-### 8.5.1 需求引导
-
-
-#### 微信支付的需求是怎么来的？$^{[3]}$
-
-支付是电商平台的重要组成环节，所以说是淘宝促成了支付宝的诞生，是钢需，可以说是理所当然的。但是微信定位在通信上，为什么会有支付的需求产生呢？
-
-在微信支付存在之前，只有支付宝和银行可以支付，而且银行系统死守传统观念，不注重服务质量。
-
-仔细看一下微信中的其它业务点：
-- 公众号打赏
-- 表情商店的付费表情包
-- 在线游戏充值
-- 朋友圈转账还钱
-
-需要支付时，堂堂的腾讯微信 APP 总不能要求用户用阿里的支付宝吧？所以产生了微信支付的需求。
-
-最开始，微信支付采取了简单的方式——直接绑定银行卡，但是在体验上存在两个问题：
-
-- 验证码问题，当时快捷支付的使用流程是用户输入密码然后接收验证短信，输入验证码完成支付。用户希望去掉短信验证这个环节。
-- 密码问题，当时支付工具的支付密码普遍采用英文数字混合的形式，张小龙希望能够像 ATM 一样使用六位的数字密码。
-
-在产品团队的努力下，这两个需求得以实现。也正是因为这两项优化，微信支付变得流程简短、操作便捷。
-
-实际上，微信支付的需求有两层：
-1. 能够支付；
-2. 快捷支付。
-
-第一层是基本型功能需求，第二层是期望型功能需求。微信在保证了平台业务发展的同时，也满足了用户的需求。
-
-#### 微信红包的需求是怎么来的？$^{[3]}$
-
-腾讯年初八“刷红包”的传统，每年发“开工利是”时，会在红包中随机放入不同金额的现金，这种不确定性让领红包的人充满期待，也引起了相互比较，产生话题性。
-
-腾讯联合创始人 Tony 将一些微信团队成员拉进了一个微信群，希望能够依托微信群，趁着春节做一个红包产品，能够让用户感到惊喜和好玩，在收到红包之后也能情不自禁地参与到发红包的行列中，让红包像击鼓传花一样传起来。于是，“拼手气红包”便这样诞生了。
-
-起初，微信红包是一个H5产品，使用公众号向用户推送领取通知。为了让用户体验更好，张小龙提出把微信红包做成原生功能。他希望通知用户的行为不通过公众号推送这种比较重的模式，转而采用群内通知，既不打扰用户，又不割裂产品体验。随着产品交互的调整和央视春晚“摇一摇”活动的进行，微信红包迅速向三四线城市下沉，用户活跃度显著提升。
-
-如果用 KANO 模型来分析，“微信红包”是一个惊喜型功能。它的来源并非是最终用户提出的，而是产品团队提出的，这是惊喜型功能的一个重要特征。
-
-#### 支付宝的社交功能是怎么来的？$^{[4]}$
-
-从阿里的角度来看，如果微信做支付是合理的，那么支付宝做社交就没有什么不合理的。人们既然能在聊天的时候花钱，那么为什么不能在花钱的时候聊天呢？
-
-阿里选择支付宝做社交功能，是因为在其所有产品中，支付宝是最有可能的入口，无需被“购物”、“电商”的概念绑架。这也证明了笔者在前面对“我们是否要做旺信 UWP 的质疑”，阿里自己都不看好旺信，微软为什么还要去做？
-
-但是，“在花钱的时候聊天”这件事儿，不是用户的真实需要，而是支付宝产品团队臆想出来的，试图引领、教育用户的行为。从社交到支付的需求引导，是自然发生的，是一种依赖增加；而从支付到社交的“引导”，是一种信任崩塌。
-
-<img src="img/Slide21.SVG"/>
-
-图 8.5.1 - 需求引导
-
-同样的两件事，有一个先后发生的条件，如同概率论中的条件概率公式：
-
-$$
-P(AB) = P(A) \cdot P(B|A) \tag{7.7.1}
-$$
-$$
-P(BA) = P(B) \cdot P(A|B) \tag{7.7.2}
-$$
-
-其中：
-- $P(A)$ 表示聊天需要的概率
-- $P(B)$ 表示支付需要的概率
-- $P(AB)$ 表示聊天和支付同时需要的概率
-- $P(A|B)$ 表示在支付时去聊天的需要（后面的 B 表示条件）
-- $P(B|A)$ 表示在聊天时去支付的需要（后面的 A 表示条件）
-
-可以推断，没有人会在支付时去聊天，所以$P(A|B)$会非常小，尽管$P(B)$很大（使用支付宝的人很多），但是两者的乘积$P(BA)$会很小，即在支付宝中加聊天是行不通的。
-
-支付宝团队看到了公式 7.7.1 的成功（即微信上加支付的成功），并且主观地认为$P(AB) == P(BA)$，因此推论$P(A|B)$也可以成功。
-
-有一个类似的故事是这样的：
-
-信徒：“我可以在祷告时吸烟吗？”
-
-神父：“不可以！这是对神的不敬。”
-
-信徒：“那我可以在吸烟时祷告吗？”
-
-神父：“可以！这是对神的无时无刻的挂念。”
-
-### 8.5.2 需求推荐
-
-一个大家都知道的例子是“纸尿裤和啤酒”的故事，并不是“多喝啤酒会需要纸尿裤”，而是“去超市买纸尿裤的男人通常会顺便买啤酒”。图 8.5.2 左侧子图表明，“啤酒”和“纸尿裤”没有直接联系，而是通过“男人”联系起来的。
-
-<img src="img/Slide22.SVG"/>
-
-图 8.5.2 - 需求推荐
-
-
-#### 乐器的例子
-
-木头喜欢音乐，经常买一些乐器，10孔的布鲁斯口琴就买了三把（C调，E调，G调）。可是每次再登录淘宝或者京东时，给木头推荐的还是各种品牌的口琴，很无语。用户一旦下单了，系统能监控到下单动作，就不要再推荐类似商品了。
-
-那么买完口琴后，系统应该推荐什么呢？根据木头的音乐爱好者的身份，应该推荐：
-
-1. 谱架，因为吹口琴需要看谱子；
-2. 麦克风和音响：没有音响系统，口琴的声音是没有感召力的，高灵敏度麦克风也很重要；
-3. 电子琴和吉他：在吹奏乐器的鄙视链上游，是键盘乐器和弹拨乐器，电子琴比较容易学，吉他配口琴特别好听。
-
-这比那个“啤酒和纸尿裤”的例子更具有专业知识性。图 8.5.2 右侧下方的子图说明了依赖本领域知识而得到的推荐顺序。
-
-#### 外卖的例子
-
-疫情期间，自己做饭太烦了，难免要点一些外卖。木头今天点了宫保鸡丁，系统明天还推荐宫保鸡丁；木头今天点了米饭炒菜，系统明天还推荐米饭炒菜。是想让用户吃腻为止吗？
-
-让木头斗胆来建议一下一个好的外卖推荐系统应该怎么做。衡量饮食的参数要分几个方面：
-
-1. 口味，酸辣咸甜苦淡；
-2. 主食，米饭面条饺子；
-3. 食量，半斤还是四两；
-4. 偏好，肉菜主食比例；
-5. 价位，温饱还是饕餮；
-6. 营养，蛋白纤维碳水。
-
-图 8.5.2 右侧上方的子图说明了这些参数。
-
-有了以上这些指标，在按照星期循环和早中晚饭推荐，可以做到精准推送了。尤其是“营养”因素，还没有任何系统做到，而且用户往往是偏食的，只吃几种口味的菜，对于营养均衡极为不利。尤其是晚上十点钟以后点外卖的，应该提高价格并加以警告，因为对人的作息时间是极为不利的，吃完立刻睡觉，很可能造成食管胃酸回流。
-
-有可能是电商和外卖系统的用户黏度足够好，不愁用户群，所以大家都还没有开发出有 AI 或专家参与的推荐系统来，这会是一个商机吗？

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.6 需求的变更与控制.md

@@ -1,238 +0,0 @@
-## 8.6 需求的变更与控制
-
-### 8.6.1 需求变更的普遍性故事
-
-以下故事从若干真实案例改编而成，图 8.6.1 展示了这一过程。
-
-
-<img src="img/Slide23.SVG"/>
-
-图 8.6.1 - 需求恶行变更
-
-
-
-1. 第一次会晤
-    
-   客户（甲方）心中对要做的软件并没有很细致的预期，所以第一次见面时，客户会说：“我们就做一个管理软件，很简单！” 
-   
-   乙方需求调查人员心想：“原来你们还都没有想好。”
-   
-   双方老总边喝茶边聊合作前景，很高兴。
-   
-   *注：甲方如果软件意识淡漠的话，很难主动提出需求。*
-
-2. 第二次面谈
-   
-   但是当软件公司（乙方）提出更多的疑问后，客户会迫使自己仔细想一想要做什么，第二次会说：“我们要做一个囊括全公司的业务流程管理软件，包括部门 A，部门 B，部门 C。” 
-
-   乙方的需求调研人员驻场两周后，回去加班加点地做需求整理。
-
-   双方老总边喝咖啡边聊行业趣闻，很高兴。
-
-   *注：需求调研的目的，就是帮助甲方提出他们的真实需求。*
-
-3. 第三次谈判
-   
-   在乙方整理出了基本的需求列表后，拿给甲方看。客户数了数功能列表条目的个数：“一共只有50条吗？咱们可是要有 100 万的合同呀！每条就 2 万块钱！太贵了！咱们再加 20 条功能，然后签合同。” 
-   
-   乙方需求调查人员才明白：“原来客户是按功能个数算钱的，早知道我就把它们拆分得细细的！”[捂脸]
-
-   双方老总签了合同，边喝酒边聊国际形势，很高兴。
-   
-   *注：客户不会懂得软件的价值，把功能列表写的细一些总是没有坏处的。*
-
-4. 原型开发结束
-
-   客户在这期间看了一下别家的产品，觉得：“我们也应该有那家软件公司的产品的几个功能，领导很喜欢。没有的话第一期的预付款就成问题了。”
-
-   双方老总握手寒暄了一下，就各自离开了。
-
-   乙方设计人员回去和需求人员讨论到半夜，感觉还是要先攻克几个技术问题，才能继续做设计、开发工作。
-   
-   *注：原型要尽早提交给客户，以免在以后的开发中出现很大的修改。竞争对手的信息调研，乙方要提前帮助甲方完成。*
-
-5. 第一期产品交付
-      
-   客户找了各个部门 10 几个人来一起看，你一句我一句地提意见：
-   
-   - “界面感觉和想象的不一样，我这眼睛不好，这里字体能不能大一些？”
-     
-     *注：软件界面上所有字体都是标准的，牵一发而动全身。*
-
-   - “哟，这个功能 A 都可以用计算机代替呀，那太好啦！我们还有另外两个功能 B 和 C 应该也可以这么做吧？这个咱们补上！”
-
-     *注：用户受到启发了，新需求呈井喷式涌现。*
-
-   - “这里的日期是自动生成的吗？那不行，有时候我们会晚几天才填写资料，但是时间必须是任务分配下来的时间。”
-  
-     *注：不正规的工作习惯导致的需求变化。*
-
-   - “我们这个单据不是给一个领导看的，是要给多个领导审批的，这个要流程必须有。”
-
-     *注：当时只说要给领导审批，没说是几个领导。*
-
-   甲方提出一堆修改意见，忘记了前面的合同条款，开发人员忙着记录，密密麻麻记了两页纸。
-
-   双方老总打电话通了个消息，说公司有事脱不开身，没有见面。
-   
-6. 后期产品维护
-   
-   客户翻了翻合同条款：“哈哈，幸亏我这里写了个三年质保！那个什么，我们有个部门 D 和部门 E，也要纳入到这个系统中。” 
-   
-   双方老总这次干脆就没出现。
-
-   最后乙方公司被拖垮了，入不敷出；给甲方提供的软件在凑合使用了一年后，跟不上数字化转型的大趋势了，不得不换掉，又找了另外一家软件公司合作。
-
-   *注：质保不等于新需求。两败俱伤的做法是双方要尽力避免的。*
-
-### 8.6.2 需求变更在微软
-
-#### 自主产品部门
-
-需求变更在国内的软件公司是司空见惯的，但是在微软，对于需求变更是严格控制的。当然微软主要是做自己的产品，为最终用户服务，而不像小软件公司是为企业客户服务。所以在微软，是不会发生图 8.6.2 所示的情景的，但那却是一般的中小型软件公司，包括国内的大型软件公司的通病。
-
-
-<img src="img/Slide24.SVG"/>
-
-图 8.6.2 - 需求恶性变更带来的灾难
-
-
-
-1. Office 产品
-
-在 Office 团队，以桌面版为例，一般是制定一个为期三年的开发计划，在开始前几个月内，这三年内的所有新特性（Feature）都要确定好，就不许再随便改动了。即使发生以下两种情况也是如此：
-
-- 发现有些特别好的特性没有加入到计划中。这种情况，需要等下一个三年才可以有机会加入。
-- 发现有些特别糟糕的特性已经开始开发了。这种情况，即使那个特性很糟糕，也要维持，下一个三年才有可能去除。
-
-2. Windows 操作系统
-
-在 Windows 团队，以 Windows 10 为例，制定为期半年的开发计划，所有的新功能都是精挑细选。加上计划阶段，实际的开发时间只有三至四个月，后面要留出两至三个月做集成、测试、稳定，表现不好的功能会被去除掉。
-
-通常情况是 10 个 Feature 有可能被去掉了 7 个，只有 3 个 Feature 最终 Release。这期间绝不会有新功能加入的机会。
-
-3. 云端产品
-
-比如 Bing 和 Azure，会自由一些，因为云端发布的特性决定了其实时性，所以有了新的功能可以随时加入。
-
-#### 企业服务部门
-
-木头采访了一位在微软中国 GSMO（Global Sales, Marketing and Operations，销售市场和服务）部门工作的朋友大淘（网名），以下是他们的对话记录。
-
-木头：你们最近还要经常访问客户场吗？
-
-大淘：是呀！项目到了最后阶段了，在赶 DDL（Dead Line，最终期限）。
-
-木头：那我们长话短说吧。我就想知道你遇到过这种情况没有：客户的需求变来变去，最后造成灾难的事情。
-
-大淘：我觉得这在企业服务部门比较容易常见，对于这种甲乙方的关系，签订合同之后，有可能合同里边没有写得特别的明确。有可能甲方在中后期会提出一些要求，就是揪合同里边的字眼。所以要对合同里边的项目条款定得非常的清晰，边缘也要非常的清晰。
-
-木头：你能举一个具体的例子吗？
-
-大淘：项目里边一个最简单的例子，合同里说要做一张表，展现一个条形图。实际的过程中，客户在第一天的时候要一个红色的条形图，第二天可能又会改蓝色的，第三天可能觉得条形图不好，要求会变成饼图。不断的去改，不断去添加。
-
-木头：这么小的功能点在合同里肯定写不全呀？不过这种级别的问题也不会造成灾难，还好。
-
-大淘：造成灾难的情况没有见过，微软的项目经理都会把控这个范围，会允许有小的改动，但是整体上不会变，否则造成客户因为这个事情而不验收。可能有边界不清晰的时候，基本上都不会有灾难。但是其他小的软件厂商没有这种把控的话，可能会造成严重的灾难。
-
-木头：那么你们遇到的最麻烦的事情是什么呢？
-
-大淘：比如原定10月1号要上线，但是我的测试一直都没有通过，用户这边的测试没有通过，那有可能就要拖，拖到客户验收为止，可能到10月30号啊，这是一种情况。另一种情况是你上线了之后，客户不讲理，尾款会拖着付。
-
-木头：原因是什么呢？
-
-大淘：造成这个的原因有几个阶段：最开始售前去卖这个方案的时候，把这个事情说成了一辆宝马车，然后那客户听了感觉很开心，觉得什么都可以实现；后来项目经理介入开始做项目的时候，项目经理会把它说成一辆摩托车，客户觉得能接受，就是开起来风大些，戴个风镜还能接受；最后，开发人员做出来的是辆自行车，这个时候客户就很不满意了，因为这个期望是不断降低的。画个图的话就像图 8.6.3 那样。
-
-
-<img src="img/Slide25.SVG"/>
-
-图 8.6.3 - 预期与交付的差距
-
-
-
-木头：哦！那是因为大家理解不一致吗？
-
-大淘：前期为了投标，一般情况下销售人员肯定会把产品说成像宝马车，然后在项目经理介入的时候，一般可能会把预期稍微低一点，比如他说成了一辆自行车，那最后交付出来发现是一辆摩托车，用户的最后的满意程度可能会提升一些。当然风镜还要免费送，哈哈！
-
-木头：那么如何避免呢？
-
-大淘：整体上我觉得还是不同职位之间的协调，是前面的销售，中间的项目经理，或者说产品经理和开发，再到客户四个方面的协调。再就是时间点和范围要非常的清楚，一般项目前面会陈述范围在哪儿？它包括什么东西不包括什么东西，那它包括到什么程度？这个东西要写的非常清楚，我觉得基本就是这些。
-
-
-### 8.6.3 需求变更控制
-
-
-<img src="img/Slide26.SVG"/>
-
-图 8.6.4 - 需求变更控制
-
-
-#### 基本教育
-
-售前人员要进行基本的客户教育。需求变更的原因是双方造成的，乙方需要对甲方进行一些基本软件知识的教育。
-
-1. 软件知识
-   
-   客户总会说：“如果是硬件也就算了，你们这个不就是代码吗？为什么不能改？”
-   
-2. 开发流程
-
-   甲方对软件开发流程不了解，会有疑问：“上次原型提供得挺快的呀，这次怎么要花这么长时间？”
-   
-3. 知识产权
-   
-   有些模糊知识的甲方会问：“不就是训练一个什么 AI 模型吗？我听说有个 PyTorch 就专门干这个的，而且还不要钱，你们这个怎么花这么长时间，价格还很贵？”
-
-4. 变更过程
-   
-   乙方对甲方的需求没有给与必要的控制管理，任由新需求滋生。乙方需要让甲方明白：需求变更的代价很大。
-
-#### 合同控制
-
-市场部门负责合同控制。
-
-1. 明确细节
-   
-   合同越细，将来的纠纷越少。比如上面提到的一些反例：
-   - 界面颜色、字体大小
-   - 图的形状、颜色、尺寸
-   - 功能点的细节描述，如输入、输出、动作
-   - ......
-
-2. 确定边界
-
-   - Goal/Non-Goal，目标和非目标
-   - 软件维护升级的范围
-   - 与外部系统交互时双方的职责
-   - ......
-
-3. 培训与文档
-   
-   - 如何正确地使用
-   - 如何解决简单故障
-   - 系统架构讲解
-   - 输入输出细则
-   - ......
-
-#### 流程控制
-
-项目经理或者开发经理要进行需求变更流程控制。
-
-【slide 标准、流程、组织、行动】
-1. 建立标准
-      
-   需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（用户参与评审），可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。
-
-2. 制订流程
-
-   制订简单、有效的变更控制流程，在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。
-
-3. 成立小组
-   
-   成立项目变更控制小组，负责裁定接受哪些变更，由项目所涉及的多方人员共同组成，应该包括甲方和乙方的决策人员在内。
-
-4. 严格执行
-   
-   需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。
-
-   何为“相当级别”？即，看看变更是界面级别的，还是模块级别的，或是系统级别的？变更太大的话，还要牵涉到费用问题。

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.6 需求规格说明书.md

@@ -0,0 +1,123 @@
+## 8.6 需求规格说明书
+
+### 8.6.1 需求规格说明书的来源
+
+需求规格说明书（SRS，Software Requirement Specification）。
+
+我们在第七章讲到过需求层次和非功能需求的分析，这些其实就是需求规格说明书的素材来源。用图 8.6.1 的右侧来表示。
+
+
+<img src="img/Slide33.SVG"/>
+
+图 8.6.1 需求规格说明书的来源
+
+
+在微软，通常把需求规格说明书称作Functional Spec（Specification，规格说明书）、Feature Spec。因为这是 PM 需要完成的工作，所以经常叫做 PM Spec。
+
+需求规格说明书是需求分析阶段完成后的输出。如果我们不关心细节的话，那么图 8.6.1 的左侧可以很好地示意。
+
+
+### 8.6.2 需求规格说明书的模板
+
+#### 1. 任务与背景（Task/Background）
+
+在需求规格说明书中，首先要简单讲解一下项目或产品的大概背景。可以分成两种情况：
+
+1）独立的软件，从零开始开发。这种情况可以简单说一下需求背景，比如：
+   
+- *我们发现大部分研究员都是用 Edge 浏览器和 OneNote（微软办公套件中的一个产品）进行阅读和做笔记，非常不方便，所以想开发一款二合一的软件产品，既能够浏览，也能够做笔记。*
+
+2）在已有软件上增加功能。这种情况需要简单描述一下已有软件的大概情况，再说一下新增功能，比如：
+
+- *我们发现大部分研究员都是用 Edge 浏览器和 OneNote 进行阅读和做笔记，非常不方便，所以想在 Edge 浏览器上开发一个扩展插件，来解决做笔记的需要。*
+
+在这一部分中，也可以描述一下条件与约束，如 7.6.4 节所述。
+
+#### 2. 目标与非目标（Goal/Non-Goal）
+
+仍然沿用读论文工具的例子：
+
+- *Goal：解决 PDF 的标记问题。*
+
+- *Non-Goal：不准备支持 Word 文档格式，不支持触摸输入。*
+
+#### 3. 典型用户与场景（Persona/Scenario）
+
+有了典型用户后，就要把该用户“放进”具体的应用场景中。Scenario 的意思，就是要把用户放进一个真实的故事片段中，来检验其可行性。
+
+比如前面所述的木头与神经网络课程的故事，用典型用户木头（老师）和毛毛（学生）作为故事的主角，串连起了两个故事片段，在故事中提及了大量的电教课程细节，都可以使用微软提供的技术方案来解决。
+
+反过来看，就是Surface Hub、Azure、OpenPAI 等设备、服务、软件，都应该提供什么功能，才能满足大学电教课程的需要。设计人员坐在办公室冥想是想不出来的，必须到教学现场观察一下上课的情况，才能够设计出相应的产品，然后再泛化。用故事场景（即Scenario）的形式来描述，就是还原现场的一种有效方法。
+
+#### 4. 用户模型（User Model）
+
+如 7.8 节所述，建立用户模型的步骤如下：
+
+1）确定边界：首先要确定系统的边界，把待建系统看作一个黑盒子，绘出系统上下文图。
+2）寻找用例：每个参与者都会描述自己要做的事情，叫做用例，把参与者和几个用例联系起来建立用例图。有紧密联系的用例可以组织在一起形成子系统，有可能的话，我们尽量把这些子系统也发掘出来，并规划它们的边界。对于复杂的用例，可以进一步细化，定义一些子用例。
+3）描述细节：用例说明可以帮助后续的人员深入理解，避免理解偏差。
+4）寻找数据：使用数据流图把用例联系起来，并进一步发现数据，因为用例一般都会产生数据，并且会有别的用例来处理数据。
+5）描述数据：数据字典可以把第 4 步中的数据整理成表格，便于后续设计开发。
+
+#### 5. 结构模型（Structural Model）
+
+如 7.9 节所述，建立结构模型的步骤如下：
+
+1）发现类和对象：从参与者和待建系统中发现类和对象，定义类和对象的模型。
+2）发现数据：从数据流图和数据字典中，定义数据模型。
+3）细化关系：一共有七种关系，对于后面的设计和实现工作有着重要的指导意义。
+4）子系统结构：就某个子系统（对象和功能的集合）建立起静态结构。
+5）系统结构：子系统结构建立起来后，若干个子系统构成系统。
+
+#### 6. 行为模型（Behaviour Model）
+
+如 7.10 节所述，建立行为模型的步骤如下：
+
+1）发现状态：有些对象具有复杂的内部状态，随着外部事件而变化。
+2）捕捉事件：分析出什么样的事件会造成状态的转换。
+3）细节分析：有一些中间状态在最开始时不容易被发现。比如，我们经常使用的计算机，平时具有“开机”和“关机”两种状态，但实际上它们还具有“开机中”和“关机中”两种状态，甚至还有“死机”状态。
+4）发现动作：对象之间是存在交互动作的，代表着将来要实现的方法调用。
+5）动作描述：描述每个动作的起始对象和作用对象，携带的消息，以及动作的先后顺序。
+
+#### 7. 特性与功能（Feature/Function）
+
+Function 和 Feature 不是同一层意思，如表 8.6.1 所示。
+
+表 8.6.1 特性和功能的比较
+
+||Feature 特性|Function 功能|
+|--|--|--|
+|定义|产品或服务可以完成的任务、目标|可以实现某一功能的工具、方法|
+|组成|产品、服务、任务、流程、计算、系统、应用、文档、组件、机器，等等|窗口、按钮、菜单、列表、图形、声音、视频、卷滚条，等等|
+|举例1|该软件可以完成统计样本方差的任务|点击按钮 A 打开窗口后选择菜单 B 可以计算样本方差|
+|举例2|使用微信可以与其它人通信|点击“发送”按钮可以发送信息|
+
+所以，Spec 既要有功能（Function）列表，又要有特性（Feature）列表。功能列表通常由用户指定，而特性列表则由 PM 在需求分析的基础上给出，要具体到软件界面元素，比如是选择菜单还是点击按钮，出现的是一个数据列表框还是条形图，等等。
+
+#### 8. 环境与质量（Environment/Quality）
+
+一般指运行环境的要求或者限制，以及在这一运行环境下的系统性能指标。比如：
+
+- *本软件要求在 Windows 10 操作系统上运行，可以管理多达 32 个类别和每个类别中最多 1024 篇论文。要求显示屏物理分辨率至少为 1920x1080。*
+
+- *推理子系统的性能要求在20毫秒以下。*
+
+- *网站允许200个用户并发，每个用户的响应时间为50毫秒。*
+
+更多的质量要求，可以参考 7.6.3 节所述。
+
+#### 9. Schedule/Plan 计划和日期
+
+给出项目的几个关键点，如表 8.6.2 所示。
+
+表 8.6.2 计划和日期
+
+|时间|成果|解释|
+|--|--|--|
+|Week 2|Feature Spec|提交需求文档并评审|
+|Week 4|Design Spec|提交设计文档并评审|
+|Week 9|Code Complete|编写代码结束|
+|Week 10|ZBB ( Zero Bug Bounce )|没有新Bug再出现|
+|Week 12|Release|发布|
+
+这里不给出人员安排，因为开发资源要根据需求的多少来决定。计划和日期当然要根据合同的约定来制定，但是切记不要过于乐观，把你的乐观估计的时长再乘以二，基本上就是实际的开发时长。

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.7 非理性需求.md

@@ -1,101 +0,0 @@
-## 8.7 避免非理性需求
-
-非理性需求往往表现在三个方面$^{[7]}$，用公式 8.7.1 来表示：
-
-$$
-非理性需求=\begin{cases}
-关系与利益 \\
-行业与对手 \\
-个人与团队
-\end{cases} \tag{8.7.1}
-$$
-
-
-对于这三方面处理不好的话，就会造成非理性的需求，进而产生非理性的行为。尽管你正确地做事了，但是没有做正确的事。Do right things, rather than do things right。 
-
-
-<img src="img/Slide27.SVG"/>
-
-图 8.7.1 - 非理性需求举例
-
-
-### 8.7.1 关系和利益
-
-#### 与用户的关系利益
-
-**用户提到的需求我都做。**
-  
-甲方的需求是无边无际的，需要管理、引导、限制。
-  
-木头经历过的一个简单例子就是：当 Windows 10 刚刚走向市场时，为了营造良好的生态环境，微软花重金在各个国家寻找合作伙伴，让它们在 Windows 10 上，包括当时还存在的 Windows Phone，做商业软件，比如阿里的淘宝 App。木头是 UWP（Universal Windows Platform）版淘宝 App 的缔造者。
-
-淘宝方要求不仅要做淘宝 App，还要做旺信 App 的 UWP 版本。市场人员为了拿下订单，很爽快地答应了这个要求。但是作为长期在一线战斗的木头看来，旺信 App 根本不会有什么用户的，原因很简单：1. 微信霸占着自由通信市场；2. 淘宝已经内置旺信的部分功能，以便买家与卖家通信。
-
-事实证明木头的观点是正确的，旺信 UWP App 的用户量少的可怜。但更可怜的是我们的开发人员，5个人花了四个多月的时间，非常辛苦。如果用这些资源来丰富淘宝 UWP App 的功能，将会是一个不同的局面。
-
-#### 与老板的关系和利益
-
-**老板说啥就做啥。**
-  
-如果老板代表用户的最终利益，这是成立的，否则你可以站在用户利益的角度来和老板讨论问题。
-
-在微软，老板更多地是一个 People Mananger（管人的），他/她可以分配工作，但是更多地要由 PM 或相关角色来决定做什么。
-
-#### 直接的金钱利益
-
-**这个还在赚钱，我要做。**
-  
-赚钱的东西当然要做，但是也要有一部分力量去研究新产品。如果你有开拓精神和能力，（公司）应该（安排你）去挣明天的钱。
-
-微软在鲍尔默时代，全力投入在 Windows、Office，如果用足球场做比喻的话，这二者处于前锋的位置，冲锋陷阵，是微软财务报表的主要贡献者。但是，大家也看到了微软股票的低迷，从投资者角度看，微软的赚钱手段太少了。
-
-当时，Bing Search（必应搜索）算是一个新生的产品，因为微软看到谷歌在搜索上大赚其钱，眼红了。在沈向洋博士的带领下，必应搜索终于能在美国市场可以与谷歌搜索分庭抗礼了。
-
-到了萨提亚时代，一本《刷新》$^{[8]}$（英文名称为 Refresh）的书阐明了 CEO 的新思想，微软放弃 Windows Phone，大力投入 Azure 云。Mobile First, Cloud First（移动为先，云为先）的战略使得微软有了新的利润增长点，股票价格也是一路飘升。
-
-从组织结构上也可以看出，Windows 的明星光环已经暗淡，在足球场上处于后卫的位置，当然后卫也很重要。但是 Windows Team 内部的一些陈旧的做派实在是不能被木头所认可，但也许那就是 Windows 的产品风格吧？
-
-#### 未来的金钱利益
-
-**别人做这个赚钱，我们也做。**
-  
-前面说到微软是看到谷歌搜索赚钱了，所以才做的必应搜索，整个公司为这个战略投入了几千人的大团队，幸好成功了，否则微软会彻底被互联网抛弃。
-
-但是，虽然同样有 Android 和 iPhone 做样板，Windows Phone 却失败了，原因很多，另文说明。只能说，别人在赚钱的东西，自己再去做不一定赚钱。
-
-### 8.7.2 行业与对手
-
-#### 关于竞争对手
-
-**“全面赶超竞争对手，每个功能都全面提高；我要做到行业最好。”**
-  
-如同需求竞争策略一节中讲到的，要把需求细分，有的努力，有的维持，有的不做，君子有所为有所不为。
-
-#### 关于行业市场
-
-**“这个做的人太多，我不做；这个做的人太少，我不做。”**
-  
-前者通常是对的，避免市场的激烈竞争。后者也通常是对的，避免没有市场。另一方面考虑，做的人多，也许是因为新兴市场需求旺盛。在已经有很多人铺好路的情况下，不妨去分一杯羹。做的人少，也许是行业刚刚兴起，正是占领市场的良好时机。
-
-此时要依靠决策人的智慧。
-
-### 8.7.3 个人与团队
-
-#### 个人主义
-
-**“我觉得爽, 我就做这个功能；这个功能太简单了，我不想做。”**
-  
-个人能力与团队需要吻合时，当然可以勇挑重担，在微软，这通常叫做 align，个人兴趣与团队利益的 align。领导通常会照顾到个人的特长与兴趣，而不是乱分配任务。但是这种文化不代表你可以任性。
-
-木头有一次听到朋友抱怨：有一位老兄，在微软是个 Senior Level，出去后晃了几年，再回来后弄了个 Principal Level 的 Engineer 职位。朋友给他安排了一个工作，过了两周和他检查进度，结果这位老兄说：那个太容易了，我没有做。当时朋友就想骂人。也许这位老兄有一些 Research 的经验，没有兴趣在 Engineer 上。
-
-另外一种常见的情况是，我们会听到一些刚刚走出校门的学生兵说：这个太容易，我不想做。新到一个公司，都要从简单的事情做起，证明自己的能力，获得同事的信任，然后才有资格去挑挑拣拣。
-
-#### 团队惯性
-
-**“我来的时候，大家就做这个产品了；我们已经在这个行业很久了，要坚持。”**
- 
-微软 CEO 萨提亚在《刷新》一书中强调了 Growth Mindset（成长性思维）的重要性：“我们必须以客户为中心。我们的业务核心就是要保持好奇心，以及保持用伟大技术满足客户未能表达的和未被满足的渴望。”
-
-在一个公司或一个行业时间太长，会有一种厌倦，或者是跳不出固有思维模式，成长性思维就是帮助我们保持好奇心和创新精神。微软每年在全球范围的 Hackathon 活动就孕育出了很多好的想法，最终形成新产品或者已有产品中的令人兴奋的新特性。
-

基础教程/A5-现代软件工程（更新中）/第4步 - 用户与需求/第8章 - 需求管理/8.8 软件的定位.md

@@ -1,99 +0,0 @@
-## 8.8 软件的定位
-
-马斯洛需要层次理论（Maslow's Hierarchy of Needs$^{[5]}$）是关于需要结构的理论，传播较广。马斯洛（1968）认为，人的需要由五个等级构成：生理的需要、安全的需要、归属与爱的需要、尊重的需要、自我实现的需要。
-
-在软件上，这个理论可以确定软件的市场需求定位，从而确定使用人群、软件功能、市场运营策略等等。
-
-比如木头在城铁上观察到的大众使用手机应用软件的情况，可以大致对应到不同等级的需求层次上，如图 8.8.1 所示。
-
-
-<img src="img/Slide28.SVG"/>
-
-图 8.8.1 - 软件产品定位
-
-
-### 8.8.1 生理的需要（Physiological Needs）
-
-传统的生理（生存）需要有：食物、水、空气、衣服、睡眠、温暖、居所等。
-
-在物质生活不再匮乏的今天，软件产品提供的网络小说、视频，实际上是为了满足现代人类的精神生活。这种精神生活并不是需求层次的提高，只是生理需求的扩充而已。
-
-- 我已经吃饱了喝足了，我需要快乐；
-- 我不满足于每天两点一线的生活，我想猎奇；
-- 我厌烦我身边的人和事，但又不能摆脱，我想拥有别样的生活。
-
-于是，网络小说和电视剧、短视频，就可以用来满足这些需要，因为它们提供了虚拟的现实、别人的生活、平行的空间，软件使用者（即读者）既可以从上帝视角观察别人的生活，也可以假设自己是主人公来体验别人的生活。
-
-微软的 HoloLens 软硬件产品，以虚拟现实的技术和形式，用视觉带领用户进入一个崭新的世界，从更高的体验层次满足用户的生理需要。
-
-### 8.8.2 安全的需要（Safety Needs）
-
-传统的安全需要，是人们需要稳定、安全的生活环境，受到保护，有秩序，避免焦虑、恐惧等负面情绪产生。
-
-新闻就是新近发生的具有异常性的真事，而微博是自媒体的一种，也可以归结到新闻类别中。人需要包括新闻在内的各种讯息，来完善知识与智力结构，调整行为，适应社会变化，这是一种安全的需要。而出于精神生活需要去看新闻，猎奇、探索、求知欲，实际上属于较低层次的生理需求。
-
-所以，新闻实际上人类被动补充知识的一种手段，以便可以更“安全”地生活和工作。大家都不喜欢看新闻联播了，但是又需要看新闻，所以“今日头条”便推出了个性化新闻服务。$^{[6]}$
-
-基于个性化推荐引擎技术，根据每个用户的兴趣、位置等多个维度进行个性化推荐，推荐内容不仅包括狭义上的新闻，还包括音乐、电影、游戏、购物等资讯。
-
-对每条信息提取几十个到几百个高维特征，并进行降维、相似计算、聚类等计算去除重复信息；对信息进行机器分类、摘要抽取，LDA主题分析、信息质量识别等处理。
-
-根据人的特征、环境特征、文章特征三者的匹配程度进行推荐。实时推荐，0.1秒内计算推荐结果，3秒完成文章提取、挖掘、消重、分类，5秒计算出新用户兴趣分配，10秒内更新用户模型。
-
-根据用户所在城市，自动识别本地新闻，精准推荐给当地居民。可根据用户年龄、性别、职业等特征，自动计算并推荐其感兴趣的资讯。
-
-从本质上来说，上学读书受教育也是一种安全的需要。木头的同事中有很多孩子家长，一般都会在“微信家长群”里，胖超就是其中一个两个孩子的家长，他的两个孩子，第一个是儿子，第二个也是儿子。群里经常会有些家长说“我们家孩子上某某补习班”之类的消息，于是其它家长纷纷效仿。按胖超的话说：“人家孩子都参加了，你不参加的话就觉得不安全。”
-
-### 8.8.3 归属与爱的需要（Belongingness and Love Needs）
-
-传统的归属与爱，就是于其它人建立感情的联系或关系，如团队、朋友、爱情。
-
-Nobody is a island（没有人是一座孤岛），这是玄学派英国诗人约翰$\cdot$多恩的诗，用比喻的方法生动地描述了人类的社会和情感需要。
-
-微软的虚拟人工智能小冰，从具有感情色彩的聊天开始，吸引了无数宅男的目光和时间，对话轮数平均可以到达30轮以上。
-- 2014年5月29日，小冰正式推出第一代产品，以对话式聊天机器人形式迅速积累训练数据。
-- 第二代产品完成了跨平台部署的交互架构。
-- 第三代产品将交互从文本扩充至多模态，进一步积累多模态训练数据。
-- 第四代小冰开始，交互总量稳居全球第一并保持至今，同时发布了全双工语音交互感官。
-- 第五代小冰采用Dual AI战略，大幅度扩展跨平台覆盖的规模，至20余个主流平台，并成为中国市场上涵盖了华为、小米、OPPO、Vivo等智能手机及硬件的唯一的跨平台人工智能。
-- 第六代小冰完成了框架迭代目标。
-- 从第七代开始推出各类框架工具，以帮助创建第三方人工智能产品，并承载其各类交互。
-- 第八代小冰已经创造了118万的虚拟男友。
-
-微信的日活跃用户数已经到达10亿了，朋友圈、群消息、私聊，每天收割着无数人的时间和感情投入。发朋友圈其实就是一种试图获得归属与爱的行为，与大家分享自己的心情和经历，希望获得朋友的点赞。
-
-木头曾经总结过点赞行为的动机，并发布在朋友圈里：
-
-- 点赞是一种义务。
-- 及时点赞是一种美德，好评是一种艺术，差评是一种亲密。
-- 给好图点赞是一种本能，给好文点赞是一种修养，给好友点赞是一种友谊，给好心情点赞是一种理解。
-- 给无聊贴点赞是一种幽默，给普通贴点赞是一种鼓励，给高级贴点赞是一种欣赏，给每个贴都点赞是一种寂寞。
-- 给木头的贴点赞是一种智慧。
-
-此贴获得 100 多赞！
-
-### 8.8.4 尊重的需要（Esteem Needs）
-
-传统的尊重需要，就是自尊和希望受到别人的尊重。
-
-女孩子在淘宝上买衣服，已经不是生理需要了，她们并不缺衣服，她们需要的是穿在自己身上能让别人夸赞的衣服，以此得到满足感。但是自尊到了极限就是虚荣，当有人挎着 LV 的包包每天在上下班高峰狼狈地挤地铁时，我们只能感叹 LV 已经走下神坛了。最关键的是，LV 的包包在设计时都没有拉链，包里面装的东西一览无余，最高兴的是小偷儿。
-
-在软件设计上，商家想方设法展示衣服的美丽（卖家秀），然后又根据大数据（购买行为）推荐各种相关产品。
-
-男人在穿衣打扮这方面一般没有什么追求，却又有展示个人性格与见解的需求。但同时，有些人的创作能力有限，平时在工作生活中窝窝囊囊，但又想获得存在感和尊重：我写不出来大段的文章来，但写一句话的评论总可以吧？于是在微博、微信公众号、论坛上，各种奇葩的评论层出不穷，骂人说脏话的是一种低级的表现，没有脏字但是句句诛心的是一种高级的表现。
-
-以现在的 NLP（Natural Language Processing，自然语言处理）技术来说，智能地屏蔽这些评论并不是什么难事，但是那些软件厂商不愿意投入精力去做，反而会觉得有这些奇葩的评论会吸引更多的人来观看。
-
-### 8.8.5 自我实现的需要（Self-actualizaiton Needs）
-
-自我实现本来就是一种高层次的需求，所以在软件行业只是形式上的不同而已。
-
-别小看打游戏，克服里面的重重困难过关斩将，实际上是一种自我实现的需要，这比看科幻小说电视剧高一个层次，因为用户亲身参与了。这些游戏玩家，为了实现更高层次的自我，还会花钱买装备，所以软件游戏成为了最容易赚钱的行业。
-
-互联网还有一个1:99定律，就是在每100个人里，只有1个人创作，其它的99人只是观众。对应到各种软件中，这一个人就是微博的博主、公众号的博主、网络小说的作者等等。他们的自我实现方式就是创作。
-
-虽然比例悬殊这么大，但是中国人口多，那么创作者就多，所以就会有一个很好的生态环境来支持微博、公众号、网络小说的运营，稍微加点儿广告，就会有很好的收入。
-
-也有在朋友圈实现自我的，比如发自己拍摄的美图和长文、自己做的短诗等等，偶尔也会有自己写歌作曲的，这大大降低了自我实现的门槛，所以朋友圈里色彩缤纷。而观众都是朋友，所以不会有攻击诋毁的评论出现，相对安全。
-
-而抖音和微信短视频的出现，更是激发了公众的“创作”欲望，因为视频比文字、诗歌、音乐等更容易生成，再配上一段平台提供的音乐就会更加有模有样。视频的分类（从难到易）大致有：知识类、才艺类、搞笑类、新闻类、生活类。