敏捷开发模式下的需求管理
本书的重点是讲述一个企业应用在从无到有过程中的需求分析和表达方式，但是产品交付后，我们还要面临现实的客户使用反馈和不断增长的用户需求。尤其是互联网软件产品，从发布之日开始，需求管理的任务不是结束了，而是刚刚开始。本章前面介绍的需求分析和表达方式适用于新产品的从头规划和打造过程，但如果用来管理现有产品的长期迭代就显得效率很低了。因此，我们专门再介绍一下 捷开发模式下的迭代需求管理。
迭代的需求从何而来
大多数企业应用的交付都不是一次性的，有的在立项的时候就已经确定了未来的阶段性计划，第一期先做什么，第二期再做什么，这可以被称为产品路线图。有的虽然没有完整的路线图计划，但也计划在第一期产品交付后根据使用情况和用户反馈再来制订更加明确的二期计划。所以，大体上可以把产品迭代的需求来源归为两个:开发者计划和用户需求。
对于产品型公司来说，来自开发者的既定计划或者权变计划应该是迭代需求的核心来源。主导和管理好迭代需求对于保证产品的清晰定位极其重要。当然，这不是说开发者的计划都是完全在自说自话，它取材于客户和市场的需求及变化，还要经过竞争和资源可行性的检验。
对于企业内部的 IT 系统来说，用户需求是更主要的迭代需求来源。因为内部 IT系统并不需要进行任何市场竞争，满足内部客户的需求就是它的核心目标。其中比较复杂的情况来自外包开发者和客户之间的需求协作。客户的需求要经过自己内部组织的处理，还要经过外包开发团队的处理，信息不可避免地会发生变形，导致开发者难以准确理解客户需求的实质。所有这些复杂情况需要一个有序的迭代需求管理机制来应对。
怎样管理迭代需求
除非是彻底的产品重整，否则一个产品发布之后的需求都属于迭代需求。这时候，我们就不能也不需要按照本章介绍的完整表达模式来沟通产品需求了。迭代需求管理的过程应该围绕计划(Plan)、分类(Classify)、评估(Evaluate)和执行(Do)这四个基本步骤进行。
1)计划
可以根据产品架构或者功能模块建立一个分类体系。形象地说，就是做好几个抽屉，把未来将要发生的迭代需求按照它们的性质进行分类和保管。计划体系还要约定需求从提出到进入需求管理过程的沟通协作模式:是在产品团队外部由专门的分工负责人搜集需求，还是在团队内部指定一位产品助理来做这项工作?
大多数失败的需求管理都是因为前期缺乏计划和约定，当需求滚滚而来的时候陷入了混乱，从而失去了正常的迭代节奏，最终导致失败。
2)分类
有的迭代需求是对可用性的简单改进，有的是实现大型的暂缺特性，还有的会和当前的产品定位有一定的冲突。如果将这些需求不分轻重地罗列出来，直接排到需求分析、设计和开发流程中，肯定是不科学的。这就需要按照一定的标准对迭代性需求进行分类。
需求的分类标准因产品和团队而异，没有统一的标准。但是有一些分类维度是大多数产品团队都应该重点考量的，这些维度如下。
(1)需求关联的模块。例如这个需求是和用户权限有关的，那个需求是和联系人管理有关的，这个分类维度可以方便产品规模较大的团队进行分工协作。
(2)需求的价值定位。一般可以将需求分为消除影响使用的障碍、实现实用的新功能、实现全新的模块和实现增加使用黏性的魅力型特性这四种。不同团队对这些需求的命名方法可能不同。一般而言，刚刚发布的新产品应关注“消除影响使用的障碍”方面的需求，不宜过多关注增加新功能和新模块方面的需求;进入成长期的产品则应该更多地发掘和处理增加魅力型特性的需求。
(3)需求提出者的利益相关度。这是在企业应用市场中不得不考虑的一个要素，无论是单一客户的内部应用，还是面向多客户的应用。某项需求是谁提出的，往往就意味着满足这项需求会给谁带来最大的收益。面向单一客户的产品自然不用说了，如果是面向多客户的产品，会根据核心客户群的吻合度来调整需求的权重。我们一般总是应该尽力聚焦在核心客户群的需求上，这一点在对需求分类时就要考虑在内。
3)评估和执行
无论多么繁杂的迭代需求，经过了有效分类，团队就能够建立理性的评估框架。在当下的总体目标指引下，在手边资源允许的范围内，应该优先满足哪些需求?这就是评估的核心。有人问这个评估过程应该是民主评议，还是由产品负责人集中决策?实际上，决策模式并不是关键点，无论何种决策模式，首先都要对前面说的目标和资源有一致的认识，这就需要产品团队内部建立透明的沟通文化。
如果团队的协作性足够强，我推荐的决策模式是“分散决策”，也就是说，面对分好类的需求池，每一批次的迭代开发(研发领域将其称为一个 Sprint 冲刺，我们在后面会介绍相关的 SCRUM 敏捷开发模式)所包含的需求由对应的模块负责人和协作的工程师自发决定，因为他们更了解每个特性设计和开发所需要花费的时间和面临的难点，而由上至下的决策往往很难克服这些盲点。更重要的是，执行者自我决策的工作内容带有更多的自我承诺，他们能够实现更快的交付速度和更高的质量。
客户需求繁多，产品研发团队应接不暇，这可能是所有产品研发团队面临的最常见的挑战，也是迭代需求管理中最容易导致失败的原因。为了解决好这个问题，除了前面提到的加强内部的透明沟通机制、经常沟通当下的目标和处境，还可以让团队成员建立80/20 原则的共 识(如下图所示)，理解我们的投入/产出比不是一个常量，少数的工作会带来大多数的成果，而其他工作加总也只能带来少数的成果。如果我们能够通过不断试错找到投入/产出比最高的那 20%的工作，那么不论多大的需求池都不会将团队淹没。
这也意味着迭代需求的管理是一个循环过程。每一轮迭代开发的成果检验都应该包括对用户的使用情况和满意度的调研，而不仅仅是完成产品交付。在迭代完成后的一两个月内，产品团队应该搜集这一轮迭代特性的用户使用情况，从而复盘出之前的评估方式和结果是否合理，该怎样改进。迭代次数越多，我们就会越了解用户。
SCRUM 和用户故事
迭代开发的模式大致可以分为两类，一类是传统的基于完整计划的瀑布模式，另一类就是日益盛行的敏捷模式。前者和一个新产品的设计开发过程类似，只是它针对的是一次大型的迭代，而不是全新的产品而已。随着大多数企业应用开始走向云端，应用的测试和部署变得越来越容易，当前敏捷开发模式已经成为企业应用迭代的主流模式。
通常为了打造一个全新的产品，团队会基于瀑布模式工作一段时间。有些大型企业应用的初版开发周期甚至会超过一年。因为长时间无法通过真实的产品与客户互动，这是很考验团队成就感和自信心的过程。在一个基本可用的产品上线并开始提供服务以后，敏捷开发模式就开始发挥作用了。后续的迭代周期会比初版的开发周期短很多，因此团队将能够很快感受到每一轮开发投入所带来的回报。
没有固定的公式可以计算一个敏捷迭代周期的长短，但通常不应该超过一个月(从建立迭代需求列表到交付)。在这一个月内，产品和研发团队将合作完成一个“冲刺”(Sprint)。就笔者所在的明道协作软件的开发实践而言，一个冲刺的周期大约是三周。
在开始一轮迭代之前，我们已经有了日益增长的产品迭代需求，它们应该被分类保管在一起，大多数产品研发团队现在都使用协作软件建立一个看板项目来管理产品需求(Product Backlog)。那么每一轮迭代开发开启前，我们就要从这个产品需求池中选择一部分(希望是那些产生 80%成效的 20%的工作)，列入迭代需求列表(Sprint Backlog)。这个选择的过程就是我们前面提到的迭代需求管理工作中的“评估”过程。
记录在产品需求池中的需求项目能够直接作为迭代开发周期的起点吗?这要根据产品的规模来判断。如果是小型的工具软件，一般可以把明确的特性定义当作一个冲刺的开发内容项目，比如“增加一 个XX报表”“支持重复记录自动合并”等。但比较复杂的大规模企业应用则需要将事无巨细的需求进行合理归并，这个归并成果就是我们前面在讲述需求文档构成时的“用户故事”。一个用户故事通常包含了一个完整的用户场景，该场景功能的实现将允许用户做到以前做不到的事情。比如“团队协作使用活动管理功能”就是一个典型的用户故事，在该用户故事中涉及的需求被满足之前，可能这个产品只能供单用户使用，而需求实现后可以供多用户的团队按照分工权限一起使用。在迭代需求中，每满足一个用户故事中的需求，就能够给一部分用户群带来更明显的使用价值。
所以，敏捷开发的每一个冲刺的起点可能是明确的特性功能，也可能是一个比较完整的用户故事，后者则可以整体地将产品需求池中的一组内容集中实现。这种大小组合的方式也比较符合现实需求，因为每一个产品在发布之后都需要交替实现那些不同价值定位的需求: 解决阻碍使用的缺陷、提供全新的功能和增加用户使用黏性的魅力型特性。
下图显示了利用明道任务管理的一个迭代冲刺所包含的特性和用户故事列表。当然用户也可以利用一个独立的项目来管理一轮冲刺。
在既定的迭代周期内，产品负责人和研发团队会商讨每轮冲刺可以包含的特性和用户故事数量，一开始的时候可能拿捏不准，导致超期或者提前完成，但团队应该能够逐步找到每轮冲刺能够完成的合理的工作量。
初版产品交付后，通常会经过数轮到数十轮的迭代需求开发，产品才能日臻完善。在这个过程中，进一步的功能特性和魅力型特性都能够逐步充实进来，让产品更有竞争力，让内部应用的使用者更加满意。
上文节选自《现代企业应用设计指南》（作者/明道创始人任向晖），点击即可购买
