很多产品写作仍然默认，最好的经验来自规模、融资和资源充足的团队。

我并不认为这是真的。

我学到的一些最有价值的产品经验，来自那些几乎没有犯错空间的环境：预算紧张、截止日期不断变化、到处都是手工流程，而且一旦顺序出错，后果会很快显现。

我就是在这样的环境里，为尼日利亚的一套大学管理平台工作。

这不是那种“错过一个优先级”只会让季度稍微弱一点，或者让某个功能晚一点交付的产品。如果招生没有及时处理，学生可能会失去名额。如果收费设计不够严密，收入就会从缝隙中流失。如果报表功能后来才补上，管理层只能在信息不完整的情况下做决策。

而当 COVID 打乱线下运营时，真正的考验不是平台是否优雅，而是它能否足够快地扩展，以维持机构运转。

那段经历促成了 CAPE 模型：Crisis-first prioritisation、Architecture as incentive、Parallel data infrastructure 和 Extensibility by design。

这不是一个放之四海而皆准的方法，也不是一个完美公式。CAPE 是一种面向高压团队的实用方法：在正确的顺序上做决策，比拥有完美计划更重要。

C – 危机优先排序

大多数团队都声称会根据价值和投入来排优先级，这在一定程度上有效。但当一个未解决的故障就足以让其他一切都失去意义时，这套逻辑就开始失灵。

招生就是这样的情况。

当时，新生入学大多还是手工处理。学生需要通过纸质表格、零散的核验和工作人员在几乎每个环节的协助，完成招生和注册。有些人路途遥远，许多人还面临很紧的截止日期。如果系统无法承受这种压力，学生就会被挡在外面。所以，入学流程必须先做。

不是因为它是平台里最创新的部分，也不是因为它在路线图上最好看，而是因为它是最容易失效的点。一旦这个流程出问题，平台的其余部分就不重要了。

这就是 CAPE 的第一条原则：不要先从最大的机会开始，而要从如果不立即修复就会造成最大伤害的故障开始。

这听起来很简单。可当你真的身处其中时，它很少显得简单。团队往往会被多个可见需求拉扯，尤其是在利益相关方意见不一致的时候。但在约束之下，把注意力摊开，可能会变成一种伪装过的回避。看起来很平衡，实际上往往会削弱交付。

约束逼出一个更不舒服的问题：如果我们只能先把一件事做好，那最该做的是什么？

这个问题在资源更充足的环境里同样重要。能够诚实回答它的团队，往往能做出更强的首发版本；答不出来的团队，通常会走向更长的路线图和更脆弱的基础。

如果首发版本没有稳定住最高成本的失败点，那它很可能就是错误的首发版本。

A – 将架构作为激励

学校最顽固的问题之一是收费不合规，这也是一个重大的设计缺陷。

我们没有把缴费看作与学术流程并列的行政事项，而是把它做成了结构性依赖。缴费解锁注册，注册解锁考试资格；不缴费，就无法继续推进。

简单，但至关重要。

这个决定改变了平台的逻辑。重点从“提醒用户遵守”转向了“系统逻辑流”。这一区别比许多团队意识到的都更重要。

很多关于行为的产品决策，仍然被当成信息传达问题来处理。但在行为关系到业务核心时，架构通常比劝说更有效。

这就是我所说的“将架构作为激励”。把正确行为直接设计进流程序列里。

一旦把这个依赖关系 встро入平台，收费合规性就显著改善了。但更重要的经验是：如果某个产品依赖于某种行为，架构就应该承担其中一部分责任。

凡是行为重要的地方，先去掉可选性，再加提醒。

P – 并行数据基础设施

许多产品会在这里让管理层失望。工作流能运行，用户也完成了任务，交易也通过了，但机构仍然看不清真实发生了什么。

这正是当时的情况。相关方无法统一看到整个流程。

在交付压力下，很容易先把工作流发出去，把报表放到后面。这样看起来高效，其实不是。它制造的盲点，代价远高于它节省的时间。

所以我们把报表与工作流并行建设。

这改变了决策方式。管理层能更清楚地看到收入状况，能按专业和层级查看注册情况，也能在缴费和入学模式发生变化之前，先看见这些变化的苗头，避免它们演变成运营问题。

这就是 CAPE 的第三条原则：如果一个工作流在运营上重要，它在分析上也应该同时重要。

一个在运行时无法被正确观察的产品，会带来二阶风险。决策开始依赖滞后的假设，而不是当前证据。然后团队又要花几个月去补救本来应该从一开始就设计进去的可见性。

没有监测能力的工作流，在运营上是活的，在战略上却是盲的。

工作流和可见性模型要一起构建，不要让管理层盲驾，还承诺以后再给仪表盘。

E – 按设计实现可扩展性

