状态怎么做？跨部门团队入门指南：任务属性从0到1

我给不少跨部门团队做过项目管理平台的落地咨询，最常被低估的一个字段，就是状态。很多团队在立项会上花两小时讨论优先级怎么定、标签怎么打，却在状态这一栏五分钟就拍板："就待办、进行中、已完成吧。"结果上线三个月后，产品经理在群里问"这个需求到底算不算做完了"，研发说"我提测了"，测试说"我还没验"，运营说"我看板上写着已完成"，三个部门，三个答案，同一张卡片。

这篇文章不讲概念，讲的是我实际做过的事情：怎么从零开始，给一个跨部门团队设计一套能活过一年的状态体系，以及状态这个属性在整个任务属性体系里到底该放在什么位置。我会用真实的失败案例、可复现的推演数据，以及在一线平台上验证过的配置方式，把"状态怎么做"这件事拆到底。

一、先把结论说透：状态不是进度条，是一份责任交接契约

如果这篇文章你只读一段，请读这一段。跨部门团队里，状态的真正价值不在于描述"这件事做到哪一步了"，而在于回答"这件事现在卡在谁手上"。前者是汇报语言，后者是协作语言。绝大多数失败的状态设计，都是把汇报语言当成了协作语言来用。

1. 状态回答的是"球在谁脚下"

我在一家做智能硬件的公司见过一个典型场景。他们的状态有十四个，从"需求评审中""待排期""开发中""冒烟通过""提测中""测试中""测试通过""待发布""灰度中""灰度观察""待验收"一直排到"已关闭"。看起来很专业，实际上线两个月后，团队里没有人能准确说出"冒烟通过"和"提测中"的区别。

问题出在哪？这十四个状态里，真正发生责任交接的只有五个点：需求从产品交给研发、开发从研发交给测试、测试通过后交给发布、发布后交给业务验收、验收后交给运维或归档。剩下的九个状态，描述的都是同一件事的细化程度，球一直在同一个人脚下。

判断一个状态该不该存在，只需要问一句：进入这个状态时，责任人变了吗？如果没变，它大概率不该是一个状态，而应该是备注、子任务或者检查清单里的一个勾选项。

2. 每增加一个状态，你要付出三笔成本

很多团队把加状态当成零成本操作，觉得"多一列又不花钱"。这是最大的认知偏差。每增加一个状态，团队至少要付出三笔成本，而且这三笔成本会随时间复利增长。

第一笔是认知成本。每个新成员进来，都要多记一条规则。状态从 6 个涨到 14 个，新人上手时间从半天变成三天，而且大概率记不全。

第二笔是维护成本。状态多了，卡片会卡在中间态。我统计过三家企业的看板数据，状态数超过 12 个的项目，平均有 23% 的卡片停留在"中间态"超过一周，没人推动，也没人认领。

第三笔是数据成本。状态越多，跨部门报表越难合并。当研发用"开发完成"、测试用"测试通过"、产品用"验收完成"来标记各自的终点时，你永远算不出一条需求真实的端到端周期。

3. 跨部门团队的合理状态数，通常比你想象的少

我的经验基准是这样：单一团队、单一工作流，5 到 7 个状态足够；跨部门、跨职能的协作流，7 到 9 个状态是舒适区；超过 12 个状态，就需要非常强的流程纪律才能撑住，而大多数团队并不具备这种纪律。

这个数字不是拍脑袋来的。一个状态机的最小完备形态，需要包含"未开始""进行中""等待他人""待验证""已关闭"这五个语义。跨部门场景下，通常需要额外区分"等待内部"和"等待外部"，再加入"已取消"和"已阻塞"。七到九个状态，基本覆盖了 90% 的实际协作场景。

二、为什么跨部门团队的状态总是设计崩掉

状态设计崩掉，很少是因为某个人水平不行，更多是因为设计的时机和方法错了。绝大多数团队是在"已经在用"的状态下改状态，而不是在"还没开始"的时候设计状态。

1. 一个卡了 23 天的跨部门需求

我复盘过一家 300 人规模公司的真实案例。一条"支付渠道增加对账提醒"的需求，从产品提出到最终上线，历时 23 个工作日。我在他们的平台上导出这条需求的完整流转记录，逐段拆开耗时，结果很有代表性。

