拖拽管理指南：产品经理如何做好看板，实操方法全流程

拖拽管理指南：产品经理如何做好看板，实操方法全流程

产品看板上有四十张卡片，大家每天都在拖动它们，项目却还是一再延期，问题往往不在拖拽操作，而在团队没有说清楚任务何时开始、什么算完成、卡住后由谁处理。做好看板，不是把工作贴进几列，而是把任务从提出到交付的流动过程变得可见、可讨论、可调整。下面我会从流程梳理、状态设计、卡片规则、团队运行到指标复盘，拆解一套可落地的方法，并用一个明确标注为情景模拟的产品团队案例说明如何检验效果。

一、先讲核心结论：看板管理的对象是工作流，不是卡片

1. 看板要回答三个管理问题

我判断一块看板是否有用，通常先看它能不能回答三个问题：现在有哪些工作正在流动？工作在哪个环节等待或受阻？团队下一步该采取什么行动？如果看板只能显示“谁手里有多少任务”，却看不出积压原因和处理路径，它更像一张共享任务清单，而不是工作流管理工具。

这一区分很重要。任务清单重在记录“要做什么”，看板还要表达“工作如何经过团队”。卡片被拖到下一列，不应该只是改了一个状态字段，而应该代表任务满足了该阶段的进入条件或完成条件。没有这层约定，成员对同一列的理解可能完全不同：有人把“开发中”理解为已分配，有人则认为必须已经写代码。

2. 看板设计的先后顺序不能颠倒

更稳妥的顺序是先找到要改善的问题，再梳理真实流程，然后定义状态和规则，最后才配置工具。许多团队一上来就挑模板、建列、加标签，做完后才发现看板没有反映实际协作过程。工具操作很快，流程定义却需要团队共同确认；顺序颠倒，后续通常要靠反复改列和补字段来弥补。

我的判断标准很简单：每个状态都应该影响团队的下一步行动。如果某个状态既不改变责任人，也不改变处理方式，还不能帮助识别等待，就要考虑是否真的需要单独设置一列。

3. 一块好看板首先要让异常显眼

看板的价值不在于让所有任务看起来整齐，而在于让少数需要处理的异常不被正常工作淹没。比如，长期停留的任务、缺少验收条件的任务、等待外部团队输入的任务、已经超出并行工作限制的任务，都应该比普通卡片更容易被发现。

因此，我不会把“卡片都填得很完整”当成成功标准。更值得追问的是：团队是否能更早发现阻塞，是否减少了任务在队列里无人处理的时间，是否能解释为什么交付变慢。工具负责呈现，规则负责定义，团队负责采取行动，三者缺一不可。

二、先还原真实场景：从一张需求卡片看出流程问题

1. 不要照搬其他团队的列名

以一个产品需求为例，它可能经过提出、初步澄清、产品评估、设计、开发、测试、发布等环节。但这不代表每个团队都应照着设置七列。有的团队把产品评估和设计放在同一个协作阶段；有的团队需要安全评审、数据审核或多轮验收；还有的团队因人员分工不同，需要把等待研发排期单独暴露出来。

我建议从最近已经完成的几项工作倒推，而不是从理想流程正推。选三到五个近期任务，分别追问：它从哪里进入？谁接手？中间经过了什么等待？什么条件满足后才交给下一位？实际走过的路径，往往比团队墙上的流程图更能揭示看板该如何设计。

2. 把“正在处理”和“正在等待”分开思考

“进行中”常常是最容易被滥用的状态。任务可能正在被某人主动处理，也可能只是等评审、等接口、等外部确认，甚至没有人记得它为什么还在这列。它们看起来都没有完成，实际管理动作却不同：主动处理的任务需要保护专注时间，等待中的任务需要跟进依赖，失去负责人的任务则需要重新确认归属。

团队不一定要为每一种等待新建一列。可以先决定哪些等待值得单独可视化，哪些适合用阻塞标记、等待原因和跟进日期表达。状态数量要少到成员愿意维护，又要细到管理者能采取不同动作。这不是追求列越多越精确，而是让流程信息刚好够用。

3. 把状态入口和出口写成可判断的条件

状态名称只是标签，进入和离开条件才是规则。以“待开发”为例，进入条件可以是需求范围已确认、验收条件已写明、设计材料已准备；离开条件则可以是开发负责人已接手并确认估算。条件不一定复杂，但必须能让不同成员对任务是否可以移动作出相近判断。

