看板已完成教程：项目经理落地方案，避坑指南

项目看板上最容易引发争论的，不是任务什么时候开始，而是任务什么时候才算“已完成”：开发说代码已提交，测试说还有缺陷，业务说结果没验收，项目经理却已经把卡片拖进完成列。看板落地的关键因此不在于列名有多齐全，而在于团队能否对每个状态的进入条件、交接责任和完成证据达成一致。下面我会从项目经理的实际决策顺序出发，讲清看板如何搭建、如何运行、如何定义完成，以及什么时候需要额外的计划工具。

一、先讲结论：看板不是任务墙，“已完成”也不是一个动作

1. 看板落地要解决的是工作流问题

我判断一套看板是否有效，通常不先看它有多少列、多少颜色或多少自动化规则，而是看它能否回答三个问题：工作现在卡在哪里？谁负责把它推进到下一步？什么证据能证明它已经完成？如果这三个问题答不出来，再整齐的看板也只是电子化任务清单。

看板关注的是工作如何经过流程，而不是把所有事情平铺在一个页面上。状态应反映实际工作阶段，卡片应承载交付信息，流转规则则说明谁在什么条件下做什么。项目经理的任务不是要求团队“多更新几次”，而是设计一套值得更新、能够指导下一步工作的机制。

2. “已完成”至少要区分执行完成与交付完成

执行人做完自己的部分，不必然代表项目结果已经交付。代码合并、文案写完、方案评审通过，可能只是某个团队的局部完成；若后续还要集成、测试、业务确认或客户验收，任务仍可能处于待验证状态。

我建议团队先明确最终完成口径，再设置状态。一个可操作的定义通常要说清楚交付物是什么、由谁验收、验收依据是什么、未通过时退回到哪里。“我做完了”是个人报告；“符合约定且验收通过”才是团队可以共同确认的完成。

3. 看板不能替代所有项目管理手段

看板擅长呈现工作流动、在制任务和阻塞位置，但它未必能独立承担复杂依赖分析、关键里程碑管理、资源冲突判断和对外承诺日期管理。若项目有固定交付节点、跨团队前后置关系或强监管要求，就需要把看板与项目计划、风险台账、依赖清单等配合使用。

因此，项目经理不应问“要不要用看板代替甘特图”，而应问“团队需要看见哪些工作流信息，哪些承诺仍要通过计划管理”。工具边界划清，才不会把看板做成既难维护、又无法回答关键进度问题的万能面板。

二、背景和真实场景：任务都在动，项目却还是不透明

1. 典型现场：所有卡片都在“进行中”

在项目管理讨论中，我经常会先用一个常见场景做诊断：团队已经有任务看板，大家也会更新状态，但“进行中”列越堆越长。项目经理每天看到几十张活动中的卡片，却不知道哪些正在执行、哪些在等设计确认、哪些被外部团队卡住，也不知道谁应该先处理。

这类问题不一定是成员不配合。更常见的原因是状态粒度太粗、任务定义含糊、交接没有明确责任，或者团队把等待和执行都塞进同一列。看板显示“有进展”，却没有显示下一步行动，于是项目经理只能回到群聊里逐个追问。

2. 先把现象拆成可观察的信号

落地前，我会先观察任务从进入到交付的路径，特别留意四类信号：同一列持续积压、卡片长期没有变化、任务频繁退回，以及某个角色成为大量工作的共同等待点。这些现象比“大家觉得最近很忙”更适合用于讨论流程问题。

对团队来说，首轮诊断不必先上复杂统计。抽取最近一段时间的代表性任务，逐张追问进入流程的时间、实际开始时间、等待原因、退回次数和验收时间，通常就能看出看板缺少的是状态定义、责任界面，还是跨团队依赖信息。

如果一张卡片不能让接手的人知道交付目标、当前责任人和下一步动作，它就不是一张可管理的任务卡。这条检查原则适用于研发、运营、产品和跨部门项目，不依赖特定工具。

3. 用一个小范围试点识别流程，而不是先铺满全公司

新建看板时，我倾向于选一条边界清楚、任务数量适中、参与角色稳定的工作流试运行。比如一个功能交付链路、一个内容审批流程，或一个持续运营任务组。先验证状态名称和交接规则是否能被团队理解，再决定是否扩展到其他项目。

