企业技术需求：一张写满黑话的便签纸，怎么就值三百万？
上周三下午，我被拉去一个“需求对齐会”。会议室里坐了十二个人，白板上贴了十七张便签。老板拍着桌子说：“我们要一个智能化的、能自我进化的、打通全链路的系统！”旁边的技术总监默默补了一句：“预算八十万，下个月上线。”我差点把手里的咖啡洒在裤子上。这不是提需求，这是许愿。
说实话，干了八年乙方工程师，我见过太多这种场面。企业技术需求——这六个字听起来特正经，对吧？但落到纸面上，经常变成一堆互相打架的形容词。今天咱不聊虚的，就从一个具体切口钻进去：你凭什么判断一个“企业技术需求”是真的需求，而不是老板昨晚喝多了拍脑袋的幻觉？
企业技术需求调研会现场白板贴满彩色便签 工程师皱眉
先别急着写PRD，你连“谁在疼”都没搞清楚
很多团队接到需求，第一反应是打开文档开始列功能点。大错特错。我吃过这个亏。2019年给一家汽配厂做MES（制造执行系统）对接，对方采购经理甩过来一份需求列表，整整四页，第一条写着“系统必须支持AI预测设备故障”。我特兴奋，连夜画架构图。结果你猜怎么着？去车间转了一圈，发现他们连设备上的电流传感器都没装，PLC（可编程逻辑控制器）的数据口被环氧树脂封死了——怕工人乱插U盘。预测个啥？预测空气吗？
企业技术需求的第一层真相：需求方嘴里说的“痛点”，往往只是他以为的痛点。得往下挖两层。怎么挖？别开大会。大会只能产出共识性的废话。你要蹲到产生数据的地方去。我后来学乖了，去任何客户那儿，先申请在车间或客服中心待半天。看操作工怎么骂系统，看客服怎么切三个窗口复制粘贴。有一次在物流仓库，我发现分拣员用记号笔在纸箱上画圈——因为扫码枪在电池电量低于20%时，会延迟0.8秒。就这0.8秒，他们宁愿手写也不扫。这才是需求：不是“提升分拣效率”，是“换一款低电量不降频的扫码枪”。简单吧？但你在会议室里永远听不到这个。
所以，拆解企业技术需求，第一步不是问“你要什么”，而是问“你现在怎么干的，卡在哪个动作上”。把那个动作拆到肌肉记忆的粒度。
技术需求像熬汤，火候不对全是沫子
好，假设你摸到了真痛点，下一步怎么把它翻译成技术语言？多数人死在这一步。举个反常识的例子：你觉得“降低生产不良率”是技术需求吗？不是。它是经营目标。你要是直接拿这个去问供应商，对方能给你报出八套方案，从视觉检测到SPC（统计过程控制）再到换模具钢。但真正有效的技术需求长这样：“注塑件在合模后0.3秒内，模腔内压力曲线出现>5%的抖动，且抖动与模温机开关阀动作时间差小于0.1秒时，不良率从2%飙到15%。”——这玩意儿才值得工程师去改控制算法。
我管这叫“压力曲线的抖动”原则：企业技术需求必须带具体场景下的可观测信号。没有信号的需求，就是玄学。比如“系统要稳定”，这叫许愿；“系统在双十一零点并发量冲到5000TPS时，订单创建接口的P99延迟不能超过200ms”——这叫需求。后者能让工程师立刻翻代码查锁竞争，前者只能让产品经理写一份八页纸的免责声明。
工厂注塑机模腔压力传感器安装位置实拍图
还有一个容易踩的坑：把解决方案当需求。客户说“我要上区块链溯源”，你先别急着画节点拓扑。问他：你究竟是想解决经销商窜货，还是想给消费者看个防伪页面？如果是后者，一个加密二维码加数据库就够了，上区块链纯属给服务器加暖气。我见过一家做茶叶的，花四十万搞联盟链，结果最常用的功能是扫码领红包——链上记录的唯一价值是让财务对账时多了一层哈希校验。不是说区块链不好，是你得先拆开看：他到底要的是“不可篡改的凭证”还是“能自动分账的智能合约”。这俩技术路线差着十万八千里。
别在真空中做集成：三条边界一碰就炸
说到落地，很多技术需求文档里缺了一页关键内容：边界条件。你写“系统需支持每天10万条记录”，但没写“在现有MySQL单机且磁盘IO已跑满的情况下”。前者叫理想需求，后者叫真实需求。我见过最离谱的项目，需求方要求“实时同步ERP数据到数据中台”，结果实施时发现ERP是2008年的SAP R/3，压根没有变更数据捕获接口。最后解决办法是：写了个定时脚本每五分钟全量扫一遍，再拿MD5比对差异。性能烂到报警，但业务上居然够用——因为财务一天只对一次账。
所以，你判断一个企业技术需求靠不靠谱，就看它有没有明确“不做什么”和“在什么条件下会失效”。比如：“本系统不处理跨币种结算；当并发用户超过50人时，自动降级为异步队列模式。”听上去怂，对吧？但这才是负责任的需求。那些拍胸脯说“我们什么都能做”的，最后往往是什么都做一半。
再举个边界上的例子。有个做冷链物流的客户，需求写的是“温度监控数据必须实时上传”。我一问：冷库在地下负二层，信号本来就不稳。实时上传？每分钟重传十次，电池三天干废。最后改成“正常时每5分钟上报，温度偏离2℃时切换为30秒上报并触发本地声光报警”。你看，同样是“实时”，边界一划，方案就落地了。否则你写再多的技术指标，也是给运维挖坑。
还有一点，企业技术需求的边界里，必须包含“组织边界”。你系统做得再漂亮，如果操作工嫌麻烦不给你扫码，数据就是死的。我见过一家服装厂，上了RFID工位机，结果车间大姐用锡纸把标签包起来——因为系统会记录她的操作节拍，她不想被计件考核。这需求怎么破？要么改考核规则，要么把标签做成纽扣式缝在衣服里拆不下来。技术方案只能解决一半，另一半得靠管理。所以我在需求调研时永远会多问一句：“谁为这个系统填数据？他填了有什么好处？不填有什么坏处？”这三个问题答不上来，这需求迟早烂尾。
写在最后：需求不是写出来的，是吵出来的
写在最后：需求不是写出来的，是吵出来的
干了这么多年，我最烦那种把“企业技术需求”写成八股文的人。什么“基于微服务架构的数字化转型蓝图”——听着就想打瞌睡。真正有用的需求文档，往往带着油渍、咖啡圈和涂改液。它得能回答：哪个工位哪个人在什么时刻因为什么原因要骂娘。你要是写不出这种句子，就去车间蹲两天，或者把客服录音翻出来听一百条。别坐在办公室里拿AI生成需求模板——那玩意儿除了让预算表好看，屁用没有。
对了，开头那个要“自我进化系统”的老板，后来我们把预算拆成了三块：先花五万打通注塑机数据口，再花八万做个看板让班组长能改阈值，最后留了二十万预备金——因为谁也不知道设备原厂肯不肯开放协议。老板嫌少？我直接怼回去：“您这需求要是能自我进化，我建议它先进化出一个财务自由。”他笑了，合同签了。你看，企业技术需求就是这样，有时候吵一架，比写十页PPT管用。