有些技术风险，不能只跟老板讲技术

技术人有时候会有点委屈。

明明已经提醒过风险了，最后出了问题，别人却说：“你当时怎么没说清楚？”

你回想一下，自己确实说过。

比如说过这个表后面数据量会很大。

说过这个接口并发上来以后可能扛不住。

说过这个需求如果现在硬做，后面会很难维护。

但问题是，你说的是技术风险，别人听到的可能只是技术细节。

一、不是每个人都会自动理解技术风险的后果

有一次项目里有个查询功能，早期数据量不大，怎么查都很快。

当时我提醒过，后面设备数量和历史数据上来以后，这个查询要重新设计，不然会拖慢。

业务那边听完也点头。

但在他们理解里，这句话大概等于：“以后有空优化一下。”

后来数据量真的上来，页面打开开始变慢，现场反馈也来了。这时候再说“我之前说过”，其实没什么意义。

因为我当时没有把这件事翻译成他们能判断的东西。

我没有说清楚：如果现在不处理，三个月后这个页面可能从 1 秒变成 10 秒，现场查数据会卡，客服会收到投诉，后面再改还可能涉及数据结构调整和停机窗口。

更具体一点，当时现场班组长查一台设备最近一周的记录，页面转了很久。他不关心我们是不是少了索引，也不关心查询有没有走分区。

他只会觉得：这个系统不靠谱，关键时候查不到东西。

技术人嘴里的“查询性能风险”，到现场就变成了“我没法判断这台设备刚才到底有没有异常”。

技术风险只有变成业务影响，才容易被认真对待。

二、向上沟通不是降低技术标准

有些技术负责人不太愿意把技术风险讲得“业务化”。

好像一旦不讲索引、缓存、队列、架构分层，就显得不专业。

其实不是。

向上沟通不是把技术说浅，而是把风险说准。

老板或者业务负责人不一定关心你用了什么方案，但他需要知道这件事会影响什么：

会不会影响上线时间；
会不会影响客户体验；
会不会带来数据错误；
后面返工成本有多高；
如果暂时不做，需要接受什么代价。

这些讲清楚了，决策才有基础。

技术负责人不能只说“这个设计不好”。你要说清楚，它不好在哪里，会什么时候出问题，出了问题谁会受影响，要不要现在处理。

三、我现在会把风险分成三句话讲

第一句话，讲现象。

比如：这个查询现在能跑，但数据量上来以后会明显变慢。

第二句话，讲影响。

比如：慢的不只是页面，后面统计任务、现场查询和接口响应都会受影响。

第三句话，讲选择。

比如：现在多花两天改查询和索引，还是先上线，但接受后面可能要停下来补一次结构调整。

这三句话比单纯说“这里需要优化”有效得多。

因为它把问题从技术偏好，变成了项目取舍。

后来我会在方案评审里专门留一小段“风险翻译”。

不用写得很长，三五行就够：

如果不做，会影响谁；什么时候可能爆出来；到时候补救要花什么代价。

这几行有时候比一大段技术说明更管用。

四、不要只报风险，也要给选项

只报风险也不够。

如果你每次都说“这里有风险”“那里不建议”，别人听久了会觉得技术团队总是在挡事。

所以风险后面最好跟着选项。

方案 A，稳一点，多花三天。

方案 B，先上线，但需要限制数据量，后面补优化。

方案 C，砍掉某个非核心功能，把时间留给底层改造。

你不一定能决定选哪个，但你要把代价摆出来。

如果业务最后还是选择先上线，也没关系。

关键是大家知道自己选了什么，而不是过两个月问题爆出来，再互相问“当时为什么没人提醒”。

这也是技术负责人和普通开发不太一样的地方。

普通开发可以说“这个实现有问题”。

技术负责人要继续往下说：“如果我们接受这个问题，后面会付出什么成本。”

五、小结

有些技术风险，不能只跟老板讲技术。

不是因为技术不重要，而是因为风险要被理解，必须变成别人能判断的语言。

性能问题背后是体验和成本。

架构问题背后是交付速度和维护难度。

数据问题背后是业务可信度。

质量问题背后是团队信用。

你把这些讲清楚，技术判断才有机会进入真正的决策。

本系列：