当学校提出“统一管理合同”时，产品经理面对的是一地碎片：74种合同类型、十类角色、五类系统、九级审批链，以及30万预算和15人团队的硬约束。本文还原从调研到需求拆解的全过程，看小团队如何把“愿望”翻译成可落地的产品方案。

为保护校方信息，本文将同类岗位和多次沟通合并叙述；工作场景依据项目材料还原，不对应某一次谈话的逐字记录。

从学校跑完最后一轮调研回到公司时，山西的暑气还没有退。办公室那台旧空调照旧嗡嗡作响，桌上却比出发前热闹了许多：不同部门勾过的需求卡片、临时记下来的问题、老师发来的制度材料、合同样本，还有手机里没有来得及整理的消息，全堆在了一起。

进学校以前，我们听到的需求只有一句话：把合同统一管起来。等真正围着采购、财务、科研、法务、后勤、信息化、用印和档案等岗位转过一圈，这句话已经碎成了很多块。采购关心合同是否偏离中标结果，财务关心预算和付款，科研关心项目及经费，用印岗位担心审批版本和最后盖章的版本不是同一份，普通老师最在意的却是合同应该从哪里发起、材料少传一份会不会又被退回来。

每个人说的都有道理，可把这些话直接放在一起，并不会自动变成一套系统。经办老师希望少填几个字段，管理部门希望材料一个也不能缺；财务希望预算没有确认就不能提交，业务部门又担心财务接口停半天，所有合同都跟着卡住。我们第一次完整翻看这些材料时才意识到，前两篇解决的只是把话问出来，真正麻烦的工作现在才开始。

我们先把“老师说过的话”留了下来

最容易犯的错，是产品经理一回公司就打开文档，把老师的话翻译成“系统支持某某功能”。采购老师说希望合同和招投标结果保持一致，写进需求就变成“系统支持智能一致性比对”；财务说付款时要核对合同、验收和发票，转眼就变成“系统自动完成三单匹配”。一句话从老师嘴里走到文档里，功能忽然变得无所不能，至于怎么实现、需要谁配合，反而没人再问了。

我们没有急着这么写，而是先给每条意见保留来源。哪张卡片勾出来的，哪个部门提出的，当时拿什么材料作依据，还有谁需要再次确认，都先记录下来。产品经理可以整理语言，但不能把采购部门的意见写成财务已经同意的规则，也不能把信息化老师口中的“可以研究接口”写成对方系统一定会免费开放。

这一步看上去很笨，做起来也没有什么成就感。办公室里真正发生的事情，就是一条条抄编号、核部门、找附件，再把不确定的地方圈出来。但如果没有这层来源记录，过几天再看文档，我们自己都分不清某句话究竟是学校明确要求，还是当时坐在电脑前觉得“最好能有”。

卡片于是被分成了三类内容。第一类是业务事实，例如科研合同需要关联科研项目、采购合同来自采购结果、盖章以后还有纸质原件；第二类是管理规则，例如金额不足能不能提交、非范本是否必须进法务、重大合同要到哪一级；第三类只是愿望，例如最好能自动读懂三份文档、自动识别发票、自动判断所有风险。事实可以继续核对，规则必须找有权决定的部门，愿望则要回到产品和预算面前重新判断。

一句话放进系统以前，要先拆开看看

桌上最典型的一条意见，是“合同要与招标文件、投标文件保持一致”。它听起来完全正确，谁也不会反对。可我们把它写到纸上以后，马上遇到了第二个问题：学校真正要的，是防止供应商、金额和核心条款悄悄改变，还是要求系统自动读完三份格式各异的PDF，再判断其中所有实质性差异？

这两件事的成本不是一个量级。采购系统如果能够提供项目编号、中标供应商和中标金额，合同系统可以取得结构化数据，先对关键字段进行校验；交付期限、付款方式、验收标准和质保期等内容，也可以做成固定核对清单，由经办人与采购岗位逐项确认并留痕。要让软件自动理解三份文档里的全部条款，则需要额外的文字识别和语义比对能力，还要有足够的样本、硬件、调试时间和验收口径。

项目材料后来在这条需求旁边留下了一段很直接的产品批注：理想化的三文比对需要外部OCR等能力，在30万元预算内无法按照原描述响应。我们没有因此把“防止合同偏离采购结果”整条删掉，而是把目标和实现方式分开。目标仍然保留，本期先用采购数据校验关键字段、人工核对清单和差异确认单把责任守住，完整的自动比对再看后续条件。

财务部门的“三单匹配”也经历了同样的拆解。合同和验收记录在合同系统，发票和付款办理通常在财务系统，如果连票据识别和财务业务也全部搬进来，相当于用有限预算再造半套财务系统。最后留下的需求，是合同系统管理约定金额、付款节点和验收材料，财务系统负责发票与支付，支付完成后把状态、时间和凭证号回写合同台账。

老师给产品经理的往往不是需求，而是一个希望看到的结果。我们真正要做的，是在不丢掉这个结果的前提下，找到项目承担得起的办法。