如果团队经常争论“这张卡到底算不算完成”，通常不是成员不认真，而是完成定义模糊。把“完成”拆成可检查的条件，例如代码已合并、关键验收项通过、发布说明已准备，就能减少卡片提前移动造成的虚假进度。

4. 看板映射的是协作边界，不只是部门分工

有些团队习惯按角色设置“产品、设计、研发、测试”四列，表面上职责清楚，却可能让任务在每个角色手里排队，没人对端到端交付负责。另一种做法是按工作状态设置列，责任人随任务当前处理阶段变化。哪种更合适，取决于团队如何协作、任务如何交接，以及是否需要暴露等待时间。

我会优先检查交接处：需求何时从产品交给设计？设计稿怎样才算可开发？测试发现问题后，卡片回到哪里？如果团队需要经常在多个列之间来回移动卡片，先别急着责怪成员操作不规范，可能是流程边界没有设计清楚，或者返工路径没有被看板表达出来。

三、拆解常见误区：看板为什么常常越做越复杂

1. 误区一：列越多，管理越精细

列多不等于信息多。一个团队如果把“已分配、排期中、开发中、代码评审、待联调、联调中、待测试、测试中、待验收、已验收”全部做成列，却没有明确哪些变化需要不同管理动作，成员很快会把看板当成填表负担。结果是状态更新延迟，管理者看到的反而是过期信息。

合并状态前，我会先问两个问题：这两个状态的责任人或下一步动作是否不同？它们的等待时长是否需要分别观察？如果答案都是否定的，可以考虑合并；如果一个状态意味着外部依赖、另一个意味着团队主动处理，即使名字相近，也可能值得区分。

2. 误区二：所有任务都塞进同一块板

产品团队经常同时处理版本需求、线上故障、技术改进、合规事项和探索性项目。这些工作的优先级机制、交付节奏和完成定义未必相同。全部放进一条队列，容易让紧急事项挤掉长期工作，也容易让探索任务因缺少固定交付日期而显得“永远没完成”。

但把每种工作都拆成独立看板，也会让负责人看不到总体负荷和跨团队依赖。更合理的办法通常是共享关键工作流，使用有限的工作类型、泳道或过滤视图表达差异，同时明确哪些任务遵循相同的优先级和交付规则。拆分依据应是流程差异，而不是组织架构图上有几个部门。

3. 误区三：拖动卡片就等于推进工作

当任务卡片在列之间频繁移动，却没有对应的交付物或判断条件时，团队得到的是“状态活动”，不是进度。比如，需求被拖到“测试中”，但测试范围、验收标准和测试责任人都不清楚；此时看板看上去前进了一步，实际风险可能刚刚开始暴露。

我会建议把关键状态变化和可验证的工作证据联系起来。证据可以是评审结论、设计链接、验收清单或发布记录，不必为了管理而制造大量文档。目标不是留痕越多越好，而是让接手者能判断工作是否具备进入下一阶段的条件。

4. 误区四：用单一数字评价团队效率

完成任务数量上升，不一定代表交付变快；平均周期缩短，也不一定代表质量改善。团队可能通过拆小任务提高完成数，却增加了集成成本；也可能把复杂需求放到统计范围之外，让平均周期看起来更漂亮。任何指标都需要与任务范围、统计周期和质量结果一起解释。

我不会把看板流量指标直接当成员绩效排名。它们更适合用来定位流程问题，例如哪类任务等待更久、哪个交接点返工更多、阻塞持续时间是否在拉长。把流程指标转成个人排名，会促使成员优化数字而不是优化协作。

5. 误区五：上线后长期不改规则

看板规则需要稳定到足以形成习惯，也要能随着业务变化调整。团队扩大、产品线增加、合规要求变化、外部依赖增多，都可能改变任务的真实路径。若看板列和实际流程长期不一致，成员会在工具外口头协商，管理者看到的板面就逐渐失真。

建议预先约定复盘触发条件，而非每天随意改列。例如连续多个周期出现同一阶段明显积压、某状态长期无人更新、任务频繁绕过某列，或新工作类型持续无法套用现有规则时，再集中评估是否需要调整。这样既避免频繁改动造成混乱，也防止流程已经变了、看板还停在旧版本。

