《构建执法》阅读笔记之六

软件需求

人们为了解决现实社会和生活中的各种问题，要求助于软件。人们的需求五花八门，那么软件团队如何才能准确而全面地找到这些需求呢？

需求分析方法一

1.获取和引导需求

软件团队需要找到 软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。
不同的项目需要不同的手段，这一步骤也被叫做“需求捕捉”，形容真正的需求稍纵即逝，需要靠火眼金睛和敏捷的身手来发现并抓住它们。另外，很多时候用户并不知道自己确切的需求，或者不愿意表达完整的需求，软件团队需要设身处地，替用户着想，引导出需求。有些需求在实现之前，并没有用户明确表达具体的需求（例如：没有用户说“我希望有一个偷菜的软件，我可以偷别人家的菜”），但是，成功的团队还是可以从“用户需要和朋友之间玩游戏，用户有证明自己能力的需求”这些角度出发，挖掘出需求。另外，软件团队可以分析技术的发展趋势以及产业的变化、社会发展的大趋势，推测用户会产生哪些新的需求。例如，看到全球定位系统（GPS）技术的成熟、地理信息系统的发展、私家车的普及和智能手机性能的不断提高，我们可以推测出利用手机给汽车导航将是一个普遍的需求
需求还可以来自各种管理机构
例如一些互联网服务对不同年龄用户的内容管理“敏感词屏蔽”、快速删除网上内容，等等
需求不仅来自外界，还可以来自软件企业本身
软件企业＝软件+商业模式。企业所采用的商业模式会对软件提出需求。一个免费的互联网服务到达一定规模后，企业就会考虑如何让这个服务带来收入，例如一个免费的互联网电子邮件服务会考虑对用户收费，支持几种不同等级的用户，在邮件中附带广告，或者在页面显示广告，等等。这些“需求”并不是来自用户，事实上绝大部分用户都反感这样的“需求”，但是企业需要一个能维持它生存和发展的商业模式，尽管这个模式的种种需求未必都是对用户有利的
需求还可以来自技术团队本身
团队在考虑软件的代码、架构、所依赖平台的长期演化的时候，会提出技术性的需求，包括代码的迁移、架构的演化、平台的变化，或者引入新的技术。例如，为了提高将来的开发效率，一个手机软件的开发者决定逐步引入跨平台的语言和框架；一个依赖客户端/服务器（Client/Server）架构的软件需要支持新的HTTPS协议；原来后台的数据服务使用了专用的数据库和专门的小型机，现在改为基于开源技术的软件和硬件；软件前端代码需要支持某种自动测试工具，以便更有效地进行自动测试，等等
有些需求的目的是要更好地了解用户的行为和需求”“
例如，我们要在软件的各个功能点加上收集信息的代码，并在后台实现数据收集、整理、报告和数据挖掘（Data Mining）工作。此类技术在一些公司叫Telemetry—遥测技术

2. 分析和定义需求（Analysis & Specification）

这是指对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化（需求实现的最后期限，实现需求大致所需的时间和资源成本，各个不同需求的优先级，需求带来的收益，等等）

3. 验证需求（Validation）

软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知

4. 在软件产品的生命周期中管理需求（Management）

在软件的生命周期中，需求在发生变化，技术在发展，团队成员的能力也在提高。原来认为重要的事情可能不再重要，有些功能原来技术上很难实现，现在出现了捷径，一些相关的法规会发生变化，外部的合作伙伴突然发生变化，这些都要求我们不断对需求进行重新审核并做出相应的调整

需求分析方法二

1. 对产品功能性的需求
要求产品必须实现某些功能。例如，学校的选课软件只允许有学生身份的用户浏览并选择课程，同时要求学生选择某一门课时必须要满足“先修课”的要求，等等

2. 对产品开发过程的需求
要求软件的开发流程必须满足某些约束条件，例如，开发过程必须产生某种类型的文档，必须在某个时间点达到某个状态，必须对源代码施以某种约束（安全性核查、代码版权核查、代码规范和支持文档的核查）