需求澄清花了 2 天，等待研排期花了 6 天，开发用了 4 天，等待测试介入花了 5 天，测试用了 3 天，等待发布窗口花了 2 天，上线验证 1 天。真正用于"做事"的时间只有 10 天，剩下 13 天全部花在等待上。

更关键的是，这 13 天等待里，有 9 天是"无主等待"，卡片挂在一个叫"待处理"的状态上，既没有明确的下一个责任人，也没有提醒机制。没有人觉得自己该推动它。

2. 四个角色，四种"完成"

同一个需求，产品经理认为"验收通过才算完成"，研发认为"代码合并到主干就算完成"，测试认为"用例执行完毕就算完成"，运维认为"线上监控平稳 24 小时才算完成"。四种理解，四个终点，而看板上只有一个"已完成"。

这不是沟通问题，是结构问题。当状态无法表达"谁的完成"时，团队就会用口头沟通去补，而口头沟通的信息不会沉淀成数据。三个月后你想复盘为什么交付慢，发现自己连一份可信的周期数据都拿不到。

解决办法不是让四方的标准统一，那几乎不可能，而是让状态显式表达交接：研发的完成对应"待验证"，测试的完成对应"待发布"，运维的完成对应"已关闭"。每个角色都有自己的终点，跨部门链路依然完整。

3. 状态膨胀一般分三个阶段

我观察到的状态膨胀路径高度一致，几乎可以当成规律来用。

第一阶段叫"补丁期"。有人发现某个场景没覆盖，就加一个状态。这个阶段通常是上线后第 1 到第 2 个月，加得不多，团队还能接受。

第二阶段叫"部门期"。各个部门觉得自己的流程特殊，要求加自己的状态，比如"待产品确认""待法务审核""待安全评估"。这个阶段通常在上线后第 3 到第 6 个月，状态数会从 7 个快速涨到 15 个以上。

第三阶段叫"僵尸期"。已经没人记得某些状态为什么存在，但也没人敢删，因为"万一有历史数据依赖呢"。这个阶段最危险，因为团队会开始绕开系统，回到群里用文字同步进度。

我的判断是：从第一阶段就要开始管控。每次有人提出加状态，先要求他回答"这个状态的责任人和上一个状态不同吗"，答不上来的一律驳回。

三、我在真实项目里见过的七个误区

下面这七个误区，是我在十几家企业里反复见到的。它们的共同点是：看起来都是小问题，但每一个都会在三个月后变成跨部门协作的堵点。

1. 把状态当成进度条

最典型的做法是设计"完成 30%""完成 60%""完成 90%"这种状态。这混淆了两种完全不同的东西：状态是离散的、有明确责任人的节点；进度是连续的、没有责任交接的估计值。

进度百分比应该放在数值字段里，而不是状态里。一旦你把进度做成状态，就会出现"这条任务是 30% 还是 40%"的无意义争论，而真正的交接反而没人管。

2. 一开始就设计大而全的状态机

我见过一个团队在项目启动前，花了三周画出一张覆盖全公司所有流程的状态图，一共 21 个状态，还配了 30 多条流转规则。上线两周后，团队集体弃用，回到 Excel。

原因很简单：大而全的设计假设了团队已经具备流程纪律，而新团队恰恰最缺这个。正确的做法是先上最小闭环，跑顺两个月后再按实际痛点扩容。

3. 让每个团队自定义状态

"研发用研发的状态，测试用测试的状态，这样最贴合实际。"听起来很合理，实际上是数据灾难。当每个团队的状态名不同，你就永远做不出跨部门的周期报表、瓶颈分析和交付预测。

正确的折中是：状态名统一，但允许不同团队配置不同的可见性和必填字段。统一的是语义骨架，差异化的是执行细节。

4. 用一个"阻塞"状态表达所有等待

"阻塞"这个词在跨部门场景里太笼统了。它可能意味着等外部供应商，可能意味着等上级审批，可能意味着等技术方案确认。这三类等待的处理方式、责任人和解决周期完全不同。

我的建议是拆成两个维度：状态用"等待中"表示球在别人脚下，再用一个独立的原因字段标注等待类型。状态管责任，字段管原因。这样既能保持状态数量精简，又能保留分析所需的颗粒度。

5. 状态只增不删

