15.11.1 如何记录需求

现在越来越多的企业重视需求，因为都知道需求是研发的源头，但是很多企业又把需求管理做得很复杂，如定义了很多需求类型，给每个需求评分，最后汇总排序，再经过很多人评审，一次需求梳理下来几个月过去了，影响了效率。还是那句话，必要的控制是需要的，但是应该适度，不要做得太过。

需求要有规范化的记录，尽可能细化，形成需求库和完善的需求来源。重视需求评审，真正接触市场和销售人员要参与需求评审，给出需求意见。

需求管理如图15-8所示。

图15-8 需求管理

案例分析：

儿子：在车里装一个扬声器吧，这样就可以听到低沉的音乐了。（客户需求）

父亲：需要110db的低频声音输出。（性能需求）

系统工程师：将广播的输出在20～500Hz的范围内扩大到115W。（规格定义）

设计工程师：使用××功放和××扬声器。（设计实现）

15.11.2 常见的需求分析风险有哪些

常见的需求分析风险如表15-28所示。

表15-28 常见的需求分析风险

15.11.3 不能正确表达和理解需求

需求沟通过程中，经常出现有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，说不清楚需求。有些用户虽然心里明白想要什么，但却说不清楚需求。例如买鞋子，我们非常了解自己的脚，但用语言很难说清楚脚的大小和形状，通常拿鞋子去试，试穿时感觉到舒服才会买鞋。另外，需求人员也经常不能正确理解客户需求或双方误解需求。

来看看一张经典的图片，如图15-9所示。

需求分析员必须设法弄清楚用户真正的需求，这是需求分析员职业的挑战。需求分析员不是销售人员，他们不可能像销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。

开发方和用户方在开展需求开发之前，双方协商清楚用户方在需求开发过程中的权利与义务，把好话和丑话都说在前头，这样能减少今后的摩擦。如果条件允许，开发方最好为用户举办关于需求开发的培训，这种培训能让用户明白需求的重要性及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。

图15-9 需求沟通不到位

模棱两可是需求规格说明中最可怕的问题之一，模棱两可的需求会使不同的风险承担者产生不同的期望。它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。测试组对需求理解不一致容易导致许多测试用例重新编写并重做测试。模棱两可的需求带来不可避免的后果便是“返工”，重做一些你认为已做好的事情。返工会耗费开发总费用的40%，而70%～85%的重做是由于需求方面的错误所导致的。想象一下，如果你能减少一半的返工会是什么样的情况？处理模棱两可需求的一种方法是组织负责从不同角度审查需求的队伍，在需求开发完成后认真审核，不能只简单浏览一下需求文档。

15.11.4 需求经常变更

案例分析（摘抄自互联网）：

你=客户，对于做2C产品的公司，你=公司大boss

服务员=客户经理+产品经理

大厨=码农

你去饭店，坐下来。“服务员，给我来份宫保鸡丁！”

“好嘞。”

——这叫原始需求

大厨做到一半。

“服务员，菜里不要放肉。”

“不放肉怎么做啊？”

“不放肉就行了，其他按正常程序做不就行了，难吗？”

“好的，你稍等。”

——中途需求变更

厨房：

大厨：“肉都回锅了。”

服务员：“顾客要求的，你把肉挑出来不就行了吗？”

大厨：“行。”

——改动太大，部分重构

餐厅：

“服务员，菜里能给我加点腐竹吗？”

“行，这个应该简单。”

——低估改动成本

厨房：

大厨：“你不知道腐竹得提前泡水？炒到一半才说？跟他说想吃腐竹就多等一会儿。”

服务员：“你怎么不早说？”

大厨：“我怎么知道他要往宫保鸡丁里放腐竹？”然而还是去泡腐竹了。

——新需求引入了新研发成本

餐厅：

“服务员，还是把肉加回去吧。”

“你不是刚说不要肉吗？”

“现在又想要了。”

“……好的，你稍等。”

——某一功能点摇摆不定

厨房：

大厨：“菜都炒过火了，你让我放肉？还好肉我没扔。”

服务员：“顾客提的要求你对我发什么火？”

大厨：“你就不能拒绝他？”

服务员：“人家是顾客。”

——甲方是大爷

餐厅：

“服务员！服务员！”

“来了来了，你好？”

“怎么这么半天啊？”

“稍等，我给你催催。”

——改动开始导致工期延误

厨房：

大厨：“腐竹没泡好，我还得重新放油，他要想吃老的也行，没法保质保量。”

——开发者请求重新排期

餐厅：

服务员：“抱歉，加腐竹得多等一会，你别着急。”

“要等那么久？我现在就要吃，你们能快点吗？”

“……行，你稍等。”

——甲方催活

厨房：

大厨：“中途改需求又想按期交付，逗我玩呢？”

服务员：“那我问问，要不让他们换个菜？”

大厨：“再换我就被折磨死了。”

——开发者开始和中间人PK

餐厅：

“服务员，这样吧，腐竹不要了，换成蒜毫能快点吗？对了，顺便加点番茄酱。”

——因工期过长再次改动需求

厨房：

大厨：“蒜毫也得焯水，你让我怎么往热菜里放番茄酱？”

服务员：“焯水也比等腐竹强吧，番茄酱往里一倒不就行了吗？很难吗？”

大厨：“腐竹我还得接着泡，万一一会儿又想要了呢。”

——频繁改动开始导致大量冗余

餐厅：

“服务员，菜里加茄丁了没有？我去其他饭店吃可都是有茄丁的。”

