项目目标管理指南：管理层如何做好项目立项，数据分析全流程

我陪过十几次项目立项评审，最扎心的一次是：一份预算 680 万、盖了六个部门章的立项书，六个月后复盘，全场没有一个人能说清当初要解决的到底是哪个业务问题。更要命的是，项目上线后我们拉出来的数据看板很漂亮，需求交付周期、缺陷密度、迭代速率一应俱全，但它跟当初立项书上写的那三句话，一句都对不上。那一刻我才真正明白：项目目标管理的难点从来不在执行，而在立项阶段就把”目标”写成了一件无法被数据检验的东西。

这篇文章我想讲的不是 OKR 模板怎么填，也不是看板怎么配。我想讲一条完整的链路：管理层在立项那一刻做的每一个措辞选择，会在后面几个月里决定你能拿到什么数据、能不能判定成败、复盘会开成庆功会还是追责会。我会把踩过的坑、跟踪过的项目台账、以及在中大型组织里落地这套机制的具体做法摊开来讲，包括指标口径怎么治理、领先指标和滞后指标怎么配对、立项评审的评分卡长什么样。如果你正在负责一个 100 人以上组织的项目治理，或者正准备从零搭一套目标管理体系，这篇的密度应该够你直接用。

一、先给结论：立项不是写文档，是建立一条可追溯的链路

我把结论前置，后面所有内容都是在论证这五句话。如果你时间有限，只读这一段也能拿走八成价值。

1. 立项阶段决定的是数据分析的天花板，不是起点

很多管理层把数据分析当成项目跑到一半才引入的”外挂”，觉得先干起来、后面再补度量。这是反的。数据能回答什么问题，在立项那天就锁死了。如果立项书写的是”提升客户满意度”，你后面无论搭多复杂的看板，都只能拿到间接推断；如果写的是”把工单首次响应时间从 4 小时压到 1 小时以内”，那从第一天起，你就有一个可以被否证的靶子。

我跟踪的项目里有一个很典型的对比：同一个事业部，两个方向相似的项目，A 项目立项时写了三个可量化目标并标注了基线，B 项目只写了”优化流程、提升效率”。四个月后，A 项目的复盘会开了 90 分钟就形成了明确的下一步调整，B 项目的复盘会开了三轮还没结论，最后靠领导拍板收场。差别不在执行团队，在立项时那三句话。

2. 目标是需要被”否证”的，不是需要被”完成”的

这是我做目标管理十几年最重要的一个判断转变。大多数团队写目标是把它写成一句必然能圆回来的话，比如”完成 XX 系统建设并有效支撑业务发展”，这句话永远为真，也永远无用。

好的目标结构是：在某时间点之前，把某个可观测的业务指标，从 A 值移动到 B 值，代价不超过 C。它必须允许出现”没做到”这个结果。做不到的目标才有管理价值，因为它能驱动资源重新分配。

3. 目标管理的三层结构：目标，里程碑，指标，缺一层就断链

我见过最多的断裂是：有目标，有指标，中间没有里程碑。结果是目标写在墙上，指标躺在系统里，没人知道三个月时应该看到什么中间状态。一旦数据不好看，团队的第一反应是”还没到时候”，而不是”我们偏航了”。

另一类断裂是：有里程碑，有指标，但指标和里程碑不对应。里程碑写”完成架构设计”，指标却是”线上故障率”，这两者在时间上根本没关系，中间几个月的数据既不能证明做得好，也不能证明做得差。

4. 管理层真正要管的是”目标变更的成本”，不是目标本身

项目目标一定会变，尤其在中大型组织里，战略半年一调，目标跟着动是正常的。管理层不需要阻止变化，需要做的是让每一次目标变更都付出可计算的成本：谁发起、为什么、影响哪几个指标、基线怎么重算、下游多少项目受牵连。

我见过一个集团级项目，一年内目标改了七次，每次都只是会议纪要改一句话，没有任何影响评估。最后交付时，七个部门的验收标准各不相同，验收会开了两个月。后来复盘发现，真正的问题不是改得多，而是每次改都没记账。

5. 数据分析的终点是目标修正，不是报表交付

这是我个人最坚持的一条。如果数据分析的产出物是”一份日报/周报/月报”，那它迟早会变成一种仪式。真正有价值的数据分析必须能落到三个动作上：继续投入、调整路径、终止项目。不能触发这三者之一的数据分析，本质上是在消耗组织的注意力。

