构建之法 阅读笔记03

第八章 需求分析

8.1 软件需求

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

②分析和定义需求

③验证需求

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

几种常用的用户调研方法：焦点小组、深入面谈、卡片分类、用户调查问卷、用户日志研究、人类学调查、眼动追踪研究、快速原型调研、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）

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

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

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

第六，服务质量的说明

总结

要学会对用户的需求进行分析，尽可能的满足用户的需求，尽可能地进行创新性的新功能博人眼球，学会典型用户分析，进行用户的范围分析，得出主要的用户类型，面向人进行程序设计，进行项目开发。