几乎每个单位都建过需求池，绝大多数最后都变成一张没人打开的 Excel。表格能存不能查，搜索不到就等于不存在。要让需求池真正运转，关键不是换工具，而是先把需求从”一段文字”拆成”一组字段”。
为什么需求池最后都变成一张死表格？
因为记录的是描述，不是数据。一段三百字的自由文本里同时混着技术方向、指标要求、预算、时间窗和联系人，任何一项都无法筛选。结果是：有新需求时没人去查重，有资源时没人能匹配，季度汇报时只能人工数行数。
更隐蔽的问题是不可复现。同一个技术需求，三个人写出三种描述，事后无法判断它们是不是同一件事，也无法判断上次为什么没做成。
一条需求应该拆成哪些字段？
字段不必多，但每一类都要能独立筛选。实践中最小可用的字段集如下。
| 字段 | 取值要求 | 作用 |
|---|---|---|
| 技术方向 | 受控词表，不超过 30 个 | 按领域聚合，避免同义词分裂 |
| 指标阈值 | 数值 + 单位 + 测试条件 | 判断是否可验收，而非”提升明显” |
| 成本区间 | 分档，如 10 万以下 / 10–50 万 / 50 万以上 | 匹配预算，避免无效对接 |
| 可对接资源 | 高校 / 院所 / 供应商 / 内部团队 | 决定走哪条合作路径 |
| 时间窗 | 期望启动与交付时间 | 排期与优先级判断 |
| 状态 | 待评估 / 对接中 / 已立项 / 已关闭 | 避免重复跟进 |
指标阈值这一栏最容易被敷衍。写”识别准确率 98% 以上”没有意义，必须带测试集来源和判定标准，否则验收时双方各执一词。
标签体系怎么建才不会失控？
标签失控的典型症状是：同一个东西有五种写法，最后没人用标签筛选。三条规则能管住。
- 受控词表：技术方向只允许从预设列表选择，不允许自由输入。新增词条需要审核，避免同义分裂。
- 两层结构：一级是领域（如机器视觉、工业控制），二级是具体技术（如缺陷检测、时序预测），检索时可按层过滤。
- 标签只描述”是什么”，不描述”怎么样”。”紧急””重要”这类状态词应放进独立字段，混进标签会让体系迅速腐化。
检索和复用怎么真正落地？
建好字段只是前提，能不能被用起来取决于三个动作。
- 新需求先查重再入库：录入时按技术方向 + 指标关键词自动推荐相似条目，避免同一需求被反复立项。
- 结项必须回写结果：成功或失败都要记录原因。失败的记录价值更高——它能防止第二次踩同一个坑。
- 按资源侧反向检索：高校或供应商有某项能力时，能倒查站内有哪些需求匹配，这才叫池子。
这套做法在实际项目里带来了什么变化？
在我们参与的三个项目里，共同的变化不是”效率提升了多少”，而是三件事变得可能：一是需求评审从讨论描述变成对照字段，会议时间明显缩短；二是跨部门重复立项被识别出来；三是失败项目的教训第一次被留存下来，而不是随人员流动消失。
一个反直觉的经验：字段越少越容易推行。一开始就上二十个字段，录入的人会立刻放弃。先上六个核心字段，跑三个月再扩展，成功率远高于一次性设计完美体系。
小团队没有系统，能用表格实现吗？
可以，但要满足两个条件：一是固定列结构，任何人不得新增或改名；二是用数据验证限制取值，比如技术方向做成下拉选择。表格的致命问题不是容量，而是缺少约束，只要约束住取值，小规模场景下表格完全够用。
需求池需要对外开放吗？
视目的而定。如果目的是找合作方，开放是必要的；但开放前必须先做脱敏，去掉企业名称、具体工艺参数和价格预期，只保留技术方向与指标区间。否则需求池会变成竞争对手的情报来源。
发表回复