项目价值落地方案：管理层开展项目立项的协同管理案例解析

2024年3月，我在一家年营收约120亿元的装备制造集团做项目治理复盘。这家集团2023年一共立项47个数字化与技改项目，走完了完整的立项评审流程：部门提报、IT部门初筛、财务测算、分管副总签字、总裁办公会表决，评审表上的签字一个不缺。但一年后我做价值回访时，能拿出证据说明”当初承诺的价值已经实现”的项目只有11个，占23%。剩下的36个项目里，有9个上线后没人用，有14个交付范围被改得面目全非，还有13个连当初承诺的是什么都说不清楚。

问题不在流程执行，而在流程设计：这套立项流程只审”要不要批这笔钱”，从来没有审”价值从哪里来、由谁来验证、什么条件下该停”。我后来把这套改造方法整理成了一版可复用的方案，也就是本文要拆解的项目价值落地方案，管理层开展项目立项的协同管理。它不是一套审批制度，而是一套让管理层、业务方、交付方在立项阶段就把价值假设对齐、把验证责任落到人头上的协同机制。

一、核心结论

先把结论摊开说。我在十几家不同规模企业里反复验证过下面四条判断，它们在制造、零售、金融科技和SaaS行业都成立，只是落地力度不同。如果你只读一段，就读这一段。

1. 立项协同管理真正要产出的，是三张可追踪的台账

绝大多数企业的立项管理只产出一个东西：一份签完字的立项报告。这份报告在归档那一刻就死亡了，因为没有人会在项目执行到第8个月时，翻出它来对照当下的现实。

真正有效的立项协同，产出的是三张活的台账。第一张是价值假设台账，记录每个项目声称的价值来源、量化口径、验证时间点。第二张是资源承诺台账，记录管理层批的到底是钱、是人，还是只批了一个”同意推进”的态度。第三张是假设验证台账，记录到约定时间点时，假设是成立、失效，还是需要修正。

这三张台账的价值不在于”管理规范”，而在于它们把立项从一次性事件变成了持续动作。项目一旦立项，假设就开始被跟踪，而不是等项目失败后再开会追责。

2. 决定立项质量的是评审会之前的那30天

我统计过自己参与过的86场立项评审会，结论有点反常识：一场立项评审会能改变最终决策的概率，不到15%。大部分评审会是在”确认一个已经谈好的结果”，而不是在”做判断”。

真正的判断发生在会前。谁去跟业务部门确认了价值口径，谁去跟财务对过收益测算的假设，谁去问过一线使用者”这个东西你愿不愿意每天打开一次”，这些动作决定了项目能不能站得住。评审会只是把它显性化。

所以立项协同的重点不是把评审会开得更长、更严肃，而是把会前30天的对齐动作结构化、留痕化、可追溯。

3. 管理层在立项里的角色是”约束条件的提供者”，不是审批开关

我见过太多管理层在立项会上做的事是：听5分钟汇报，问一句”这个要不要花这么多钱”，然后签字。这是把管理层当成了审批开关，用一次开或关来替代真正的管理动作。

管理层在立项阶段最有价值的贡献是三件事：给出资源约束的边界（今年研发人力就这么多，你自己算清楚要谁）、给出优先级排序的规则（战略项目可以在价值验证上宽松，效率项目必须算清账）、给出退出条件（什么信号出现时必须停下来重新评估）。

把这三件事说清楚，比批或不批一个项目重要得多。因为约束条件一旦明确，下级组织自己就能筛选掉大部分不该立项的项目，评审会的工作量会自然下降。

4. 唯一值得放进高管看板的过程指标是价值兑现率

立项通过率、立项数量、评审及时率这些指标都是”流程健康度”指标，它们可以很好，同时价值一塌糊涂。我服务过的一家企业，立项评审及时率连续四个季度100%，同期价值兑现率不到25%。

价值兑现率的定义是：项目上线并进入价值验证期后的约定时间点（通常是6或12个月），达到立项时承诺价值指标的项目数，除以已进入验证期的项目总数。这个指标难算、有争议、会得罪人，但它是唯一直接指向结果的指标。

二、背景和真实场景

要理解为什么立项协同会失效，得先看看它失效时的现场长什么样。下面这段是我在复盘会上听到的原话，我几乎是原样记下来的。

1. 一家制造集团的立项现场

