大多数工程组织都专注于交付项目。他们应该专注于里程碑。
管理项目很困难。公司会为了做好这件事而扭曲自己。与其下棋，不如改用跳棋。里程碑是一个更简单的游戏，你会得到更好的结果。
在这篇文章中，我描述了：
- 我建议您采用一种特殊的里程碑。
- 为什么人类很讨厌项目。
- 为什么我们实际上非常擅长里程碑。
- 基于里程碑的交付使一切变得更好的无数种方式。
- 如何切换到基于里程碑的交付。
里程碑应该如何定义？
我使用了一个特殊版本的里程碑，并建议你也这样做。这些里程碑具有以下属性：
- 小。里程碑是一到三周的工作，而不是更多。一个或多个里程碑形成一个项目。
- 高品质。每次完成里程碑时，都要让事情比开始时更好。代码库和用户体验不应降低。一个例外是如果您正在制作一次性原型。这可以保留您随时间交付价值的能力。完成里程碑后，它应该可以以某种方式发布。您可以选择不将其发布给所有客户，但应该以某种定义的方式完成。
- 可以理解。选择传达您正在交付的价值的里程碑名称。公司中的任何非工程师都应该了解里程碑的作用。我喜欢使用“[价值交付]通过[方法]”。这会与工程和其他业务进行交流。例如：“通过实施 ElasticSearch 加快列表页面上的搜索结果”。商界人士了解价值部分。工程团队将从方法部分了解我们正在做什么。
- 有价值的。每一个里程碑都会带来价值。如果您正在处理具有许多里程碑的项目，您应该能够中途停止。即使您没有完成所有里程碑，您也应该已经交付了价值。
对于最后一块，该值可以是
- 客户价值
- 商业价值，或
- 信息。
里程碑的这些属性的首字母缩写词是 SHUV。
为什么要使用里程碑？好吧，让我们先谈谈为什么不使用项目。
人类在项目管理方面很糟糕
项目管理令人着迷。它提供了一种控制非常混乱的过程的错觉。
项目管理似乎很有价值。你确实需要某种结构。您确实希望考虑风险、审查进度并跟踪依赖项。
项目管理的一个更好的替代方法是里程碑管理。你所做的就是“用里程碑取代所有关于项目的谈话”
让我解释一下为什么这个简单的改变是可取的。
- 工程师通常不擅长增量设计
工程师倾向于以整体方式设计和排序工作。经验丰富的工程师知道如何逐步工作。但是工程组织的重心是在水平层上进行设计。
以下是您的工程团队将如何设计典型功能。这假设工作有前端和后端部分。
- 有一个你正在工作的对话或设计文档。设计师提供模型。
- 在专注于前端和后端的工程师之间就 API 的外观达成一致。
- 后端工程师开始处理 API。他们设计数据模型，创建 CRUD 操作，然后在其中添加有趣的业务逻辑。为其启动一个新服务。
- 前端工程师开始构建 UI。他们从模拟中构建它，为每件事创建组件。一页一页地做。模拟后端直到它可用，然后将其连接起来。
- 解决前端和后端之间不可避免的问题。
全栈工程师通常会以相同的水平设计方式构建事物。
这种方法有什么问题？
- 它根本不是增量。
- 所有的价值都在最后交付。
稍后我们将讨论一个更好的方法来做到这一点。
- 设计师也不擅长增量设计
设计人员在增量交付方面也面临着类似的挑战。为了设计好东西，你必须考虑最终状态。因此，设计师将制作代表您正在努力实现的最终状态的工件。
这是必要的。设计师需要做的工作是考虑最终状态。但这进一步使您的交付偏向于整体。这是一个陷阱！
- 产品经理考虑长期的最终目标。
同样，产品经理从最终状态的角度考虑事情。他们拥有想要交付给客户的能力，因此他们可能不会考虑到达那里的途径。所以他们加入了所有偏向于整体交付的人群。
- 有效的项目估算几乎不存在
我们的领域以不可靠的估计而臭名昭著。这太糟糕了，NoEstimates 阵营中的许多人认为你根本不应该估计。
这是有争议的，因为了解构建能力的成本很重要。如果您无法计算成本，那么您就不可能找出最有价值的工作（价值/成本）。
问题是我们渴望不必要的精确度。我们不需要知道确切的估计来确保工程专注于最重要的工作。产生精确估计的成本是浪费的。它甚至不会产生您正在寻找的结果。您无需假装该功能将在 6 月 20 日完成。无论如何，这个日期肯定是不正确的。
里程碑降低了将高级估计放在一起的复杂性。它们提供了一个速记，对于大多数决策来说已经足够好了，而且没有严格估计的开销。
有时，我看到人们在严格的估计上取得成功。但它很少是系统性的——通常是一个人擅长它。它依赖于他们。如果他们去度假一周，没有人能够喂养他们的模型，然后它就会崩溃。虽然这是一项很棒的技能，但对我来说，这是证明规则的例外。可以这样想：如果二十分之一的人可以在高度复杂的情况下进行估计，那么在不太复杂的情况下有多少人会更成功？
- 项目往往对人不利
项目交付感觉就像是一个艰难的过程。通常你会为一个可能不切实际的目标工作数月。或者目标可能一直在变化。你工作了几个月来交付一些东西，却发现它没有达到目标。
这些是疾病的症状：项目是其背后的邪恶。
人类实际上非常擅长里程碑管理
项目和里程碑之间的区别就像玩杂耍三个球和六个球之间的区别。处理六个球需要更多数量级的技巧。大多数人可以在二十四小时内学会玩弄三个球。学会玩弄六个球可能需要数年或数十年的时间。
项目管理是一项比里程碑管理更难的技能。为什么不玩最简单的游戏，尤其是当结果可以好得多的时候。让我们列举所有这些方法。
- 估计一到三周的工作很容易
一到三周足够短，人们可以推理范围。他们可以估计所涉及的工作量并且相当准确。一家公司发现他们的团队大约 97% 能够达到他们对这种规模项目的估计。
设定目标的最佳时间是一周到三周。人类在这种规模的工作中做得更好。他们对具有这种复杂性的工作的估计要准确得多。
- 将项目分解为里程碑可让您塑造项目
当人们分解一个项目时，他们通常会将其分解为技术任务。一些更有经验的团队可能会将其分解为用户故事。
如果您首先将项目分解为里程碑列表，您将获得更大的价值。项目是一个或多个里程碑的列表。您的项目高级计划是要交付的里程碑的有序列表。
这更有价值，因为人类可以比技术任务列表更好地推理里程碑列表。列表更流畅。与此相反的是一系列技术任务。他们将巩固您的方法，并使改变计划的工作量很大。
用户故事虽然比技术任务好得多，但也更难推理，因为你可能有很多。
里程碑位于您可以与它们一起玩的合适高度。
您可以通过多种方式交付能力。产品交付中最未开发的方面之一是处理分解工作的顺序和方式。时间最有价值的用途之一是考虑多种方法来构建项目。
我喜欢让团队想出三种不同的方法来对项目进行排序。我让他们讨论权衡并选择最好的一个。
要考虑的权衡包括：
- 客户什么时候会接触到你的作品？向前移动它可以更早地提供信息。您将在成功项目中看到的一般模式是早期的客户反馈，然后随着时间的推移增加与客户的联系。
- 你会学到什么信息，什么时候？您可能会尽早完成风险更高的里程碑，以探索您不太自信的领域。或者你可能会做一个里程碑，明确地在早期测试一些假设。
- 什么时候可以完全整合？经验丰富的工程师将从钢螺纹开始，并使其始终保持工作状态。对依赖于稍后合并工作的订单持怀疑态度。
- 你给未来的自己多少选择？使我们能够转向新的优先事项的排序可能非常有价值。如果您能够对项目进行排序，以便在项目结束时价值会随着时间的推移而减少，那么您可以通过不实施可能价值较低的事情来保持项目的精益。随着时间的推移，这也可以减少技术债务。当您只交付一部分时，请确保您早期交付的内容实际上是有价值的。
里程碑鼓励探索性和执行性项目的分离
里程碑有助于将可交付成果分为两类：
- 执行。可以分解的工作，以及
- 探索。有很多未知数且无法分解的工作。
这允许您将购买能力与购买信息分开。
我们使用的里程碑定义的一个好处是每个里程碑都提供价值。有些项目将无法分解为一组完整的里程碑。当对该项目的了解还不够时，就会发生这种情况。那很完美！因为里程碑旨在传递的价值是信息。
提供信息的项目会带来价值。例如，假设您想为客户构建一些东西。新功能依赖于贵公司中没人熟悉的技术。您采用的方法很大程度上取决于技术细节，而这些细节是未知的。
在这种情况下，您可以让团队进行调查。里程碑的可交付成果可以是演示文稿，也可以是原型。团队还应该致力于提供三种不同的方式，他们将排列未来的里程碑以提供能力。
当面临对提供信息的里程碑进行优先排序时，产品经理可以做出理性的选择：这些信息是否值得团队花费几周的时间？
里程碑自然地鼓励垂直、增量设计
当使用里程碑的团队交付功能时，我们将采用的方法与我们之前描述的方法大不相同。
- 您将有一个正在工作的对话或设计文档。也许设计师提供了模型。
- 您将同时考虑完整功能和功能的第一个里程碑。如果该功能足够复杂，那么您就有了整个事物的技术设计。如果您可以逐步完成，那么您只需设计下一个里程碑。
- 设计师有一个最终状态的设计，但也必须为里程碑做一个设计。
- 您将专注于第一个里程碑，它具有一个狭义定义的功能子集，您可以构建这些功能并提供价值。
- 前端和后端工程师共同构建里程碑。
- 后端工程师可能不会构建完整的 API。他们构建了里程碑所需的东西。他们设计数据模型，创建 CRUD 操作，然后在其中添加有趣的业务逻辑。为其启动一个新服务。但他们遗漏了目前不需要的部分。
- 前端工程师开始构建 UI。他们工作的模拟比最终状态更苗条，所以他们构建了一个更苗条的特性。他们为每件事创建组件。如果他们没有完成，他们可能会在几天内模拟对后端 API 的调用，但是当他们完成时，他们应该能够快速提供反馈并与后端工程师进行迭代。
- 他们一路演示他们的工作，在里程碑结束时，他们可以一起演示一组完整的工作。
正如您所注意到的，这并没有什么不同，只是前端和后端工程师更紧密地合作，共同交付里程碑。他们更加同步。
尽管这样做的好处似乎很微妙，但它们很重要。渐进式设计的结果是在每个里程碑之后都能产生价值。您不是每三到六个月就交付大量不可靠的价值，而是每隔一到三周交付一次价值，并在未达标时学习和调整。您必须投资于学习和适应以利用增量设计，但回报是巨大的。
如何分解项目里程碑
当您处理里程碑时，仅分解当前里程碑。使用用户故事而不是技术任务。垂直切片可以是分形的，也可以在里程碑内向下延伸。您可能会发现可以删除、推迟或更改的用户故事。
例如，假设我们从我们的第一个里程碑开始：“为我们自己的团队创建一个硬编码的 Slack 机器人，用折线图显示有用的指标。”
有很多方法可以做到这一点，但让我们列出一些潜在的用户故事：
- “当团队成员输入 /happybot test 时，他们可以在 Slack 的my-team 房间中看到显示的‘hello world’消息”
- “团队成员在输入 /happybot test 时，可以在 Slack 的 my-team 房间中看到当前显示的幸福度分数”
- “当团队成员输入 /happybot line 时，他们可以在 Slack 的 my-team 房间中看到一个折线图”
如果有帮助或必要，这些中的每一个都可以分解为技术任务。
具有里程碑的优先级就足够了
在确定优先级时，您将大致了解基于里程碑数量的功能成本（对于执行项目）。您可能不需要像您认为的那样对功能进行优先排序的准确性。
但是关于里程碑的一件好事是，您可以通过优先级来发挥创意。例如，您可能会查看一个项目，并决定您可以完成前半部分里程碑，并交付该项目的大部分价值。这种规划中的流动性是我们在产品开发过程中所缺少的主要因素之一。
正如产品开发流程原理（我最喜欢的产品开发书籍之一）的作者 Donald Reinertsen所说：
当团队始终提供价值时，他们就会蓬勃发展
每隔几周就为企业创造价值的团队感觉很棒。他们有源源不断的成就。当你为世界创造价值时，工作就会变得有意义。人们会发展出一种动力感和自信感，这有助于将团队凝聚在一起并培养相互批评和改进的能力。
里程碑是敏捷的，从某种意义上说，变化是自然的
有了里程碑，你每隔一到三周就会有一个自然停留的地方。这意味着团队可以改变他们的优先事项，这样做不会让人觉得很痛苦。而且因为交付了一些价值，所以不会觉得您的工作被浪费了。对于项目，优先级更改感觉就像放弃工作一样，并且可能令人沮丧。有了里程碑，你通常可以完成你正在做的事情。
在某些情况下，您会想要停止里程碑：如果某些事情真的很紧急。但如果你这样做，你就会有意识地选择承担放弃工作的成本。而且它不太可能发生，因为里程碑的结束更有可能临近。