3、产品风险全景：功能风险、性能风险、安全风险、运维风险、市场风险的定义与识别
做技术产品经理这些年，我最大的感触就是——风险这东西，你越早看见它，它就越不是事儿。怕就怕你压根没意识到这是个坑，一脚踩进去，项目延期、线上事故、用户流失，全来了。
今天咱们就把产品风险拆开揉碎了聊。我习惯把风险分成五类：功能风险、性能风险、安全风险、运维风险、市场风险。每一类我都踩过坑，咱们一个一个说。
3.1 功能风险：做出来的东西对不对？
功能风险，说白了就是「你做的东西，跟需求对不上」。这是最基础的风险，但也是最容易被忽视的。
为什么会这样？我遇到过好几次，产品经理写了个需求文档，开发照着做，测试照着测，上线后用户说「这玩意儿不是我想要的」。问题出在哪？出在需求传递过程中，信息失真了。
- 需求理解偏差：开发理解的和产品想的不是一回事
- 边界条件遗漏：正常流程跑通了，异常场景全挂了
- 逻辑冲突：A功能改了，B功能没跟着改，互相打架
- 用户体验断层：功能能用，但用起来别扭，用户不愿意用
我记得有一次做支付系统，需求文档里写「支持退款」。开发做了退款功能，测试也过了。上线后才发现——退款只能退整单，不能退部分商品。用户炸了。你看，这就是典型的边界条件遗漏。
3.2 性能风险：扛不扛得住？
性能风险，就是你的系统在预期负载下能不能正常响应。我见过太多项目，功能完美，一上线就被用户骂「卡死了」。
性能风险往往不是「有没有」的问题，而是「够不够」的问题。你想想看，一个系统平时跑得飞快，双十一零点一到，直接挂了。这就是典型的性能风险没识别到。
| 性能风险维度 | 典型问题 | 我踩过的坑 |
|---|---|---|
| 响应时间 | 接口响应超过3秒，用户流失 | 曾经有个报表查询，数据量大了直接超时 |
| 吞吐量 | 并发上来后，系统处理能力跟不上 | 秒杀活动，数据库连接池被打满 |
| 资源消耗 | CPU、内存、磁盘IO飙升 | 日志没做滚动，磁盘写满，服务挂了 |
| 扩展性 | 加机器不管用，系统架构有瓶颈 | 数据库单点，加再多应用服务器也没用 |
我个人习惯在做性能风险识别时，先问三个问题：
- 峰值负载是多少？ 别信「平均负载」，要看峰值。平均100，峰值1000，这完全是两码事。
- 瓶颈在哪？ 数据库？网络？还是代码逻辑？
- 降级方案是什么？ 扛不住的时候，能不能优雅地降级？
3.3 安全风险：漏不漏？
安全风险，我把它分成两类：外部攻击和内部泄露。外部攻击是黑客搞你，内部泄露是自己人搞自己。
说实话，很多技术产品经理对安全风险不够重视。总觉得「我们又不是银行，谁没事来攻击我们？」。我告诉你，错了。现在连个智能灯泡都能被黑，你凭什么觉得自己安全？
- SQL注入：用户输入恶意SQL，直接操作数据库
- XSS跨站脚本：用户提交恶意脚本，偷取其他用户信息
- 越权访问：普通用户能访问管理员接口
- 敏感信息泄露：密码明文存储、日志打印敏感数据
- 第三方依赖漏洞：引用的开源库有已知漏洞
我曾经接手过一个项目，用户密码居然是MD5加密存储的。你没看错，MD5。我当时就懵了，这玩意儿跟明文有啥区别？后来花了两周时间，把所有密码升级成bcrypt，还加上了盐值。这事儿让我养成了一个习惯——安全风险识别，从代码审查开始。
「如果这个数据被篡改了会怎样？」
「如果这个接口被恶意调用了会怎样？」
「如果这个用户是黑客，他会从哪里下手？」
嗯，多问几个「如果」，安全风险就藏不住了。
3.4 运维风险：跑不跑得稳？
运维风险，就是系统上线后能不能稳定运行。很多产品经理只关注「上线那一刻」，忽略了「上线之后的日子」。我告诉你，上线只是开始，运维才是持久战。
运维风险的核心就三个字：不可用。系统挂了、数据丢了、服务慢了，这些都是运维风险。
| 运维风险类型 | 具体表现 | 我曾经...（避坑指南） |
|---|---|---|
| 部署风险 | 发布新版本导致服务中断 | 我曾经直接在生产环境部署，忘了回滚方案，结果出问题了只能干瞪眼 |
| 监控缺失 | 系统出问题了没人知道 | 我曾经有个服务挂了6小时，用户投诉了才知道，因为没有监控告警 |
| 容量不足 | 业务增长，资源不够用 | 我曾经低估了用户增长，数据库磁盘满了，整个服务瘫痪 |
| 灾备缺失 | 机房挂了，数据全丢 | 我曾经以为单机房就够了，直到有一次机房断电...嗯，后来上了多活 |
我个人习惯在做运维风险识别时，重点关注三个点：
- 可观测性：日志、监控、告警，这三样缺一不可。没有监控的系统，就像闭着眼睛开车。
- 可回滚性：每次发布都要能回滚。不能回滚的发布，就是赌博。
- 可恢复性：系统挂了，多久能恢复？有没有预案？
3.5 市场风险：卖不卖得出去？
市场风险，就是你的产品做出来了，有没有人买单。这个风险最容易被技术出身的PM忽略。你想想看，技术再牛，功能再全，性能再好，没人用，一切都是零。
市场风险包括：
- 需求真实性风险：你以为用户需要，其实用户不需要。或者用户嘴上说需要，实际不会用。
- 竞争风险：你做的功能，竞品已经做了，而且做得更好。
- 定价风险：定价高了没人买，定价低了赚不到钱。
- 时机风险：入场太早，市场没成熟；入场太晚，蛋糕被分完了。
我记得有个项目，团队花了半年做了一个非常牛的功能，技术架构、性能优化都做到了极致。结果上线后，用户反馈「这功能我们用不上」。为什么？因为我们没有提前做用户调研，全凭产品经理「我觉得用户需要」。嗯，这个教训挺深刻的。
3.6 五类风险的关联与优先级
这五类风险不是孤立的，它们之间会互相影响。比如：
- 功能风险没控制好，频繁改需求，会导致性能风险（代码越改越烂）
- 安全风险没处理好，被黑客攻击了，运维风险就来了（系统挂了）
- 市场风险没识别到，产品没人用，其他风险再低也没意义
那优先级怎么排？我个人建议：市场风险 > 功能风险 > 安全风险 > 性能风险 > 运维风险。为什么？因为市场风险决定了产品能不能活，功能风险决定了产品好不好用，安全风险决定了产品能不能持续用，性能风险和运维风险决定了产品用得爽不爽。
当然，这个优先级不是绝对的。如果你是做金融系统的，安全风险可能比市场风险还重要。如果你是做游戏业务的，性能风险可能排第一。具体问题具体分析，别死板。
- 功能风险：做对了没有？用用户故事地图+异常场景脑暴来识别
- 性能风险：扛不扛得住？关注峰值负载、瓶颈、降级方案
- 安全风险：漏不漏？用威胁建模，从代码审查开始
- 运维风险：跑不跑得稳？关注可观测性、可回滚性、可恢复性
- 市场风险：卖不卖得出去？用MVP思维，做用户调研和竞品分析
好了，这一章的内容就到这儿。下一章咱们聊聊「技术债的量化评估」，我会分享一套我自己用了好几年的评估模型，保证实用。