产品策略与探索
探索阶段降低的是做错东西的风险。我们明确用户是谁、问题是什么、能够验证最高风险假设的最小版本是什么，以及用哪个指标来判断它是否奏效。技术可行性和成本在探索阶段就进行评估，而不是等路线图定下来之后。
- 问题与用户定义
- 假设梳理
- 范围界定与版本切分
- 技术可行性验证（Spike）
- 成功指标
- 自研与采购分析
概览
数字产品工程覆盖一款产品的完整路径：构想、产品策略、UX、架构、开发、基础设施、安全、部署、数据分析和持续改进。这些阶段人尽皆知。难点在于，一个阶段做出的决策会约束其他阶段，而在相互独立的团队之间交接工作，会让这种关联丢失。
定价模型隐含着租户模型。承诺即时反馈的 UX 隐含着能够兑现这一承诺的架构。受监管的市场意味着从第一个版本起就要有审计轨迹和数据驻留方案。我们把这些作为同一项工程工作来推进，让产品策略在技术上站得住脚，让架构服务于一款人们真正想用的产品。
这项工作涵盖 SaaS 平台、企业应用、金融科技应用、交易市场平台、移动应用、B2B 与 B2C 平台、API 产品、企业内部系统和工作流平台。每一类的重心各不相同，尽早识别出重心所在，决定了工程投入该用在哪里。
我们构建什么
技术领域
UX 与界面工程
设计 UX 时，我们始终把系统的约束放在眼前：延迟、离线行为、权限、错误状态和无障碍访问。设计系统让 Web 和移动端界面保持一致，也让新页面的构建成本很低。
- 用户流程与原型
- 设计系统与组件库
- 对齐 WCAG 的无障碍设计
- 响应式与移动优先布局
- 空状态、加载状态与错误状态
架构与平台基础
早期的架构决策集中在难以更改的部分：数据模型、身份与授权、租户边界和 API 的形态。我们让结构保持简单，通常是运行在托管数据库之上的模块化单体，并把这些基础做对。
- 领域与数据建模
- 认证与基于角色的访问控制
- 租户隔离
- API 设计与版本管理
- 计费与订阅集成
- 后台任务处理
开发与交付
产品以短周期的增量方式构建，每个增量都会到达一个类生产环境。自动化测试、持续集成和预览环境让每次变更的成本保持在低位，团队因此能够针对用户的实际行为作出响应。
- 主干开发
- 自动化测试套件
- CI 管道与预览环境
- 功能开关
- Web、移动端与 API 客户端
- 代码评审
基础设施、安全与部署
从第一个环境起，基础设施就以代码定义；在还没有多少东西可部署之前，部署就已经自动化。安全工作与所处理数据的敏感程度相称，并内建于管道之中：依赖扫描、密钥管理、加密和审计日志。
- 基础设施即代码
- 托管云服务
- 自动化部署与回滚
- 密钥管理
- 传输加密与静态加密
- 审计日志
- 备份与恢复测试
数据分析与持续改进
没有度量的产品，无法有的放矢地改进。我们为与产品成功指标相对应的事件埋点，把它们与运维遥测数据关联起来，并通过实验和分阶段发布来检验改动。
- 产品事件埋点
- 漏斗与留存分析
- A/B 测试与分阶段发布
- 错误与性能监控
- 反馈回流到路线图
构建 MVP，同时不堵死日后的扩展之路
MVP 的存在是为了快速学习，所以大多数事情都应该推迟。风险在于，把少数几项一旦有了用户和数据就很难逆转的决策也推迟了。偿还成本低的技术债是可以接受的。会阻碍扩展的那种技术债，是需要迁移线上数据或在负载之下重新架构的那一类。
凡是无需触碰现有数据或契约就能补上的东西，都可以推迟：微服务、多区域部署、定制基础设施、复杂的缓存、插件系统、已知热点路径之外的性能调优，以及眼下一条数据库查询就能替代的管理后台工具。使用托管服务和广为人知的成熟技术，并且只构建一个可部署单元。
有五件事绝不能推迟。数据模型，因为每一项功能和每一次迁移都建立在它之上。认证与授权，因为事后补权限意味着要逐一审查每个接口。租户边界，因为给已有数据的 Schema 加上租户标识是一次高风险的迁移。部署自动化，因为手工发布会拖慢之后的每一次变更。可观测性，因为没有它，第一个生产问题就无从诊断。
- 可推迟：服务拆分、多区域、高级缓存、定制基础设施
- 可推迟：不用于验证最高风险假设的功能
- 绝不推迟：经过深思熟虑的数据模型，迁移脚本纳入版本控制
- 绝不推迟：认证、授权与租户隔离
- 绝不推迟：自动化部署、备份、日志、指标与错误追踪
产品类型如何塑造架构
不同品类的产品，工程难点所在的位置不同。SaaS 平台的核心是租户模型、订阅计费和按租户配置。金融科技应用的核心是账本正确性、幂等的交易处理、对账和可审计性。交易市场平台的核心是双边流程、搜索、在交易双方之间托管的款项，以及信任机制。
API 产品把契约本身当作产品，因此版本管理、速率限制、用量计量和开发者文档排在首位。企业内部系统和工作流平台的重头是与现有系统的集成、对应组织结构的角色模型，以及可配置的流程定义。B2C 平台必须承受不可预测的流量，并让新用户引导流程保持简短；B2B 平台则需要单点登录、细粒度权限和审计轨迹。
尽早明确产品品类，可以避免把精力平均摊开。难点部分由资深工程师重点投入，并做定制化工程；其余部分一律使用标准组件。
让产品决策与工程决策保持关联
许多扩展性问题，最初都是在没有工程参与的情况下做出的产品决策。承诺按客户定制，如果没有把配置能力设计进模型，就会变成每个客户一个代码分支。免费版会改变负载特征和可被滥用的攻击面。实时协作则会彻底改变数据架构。
从探索阶段开始，我们就让产品和工程处在同一场对话中。每一个路线图条目都附带它的技术影响和成本，每一项架构决策都对应着支撑它的产品需求。这也是估算可信的原因：在作出承诺之前，范围、设计和架构是放在一起理解的。
我们如何构建
我们的方法
每个阶段都会产出下一阶段可以检验的成果。
- 01
探索与产品策略
明确用户、问题、最高风险的假设和成功指标。就能够产生证据的最小版本达成一致。
- 02
UX 与原型
设计核心流程，并在投入工程时间之前，用可点击的原型对它们进行测试。
- 03
架构与基础
对领域和数据建模，确定身份、租户模型和 API 形态，并搭建代码仓库、CI、环境和可观测性。
- 04
增量开发
构建每个迭代都能演示的垂直切片，从一开始就配备自动化测试，并部署到类生产环境。
- 05
加固与上线
进行安全评审、负载测试以及备份与恢复检查，然后通过分阶段发布上线，并随时可以回滚。
- 06
度量与改进
对照成功指标解读使用数据和运维数据，调整路线图，并偿还数据表明已经在拖慢进度的技术债。
取舍
决定设计走向的决策
在确定架构之前，我们会与您的团队逐一厘清的问题。
- 自研、采购，还是用现有服务组装？
- 不构成差异化的部分，就采购或集成：认证、支付、邮件、搜索、数据分析。定义产品本身的部分，或者供应商的模型会束缚产品的部分，则自己构建。对每一项依赖，都要检查退出成本、数据所有权，以及在比如十倍于当前用量时的定价。
- 原生移动应用、跨平台，还是先做响应式 Web？
- 当产品主要在办公桌前使用，或需要以最低成本覆盖最广的用户时，先做响应式 Web。当移动应用必不可少、且要由一个团队同时覆盖两个平台时，选择 React Native 或 Flutter 这类跨平台框架。当产品依赖设备能力、平台特有的 UX 或持续稳定的性能时，选择原生开发。
- 从第一天起就做多租户，还是每个客户单独部署？
- 对于 SaaS，从一开始就按多租户设计，每一行数据都带有租户标识，并在数据访问层或通过行级安全策略强制隔离。对于有严格隔离或数据驻留要求的客户，可以把独立数据库或独立部署作为一个服务层级提供。默认采用单租户，会让运维成本随着每个新客户成倍增加。
- MVP 应该在可扩展性上投入多少？
- 把投入放在可扩展的能力上，而不是规模本身。无状态的应用服务器、合理的数据模型、针对真实查询建立的索引和自动化部署，可以让容量在需要时再行增加。分片、多区域和服务拆分应当等到有了经过度量的需求再做。
- 新产品该用单体还是服务化？
- 模块化单体。新产品的边界尚不明确，而单体能让边界以很低的成本调整。保持模块之间通过接口隔离，这样一旦某条边界稳定下来、并且有了独立存在的理由，就可以把它抽取成服务。
生产就绪
怎样才算生产就绪
如何保障安全
身份、授权和租户隔离在第一个迭代中就完成设计，并由自动化测试覆盖。数据加密，密钥集中管理，依赖经过扫描，审计日志记录谁做了什么，其格式的设计旨在支持产品所在市场所期望的框架。
如何扩展
产品在一个简单、可水平扩展的基础上启动：无状态服务、留有余量的托管关系型数据库、缓存和任务队列。增长通过增加容量和抽取热点路径来应对，并以度量数据为依据。
如何监控
运维遥测和产品分析在上线前就已到位：日志、指标、链路追踪、错误追踪，以及成功指标背后的事件。团队既能看到系统是否健康，也能看到产品是否按预期被使用。
如何部署
每一次合并都可以通过自动化管道部署到以代码定义的环境中。功能开关和分阶段发布让未完成或有风险的工作可以安全地进入生产环境，回滚则是一项常规操作。
如何集成
产品从一开始就对外提供版本化 API，并由自己的客户端使用；它通过适配器与支付、身份、消息和企业系统集成，把供应商的特有细节隔离在适配器内。Webhook 和事件让客户与内部系统能够对变化作出响应。
技术
根据工作负载和您现有的技术资产来选择。
- TypeScript
- React
- Next.js
- React Native
- Flutter
- Node.js
- Java
- Spring Boot
- PostgreSQL
- Redis
- Docker
- Kubernetes
- Terraform
- OpenTelemetry
从零到生产
工程生命周期
- 01
想法
- 02
探索
- 03
系统架构
- 04
UX / 产品设计
- 05
应用工程
- 06
AI / 数据层
- 07
云基础设施
- 08
安全
- 09
质量保证与性能
- 10
部署
- 11
可观测性
- 12
持续演进
常见问题
常见问题
构建一个 MVP 需要多长时间？
这取决于范围、集成和监管约束，所以要先做探索。探索的目标是得出一份发布计划，其中有明确的第一个切片，以及基于已理解范围的估算，而不是在问题尚未定义之前就给出一个数字。
我们只有一个想法，还没有需求规格。可以从这里开始吗？
可以。探索阶段会把一个想法转化为明确的用户、流程、假设、架构和排好优先级的范围，同时也会确定哪些东西现在还不该做。
MVP 以后是否必须推倒重来？
不应该如此。只要数据模型、身份、租户模型、部署和可观测性都做得到位，MVP 就是生产系统的第一个版本，并通过扩展不断演进。有意走捷径构建的部分会被记录下来，以便日后有计划地替换。
上线之后你们还会继续参与吗？
会。运维、监控、优化和后续开发，都属于我们在工程上所考虑的生命周期的一部分。交接模式在项目开始时就约定好，无论是由我们继续运维系统，还是移交给你的团队。