技术人的业务思维:创造需求、发现需求、解决业务

很多人对技术人的想象,还停留在"接需求、写代码、交付"这条流水线上。但真正走过几年项目之后,你会发现:决定一个技术人长期价值的,从来不只是代码能力,而是他能不能站到业务那一侧,看清"为什么要做"和"应该怎么做"。

这篇文章想聊三个能力:创造需求、发现需求、解决业务。它们看起来是产品经理和业务方的事,但实际上,任何一个想往上走的工程师,迟早都要面对。

一、为什么要谈业务

在开始之前,先说一个事实:技术不是孤岛。

一个系统再优雅,跑在一个没人用的功能上,就是一堆没人访问的代码;一段算法再精妙,解决了一个伪问题,就是工程师的自嗨。

业务思维,说到底,就是"从用户和市场的角度看技术"。它不是让你转行做产品,而是让你在做技术决策的时候,多一把业务尺子。

这把尺子上至少有三件事:创造需求、发现需求、解决业务。

二、创造需求:从 0 到 1 的能力

1. 什么是"创造需求"

很多人以为"创造需求"就是忽悠、就是营销、就是编一个不存在的痛点。错了。

真正的创造需求,是发现一种"人们隐约感觉到、但还没被明确表达出来的渴望",然后用产品或技术把它具体化。

iPhone 不是创造了对手机的新需求——人们对"更好的手机"一直有渴望,但没人能说清楚它长什么样;直到乔布斯把它做出来,大家才意识到"原来我要的是这个"。

GPT 不是创造了对 AI 的需求——人们对"更自然的人机交互"一直有想象,但这条路径上,只有 OpenAI 走通了工程实现。

创造需求的本质,是把模糊的渴望变成具体的产品形态。

2. 创造需求的前提:理解人性

技术人最容易踩的坑,是"用技术逻辑推需求"。

比如:

• 工程师 A:“这个查询很慢,我加个索引。”
• 工程师 B:“这个功能用起来很别扭,我重写下流程。”
• 工程师 C:“用户其实想要更安全,我加个双重验证。”

A 是技术优化,B 是体验优化,C 是在凭空创造需求——他可能根本没问过用户为什么觉得"不安全"。

真正的"创造需求"建立在对人性的理解上。几个常见的人性锚点:

• 懒:能少动一下就少动一下
• 怕:怕麻烦、怕丢失、怕错过
• 攀比:别人有我也想有
• 求快:想马上得到结果
• 求美:愿意为"好看"买单

任何一个"创造需求"成功的产品,背后都能找到这几个人性锚点。

3. 技术人怎么练"创造需求"

(1) 多问"为什么之前没人做"

看到一个成功的产品,不要只看它"做了什么",而要问"在它出现之前,为什么没人做"。

抖音之前有快手,快手之前有无数短视频工具。为什么是抖音做出来了"刷"这个动作?这个动作的"为什么不做",就是它的"创造需求"。

(2) 从抱怨里挖金矿

最朴素的需求信号,就是抱怨。

同事说"这个流程太烦了",用户说"为什么没有 xxx",老板说"这个数据我看不到"——这些抱怨里,藏着大量没被满足的需求。

养成记抱怨的习惯,你会发现很多"创造需求"的种子。

(3) 别怕"反共识"

创造需求很多时候意味着你要做一件别人不看好的事。如果你的判断完全跟随共识,那你永远在跟随,不在创造。

当然,反共识不是抬杠。反共识需要你有"对人性、对市场"足够深的理解,否则就是赌博。

三、发现需求:从 1 到 N 的能力

如果说创造需求是"开脑洞",那发现需求就是"接地气"。

1. 什么是"发现需求"

用户嘴里说出来的,往往不是他真正想要的。

• 用户说"我想要一匹更快的马"——他真正想要的是"更快的交通方式"。
• 用户说"我想要更便宜的云服务器"——他真正想要的是"更低的运营成本"。
• 用户说"我想要一个报表系统"——他真正想要的可能是"我不想再被老板追问数据"。

发现需求,就是穿透用户说出来的字面意思,看到他背后的真实目标。

2. 为什么"字面需求"会骗人

三个原因:

(1) 用户用他知道的语言描述问题

他不知道有什么解,所以只能用"现有的东西 + 形容词"来表达。

(2) 用户是"症状描述者"

他感受到的是"痛",但痛的根在哪里,他不一定知道。

(3) 用户有路径依赖

他基于"现在的方式"想"更好的方式",但"现在的方式"本身可能就是错的。

3. 发现需求的三个层次

(1) 听字面:用户说什么,记什么。 (2) 听意图:用户为什么要这个?他背后的目标是什么? (3) 听系统:用户的"这个问题",和"他的整个工作流"是什么关系?只解决这一点,够不够?

举个例子。

某运营说:“我需要一个批量发券的工具。”