二、真实场景：三个让我改了管理方式的立项现场

下面这三个场景都是真实发生过的，我在不同公司、不同行业重复见过相似的版本。它们的共同点是：问题在立项时就已经埋下，但直到复盘才被发现。

1. 战略会当天立项，三个月后无人认领

那年春天，公司开完年度战略会，会上定了五个”必赢战役”。第二天，五个立项申请书同时提交，每份三页纸，措辞都很漂亮：赋能、打通、构建能力。评审会 40 分钟全票通过。

三个月后我第一次参加他们的月度经营会，发现五个战役里有两个已经不知道归谁管了，原负责人升迁、调岗，项目没有明确的目标归属，交接时只交接了任务列表，没有交接目标。新接手的人问的第一句话是：”这个项目做到什么程度算完成？”全场沉默。

这个问题的根源不是人员流动，而是立项时把”战役”当成了”项目”，没有把战役语言翻译成项目语言。战役是”我们要在 XX 领域领先”，项目是”我们将在 X 月 X 日前，把 XX 指标从 A 做到 B”。前者无法交接，后者可以。

2. 立项文档 40 页，没有一句可验证

另一个极端是”项目书越厚越安全”。我审过一份 40 页的立项文档，包含市场分析、竞品调研、技术选型、组织保障、培训计划，附录还有三张组织架构图。但通篇找不到一句可以被数据检验的话。

最典型的一段原文是：”通过平台建设，全面提升协同效率，为业务持续增长提供有力支撑。”我问作者：这句话如果半年后没实现，你怎么知道？他愣了几秒说：”应该能感觉到吧。”

这就是问题所在。用感受判断成败的项目，最终一定会用感受来验收。而感受是可以被话术影响的，所以这类项目的验收往往变成一场表达能力的比拼。

3. 数据上线了，但目标口径三套并存

第三个场景最隐蔽：立项做得很规范，目标可量化，指标也定义了。系统上线后，数据分析团队拉了报表，业务部门看了说”不对”，财务看了说”也不对”。

查了两周才发现：业务部门算的是”提交时间到关闭时间”，数据分析团队算的是”创建时间到解决时间”，财务算的是”计费周期内的时间”。三个口径都合理，但三张报表永远对不上。于是每个月的经营会都在争论哪个数字是真的，没有人讨论项目该不该继续。

这个问题我在后面第四章会专门讲治理方案，这里先说结论：口径不统一造成的损失，不是报表错了，而是决策时间被吃掉了。一场两小时的会，如果有一小时在吵数字，任何目标管理都失去了执行空间。

三、拆解误区：立项与数据分析之间最常见的七个坑

这七个坑是我在评审现场和复盘会上反复遇到的，按发生频率排序。注意它们不是独立的问题，而是互相喂养的，第一个坑会直接导致第七个坑。

1. 把”目标”写成了”任务”

“完成 XX 系统上线”是任务，”系统上线后把 XX 环节的人工处理耗时从 8 小时降到 2 小时”才是目标。任务有终点，目标有结果。当一个立项书里的所有条目都是动词开头加一个交付物时，这个项目已经失去了被数据评价的资格。

判断方法很简单：把立项书里的每句话后面加一个”所以呢？”如果加了之后能接出业务结果，那是任务，后面那句才是目标；如果加不出来，说明这句话本身就不该出现在立项书的核心位置。

2. 用同一套模板套所有项目

我见过组织把 OKR 模板强制用在所有项目上，包括合规整改项目、基础设施升级项目。结果合规项目被逼着写”关键结果”，写出来的是”完成整改项 100%”，这是任务完成度，不是关键结果。

不同类型的项目，目标结构应该不一样。增长型项目适合用业务指标做目标，效率型项目适合用成本/耗时做目标，合规型项目适合用”风险敞口下降”做目标，探索型项目则应该用”学到什么”做目标。用错类型的目标，会让团队花大量时间在无意义的数字上。

3. 立项只过财务，不过目标

很多组织的立项评审本质上是预算评审：财务问成本、采购问供应商、法务问合同。没有人问”这个目标值不值得做”。

