Appearance
功能开发完成了，为什么半年还没上线？
一、一个迟迟没有上线的功能
2026 年 3 月，团队接到了一个新的业务需求。
随后，这项需求进入开发阶段，主要开发工作集中在 4 月至 5 月。
到了 7 月左右，测试人员开始对功能进行验证。期间发现了一些问题，我也根据测试反馈进行了相应的修复。
按照原本的开发流程，接下来需要继续测试、确认结果，并在满足发布条件后上线。
但后续测试没有继续完成。
随着其他需求陆续获得更高优先级，测试人员转向了其他工作，包括本团队后续需求以及其他团队、其他系统的测试任务。
原来的需求便一直处于等待状态。
截至 2026 年 10 月，这项功能仍然没有正式向业务开放。
如果从 5 月左右完成主要开发开始计算，到 10 月已经过去近半年。这里的“半年”是对等待时间的近似描述，并非精确的六个月。
在我参与和了解的工作沟通中，没有收到这项需求被正式取消或暂停的通知。
它只是没有继续完成后续测试。
这让我开始思考：
为什么一项已经完成主要开发工作的需求，还可能在数月后无法完成交付？
二、开发与测试之间的资源约束
这次需求的测试没有完成，并不是团队第一次遇到类似情况。
在我工作的这段时间里，开发与测试资源不匹配的情况已经持续存在多年，研发和测试人员对此都比较了解。
当时，多个业务系统共用数量有限的测试人员，而各个系统仍然持续产生新的开发需求。
因此，团队在实际工作中形成了一些不成文的测试分工约定。
对于修改文案、调整简单字段、修改部分后台接口等相对简单的需求，通常由开发人员自行验证，不再专门安排测试人员参与。
而对于涉及页面、业务流程比较长的功能，则需要经过测试人员验证。
不同功能的修改范围、业务复杂度和验证工作量并不相同，这些约定反映了团队在有限测试资源下采用的实际工作方式。
本次需求涉及较完整的业务流程，按照团队原有约定，需要测试人员参与。
所以，即使开发人员已经完成代码实现，并根据测试反馈修复了发现的问题，整个测试流程仍然没有结束。
开发完成，并不代表功能已经具备正式向业务开放的条件。
三、没有明确取消，但也没有继续推进
这次经历还有一个值得关注的地方：需求并没有被明确取消。
在日常工作中，需求内容可能通过企业微信等方式发送给开发人员，而优先级安排经常通过口头交流完成。
例如，正在处理某项工作时，可能又收到新的安排：
“这个需求比较急，先做这个。”
当其他工作获得更高优先级时，原来正在进行的工作就可能暂时让出资源。
本次需求也是如此。
它已经开始测试，期间发现的问题也进行了修复，但随后测试人员转向了其他需求，原来的测试工作便没有继续完成。
这些后续工作既包括我参与的其他开发需求所对应的测试，也包括其他团队和系统的测试任务。
在后续的日常工作中，我曾向测试人员询问这项需求的测试进度，也了解到他们当时正在处理哪些其他任务。
这些交流只是为了了解当前进展，并不涉及由我决定测试工作的优先级或重新安排测试任务。相关工作的优先级仍按照实际业务安排确定。
在我参与和了解的工作沟通中，没有收到这项需求被正式取消或暂停的通知。
因此，从已知的需求状态来看，它没有被明确终止；但从实际执行过程来看，它也没有继续向下一阶段推进。
一项需求可以没有被明确取消，却长期无法完成后续交付。
这里无法据此判断相关人员是否遗忘了需求，也无法仅根据最终结果评价每一次优先级调整。
能够确认的是，其他工作获得了优先处理，而本次需求的后续测试没有完成。
四、开发完成与业务交付并不是同一件事
在软件开发过程中，我们经常使用“做完了”来描述一项工作。
但它可能对应不同的状态：
- 代码实现完成，开发人员已经自测。
- 功能提交测试，等待测试人员验证。
- 测试发现的问题已经修复，但尚未完成后续验证。
- 测试完成，功能等待正式启用。
- 功能正式向业务开放，开始提供预期服务。
这些状态之间存在明显区别。
从开发工作的角度看，代码实现完成，意味着主要开发任务已经结束。
但从业务需求的角度看，通常还需要经过测试、发布或启用等环节，功能才能真正投入使用。
本次需求在 5 月左右已经完成主要开发工作，后续也根据测试反馈修复了发现的问题。
相关代码虽然已经完成集成与生产部署，但由于测试流程尚未结束，功能仍然没有正式向业务开放。
这意味着开发工作已经投入了相应的时间，而业务端尚未获得这项功能原本预期提供的能力。
单独观察开发阶段，工作已经取得了阶段性成果。
但如果从需求提出一直观察到实际使用，这项工作仍然没有完成最终交付。
两种判断并不矛盾，只是观察范围不同。
开发完成、代码部署和业务交付，可以是三个不同的状态。
五、长时间等待，也可能产生工程成本
功能长期等待正式启用，除了延迟业务使用，还可能带来一些工程上的影响。
5.1 提前集成代码，降低长期分支风险
在本次需求中，开发完成后的代码已经合并进入 prod 分支，并随其他版本部署到了生产环境。
不过，代码部署并不等于功能正式启用。
由于前端尚未配置对应的功能菜单，后端调用入口也受到 flag 控制，这项功能虽然已经部署，但尚未正式对业务开放。
提前完成代码集成，主要是考虑长期独立分支可能带来的风险。
假如功能代码一直停留在独立分支中，而 prod 分支持续发生变化，那么几个月后再进行合并时，就可能因为相同代码被修改、公共类调整或接口变化，需要处理合并冲突或额外适配。
对于修改范围较大、与其他业务代码存在关联的功能，长期不合并后出现这类问题的可能性通常更值得关注。
当然，长期不合并并不意味着一定会发生冲突。是否出现问题，仍然取决于不同分支之间实际发生的代码变化。
本次需求通过提前集成代码，没有将长期独立分支的合并工作留到未来测试恢复时再处理。
这降低了部分潜在风险，但并不意味着后续不再需要验证功能。
5.2 已经部署的代码，仍可能受到后续变化影响
虽然本次代码已经进入生产分支并完成部署，但其他业务开发工作仍然在继续。
在等待期间，公共组件、接口定义和相关业务逻辑都可能发生变化。
这些变更即使没有产生 Git 合并冲突，也可能影响尚未完成测试的功能。
因此，当这项需求重新进入测试流程时，仍然需要结合实际代码变化，判断是否重新验证相关功能。
5.3 重新恢复开发上下文的成本
另一项潜在成本，是重新理解此前已经完成的工作。
开发人员完成一项需求后，通常还会继续处理其他功能。
如果几个月后重新回到原需求，可能需要重新阅读业务规则、回顾代码实现、确认此前修复的问题，并了解期间发生的系统变化。
这些工作并不等于重新开发功能，但可能产生额外的时间成本。
需要说明的是，目前没有数据证明本次需求已经产生多少额外验证或上下文恢复成本。
这里讨论的是长时间等待可能带来的工程风险，而不是已经确认发生的损失。
代码已经完成、集成并部署，不代表功能交付已经完成，也不意味着后续恢复工作一定没有额外成本。
六、团队持续忙碌，与需求持续交付的区别
从日常工作来看，开发人员可能一直有新的任务。
一个功能完成以后，继续开发下一个功能。
测试人员也可能持续处理不同系统的测试需求。
因此，团队成员持续工作，与某一项业务需求能否顺利完成交付，并不是同一个问题。
软件交付依赖多个环节之间的衔接。
开发完成后，需要有人承接后续验证；测试完成后，还需要满足相应的发布或启用条件。
如果某个环节长期缺少足够的承接能力，那么前一个环节即使不断完成工作，也可能形成待处理任务的积累。
这是一种工程流程上的可能结果，并不意味着本次经历已经能够证明团队存在多少积压任务。
而当新的工作不断获得更高优先级时，原本已经投入开发时间的需求，也可能继续处于等待状态。
从单个岗位来看，工作一直在推进。
但从某项需求的完整生命周期来看，它可能长时间没有向最终交付迈进。
这并不是说所有工作都必须按照需求提出的先后顺序完成。
实际业务中，优先级调整是正常现象，紧急需求也可能需要优先处理。
只是从工程交付的角度看，启动一项工作、完成一个开发任务，与最终完成一个业务需求，并不是同一个概念。
七、从这次经历中看到的工程问题
回顾本次需求，主要开发工作已经完成，相关代码也已经合并进入 prod 并部署到生产环境，但功能仍未正式向业务开放。
从已知情况看，这项需求主要停留在后续测试阶段。
随着其他需求获得更高优先级，测试人员转向了其他工作，原需求的后续验证因此没有继续完成，功能也就一直没有正式向业务开放。
这次经历让我注意到软件交付过程中的几个区别。
开发人员完成代码，不代表测试已经完成。
代码已经进入生产环境，也不代表对应功能已经正式启用。
一项需求没有被明确取消，也不代表它一定能够持续获得完成后续交付所需的资源。
而当一项工作长期处于等待状态时，除了业务使用时间被延后，还可能产生重新验证和恢复开发上下文等额外工程成本。
这些现象并不需要通过评价某个人或某个岗位来解释。
仅从本次需求的实际推进过程，就能够观察到不同工作阶段之间的联系。
功能开发完成，只意味着软件交付过程中的一个阶段已经结束。
对于一项完整的业务需求，还需要关注它能否经过后续验证、正式启用等环节，最终成为业务真正能够使用的功能。
这也是这次经历让我重新认识到的一个区别：
开发任务的完成，与业务需求的交付，需要从不同的范围来观察。