3. 非功能性需求：这也叫“服务质量需求”（Quality of Service Requirement）
例如，股票交易系统必须在一定时间内返回用户查询结果（它对时间的要求要比“科技文献检索”网站要高），火车票购票系统、大学选课软件必须能支持一定数量的用户同时访问，等等

4. 综合需求
有些需求并不是单单一个软件模块就能满足，例如，“购物网站必须在24小时内把货物发送到用户手中”，这个需求牵涉到软件系统、货物派送系统、送货部门、监控系统等不同部门的功能和执行能力。软件团队和客户代表要在需求阶段把这些问题定义清楚

软件产品的利益相关者

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

用户：或称最终用户（user，end-user）
是直接使用软件系统的人。取决于软件的特点，一个软件也许有多种不同的用户。（例如，一个打车软件的用户有三种：出租车司机、顾客和监管方。）
顾客：或称客户（customer，client）
购买这个软件或者根据合同或规定接收软件的人。这些人不一定是软件的直接用户，但是他们的利益和软件直接相关。例如，给小孩买英语学习软件的家长；决定公司应该使用哪一款远程会议软件的主管（可能是CTO），决定本公司的出租车司机应该用哪一款打车软件的管理人员；代表委托方（甲方）向软件团队提交需求的人员
市场分析师
市场部门要代表“典型用户”的需求
监管机构
在一些行业，软件必须符合许多行业和政策规定（如银行、公共交通、通信、矿产资源等）
软件工程师
工程师也是软件需求阶段的一个重要角色，软件的各种约束、特性会影响到他们工作的效率、开发难度和软件维护的难度。他们应积极参与到软件需求阶段中来

软件开发不可能一次满足所有利益相关者的要求，但是我们一定要让相关角色在这个阶段有机会提出他们的需求和意见，同时，要弄清楚“他们想从软件中得到什么”

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

软件开发的过程，就是“用户最需要的东西”在下面这一链条中传送、转换、实现、扭曲或丢失的过程。

用户最需要的>
　　用户表达出来的>
　　　　软件团队能理解的 + 团队的商业目标>
　　　　　　　软件团队成员具体表达出来的（PM写Spec）>
　　　　　　　　　在各种约束条件下，具体执行表达出来的（Dev写代码）>
　　　　　　　　　　　验证通过的（Test）>
　　　　　　　　　　　　　通过各种渠道告诉目标用户（发布/推广）>
　　　　　　　　　　　　　　　用户终于能用上了，但是他们不满意

软件业界有一个非常著名的秋千图，表达了类似的情形：

下面是几种常用的用户调研方法
１. 焦点小组（Focus Group）

找到一群目标用户的代表，加上项目的利益相关者来讨论用户想要什么，用户对软件的评价等等。焦点小组是很常用的调研方法，它也有一些弱点：

一群人在一起，往往大家会出于讨好其他人的心理来发表意见，避免不一致的意见或冲突。参与讨论的人士表达能力也会有差异，有可能会出现一些善于表达的人士控制讨论议程的倾向
讨论者对于他们不熟悉的事物（例如全新的市场、颠覆式的创新）不能表达有价值的想法—在汽车出现之前，我们找一帮马车夫来畅想“未来的交通工具”，他们未必会贡献很有价值的想法
讨论者容易受到主持人有意或无意的影响
研究者往往从不同意见中挑选最符合自己利益的那些条目，然后对外号称这就是大家的共识

以上这些特点要求会议的组织者要有很强的组织能力，能让不同角色都充分表达意见，并如实地总结这些意见。这种形式也叫做推进会议（Facilitated Meetings）

2. 深入面谈（In-depth Interview）

通过详细的面谈，广泛而深入地了解用户的背景、心理、需求等。这通常是一对一的采访。这种方法费时费力，效果往往取决于主持面谈的团队成员的能力。深入面谈这一方法也可以用在某一特定领域，例如软件的用户可用性和用户界面，这也可以称为软件可用性研究（Usability Study）。

此类研究着重探究用户在使用软件时有哪些困难，并如何改进软件，让软件更好用。常用的方法是请用户来完成一些任务，然后软件项目成员可以在一旁观察，也可以隐蔽在单向玻璃后边，或通过录像观察。这时候让用户使用的软件不一定是自己公司开发的软件，也可以使用别的软件，从而找出此类软件的问题，以及用户潜在的需求

