PG官网

"我不懂技术，怎么跟你们提需求啊？"

这句话，做开发的人几乎每周都会听到。说这话的客户，一半是真的谦虚，一半是怕说外行话被忽悠。

先说结论：提需求这件事，考验的是你对自己的生意熟不熟，跟懂不懂技术没有关系。你不需要会说代码，需要的是把你每天怎么做事、怎么挣钱、哪里最烦，讲给别人听。

这篇不讲大道理，直接给方法。

提需求最常见的三个坑

先看看需求为什么总说不清，大多逃不开这三个。

只报功能名。 "我要一个会员系统"" 我要一个进销存 ""我要一个商城"。功能名听着专业，其实信息量接近零。会员怎么分级、积分怎么算、进销存管到哪个环节、商城谁上架谁发货，全都没说。开发公司听完，只能按自己的理解猜。

只说结果，不说过程。 "我要能查库存。" 这句话没错，但库存是怎么来的？是每次进货手动录，还是和供应商系统自动同步？盘点怎么盘？报损怎么处理？过程不说清，做出来的查库存，大概率不是你想要的查库存。

需求全在脑子里。 客户心里其实有一套完整的想法，但没写下来，也没讲全。讲到一半觉得 "这个不用说了吧"，结果开发公司真的不知道。需求没有落到纸面上，就等于没需求。

这三个坑的共同点，是把 "需求" 当成了 "名词"，而不是 "过程"。

讲人话的三件套：讲场景、讲流程、给例子

别急着背功能清单，试着用三种方式说需求。

讲场景。 不说 "我要会员系统"，说 "我的店长每天下班前，要把当天的充值、消费、退款统计出来，发到工作群里"。场景一说，开发公司立刻知道要做什么、给谁用、什么时间用。

讲流程。 不说 "我要一个下单功能"，说 "客户现在是这样下单的：打电话给我，我在本子上记，月底手工对账。我想让客户自己在手机上选、自己付款，账自动对"。流程一说，改造的目标就清楚了。

给例子。 你手上如果有现在用的纸质单据、Excel 表格、对账单，直接拍照片发给开发公司。一张真实的单子，顶一百句描述。开发公司照着单子做，跑偏的概率小得多。

这三件套有一个共同点：都在说 "你现在的样子"。现在的样子说清楚了，要改成什么样，自然就出来了。

分清 "必须有" 和 "可以没有"

提需求时，人很容易把什么都当重点。预算有限、工期有限，需求也得排队。

把需求分成两堆：一堆是 "没有它，生意没法做"，一堆是 "有了更好，没有也能先跑"。前者先进开发，后者往后排。

这招还有一个好处：开发公司拿到需求清单，知道什么是底线、什么是弹性，报价和排期都会实在很多。你只说 "全都要"，对方只能按 "全都要" 报价，钱多花在你不着急的地方。

怎么判断对方有没有听懂

需求讲完，别急着走。让对方复述一遍。

"那你总结一下，我到底要做个什么？" 他要是能把你说的场景、流程、关键点，用自己的话讲出来，说明真听进去了。他要是含糊其辞、只说 "没问题没问题"，或者当场掏合同让你签，那就要多留个心眼。

好的开发公司，听需求的时候会不断追问：这里怎么处理？那个人是谁？这笔钱从哪来？问得越多，说明越认真。真正懂行的，还会主动告诉你 "这个需求先别做，成本高收益低"。

见面前，花一小时准备这张纸

与其见面现场想，不如提前花一小时，把下面这些写下来，见面直接念都行。

你的生意是干嘛的。 卖给谁、收谁的钱、靠什么挣钱，两三句话讲清。

谁在用这个系统。 是自己用，还是店员用，还是客户用？多少人用？

核心流程长什么样。 从开始到结束，现在是怎么走的，哪一步最费事、最容易出错。

你最想解决的那个问题。 只能写一个，就是你最痛的那个。

你见过别人家什么功能，觉得不错。 顺手记下来，见面可以聊，但别当需求清单用。

这一页纸写下来，需求基本就讲清了一半。剩下的一半，交给开发公司陪你捋。

不懂技术，不影响你把需求讲清楚。

把你每天怎么做事、哪里最烦、最想要什么，一样一样说给开发公司听。说的人越具体，做的人越少猜。

见面前先写那页纸，这是你花一小时就能做好的事，比懂任何技术都管用。