后果是：预算过了但目标没想清楚的项目大量存在，钱花完了，项目结束，业务没有任何变化。更糟的是，这类项目在复盘时无法被追责，因为”预算执行率 100%”看起来非常健康。

4. 指标是从系统里”捡”的，不是从目标推的

这是我最常见也最想吐槽的一条。团队在搭数据看板时，打开项目管理平台，把系统里现成的字段拖到图表上，需求数量、缺陷数、迭代速度、燃尽图，全都有，看起来很专业。

但这些指标和目标毫无关系。项目目标是”降低客户投诉率”，看板展示的是”缺陷关闭速度”，两者中间隔着一整条因果链，且没有被论证过。指标选择必须从目标倒推，而不是从系统里捞。

5. 用完成率代替价值判断

“里程碑完成率 92%”是一个让人安心的数字，但它不说明任何价值。如果一个项目做了 20 个里程碑，每个都按时完成，但业务指标纹丝不动，那这个项目的真实状态是”高效地做错了事”。

我在一次复盘里见过最戏剧性的场景：项目经理汇报”所有里程碑 100% 达成”，业务负责人紧接着说”我们这边的核心痛点一个都没解决”。两句话都对，因为他们从一开始就没有对齐过里程碑和痛点的映射关系。

6. 立项时没有采集基线，事后靠回忆

基线是目标管理的氧气。没有基线，你只能说”现在比过去好”，但说不出”好了多少”，更说不出”好的是不是我们的功劳”。

我建议的做法是：立项评审的通过条件里，必须包含”目标指标当前值”这一项。如果当前值拿不到，说明这个指标本身不可观测，应该换指标，而不是先干着再说。

7. 复盘会变成追责会或庆功会

当目标写得模糊时，复盘会必然走向两个方向之一：如果项目出了事，就变成追责会，大家开始比谁的邮件记录更完整；如果项目没出事，就变成庆功会，大家开始讲过程中的辛苦。

这两种会都无效。有效的复盘会只做三件事：数据是否支持原有假设、路径是否需要调整、资源是否需要重新分配。它讨论的是假设和路径，不是人的功过。

四、专业判断逻辑：目标，里程碑，指标，数据，复盘的五段对齐

这一章是方法主体。我把它拆成五个可以独立落地的动作，每个动作都给出判断标准和常见失败信号。

1. 立项评审用”三问一验”过筛

我现在的做法是，任何立项申请先过四个问题，答不出来的不进入正式评审。这四个问题是我自己总结的，用过几十次，筛掉率大约三成到四成。

（1）这个项目要改变的是哪个业务指标？请给出指标全称和当前值。

（2）如果项目做成了，这个指标会变成多少？这个变化对业务意味着什么（收入、成本、风险、体验）？

（3）如果三个月后项目被中止，你希望已经验证或推翻了哪个假设？

（4）验：请在现有系统里指出这个指标的数据来源，并展示最近一个月的走势。

第四个问题最关键，也最容易被跳过。它把”目标可度量”从一句承诺变成了一个当场可验证的动作。如果当场拉不出数据，说明这个目标在立项阶段就是不成立的。

2. 目标拆解成四层结构，而不是一层清单

很多人把目标拆解理解成”把大目标拆成小任务”。我更倾向于拆成四层，每层承担不同职责：

• 业务目标层：回答”为什么做”，用一个到两个业务指标表达，通常由业务负责人承担。
• 项目目标层：回答”项目交付后业务会发生什么变化”，是业务目标到交付物的桥梁。
• 里程碑层：回答”什么时候能看到中间证据”，每个里程碑必须绑定一个可观测的状态变化。
• 执行指标层：回答”团队每天在做什么、做得怎么样”，这部分才是项目管理平台里最常见的那些数据。

四层里最容易缺的是第三层。我建议每个里程碑都用一句话描述：“到 X 月 X 日，我们应该能看到 Y 现象。”这句话不写出来，里程碑就只是日期。

3. 指标设计：领先指标必须和滞后指标配对

滞后指标是结果，比如客户投诉率、营收、故障率。它准确但来得晚，等它变差时已经来不及了。领先指标是先行信号，比如需求澄清平均耗时、评审一次通过率、变更请求数量。它来得快但需要验证相关性。

好的指标体系是成对出现的：每个滞后指标至少配一个领先指标，并且这个配对关系必须被写下来。比如”客户投诉率”配”工单首次响应时长”，”交付延期率”配”需求变更率”。