四、专业判断逻辑：从问题到看板配置的完整方法

1. 第一步：明确看板要改善的具体问题

“提升效率”太宽泛，无法指导配置。更好的问题描述应当包含可观察现象，例如：需求进入开发前缺少验收标准；跨团队等待没有责任人；紧急插单不断打断已承诺工作；任务到了测试阶段才暴露依赖。问题越具体，后续越容易判断看板是否有效。

我会把问题写成“现象，影响，可观察信号”三部分。例如：“设计交付信息不完整，导致开发阶段反复询问，信号是需求卡片的澄清评论和返工次数增加。”这不是为了制造复杂分析，而是避免团队把任何问题都归因于工具缺少某个字段。

2. 第二步：追踪真实任务，而不是设计理想流程

从近期完成和延期的任务中各挑几项，沿着历史记录、会议结论和成员访谈还原路径。除了“任务经过哪些阶段”，还要标记在哪些节点等待、等待谁的输入、是否返工、优先级何时变化。延期任务可以帮助暴露异常路径，顺利交付的任务则能显示团队真正有效的协作方式。

若无法获得完整记录，可以先做轻量观察：连续一到两个工作周期，每天记录在制任务、状态变化和阻塞原因。样本不必被包装成统计学结论，但足以发现反复出现的摩擦点。最重要的是明确观察范围，别把几次个案夸大成所有团队都适用的规律。

3. 第三步：设计最小够用的状态与卡片字段

我倾向于先做最小可运行版本，而不是一次性设计一套完备制度。状态列表达工作流阶段；字段表达卡片属性；标签或泳道表达需要特别关注的类别。三者混用，是看板越来越难维护的常见原因。例如“高优先级”通常是属性，不一定要变成一个状态列；“等待外部确认”则可能是需要显式跟进的工作状态。

一个常见的产品需求卡片可以从以下信息起步：清晰标题、问题或目标、负责人、优先级、验收条件、依赖与风险。不是每张卡片都要把所有信息写成大段说明。探索性任务可能先强调假设和验证方式，线上故障则可能需要影响范围、应急责任人和恢复条件。字段应服务于决策与交接，不是为了追求表格完整。

4. 第四步：把团队规则写成可执行约定

看板规则至少要说清楚：谁创建和维护卡片？谁能调整优先级？任务进入下一列需要什么条件？阻塞由谁标记和跟进？紧急事项如何进入正在运行的工作流？成员休假或负责人变更时，卡片如何交接？规则不需要写成厚厚的流程手册，但必须让团队遇到真实场景时有一致做法。

尤其要提前约定插单机制。如果“紧急”可以由任何人随时定义，团队实际上没有优先级规则。可以要求提出方说明影响、时限和不处理的后果，再由指定角色决定是否打断现有工作。被挤出的任务也要同步调整承诺，不能只把新任务塞进去，却假设原计划仍然成立。

5. 第五步：先试运行，再决定是否推广

试运行的目标不是证明方案一定成功，而是快速发现状态定义、字段和协作习惯哪里不匹配。可以先选择一条产品线、一个跨职能小组或一类工作，运行一到两个复盘周期。试点时记录成员更新负担、任务等待、阻塞处理和看板外协作情况，重点观察规则是否被使用，而不是只看配置是否完成。

如果成员需要在多个地方重复录入同一信息，或者为了更新看板必须绕开日常工作，就要检查工具集成和流程设计；如果卡片长期不更新，先查规则是否模糊、更新责任是否无人承担，不要立即认定成员抵触变革。试点结束后只保留能支持协作的结构，删除没人使用、也无法解释管理价值的字段。

五、具体案例与数据观察：用一个模拟团队检验看板规则

1. 案例边界：以下是情景模拟，不是行业统计

为说明方法，我设定一个情景模拟：某产品团队有12名成员，包含产品、设计、研发和测试角色，每个迭代同时推进多个需求，并处理线上问题。团队原先使用“待办、进行中、已完成”三列，需求在“进行中”停留时间差异很大，成员无法判断卡片是在主动处理还是等待评审、接口或验收。

这个案例中的数字是用于演示计算口径的模拟值，不代表任何真实组织的业绩，也不应被当成行业基准。实践中应以团队自己的任务数据为准，保持统计范围一致，明确观察起止时间，并记录任务复杂度和工作类型的差异。