过早推广常会把局部流程差异放大：研发把“评审”理解为技术评审，运营把它理解为业务审批，管理层却希望它代表项目决策。一个词在不同团队里含义不同，数据汇总便失去可比性。因此，先在小范围统一定义，比先做全组织大屏更有价值。

三、常见误区：为什么看板上线后反而更难管理

1. 照抄模板，状态列却不对应真实流程

常见模板会提供“待办、进行中、已完成”等通用列，但团队真实流程可能还包括需求澄清、外部等待、评审、验收、发布等阶段。照抄模板本身没有错，问题在于把模板当成流程答案，而不是起点。

如果某个状态既表示“等需求方补资料”，又表示“等负责人有空”，项目经理就无法判断积压来源。反过来，若每个细小动作都拆成一列，看板也会变成状态迷宫。判断标准不是列越少越好或越细越好，而是每一列是否会改变责任、决策或下一步行动。

2. 把“进行中”当成工作状态的万能收纳箱

“进行中”过宽，是看板失去诊断能力的常见原因。卡片可能正在制作，也可能等审批、等外部接口、等环境修复；它们需要的管理动作并不相同。把这些情况混在一起，项目经理看到的只是数量，不是原因。

我会先检查是否有必要把等待标记显性化。等待不一定都需要新增一列，也可以用阻塞标记、等待对象、阻塞原因和下一次跟进时间表达。关键在于团队能否区分“有人正在处理”和“工作暂时不能推进”。

3. 任务卡只有标题，没有交付物和验收条件

“优化页面”“处理接口”“完善方案”这类标题对执行人可能足够熟悉，但对协作者和验收人未必明确。任务进入看板前，至少要让团队知道预期结果是什么、谁负责、如何判断结果达标。复杂任务还要说明依赖条件和拆分边界。

卡片字段并非越多越好。字段维护成本过高时，成员会复制粘贴旧内容，甚至随手填默认值。项目经理应从当前最常出现的误解出发，保留能帮助交接、验收和决策的字段，其他信息放到关联文档或专门记录中。

4. 用“卡片移动了”代替“工作产生了结果”

状态更新是过程信号，不是交付证明。卡片被拖入完成列，可能只说明有人执行了一个界面动作。若最终验收、发布或客户确认还没发生，项目状态就可能被提前美化。

建议团队把“完成”定义成可检验的条件，而不是要求每个人凭感觉决定。对内部任务，完成条件可以是产物已提交并通过约定检查；对面向客户的交付，则可能还需要客户确认或约定的验收记录。定义应按工作类型区分，不应把所有任务强行套成一个口径。

5. 用更新频率掩盖流程设计问题

当看板信息过时，第一反应往往是要求大家每天更新。但若团队不知道何时更新、由谁更新、等待状态该如何记录，增加提醒只会增加维护负担。状态更新应与真实工作事件绑定，例如任务交接、评审结果、阻塞出现或验收完成。

我会先检查看板是否能让更新者明确回答“变化了什么、下一步是什么”。若没有，先改状态定义和任务字段，再讨论更新频率。让信息流动贴近工作流，比单纯提高填表次数更重要。

四、专业判断逻辑：从流程、责任和证据设计看板

1. 从工作流出发确定状态，而不是从工具菜单出发

状态列应对应团队真实的工作阶段。项目经理可以先选取一批已完成任务，回溯它们经历过的步骤，再对照未完成任务检查是否存在被遗漏的等待或审批环节。这个做法比先讨论“行业标准应该有几列”更容易得到符合现场的答案。

每个状态都要能回答两个问题：进入这个状态意味着什么？离开这个状态需要满足什么条件？如果团队成员对答案意见不一，就先不要急着建列，应先统一流程规则。状态名称可以简洁，但规则不能只靠口头默契。

2. 给任务卡设置最小必要信息

我通常先从六类信息评估任务卡是否足够清楚：任务负责人、预期交付物、优先级或承诺日期、验收条件、关键依赖、当前阻塞。并不是每个团队都需要把六项做成强制字段，但凡经常导致返工或追问的信息，都值得考虑是否在任务创建时补齐。

对小任务，标题加负责人和完成标准可能已经够用；对跨团队任务，则需要依赖方、交付接口和目标时间。字段的价值要用减少的解释成本来衡量：如果一个字段几乎不会影响执行、验收或决策，就不必为了“看起来专业”而保留。

