软件是一种持续演进的产品

上线是重要的里程碑，但并不代表一款有用的软件产品从此无需管理。用户、运行环境、依赖项、安全风险、监管要求和业务优先级都可能变化。实际需要回答的问题，并不是软件是否能在绝对意义上完成，而是产品还承担哪些生命周期责任、由谁负责，以及什么证据足以支持下一笔投入。

现行的 ISO/IEC/IEEE 12207:2026 软件生命周期标准涵盖构思、开发、运营、支持、维护和退役。它还说明，生命周期过程可以并行、迭代、递归和增量开展。这比让每个功能都按同一套固定阶段顺序推进更符合实际。

本文把生命周期转化为一份实用的产品检查表。它提供决策框架，并不声称某一种方法适用于所有团队。

建筑类比有帮助，但也有边界

软件和建筑都需要明确目标、约束条件、设计、验证、集成、运营与维护。当这个类比促使团队把决策说清楚时，它很有用。如果它让人误以为所有软件需求都能在实现前完全确定，或每项变更都必须经过一套固定顺序，它就会造成误导。

产品可以在用户研究后重新进入探索阶段，在负载测试后调整架构，或在运营数据暴露薄弱假设后修改版本。因此，与其把生命周期看作流水线，不如把它理解为一组带有反馈回路的责任。

面对每一项重要变更，都应先决定继续投入需要什么证据。低风险的文案修改可能不需要复杂流程。支付、身份、医疗或安全相关功能，则可能需要正式需求、威胁建模、独立审查和受控发布。

需要明确的七项生命周期责任

1. 明确目标与约束

规划应明确用户问题、预期结果、决策负责人、关键约束，以及支持继续、转向或停止的证据。有关预算、期限、数据、集成、合规和运营责任的假设也应公开可见。

敏捷交付并不意味着放弃规划。《敏捷宣言》背后的原则既强调频繁交付和响应需求变化，也强调可持续开发、技术卓越和定期复盘。计划可以变化，但其目的应保持明确。

2. 按风险细化需求

需求把目标转化为行为、约束和验收证据。团队不必预测未来的每一个细节，但应尽早解决那些拖延后会带来高成本或高风险的决策。例如权限边界、数据保留、可用性目标、迁移规则，以及外部服务故障时的处理方式。

让尚未验证的假设保持可见。原型可以测试用户是否理解流程，技术验证可以测试集成，小规模发布可以测试需求。每个实验都应有负责人，并明确它要支持哪一项决策。

3. 同时设计体验与系统

体验设计关注用户如何发现、理解流程，以及出错后如何恢复。软件设计关注组件责任、数据边界、接口、故障行为和运营约束。两者都应达到足够的细节，使关键取舍能在被实现代码掩盖之前接受审查。

架构并不等于增加服务。对某个产品而言，模块化单体可能比分布式服务更合适；另一个产品则可能需要更强的隔离或独立扩展。选择能满足当前约束、并为已知变化保留可信路径的最简单结构。记录影响重大的决策及其依据。

4. 以可审查的增量交付

实现阶段应交付足够小的增量，让利益相关方和工程团队能够有效检查。对于选择 Scrum 的团队，官方 2020 年《Scrum 指南》描述了有序的 Product Backlog、Sprint Goal、Sprint Backlog、Definition of Done，以及反复进行的检查和调整。它没有规定合同或定价模式，也不是唯一有效的交付框架。

有用的汇报应围绕决策和证据：哪些目标取得进展，什么发生了变化，哪些问题仍不确定，哪些风险上升，以及团队建议下一步做什么。活动数量本身不能证明产品价值。

如需进一步了解商业结构与不确定性，请阅读我们的软件服务商评估指南。

5. 验证行为、安全与集成

测试应从产品风险出发选择。单元测试可以保护局部行为，而集成、契约、端到端、性能、无障碍、安全、恢复和迁移测试分别回答不同问题。任何有限的测试集都无法证明一个非平凡系统完全没有缺陷。

NIST 最终版 Secure Software Development Framework 1.1 建议把安全开发实践融入所选生命周期。其四组实践包括组织准备、软件保护、生产安全性良好的版本，以及响应漏洞。因此，安全需要贯穿设计、实现、验证、发布和响应，而不是仅在上线前安排一次测试。

集成也需要针对故障路径收集证据。根据实际风险，测试身份验证过期、速率限制、异常响应、局部故障、重试、重复事件和恢复。对于智能合约系统，还应使用合适的测试网和经过严格控制的生产验证，因为测试环境无法复现所有主网依赖或经济条件。

6. 运营并观察产品

发布后仍需明确负责人。定义服务指标、告警、支持渠道、事故角色、回滚或缓解流程、备份与恢复要求，以及用户反馈进入待办列表的方式。可观测性应能回答产品和可靠性问题，同时避免收集超出实际需要的个人或敏感数据。

运营证据可能推翻设计假设。应把事故、支持请求、性能追踪和采用数据作为规划输入，而不是长期当作另一个团队负责的独立事项。

7. 有意识地维护、演进或退役

维护可能包括修复缺陷、更新依赖项、响应漏洞、适应平台变化、提升可运营性，以及随用户需求变化调整行为。并非每个产品都需要持续增加功能，但处于运营状态的产品仍需要明确责任归属和可接受风险。

维护协议应明确范围，包括支持的环境、响应预期、安全更新处理、依赖项责任、监控、备份、数据导出和退出协助。如果产品已不值得继续运行，退役同样属于生命周期工作。应规划通知、迁移、数据保留或删除、访问权限撤销和系统下线。

实用治理检查表

• 目标：用户或业务结果是否明确，决策负责人是谁？
• 证据：什么证据足以支持继续、转向或停止？
• 风险：哪些故障模式需要更严格的需求、审查或测试？
• 质量：发布门槛是否明确且可观察？
• 运营：谁负责部署、事故、支持和恢复？
• 维护：谁负责依赖项、漏洞、平台变化和技术债？
• 退出：产品或供应商变化时，用户和数据能否安全迁移？

维护持续演进的软件产品可能需要长期技术领导。如果这项责任尚不足以设置全职管理岗位，请了解我们的奥地利 Fractional CTO 服务。