3. 卡片分类（Card Sorting）
通常，团队收集到的需求都是杂乱无章的，不同的角色从不同角度表达了希望软件能做什么，有什么特点，能解决自己的什么痛苦，或者有什么好玩的地方，等等。在收集这类反馈时我们可以利用“卡片分类”的办法，把各种需求做成便于规整的小卡片（也可以写在小贴纸上），然后反复进行下列活动：

讨论 → 明晰定义 → 归类 → 排序

这一方法可以帮助我们更好地统一大家对软件需求的认识，量化各种特性，更好地定义一个软件的信息架构、用户的工作流程、软件菜单结构、网站的浏览路径、各种内容的层次关系等

4. 用户调查问卷（User Survey）
这种方法是指向用户提供事先规定好的问题，让用户回答。我们在大街上碰到过不少。有时候用户在浏览某个网站时，一个弹窗会跳出来，打断用户的思路，不客气地要求用户回答几个问题。用户在回答这类问题时，是否会心不在焉，乱点一气？

用户调查问卷看似容易，其实大有门道，下面是调查者一些常见的错误

问题定义不准确
例如：你用哪一个搜索引擎？对此，用户可能提供多个合理的答案：最近使用的；最喜欢的但是未必最常用的（例如最喜欢的搜索引擎由于某种原因访问不了）。定义不准确的问题会让用户困惑，我们也许能收集到很多答案，但仍然无法准确了解用户的想法
使用含糊不清的形容词、副词描述时间、数量、频率、价格等
例如：最近、有时、经常、偶尔、很少、很多、相当多、很贵、很便宜。这些词语对不同用户和在不同的语境中有不同的意义。
让用户花额外的努力来回答问题
例如：请问你全家平均每人每年下载多少手机应用软件？用户很难在短时间内得出准确的答案。
问题带有引导性的倾向
例如：用户普遍认为，搜索引擎A收录了许多侵犯版权的资料而拒绝承认错误，搜索引擎B则赢得用户信任，你会选择A或B？
问题涉及用户隐私、用户所在公司的商业机密或细节等

用户调查问卷的问题可以有以下这些方式，大家可以根据具体情况使用。

全开放式问题
例如，你对手机上的日程管理软件的期望是：——————————这种问题能让用户畅所欲言，但是整理和量化比较困难
二项选择题
用户只用回答是/否即可。这类问题便于统计处理，分析也比较容易，但用户没有进一步阐明理由的机会，难以反映意见与程度的差别，了解的情况也不够深入。这个类型还有一个变种，就是在两种选择对比中只能选其中之一
多项选择题
大家在平时的考试中经常碰到
顺位选择题
例如，您选择手机背单词软件的主要考虑因素是（按照优先级填写A、B、C……）：
A. 词汇量　　B. 能记录进度　　C. 能定制单词表　　D. 支持与PC同步　　E. 持英语四级等专门词库　　F. 支持发音

5. 用户日志研究（User Diary Study）
这一调研方式要求用户记录自己日常工作或生活中与所用软件相关的行为，供软件团队分析

用户可以写类似日记体的文字描述，也可以每天填表（例如跟踪自己每天的饮食种类），也可以使用软件来跟踪。这是用户调查在时间上的延长，要求用户有很高的自律能力。另外，如何保护用户的隐私也是一个问题

6. 人类学调查（Ethnographic Study）

这种方法听起来学术味很浓，其实可以解释为—和目标用户“同吃同住同劳动”。例如，与其坐在办公室里想象如何给老年人设计手机，不如去和老年人生活几天，从生活中得到体会和需求

7. 眼动跟踪研究（Eye Tracking）
软件团队发布了内容丰富的互联网应用，或者大幅度更新了网站的用户界面，但是很多用户反映软件更难用了，怎么办？大部分的软件都向用户展现了很多信息，也有很多交互，怎样才能让用户容易找到设计人员想让他们看到的信息，找到自己想用的功能？用户浏览网页上的众多内容通常是什么样的规律？一些研究发现了F模式