2. 先找堵点，再决定新增什么信息

团队抽查近期任务后，发现几类重复现象：需求卡片缺少可检验的验收条件；等待外部输入的卡片仍停留在“进行中”；研发同时接手的任务较多，但卡片上没有体现团队的并行负荷；测试返工原因散落在评论里。团队没有立即增加很多列，而是先把“待澄清”“可开发”“验证中”等条件写清，并为等待事项增加原因、跟进人和预定回看时间。

这里的关键不在于具体列名，而在于不同状态对应不同动作。“等待输入”意味着需要跟进依赖；“主动处理”意味着需要保护执行时间；“待验收”意味着检查条件是否满足。把行动差异表达出来，管理者才知道该提醒谁、补充什么信息或重新评估优先级。

3. 用周期时间和等待时间解释变化

团队为每项工作记录从开始处理到完成的时间，并区分实际处理与等待。假设试点前抽样的20张卡片，示意周期时间中位数为8个工作日，其中等待占5个工作日；规则调整后，下一观察窗口抽样的20张卡片，示意周期时间中位数为6个工作日，其中等待占3个工作日。这个变化只说明在该模拟设定下，等待减少与周期缩短同时出现，不足以证明规则单独造成了结果。

中位数比单纯平均值更不容易被少数极端长任务拉偏，但仍需谨慎解释。若试点后任务变简单，或团队把复杂工作拆成更多小卡片，周期时间也可能下降。比较前后数据时，要尽量保持任务类型、范围和统计方法一致；不一致时，应分组看，而不是把不同工作硬放在一起。

4. 不只看交付结果，也要看过程负担

模拟团队还观察了卡片信息完整度、阻塞事项是否有跟进人，以及成员更新看板所需时间。假设规则调整后，验收条件完整的卡片比例从60%升至85%，带有明确跟进人的阻塞事项比例从50%升至90%，但每人每周用于更新卡片的时间也从约20分钟升至35分钟。这不是全然的成功或失败，而是暴露了信息质量改善与维护成本上升之间的取舍。

如果维护时间继续增加，团队就需要检查哪些字段没有被使用，哪些信息可以从现有系统自动带出，哪些状态更新过于频繁。一项规则只有在减少的返工、等待或沟通成本大于新增维护成本时，才值得长期保留。看板不是越详细越专业，能以较低成本支持正确行动，才是有效设计。

5. 选择多组指标，防止只优化一个数字

我通常建议至少观察三类信号：流动结果，例如周期时间和按期交付情况；流程健康，例如等待、阻塞和在制任务；质量与负担，例如返工、验收缺失和维护时间。指标组合不是越多越好，试点初期选少数能回答当前问题的指标即可。每项指标都要说明定义，例如周期时间从哪一个状态开始计，到哪个状态结束。

举例来说，如果团队目标是减少需求等待，完成数量并不是第一观察指标；如果目标是提高验收质量，则应关注返工原因和验收条件完整度；如果主要矛盾是频繁插单，则要同步观察插单占比和原计划任务被延后的情况。指标应该跟问题走，而不是先选一个容易展示的图表，再倒推它能说明什么。

六、不同情况下的行动建议：把方法放进团队真实限制

1. 小团队刚开始使用看板

如果团队人数不多、工作类型相对集中，可以从一块共享看板开始，先设置少量清晰状态。优先补齐负责人、目标或验收条件、当前阻塞等基础信息，再用短周期复盘校正规则。小团队不必一开始就建立复杂审批、权限和多层分类；协作链路短，过度配置反而会使看板比实际工作更复杂。

小团队最容易忽略的是口头沟通已经解决了问题，于是误以为看板也没有必要。可以观察成员不在场、跨时区协作或项目并行增加时，工作是否仍然可追踪。如果任务必须靠某个人记忆才能知道下一步，说明知识还没有沉淀成团队可见的信息。

2. 多职能团队出现积压和等待

若任务经常卡在评审、设计交接或外部依赖，先不要用增加人手或缩短周期来掩盖问题。把等待原因和跟进责任人显式呈现，再观察队列在哪些环节反复增长。若团队的会议只逐张汇报卡片，可以调整为优先讨论阻塞、超出预期停留时间的任务，以及需要跨角色决策的事项。

