目标设定与成功标准

第 12 章 · 架构师成长

「功能都上了，算做完了吧？」「我们要高性能、高可用。」 「做完」不等于「做好」——若没有可衡量的成功标准，交付物可能不符合预期却无法说清；而「高性能」「高可用」若没有具体指标，既难验收也难排优先级。本章讲如何设定可衡量的目标与验收标准，介绍OKR、SMART与可观测指标，在架构与项目中如何定义「做完」与「做好」，以及如何让非功能需求可测试、避免模糊表述。

一、可衡量的目标与验收标准

目标若不可衡量，就难以判断是否达成、也难以对齐各方预期。验收标准（Acceptance Criteria）是「在什么条件下算通过」的具体描述：可观察、可验证，最好可自动化。例如「用户能在一分钟内完成下单」比「下单要快」更可测；「接口 P99 延迟 < 500ms」比「高性能」更可验收。

习惯把目标写成「谁在什么条件下达成什么结果、如何验证」；验收标准写成「Given … When … Then …」或等价的可执行检查项，便于开发与测试对齐。

二、OKR、SMART 与可观测指标

OKR（Objectives and Key Results）：O 是定性的方向（我们想达成什么），KR 是定量的关键结果（如何衡量达成）。KR 通常 2～5 个、可打分（0～1），用于对齐和复盘，而非直接当绩效考核。

OKR 示例（技术侧）

O：提升订单系统稳定性与可观测性，减少线上故障定位时间。

KR1： 核心接口 P99 延迟从 800ms 降至 500ms 以内。

KR2： 全链路 trace 覆盖核心路径，故障定位平均时间从 2h 降至 30min。

KR3： 零 P0 故障因「未知原因」导致（根因均有日志/监控可查）。

O 定方向，KR 定可衡量的结果

SMART 是目标设定的经典原则：Specific（具体）、Measurable（可衡量）、Achievable（可达成）、Relevant（与整体相关）、Time-bound（有时限）。用 SMART 自检目标，能减少「喊口号式」目标。

SMART：具体、可衡量、可达成、相关、有时限

可观测指标：把「做好」落到可采集的数据上。例如延迟（P50/P95/P99）、错误率、QPS、可用性（SLA）、业务转化率等。指标要有定义、采集方式与告警/复盘机制，否则目标仍是空中楼阁。

三、架构与项目中「做完」与「做好」

「做完」常指功能交付（代码上线、需求关闭）；「做好」指满足成功标准、可验收、可观测。两者要一起定义：做完 = 交付物清单 + 验收通过；做好 = 目标/指标达成（含非功能）。若只盯「做完」不盯「做好」，容易交付了却达不到业务或技术预期。

做完（Delivery）

交付物明确、验收标准清晰、通过即关闭。

功能/接口按 AC 验收
文档、配置、上线检查清单

做好（Success）

目标与指标达成、可观测、可持续。

业务/技术目标可衡量
监控与复盘机制在运行

做完 vs 做好：交付 + 验收 vs 目标与指标达成

四、非功能需求的可测试性

性能、可用性、安全、容量等非功能需求若只写「高性能」「高可用」，无法验收。要写成可测试的表述：指标 + 条件 + 方法。例如「在 1000 QPS 下 P99 < 500ms」「单机房故障时 RTO < 5min」「接口需通过 OWASP 基线扫描」。

非功能需求可测试化示例

性能： 列表接口在 500 QPS 下 P99 延迟 < 300ms；压测报告留存。
可用性： 核心服务 SLA 99.9%，按月统计；故障演练 RTO/RPO 达标。
安全： 登录/支付相关接口通过安全扫描无高危；敏感数据加密存储。
容量： 大促前压测通过，容量预留 1.5 倍峰值。

非功能需求要落到可测指标与验收方式

五、避免模糊的「高性能」「高可用」表述

「高性能」「高可用」「体验好」若不拆成具体指标，开发不知道做到什么程度、测试不知道如何验收、上线后也无法判断是否达标。下表对比模糊表述与可验收表述。

类型	模糊表述（难验收）	可验收表述
性能	高性能、要快	核心接口 P99 < 500ms；首屏 < 2s
可用性	高可用、不能挂	SLA 99.9%；RTO < 5min
容量	要能撑住大促	压测 2 倍预期峰值通过；扩容预案就绪
安全	要安全	无高危漏洞；敏感字段加密；审计日志保留 90 天

模糊表述 vs 可验收表述

要点： 每个非功能目标最好对应「指标 + 目标值 + 验收方式」。这样评审时可讨论是否合理、资源是否足够；上线后可用监控与复盘检验是否「做好」。

反例：目标模糊、无验收标准，交付后扯皮。

某项目 PRD 写「系统要高性能、高可用」，没有具体指标。开发按自己理解做了优化，上线后业务说「大促时还是慢」；开发说「已经优化过了」。因为没有约定「多快算快、多少 QPS 下多少延迟」，双方无法对齐。再如：需求写「支持高并发」，验收时只做了功能测试，没有压测；上线后流量一上来就超时。正确做法：需求阶段就定「核心接口 P99 < 500ms、压测 1000 QPS 通过」，开发有目标、测试有用例、上线有监控可复盘。目标可衡量、验收可执行，才能少扯皮、多改进。

小结： 目标要可衡量，验收标准要可观察、可验证。用OKR定方向与关键结果，用SMART自检目标质量，用可观测指标落地「做好」。架构与项目中同时定义「做完」（交付+验收）与「做好」（目标与指标）；非功能需求要写成可测试的指标与条件；避免「高性能」「高可用」等模糊表述，改为具体指标与目标值。

自检： 当前迭代或项目里，每个重要需求有没有 1～2 条可执行的验收标准？非功能需求里有没有写成「指标 + 目标值 + 验收方式」？若没有，挑一条补上，并和测试/业务对齐一次，体会「可衡量」带来的清晰度。

六、小结

目标设定与成功标准决定了「做完」与「做好」能否说清。用可衡量的目标与验收标准、OKR/SMART/可观测指标把方向与结果具体化；在架构与项目中同时定义交付与成功；让非功能需求可测试，并避免模糊表述。下一章讲方案设计与多方案对比：如何生成多个选项并做取舍。