这家集团的立项节奏是每年两次集中立项，分别在3月和9月。3月那次，IT部门从各业务线收集到63份项目需求，初筛后留下41份提交评审。评审会安排在一天半内完成，平均每个项目23分钟，其中业务方汇报8分钟，评委提问10分钟，剩下5分钟签字。

我旁听过其中一场。一个关于”设备预测性维护平台”的项目，汇报材料写了24页，核心价值描述是”降低非计划停机时间，提升设备综合效率”。评委问了三个问题：投入多少、周期多长、和去年那个设备管理项目什么关系。汇报人回答了投入和周期，第三个问题说”会有一定重叠，但侧重点不同”。然后全场通过了。

一年后我回访这个项目。平台上线了，接入了37台关键设备，但真正用起来的只有6台。我问业务方为什么不用，对方说：”当初说要降低非计划停机，但我们车间的停机原因一大半是换型等待和物料不到位，设备故障只占18%。这个平台解决的不是我们最大的问题。”

这不是执行问题，这是立项问题。在立项阶段，”非计划停机”这个价值假设从来没有被拆解过，也从来没有人问过”停机的主要成因是什么”。

2. 立项会上的三个典型信号

后来我把这类项目失败前的信号总结成了三个，出现任何一个，项目的价值兑现概率就会明显下降。

• 信号一：价值描述里没有数字。比如”提升协同效率””增强数据支撑能力””打造行业标杆”。这类表述无法验证，也无法追责，本质上是一种语言上的免责。
• 信号二：业务方只做”配合”不做”承诺”。汇报时业务部门说的是”我们会积极配合”，而不是”我们承诺在使用率达到X%后承接Y结果”。配合是态度，承诺是责任。
• 信号三：没有人问”如果它不成立会怎样”。整场评审没有任何人讨论退出条件或失败标准，说明这个项目在心理上已经被默许”必须成功”，而这恰恰意味着没有人在真正评估它。

这三个信号在评审材料里非常容易识别，识别成本低到只要看一眼价值描述那一段就够了。但它们极少被写成硬性检查项，因为写进去就意味着要否决一批项目。

3. 为什么”流程越完善，价值越模糊”

这是我观察到最反直觉的现象：一家企业的立项流程越规范、表单越完整、评审层级越多，它的价值兑现率往往越低。

原因不复杂。流程完善的动力通常来自风险规避，而不是价值创造。每增加一个审批节点，就增加一层”谁能免责”的考虑，于是立项材料的撰写目标从”说清楚价值”悄悄变成了”让每一级都挑不出毛病”。

结果就是材料越写越长、越写越安全、越写越空洞。我见过一份38页的立项报告，其中真正的价值论证不到两页，剩下的全是必要性、背景、行业趋势和风险应对。这种材料在评审会上是”无懈可击”的，因为它什么都没承诺。

三、常见误区拆解

讲完场景，我要拆四个我认为最致命、也最普遍的误区。这四个误区有个共同点：它们看起来都很合理，所以在企业内部几乎不会被质疑。

1. 把立项当预算审批

这是最普遍的一个。很多企业里”立项”和”预算申请”是同一件事，立项材料的核心章节是投入明细，评审的核心议题是”这笔钱该不该花”。

但预算只回答”资源是否可得”，不回答”资源投进去之后能不能产生回报”。一个项目可以预算极其合理、审批极其顺畅，同时价值假设完全站不住。把立项等同于预算审批，等于把管理动作停在了一半。

更麻烦的是，一旦立项等于预算，项目组的目标就会变成”让预算通过”，而不是”让价值成立”。这两件事在很多情况下方向是相反的，预算通过的最佳策略是把范围写大、把收益写高，而价值成立的最佳策略往往是把范围写小、先验证核心假设。

2. 用同一把尺子量四类项目

我见过最典型的做法是：所有项目都要填同一张表、回答同一组问题、走同一套评审层级。这在形式上很公平，在实质上很不公平。

战略型项目的价值本来就是长周期、难量化的，如果你要求它给出12个月的投资回报率，得到的一定是编出来的数字。合规型项目的价值是”避免处罚”，它的立项逻辑和效率型项目完全不同。探索型项目最大的价值是”快速证伪”，你用它有没有产生收益来考核，等于逼所有人不敢提探索项目。

下面这张表是我在不同企业实践后固定下来的分类口径，四类项目的立项深度差异很大。