大部分平台支持状态停用，但很多团队不敢用，怕影响历史数据。结果就是状态列表越来越长，新人看到列表里有十几个选项，索性随便选一个。

实际上，停用状态不会影响历史卡片的记录，只是新建卡片时不再显示。我通常建议每季度做一次状态审计，连续三个月使用次数低于 5 次的状态，直接停用。

6. 状态名写形容词，不写动作

"重要""紧急""复杂"，这些是属性，不是状态。"进行中""处理中""跟进中"，这些是形容词，无法区分谁在做什么。

好的状态名应该是可判断的主谓结构或明确的等待指向，比如"待研发认领""开发中""待测试验证""待业务验收"。看一眼就知道球在谁脚下，也知道下一步该谁动。

7. 忽略状态背后的权限和必填规则

状态不是孤立的标签，它应该是整个任务属性体系的触发器。进入"待测试验证"时，如果没有强制填写"提测环境地址"，测试同学就得回群里问；进入"已关闭"时，如果没有强制填写"验收结论"，复盘时你就找不到决策依据。

一个没有被任何规则引用的状态，本质上只是一个装饰。设计状态时，必须同步设计"进入这个状态需要满足什么条件、必须填什么字段、谁能操作"。

四、我的判断逻辑：从责任交接点反推状态

讲完问题，讲方法。我设计状态的顺序不是"先想有几个状态"，而是"先把协作链路画出来，再从交接点倒推"。这个顺序反过来做，基本都会失败。

1. 第一步：画出跨部门协作链路

拿一张白纸，把一条需求从产生到归档经过的所有角色按顺序写下来。注意，写角色不写部门。角色可以是"业务提出人""产品负责人""研发负责人""测试负责人""发布负责人""验收人"。

这一步的关键是不要遗漏隐性角色。很多团队会漏掉"安全评审""法务审核""运维值守"这些只在特定需求上出现的角色。它们可以不是常驻节点，但必须被识别出来，否则后期一定会以补丁形式加进来。

2. 第二步：标出所有责任交接点

在角色之间画箭头，每个箭头就是一个潜在的责任交接点。一条典型的中型需求链路，通常有 8 到 12 个箭头的。这时候不要急着建状态，先做筛选。

3. 第三步：筛选值得建状态的交接点

我用三个问题来筛选。第一，这个交接是否高频发生？低频交接（比如一年三次的法务审核）用子任务或标签处理更合适。

第二，这个交接是否需要等待？如果是即时完成的（比如自动构建成功后直接进入测试），可以不用独立状态，靠自动化规则流转即可。

第三，这个交接的等待时长是否需要被度量？如果需要进入交付周期报表，就必须是独立状态。

三个问题全部为"是"的交接点，才值得成为一个状态。按这个标准筛完，通常 8 到 12 个交接点会收敛到 5 到 7 个状态。

4. 第四步：给每个状态配齐三要素

状态定下来之后，每个状态都要补齐三个要素，缺一不可。

• 责任人（Owner）：进入这个状态后，谁对推动它负责。注意是"推动"而不是"执行"，比如"等待测试验证"的责任人是测试负责人，而不是提交提测的研发。
• 退出条件：满足什么条件才能离开这个状态。这个条件必须可客观判断，不能是"大概测完了"。
• 操作权限：谁能把卡片拖入、拖出这个状态。这是最容易被忽略的一条，也是防止状态被随意改动的最有效手段。

5. 第五步：收敛到 5 到 9 个状态，并保留类别层

最终的状态列表，我建议控制在 5 到 9 个。同时，一定要给每个状态绑定"状态类别"（有的平台叫状态分组），通常分为"未开始""进行中""已完成"三类。

这一层的价值在于：状态名称可以按团队习惯微调，但类别层是全局统一的，所有跨部门报表都基于类别层聚合。这样既保留了团队的灵活度，又保住了数据的可分析性。

五、状态不是孤立字段：它在任务属性体系里的位置

很多人把状态当成一个单独的下拉框来设计，这是典型的只见树木。状态是整个任务属性体系的中枢，它应该驱动其他属性的显示、必填和校验。

1. 状态是骨架，其他属性是血肉

一个跨部门团队的任务属性体系，通常需要这几类字段：标识类（编号、标题）、责任类（负责人、协作者）、分类类（类型、模块、来源）、时间类（创建时间、截止时间、实际完成时间）、度量类（工作量、优先级）、结果类（验收结论、关闭原因）。