“好好好，你稍等，你稍等。”

——奇葩需求

厨房：

大厨：“宫保鸡丁里放茄丁？”

服务员：“茄丁抄好了扔里边不就行了吗？”

大厨：“那还能叫菜吗？哪个系的？”

服务员：“顾客要，你就给炒了吧。”

大厨：“你顺道问问他腐竹还要不要，我这盆腐竹还占着地方呢，不要我就扔了。”

——奇葩需求你也得做

餐厅：

“服务员，还要多久能好啊？”

“很快，很快……”

“再给我来杯西瓜汁。”

“……好。”

“我再等10分钟，还不好我就走了，反正还没给钱。”

“很快，很快……”

——黑暗前的最后黎明

10分钟后，

“咦，我上次吃的不是这个味啊？”

从厨房杀出来的大厨：“……”

——最终决战

从这个小故事里可以看到常见的产品开发情况，笔者认为需要改进的地方是需要好的产品经理，替客户和开发控制需求，同时形成需求控制方法。

很多人都在抱怨需求总变化，实际情况下确实很难让客户把一切都固定下来再开始开发产品。需求变更原因一般是随着产品或项目的进展，项目团队对需求的了解越来越深入，初始需求文档可能存在一些错误或不足。也有因为市场发生了变化，初始需求文档跟不上当前的市场需求。

另外，沟通不清楚也是很多需求经常变化的原因。建议从客户中来，到客户中去，与客户相关利益群体的交流，做好收集、整理和理解客户需求的工作。研发人员也应该多到客户中、到生产中去，真正理解客户需求，不能闭门造车。

总结起来需求变更的原因多种多样，经常发生的主要有以下几种：

♢因竞争、成本等因素，工期已经确定且极不合理：

♢用户在需求阶段提不出需求，或用户的需求不明确：

♢项目组对业务不熟悉，或者没有与用户密切结合、需求分析工作不细致；

♢需求沟通不充分；

♢项目组没有很好地实施需求管理。

需求变更本身并不可怕，可怕的是需求变更失去控制，导致项目混乱。需求管理过程中更重要的是保证需求变更的可管理性，拒绝客户的变更要求，要求客户在需求规格说明书上签字。这些做法只能适得其反。制定必要的需求变更管理制度，让用户理解无休止、无控制的变化会造成资源的极大浪费和进度的延误，需求变更被接受的评判标准应该是“是否合理”，而不是“是否易于实现”。拥抱变化的更高一个层次是提前预估变化，制定一个可能的变化清单来记录可能出现的变化。

提出需求变更的动机是好的，希望产品更加符合用户的需求。但对于产品开发团队而言，需求变更通常会对项目的进度、人力资源、经费产生很大的影响。变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，产品开发团队一般需要为此付出较大的代价。如果每次需求变更请求都被采纳，项目也许永远不能按时完成，如图15-10所示。

图15-10 需求过程的恶性循环

如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。如果需求变更带来的坏处大于好处，那么拒绝变更。

需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先建立“游戏规则”，开发方与客户方达成共同的约定，即允许客户变更一次到两次需求。如果客户仍继续提出变更需求，开发方有权拒绝，除非客户愿意补偿开发方的损失。

减少需求变更的方法包括版本化产品开发，事先建立“游戏规则”，安排客户重要人员参与变更控制，量化的数据统计，良好的沟通，构建样板工程，采用合适的开发模型。

15.11.5 如何获得消费者有价值的需求

研发与市场脱节，对市场需求把握不准确。如何找到有价值的需求？如何调研用户需求？

产品经理需要走入到用户的生活中，和他们一起工作、学习、聚会、娱乐，搜集和观察产品体验中细致的差异。把自己当成小白用户，站在用户角度，忘记自己的经验和技术。同时学会提问题：需求是从哪里来的？目标客户是谁？有多少人有这样的需求？这个需求紧迫吗？他们的痛点是什么？场景是什么（用产品之前/之后）？需求满足之后数据和指标上会有什么表现？

15.11.6 需求太多，不知道从哪里下手怎么办

需求收集应该统一归口一个部门，任何人都可以提需求，但是不能直接对任何开发人员提需求。客户和老板不能看到哪里、想到哪里就直接打电话给产品开发人员修改。即便对开发人员提需求，开发人员也应该把需求归口到这个部门，这个部门统一安排调度开发。

需求先记录好，能不能解决，能不能快速解决，看公司现有的开发能力，不能着急。

15.11.7 用户需求不断增加怎么办

在开发中若不断地补充需求，项目就越变越庞大，以致超过其计划及预算范围。计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致，这使得问题更难解决。用户需求的改变和开发者对新需求所做的修改等产品开发中不断延续的变更会使其产品开发进度和过程完全不受控制。

应该建立需求基线，明确核心需求，将一些优先级低的需求作为下一阶段实现的内容，集中精力完成核心用户需求的实现。

15.11.8 用户要求不必要的特性怎么办

有时客户或者公司领导要求一些看上去很有用但缺乏实用价值的功能，为了实现这些功能又要耗费很多时间和成本。

在这种情况下，产品开发团队应当为客户或者公司领导构思方案，并为他们提供一些具有创新意识的思路，明确为什么要开发这些功能，以及这些功能的价值和实现成本和周期，耐心解释提供哪些功能要在成本、周期和技术可行性之间求得平衡，这样使得需求分析过程始终是注重那些能使用户完成业务任务的核心功能。

产品开发团队也应努力使功能简单易用，不要未经客户同意擅自脱离要求，自作主张。