3. 用在制品限制促使团队完成，而不是不断开新任务

在制品限制，也就是限制某个阶段同时处理的任务数量，可以帮助团队看见并讨论过度并行的问题。它不是惩罚指标，也不是适用于所有工作的固定数字。若任务性质差异很大，简单限制卡片数量可能不公平；此时可以按团队容量、工作类型或角色负载分别观察。

设置限制前，建议先记录一段时间的在制品数量、交付节奏和阻塞原因。若某一环节长期积压，先确认是容量不足、输入质量不佳、依赖等待还是规则不清。没有原因分析就直接压低上限，可能只是把问题从看板上藏起来。

4. 把完成定义写成团队可验证的约定

一个可用的完成定义，可以写成一段简短规则：交付物已提交到指定位置；必要检查已通过；责任角色已完成确认；若不通过，任务退回到哪个状态并附上原因。不同任务类别可以有不同完成标准，但同一类别内应尽量一致。

如果任务有多个验收人，应明确谁有最终确认权，谁只提供意见。否则卡片可能在“等待确认”中长期停留，项目经理却无法判断是否该升级。完成定义的目的不是增加审批，而是让所有人知道验收边界和关闭任务的证据。

5. 用流动指标发现瓶颈，不用单一指标给个人排名

看板数据常见的观察角度包括交付周期、周期时间、吞吐量、在制品数量和任务年龄。交付周期通常从工作被请求或承诺开始计到交付；周期时间通常从实际开始处理计到完成。团队应先统一起止点，再比较数据，否则不同口径的数字没有可比性。

这些指标更适合观察系统，而不是简单评价个人。某段时间吞吐量下降，可能与任务变大、外部等待增加、验收标准变化或人员容量变化有关。单看完成数量，容易鼓励拆小卡片或提前关闭任务，反而损害真实交付质量。

下方数值是用于说明指标关系的情景模拟数据，不是行业基准，也不代表任何特定团队。它展示的是：当等待占用周期的大部分时间时，单纯加快执行速度未必能显著缩短交付。

五、具体落地方案：让一张卡片从进入看板走到验收

1. 第一步：选定一条工作流并画出实际步骤

先选一个范围明确的流程，例如需求进入到功能上线，或内容提出到正式发布。请参与流程的角色共同列出真实步骤，并标出每一步的责任人、输入和输出。流程图不必复杂，关键是把过去依赖口头沟通的交接点写出来。

初始状态可以从少量核心阶段开始。若团队发现某些等待需要被单独管理，再增加状态或阻塞标签；若某列长期没有卡片、也不产生独立决策，可以考虑合并。不要为了与别的团队看起来一致而保留没有实际意义的状态。

2. 第二步：明确任务进入看板的门槛

任务进入工作流前，至少要有可理解的目标和明确的提出方。涉及多人协作的任务，还应确认负责人、必要依赖和验收人。入口规则的作用不是拦住工作，而是避免模糊需求一进入执行阶段就变成返工和争议。

对于信息尚未齐全的事项，可以设置“待澄清”或等效机制，但要指定谁负责补齐、何时复核。若所有不确定事项都直接进入执行列，执行人就会被迫边做边猜，后续计划也会被不稳定的输入牵着走。

3. 第三步：把执行、等待和阻塞区分开

任务开始后，负责人应维护当前阶段和下一步动作。遇到阻塞时，记录阻塞原因、需要谁协助、预计何时复查。项目经理要关注的是阻塞能否被及时看见、是否有人承担推进责任，而不是每张卡片都必须写一段长篇日报。

如果等待状态数量很多，可进一步区分内部等待和外部等待。前者可能需要调整团队优先级或容量，后者可能需要向依赖团队升级。分类不宜过细；能改变处理方式的分类才值得留下。

4. 第四步：建立明确的交接与验收动作

任务从一个角色交给另一个角色时，交接双方要知道交付物、验收条件和问题反馈渠道。比如开发提交后，测试需要知道要验证什么版本、覆盖哪些情形；业务验收需要知道预期结果和可接受偏差。只把卡片移动到“待验收”，却没有交接信息，通常会引发二次追问。

