如何评估一个需求开发通常需要多长时间？

news2024/12/26 23:35:32

业务人员和产品管理者有时候会想要知道在他们即将进行的项目中，“处理需求”的环节会花费多长时间。但这个问题并没有固定的答案，因为这会取决于很多因素。

有许多已经公开的行业平均数据可以提供参考，它可以提示我们在一个典型项目中应该花多大比例的精力去进行需求开发，这包括需求收集（也被称为需求引发）等活动。但是，不同来源的基准数据并不总是能够达成一致，而且这些“典型”的项目是否和你自己的项目类似也是一个未知数。

在这篇文章中，作者会基于他的书籍内容提出一些建议，关于你应该如何确定在需求收集等活动上投入多少适当的时间和精力。

一、行业基准

这里提供了一些行业基准数据的示例，这些数据显示了在几种不同类型的项目中，平均有多少比例的总工作量和时间被用在了需求搜集和原型设计上。这些基准数据来自Capers Jones的“软件评估，基准和最佳实践”，主要针对非常大型的项目，这些项目规模大约是10000个功能点（大约一百万行代码）。读者需要去思考他们自己的项目是否与这些基准数据相似。

但是，使用这种类型的行业基准数据存在一个问题，那就是这些数据并未表示出这些项目有多成功，或者每个项目中“成功”的定义是什么。这些数据也没有指出，比起不那么成功的团队，更成功的团队是否投入了更多的工作在需求搜集活动上——这些数据只是真实情况的平均值。

通常，项目团队可能只在需求收集等活动上花费10%或更少的工作量，但是增加投入会有很大的收益，只要团队不陷入分析过程中无法行动的状态。与许多人的看法相反，投入更多的工作去改进需求开发流程实际上可以加速开发过程。

作者在柯达公司工作时参与的一些小型项目中，他们的团队通常会在需求活动上投入占总工作量的15%-18%。他们发现这种投入减少了项目交付后需要返工的情况。尽管很难确定原因和结果之间的确切联系，但作者认为他们维护需求的水平较低的主要因素是他们培养了广泛的用户参与。

作者无法告诉读者在他们的下一个项目中，他们应该预计花费多长时间在需求收集上。但是，文章中的图表1指出了一些可以加速需求过程的条件，以及一些其他因素，这些因素会增加开发有效需求所需的时间。

图一

二、自身经验

对于初学者来说，最好的办法是收集一些数据，了解你自己的项目工作量有多少花在需求收集上。

这将有助于你评估你过去的需求开发过程的表现如何。在估计未来项目的需求工作量时，你可以参考这些历史数据。你可以使用图1中的考虑因素来调整你的初始估计，以弥补你的下一个项目与基准项目之间的差异。考虑任何可能影响你自己项目的其他因素。你可以将图1中显示的每个因素在0（无影响）到5（重大影响）的范围内进行打分。这种分析可以帮助你找出可能会延长你的需求开发工作的风险因素。

另一个需要考虑的因素是项目所遵循的开发生命周期。并非所有的需求搜集工作都应该在项目的早期阶段完成，就像在顺序或瀑布生命周期模型中那样（参考图2中的虚线）。不要把需求搜集工作想象成一个离散的“需求阶段”，而应该考虑一系列贯穿项目生命周期的需求相关活动。特别是，一旦系统需求规范（SRS）的一组需求基线被确定，并且开始出现变更请求，需求管理就会变成一个持续的操作。

图2

三、迭代和增量方式

一些遵循敏捷开发方法的项目，如Scrum，因为使用了一种增量方法，所以能快速构建产品的小部分。这使得用户能够快速看到可能有用的功能，同时这又能帮助团队更精确地确定他们的需求，同时开发者可以跟上不断变化的商业需求。敏捷项目会有频繁但规模小的需求收集工作（参考图2中的实线）。

与传统项目的需求工作不同，敏捷项目的需求工作贯穿于整个项目周期。初始的需求探索会产生各种优先级的待开发功能。当某个特性或功能被安排到一个特定的迭代中时，团队会将该功能的需求细化到足够让开发和测试有信心进行的水平。

比如，许多年前，我们的软件开发团队在一个成功的项目中就采用了这种增量方法。这个项目每三周向公司的内部用户社区发布有用的功能。每个三周周期的第一部分时间被用于项目计划、开发以及为该周期内的增量收集需求。团队仅为该增量做了足够的需求开发，以便快速实现它，并逐渐向用户提供新功能。用户对这些增量的反馈有助于指导项目的其余部分，以提供最大的价值。

然而，并非所有项目都适合进行如此细粒度的增量交付。例如，当对现有应用进行重新设计时，新系统需要具备一定量的功能，用户才能转向使用它。无论你的团队在每个项目周期中处理多大的增量，他们都需要理解该增量的需求，以避免对设计、代码和测试进行大量的修改和返工。