用户通常浏览通栏标题，然后目光沿着左侧下行，再平行浏览下面的子标题。如果你有重要内容希望用户知道，应该放在什么地方呢？

8. 快速原型调研（Quick Prototype）
等软件做好了再去找用户做调查，未免太费时，并且修改的成本很高。能否快速地取得用户的反馈？这时不妨拿一些纸张模型，让用户去使用，得到反馈。这也是用户参与式设计（Participatory De-sign）的一个例子。另外，模型不一定要用纸，用其他材料，例如小木头块也行—Palm Pilot的创始人杰夫·霍金（Jeff Hawkins）[注释10]就用一块小木板照着设计做了一个实物，把它放在上衣口袋中，时不时拿出来写写画画……最后发布的Palm Pilot及其系列产品开创了PDA这样一个新产业。

9. A/B测试（A/B Testing）
如果你的产品已经有一些用户在用，你想对用户界面做一些改进，但是又不知道到底有多少用户会喜欢新的界面，怎么办？例如，你的网站是两栏的布局，但又很想试一下三栏的布局方式，就像下图

例如，你想用弹窗来促使用户对某个重要信息作出反应，是把弹窗放在右下角呢，还是放在屏幕中央？这时候，你是找新的用户去做一对一的深入调研，还是跑到大街上去发调查问卷？为什么不能让你现有的用户告诉你哪一种设计比较好呢？这时候不妨考虑A/B测试。A/B测试看起来很简单：

决定试验哪两种不同的UI，以及衡量标准、数据收集流程、试验运行时间、人数
在技术上实现A/B测试（通常在5%—10%的用户上运行试验）
收集数据，分析数据，形成结论。

A/B测试当然也有弱点：

运行成本随着时间的推移而变大，增加网站运维的复杂度，对网站数据收集和数据挖掘的能力也是一个考验；
用户的情绪反应你看不到，你只看到交互的行为，但是交互的行为不是用户的全部反馈（例如，如果把网页的广告弹窗定位到屏幕中央，你会看到用户点击屏幕中央的广告更多，但是一定有更多的用户咒骂屏幕中央的广告）
要分清各种因素的关系，例如，网站“改版三列布局”和“用户在网站停留时间”之间存在以下那种关系？
不相关，当前收集到的两者的数据没有任何直接关系
相关，但不是决定因素
因果关系
用网站当前的用户做实验，万一引起巨大的反感，用户就真的流失了

各种方法的分类
各种方法的分类图（下图）表示了这些方法在（态度∶行为、定性∶定量）上的分野：

竞争性需求分析的框架 —— 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都不错，那如何把产品交到千万个用户手中呢？很多同学会说，把它提交到应用商店去啊！但是在中国大陆有多少个手机应用商店？你的应用提交上去之后，会在相应的产品类别中名列第几？有多少人会看到？

功能的定位和优先级

得到了需求之后，软件团队就要考虑用功能来实现这些需求。一个公司可能有多种软件产品和服务，它们各有不同的战略意义。一个软件或服务也由很多功能组成，它们有机地结合起来，才能解决用户的问题，产生效益。如果项目成员突然被问及，你为啥在做这个功能而不是另一个功能？为什么做这个产品而不是别的产品？我们大概会得到一些感性的回答。

老板说啥就做啥
我来的时候，大家就做这个功能了，所以我要做
我觉得这个功能爽，我就做
别的产品通过这个功能赚钱，我们也做

感性地思考问题未必全错，但是一个团队的资源毕竟有限，怎样才能保证我们的投入能得到较大的回报呢？我们可以考虑用下图的四个象限来划分产品功能的特点，以便更好地、理性地了解我们产品的核心价值，从而帮助我们决定应该把资源放在什么地方

要把用户从竞争对手那里吸引过来，团队自己的产品要有一个差异化的焦点，在这个焦点上，我们的团队能做得比别人好10倍，高一个数量级（安迪·葛洛夫把它叫做10X原则[注释18]）。这种功能又叫杀手功能，其他功能也很重要，但是它们都是（相对来说）外围的。产品也许有很多功能，但是应该只有一两个功能是杀手级的。例如我们和许多卖包子的同行竞争，别人有肉包、菜包、小笼包……经过分析，我们决定做蟹黄小笼包，什么是杀手级功能？当然是蟹黄！它虽然量少，却是产品的关键，蟹黄小笼包还有许多其他功能和属性，但是相对而言，他们都是外围的。于是我们有了两种不同类型的功能：