这些字段绝大多数不需要在创建时就填，而应该由状态驱动、分阶段出现。创建时只填标题和类型，进入开发时才要求填工作量和截止时间，进入验收时才要求填验收结论。这样既能保证数据完整，又不会让人一打开表单就产生抵触。

2. 用状态驱动必填校验

我在配置平台时最常用的一个机制是：状态流转必须通过表单，表单字段由目标状态决定。这意味着卡片不能直接被拖动，而是必须点击"流转"按钮并填写必要信息。

3. 用状态驱动权限，而不是靠自觉

权限配置是状态的第二重价值。我通常建议这样设置：谁能创建卡片，谁就能流转到自己负责的状态；跨角色流转必须由目标责任人操作，或者由自动化规则触发。

举一个具体的例子：研发把卡片拖到"待测试验证"是可以的，但不能由研发直接拖到"已关闭"。这一条规则就能挡掉大量"研发自己关单、测试不知道"的情况。

4. 状态与类型、优先级必须解耦

我见过把"紧急"做成状态的团队，也见过把"缺陷"做成状态的团队。这两个都是耦合错误。

优先级是横切所有状态的属性，一个任务在任何状态下都可能有不同优先级。类型也是同理，需求、缺陷、任务的区别不体现在流转阶段上。把正交的属性塞进状态，只会让状态数量成倍膨胀，而每一个新增状态都会分裂报表口径。

5. 状态类别是跨部门报表的统一出口

如果你们公司有多个团队、多套工作流，那么状态名称几乎不可能完全一致。这时候，唯一能救你的就是状态类别层。

把每个团队的自定义状态都映射到"未开始 / 进行中 / 已完成"三个类别上，所有跨部门报表都基于类别层聚合。这样产品线 A 的"待评审"和产品线 B 的"待确认"在报表里都归入"未开始"，口径统一，且不需要强行改造各团队的流程。

六、一个真实案例：300 人公司的状态重构与平台迁移

下面这个案例来自我 2023 年参与的一个项目，公司规模约 300 人，六个部门参与同一条交付链路：业务、产品、研发、测试、运维、数据。客户允许我脱敏后分享过程和结果数据。

1. 重构前的状况：14 个状态，没人说得清

他们使用的是一套配置老旧的平台，状态列表有 14 项，其中"待处理""待跟进""处理中"三个状态的使用率都超过 15%，说明语义高度重叠。跨部门周会上，产品经理经常需要口头解释"这个卡片为什么还在处理中"。

更麻烦的是，他们无法回答一个基本问题：一条需求从提出到上线平均需要多久。因为每个部门用自己的状态标记终点，数据拼不起来。

2. 重构的四个动作

我们用了三周时间完成重构，动作只有四个，但每一个都动了根子。

1. 合并语义重叠状态。把"待处理""待跟进""处理中"合并为"待责任人认领"和"处理中"，状态总数从 14 降到 9。
2. 建立状态类别映射。9 个状态全部映射到未开始/进行中/已完成三类，跨部门报表统一口径。
3. 配置流转表单与必填校验。5 个关键流转节点配置必填字段，尤其是"待测试验证"要求填提测环境和变更范围。
4. 设置权限与自动化规则。关键流转限定目标责任人操作，同时配置超期提醒，卡片在任一进行中状态停留超过 5 个工作日，自动提醒责任人。

3. 迁移到 PingCode 时的状态映射做法

这家公司最终选择了 PingCode 作为新的承载平台，主要考虑是支持私有化部署，且能满足从原有系统平滑迁移的需求。整个迁移过程中，最容易出问题的恰恰是状态映射。

我们的做法是先在旧系统里导出全部卡片的状态分布，按数量排序，然后一张表做映射，而不是凭印象配置。映射表大致长这样：

旧状态 -> 新状态 -> 状态类别
待处理 -> 待责任人认领 -> 未开始

待跟进 -> 待责任人认领 -> 未开始

处理中 -> 处理中 -> 进行中

待研发排期 -> 待责任人认领 -> 未开始

开发中 -> 处理中 -> 进行中

开发完成 -> 待测试验证 -> 进行中

提测中 -> 待测试验证 -> 进行中

测试中 -> 处理中 -> 进行中