这张表最实用的地方在于第三列。当业务方提报项目时，先让他自己选类型，然后只回答对应那一列的问题。我实践下来，仅仅这一步就能过滤掉大约三分之一的模糊项目，因为很多项目提报者根本说不清自己做的是哪一类。

3. 追求”可批性”而非”可验证性”

这是一个非常隐蔽的误区。”可批性”指的是材料写得让评委挑不出毛病，”可验证性”指的是价值假设能被真实数据检验。这两者的优化方向完全不同。

可批性的技巧是：引用行业趋势、堆砌必要性论述、把收益写得模糊但有想象力、把风险写得全面但都不致命。可验证性的要求是：给出具体基线数字、明确数据来源系统、指定验证时点、写清”如果达不到就怎样”。

我看过一份改造前后的同一个项目材料对比。改造前，效率价值写的是”预计提升整体运营效率约15%-20%”；改造后写的是”当前订单处理人均日处理量为42单（数据来源：ERP订单模块2024年3月均值），目标在系统上线6个月后达到58单，验证方式为ERP系统月度报表自动导出”。后者不一定能实现，但它在6个月后一定会有一个明确的对错。这就是差别。

4. 立项后没人回头验证假设

大部分企业的立项管理链条在”批准”那一刻就结束了，后面的动作归项目管理办公室或PMO，而PMO考核的是交付进度和预算执行，不是价值实现。

于是就出现了一个结构性空档：承诺价值的是业务方和IT方，交付管理的是PMO，最终承受结果的业务一线，但没有任何一个角色的KPI挂在”假设是否成立”上。

我后来在方案里加了一条硬机制：假设验证台账必须指定一个”价值责任人”，这个人是业务侧的管理者，不是项目经理。他不需要管交付，只需要在约定的时间点确认假设是否成立，并在不成立时给出处理意见。这条机制加进去之后，项目复盘会的质量立刻变了，因为终于有人要为假设说话。

四、专业判断逻辑

拆完误区，讲我实际使用的判断逻辑。这部分是整套方案的内核，也是我在不同企业里调整最多的部分。

1. 立项三问

我把立项阶段的判断压缩成三个问题。任何项目，如果这三个问题答不利索，就不应该进入正式评审。

第一问：价值从哪里来？不是”这个项目有什么用”，而是”它改变了哪一个具体的业务指标，这个指标当前的基线是多少”。答不出基线的项目，一律退回补充数据，不进入评审。这一条会遇到很大阻力，因为很多业务方确实拿不到基线数据，但恰恰是这种阻力暴露了项目本身的模糊性。

第二问：谁来验证，什么时候验证？要指定具体的人和时间点。不是”项目上线后评估”，而是”2025年3月由运营部负责人依据MES系统月度报表确认良品率是否从96.2%提升到97.5%”。

第三问：什么情况下应该停？这是最少被回答、也最有价值的一问。我给客户的模板里强制要求填写至少一条退出条件，比如”若上线6个月后日活使用率低于30%，暂停后续模块投入”。能写出退出条件的项目，往往在其价值逻辑上也想得更清楚。

2. 四类项目的立项深度分层

三问答完之后，还要根据项目类型决定投入多少立项成本。我见过两个极端：一种是对所有项目都要求完整论证，导致效率型项目立项周期长达两个月；另一种是对所有项目都走简化流程，导致战略型项目在没有任何对齐的情况下就启动了。

我的建议是分层。战略型项目必须做完整的价值假设卡加两轮管理层前置对齐，平均投入20人天是合理的；效率型项目做简化版价值假设卡加一轮业务财务联合确认，控制在8-10人天；合规型项目只需明确后果和成本上限；探索型项目走”轻立项”，一页纸，四周内给结论。

3. 协同的三个关键节点

协同管理不是”多开会”，而是把三个必须共同决策的节点固定下来。这三个节点如果不设，后面的所有协同都会变成救火。

1. 价值假设对齐会。参与人是业务方负责人、项目发起人、财务代表，产出是价值假设卡。这个会的核心议题只有一个：价值口径是否被三方共同认可。会议时长控制在90分钟以内，超过这个时间通常说明问题本身没有想清楚。
2. 资源承诺确认。参与人是管理层、人力或财务、项目发起人，产出是资源承诺台账。这个节点要明确的是”谁在什么时间段内投入多少”，而不是”我们会支持”。关键角色的名字必须写进去。
3. 假设验证回访。参与人是价值责任人、项目组、PMO，产出是假设验证结论。这个节点通常发生在立项后3个月、6个月和12个月，其中3个月那次最重要，因为它是最早能发现方向性错误的时点。

