什么是跨功能需求
在成为Tech Lead的初始阶段，大部分同学很容易忽视业务需求之外的一些需求，我们称之为跨功能需求（Cross-Functional Requirements，CFR），有时也常被称为非功能需求（Non-Functional Requirements，NFR）。为了直观的感受下什么是跨功能需求，我们来看几个交付过程中常见的场景：
场景一：在一个需求上线后，线上数据量明显超出想象，上线后仅仅半年，数据库存储就无法支撑新增的业务数据，性能下降，甚至可预见在未来一个月内，数据库会因为存储满了而无法提供服务。
场景二：需求开发上线后工作正常，但在一次市场活动中，业务迎来一个峰值，系统因无法处理高峰期的大量并发请求而宕机。
在这两个场景中，需求上线时业务都是可以正常工作的，但随着时间推移或使用场景发生变化，系统无法正常工作，表现为不可用或性能差。软件产品是一个复杂的系统，承载着帮助产品使用者完成复杂的日常工作，提升效率的使命，我们希望它能够在业务演进和架构演进的过程中，保持稳定性和可用性，做高效的助手，而非找麻烦的捣蛋鬼。
正如跨功能需求这个名字中定义的，这些需求跨越了我们构建的所有功能需求，不只是关注在某一个业务模块，而更关注在多个业务功能协同工作时，为保证业务正常运转，软件系统需要满足的一些特性。这些跨功能需求通常表达为“XX性”，如安全性、可靠性、兼容性、可扩展性等。
关注跨功能需求
从上面两个场景案例可以看出，问题一旦发生，都会是整个交付团队第一优先级需要处理的问题。跨功能需求和功能需求同样重要，不容忽视。
当问题解决后，回顾和反思为什么没有人第一时间考虑这些需求时，或许会将矛头指向需求方：
“为什么没有同时提出这样的跨功能需求?”
“为什么没有提前说会有市场活动？”
而得到的答案往往也比较直接:
“我们只管提业务需求，怎么实现是你们的事情。”
“为什么你们在设计技术方案时没有考虑业务量会增长的情况？”
不管是功能需求还是跨功能需求，需求的澄清和确定都不是某一个角色可以独立完成的，而需要所有参与方共同协作，根据软件系统的现状和未来发展目标，讨论并达成一致。
作为Tech Lead，在需求讨论和解决方案设计阶段，要从技术侧提出相关问题，帮助团队在进入开发前澄清和确定跨功能需求。这些问题通常需要关注以下几点：
- 软件产品的业务目标
- 产品利益相关者的长期愿景
- 公司内对技术合规的约束和要求
常见的跨功能需求有哪些？
跨功能需求影响着软件的整个生命周期，在项目交付过程中，可以根据软件产品的目标和特点，从以下几个视角来收集和确定跨功能需求：
- 研发团队视角，关注软件研发过程中的跨功能特性，包括软件架构设计相关的一些特性，如可扩展性、可移植性、可伸缩性、兼容性等。
- 用户视角，关注软件使用过程中的跨功能特性，关注用户体验，如设备兼容性、可访问性、可配置性等。
- 运维团队视角，关注软件维护过程中的跨功能特性，包括基础设施运营维护、数据维护、故障恢复相关的一些特性，如性能、可用性、容量、监控、熔断降级策略等。
- 安全审计团队视角，关注软件全生命周期的安全相关的跨功能特性，大部分企业有专门的安全审计部门，会对软件产品的安全提出很多需求，如可审计性，法律合规性，数据隐私性
以上的分类视角可以作为参考，帮助我们快速识别当前产品在哪些方面可能存在跨功能需求，但分类没有绝对的边界，在不同的软件产品研发过程中，一个跨功能需求可能影响多个参与方。
常见的跨功能需求及描述参见下表：
| CFR | 描述 |
|---|---|
| 可扩展性（Extensibility） | 是否需要组件化？ 是否需要提供一个插件功能，由谁来实施？ |
| 可移植性（Portability） | 是否有迁移到另一个数据库产品或操作系统的必要性？ |
| 可安装性和可部署性（Installability & Deployment） | 需要提供什么样的基础设施？ 需要什么样的安装便利性？ 需要支持持续交付吗？ 如何回滚或升级版本？ |
| 兼容性（Compatibility） | 需要与哪些其他系统集成？ 需要遵循哪些其他行业标准？ 是否需要考虑现有数据格式？ |
| 可集成性和互操作性（Integratability & Interoperability） | 是否需要提供API或库供其他系统使用？版本管理和升级策略是什么？ |
| 可复用性（Leveragability & Reuse） | 是否能够复用企业现有组件/库，或者当前组件/库是否将被重用？ |
| 可伸缩性（Scalability ） | 如何根据不断变化的用户量来提高吞吐量？ 如何对此进行测试？ |
| 版本化和升级策略（Versioning and upgrades） | 版本化策略是什么？ 如何跟踪内部/外部的版本？ 有没有向后兼容的限制？ |
| 可访问性（Accessibility） | 支持有特殊需要的用户（如读屏）。 |
| 本地化和国际化（Localisation & Internationalisation） | 对静态/操作数据是否有多语言支持？ 日期/时间/货币？ 转换和翻译？ |
| 可用性和用户体验（Usability and user experience） | 用户体验对这个系统有多重要，在这个过程中会如何运作？ 是否有公司的用户体验准则要遵循？测试？ 我们是否需要考虑不同的设备/屏幕尺寸？ |
| 分布性（Distributability） | 人们是否能够在特定区域使用该系统，而不会因为地点或距离而受到阻碍？ 它能在没有互联网接入的情况下运行吗？ 如何同步信息？ |
| 帮助与支持（Help & Support） | 需要什么程度的用户文档？ 是否需要建立一个教程，提供视频或提供一个帮助和支持团队？ 是否需要为培训做计划？ |
| 可配置性（Configurability） | 用户或管理员可以配置功能吗？ 如何进行配置管理（如文件、用户界面、API等）？ |
| 支持性（Supportability） | 确定用户/操作支持的级别，以及将如何支持它们？ |
| 归档（Archiving） | 归档什么信息 何时归档 如何归档 谁/如何访问这些归档信息 |
| 可用性（Availability） | 是否有可用性目标要求？ 需要什么架构来满足这些要求？ 是否有特定的日子（如黑色星期五）需要这些？ CAP（一致性、可用性、分区容忍度）。 |
| 容量（Capacity） | 是否有任何特定的存储要求？ 是否有高峰负荷的考虑？ 需要由系统处理的数据量是多少？ 有多少用户将同时使用该系统？ |
| 连续性（Continuity） | 是否考虑灾难恢复计划？ |
| 数据完整性和一致性（Data Integrity and Consistency） | 是否需要数据校验、日志追踪或提供数据恢复机制？ |
| 可维护性（Maintainability） | 最大的可容忍停机时间（RTO/恢复时间目标）是什么？ 是否有预定停机时间的通知要求？ 错误页面如何处理？ |
| 监控（Monitoring） | 是否有现有的工具和基础设施？ 应该衡量哪些业务/技术指标？ 如何进行监测？ 哪些类型的警报是必要的？ |
| 多环境支持（Multiple Environment Support） | 理想情况下需要多少/哪些环境？ 如何配置和管理这些环境？ |
| 性能（Performance） | 吞吐量/响应时间要求是什么？ 需要有计划地进行性能测试吗？ 是否需要考虑异步场景？ |
| 弹性和容错性（Resilience & Fault Tolerance） | 如果某些外部依赖失效/不可用，系统将如何降级？ |
| 可靠性（Reliability） | 不可靠的成本是什么？ 需要多少成本来保证可靠？ |
| 可审计性（Auditability） | 哪些操作应该被跟踪？ 必须满足哪些法律或监管要求？ |
| 认证（Authentication） | 如何鉴别用户身份？ 应该遵循什么标准或使用哪些现有的认证系统？ |
| 授权（Authorisation） | 哪些角色和权限是必要的，他们需要访问哪些功能或数据？ 谁来维护权限，如何维护和应用权限？ |
| 法律合规性（Legal Compliance） | 对数据/系统或软件交付过程是否有法律限制？ 对发布过程是否有任何限制？ |
| 数据隐私（Data Privacy） | 哪些数据应该被加密？ 哪些数据对终端用户和操作人员可见/隐藏？ 开发/测试过程中能否使用生产数据？或者如何做生产数据脱敏处理？ |
| 安全性（Security） | 需要为安全审计或渗透测试制定哪些流程？ 企业的安全准则是什么？ 是否有SSL或VPN要求？ |
小结
跨功能需求涉及了软件产品的各个方面，但这些需求并不会随着业务需求一起提出。作为Tech Lead，需要根据项目的情况，尽早地识别哪些跨功能需求在当前项目中需要特别关注。对于某些需要长期持续关注的跨功能需求，可以转化为解决方案设计中的一些规范，而针对其他非固定的关键跨功能需求可以设计一个checklist，在每个新需求到来时进行检查。
在实现业务目标时，有些跨功能需求不是必须的，因此在预算不足的情况下，往往会被踢出去，而变成 技术债。Tech Lead需要权衡对于一些关键跨功能需求在当前实现和延后实现的收益和成本，做出相对合理的决策，也要时刻警惕因跨功能需求处理不当而引入的 风险。
