敏捷需求管理原则与实践

杨俊

项目需求管理的痛点

需求管理是项目管理的一个痛点，主要表现在以下4个方面。一是在项目早期客户没有明确的需求，只能提出大致的想法，但期望项目团队能够精准地交付成果。二是在项目管理过程中，客户可能不断地提出新需求，越到项目后期变更越频繁。通常情况下，在项目初期，客户等关键相关方并没有积极参与项目，到验收阶段才真正重视起来，导致需求频繁变更，从而造成项目团队前松后紧的工作狀态。三是项目相关方众多，尤其是相关方意见不一致导致需求混乱，让项目团队无所适从。四是项目团队花费大量资源和时间交付最终产品，然而很多产品功能用户使用的频率很低。根据以往对软件产品的调查发现，45%的产品功能用户几乎从未使用过，而用户经常使用的产品功能仅占所有功能的20%左右。这说明在产品研发过程中，客户虽然提出了很多需求，但实际上大部分需求并没有价值，浪费了项目团队的资源和时间。

敏捷需求管理的原则

针对需求管理的痛点，从实践中归纳提炼出敏捷方法，敏捷方法秉持了一个基本原则，即“不是看怎么做，而是看为什么做”。敏捷需求管理的探索与实现路径，如图1所示。

通过理解“为什么”，打开工作思路

通常情况下，面对客户提出的新需求，项目团队为了提升客户满意度，快速响应，第一时间思考“怎么做”并讨论实施方案，安排相关资源快速完成。然而，即使任务顺利完成，可能之前存在的问题仍然没有得到解决。同时，客户的需求是多变的，往往项目团队刚实现一个需求，客户又提出新的需求，如此往复，项目团队疲于应对。这种变更可能会持续到项目验收阶段，也可能让项目无法顺利验收。

敏捷需求管理规避了上述情况的发生，通过理解“为什么”，打开工作思路。当客户提出需求时，项目团队并不是马上思考如何实现，而是研究为什么要实现这样的需求，因为客户给出的需求可能并不是真正的需求，而是解决方案。客户基于自身的理解设计了一套解决方案让项目团队实现，而这个解决方案能否真正解决问题不得而知。

例如，在某控制系统软件项目中，客户提出这样的需求：如果数据传送失败，应该在产品屏幕上显示一条闪烁信息。这可能不是客户的真正需求，真正需求可能是客户希望系统出故障时能够及时提醒维修人员快速响应。了解客户的真正需求后，项目团队的工作思路被打开，产品屏幕提示信息也许不是最有效的解决方案，播放报警声音、紧急情况下的语音通知等做法可能效果更好。

又如，某项目团队需要开发一套地铁售票系统，客户提出该售票系统需要支持触摸屏设备。然而，支持触摸屏设备只是解决方案，客户的真正需求也许是给用户提供方便快捷的购票方式，因为传统的键盘打字方式效率低下。了解客户的真正需求，要想快速购票，有没有更好的办法呢？可以直接设置固定票额的实体按钮，如“2元按钮”“3元按钮”等，用户无须选择起点和终点，直接按下按钮就可以快速购票。同时，实体按钮比触摸屏按钮可操作性强，还能解决触摸屏定位不准的问题。

项目经理需要建立专业能力

通过以上两个例子，项目经理需要从 “做什么”到 “为什么做”，打开工作思路，才能走向更好的“做什么”，以满足客户的需求。完成这个过程对项目经理的核心能力提出了更高的要求。什么是项目经理的核心能力？优秀的项目经理应该具备多种能力，其中沟通能力经常被认为是项目经理的核心能力，因为项目经理的大部分时间都花在沟通上。然而，做好项目沟通必须依托项目经理自身的专业能力，如果自身专业能力不足，对行业和产品理解不深入，和客户沟通时就会信心不足，难以取得客户的信任，今后与客户沟通的难度可想而知。反之，与客户沟通前项目经理做足了功课，充分了解客户的痛点，结合自身的专业知识，能够给出专业的建议，才有可能与客户建立真正的信任关系。因此，项目经理的核心能力是专业能力，而专业能力中知道“为什么做，值不值得做”比知道“怎么做”更重要。如果不值得做，功能再简单也不做；如果值得做，要优先做。这就是敏捷方法面对需求变更的态度。

相关方持续参与是项目成功的关键因素

由图1可知，在了解客户的真正需求、明确有针对性的解决方案之后，项目团队接下来会研究实现方法，即“怎么做”。然而，敏捷方法更加注重人的参与。再好的解决方案、技术手段，离开了人的积极参与和支持，项目也可能最终流产。

在需求探索和实现的过程中，敏捷方法特别关注两类人的参与：一类是客户、高级管理层等项目团队外部重要相关方；另一类是项目内部团队成员。

针对项目团队外部相关方，在项目启动之初就要明确真正的客户。真正的客户有时并不是项目经理经常打交道的客户对接人，而是项目进展到中后期突然出现的重要相关方，他可能否决之前达成的需求共识，导致项目返工，验收困难。