• 听字面:做一个批量发券页面。
• 听意图:他想提高运营效率,少做重复劳动。
• 听系统:他真正的痛点可能是"每周要做一次发券复盘",发券只是其中一个动作。这个"周复盘"本身可能才是该被重新设计的东西。

做到第三个层次,你就不是在"做需求"了,而是在"重新设计工作流"。

4. 技术人怎么练"发现需求"

(1) 多问 5 个为什么

对任何需求,连续问 5 个"为什么"。你会发现大量"伪需求"在第三个"为什么"就露馅了。

(2) 画流程图而不是写 PRD

把"用户做这件事的完整流程"画出来,你会发现 80% 的痛点不在用户说的那一点上,而在上下游衔接处。

(3) 去看用户,而不是看邮件

再好的 PRD,都比不上和用户聊 15 分钟。你会看到 PRD 永远写不出来的东西:他在哪里卡住、为什么放弃、最后怎么绕过。

四、解决业务:从执行到伙伴

1. 什么是"解决业务"

接需求 → 写代码 → 交付,这是"完成任务"。

拿到一个业务问题 → 分析本质 → 设计解法 → 落地 → 衡量效果,这是"解决业务"。

两者的区别在于:前者的目标是把事做完,后者的目标是把问题真正解决。

2. 为什么"完成任务"远远不够

一个常见场景:

业务方:“我们需要一个能让我们在后台改价格的功能。” 技术:“好的,下周上线。”

技术按要求做了。但上线后:

• 业务方发现"还是麻烦,每次都要找运营"。
• 运营发现"价格改错了没人审核"。
• 老板发现"改了价格 GMV 反而掉了"。

这个需求表面上完成了,业务问题没解决。

真正的"解决业务"是:

• 改完价格后,有审核链路。
• 改价格这事,业务方能自助,不用每次找运营。
• 改价格的效果,能直接看到数据回流。

3. 技术人"解决业务"的四个动作

(1) 定义问题

客户要的是"马",你要帮他看到"他真正要的是交通"。这一步不做,后面全错。

(2) 设计解法

不只给一个方案,而是给"问题 + 备选解 + 推荐解 + 取舍说明"。让业务方有得选,而不是被动接受。

(3) 衡量效果

上线不是终点,要看数据变化。功能上线一周后,数据有没有按预期走?没走,为什么?

(4) 持续迭代

业务是活的,没有一劳永逸的解法。做完一步,看数据,再走一步。

4. 技术人怎么练"解决业务"

(1) 永远要"商业理解"这一栏

做任何一个需求,先问:这个需求在业务链路里是哪个环节?它影响谁?它带来什么价值?

哪怕只是个 CRUD,也能问出业务。

(2) 主动写"业务说明"

PRD 是产品经理的,但"业务的逻辑"应该是技术人主动去写的。写的过程,就是逼自己想清楚。

(3) 参与业务复盘

很多技术人只参与开发,不参与复盘。这等于放弃了一半的"解决业务"能力。复盘里看到的"为什么没达到预期",才是最有营养的部分。

五、两个时代,三种能力的两种打法

到这里,我们聊了三种能力"是什么"和"怎么练"。但有一件事还没聊:这些能力,被时代放大或削弱的程度并不一样。

把"程序员时代"和"AI 时代"放一起看,你会发现一件有意思的事:同一种能力,在两个时代里扮演的角色,几乎是反过来的。

1. 程序员时代:稀缺的是"做出来"

过去十几年,移动互联网和 SaaS 爆发,技术供给是稀缺的。

那个时代,公司里最响亮的问题永远是:“这个需求,什么时候能上线?”

这个时代的几个特征:

• 需求明确:业务方会给你 PRD,字段、按钮、流程都画好了
• 实现昂贵:做一个产品,需要团队、需要时间、需要测试和运维
• 判断稀薄:只要能"做对",价值就成立了
• 工程师定位:接需求 → 写代码 → 交付,流水线工人

所以这个时代的三种能力,长这样:

• 创造需求 —— 主要由产品经理驱动,工程师参与得少
• 发现需求 —— 靠用户调研、用户访谈、A/B 测试
• 解决业务 —— 靠系统设计、性能优化、稳定性建设

能写代码、能扛流量、能做大系统,就是这个时代的硬通货。技术人的职业路径,基本是"初级 → 高级 → 架构师 → 技术专家"。

2. AI 时代:稀缺的是"判断做什么"

到了 2023 年以后,事情开始变味了。

GitHub Copilot 让写代码的速度翻倍;ChatGPT 让"做一个原型"从一周变成一小时;Cursor、Claude Code 之类的工具,直接把"写代码"这件事的成本压到接近零。

这个时代的新特征:

• 实现廉价:同样的功能,一个人 + AI 一天能出原型
• 需求模糊:因为"做出来"便宜了,“做什么"反而没人想清楚
• 判断升值:能判断"该不该做"的人,比能写代码的人更值钱
• 工程师定位:从"实现者"变成"判断者 + 整合者”

