第4章：详细设计文档：编写PRD、绘制业务流程图、定义数据字典
各位好，我是老张。今天咱们聊聊货架系统从0到1过程中，最容易被忽视、却又最要命的一环——详细设计文档。
很多人觉得，产品嘛，画个草图、写个需求列表就完事了。我告诉你，这想法在货架行业行不通。货架系统涉及结构力学、仓储物流、生产排期、成本核算，任何一个环节掉链子，后面就是灾难。
我自己带过十几个项目，从轻型货架到重型立体库，踩过的坑能写本书。今天我把核心经验提炼出来，就是三样东西：PRD（产品需求文档）、业务流程图、数据字典。这三样做好了，项目就稳了一半。
4.1 编写PRD：别写成“愿望清单”
PRD是什么？不是给老板看的画饼文档，而是给研发、生产、质检、采购看的行动指南。
我见过太多PRD，写“货架要坚固耐用”。这叫什么需求？这叫废话。你得写清楚：
- 承重指标：每层均匀载荷500kg，集中载荷300kg
- 材料规格：立柱采用SS400冷弯型钢，厚度2.0mm±0.1mm
- 表面处理：静电喷涂，涂层厚度60-80μm，盐雾测试≥240小时
- 安全系数：静载安全系数≥1.5，动载安全系数≥1.8
核心原则：PRD里的每一条需求，都必须能被验证。不能验证的需求，就是耍流氓。
举个例子。我曾经遇到一个客户，说“货架要防锈”。我追问：“防锈到什么程度？室内还是室外？预期寿命几年？”客户懵了。最后我们定下来：室内环境，相对湿度≤85%，无腐蚀性气体，质保期内不允许出现锈蚀。这才叫可验证的需求。
PRD的结构，我习惯这样组织：
- 项目背景：为什么做这个产品？解决什么问题？
- 目标用户：谁在用？仓库管理员？叉车工？
- 功能需求：货架要能装什么？怎么装？怎么取？
- 非功能需求：承重、寿命、环境适应性、安全标准
- 约束条件：预算、工期、现有场地限制
- 验收标准：怎么才算做完了？
我的小技巧：PRD写完后，找生产主管和质检经理各看一遍。他们能发现你根本想不到的问题。比如有一次，我写“立柱打孔间距50mm”，生产主管说：“你考虑过冲孔模具的磨损吗？50mm间距会导致模具寿命缩短30%。”嗯，这个我确实没想到。
4.2 绘制业务流程图：把“怎么做”画出来
PRD是“做什么”，流程图是“怎么做”。
货架系统的业务流程，我一般分三个层面：
- 业务层面：从客户下单到交付的全流程
- 系统层面：WMS（仓库管理系统）与货架的交互逻辑
- 操作层面：叉车工怎么存取货？流程是什么？
画流程图，我推荐用泳道图。每个角色一泳道，清清楚楚。
举个例子，一个典型的“入库流程”泳道图：
| 角色 | 步骤1 | 步骤2 | 步骤3 | 步骤4 |
|---|---|---|---|---|
| 收货员 | 扫描托盘条码 | 核对货物信息 | 确认入库 | — |
| WMS系统 | 接收入库请求 | 分配货位 | 更新库存 | 生成上架任务 |
| 叉车工 | — | — | 接收上架指令 | 将托盘放入指定货位 |
你看，每个角色做什么，一目了然。这就是流程图的价值。
注意：流程图一定要画到异常分支。比如“扫描条码失败怎么办？”“货位已被占用怎么办？”很多项目只画了正常流程，一遇到异常就抓瞎。我吃过这个亏，后来每个流程都强制画异常分支。
4.3 定义数据字典：让所有人说同一种语言
数据字典，说白了就是统一术语。
你想想看，一个项目里，销售说“货架”，研发说“货架系统”，生产说“货架组件”，采购说“货架零件”。四个人说的都是同一个东西吗？不一定。
数据字典就是解决这个问题的。它定义每个数据项的：
- 名称：统一的中文名
- 英文名：系统里用的字段名
- 类型：字符串？数字？日期？
- 长度：最多多少字符？
- 取值范围：只能选哪些值？
- 业务含义：这个数据到底代表什么？
我举个例子，货架系统里最核心的数据项——货位：
| 数据项 | 英文名 | 类型 | 长度 | 取值范围 | 业务含义 |
|---|---|---|---|---|---|
| 货位编号 | location_id | varchar | 20 | A01-01-01 格式 | 唯一标识一个货位 |
| 货位类型 | location_type | varchar | 10 | 托盘位/箱式位/散货位 | 存放的货物形态 |
| 最大承重 | max_weight | decimal | 8,2 | 0-99999.99 | 单位：kg |
| 当前状态 | status | varchar | 10 | 空闲/占用/锁定/维修 | 货位当前可用性 |
关键点：数据字典不是一次写完就完事了。项目过程中，发现新字段、新术语，必须及时更新。我习惯在项目启动会上就把数据字典定下来，然后每周review一次。
我曾经遇到一个项目，研发和业务对“货位编号”的理解不一样。研发觉得“A01-01-01”里的“A”是区域，“01”是排，“01”是层。业务觉得“A”是仓库，“01”是货架号。结果系统上线后，数据全乱了。后来花了整整一周才把数据清洗干净。你说冤不冤？
4.4 三者的关系：PRD是灵魂，流程图是骨架，数据字典是血肉
这三样东西，缺一不可。
- PRD 告诉你“要做什么”
- 流程图 告诉你“怎么做”
- 数据字典 告诉你“用什么做”
我个人的习惯是：先写PRD，再画流程图，最后定义数据字典。但实际过程中，三者是迭代的。画流程图时发现PRD有遗漏，改PRD；定义数据字典时发现流程不清晰，改流程图。很正常，别怕改。
避坑指南：我曾经在一个项目里，PRD写了80页，流程图画了20张，数据字典定义了300多个字段。结果呢？没人看。为什么？太长了。后来我学乖了：PRD控制在20页以内，流程图不超过10张，数据字典只定义核心字段。剩下的，用附录或者在线文档补充。记住，文档是给人看的，不是用来压箱底的。
好了，这一章就到这里。下一章咱们聊聊结构设计与力学计算，那才是货架系统的硬核部分。到时候见。