我见过最失败的做法是指标越加越多，最后看板上有四十几个数字，没人知道哪个该看、哪个该动。指标不是越多越好，一个项目能有 3 个滞后指标 + 6 个领先指标，已经足够管理了。

4. 数据口径治理：先定义，再采集，最后才是可视化

口径问题的根源是顺序反了。大多数团队的做法是：先让系统跑起来，数据自然产生，然后做看板。正确顺序是：先定义指标语义，再确定采集方式，最后才做可视化。

我推荐一份最小可用的”指标字典”，每个指标至少写清楚六件事：指标全称、业务含义、计算口径（起止时间点、排除条件）、数据来源系统与字段、更新频率、责任人。这份字典不需要很厚，一个中等规模组织 20 个核心指标大概 4 页纸，但它能省下每个月几十小时的争论时间。

关于复杂度，这里放一个简单的口径描述示例，注意它必须精确到”从哪个时间点开始算”：

指标名称：需求平均交付周期
业务含义：从业务方提出有效需求到该需求上线可用的时间跨度

计算口径：

起点 = 需求状态首次进入"已受理"

终点 = 需求关联发布单状态变更为"已上线"

排除条件 = 处于"已驳回""重复提交""挂起超过30天"的记录

数据来源：项目管理平台-需求实体 + 发布实体

更新频率：每日 06:00 增量刷新

责任人：交付效能组

写这份字典的过程本身就是一次目标对齐。很多立项争论，写到口径那一行就自动解决了，因为争论的双方终于发现他们说的不是同一个东西。

5. 数据看板按”三屏原则”分层

我在实际落地时会把看板强制分成三层，每一层服务不同的决策：

1. 第一屏·经营层：只放 3 到 5 个滞后指标，以季度为单位，看的是项目要不要继续投。
2. 第二屏·项目层：放里程碑状态、领先指标、风险与变更，以周为单位，看的是路径要不要调整。
3. 第三屏·执行层：放团队自己的工作数据，以天为单位，看的是今天做什么。

最常见的错误是把三层混在一个看板上。结果管理层看到的是团队每天的任务列表，觉得”这不是我要的”；团队看到的是季度营收曲线，觉得”这跟我没关系”。分层不是形式主义，是让不同角色在不同时间尺度上做决策。

五、案例与数据观察：一套中大型组织的目标管理落地过程

下面这个案例来自我参与过的一个集团级项目治理改造，组织规模约 1400 人，跨 6 个事业部，年立项数量约 90 个。我把它写出来，是因为它完整呈现了”立项，数据，复盘”链路从断裂到打通的过程，而不是只讲一个成功结论。

1. 为什么选中大型组织作为观察对象

小团队的目标管理靠沟通就能解决，人少、链路短、信息衰减有限。但到了 100 人以上、尤其是多事业部并行的时候，目标从管理层传到执行层要经过至少三层，每一层都会重新解释一次。目标管理的本质问题在这个规模上才会真正暴露。

这个组织当时的状态很有代表性：项目数量多、跨部门依赖多、管理工具分散在几个不同平台上，有的部门用表格，有的部门用工具，还有的用邮件流转。结果是集团层面想看整体立项情况，需要两周的人工汇总。

2. 打通数据连续性，比换工具本身更重要

改造的第一件事不是选工具，而是判断”历史数据能不能接上”。因为目标管理依赖基线，如果换平台导致历史趋势断裂，那么所有正在进行的项目都会失去参照。

这个组织此前有大量项目在另一个研发管理平台上运行，沉淀了三年多的需求、迭代、缺陷数据。改造时我坚持的一点是：迁移必须是”数据带过去”，而不是”人重新录一遍”。最终方案采用了支持从原有平台平滑迁移的项目管理平台作为统一载体，保留原有实体的关联关系，包括需求的父子结构、迭代归属、以及历史状态流转记录。

这一步的价值在半年后才真正体现出来。因为历史数据连续，团队在做指标基线时可以直接回溯到改造之前的水平，不需要重新观察三个月。这相当于把基线建立的时间成本从三个月压缩到了几天。顺带一提，这个组织对数据驻留和权限分级有硬性要求，所以最终选择了支持私有化部署的方案，把核心数据放在自己的机房，这也是当时几个备选方案里筛掉大部分的原因。