三个节点里，我认为最容易被省略、实际收益最大的是第一个。很多企业直接跳到第二个节点，结果就是管理层在确认一份自己都没看懂价值的资源承诺。

4. 用价值假设卡替代立项报告

我把传统立项报告压缩成了一张价值假设卡。这不是为了简化，而是为了让价值部分无法被稀释在一堆背景论述里。卡片的结构大致如下：

【价值假设卡 v2.1】
项目名称：车间设备预测性维护平台

项目类型：效率型

价值假设：非计划停机时长从月均 46 小时降至 32 小时

基线数据：46 小时/月（来源：设备管理台账 2024Q1 均值）

目标口径：月均 ≤32 小时，连续 3 个月达成

验证时点：上线后第 6 个月

价值责任人：设备管理部 张 X（非项目经理）

关键前提：停机成因中设备故障占比 ≥40%

（若实际占比低于 30%，本假设不成立，需重新定义价值）

资源承诺：设备部工程师 2 人 × 30%，IT 开发 3 人 × 60%

退出条件：上线 6 个月后，平台日活使用率 < 30%

待验证清单：

1. 停机成因分布是否已统计？（未完成，责任人：设备部）
2. 数据采集点位是否覆盖关键设备？（已完成 37/52 台）

这张卡最值得注意的两处设计：一是”关键前提”字段，二是”价值责任人不是项目经理”。前者把隐藏假设显性化了，后者把责任从交付方转移到了业务方。这两处改动在实践中的阻力最大，但收益也最大。

五、案例与数据观察

下面进入具体案例。这家集团的改造从2024年第二季度开始，到2025年第一季度完成了完整的一轮验证。企业名称和具体业务数据做了脱敏处理，但结构和口径是真实的。

1. 改造动作：从需求池到价值验证看板

改造不是从改制度开始的，而是从改承载工具的字段开始的。这一点很关键：如果制度和工具脱节，制度会在两周内退化回原来的样子。

他们做的第一个动作是把原来分散在邮件、Excel和 OA 里的项目需求池收敛到统一的研发项目管理平台上。这家集团有8000多名员工、IT与数字化团队180人，属于典型的中大型组织，同时因为涉及生产数据，集团对数据不出内网有明确要求。

他们最终选择的是 PingCode。选择理由有三条：一是支持私有化部署，满足数据不出内网的信创要求；二是能够承接他们此前使用 Jira 沉淀的存量项目数据，迁移过程中工作项、状态流转和权限关系基本平滑保留，不需要团队重新学习一套全新的操作习惯；三是面向中大型组织的研发管理场景，工作项类型、状态流、自定义字段的配置能力足够支撑价值假设卡这类非标准字段结构。对有信创清单要求的中大型企业来说，能同时满足私有化部署和 Jira 存量迁移的国产替代方案并不多，这是一个比较务实的选择。

具体落地时，他们做了四件事：

• 在需求池里新增”项目类型”和”价值假设”两个必填字段，不填无法流转到下一状态。
• 把价值假设卡的每个字段做成工作项属性，基线数据、验证时点、价值责任人都是结构化字段而非附件。
• 设置三个自动提醒节点，分别在立项后第90天、第180天、第365天推送给价值责任人。
• 把价值兑现情况做成一张看板，每个季度自动汇总，直接推送给总裁办公会。

四件事里，我认为最关键的是第二件。结构化字段和附件文档的区别在于，字段可以被统计、被筛选、被提醒，而附件只会被归档。很多企业做了价值假设卡，但存成了 Word 附件，结果三个月后没有任何人再去打开它。

2. 关键数据变化

改造前后的对比数据如下。需要说明的是，这些数据来自企业内部复盘口径，不同口径下会有几个百分点的差异，但方向是稳定的。

这张表里我最想让读者注意的不是价值兑现率，而是最后一行。改造后主动终止的项目从0变成了6个，这不是失败，这是整套机制在起作用的证据。一个只能立项、不能终止的组织，本质上没有在做管理，只是在做资源发放。