随着时间推移，我们继续完善平台，逐步把它做成能够处理招生、学费支付、注册、考试和成绩单等大学关键任务的系统。

然后 COVID 来了。

几乎一夜之间，一切都变了。注册、考试、费用及相关流程的问题在那一刻变得次要，因为如果学生没有在学习，这些功能就没有意义了。我们的关注点转向：当线下课堂和运营停止时，平台能否足够快地适应，以维持运转。

平台支持招生、学费支付、考试和成绩单，但没有学习能力。这个缺口成了焦点。问题很直接：从零开始构建学习能力，还是快速集成一个 LMS，以维持大学运转？

学生都在家里，教学停滞，收入下滑。机构需要的不是完美答案，而是最快可行的答案。

我们选择集成，是因为更早的一个架构决策：我们以足够的模块化来构建系统，使其能够吸收新能力，而不必重写一切。不是无限灵活，只是足够开放，让下一步成为可能。

这就是实践中的可扩展性。

它并不意味着为所有可能的未来做准备；那会导致过度工程化。按设计实现可扩展性，指的是为下一个真实变化留出足够空间，而不是每次变化都重建核心。

这一点很重要，因为产品团队常常把可扩展性当成可有可无，直到某一天它变得紧迫。等到那时，成本就高了。

LMS 集成用了四个月交付。学术连续性得以恢复，收入也在同一周期内显著回升。但更大的教训是架构层面的：能够扛住外部冲击的系统，不一定是那些提前预测到冲击的系统，而是那些没有被建得过于僵硬、以至于无法响应变化的系统。

要为下一个真实挑战做准备，而不是为每一种可能场景做准备。

CAPE 的价值不在于它听起来工整，而在于它的顺序成立。

每一个快速增长的产品，都会遇到属于自己的“招生”版本：如果不先解决某个故障点，整个路线图都会被拖垮，而其他事情相较之下都可以商量。每一个收入关键行为驱动的产品，都会遇到属于自己的“缴费闸门”版本：业务依赖的某个东西，要么被写入架构，要么就只能永远靠提醒去追。

每一个团队，都会遇到属于自己的“报表问题”：因为可见性被推迟，管理层只能盲飞，工作流却在不断交付。每一个产品最终也都会遇到自己的 COVID：那个没人预料到的冲击，用来检验你建出来的系统到底是能弯曲，还是会断裂。

这就是 CAPE 能迁移的原因。约束并不真正只是预算问题，而是“必须成立的东西”和“你能承受犯错的程度”之间的比率。这个比率会出现在紧缩融资轮、严苛监管期限、精简的内部工具团队，或者只靠六个月 runway 运行的初创公司中。压力不同，但需要的纪律是一样的。

如果要坦白说，最难真正落实的原则是 Architecture as Incentive。危机优先排序是你在开始时做一次的决定；可扩展性是你可以随着时间写进标准里的习惯。而 Architecture as incentive 要求的是更难的东西：足够坚定地把某种行为变成产品里不可妥协的部分，而不是事后用提示或活动去补救。

这对利益相关方来说是个很难的对话，因为他们通常更愿意“好好提醒用户”，而不是“移除选项”。这也最容易在设计评审里被稀释，因为“我们先加个提醒吧”总显得更舒服。可它往往不是正确选择。

如果你已经在拉各斯、在西非、在一个“我们没有预算用别的方式做”不是口号而是周二日常的市场里，用精简方式构建产品，我不是在告诉你约束是好事。你已经知道这件事。

我想强调的是更窄、也更有用的一点：约束本身不会产生纪律，它产生的是压力。如何使用这种压力是另一个问题；即使在真实约束之下构建产品，也完全可能把顺序做错，因为大多数面向精简团队的建议，并不是为精简团队写的，而是由有缓冲的人，写给有缓冲的人看的。

“先快发，合规以后再补”不是坏建议。它是给那些负担得起“以后成本”的人的建议。如果同样的决定后面没有融资轮等着，那“以后”通常就意味着永远不会，或者意味着一次成本是当初十倍的紧急补救。

本文里每一个被延后的决定——把缴费当成可选、把报表放到后面、跳过模块化所需的可扩展性——都属于这种借来的建议。它们看起来高效，直到没有后续预算来消化延后带来的成本。

CAPE 是我试图有意命名一种我们大多数人在截止日期压力下偶然学到的东西。不是在说约束能塑造品格，而是在发布之前，检查自己是否悄悄借用了一个只适用于别人资产负债表的顺序决策。

即便约束减轻了，这种纪律也值得保留。我们大多数人并不是想摆脱约束，好终于不用再这样思考。如果资金来了，目标也不是丢掉让你走到今天的直觉。

另请阅读：FUTA 表彰由校友转型而来的网络安全创业者，学校举办里程碑式国际计算大会