桌上的合同越分越多，最后变成了74种

把单条意见拆开以后，另一件麻烦事又冒了出来：同样叫合同，不同部门说的根本不是同一种东西。采购部门先列出货物、服务和工程，科研部门又补进横向项目、技术开发、技术服务和成果转化；后勤还有维修、物业、食堂、租赁和场地使用，教学部门又带来校企合作、实习基地、培训与合作办学。

开始时，我们还想用“采购合同、科研合同、其他合同”几个大类把它们装进去。真正往下填字段才发现，工程合同关心预付款、进度款、结算款和质保金，租赁合同关心租金和收款周期，科研合同要带项目编号、负责人和经费，设备采购又可能关联中标信息与资产验收。如果只有一个“其他合同”，老师发起时仍然不知道该选什么，系统也无法决定该显示哪些字段、材料和流程。

我们只能继续拆。每看到一个新的合同名称，就追问它从哪个业务产生，归谁管理，有没有标准模板，发起时要带什么材料，金额和业务属性会不会改变审批，签完以后怎样履约。名称相近但规则相同的合并，名称相同但责任完全不同的分开，最终在项目材料里整理出了74种合同。

74不是为了证明学校合同多，也不是要开发74套页面。这个数字第一次让我们看见，全校合同管理真正缺的不是一个登记入口，而是一张能够把合同名称、归口部门、模板、表单、审批和履约方式连起来的地图。没有这张地图，后面所有“流程自动匹配”和“分类统计”都只是空话。

合同越分越细，负责处理它的人也越来越清楚。经办人、所在部门负责人、业务归口负责人、采购负责人、合同管理或法务、财务负责人、合同管理部门负责人、分管校领导、校长和审计纪检，最后被整理成十类角色。九级审批链也在这些角色之间逐渐显出来，但审计纪检属于独立监督，不应该为了凑齐角色硬塞进普通审批。

外部系统同样是这么冒出来的。最开始大家只说采购、财务和科研三个核心业务系统，后来登录需要统一身份认证，移动审批和消息又离不开学校的办公平台，于是范围变成了五类系统。到这时候，一张卡片上的勾选已经不再是孤零零的功能，它开始与合同类型、岗位、数据来源和异常处理发生关系。

我们把现有产品打开，一条条对照

如果我们是一家几百人的服务公司，也许可以顺着所有想法从头设计一套新系统。但我们只有15个人，合作伙伴之所以打来电话，也是因为他已经看过我们的免费演示环境，觉得现有合同起草、审批、用印、履约和归档大体能够承接学校的事情。我们回到办公室后的任务，不是重新画一套高校系统，而是把整理出来的规则放到现有产品旁边逐项核对。

合同台账、附件、审批记录、到期提醒和基础归档，现有产品可以直接承接；合同分类、模板、表单、编号、角色和流程，大部分可以通过配置完成；科研项目关联、工程付款结构、收入合同收款计划等差异，需要少量定制；统一身份、采购、财务、科研和办公平台属于接口；自动三文比对、自动三单匹配、独立审计平台和完整重大合同会议管理，则必须结合外部能力、预算和建设阶段再决定。

我们在材料旁边不断留下批注。有些地方写“现有功能”，有些写“需要少量定制”，有些写“需要学校提供接口”，还有几处直接写“本期预算无法响应”。这些字并不好看，甚至会让一份正在膨胀的需求显得不够圆满，但它们比所有地方都写“支持”更接近项目真实成本。

这也是小团队必须做的一道算术题。30万元不仅要承担定制开发，还要覆盖五类系统集成、部署、数据初始化、等保适配、培训、试运行和3年质保。单个部门提出的要求都合理，合在一起却可能超过一支15人团队能够交付的边界；如果产品经理不在整理阶段把差异标出来，项目签完以后，研发和实施就只能用加班替前面的含糊买单。

那一桌子卡片整理到最后，并没有直接变成一个漂亮的产品方案。它先变成了我们的工作底稿：74种合同的范围、十类角色、五类外部系统、一条九级审批链，以及一批已经标明直接满足、配置、定制、接口和后续建设的需求。到这一步，我们才算把学校里各自成立的意见，拼成了一套能够继续写下去的东西。

几天后，合作伙伴又把话带了回来：学校准备继续推进，下一步需要一份能够用于采购的正式需求文稿。我们刚整理好的底稿没有机会在文件夹里躺太久，很快又被推到了另一张更大的表格面前——17个功能模块、78项参数、实施培训、质保和验收，都要在同一份文件里说清楚。

需求整理的结束，不是我们终于把老师的话抄完了，而是下一次有人问“这句话凭什么这样写”时，我们还能从文档一路找到那张卡片、那个部门和那条业务理由。

下一篇，我会继续写这份工作底稿怎样变成学校可以使用的采购需求。很多高校的软件采购需求并不是老师从空白文档里独立写出来的，而是由熟悉产品的一方协助起草；真正困难的地方，是怎样参考已有文稿，却不把别人的功能、我们的能力和学校的需要混成同一件事。