另外值得注意的是立项数下降了30%，但改制后的第二年，业务部门主动提报的有效需求反而增加了。原因是在旧的机制下，提报项目的人知道自己会被卡在评审上，所以倾向于一次报大、报全；在新的机制下，先立项验证核心假设、再追加投入成为常态，提报的心理门槛反而降低了。

3. 工具层怎么落地：为什么”结构化”比”自动化”更重要

这里我要说一个可能和主流观点不同的判断。在立项协同这件事上，工具的价值排序是：结构化 > 可追溯 > 自动化。很多企业一上来就追求自动化审批流，结果是把一个本来就有问题的流程自动化了，只是跑得更快。

结构化意味着每个关键判断都有对应的字段承载。比如”价值责任人”这个字段，如果它只是文档里的一句话，三个月后没人记得；如果它是工作项上必填的人员字段，并且系统会在第90天自动把提醒推送给这个人，那它就变成了一个真实的管理约束。

可追溯意味着任何一次价值口径的修改都留下记录。我做复盘时最常遇到的问题就是”当初说的是另一个指标”，有了变更记录之后，这类争论会大幅减少。

自动化放在最后，是因为它解决的是效率问题而不是有效性问题。一个有效的机制哪怕手动跑三个月也是有效的，一个无效的机制自动化之后只会更快地产生无效结果。

六、不同情况下的行动建议

这套方案不能照搬，不同规模的组织有完全不同的约束。我按员工规模给出四档建议，你可以直接对应自己的情况。

1. 100人以下组织

这个规模的企业不需要设立专门的价值假设台账系统。你需要的是让创始人或核心管理层在每次项目启动前，问出那三个问题并记录答案。记录形式可以是共享文档，关键是要有人问、有记录。

资源上也别投入太多。四个人天的立项对齐成本对这个规模的组织来说已经偏高，建议压缩到一人天以内：一次60分钟的会，一张纸的价值假设，一次口头确认的验证时点。

工具方面，这个规模不建议上重型研发管理平台，用现有的协作工具加一个固定模板就够了。过度工具化会消耗掉本就不多的人力。

2. 100-500人组织

这是最容易出现”制度空转”的区间。组织已经有了一定的流程意识，但还没有专职的PMO。我的建议是先做一件事：把立项材料从”报告”改成”卡片”，强制压缩到一页。

这个规模的组织开始需要工具承载了。需求池、立项状态、验证时点这些字段如果没有系统承载，纯靠人工跟踪，通常在第三个月就会断掉。选择工具时优先看两件事：字段能否自定义、提醒能否按时间自动触发。

治理节奏上，建议每季度做一次假设验证回访，不需要每月，但必须固定。回访会议控制在两小时以内，只讨论假设是否成立，不讨论交付进度。

3. 500-2000人组织

这个规模通常有专职PMO或项目管理岗，可以让机制真正跑起来。建议做三件事：建立四类项目的分类标准并写进制度；把价值假设卡做成系统里的结构化工作项；指定价值责任人制度并纳入业务部门管理者的年度考核。

第三件事最难推。业务部门管理者通常会认为自己只对业务结果负责，不对项目假设负责。但恰恰相反，价值假设本来就是业务假设，业务方才是假设的所有者，IT或交付方只是实现者。这个认知不扭转，整套机制就会一直悬空。

工具选型上，这个规模开始需要考虑私有化部署和数据主权问题。如果涉及财务、生产或客户数据，建议优先考虑支持私有化部署的平台，同时评估从现有国外工具迁移的成本。这里要提醒一点：迁移成本不只是数据搬运，还包括团队操作习惯的迁移，所以平滑迁移能力应该作为选型的硬指标而不是加分项。

4. 2000人以上或集团型组织

这个规模的核心问题不是流程，而是分级授权。集团层面管什么、事业部管什么，必须切清楚。我的建议是集团只管两类项目：跨事业部资源协调的项目，和金额超过特定阈值的项目。其他项目一律下放，由事业部按统一的价值假设标准自行立项和验证。

集团层面要做的不是审批，而是建立标准、做抽查和汇总。每年抽检不低于20%的项目，检查价值假设的质量和验证回访的真实性。抽检结果不直接处罚，但要在集团层面公布部门维度的价值兑现率。

这个规模的企业往往已经有多个业务系统和管理工具，此时选型要考虑集成能力。支持私有化部署、具备开放接口、能够与现有系统做数据打通，通常比功能多寡更重要。

