如何实际地估算软件开发项目？

引言

许多软件开发团队偶尔甚至经常无法按时完成项目或超出项目预算，这已经不是什么秘密了。尽管项目时间表和工时必须在项目开始前进行适当估算是一个众所周知的事实，但开发人员仍然普遍未能遵守他们在开始时设定的限制。那么，问题出在哪里呢？成本是如何随着时间的推移而增加的，项目完成时间又是如何超出最初计划的呢？

以下因素经常发挥作用：

1. 因为新的需求和想法是在后期才添加的
2. 因为没有考虑到需求的某些方面
3. 因为开发过程中出现意想不到的技术困难

为了在规定的截止日期和预算内完成项目，所有需求都必须首先列出、澄清并与客户确认。我们相信，一个成功项目的基础可以而且应该通过首先编写技术规范，然后准备并与客户确认模型，最后创建界面原型来奠定。一旦这些步骤完成，合格的分析师将更有可能准确估算项目工作量，从而更精确地规划截止日期。

尽管这种策略看似常识，但它似乎很少付诸实践。但为什么呢？

以下因素可能发挥作用：

1. 客户希望在就需求达成详细协议之前了解项目的估算成本。
2. 为每个新的 RFP（建议书请求）准备上述所有步骤而不获得补偿可能会相当昂贵。
3. 技术分析师在投入大量精力初步准备提案后，如果面临过多的额外请求，可能会感到沮丧。过多的重复请求可能会让人筋疲力尽，并可能导致技术分析师不再投入百分之百的精力详细分析每个额外请求并提供相应的准确估算。
4. 最常见的问题之一：执行估算的人不知道如何系统地进行项目分析和估算。另一方面，销售经理通常不知道如何准确填写提案的商业部分。这种情况在小公司中尤为常见，其中一个人处理提案的技术和业务方面，但并不一定具备所需的知识和经验。结果，这会降低估算工时和预算的整体准确性。

为了解决这个问题，许多公司会准备一份初步估算，只有当客户表现出认真继续合作的兴趣时，他们才会提供更复杂和深入的分析。

销售经理无法与客户讨论预算的情况并不少见，而且当项目多次变更时，交易最终以快速初步估算后确定的价格成交。这使得开发人员在这些条件下承担完成项目的重担。

对于那些业内人士和每天都需要进行估算的人来说，这些信息都不是新鲜事。然而，对于许多开发团队来说，问题仍然没有解决。

这个问题可以通过基于系统方法处理新项目请求和新客户的稳固工作流程来解决。毋庸置疑，销售经理和技术分析师也应具备必要的知识和经验来与客户合作并进行软件项目估算。系统方法包括流程正规化，将项目划分为各个阶段以及每个阶段内的任务。

我们为改善这种情况想出了什么办法？

几年前，我们已经认识到，大多数错误都是在初步项目估算阶段发生的。很明显，使用 Excel 电子表格或 Google 文档来估算工时，然后将这些信息放入商业提案的模板文件中，太耗时了。不仅如此，它还会导致一些小错误，这些错误经常被员工忽视。此外，还清楚地表明，员工并不总是知道需要按照什么顺序编写什么内容才能准确估算项目并创建商业提案。

认识到这一点后，我们决定开发自己的内部项目估算应用程序，并与商业提案结合使用。我们决定设定强制性规则，要求技术分析师浏览一组特定的页面并填写必填字段。此外，技术分析师还必须将每个项目划分为不同的完成阶段和模块（较大的一组需求），以及任务和较小的子任务。然后，我们选择以表格形式在单独的页面上显示项目估算数据，类似于 Excel 电子表格，并包含利用许多用户熟悉的相同快捷键的选项。

这看起来如下：

• 模块 1
  • 主要任务 1 - 5 小时
    • 子任务 1.1 – 3 小时
    • 子任务 1.2 – 2 小时
  • 主要任务 2 - 9 小时
    • 子任务 2.1 – 1 小时
    • 子任务 2.2 – 3 小时
    • 子任务 2.3 – 5 小时
  • 主要任务 3 - 5 小时
    • 子任务 3.1 – 2 小时
    • 子任务 3.2 – 2 小时
    • 子任务 3.3 – 1 小时
• 模块 2
  • 主要任务 4 - 7 小时
    • 子任务 4.1 – 3 小时
    • 子任务 4.2 – 4 小时
  • 主要任务 5 - 13 小时
    • 子任务 5.1 – 3 小时
    • 子任务 5.2 – 7 小时
    • 子任务 5.3 – 3 小时
  • 主要任务 6 - 6 小时
    • 子任务 6.1 – 1 小时
    • 子任务 6.2 – 1 小时
    • 子任务 6.3 – 4 小时

因此，项目估算包括填写特定字段并系统地将工作范围划分为阶段（里程碑）、模块和子任务。

此外，对于每个“主要任务”，我们不仅计划了编码时间，还计划了自动化测试和手动测试的时间。

根据具体项目，一个模块的工作（例如 Web 应用程序中仪表板的开发）也可以分为不同的阶段。在这种情况下，我们按如下方式分配任务：

• 阶段 1
  • 模块 2
    • 主要任务 4 - 7 小时
    • 子任务 4.1 – 3 小时
    • 子任务 4.2 – 4 小时
    • 主要任务 5 - 13 小时
    • 子任务 5.1 – 3 小时
    • 子任务 5.2 – 7 小时
    • 子任务 5.3 – 3 小时
• 阶段 2
  • 模块 2
    • 主要任务 6 - 6 小时
    • 子任务 6.1 – 1 小时
    • 子任务 6.2 – 1 小时
    • 子任务 6.3 – 4 小时

结果，工时和项目时间表的估算总体上变得更加准确。此外，最初的提案准备阶段引出了许多关于具体细节的非常具体的问题，这反过来使得估算更加精确和准确，因为需要找到这些问题的答案。整个过程也发生了变化，销售经理只需填写几页，其中包括添加预算（基于每小时成本或套餐费率）、付款条件和某些营销数据。

另一个重要的步骤是我们决定划分销售经理和技术分析师的职责。这意味着某些页面只能由技术分析师填写，而其他页面只能由负责销售和项目成本的员工填写。因此，技术分析师只能看到提案的技术部分，而销售经理虽然可以查看数据，但无权修改提案技术部分中的任何内容。

随着时间的推移，我们经常遇到类似的项目，并决定添加模板（根据以前创建的提案生成提案的选项）以及 CRM 模块，该模块将允许存储客户数据并跟踪谈判进度。

如上所述，我们已经显著提高了项目估算过程的准确性。从获取初始需求到项目开始工作的所有步骤都变得更加结构化和正规化。项目估算中的严重错误已被消除。

市面上有几种类似的应用程序（如 www.swproposal.com、www.evenflowpro.com 或 www.proposable.com）可以促进项目分析和估算过程。可以通过搜索“软件项目提案创建”或类似查询找到它们。然而，重要的是要强调，选择一种软件而不是另一种软件本身并不是最终解决方案。更重要的是，项目分析和估算周围的流程必须结构良好且经过深思熟虑。这包括清晰定义所需中间和最终结果的步骤，以及在员工之间划分职责。

正如这篇文章所示，从一开始就正确分析和估算项目可以大大增加您按时、在预算内成功完成项目的机会。