如何为项目定价和管理范围蔓延
已发表: 2022-03-10我相信您已经阅读过不切实际的文章，这些文章表明存在一些科学的定价方法，可以神奇地让您创建准确的报价。 您可能还被引导相信应该不惜一切代价避免范围蔓延，但在现实世界中，它总是会发生。
现在是我们停止玩这种荒谬游戏的时候了，开始以一种不像赌博的方式来运行项目，而更像是遵循一个稳健可靠的流程。
我夸大其词了吗？ 可能，但让我们看看数字项目经常出错的地方。
我们项目过程的问题
根据我的经验，任何行业的大多数组织都以大致相同的方式运行项目：
- 管理人员要求完成一个项目。 不幸的是，这个请求通常缺乏可交付成果的细节，而且往往只有模糊的目标。
- 一个利益相关者委员会被召集来详细定义项目并决定范围。
- 然后将详细的范围提交给将要构建它的团队，并要求他们估计需要多长时间和成本。
- 项目按规范交付，强调按时交付并在预算范围内。 结果，范围蔓延成为敌人。
- 项目已交付，每个人都继续执行任务列表中的下一个项目。
这种方法远非理想，尤其是对于数字项目。 数字化为我们提供了前所未有的关于用户行为的反馈，并使实施变更相对容易（与实体产品相比）。 然而，一旦确定了范围并提供了报价，项目就会被锁定，随着项目的进展，每个人都不愿意做出改变。
然而，不可避免地，范围最终会发生变化，主要是因为利益相关者对将要构建的内容有不同的解释，或者因为他们在项目中期意识到关键要素是错误的。
事实上，范围蔓延并没有错。 在您了解更多信息时保持灵活性和适应能力是创建出色数字服务的基础。 问题不在于范围蔓延，而在于我们运行项目的方式。
不幸的是，由于已就截止日期和成本达成一致，我们试图在这些限制内交付这些更改，从而导致偷工减料。
并不是说时间表和成本首先是准确的。 数字项目很复杂，通常需要专家和利益相关者一起工作。 因此，众所周知，它们很难准确估计。
我已经阅读了许多文章，这些文章提出了准确估计的方法。 然而，它们在现实世界中几乎在所有情况下都是不切实际的，主要是因为它们太耗时而无法应用。 对项目进行估算取决于直觉、经验和有根据的猜测！
任何曾在该领域工作过的人都会告诉你，大多数估计都是虚构的。 我们通常不知道足够的前期知识，甚至无法确定正确的解决方案是什么或用户可能如何响应它。 因此，不可能预先准确估计整个项目。
不幸的是，当项目不可避免地错过最后期限并超出预算时，这种模糊性通常会导致不公平地分配责任。
幸运的是，有一种方法可以提供准确的估算，并管理涉及更改运行项目的范围蔓延。 秘诀在于将项目分成更小的块。 这种方法避免了承担大型和复杂的项目。
将项目分解为一系列较小的参与
在这一点上我需要清楚。 我并不是说雄心勃勃的工作计划是错误的。 我在大量网站和庞大的工作计划上为大客户工作。 然而，我很少将这些参与视为一个单一的大型项目。 相反，我将它们分解为更易于管理的项目，我一次只限定一个。
当客户找我要进行数字项目（无论大小）时，我通常将其分为四个阶段，按以下顺序发生：
- 发现，
- Α，
- 最小可行产品，
- 持续迭代和优化。
每个阶段都是具有明确可交付成果的单独参与。 因此，我不承诺整个项目，而只承诺第一阶段。 这使得估计和管理范围蔓延变得容易得多。
例如，您只需要定义下一阶段的范围。 这使您可以更好地管理范围蔓延，因为您可以在定义下一个阶段时适应它，一旦前一个阶段完成。
您不是在估算整个工作计划，而是在估算该计划中的下一个项目。 此外，您可以使用前一阶段来帮助您更准确地进行估算。
每个阶段都有助于定义和估计下一个阶段，从发现开始。
1. 发现
在发现阶段，我与利益相关者一起验证项目。 根据项目的整体规模，这可能只是几次会议，也可能是整个工作计划。
通常它包括以下元素：
- 进行用户研究；
- 分析竞争；
- 确定关键绩效指标；
- 定义成功的样子；
- 理解约束；
- 整理利益相关者的意见。
这个想法是，发现阶段将为项目提供更明智的定义，包括用户需求、业务目标以及需要创建的内容。
最重要的是，它将验证项目将交付所需的价值。
然后，我们可以使用此可交付成果来定义和估计 alpha 阶段所需的工作。 这样做可以使我们的估计更加准确，并根据我们所学的内容调整范围。
2.阿尔法
Alpha 阶段是我们定义数字服务（无论是 Web 应用程序还是网站）如何工作并确保用户在使用它时获得积极体验的地方。
这通常是通过创建原型来完成的。 在较小的项目中，这可能只是一些设计模型。 在较大的项目中，它可能是人们可以试用的功能原型。
无论如何，我们的想法是可视化您正在构建的数字服务。
我们这样做有三个原因。
- 首先，可视化将确保所有利益相关者对您正在创建的内容有一个共同的愿景。 一个文档可以用许多不同的方式来解释，但是用原型来做这件事要困难得多。
- 其次，原型将更容易识别任何可能被忽视的东西，因此当解决成本更高时，避免范围进一步蔓延。
- 最后，如果我们有一些有形的东西，我们可以与用户一起测试它，以确保它符合目的，然后再花钱建造真实的东西。
如果测试不佳，我们在下一阶段之前仍有空间进行调整，而不会破坏预算或打乱时间表。
与发现阶段一样，我们可以使用 alpha 来估计下一阶段所需的工作。 对需要构建的内容进行可视化可以使所有相关利益相关者更容易估计所需的工作。 他们可以看到他们被要求建造什么。
此外，我们可以利用从测试 alpha 中吸取的教训来调整我们将要创建的内容，再次为范围的更改创造空间，而不会破坏项目。
一旦我们有了 alpha，我们就可以自信地进入构建，知道我们将创建正确的东西，并且用户会积极响应它。
3. 最小可行产品
我曾经将这个阶段称为“构建”。 但是，我发现利益相关者将完成构建与完成项目联系在一起。 实际上，数字服务永远不会完成，因为它们需要不断迭代以确保它们尽可能有效。
为了避免这个问题，我开始把这个阶段称为最小可行产品（MVP）。 在这个阶段，我们构建并启动了数字服务的初始版本。
通过将其称为最小可行产品，我们强调将有一个发布后的迭代。 这为我们提供了一种处理范围蔓延和意外复杂性的方法，方法是将其推迟到发布后。 这确保了项目保持在轨道上并保持其势头。
在构建过程中不可避免地，我们会将一些东西搁置到发布后。 然后，这些元素成为定义我们最后阶段的基础，使我们能够对发布后的优化做出初步估计。
4. 持续迭代和优化
发布后阶段处理我们在 MVP 中没有解决的功能、复杂性和其他问题。 在这一点上，这个改进列表相对容易确定，并且可以以合理的准确度进行估计。
然而，除了这项工作之外，还应该有一个持续的监控、迭代和测试过程，以进一步完善数字服务的有效性。
根据数字服务的规模和复杂性估算您承担的工作量。 您的估算还应与项目其余部分的投资成正比。
通过将您的项目分解为这四个阶段并分别完成每个阶段，您将消除我们在使用传统项目管理方法时面临的许多挑战。
为什么分解项目有效
以这种方式分解项目有四个显着的好处：
- 每个阶段都有更好的定义。
因为上一阶段的可交付成果定义了每个阶段，这意味着有一个清晰的方向愿景。 这有助于利益相关者了解事情的发展方向，并避免以后出现令人讨厌的意外。 - 项目估算更准确。
例如，您不必猜测交付一个具有大量未知数的重要而模糊的项目需要多长时间，您只需估计下一阶段并根据前一阶段的可交付成果进行估算。 - 它带来更好的数字服务。
由于项目创意已经过用户验证和测试，因此您可以更有信心最终产品符合目的。 它还允许在阶段之间调整范围和功能，以确保您提供可能的最佳结果。 - 这是一种风险较小的方法。
委托数字服务的公司不需要预先承诺整个项目。 如果发现阶段未能验证项目的可行性，则可以将其丢弃，损失很小。 同样，如果 alpha 原型没有在用户中很好地测试，它可以在价格变得太贵之前进行调整。
如果第一次使用外部供应商，最后一点是令人放心的。 与其在不知道他们是否可以交付的情况下为大型项目签约代理，客户可以让他们参与发现阶段，看看他们是什么样的。 如果他们很好，他们可以继续与他们合作。 如果没有，他们可以将调查结果带到另一个机构，而不会丢失任何东西。
如果您经营一家代理机构或者是一名自由职业者，您可能会认为这听起来是个坏主意。 可以理解的是，您更愿意为整个项目注册一个客户。 但是，我通过这种方法避免了许多竞争性投标，因为客户不觉得他们在这么小的初始投资上承担风险。 此外，他们不觉得有必要与不同的供应商交谈，因为如果他们不喜欢我，他们可以很容易地转换。
此外，使用这种分阶段的方法将使您的下一个固定价格项目的范围界定和定价变得更加容易。 当然，它不会神奇地提供估计或防止范围蔓延。 但是，这将使估算更易于管理，因为您一次只确定一个部分的范围。 它还将允许您使用范围蔓延，而不是试图抑制它。
因此，我的建议是，无论您是在内部还是外部工作，在大型或小型站点上工作，都不要试图在不将项目分解为阶段的情况下对项目进行估计和确定范围。 相反，一次解决一个阶段，并用你学到的知识来通知下一个阶段。 如果你这样做了，你的估计会更准确，有根据你所学的内容进行调整的空间，并且会发现项目管理更简单。