七、不同情况下的取舍

做这套方案最难的不是”做什么”，而是”在哪里让步”。我把最常被问到的四组取舍单独拎出来讲。

1. 立项速度 vs 立项深度

这是一组真实冲突。集团那家企业的立项周期从31天缩短到18天，看起来是提速了，但实际上会前对齐的投入是增加的，减少的是”材料返工”和”评审等待”的时间。

我的判断是：会前的时间不能省，会上的时间可以省。省会前时间的代价是几个月后的返工，成本高得多。省会上时间的代价通常只是评委少问几个问题，风险可控。

如果你只能在两者间选一个，选深度。一个走得慢但走对的立项，比一个走得快但走错的立项，总成本低很多。

2. 统一模板 vs 分类模板

统一模板的好处是容易推广、便于汇总；分类模板的好处是贴合实际、减少无效填写。我的经验是在组织成熟度较低时用统一模板，成熟后再分类。

原因很现实：一开始就分类，业务方会倾向于把自己往”要求最宽松”的那一类里塞。等大家对价值假设这件事本身建立了认知，分类才不会被滥用。

一个折中的做法是：前期用统一模板，但只在字段必填程度上做区分。比如探索型项目的”目标口径”字段允许填”待明确”，但必须写明证明周期；效率型项目则强制要求基线数字。

3. 工具先行 vs 机制先行

我见过两种失败：一种是把流程全部上线到工具里，结果没人用；另一种是在文档里写了厚厚一本制度，结果三个月后没人记得。

我的建议是：机制先想清楚，工具先落最小闭环。不要等制度全部定稿再上工具，也不要指望上了工具机制就会自然形成。最小闭环就是”价值假设卡 + 三个自动提醒 + 一张汇总看板”，这三件事能在两周内配置完成，先跑起来再看效果。

工具选型时有一条经验：优先选择字段配置能力强、能快速迭代的产品，而不是功能最全的产品。因为你的价值假设卡模板一定会在前三次使用中反复修改，改不动的工具会直接把机制拖死。

4. 强管控 vs 授权自治

强管控的好处是标准统一，坏处是审批积压和形式主义；授权自治的好处是响应快，坏处是标准漂移。

我的判断基于一个观察：当组织的价值假设能力尚未建立时，强管控是必要的，但要以”抽查”代替”审批”。因为审批只能看出材料是否完整，看不出假设是否成立；抽查则是事后对真实结果的检验，反而更能形成约束。

等到连续两年的价值兑现率稳定在50%以上，就可以逐步下放立项权限。此时业务部门已经形成了对价值假设的基本判断力，不需要每一单都过集团评审。

八、结论与下一步

回到开头那个数字：47个项目，只有11个能说清价值。这个结果不是执行团队不努力，而是整个立项机制在设计上就默许了这种结果。

1. 三个反常识结论

第一，立项的价值不在于”批得准”，而在于”追得动”。没有任何评审机制能保证一个项目一定成功，但一个能追踪假设的机制可以保证错误在三个月内被发现，而不是一年后。

第二，立项数量下降不一定意味着保守，可能是前置过滤在起作用。该集团立项数下降30%的同时价值兑现率提升38个百分点，这组反向数据是我认为最值得写进高管汇报的一页。

第三，管理层的项目管理工作量不一定增加，只是位置变了。从”会上的审批者”变成”会前的约束条件提供者”，总时长甚至略降，但作用的有效性完全不同。

2. 你下周可以先做的三件事

不要一次性推行整套方案。我在每家企业都是从下面三件事开始，两周内就能看到变化。

1. 挑一个正在准备立项的项目，用三问过一遍。问它的基线数据、验证责任人、退出条件。如果三个问题有两个答不上来，这就是你最好的改造切入点。
2. 把下一次立项评审会的材料模板改成一页价值假设卡。不要先改制度，先改模板。模板变了，汇报的内容自然就变了。
3. 在你的研发管理工具里，为项目工作项加上”价值责任人”和”验证时点”两个字段，并设为必填。如果工具不支持自定义字段，这本身就是一个需要解决的选型问题。

做完这三件事，你会得到一批”答不上来”的项目和一批”答得上来”的项目。把资源按这个区分来分配，价值的落地就已经开始发生了。剩下的，就是把上面这套协同机制固化成流程和字段，让它在你换人、换项目、换年度之后依然能跑下去。