技术团队说"做不了"，是真的还是假的

业务部门和技术团队之间，最常见的冲突之一就是：业务说"这个需求很重要"，技术说"这个做不了"。

有时候是真的做不了，有时候是"能做但代价很大"，有时候是"不想做"。怎么分辨？怎么沟通？

技术团队说"做不了"的几种真实含义

真的做不了。受限于当前的技术架构、第三方服务的能力、或者法律法规的要求。比如：

• "要让两个已经上线的系统实时同步数据，但这两个系统都没有开放接口"——技术上确实做不到
• "要在小程序里直接调用摄像头做人脸识别，但微信不允许"——平台限制
• "要把用户的身份证信息明文存到数据库里"——合规不允许

能做但代价很大。技术上可行，但要花的时间、资源远超预期。比如：

• "要做一个和抖音一样的推荐算法"——能做，但要几十人的算法团队做半年
• "要把页面加载时间从 3 秒降到 0.5 秒"——能做，但要重构整个前端架构
• "要支持同时在线一百万人"——能做，但要买几十台服务器，每月成本几十万

不想做。技术上没问题，但技术团队认为这个需求不合理、优先级不高、或者投入产出比太低。比如：

• "要在这个页面加一个倒计时，剩余时间到了自动刷新"——能做，但会严重影响用户体验
• "要把所有数据都导出成 Excel"——能做，但数据量大了会拖垮数据库
• "要同时支持十套 UI 主题"——能做，但维护成本太高

没理解需求。技术团队对需求的理解有偏差，以为要做的事情比实际复杂得多。比如：

• 业务说"要一个智能推荐"，技术以为要做 AI 算法，其实业务只是想要"按销量排序"
• 业务说"要实时同步"，技术以为要毫秒级延迟，其实业务只是想要"五分钟内更新"

怎么判断是真的做不了

问具体的限制是什么。"做不了"太笼统，要追问：是技术限制、时间限制、还是资源限制？如果是技术限制，问清楚是当前的架构不支持，还是整个行业都做不到。

问有没有替代方案。如果 A 方案做不了，B 方案行不行？比如：实时同步做不到，每小时同步一次行不行？全平台支持做不到，先做 iOS 行不行？

问代价有多大。如果技术团队说"能做但要三个月"，问清楚：如果给六个月呢？如果加两个人呢？如果砍掉一些非核心功能呢？

找第三方验证。如果技术团队说"这个做不到"，但你在竞品那里看到了类似的功能，那大概率不是"做不到"，而是"代价太大"。可以找外部的技术顾问评估一下。

怎么和技术团队沟通

先听技术团队的解释。不要一听到"做不了"就质疑，先让他们把原因说清楚。很多时候，技术团队会给出你没想到的限制。

讲清楚业务价值。技术团队说"做不了"，有时是因为他们不理解这个需求对业务有多重要。讲清楚：这个功能能带来多少收入？能解决多少客户的痛点？如果不做，损失是什么？

一起找替代方案。不要陷入"做 vs 不做"的二元对立，和技术团队一起想：有没有更简单的实现方式？有没有分阶段做的可能？有没有先做一个 MVP 验证价值？

让技术团队参与需求讨论。如果技术团队从一开始就参与需求讨论，他们会在设计阶段就提出技术限制，而不是等到开发阶段才说"做不了"。

常见的误解和真相

误解："技术团队就是在推脱" 真相：大多数技术团队都想做出好产品，他们说"做不了"通常是有原因的。直接质疑只会让沟通更困难。

误解："如果做不了，就换一家技术外包" 真相：换一家外包，同样的限制还在。问题不是"谁来做"，而是"能不能做"。

误解："技术团队应该无条件满足业务需求" 真相：技术团队的责任是用合理的方式实现业务目标，而不是无条件接受所有需求。有时候"不做"才是对业务负责。

误解："竞品做到了，我们也一定能做到" 真相：竞品可能做了不同的取舍。他们可能花了更多的钱、更长的时间、或者牺牲了其他功能。

怎么防止这种冲突

建立技术评审机制。每个需求在立项前，技术团队要做一次评审，给出可行性评估和成本估算。不要等到开发阶段才发现"做不了"。

让业务了解技术限制。定期组织技术分享，让业务团队了解当前架构的能力边界、第三方服务的限制、技术债务的现状。

建立需求优先级机制。不是所有需求都要立刻做。建立一个优先级评估框架，按业务价值、技术成本、紧急程度排序。资源有限时，先做最重要的。

鼓励技术团队提替代方案。如果技术团队只能说"做不了"，那是不够的。要求他们同时给出"能做到什么程度"的替代方案。

读完能做什么决定

• "做不了"有三种含义：真的做不了、能做但代价大、不想做
• 判断方法：问具体限制、问替代方案、问代价、找第三方验证
• 沟通要点：先听解释、讲业务价值、一起找替代、让技术早期参与
• 防止冲突：技术评审、业务了解技术限制、需求优先级、鼓励替代方案
• 记住：技术团队说"做不了"时，先问"为什么"，再问"还有什么办法"