说说产品设计中的非功能需求

你的产品有没有遇到过打开页面很慢？使用人数多了之后经常崩溃？这可能是在产品设计的时候没有明确非功能需求，导致技术开发只关注功能实现，而忘了性能和其他方面的需求。在产品的设计和开发过程中，除了关注基本功能需求外，我们还需要关注产品的非功能需求，这对于产品的用户体验和业务拓展非常重要。

互联网产品的非功能需求是指在产品设计和开发过程中需要满足的除基本功能以外的其他需求，如性能、安全、易用性、可维护性、可扩展性、可定制性等。这些需求虽然不像基本功能需求那样直接满足用户的需求，但它们能够增强产品的用户体验、提高产品的稳定性。

例如，对于一个电商平台来说，除了提供基本的购物功能外，还需要考虑网站的响应速度、最大并发数等非功能需求。如果网站响应速度慢，可能会导致用户流失；如果网站只能同时容纳少量用户，那么增长速度就快不起来。因此，关注并满足产品的非功能需求对于产品设计同样非常重要。然而，现实中却往往是优先实现功能，甚至，不少产品需求文档都不会体现这部分内容。

下面列举一些常见的非功能需求。

01

响应速度

指产品在处理业务时的速度和响应能力。通常来说，这个是指某个单项功能的响应速度，例如加入购物车这一项功能。

用户侧响应速度影响的因素主要包括以下四个方面：

• 用户自身的网络条件：虽然这主要是用户自身的原因但是我们需要考虑特殊情况下保障用户体验。典型的例子就是早期 QQ 为了便于用户安装，将安装包做到了几十 KB，即便是在电话拨号时代的“龟速”下用户也能快速下载安装。解决用户网络速度慢的办法可以减少不必要的数据传输，降低数据传输量。比如。在列表中的图片要求使用缩略图，而不是原图。

• 服务器带宽：服务器带宽会影响服务器与公网之间的数据传输速度。我曾经给一个房产中介公司做过一个楼盘网站，上线之初他们感觉访问很慢。实际上是我们为了节省他们的带宽费用特意开通的低带宽云服务器，正式运营后加大带宽即可。这块解决的办法有两个，一是加大服务器带宽，二是增加 CDN （内容分发网络）服务器，可以利用 CDN 服务器提高文件传输。不管哪种方式都需要额外花钱。

• 程序业务处理时间：这块是程序员负责的，一个程序代码的好坏有时候会决定业务的响应速度。大家有兴趣可以看看吴军的《数学之美》，里面有部分介绍内容。

• 数据库的处理速度：大部分业务系统都需要从数据库读写数据，数据表设计不合理、插座语句写得不好或者数据库服务器本身的性能不好都可能导致数据库的处理速度变慢。通常，需要对数据库的慢 SQL 进行监控，然后再来寻求优化方法。

对于产品经理而言，应该对关键业务明确响应速度，通常需要明确网络环境后，给出最低的响应速度要求。例如，3G 网络下，要求加入购物车的响应时间不超过 2 秒。

02

并发数

并发数包括最大同时在线用户数和单位时间最大响应请求数。一个是反映用户容量，一个是反映服务请求容量。在线用户数通常在即时通讯、在线协作、直播类产品中更常用。因为这类产品需要保证在线用户的即时连接。

一种常用的方法是利用平均并发用户数和并发用户数峰值进行用户并发数计算。平均并发用户数C可以根据公式计算。

其中 n 为系统用户数，L为平均在线用户数，T为一天中使用业务的时间。并发用户数峰值C'可以通过公式

这种方法适用于稳定情况下的并发数计算，如果遇到特殊情况，比如春节刷红包、双十一等热门活动，那么是需要额外加大并发数估计的。

单位时间最大响应请求数通常用 QPS（Queries per Second，每秒请求数） 来评估。QPS = 并发量 除以平均响应时间，其中并发量可以被认为是每秒的请求数，平均响应时间可以被认为是每次请求的平均处理时间。从这个公式可以看出，响应时间越短，意味着单位时间能够容纳的请求数越大，服务能力也就越强。如果你的QPS 太低，使得很多用户都需要排队等待，甚至超时未响应。那么要么提高响应速度，要么修改为排队机制的异步操作（比如大量数据的批量导入）。

在计算QPS时，一种常用的方法是利用每天的接口请求数和每天秒数进行计算。公式如下。

其中80%和20%是经验系数，可以根据实际情况进行调整。实际上，有工具可以测试并发请求数量，最为常用的就是JMeter。不过需要注意，不要在生产环境进行测试，以免影响正常服务。

03

安全相关

安全相关实际上是最容易忽略的，因为在没有发生安全事故前，满足这块的需求的回报是看不见的。最为常见的问题就是超级管理员的密码有遇到直接设置为12346这种简单密码的。安全相关的需求包括如下几个方面：

• 账号密码：密码一定是要加密存储的，而且是不可逆加密，目前技术上的做法是用原文+随机字符串，再利用 SHA256这种不可逆编码转成加密密码。这种做法只能单向验证，无法逆向破解，因此比较安全。

• 敏感信息：涉及到个人敏感信息的，需要进行加密处理，比如身份证号码，银行账号等敏感信息。

• 系统漏洞：一般来说，这块都是由运维工程师来完成，对于需要做信息安全等保测评的产品来说，是必须要能够通过漏洞扫描检测的。这块有点超出产品经理的职责范畴了，如果是项目经理，那么就需要提前规划好相关的资金预算和技术资源。

大部分团队将可扩展性丢给了技术开发，但是如果产品经理缺乏长远的规划能力和业务架构能力的话，那么技术是很难了解整个产品的全貌以及产品发展路线的。因此，一方面，产品经理要规划好产品路线图；另一方面需要清晰地梳理出产品的业务架构，有可能的话可以和技术开发一起梳理业务对象之间的关系。这样，可以让产品经理和技术开发更紧密地配合，才有可能保障产品的可扩展性。关于可扩展性，在技术上有一个原则，叫做“对修改关闭，对扩展开放”，意思是尽可能不对原有的业务模块进行修改，而可以通过扩展能力的方式提高产品的业务适配能力。举个例子，消息中心就属于典型的高度可扩展的设计，可以在需要的时候，扩展出来新的消息发送渠道，而不需要修改已有的消息发送渠道

日志系统一般有两种，一种通过埋点记录用户的行为，来追溯责任或分析用户行为；另一种则是监控系统运行状况，对于异常情况进行跟踪，以便技术排查问题，保障系统的稳定性。对于埋点，可以根据运营的需求，合理设计，比如事件埋点、访问路径埋点等等。对于系统监控，需要有日志链路跟踪（也就是能够顺藤摸瓜，找出问题来源），同时，可以考虑接入钉钉、企微、飞书的群消息，出现严重问题时甚至能够自动发起语音呼叫，第一时间解决问题。

本篇介绍了产品经理容易忽视的非功能需求。实际上，如果团队的人都比较负责的话，能够互相补位，那么技术开发和运维也会主动提相关的非功能需求。但是，碰到了“多一事不如少一事”的队友的话，那么产品经理就需要主动给他们“加料”了。我们需要在产品需求文档中明确这些非功能需求，免得他们说“这个你之前又没提”。