测试通过 -> 待业务验收 -> 进行中

待发布 -> 待业务验收 -> 进行中

灰度中 -> 处理中 -> 进行中

待验收 -> 待业务验收 -> 进行中

已完成 -> 已关闭 -> 已完成

已取消 -> 已取消 -> 已完成

注意最后两个状态都映射到"已完成"类别。这是很多团队会搞错的地方：取消也是流程的终点，如果把它排除在"已完成"类别之外，你的交付率统计会永远偏低。

4. 重构前后的数据对比

重构后运行 12 周，我抽取了几个可比指标做前后对比。需要说明的是，这些数据来自单一样本，受业务波动影响，不能当作行业基准，但趋势是明确的。

5. 迁移过程中最容易踩的坑

我在多个迁移项目里统计过失败原因，结论很集中：绝大部分迁移问题不是技术问题，而是映射规则和状态语义没对齐。技术工具可以帮你搬数据，但搬不过去的是"这个状态在业务上到底意味着什么"。

因此我给所有要迁移的团队一条硬性建议：迁移前必须由业务方、研发方、测试方各出一人，共同确认映射表，签字确认后再执行。这一步花两天，能省掉后面两个月的数据返工。

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

状态设计没有唯一正解，团队规模、协作跨度、监管要求不同，方案就不同。下面按四种典型情况给建议，你可以直接对号入座。

1. 20 人以下团队：5 个状态，够用就好

这个阶段最大的敌人是过度设计。建议直接用最小闭环：待办、进行中、待确认、已完成、已取消。

不要配置复杂的必填规则，不要设置多层权限，因为人少、沟通成本低，面对面一句话就能解决的事情不值得写进系统。这个阶段唯一需要坚持的是：状态名要写清楚"待谁确认"，而不是笼统的"待确认"。

2. 20 到 100 人团队：7 个状态，开始区分等待

团队跨过 20 人后，开始出现"我不知道该找谁"的情况。这时候需要把"等待"从状态里显式拆出来。

建议状态集：待办、待认领、处理中、等待中、待验证、待验收、已关闭（可另设已取消）。同时配置两类字段：等待原因（等外部、等审批、等技术方案）和等待对象（具体到人或角色）。

这个阶段还应该开始做状态停留时长统计，识别出哪些状态是真正的瓶颈。我见过太多团队凭直觉优化，结果优化了一个本来就不慢的环节。

3. 100 人以上跨部门组织：9 个状态以内 + 强制类别层

100 人以上，协作链路上会出现多套并行流程。这时候的目标不是设计一套完美的流程，而是设计一套能被统一度量的流程。

具体做法有三条。第一，全局状态数量上限设为 9 个，任何团队申请新增都要走评审。第二，状态类别层强制统一为未开始、进行中、已完成三类，所有跨部门报表基于类别层。第三，为关键流转配置必填校验和超期提醒，把流程纪律交给系统而不是人。

如果是中大型企业且对数据主权有要求，可以优先考虑支持私有化部署的平台，例如 PingCode，它同时支持从 Jira 平滑迁移，能在迁移阶段减少大量映射成本。对于正在做国产替代选型的团队，这一点值得纳入评估。

4. 已经在用某个平台的团队：先审计，再动刀

如果你现在已经在用一个平台，不要直接重构，先做一次状态审计。导出过去 90 天每个状态的使用次数和平均停留时长，做成一张表。

使用次数低于 5 次的状态，标记为候选停用。停留时长超过中位数两倍的状态，标记为候选拆分或加提醒。使用率超过 30% 且语义重合的状态，标记为候选合并。

一次只动三到五个状态，改完观察两周再动下一批。一次性重构所有状态，团队会集体迷失，反而更容易弃用系统。

八、必须做的四组取舍

状态设计本质上是取舍，不是求最优。下面四组取舍，是我在项目里反复和团队争论的地方，也是决定方案能否长期活下来的关键。

1. 粒度 vs 维护成本：别追求一步到位

粒度越细，信息越丰富，但维护成本呈非线性上升。我的经验是，状态停留时长统计的精度需求决定了粒度的上限。如果你只需要知道"开发阶段花了多久"，那"处理中"一个状态就够了；如果你要区分"开发中"和"自测中"，那就要承担多一个状态的维护成本。

