技术管理 之 跨功能需求管理

原文参见本人博客：技术管理 之 跨功能需求管理

什么是跨功能需求

在成为 Tech Lead 的初始阶段，大部分同学很容易忽视业务需求之外的一些需求，我们称之为跨功能需求（Cross-Functional Requirements，CRF），有时也常被称为非功能需求（Non-Functional Requirements，NFR）。为了直观的感受下什么是跨功能需求，我们来看几个交付过程中常见的场景：

场景一：在一个需求上线后，线上数据量明显超出想象，上线后仅仅半年，数据库存储就无法支撑新增的业务数据，性能下降，甚至可预见在未来一个月内，数据库会因为存储满了而无法提供服务。

场景二：需求开发上线后工作正常，但在一次市场活动中，业务迎来一个峰值，系统因无法处理高峰期的大量并发请求而宕机。

在这两个场景中，需求上线时业务都是可以正常工作的，但随着时间推移或使用场景发生变化，系统无法正常工作，表现为不可用或性能差。软件产品是一个复杂的系统，承载着帮助产品使用者完成复杂的日常工作，提升效率的使命，我们希望它能够在业务演进和架构演进的过程中，保持稳定性和可用性，做高效的助手，而非找麻烦的捣蛋鬼。

正如跨功能需求这个名字中定义的，这些需求跨越了我们构建的所有功能需求，不只是关注在某一个业务模块，而更关注在多个业务功能协同工作时，为保证业务正常运转，软件系统需要满足的一些特性。这些跨功能需求通常表达为“XX 性”，如安全性、可靠性、兼容性、可扩展性等。

关注跨功能需求

从上面两个场景案例可以看出，问题一旦发生，都会是整个交付团队第一优先级需要处理的问题。跨功能需求和功能需求同样重要，不容忽视。

当问题解决后，回顾和反思为什么没有人第一时间考虑这些需求时，或许会将矛头指向需求方：

“为什么没有同时提出这样的跨功能需求?”

“为什么没有提前说会有市场活动？”

而得到的答案往往也比较直接:

“我们只管提业务需求，怎么实现是你们的事情。”

“为什么你们在设计技术方案时没有考虑业务量会增长的情况？”

不管是功能需求还是跨功能需求，需求的澄清和确定都不是某一个角色可以独立完成的，而需要所有参与方共同协作，根据软件系统的现状和未来发展目标，讨论并达成一致。

作为 Tech Lead，在需求讨论和解决方案设计阶段，要从技术侧提出相关问题，帮助团队在进入开发前澄清和确定跨功能需求。这些问题通常需要关注以下几点：

• 软件产品的业务目标

• 产品利益相关者的长期愿景

• 公司内对技术合规的约束和要求

常见的跨功能需求有哪些？

跨功能需求影响着软件的整个生命周期，在项目交付过程中，可以根据软件产品的目标和特点，从以下几个视角来收集和确定跨功能需求：

• 研发团队视角，关注软件研发过程中的跨功能特性，包括软件架构设计相关的一些特性，如可扩展性、可移植性、可伸缩性、兼容性等。

• 用户视角，关注软件使用过程中的跨功能特性，关注用户体验，如设备兼容性、可访问性、可配置性等。

• 运维团队视角，关注软件维护过程中的跨功能特性，包括基础设施运营维护、数据维护、故障恢复相关的一些特性，如性能、可用性、容量、监控、熔断降级策略等。

• 安全审计团队视角，关注软件全生命周期的安全相关的跨功能特性，大部分企业有专门的安全审计部门，会对软件产品的安全提出很多需求，如可审计性，法律合规性，数据隐私性

以上的分类视角可以作为参考，帮助我们快速识别当前产品在哪些方面可能存在跨功能需求，但分类没有绝对的边界，在不同的软件产品研发过程中，一个跨功能需求可能影响多个参与方。

常见的跨功能需求及描述参见下表：

小结

跨功能需求涉及了软件产品的各个方面，但这些需求并不会随着业务需求一起提出。作为团队里的 Tech Lead，需要根据项目的情况，尽早地识别哪些跨功能需求在当前项目中需要特别关注。​对于某些需要长期持续关注的跨功能需求，可以转化为解决方案设计中的一些规范，而针对其他非固定的关键跨功能需求可以设计一个 checklist，在每个新需求到来时进行检查。

在实现业务目标时，有些跨功能需求不是必须的，因此在预算不足的情况下，往往会被踢出去，而变成 技术债。Tech Lead 需要权衡对于一些关键跨功能需求在当前实现和延后实现的收益和成本，做出相对合理的决策，也要时刻警惕因跨功能需求处理不当而引入的 风险。