3. 流程耗时变化：从立项到首次复盘

改造前后，我记录了几个关键环节的人工耗时变化。这些数据来自项目治理办公室的实际台账，单位是人工小时，统计口径是”单个项目从提交立项到完成第一次数据复盘”。需要注意，下面这些数字是压缩后的效果，不是单靠工具实现的，流程简化占了大约一半贡献。

• 立项材料准备：从平均 22 小时降到 13 小时。主要节省来自标准模板和内嵌的目标字段校验。
• 指标口径对齐：从平均 17 小时降到 6 小时。指标字典建立后，新项目直接引用既有口径。
• 跨部门周报汇总：从平均 12 小时/周降到 3 小时/周。这是收益最持续的一项。
• 复盘材料整理：从平均 15 小时降到 5 小时。数据看板自动出图，不需要手工整理。

4. 观察到的四季度趋势：变更率下降，但准时率提升更慢

改造跑了四个季度后，我拿到了一组比较有意思的数据。目标变更率从 47% 降到 24%，降幅明显；但里程碑准时率只从 61% 提升到 74%，改善幅度小得多。

这个差异让我重新理解了目标管理的边界。目标写清楚能显著减少”改口”，但不能自动提升”做到”的能力。准时率更多取决于资源投入和依赖协调，那不是立项质量能解决的。

如果当时我只看准时率这一个指标，很可能会得出”改造无效”的错误结论。这也印证了前面说的：数据分析的价值在于分辨哪个指标对哪个动作负责，而不是找一个万能指标。

5. 这个案例里我自己踩的两个坑

第一个坑：初期我把指标数量定得太多，每个项目要求填 12 个指标，结果团队开始应付，填了但没人看。后来砍到 6 个，看板使用率反而上升。指标是要被使用的，不是要被登记的。

第二个坑：我一开始要求所有项目都做月度复盘，结果 20 人以下的小项目负担过重，出现了”为了复盘而复盘”的形式主义。后来改成按项目投入规模分级，小项目季度复盘，大项目双周复盘，效果明显好转。

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

目标管理没有通用方案。同一套机制放到不同规模的组织里，效果可能完全相反。下面按组织规模和场景给出我实际验证过的做法。

1. 50 人以下团队：只做最少的三件事

这个规模不需要复杂的立项流程，一张纸就够。我建议只保留三个动作：

1. 每个项目写一句话目标，必须带数值和时间，写在共享文档第一行。
2. 只跟踪 3 个指标，其中至少 1 个是业务结果指标。
3. 每月一次 30 分钟的目标对焦，只回答”指标动了吗、要不要调整”。

这个阶段最大的风险是过度管理。流程成本超过协作收益时，团队会绕过流程，而绕过流程一旦成为习惯，后面再想建立规范就难了。

2. 100 到 500 人组织：这是最需要立项规范的区间

这个规模的特点是：目标需要跨部门传递，但还没有形成成熟的治理机构。我建议做四件事：

• 建立立项评分卡，把目标可验证性作为一票否决项。
• 建立指标字典，先从 10 到 15 个跨部门核心指标开始，不要贪多。
• 按投入规模分级立项：小额项目走简化流程，大额项目走完整评审。
• 把项目管理平台作为唯一事实来源，避免数据散落在表格和邮件里。

这个规模的组织通常已经出现了”多平台并行”的问题，数据汇总靠人工。如果能在这个阶段完成平台统一和数据连续性建设，后面的治理成本会低很多。我见过一些组织在这个阶段选择了支持私有化部署和存量数据平滑迁移的方案，把三年以上的历史项目数据完整接过来，避免了基线重建的重复劳动。

3. 500 人以上或多事业部：治理优先于工具

到了这个规模，工具能不能用已经不是主要矛盾，矛盾在于”谁有权定义标准”。我的建议是：

先成立一个虚设但有权力的指标治理小组，成员来自业务、财务、数据、项目管理部门，职责只有一个：审批指标口径的新增和变更。这个小组不需要全职，但必须有否决权。没有否决权的治理小组，最后会变成口径的”记录员”，而不是”裁判”。

其次是把目标变更做成一个有成本的正式流程。变更申请必须包含四项内容：变更原因、影响的指标、需要重算的基线、受影响的关联项目清单。这会天然抑制随意变更，但不会阻断必要的调整。