3. 三个能力,在两个时代的不同权重

逐条说。

(1) 创造需求:从"产品的事"变成"工程师的事"

过去创造需求是产品经理的活,工程师按部就班做就完了。

但当"实现"几乎免费,创造需求的瓶颈就从"能不能做"变成了"该做什么"。这时候,谁能先看到机会,谁就赢。

Cursor、v0、bolt.new——这些产品背后的核心,都不是"写代码写得多漂亮",而是"在 AI 时代,开发者应该用什么方式写代码"。它们的创造者,几乎都是工程师。

这意味着:技术人不再是执行者,而是机会的发现者。

(2) 发现需求:从"听用户说"到"看用户做"

过去发现需求的标准动作是用户调研、问卷、访谈。

但 AI 时代,用户会用 AI 来表达"想要什么",而 AI 表达出来的,常常不是用户真正想要的。

这就需要技术人有更强的"穿透"能力:

• 用户用 AI 生成的 prompt 里,藏着他真正的目标
• 用户和 AI 的对话里,藏着他对当前工具的真正不满
• 用户在多个 AI 工具间跳来跳去的行为,藏着他的真实工作流

听字面 → 听意图 → 听系统,这个三层穿透在 AI 时代更重要,因为 AI 让"看起来像需求"的东西变多了,真正的需求反而更隐蔽。

(3) 解决业务:从"做到极致"到"做到刚好"

过去做业务的标志是:性能最好、稳定性最高、覆盖最全。

但 AI 时代,“做到极致"的成本可能不必要。AI 生成的方案常常已经"80 分够用”。这时,真正的功夫是:

• 准确定义问题,别在错的问题上花 10 倍精力
• 整合多个 AI 工具,而不是自己手写一切
• 保留"人"在关键决策上的控制权,别把方向盘交给 AI
• 持续看数据,快速迭代,别追求一次到位

也就是说:解决业务的能力,从"实现能力"变成了"判断能力"。能不能写代码不再是核心,能不能定义对问题、整合对资源、判断对方向,才是。

4. 两个时代,两个"不变"

两个时代打法不同,但有两件事始终没变:

• 业务的本质没变。技术始终是工具,业务始终是"人为什么买单"。AI 改变了"怎么做",但没改变"为什么做"。
• 对人性的理解没变。对人的理解(用户、同事、老板),跨时代都成立。

AI 替代不了"理解人",也不会被时代淘汰。

这也是为什么下一节要谈"跨界"——跨的不是"技术 vs 业务",而是**“一个具体时代里盛行的技能 vs 跨时代都成立的认知”**。

六、跨界:把三个能力串起来

前面说的三种能力——创造需求、发现需求、解决业务——单独看都不新鲜。

但对技术人来说,真正难的,是跨界。

1. 什么是跨界

跨界不是"学一点别的领域",而是三件事的叠加:

• 理解业务:能听懂业务方的语言,能用业务指标思考。
• 理解技术:能看清一个技术方案的真实成本,能区分"概念可行"和"工程可行"。
• 理解人:能理解业务方的焦虑、用户的抱怨、同事的处境。

这三者叠加,就是跨界。

2. 跨界是这三种能力的"乘数"

• 创造需求 × 跨界 = 看得到别人看不到的机会
• 发现需求 × 跨界 = 听得到别人听不懂的话
• 解决业务 × 跨界 = 给得出别人给不出的解法

没有跨界的创造,就是空想;没有跨界的发现,就是误读;没有跨界的解决,就是完成任务。

3. 技术人怎么练跨界

(1) 选一个"非技术"领域,深耕 1-2 年

可以是行业(电商、教育、医疗)、可以是职能(运营、销售、市场)、可以是技术相邻(产品、设计)。

不要贪多,选一个深耕到能"和那个领域的人聊 30 分钟不露怯"。

(2) 养成"翻译"习惯

把"业务语言"翻译成"技术语言",把"技术语言"翻译成"业务语言"。

你能不能用 1 分钟,把"分布式事务"翻译给业务方?能不能用 1 分钟,把"GMV 下降"翻译成"系统该改什么"?

能,就是跨界。

(3) 多和"非技术人"协作

找机会和业务、运营、销售一起做项目。哪怕只是在会上多听,都比闷头写代码强。

(4) 用业务的语言衡量自己的成果

不要再只说"我做了什么功能",而是"我帮业务解决了什么"。

七、写在最后:业务思维不是天赋

很多技术人觉得自己"不会业务"——其实只是没练过。

业务思维和写代码一样,是可学、可用、可练的。

你不需要:

• 转行做产品
• 精通商业理论
• 天生对钱敏感

你只需要:

• 看到需求时,多想一层"为什么"
• 看到方案时,多问一句"这能解决什么"
• 看到结果时,多回看一眼"是不是真有效"

当你开始这么做的时候,你就不是"在写代码",而是"在解决业务"。

这才是技术人长期价值的来源。