针对项目内部团队成员，他们的参与也是至关重要的：一方面，虽然项目经理了解项目目标和需求，但由于沟通不足，团队成员可能并不了解项目目标和具体要求，他们会按照自己的理解去解读需求，使最终产品达不到预期；另一方面，由于团队成员来自各个职能部门，他们重点关注分配到本职能的工作，缺乏项目全局观，使项目各环节衔接不畅导致项目进度不如预期。

基于以上两点，项目经理要顺利地完成项目需求管理，必须尽早地多关注人，在项目团队外部重要相关方和项目内部团队成员之间统一目标，邀请其共同制订项目计划，这样才能更好地推进项目需求管理工作。

敏捷需求管理实践

敏捷需求管理引入了多种工具和实践，如用户故事、产品待办事项列表、价值优先级排序等。本文主要讨论众多实践背后的逻辑，即“试错、快速试错、低成本快速试错”的工作理念。

需求管理的“线性思维”违背了项目实际

关于“线性思维”可参考预测型需求管理方法的逻辑模型，如图2所示。

由图2可知，模型的纵轴代表与客户互动的程度，分为高与低两类；模型的横轴代表项目周期，假设项目周期分为需求收集、方案设计、产品开发、内部測试和外部验收5个阶段。从传统的项目管理角度看，前期的需求收集阶段和后期的外部验收阶段通常与客户互动程度较高，其他阶段互动程度较低。那么，这个模型是否符合真实的项目环境呢？答案是否定的。因为此模型违背了一个常识，即客户在项目生命周期的早期很难明确自己的需求，随着项目工作推进，获得了更多的信息，看到了产品雏型，甚至进行试用后才能逐渐明确需求。根据这个模型，在项目前期规划一个需求收集阶段，项目团队收集大量需求，在项目后续各阶段围绕前期需求收集开展工作，但前期需求文件中会存在大量的伪需求。这就导致了项目越到后期变更越多、矛盾越突出，想要控制变更越难。因此，有项目经理把这种需求管理模型称为“坑”，其本质就是项目管理的“线性思维”。

敏捷实践推崇“试错”与“快速失败”的理念

敏捷方法建议将项目周期划分为若干个迭代，每个迭代约2～4周，具体时长取决于项目特点，如图3所示。

在每个迭代的早期澄清并确认客户的需求，客户可能会提出很多需求，也可能说不清需求，导致需求非常笼统。不管哪种情况，项目经理首先要和客户一起探讨在接下来的一段时间内的工作重点，以期解决目前最关键的痛点。这个阶段，项目经理不求大而全，要聚焦小而精。项目团队在短时间内产出的部分成果，在迭代结束时邀请客户进行评审，有条件的可通过实际使用给出反馈，以验证迭代假设。初次迭代的产出成果可能并没有解决客户的问题。不过这时项目团队不用担心，因为工作才刚开始，试错成本并不高，船小好调头。不像“线性思维”方式，团队埋头工作了很长时间，才发现方向错了，这是项目最大的风险。“快速失败”降低了项目风险，更为重要的是，客户在迭代结束后看到了部分产品功能，给出的实际使用反馈有可能是真正的需求，而在会议室中凭空谈出来的需求不见得是真正的需求。在接下来的迭代中，根据客户反馈聚焦关键需求，再进行实际使用评审，收集反馈，如此循环往复，真正做到与客户共同探索需求，始终践行“低成本快速试错”的理念。

“线性思维”与“试错思维”孰优孰劣

采用“线性思维”方式管理需求和采用“试错思维”方式管理需求孰优孰劣？这两种管理方式不存在好坏之说，关键要看是否适应项目特点和项目运行环境。如果项目产品比较成熟，需求能够在项目早期得到明确，项目管理过程中不易变更，可采用“线性思维”方式。例如，某些传统建筑类项目，在项目前期可收集到足够详细的需求，产品成型后纠错成本极高，那么项目团队应该在项目早期充分了解项目需求，进行详细的分析和记录，在项目执行过程中严格遵循变更管理流程，确保最终产品符合需求。反之，如果产品创新性高，外部运行环境变化快，则应该采用“试错思维”方式，进行“试错、快速试错、低成本快速试错”，拥抱变更，始终聚焦项目价值。众所周知，当前越来越多的项目处于快速变化的外部环境中，因此，除了IT类行业，敏捷方法也逐渐被更多行业所接受。

结语

从源头看，项目工作起源于需求评估与分析，需求管理的有效性直接影响项目成败。在对各类企业的培训中，我们发现需求管理是众多企业项目管理的痛点。其根本原因在于项目外部环境变化快，固守传统的需求管理模式难以提供真正有价值的项目成果。另外，未经管理的需求变更会演化为盲目的需求蔓延，打乱项目团队正常工作秩序，产出大量的无价值输出。敏捷方法通过询问“为什么”，聚焦客户价值，采用“试错、快速试错、低成本快速试错”的实践方法提供了一整套需求管理的工作思路。知易行难，期待项目管理从业人员共同努力，在实践中进一步完善敏捷需求管理理论和方法，提高项目管理效率，提升项目价值。P