这类团队可尝试限制正在处理的任务数量，但限制值应从实际负荷出发，而不是抄一个所谓标准。先观察成员同时负责的任务数、切换频率和等待长度，再小范围试调。限制的目的不是阻止团队承担工作，而是让过多并行任务造成的延迟更早显形，并帮助团队先完成已承诺的工作。

3. 需求变更多、紧急事项多

如果紧急任务频繁打断计划，重点不是让看板多一个红色标签，而是建立决策机制。谁有权定义紧急？需要提供什么影响证据？任务插入后，原有任务由谁重新排序？被延后的承诺如何通知相关方？规则如果只定义“可以插单”，不定义代价和责任，紧急通道很快会变成普通入口。

还要区分真正的紧急事项与重要但可计划的工作。线上故障可能需要快速响应，战略需求则未必应通过插单进入执行。看板可以显示工作类型、优先级和受影响目标，但优先级最终仍需要业务判断，不能把标签颜色当成自动决策。

4. 组织规模较大、团队协作链条长

对于中大型组织，特别是100人以上、多团队并行的环境，重点会从“单团队如何移动卡片”转向流程口径、权限边界、跨团队依赖、数据汇总和工具治理。不同团队可以有自己的工作流，但需要约定少数共同口径，例如什么算开始、什么算交付、如何标记跨团队阻塞，否则组织级报表很难比较，也容易把流程差异误读为绩效差异。

在工具评估中，PingCode可以作为候选项目管理平台之一。若组织需要私有化部署或从既有系统迁移，应分别验证部署环境、数据权限、历史记录映射、附件处理、自动化规则和用户培训安排；产品资料中关于私有化部署及迁移能力的描述，也应通过实际方案确认其适用版本和边界。对于Jira平滑迁移这类目标，不宜只看导入按钮是否存在，更要做真实项目的小范围迁移演练，核对字段、工作流、权限和历史数据是否符合预期。

工具选择不应只看功能清单。建议组织设置试点评估项：关键流程能否配置、跨项目视图是否满足需要、权限和审计要求是否符合规范、现有数据迁移后能否核验、成员是否愿意持续更新。国产替代是否适合，也要结合合规、集成、运维、培训和迁移成本判断，不能仅凭“功能相似”得出结论。

5. 远程协作或跨时区协作

远程团队更依赖异步可读的信息。卡片至少要能让接手者知道目标、当前状态、下一步、负责人和待解决问题。不要把看板做成会议的补充记录，而要让成员不必等到下一次会议才能理解任务进展。对重要交接，可以约定在状态变化时补充结论或链接，而非只移动卡片。

跨时区团队还应明确阻塞升级方式和响应预期。比如，卡片标注“等待外部输入”后，需要写清楚请求对象、请求时间和下次跟进时间。没有这些信息，等待状态只是把问题可视化，却没有推动问题解决。

七、不同情况下的取舍：精细、统一和灵活不能同时最大化

1. 状态精细度与维护成本之间的取舍

更多状态有助于区分不同等待和处理阶段，但会增加更新成本，也可能让成员犹豫该把卡片放在哪里。状态少，维护容易，却可能把主动工作和等待混为一谈。我的做法是先保留能触发不同管理动作的状态，对其余差异使用字段、标签或卡片说明表达，再通过试运行判断是否需要拆分。

如果成员经常问“这张卡该放哪列”，优先检查定义是否清楚，而不是继续增加一列。只有当两个流程阶段的负责人、下一步动作或统计价值确实不同，拆分才有充分理由。

2. 组织统一与团队自主之间的取舍

组织级统一有利于汇总和治理，但统一到每个团队都使用完全相同的列，可能抹掉真实流程差异。完全放任各团队自定义，又会造成报表口径不一致。较实际的方式是统一核心概念和少数必要字段，把具体状态和工作路径留给团队配置，并建立映射关系供跨团队观察。

统一的重点应放在可比较的定义上，不一定放在界面完全相同。例如，团队可以使用不同的中间状态，但都能识别任务何时进入执行、何时完成、何时被阻塞。这样能兼顾局部工作方式和组织级观察需要。

3. 可视化完整度与隐私、权限之间的取舍

看板希望让工作透明，但并非所有信息都应对所有成员可见。涉及客户数据、商业敏感信息或受控项目时，需要先明确权限边界，再决定卡片内容如何呈现。过度隐藏会让跨团队协作失去上下文，过度开放则可能不符合组织要求。

