作者：合同吴彦祖
2025年7月，那是我在山西经历过最难忘的一个夏天。
毒辣的太阳从早上开始发狠，到了中午，整座城市像一口烧红的铁锅。热气顺着窗缝往办公室里钻，墙上那台用了很多年的空调始终嗡嗡作响，吹出来的风却没有多少凉意，像一条趴在墙角、已经没有力气叫唤的老狗。
我们公司一共15个人。有人在改产品，有人在处理项目，还有人对着客户发来的问题排查原因。15个人听起来不少，但要做产品、写代码、交付项目、处理售后，再分到每件事情上，也就没有几个人了。
这些年，我们做得更多的生意，是把合同管理系统的源代码卖给有技术团队的软件公司。对方经营客户、承接项目，再根据自己的项目做实施和交付；我们把主要精力留在产品和代码上。对于一家只有15个人的小公司来说，这种分工比较适合我们，因为我们没有足够的人手长期经营大量终端客户，也很难让销售、售前和实施围着一个机会反复投入几个月。
所以，当一个有当地关系的合作伙伴打来电话，说某高校正在考虑建设合同管理系统时，我们最初并没有把它当成一个已经到手的项目。
他在我们的免费演示环境里看过系统，知道合同起草、审批、用印、履约和归档大概怎样运转，也信誓旦旦地说，这件事他有把握推进。可当时学校还没有正式立项，没有采购文件，也没有一份已经确认的需求。摆在我们面前的，只有一个关系带来的机会和一句非常笼统的话：学校想把合同统一管起来。
接活之初，我还写过一篇高校合同系统设计。现在项目做完再回头看，那篇文章写得太早了。那时我已经能想象一套高校合同系统应该有什么，却还不知道高校里的需求究竟要从哪些人手里一点点找出来。系统可以在办公室里想，需求却必须走进学校里问。
这组文章，就是想把这段过程重新写一遍。一方面记录我们怎样把这个项目做完，另一方面也希望以后再有人接到高校合同项目时，知道第一步该找谁、该问什么、回来以后应该留下什么文档，而不是拿着一张功能清单在学校里四处碰运气。
见领导，是为了让调研开始，不是为了拿到全部需求
合作伙伴先安排我们拜见了分管校领导。
在很多项目故事里，见到领导仿佛意味着需求已经清楚了。实际情况恰恰相反。领导能够告诉我们学校为什么想做这件事，现有管理方式出了什么大问题，希望系统最终管到什么范围，也能决定哪些部门必须配合；但领导不会逐项告诉我们，一份采购合同要带哪些附件，科研合同和普通采购合同为什么走不同的审查路径，付款时财务要核对什么，用印后纸质合同又由谁收走。
这些不是领导不懂，而是职责不同。
第一次见校领导，我们真正需要确认的是四件事：这件事是不是学校准备认真推动的事；建设目标只是把合同登记起来，还是要把起草、审批、用印、履约、归档连起来；哪些部门必须参加后续调研；当部门之间说法不一致时，最终由谁组织讨论和拍板。
这次见面最重要的结果，也不是记下了几个功能，而是学校给出了一个可以继续开展工作的入口。之后，一位系主任的助理成为我们的日常对接人。她不是整套合同业务的需求负责人，也不可能替财务、采购、科研和后勤回答所有问题，但她熟悉学校内部的人，知道每个问题应该找谁，并且能够带着我们进到不同部门，把原本互不相干的人和事串起来。
这类角色在高校项目里非常重要。我后来把她称为“校内协调人”。产品经理不能把校内协调人当成所有需求的来源，她真正解决的是另外三个问题：帮我们找到正确的人，帮我们安排正确的沟通顺序，帮我们把跨部门的问题重新带回学校内部。没有这个角色，产品经理很容易在校园里转了一圈，收回十几份互相矛盾的意见，却没有人负责组织确认。
所以，高校需求调研的第一步，不是约一场全员大会，而是先建立三层联系人：由校领导或项目负责人确认建设方向，由校内协调人组织调研，由各业务部门分别说明事实和规则。方向、组织和业务不能混在一个人身上。
那一圈到底问了哪些部门
真正开始排调研计划时，我们很快遇到了第一个难题：高校到底要问多少个部门？
如果照着学校通讯录找，部门可以列出一长串；如果只找合同管理部门，又会发现它只能讲管理制度，讲不清合同从哪里产生，更讲不清采购、科研、财务和后勤各自怎样处理。我们最后采用了一个很朴素的办法：先不管门牌上写着什么，顺着一份合同从产生到结束走一遍，看每个环节是谁在做事、谁在定规则、谁在提供数据、谁在承担风险。
在那位助理的带领下，我们围绕十类对象展开沟通：校领导和项目推动人、合同管理及法务、采购招标、财务、科研、教务及二级学院等合同发起部门、总务后勤及资产管理、信息化、党政用印及档案、审计纪检。这里的“十类”是按职责归并后的调研范围，不是硬把学校组织架构说成十个部门。有些岗位在同一个部门，有些职责又会分散在多个学院和职能处室。产品经理需要找全的是责任，不是凑够十块门牌。
见校领导时，我们问的是建设方向：学校为什么在这个时间提出合同管理，究竟要解决线下审批，还是准备把起草、审批、签署、用印、履约、变更、归档和审计都连起来；系统准备覆盖全校，还是先从采购合同开始；跨部门说法不一致时谁负责协调；重大合同按照什么标准识别，又需要上到哪一级会议。领导给出的不是页面需求，而是项目边界。后来需求书里的“全生命周期”“全校统一合同仓库”“重大合同上会”和十类标准角色，都要从这个边界继续往下拆。
到了合同管理和法务岗位，我们不再问“想要哪些功能”，而是把学校现有的合同制度、分类办法、模板和审批规则摆在桌上逐项追问：学校现在把合同分成多少类，每一类归谁管理；标准模板由谁制定、谁发布，老师修改了标准条款以后谁来判断风险；合同金额、类型和部门会不会改变审批路径；非标准合同怎样送审；合同变更、续签、作废和纠纷有没有单独程序；合同编号何时生成，作废以后能不能重新使用。这个部门暴露出来的核心问题，是学校没有一套全校统一的分类、归口、模板和流程标准。同样叫“合同”，在不同部门手里可能按照完全不同的办法办理。
采购与招标办公室是另一条线。我们问一份采购项目在什么时间变成合同，合同发起时需要带入哪些中标信息，供应商、金额、标的物、付款方式和验收标准以哪个系统的数据为准；招标文件、投标文件和最终合同由谁核对；采购结果发生变化怎么办；小额零星采购要不要走完整流程；供应商黑名单是否需要同步。采购部门真正担心的，不只是重复录入，而是合同内容和采购结果不一致以后，责任落在谁身上。于是后来的需求里才会出现采购项目关联、供应商校验、招投标文件留档以及合同与招投标结果一致性核对。
财务部门关心的又不是同一件事。我们要问合同签订前是否必须选择预算项目或经费卡，付款时需要合同、验收单和发票中的哪些数据，分期付款和质保金怎样登记，合同变更后剩余付款计划怎样调整，收入类合同由谁登记收款计划，到账以后怎样确认。财务提出的问题很直接：只有合同金额，没有付款和收款节点，系统最后仍然只是一套电子档案。这个意见让履约、付款、收款、发票登记和“三单匹配”从一句“财务系统对接”，变成了可以继续分析的业务要求。
科研和科产相关部门要单独问。科研合同不等于普通采购合同，我们需要弄清横向和纵向项目怎样区分，技术开发、技术服务、成果转化、知识产权等合同分别由谁归口，合同应该关联哪个科研项目和经费，科研系统向合同系统提供什么数据，科研合作收入又如何进入财务管理。这个部门暴露的问题，是不能拿采购合同的字段和流程直接套科研合同。合同类型不同，发起依据、归口部门、审查重点和履约结果都会变化。
总务后勤和资产管理涉及的合同最杂。货物采购、工程施工、维修、物业、食堂、租赁和场地使用，看起来都归在后勤业务里，实际履约方式完全不同。我们问他们工程合同怎样按进度付款，验收材料由谁提供，质保金何时退，房屋和场地出租怎样收款，水电物业等长期服务怎样按周期确认，设备采购又要不要关联资产验收。这个部门提出的难题，让我们意识到“合同履约”不能只做一个完成按钮，工程进度款、分期验收、质保到期和租金催收都需要独立的节点。
教务、二级学院以及学生、继续教育、创新创业等业务部门，是合同真正的发起端。我们向他们问得最多的是日常操作：平时会签哪些合同，怎样判断该选什么类别和归口部门，发起前要准备哪些材料，最常用哪些模板，退回通常是因为缺字段、缺附件还是选错流程，校企合作、实习基地、培训和合作办学等合同与普通采购有什么不同。这些老师最真实的困难，往往不是审批按钮不好点，而是不知道一份合同从哪里发起、该选谁、该交什么。后来形成合同分类、发起引导、材料清单和差异化表单，源头就在这里。
党政办公室、印章和档案岗位关心的是合同审批完成以后的那一段。我们问合同编号什么时候确定，用哪一枚章、盖几份、谁能领走，审批通过的版本怎样与实际盖章版本保持一致，盖章扫描件由谁上传，纸质原件有几份、分给谁、什么时候归档，历史纸质合同怎样补录。对方提出的核心问题，是线上审批、线下盖章和纸质归档彼此断开。一旦最终签署文本被替换，前面所有线上审批记录都会失去意义。因此，用印记录、最终版本固化、线上线下双备案和合同副本借阅，后来都被写进了需求。
信息化部门的沟通最容易被产品经理拖到最后，但我们必须提前问。学校用什么统一身份认证，组织和人员数据由谁提供；采购、财务、科研分别有哪些接口，哪边是数据源；移动端依托什么平台；服务器、操作系统、数据库和网络环境是什么；系统是否必须本地部署；外部系统临时不可用时，合同业务能不能继续。信息化部门提出的问题不是“能不能对接”，而是对接什么数据、谁提供接口、同步失败怎么办。最终材料里明确的五类外部系统——统一身份认证、招标采购、财务、科研、办公及移动平台——就是在这一轮逐渐确定的。
最后还要问审计纪检。我们问他们查一份合同的时候通常从哪里开始，要看到哪些审批、变更、付款、用印和履约记录，哪些异常需要预警，审计发现问题以后怎样下达整改、跟踪和验收。这个部门要求的不是再增加一道普通审批，而是保证任何一步都能回头找到人、找到时间、找到当时的版本和依据。因此，操作日志、版本记录、异常预警、审计整改台账和供应商风险记录才有了明确的使用人。
把这一圈走完以后，我们才真正理解：高校合同需求不会从某一个人的嘴里完整出现。发起部门说的是操作困难，归口部门说的是管理规则，信息化部门说的是技术边界，审计纪检说的是追溯要求，最后由领导决定哪些冲突怎样取舍。每个人说的都可能是真的，但每个人说的都只是其中一部分。
从一堆谈话，到可以交付的六份成果
部门跑完并不等于需求调研完成。我们最初也吃过这个亏：大家聊得很热闹，回来以后笔记写了好几页，却很难直接放进需求文档。老师说“审批太慢”，这是一种感受；说“希望和财务系统打通”，这是一个方向；说“科研合同比较特殊”，只是提醒。它们都很重要，但都不能直接交给研发。
所以每走完一个部门，我们都要把内容整理成《分部门需求调研纪要》。这份纪要不能只写会议时间和参会人，还要保留部门负责的合同、现行办理过程、使用的表格和系统、原话提出的问题、提供的制度与样例、仍待确认的事项，以及谁有权确认。产品经理首先要保留原始事实，不能在会议结束后凭印象把对方的话改写成一个功能。
所有部门的纪要汇总以后，我们形成的第二份成果是《高校合同分类与归口表》。最终材料中共梳理出74种合同，分布在货物采购、服务采购、工程、科研、合作、人事学生、后勤、信息化与数据、知识产权、租赁场地等业务中。表里不能只有合同名称，还要继续记录发起部门、业务归口部门、是否有标准模板、发起所需材料、适用的审批规则和履约特点。学校原先也不知道全校究竟有多少种合同，这张表第一次把散落在各部门的合同放到了一张图上。
第三份成果是《角色与审批权限表》。我们把经办人、所在部门负责人、业务归口负责人、采购负责人、合同管理或法务岗、财务负责人、合同管理部门负责人、分管校领导、校长、审计纪检等十类角色逐一列出，记录每个角色在哪类合同中出现、能够查看什么、审批什么、能否退回或转办，以及人员变化后由谁维护。这样做，是为了把“找某某老师审批”变成“由某个岗位承担责任”，避免人员一换，流程就失效。
第四份成果是《系统接口清单》。统一身份认证解决登录、人员和组织；采购系统提供采购项目、中标供应商和中标结果；财务系统处理预算、付款与收款；科研系统提供项目和经费信息；办公及移动平台承接待办和消息。每个接口都要写清数据从哪边来、传哪些字段、何时同步、以谁为准、失败后是否允许手工补录，以及恢复后怎样核验。只写一句“与财务系统对接”，不算需求。
第五份成果是《需求问题与决策台账》。不同部门意见冲突时，我们不替学校私自拍板，而是记录问题来源、涉及部门、不同意见、对现有产品和项目范围的影响、需要谁决策以及最后的确认结果。业务事实由实际经办人说明，制度规则由归口部门确认，跨部门冲突和建设范围交给项目负责人或校领导决定。这样到了评审阶段，才能找到每条需求的来处。
前五份材料准备到一定程度以后，才有第六份成果，也就是后来形成的《高校合同管理系统采购需求书》。它不是第一次访谈时从老师嘴里直接问出来的，也不是产品经理关起门来写出来的。前面的部门纪要解决“大家说过什么”，分类归口表解决“学校到底管哪些合同”，角色权限表解决“谁负责什么”，接口清单解决“系统之间怎样交换数据”，问题决策台账解决“意见冲突以后听谁的”。这些内容继续被整理成功能范围、技术要求、接口要求、实施培训、运维服务和验收标准，才成为可以进入采购环节的正式技术需求。
这才是第一轮需求工作的完整产出链：部门谈话不是终点，会议纪要也不是需求文档。产品经理要把零散想法逐级加工成可追溯、可确认、可采购、也可验收的材料。
我们当时已经有一套可以运行的合同管理产品，所以后续工作不是从白纸上画一套所谓的“高校专用原型”，而是拿这六份成果与现有产品逐项比对：能够直接满足的保留，能够配置的配置，确实存在差异的再做少量定制。关系可以把我们带进学校，但只有把每个部门的话变成正式成果，才能把一次机会慢慢变成一个可以落地的项目。
下一篇，我会继续写我们怎样把这些调研问题做成真正可以交给部门老师的“需求调研卡片”：通用卡片有哪些栏目，采购、财务、科研、后勤、信息化等不同部门的卡片为什么不能一样，以及老师填回来的内容，怎样成为后续需求分析的第一批原始材料。