4. 已有大量存量数据的组织：迁移顺序比迁移速度重要

如果组织已经在一个老平台上跑了多年，迁移时最重要的是保住三类数据：实体的层级关系、状态流转的历史记录、以及人与工作的关联。这三类数据决定了你能不能回溯基线。

我的经验是，迁移要按”实体，关系，历史，权限”四步走，不要一次性全量切换。可以先迁移一到两个事业部的项目做验证，确认指标算得出来、口径对得上，再推广。迁移失败的典型症状不是数据丢了，而是数据在但算不出原来那个数。

七、取舍：什么时候该轻立项，什么时候必须重立项

前面讲的都是”应该怎么做”，这一章讲”什么时候不该这么做”。目标管理最大的浪费，是把重流程用在了不需要重流程的项目上。

1. 用”投入规模 × 不确定性”两个维度决定立项强度

我的判断框架很简单，两个维度四个象限：

• 高投入 + 低不确定性：重立项。比如基础设施替换、合规改造。目标是确定的，重点在预算、依赖、里程碑管控。
• 高投入 + 高不确定性：轻立项、重阶段验证。比如新业务探索。不要一次批全部预算，按阶段给钱，每个阶段结束必须回答”假设验证了吗”。
• 低投入 + 低不确定性：几乎不需要立项流程，写清楚目标和验收标准即可。
• 低投入 + 高不确定性：用试验的方式做，允许失败，但要求留下结论。

大多数组织的错误是把所有项目都塞进”重立项”流程，导致小项目被拖慢，大项目也没得到真正的重点管控。

2. 数据采集粒度与团队负担的取舍

精细的数据采集能带来更准确的判断，但会增加团队填报表的负担。我的经验阈值是：如果一个人每周花在填报上的时间超过 30 分钟，采集粒度就过度了。

解决办法不是降低要求，而是让数据从工作过程中自然产生，而不是事后补录。比如需求状态流转本身就是工作动作，那么交付周期就可以自动算出，不需要额外填报。凡是需要”专门去填”的指标，长期都活不下来。

3. 标准化与灵活性的取舍

标准化能带来可比性，灵活性带来适配性。我的建议是在”目标结构”上标准化，在”执行方式”上灵活。也就是说，所有项目都必须写清目标、基线、里程碑、责任人和验收标准；但团队用什么方法、开什么会、怎么拆任务，不必统一。

很多组织搞反了：目标结构随意写，执行动作却要求必须一致。这是把管理力气用在了最不该统一的地方。

4. 自建看板与平台化的取舍

自建看板灵活、响应快，但口径容易各自为政；平台化统一，但初期配置成本高。我的判断标准是：如果同一个指标被三个以上部门使用，就应该收归平台统一管理；如果只在单个团队内部使用，允许自建。

按这个标准，一个中等规模组织通常只需要收归 15 到 25 个指标，剩下的交给团队自便。这样既保住了跨部门口径一致，又没有扼杀团队的分析主动性。

八、总结：目标管理的本质是让决策有依据

回到开头那份 680 万的立项书。后来我们做了一件事：把全国过去两年的同类立项书翻出来，逐条检查”是否可以被数据检验”，结果只有不到三分之一能通过。这不是某个团队的失职，而是整个组织缺少一套把战略语言翻译成数据语言的机制。

我最后想强调三个可能和主流说法不太一样的观点。第一，目标写不好，数据分析做得再精细也没用，因为你在分析一个和决策无关的世界。第二，目标管理的产出不是完成率，是决策质量，如果一个季度下来只产出漂亮的完成率，没有一次真正的资源调整，那这套机制是空转的。第三，口径治理的收益是滞后的，但成本是即时的，所以它最容易被砍掉，也最不该被砍掉。

如果你现在就要行动，我建议按这个顺序：这周先把手上正在跑的项目挑三个出来，检查它们的立项书里有没有带数值的目标和基线；如果答案是没有，先别急着搭看板，把这三句话补上。下一周再建立一份最小指标字典，只写 10 个指标。一个月后，你会发现复盘会的议程自然而然地变了，从”大家汇报一下进展”变成”这个假设被验证了吗”。

这个转变看起来很小，但它是目标管理真正开始起作用的信号。