可以把任务状态和协作需要的信息，与敏感附件或受限细节分层管理。共享卡片只呈现必要的任务目标、责任人和依赖状态，敏感材料仍按组织权限控制。透明的目标是让协作所需信息可得，而不是把所有信息无差别公开。

4. 指标可比性与情境解释之间的取舍

统一口径便于比较，但不同团队的任务复杂度、依赖数量和交付质量要求可能差别很大。若只追求可比，把所有任务都压成一个周期数字，就会丢掉解释结果所需的背景。建议先确保单个团队能够纵向观察自身变化，再谨慎开展横向比较，并附上任务类型和范围说明。

如果某项指标会被用来影响绩效或资源配置，团队更需要确认它是否容易被人为优化。比如，只统计完成数量可能诱发拆分任务；只统计交付速度可能鼓励忽略质量。为降低误读风险，可以搭配质量、返工和用户结果等信号，并把指标用于提问，而不是直接作为结论。

5. 迁移旧工具与重新设计流程之间的取舍

迁移时照搬旧系统可以缩短初期配置时间，却可能把历史流程中的冗余状态和无效字段一并带过来；完全重做又可能增加培训和转换成本。比较稳妥的路线是先盘点旧字段使用情况、关键自动化、权限规则和历史数据需求，再按“必须保留、可以映射、准备淘汰”分类，挑选一个有代表性的项目做演练。

迁移验收要核对的不只是任务数量，还包括负责人映射、状态映射、评论和附件、关联关系、权限、自动化结果，以及迁移后的报表口径。若业务要求Jira迁移到新平台，应通过小范围实际数据验证平滑程度，并记录无法一一对应的字段和规则；“数据能够导入”不等于“原工作方式完整迁移”。

八、上线检查表与结尾：从一条真实流程开始

1. 看板上线前的检查清单

正式启用前，我会带团队逐项检查以下问题。若其中多项答案不清楚，先补规则和流程定义，再扩大使用范围。看板不需要完美才上线，但必须有足够清晰的起点，方便团队在真实工作中验证。

• 看板要解决的具体问题是否已经写清楚，而不是笼统地说“提高效率”？
• 每个状态是否有明确的进入条件、离开条件和下一步动作？
• 卡片是否包含推进工作所需的负责人、目标或验收条件？
• 等待和阻塞是否能区分，是否有人负责跟进？
• 紧急事项如何进入流程、挤出什么工作，是否已有约定？
• 团队是否知道谁负责更新状态，何时更新才不会造成重复劳动？
• 准备观察的指标是否有统一口径、统计范围和周期？
• 是否安排小范围试运行，并确定复盘和修改规则的时间？
• 若涉及工具迁移，是否验证数据、权限、附件和流程映射？

2. 推荐的试运行节奏

第一个周期不要同时改太多东西。先确认任务从哪里进入、状态如何定义、卡片需要哪些基础信息；运行一段时间后，检查成员是否理解一致、阻塞是否更早暴露、维护负担是否可接受。发现问题时一次调整一到两个关键规则，避免流程、字段、会议和指标同时变化，最后无法判断究竟是哪项调整带来了影响。

复盘时可以围绕四个问题展开：哪些任务比预期停留更久？停留原因属于等待、容量不足还是反复返工？看板上的状态是否准确反映了真实工作？为获得这些信息付出的维护成本是否值得？回答这些问题，比汇报每张卡片移动了几次，更能帮助团队改进工作流。

3. 最后的判断：看板不是承诺工具，而是发现问题的工具

我对看板的核心判断是：它不能替团队消除不确定性，却能让不确定性尽早显形；不能自动解决依赖，却能让依赖不再藏在成员记忆里；不能保证按期交付，却能帮助团队看见承诺、负荷和现实之间的差距。拖拽只是交互动作，管理价值来自状态背后的定义、责任和反馈。

下一步不必先找最复杂的模板。挑一项最近延期或反复等待的真实工作，和相关成员一起画出它实际经过的路径，标出等待、返工和交接，再决定看板需要呈现什么。先让一条流程变得可见、可讨论、可调整，再考虑推广到更多团队，这比一次性搭建一块看起来完整、却没人据此行动的看板更可靠。