1.一切源于欲望

　　1.1 欲望?需求!

　　欲望!何为欲望?心理学上对欲望的解释是由人的本性产生的想达到某种目的的要求。在这个定义里有两个关键词：本性、目的。它指出了欲望的源头，是由人的本性产生的，是一种本能，人人皆有。同时也指出了欲望的产生原因，是为了达到某种目的。

　　举个例子，吃饭，这是一项最基本的生理欲望，每个人为了生存必须要吃饭。要吃饭，就得先把饭做出来。我们有微波炉，电饭锅等等很多可选择的工具来帮我们做饭，甚至，做特殊的食物有专用的工具提供给我们，比如面包机。再者，如果你不想做饭，连出门都懒得出，你可以用一款叫“饿了么”的软件将食物快递上门。

　　前面提到的微波炉，电饭锅，面包机以及“饿了么”软件，都是我们可以用来满足吃饭这项生理欲望的工具。换个角度，这些工具不就是工具生产厂家的产品吗?换句话说，产品就是为了满足人们欲望而产生的工具。既然产品是为了解决人们的需求问题，也就是说需求就是人们的欲望。

　　1.2 欲望，如何满足

　　每款产品都有自己要解决的核心的用户需求，也就是说产品都有一个核心的欲望需要去满足。比如，“饿了么”软件就是满足人们叫外卖的欲望。但是，叫外卖的方式有很多种，为什么用户一定要用“饿了么”软件呢?这个时候，就需要对欲望进行深入的分析，已提供更好的服务来满足人们的欲望，这个活动常常被产品人称作需求分析。

　　举个苏杰大大在《人人都是产品经理》中的一个例子：绝迹小朋友想去吃火锅，这是一个欲望。但是绝迹小朋友真的是嘴馋了想去吃火锅吗?可能绝迹只是饿了，但是这四川娃子饿了就只想到吃火锅。如果真的只是饿了，给他俩包子也可以满足绝迹的欲望，还能节省成本，何乐而不为呢。这就是一个典型的需求分析过程，通过需求分析找到了最简单的满足人们欲望的方式。

　　再来谈谈“饿了么”软件，在这个软件出现之前人们也是能叫外卖的，那么这款软件有什么更好的满足人们叫外卖欲望的方面呢。我们先来看看以前叫外卖的痛点。叫外卖有两种方式，如果店铺有官网，可以去官网订餐，但是，这些只限于一些大型连锁餐厅，比如麦当劳。另一种方式就是电话预定，但是前提是你要有店铺电话，一般人肯定不会有附近所有餐厅的电话。“饿了么”软件就解决了这两个痛点，它能搜罗用户周围提供送外卖服务的所有餐厅，并为所有餐厅提供网上订餐服务，同时也免去了获得餐厅电话的需求。通过分析，“饿了么”软件提供了更好的满足需求的服务。

　　2.合适的欲望碰到合适的人

　　2.1 用户角色建模

　　每一款产品都有自己的受众，没有哪款产品是每个人都需要的。为此，我们需要对自己产品的受众进行分析，看看这些用户使用产品的习惯是怎么样的。这样可以更好的提取用户的需求。

　　首先，要找出产品的受众，这个流程一般被称为用户角色建模。用户角色建模首先要通过头脑风暴的方式列出可能的用户角色集合。还以“饿了么”软件为例，一般都是什么样的人会叫外卖呢?劳累一天的上班族，学校的学生，偶尔想改善伙食但不想出门的人，加班的人，不会做饭的人。

　　在收集了用户角色集合以后，我们需要对这些用户角色进行整理，看看角色之间有没有包含或者重合的地方，如果有，则需要考虑是否用角色需要被丢弃。比如上面的用户集合中，不会做饭的人并没有典型的特征，而且，在上班族、学生、加班的人中都可能会有不会做饭的人。则，不会做饭的人完全可以被其他角色所代替，这个用户角色就可以被丢弃了。

　　在整理完毕用户角色后，可以将每个用户角色写在一个卡片上，并在每个卡片上写下这个用户角色的一些特征，这样可以方便的对用户角色进行分析。比如，在上班族卡片上可以写上对菜品质量要求较高，可以熟练使用电脑，可能会经常使用该软件等等。

　　有些时候为了对用户角色更加深入的了解，一般会对重要的用户角色建立角色实例。角色实例是一个贴近生活的用户场景，通过角色实例可以建立起一个真实的人物，让我们对角色有更真切的了解。如果上班族是我们主要的目标用户，我们为上班族建立一个角色实例如下：

　　有业界的大大建议在设计新系统时对一些极端人物建立角色卡。这些极端人物并不是产品的典型用户，但是他们却是真的会使用我们的产品。比如一些花痴小妹妹，叫外卖或许对她们来说并不是必须的，但是她们可能仅仅是为了看某个送外卖的帅哥，而经常定那家餐厅的外卖。我们不需要浪费太多时间在这些极端人物身上，甚至这些人物的需求根本不会被实现，但是花点时间在这些用户身上，或许会产生一些意想不到的灵感。

　　2.2 需求源于角色

　　前面在用户角色建模上浪费了很大精力，其实都是在为这里的需求收集做准备。不同的角色肯定会有不同的需求，这个时候，我们需要将自己代入角色，仔细想想如果自己是这个角色，会有什么样的需求。将所有考虑到的需求都记录下来，为以后的需求整理做准备。

　　比如，作为一名上班族，很晚才回到家，这个时候叫外卖肯定希望外卖会很快的到达。而且上班族一般都习惯刷卡，如果提供刷卡或者网上支付功能会很方便。而“饿了么”软件就为用户提供的外卖到达时间的预估，用户可以方便的选择可以快速到达的外卖。

