ARTICLE · 1062274
跨境物流系统自研 需求文档怎么写才不会返工 90% 的人第一步就错了
产品经理小陈又加班了。
业务部门周一提的需求，周三画好的原型，周四评审通过，周五开发说"这块实现不了，得改"。改完业务又说"不是这个意思"。一版需求文档，前后改了七个版本，项目还没开工。
小陈很委屈：我文档写得很详细啊，每个字段都标了，每个流程都画了。
问题恰恰出在这；90% 的人写需求文档，第一步就错了。
错在哪？错在上来就写文档。
很多人把"写需求文档"当成需求工作的全部：接到需求，打开 Axure，画原型、写字段、排流程，输出一份看起来很专业的 PRD。但文档只是需求的"表达形式"，不是需求本身。文档写得再漂亮，采集错了、分析漏了，写得越快，返工越狠。
需求文档不返工的秘密，不在"写"这个动作里，而在写之前的三步。今天把它拆开讲透。
第一步：先采集，再动笔；你的需求，真的采集全了吗？
动手写文档之前，先问自己一个致命问题：需求清单是"问出来的"，还是"等人给的"？
大部分人写文档的第一手材料，是业务部门"喂"过来的：一次会议、几句口头描述、一个参考系统截图。这些零散的需求点，直接整理成文档，看似完整，实际上千疮百孔；因为业务团队说的，永远是他们看得见的界面需求；看不见的环节，一个字都不会提。
跨境物流系统实战课里，给了一个非常好用的工具：二维需求采集框架。
把它想象成一个坐标：
横轴，是不同类型的物流产品：快递小包、跨境专线、集运转运、海外仓；代表不同的业务模式和客户群体；
纵轴，是系统业务流程：从提交运单、揽收、入库、报关、国际运输，到海外清关、末端派送、签收，共 28 个节点；代表货物流动的链条。
横竖交叉，每一个交点，就是一个必须采集的需求点。
比如"快递小包 × 入库操作"这个交点，要采集的是：重量、长宽高、入库照片、库位分配。把所有交点走一遍，需求框架自然完整呈现。
课程里有个精彩的比喻：这就像下一盘围棋。业务流程是一条线，物流产品也是一条线，每一个落子的位置，就是要采集的需求点。当该落子的位置都落满了，这盘棋的格局也就定了。
这样采集的好处是有章可循，不会有错漏。你不需要天赋异禀，只需要把棋盘铺开，一格一格走。当你拿着这个框架去见客户，客户也不会把你当成菜鸟新手；因为你问的每一个问题，都在点上。
记不住全文，就记住 12 个字：横轴是产品，纵轴是流程，交点是需求。
框架搭完还不够。框架只是骨架，告诉我们系统"要有什么"；但系统"要做到什么程度"，还要跟业务团队确认三大核心问题：
成品系统要达到什么要求？；是支持每天一万单，还是多点多仓管理？这决定了系统能力边界；
当前的痛点是什么？；轨迹不透明？敏感货有漏洞？这是系统要解决的问题清单；
验收指标是什么？；打单效率提升多少？对账错误率降到多少？必须可量化。
课程里的说法很形象：需求框架是骨架，目标、痛点、指标是血肉。骨架和血肉都完整了，这个系统才算被真正定义清楚。
骨架有了，血肉有了，是不是可以写文档了？
还差一步；也是最容易被跳过、日后最容易被翻旧账的一步。
第二步：所有需求，皆有记录；尤其那些被否决的
课程里对这句话的强调是："所有需求，皆有记录。这个必须强烈推荐……强烈推荐……强烈推荐，重要的事说三遍。"
很多人做需求记录有个习惯性漏洞：只记录"要做"的需求，不记录"不做"的需求。
课程里给过一个真实的翻车现场：项目初期，业务团队提了一个需求，大家开会口头否决了，没做记录。系统验收时，业务团队又提起来；"这个功能当时不是说好了吗？"双方各执一词，矛盾就这么结下了。你说没答应过，他说是你们否决的，谁拿得出证据？
没有任何人拿得出证据，因为没有记录。
为什么要连"不合理的需求"都记下来？课程里给了两个理由：
第一，记录本身是一种尊重。业务团队愿意提需求，说明他们在认真思考。哪怕当下实现不了，认真记下来，这个动作本身就在传递信号：我在听，我重视你的意见。
第二，今天的"不合理"，不等于明天的"不合理"。技术是动态发展的，今天觉得是天方夜谭，三个月后可能就是现实。
具体怎么落地？三条机制：
统一入口：会议纪要里的需求、微信里一句话的需求，全部汇总到同一个需求池；
分阶段分版本存档：每条需求打上标签，是哪一期做、哪个版本做，清晰可查；
评审双方见证：每一次需求评审会形成书面材料，双方签字确认。
做到了这三条，需求过程全程可追溯，从提出到验收每个环节都有据可查。把所有信息摆在台面上，就不会有推诿扯皮。
第三步：写进文档之前，先过卡尺；不是所有需求都配进文档
需求采集全了、记录全了，是不是全部写进文档？
不是。文档的另一个隐形功能，是承诺清单；写进去的，开发就得做；写不进去的，日后就没有立场争。所以动笔前，要先用一把卡尺筛一遍。
课程里给跨境物流系统定了一把非常明确的优先级卡尺：
清关政策>运输规则>用户需求。
清关政策是底线，不可撼动。需求触碰清关政策，没有任何商量余地，立即否决。课程里有句话说得狠："不合规的系统，随时可能被打回原形。"课程里还讲过一个真实故事：业务团队说某关口有"很铁的关系"清关不用单证，系统规划就把单证砍了；上线没多久，关口换人，必须要单证，全部推倒重来。守住底线，看似慢，实则快；看似笨，实则稳。
运输规则是约束，必须遵守。比如空运对货物尺寸的硬要求；单边不超 1.2 米、三边之和不超 2 米，因为飞机腹舱舱门就那么宽。这类规则不是法律，但承运人有权拒载，同样是刚性的。
用户需求是目标，在合规前提下最大化满足。用户需求是做系统的初衷，但只能在政策和规则允许的范围内尽最大努力。
用法上分两步：先做减法，再做审查；不可撼动原则砍掉不合规的需求，可行性分析筛掉不能或不需要实现的需求。筛完之后的需求，再逐一"贴坐标"定位：这条需求落在二维框架的哪个交点上？框架外怎么办？客户管理、财务管理这类伴生需求，单独建伴生维度定位。
过了卡尺的需求，才有资格进文档。这样写出来的每一行，都立得住。
顺序对了，文档只是水到渠成
三步走完，才轮到"写文档"这个动作。而且这时候你会发现，文档里最难的部分已经不难度过了：
原型图是需求的"可视化翻译器"；业务团队看到的不再是"筛选条件"四个字，而是一个真实的搜索框、日期选择器、状态下拉框。文字需求变成可视界面，歧义在开发之前就被消灭；
原型图是双方确认的凭证；配上评审签字，它就是验收时的"合同附件"；
需求文档全程可追溯；哪一期提出、哪个版本确认、谁签的字，翻开记录一目了然。
一句话总结今天的主题：
需求文档的质量，不取决于你写文档的水平，取决于你动笔之前做了什么。
先采集（二维框架走交点），再记录（所有需求皆有记录，双方签字），后筛选（卡尺先过一遍）；三步做完，文档只是把已经确认的事实。这样的文档，开发不敢说"实现不了"，业务翻不了旧账，验收吵不起来。
返工，从来不是文档的错，是顺序的错。
自检：你的需求文档踩了几个坑？
对照下面 5 条，看看你们的需求流程缺了哪步：
1、需求清单是拿二维框架（产品 × 流程交点）逐格采集的，不是等人"喂"的；
2、系统目标、当前痛点、验收指标三大问题，都拿到过明确、可量化的答案；
3、被否决的需求也有记录，注明否决原因和时间；
4、每次需求评审都有书面材料，双方签字确认；
5、写进文档的每条需求，都过了"清关政策 运输规则 用户需求"这把卡尺。
少于 3 条，你的需求文档大概率正在批量生产返工。
---
懂跨境物流的人不懂IT系统设计，懂IT的人不懂跨境物流业务。跨境物流系统实战课，帮助跨境物流从业者和IT从业者建立“业务 --> 系统”的翻译能力。跨境物流行业正在经历数字化升级，这种翻译能力，是团队协作的基础，是业务人员、技术人员、管理人员等团队角色，都需要精进的实用技能。
深入了解跨境物流系统实战课，请扫描下方二维码。