未通过验收时，不应为了保持完成率而关闭任务。应将任务退回到合适阶段，记录未通过原因和下一步负责人。对于只需小幅修正的情形，可以沿用原任务；若范围发生实质变化，则应重新评估任务边界和交付承诺。

5. 第五步：按节奏检查流动，不把例会开成逐卡念状态

看板检查会议的价值，在于处理例外和决策，而不是让每个人从头汇报所有卡片。项目经理可以从最接近交付的任务、长期停留的任务、超出在制品限制的阶段和新出现的依赖风险开始讨论。

会议结束时，每个需要干预的事项都应有下一步动作、负责人和复查时间。对没有变化、没有风险、也不需要决策的任务，不必反复念状态。团队可根据项目节奏安排检查频率，重点是阻塞出现后能在合理时间内被看见并处理。

下图为试运行时可以采用的建议检查节奏示例，不是统一规定。若团队交付节奏较快，可缩短复核间隔；若任务变化较少，则可以减少例行检查次数，但保留阻塞升级渠道。

6. 第六步：用试运行复盘修正规则

试运行期间，我建议记录规则本身是否有效，而不只记录任务是否按时完成。比如哪些状态经常被误用，哪些字段总是缺失，卡片在哪类交接后最容易退回，哪些阻塞原因反复出现。这样复盘的对象是工作系统，而不是只找某个成员“为什么没更新”。

试运行可以设一个明确的检查窗口，例如先运行两周后集中复盘；这只是便于安排讨论的实践建议，不是固定标准。遇到明显错误的流程规则，应及时修正，不需要为了等到窗口期而继续制造混乱。调整时保留变更记录，避免团队同时使用多个版本的规则。

六、案例与数据观察：模拟团队怎样定位“完成列”失真

1. 情景说明：不是实测报告，而是用于演示的样本推演

下面用一个虚拟产品交付团队说明诊断过程。团队有 12 名成员，参与需求、开发、测试和业务验收；每周处理约 20 张任务卡。某次复盘发现，看板显示任务持续流转，但业务侧仍频繁询问“什么时候能用”，项目经理也无法从完成列判断实际可交付范围。

为了避免把示例误读成行业结论，以下数据全部是样本推演，仅用于展示如何设计观察项。真实项目应从自己的任务记录中取数，并注明采样区间、统计口径、任务类型和是否排除取消项。

2. 先比较“关闭数量”和“验收通过数量”

团队抽取连续 4 周的 80 张任务卡，发现其中 68 张被移入完成列，但只有 52 张在该窗口内有明确验收记录。差异并不能直接证明 16 张任务都不合格：也可能是验收记录未回填、验收在窗口之后发生，或任务定义本身就不要求业务确认。它首先说明“完成列的统计口径”需要进一步拆解。

项目经理接下来应抽样核对卡片，而不是立即要求成员提高验收率。逐张检查交付物、验收人、确认时间和退回记录，可以区分流程缺陷、信息缺失和实际质量问题。数字负责指出值得调查的位置，不能替代原因判断。

3. 再查等待时间和退回原因

同一组虚拟任务中，团队发现一部分卡片在“待验收”停留较久，常见原因是验收人未明确、验收条件不一致，或交付说明不足。此时若只催执行人更快提交，问题不会消失；更有效的动作可能是任务入列时确定验收人，并在交接时附上验证范围。

另一部分卡片被退回后仍留在完成列，导致面板上的完成数量无法反映当前真实状态。修正办法不是删掉历史，而是让任务回到需要处理的状态，并保留退回原因与处理记录。这样既不抹掉过程，也不夸大交付结果。

4. 用多个观察指标交叉验证，而不是追求一个漂亮数字

诊断完成列是否可靠时，至少要同时观察关闭任务数、验收记录覆盖率、验收退回率和完成后重新打开的比例。不同指标解释不同：覆盖率低可能是记录机制不足，退回率高可能是需求或质量问题，重新打开比例上升则可能说明完成口径过早或交付后问题增多。

以下图表仍为样本推演。它的作用不是宣称某个团队实际达到了这些数值，而是演示如何用多个指标区分“卡片关闭”与“交付确认”之间的差异。

5. 从发现问题到调整规则，形成可验证的小闭环

基于这组模拟观察，团队可尝试三项调整：创建任务时指定验收人；进入待验收时附上交付位置和检查范围；验收退回时必须填写原因并恢复到相应处理阶段。之后再观察相同类型任务的验收记录覆盖率、待验收停留时间和重新打开比例是否变化。