　　再考虑学生，学生这是个没有收入的群体，所以物美价廉的外卖是他们的首选。学生一般对快递的送达时间会有相对较大的容忍度。学生中对刷卡的需求不是很迫切，他们一般更喜欢现在付款，所以如果有货到付款的服务会很合适。同时，如果可以用学生卡打折，我想会很受学生们的欢迎。

　　3.欲望也有轻重缓急

　　在需求收集和整理完成后和项目开始开发之前，我们需要召开需求评审会来确定每个需求的优先级和开发计划。如果你的团队正在使用 Scrum 敏捷开发，那么你们一定在用用户故事来整理用户需求。用户故事通常使用客户和团队都可以看懂的表达方式来写，每一个用户故事都是产品的一个需求。当然，用户故事还包括需求的商业价值和相关人员。使用用户故事可以方便的与客户沟通，而且不用查看繁琐的需求文档。

　　用户故事一般使用如下格式：为了[商业价值]，作为[角色]，我想要[做某事]。还是使用“饿了么”软件为例，比如上班族想找到送外卖快的餐厅的需求可以表述为：为了让外卖更快的送达，作为上班族，我想要查看每家餐厅的外卖送达预估时间。

　　在用户故事确定以后，我们需要召集开发人员，客户还以一些产品的相关人员来参加需求评审会。在会议上，我们需要对每个需求的商业风险，技术风险，开发耗时和优先级作出评估。

　　首先需要确定的是商业风险，也就是确定哪些是核心需求，哪些是亮点需求。核心需求需要尽早完成，缺失了产品就不完整。而亮点需求有则会给产品加分，没有也不会影响用户的使用。一般来讲，核心需求的商业风险会比较低，因为这些需求都是产品必须的，被砍掉的可能性很低。而亮点需求的商业风险就会高，可能会因为开发时间不足而被砍掉或者被放入下次版本迭代的周期中。

　　下来需要确定技术风险和开发耗时，技术风险代表的是这个需求开发的难易程度。如果这个需求所需要的技术开发团队从来没接触过，需要对这个技术从头开始学习。那么这个需求的技术风险就会很高，因为这个新技术不知道开发团队是否能掌握，多久才能掌握。技术风险的评估对开发耗时的评估有很大影响。开发耗时在 Scrum 开发团队中一般用时间点来计算，一个时间点代表一个理想工作日。在我的团队中，一般使用斐波那契数列来划分时间点的等级。因为我们发现工程师经常在为一个需求的时间点而争论不休。如果为一个需求是 2 个时间点还是 3 个时间点而争论，这是有意义的，因为 3 个时间点比 2 个多了一半的工作量。但是如果在为一个需求是 99 个时间点还是 100 个时间点而争论就是没有意义的，因为这一个时间点的差别对我们的影响很小。为了避免这种无意义的争论，我们使用斐波那契数列来划分时间点，这个时候工程师只需要考虑这个需求的耗时更靠近 89 还是 144 ，而不用为了细小的差别而争论不休。在评估技术风险和开发耗时时，一般都有技术人员和项目经理来确定，其他人员不应该左右技术人员和项目经理的思维。

　　最后则是评估需求的优先级，综合分析以上三个要素，来最后给需求评估优先级。一般情况下核心需求的优先级往往是最高的，不过有时候由于技术风险过大，或者开发耗时过长，有些核心需求的优先级会被降低。在优先级评估完毕后，开发团队会确定第一轮的迭代要完成的需求。如果是使用 Scrum 敏捷开发有一段时间的话，开发团队是知道自己在一个迭代周期能够完成多少时间点的任务的，也就是团队的速率。一些高优先级的需求由于时间点太大而不能放入本次迭代，而使用其他优先级相对较低但时间点小的需求代替的情况也会时常发生。

　　4.让欲望在掌握之中

　　在完成需求评估后，开发团队就会进入开发阶段。在 Scrum 团队中，需要对开发中的需求进行管理。常用的方法是在一块木板或是一面墙上列出正在开发的，开发完成的，正在测试的和完成了的需求。这块木板或强被称为看板。每个人都可以在看板上清晰的看到团队现在的开发状况。我的团队没有使用实体的看板，而是使用 JIRA 这个软件提供的电子看板。

　　在开发过程中，需求的变更是必然会发生的。正常情况下，如果一轮迭代已经开始了，Scrum 团队是不会中途停止的。新的需求必须在下一轮迭代中才能加入，这样可以保证开发的正常秩序。为此，我们在看板最前方新加了一项：待开发。我们会将变更的而且有限级高的需求放在这一列，以保证在下一轮迭代中实现这些需求。

　　大部分公司都会要求写需求文档，这样对所有需求归类，并且可以方便以后的查阅。但是这些需求文档有时候书写的并不是很规范，或是很全面。导致查阅的时候很难找到我们需要的内容而且在需求，有时候甚至是写完后根本无人去理会。而且，在需求变更时需要进行维护，耗费人力，文档在多次修改后导致内容很乱，或是前后需求矛盾的情况时有发生。

　　现在一个新的需求管理方法，需求的实例化，可以解决这些问题。需求的实例化是不再编写和维护需求文档，而是直接使用高质量的测试用例作为需求文档。通过测试用例可以很清楚的看到产品的需求内容，而且，在需求变更时，必然会产生新的测试用例，而不必费力去维护。在清晰的表现需求的同时，减少了维护需求文档的人力。