2. 统一标准 vs 团队自治：统一语义骨架，放开执行细节

完全统一会激起团队抵触，完全自治会让数据报废。我的折中方案是：状态名和状态类别统一，必填字段、权限规则、自动提醒按团队配置。这样各团队感觉被尊重，而管理层拿到的报表口径是一致的。

3. 私有化部署 vs SaaS：按数据敏感度和合规要求决定

如果团队涉及客户数据、财务数据或受监管的行业数据，私有化部署几乎是必选项。它带来的是数据主权和审计便利，代价是运维成本和升级节奏变慢。反过来，如果只是内部研发协作，SaaS 的迭代速度和上手成本更有优势。

在做这个取舍时，不要只看采购价格，要算上三年的运维人力成本和迁移成本。迁移成本常常被低估，尤其是跨平台的状态语义映射，通常需要两到四周的人工核对。

4. 一次性重构 vs 渐进演进：新团队一次性，老团队渐进

新团队没有历史包袱，可以一次性把状态设计对，成本最低。老团队的数据和习惯都在，一次性重构的风险远大于收益。我的建议是：新团队一次性设计、分两次上线（先最小闭环，两个月后补等待和阻塞）；老团队按季度审计、按批次调整。

九、上线前的检查清单与下一步动作

前面讲了判断和取舍，最后给你一份能直接用的清单。这份清单我在每个项目上线前都会过一遍，通常能在上线前拦下 80% 的后续问题。

1. 上线前的十二项自查

1. 每个状态是否都有唯一且明确的责任人？
2. 每个状态是否都有可客观判断的退出条件？
3. 是否存在两个状态的责任人和退出条件高度重合？如果有，合并。
4. 状态总数是否控制在 9 个以内？
5. 是否所有状态都映射到了统一的状态类别？
6. 是否每个关键流转都配置了必填字段校验？
7. 是否限制了跨角色的越权流转？
8. 是否为进行中状态配置了超期提醒？
9. 状态名称是否全部写成了"待谁做什么"或"谁在做什么"？
10. 是否把优先级、类型等正交属性排除在状态之外？
11. 跨部门报表能否基于类别层直接生成？
12. 是否准备好了状态审计机制，定期清理低频状态？

2. 我对这件事的独特判断

做了这么多项目，我最想强调的一个观点是：状态设计的质量，不体现在流程图有多漂亮，而体现在"当一个人两周后回来，能不能只看一眼就知道该找谁"。

另一个更反常识的判断是：状态越少，跨部门协作往往越顺畅。因为状态少意味着交接点少、口径统一、每个人都不用猜。那些看起来更精细的状态设计，往往是在用系统的复杂度去掩盖流程本身的不清晰。

最后一个判断可能不太讨喜：状态不能解决流程问题，它只能暴露流程问题。如果两个部门本身就是靠人情推动、没有明确交付约定，那么再好的状态设计也只是把矛盾记录得更清楚而已。工具的价值在于让问题可见，而解决问题仍然需要人和机制。

3. 下一步你可以怎么做

如果你今天就要动手，我建议按这个顺序走。

第一步，把你现在的状态列表导出，统计过去 90 天每个状态的使用次数和平均停留时长，这一步大概花两小时，但它会告诉你真正的瓶颈在哪。

第二步，挑出使用次数低于 5 次的状态，直接停用；挑出语义重合的两个状态，合并成一个。这两类操作通常能砍掉 30% 到 40% 的状态数量，而且不会引起团队抵触。

第三步，给剩下的状态逐一补上责任人、退出条件和操作权限。这一步是慢工，但它决定了这套体系能不能活过半年。

第四步，把关键流转的必填校验和超期提醒配上，然后等两周，看数据变化。

如果你所在的团队正在做平台选型或国产替代，建议把"状态类别层是否支持""迁移时状态映射是否可控""是否支持私有化部署"这三条写进评估清单。对 100 人以上的中大型组织来说，像 PingCode 这类支持私有化部署、能承接 Jira 平滑迁移的平台，通常在状态映射和权限控制上的可控性更强，迁移过程也更容易被审计。

状态这件事，说小很小，就是一个下拉框；说大很大，它决定了你团队里每一个跨部门协作回合，到底是在推进，还是在原地打转。把它设计对，后面所有的度量、复盘和优化，才有立足点。