这类改动的优点是小而可验证。若所有指标都一起改善，也仍要留意任务规模、人员容量和外部依赖是否同时发生变化。项目经理不应把短期波动包装成确定的因果关系，而应把每次调整当作一个有假设、有观察口径的流程实验。

七、工具与方案取舍：按组织复杂度选，不按功能清单选

1. 小团队先验证流程，未必需要复杂平台

如果团队人数少、流程单一、跨项目依赖不多，一张共享看板或轻量协作工具可能足够。此时最重要的是统一任务状态和完成定义，而不是一次配置所有报表、权限和自动化。工具配置越复杂，越需要明确谁维护、谁解释数据、规则变化如何通知。

但当团队规模扩大，任务跨多个部门流转，权限、审计、部署方式、历史数据迁移和统一报表开始影响选择时，仅靠个人维护的任务表格可能难以持续。此时应先列出治理要求，再验证平台能力，而不是只比较首页上的功能数量。

2. 中大型组织需要评估治理、迁移和部署约束

对于 100 人以上组织，项目经理应进一步确认平台能否支撑多团队流程差异、角色权限、数据汇总、变更审计和长期维护。还要评估旧系统中的项目、任务、附件、评论和历史关联能否迁移，迁移后哪些字段会映射、哪些记录需要人工核验。

以 PingCode 为例，若组织正在评估中大型项目管理平台，可以把私有化部署能力、Jira 平滑迁移路径和多团队协作需求列入验证清单。具体能力、适用版本、实施方式与迁移范围，应以当前产品文档、方案确认和合同约定为准；“支持迁移”不等于所有历史数据都能无损自动转换。

我不会仅凭“国产替代”标签就推荐任何平台。更可靠的判断是：组织是否需要本地部署或数据控制，现有流程和数据是否能迁移，使用方是否接受新工作方式，供应商能否提供可验证的实施方案。对平台进行小范围概念验证，再决定是否扩大部署，通常比仅凭演示环境作出采购判断稳妥。

3. 采购评估要把功能、成本和迁移风险放在一起

评估工具时，可以准备一组真实任务样本，覆盖正常流转、阻塞、返工、跨团队依赖和最终验收。让实际用户完成建卡、交接、退回、查询和报表等操作，再检查每个步骤是否符合流程。演示环境里“看起来能做”，不代表团队日常愿意使用。

迁移还要考虑字段映射、权限重建、附件与评论迁移、历史报表口径、用户培训和并行运行成本。若旧系统中的状态含义混乱，直接迁移只会把旧问题搬到新平台。迁移前先清理流程和数据规则，可能比追求一次性迁完所有历史记录更重要。

4. 选型不是“功能最多胜出”，而是约束条件先通过

可以把工具比较分为两层。第一层是硬约束，例如部署要求、数据安全、访问控制、迁移要求和组织合规；第二层才是易用性、报表灵活度、自动化能力和总拥有成本。硬约束未通过的方案，不应因为界面好看或功能丰富而进入最终选择。

下表可作为评估讨论模板，评分应由实际试用和供应商材料共同支持，不能把预设权重当作客观结论。

八、不同场景下的行动建议与取舍

1. 新团队刚开始使用看板：先追求规则清楚

如果团队以前主要靠会议和即时消息跟进，先不要急着建立复杂度量体系。选一条核心工作流，确定状态、负责人、交付物和完成定义，再让团队真实使用。此阶段最值得观察的是卡片是否能顺利交接、阻塞是否被及时标记、完成口径是否一致。

此时的取舍是少做报表、少设字段，换取更低的学习和维护成本。先让成员愿意把真实工作放进看板，等流程信息稳定后再讨论趋势分析和自动化。若一开始就强制填满大量字段，团队可能只完成录入动作，却没有形成共同的工作语言。

2. 已有看板但任务堆积：先处理流动瓶颈

如果工作长期停留在某个阶段，不要立刻要求全员“加快速度”。先分解积压任务的年龄、等待原因、任务类型和责任角色，判断问题集中在需求输入、人员容量、审批等待还是外部依赖。不同原因对应不同动作，不能只靠增加催办频率解决。

