7.7
深览指数
产品人人都是产品经理·合同管理吴彦祖··AI 生成
我们怎样把高校的部门意见写成合同系统的正式需求
本文还原了一个15人小团队在30万预算硬约束下，为高校设计合同管理系统的完整需求整理过程。核心结论是：老师给产品经理的不是需求，而是希望看到的结果；产品经理必须把“愿望”翻译成可落地的产品方案，通过保留意见来源、拆分模糊要求、梳理出74种合同类型和十类角色，最终形成一份清晰的、可落地的采购需求工作底稿。适合甲方信息化负责人、2B产品经理、以及所有在资源受限情况下做软件规划的从业者阅读。原文 ↗
核心观点
- ▍高校各个部门提出的合同管理需求，不能直接翻译成系统功能，必须先经过“拆解”和“打标签”——保留来源、区分事实、规则与愿望，再结合预算与技术可行性进行取舍。
- ▍30万预算和15人团队意味着必须做严格的算术题：不能为了实现“自动三文比对”等理想目标，而牺牲系统集成、部署、等保适配等基础性工作。
- 01需求整理过程将“合同与招标文件保持一致”拆解为两个层次：采购系统提供结构化的关键字段校验（可本期实现），以及全自动PDF语义比对（预算内无法响应，延期至后续）。
- 02财务部门提出的“三单匹配”需求被拆解为：合同系统管理约定金额和验收材料，财务系统负责发票支付并回写状态，而不是用30万再造半套财务系统。
- 03通过逐项追问合同的业务来源、归口部门、模板、表单、审批流程，最终从全校范围整理出了74种合同类型，而非简单的“采购、科研、其他”三大类。
- 04整个项目涉及十类角色（经办人至校长）、五类外部系统（采购、财务、科研、统一认证、办公平台）以及一条九级审批链，审计纪检被识别为独立监督角色而未强行塞入审批流。
- 05团队采用“卡片分类法”，将每条意见分入业务事实、管理规则、纯愿望三大类中，并记录来源部门及附件，防止产品经理的二次加工扭曲原始需求。
- 0630万预算不仅包括定制开发，还需覆盖5类系统集成、部署、数据初始化、等保适配、培训、试运行和3年质保，是需求取舍的根本约束。
- 07最终工作底稿明确了哪些需求用现有功能满足、哪些需配置、哪些需定制开发、哪些需依赖外部接口、哪些本期无法响应，形成了17个功能模块、78项参数的系统规划。
反方 / 局限
- — 文章承认了这种“逐一拆解、返回来源”的做法看上去很笨，且充满“现有功能无法支持”的批注，不如直接写“系统可以支持”来得好看，但这却是控制项目成本与交付风险的唯一方式。
- — 自动三文比对、自动三单匹配、重大合同会议管理等高级需求被明确排除在当期预算之外，暗示了该方案的局限性——它并非完美的长期方案，而是一个在约束条件下的妥协产物。
9 分钟 · 4 卡片 · 11 资料
读原文 →