杀手功能（Core）/ 外围功能（Context）

除此之外，我们的竞争对手和用户已经决定了一些此类产品必须要满足的需求，不能满足这些需求，产品就入不了用户和评论员的法眼，当然，还有许多功能是辅助性的。这样，我们又得到另一种划分

必要需求（Mission Critical）/ 辅助需求（Enabling）

这四种划分结合起来，就得到了功能分析的四个象限。我们以一个英汉词典软件为例子来说明。

杀手功能：OCR文字识别技术，可以在屏幕上取词解释，拥有独家权威词典，等等
外围功能：良好的界面设计，在各个平台上都能运行
必要需求：单词短语释义的准确性（如果达不到这一点，用户就不会来使用）
辅助需求：可以做各种皮肤（这也许能让一些用户更喜欢这个软件，但不是决定因素）

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

计划和估计

软件项目计划的一个重要环节就是估计项目各类工作（特别是各种功能）所需的时间

先分清楚几个概念：目标、估计和决心。

目标：表明一个希望达到的状态。例如，软件“五一”之前要投放市场！在建校一百周年之时把我校建成世界一流大学！不论这类目标如何重要，它们未必能够实现
估计：以当前了解的情况和掌握的资源，要花费多少人力物力时间才能实现某事
决心：保证在某个时间之前完成预先规定的功能和质量。例如：我们跑步前进，全民炼钢，两年超英赶美

软件时间的估计，事实上是多个估计值的乘除法（估计的需求，估计的需求复杂度，估计的技术难度，估计的人员能力）

软件工程师在长期的实践中，摸索出一套经验公式：实际时间花费主要取决于两个因素—对某件事的估计时间X，以及他做过类似开发工作的次数N。

Y = X ± X ÷ N //注：Y是实际时间花费。中间的±表明

当N等于1时，一项工作估计的实际花费范围是[0 ..2X]，如果员工一直做类似的项目，他们的N值不断增加，估计变化的范围会越来越小，准确度则越来越高。当然，技术在变，市场在变，员工的心态也在变，员工是不甘于一直做雷同的项目的。如果把这个公式展开一下，项目的复杂程度将由下面两个因素决定：

需求的复杂程度：程序员是第几次实现类似的需求？有些外行看起来很复杂难懂的需求（如银行业务流程），如果一个程序员已经做过多次相关的银行项目，其实不像外人看的那么难
技术的复杂程度：程序员是第几次用这个技术实现？

一个极端的例子：几个程序员用他们从来没用过的技术（例如HTML5，iOS客户端开发）去实现一个他们以前没碰到过的需求（例如银行业务），他们的时间估计一定会很飘忽。

业界的专家也有类似的分析，例如下面这个项目/过程复杂度的二维图

整个软件项目的时间估计也可以从两个方面来看

自底向上。团队成员各自估计底层模块和单个功能（及单元测试）所需的时间，再加上集成及基本测试的时间，就是大概的开发时间。这还没有考虑各个模块之间的相互依赖性
回溯。团队从整个项目最终交付之日往回倒推
如果在“十一”就要交付整个软件，那么9月1日就要完成基本测试。如果9月1日要完成基本测试，那么8月1日就要代码完成（Code Complete）。如果8月1日要代码完成，那么我们要有16周的开发任务，那意味着我们4月1日就要开始，而且4月1号要有第一批设计规格说明书（Spec）

分而治之（Work Breakdown Structure）

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

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

保证所有子节点覆盖了全部父节点包含的内容
保证各个子节点不要相互覆盖
叶子节点要保证足够小，能在一个里程碑中完成。在通常的软件项目中，叶节点的成本最好不要超过两周。如果团队成员从常理出发，认为叶节点不宜再分下去，那就可以停止
从结果（Outcome）出发构建WBS，而不是从团队的活动（Action）出发