取舍重点是减少同时开工的数量，还是扩充瓶颈环节容量。减少并行可能让单个任务更快完成，但会暂时推迟部分新任务启动；增加容量可以缓解特定环节，却可能造成上下游利用不均。项目经理应把影响和承诺说清楚，再与相关负责人一起调整。

3. 跨团队项目依赖很多：看板与里程碑计划并用

若任务之间存在大量前后置关系，或项目需要对外承诺固定日期，看板应负责呈现日常流转，项目计划负责管理里程碑和依赖。关键路径、外部交付时间和关键资源冲突，不应只靠卡片位置推断。项目经理可以在看板卡片中关联里程碑或依赖项，但仍要保持独立计划的清晰性。

取舍在于信息重复维护。若两套系统都需要人工更新，团队会产生双重录入负担；可通过明确数据主责、使用链接或集成减少重复。不要为追求“所有信息都在一个页面”而牺牲计划关系的准确性。

4. 强监管或高审计要求：优先保证记录完整与责任可追溯

如果任务涉及审批、审计、客户验收或合规要求，完成口径要包含必要记录、审批人和时间戳。此时状态设计不只是为了团队方便，也要确保事后能还原谁在何时做了什么决定。平台权限、日志保留和数据导出能力都应纳入评估。

取舍是流程灵活性与控制要求之间的平衡。控制环节过多会拖慢低风险任务，控制不足则可能让关键交付缺少证据。可以按任务风险设置不同验收路径，避免所有工作都走同一套繁重审批。

5. 组织准备更换平台：先定义迁移边界，再讨论工具

如果旧平台难以支撑协作，先盘点需要迁移的项目、活跃任务、历史附件、评论、用户权限和报表。再确定哪些数据必须完整保留，哪些只需归档，哪些适合清理。迁移范围越大，验证和培训成本越高，不应把“全部搬过去”当成默认目标。

取舍时要比较一次性迁移成本与长期并行成本。分阶段迁移更容易控制风险，却会在过渡期增加跨系统查询；一次性切换减少双轨运行时间，但对数据质量、培训和上线保障要求更高。中大型组织尤其应先做试迁移、验收映射和回退预案。

九、项目经理的落地清单：从今天开始做什么

1. 开始搭建前，先回答六个问题

• 这张看板要管理哪一条明确的工作流？
• 每个状态代表什么，进入和离开条件是什么？
• 每张任务卡最少要包含哪些执行与交付信息？
• 阻塞、等待、返工和取消分别如何记录？
• 谁有权确认任务最终完成，完成证据是什么？
• 哪些依赖、里程碑或风险仍需在看板之外管理？

2. 试运行期间，优先观察四类信号

• 停留信号：哪些阶段持续积压，任务年龄是否出现异常增长。
• 交接信号：任务进入下一阶段后，接手角色是否经常要求补资料。
• 验收信号：完成列是否有验收证据，退回原因是否重复出现。
• 维护信号：哪些字段经常没人填，哪些信息录入后很少被使用。

3. 每次调整都留下假设和验证口径

比如“待验收卡片积压，是因为验收人没有在任务创建时明确”，这是一条可以验证的假设。调整规则后，观察同类任务的等待时间、验收记录覆盖情况和退回原因，判断变化是否与规则调整方向一致。若同时修改了流程、人员配置和任务优先级，就要谨慎解释结果，不能轻易归因给单一改动。

一个可持续的看板不是上线后永远不变，而是团队能以可控方式修改规则，并知道修改为何发生、产生了什么影响。项目经理应让流程迭代有据可查，而不是每隔一段时间就重新命名所有状态。

4. 最终判断：看板的价值在于暴露真实工作，而不是制造漂亮进度

项目经理落地看板，最容易忽视的不是工具功能，而是“完成”的边界和等待的责任。状态列越清楚，越能看见工作真正停在哪里；验收规则越明确，完成数据越值得信任；阻塞越早显性化，项目经理越有机会协调资源，而不是在交付临近时才发现风险。

下一步不必先购买更复杂的平台，也不必先做一块展示全项目颜色的大屏。选一条流程，抽取一批真实任务，写清状态条件、责任交接和完成证据，再运行一段时间检查积压、等待与退回。如果组织规模、权限和迁移要求已超出轻量工具能力，再带着这套清晰规则评估平台，才更容易看出工具到底解决了什么问题。