驾驶舱看板这四个字在企业数据圈里早就不是新鲜词了。从销售大屏到生产监控从管理层驾驶舱到门店经营仪表盘几乎每个企业都在做但真正做得好、用得起来、坚持用下去的说实话不多。我这些年参与过大大小小十几套看板项目最大的感受是选型阶段埋下的雷后期上线运行的时候一定会爆。而选型困局的根本原因往往不是产品功能不够而是需求方和采购方根本没想清楚“好用、不贵、有保障”这三个词到底意味着什么。这篇内容不是产品测评也不是厂商软文而是我梳理的一套选型思考框架和实践方法。适合正在为团队挑选数据可视化工具的决策者、信息化负责人也适合被领导临时抓壮丁去做选型调研、却不知道从哪下手的同学。我会把“好用”拆成可落地的评估项把“不贵”算成含隐性成本的总账把“有保障”落实到合同条款和技术架构层面同时分享我们踩过的坑和总结出的选型流程希望能让你在选型这件事上少走弯路。1. 驾驶舱看板的核心价值不只是“好看的大屏”1.1 从报表到驾驶舱企业数据消费方式的转变传统的企业报表本质上是“被动查数”——业务人员想了解某个指标需要打开报表系统找到对应菜单设置查询条件然后翻看一张张表格。这个过程有几个天然短板一是滞后报表往往是T1甚至T3生成业务已经发生了数据还在路上二是割裂销售额、库存、客诉、人效分散在不同系统里想看全貌得开好几个页面三是对人不友好密密麻麻的数字堆在一起领导扫一眼根本抓不住重点。驾驶舱看板解决的正是这三个问题。它把核心经营指标集中到一个界面上用图形化方式呈现并且尽可能做到准实时刷新。管理者打开就能看到“今天卖了多少、哪个区域掉量、库存哪些超警戒线”不需要再等别人做PPT汇报。我服务过的一家连锁零售企业之前每周一上午要花两个小时开经营分析会销售、运营、供应链各拿一份报表对着念自从上了驾驶舱会议缩短到四十分钟因为大多数异常在会前就已经通过看板暴露出来了。1.2 “驾驶舱”这个名字背后的产品逻辑“驾驶舱”这个词很形象。飞机驾驶舱里的仪表盘不会把所有飞行参数都堆在飞行员面前而是按照重要性分区布局关键指标放在视线中心告警信息用颜色突出飞行员扫一眼就能知道当前状态。企业驾驶舱看板的逻辑是一样的——它本质上是决策者的“仪表盘”核心任务是帮助人快速理解现状、发现异常、做出判断而不是展示数据的“艺术画廊”。这也解释了为什么很多看板项目会失败团队把精力花在了炫酷的3D特效、动态地图、飞线动画上却忽略了最基础的信息架构设计。有一次评审一个物流企业的调度大屏整屏都是车辆移动的3D动效看着确实震撼但关键问题来了——现场的人根本说不清“今天异常订单率是多少”到底显示在哪里。这种项目就是典型的本末倒置。1.3 选型困局是怎么形成的供给端概念繁多需求端标准缺失选型难首先难在供给端。市面上的驾驶舱看板产品粗略分一下至少有四类第一类是报表BI工具的延伸比如一些传统报表厂商增加了大屏配置功能第二类是专业的可视化大屏工具主打酷炫效果和快速搭建第三类是云厂商的商业智能套件依托云生态提供一体化能力第四类是开源方案技术团队自己基于开源组件搭一套。每类产品都有自己的话术有的说“拖拽生成大屏”有的说“支持任意数据源”有的说“私有化部署安全可控”听起来都很美。但如果需求方没有一个清晰的选择标准就很容易被这些概念拖着走。更麻烦的是很多企业选型时只看两个东西——功能列表和价格却忽略了“能不能用起来”这个核心命题。功能列表可以很长但其中大量功能可能是你永远用不到的价格可以很低但实施、维护、培训、二次开发的隐性成本可能远超预期。2. “好用”的硬标准把体验拆成可验证的指标2.1 先问清楚看板到底给谁用、看什么、多久看一次我做过一个很简单的诊断方法选型之前把公司里可能的看板使用者列一个清单每个角色回答三个问题你看哪些指标你多久看一次你看到异常之后会做什么这三个问题的答案直接决定了你要选什么样的产品。高管看板看的是宏观经营指标通常是每天早上打开看一眼关注同比环比和异常预警使用场景大都是办公室里的大屏或电脑浏览器一线业务看板比如仓储管理看板、呼叫中心实时监控看的是过程的实时状态可能需要7x24小时挂在墙上操作频繁还有一种数据分析型看板是分析团队自用的需要支持维度钻取、联动筛选这些交互操作对灵活性的要求非常高。这三种场景对产品的要求差异很大。高管控的看板数据刷新频率按天或按小时就够但信息层级要清晰颜色语义要统一一线实时监控看板对数据延迟和稳定性要求极高刷新慢几秒钟都可能出问题分析型看板则要求产品在图表交互上有足够深度。选型最忌讳的就是“一套方案包打天下”买之前先确认核心场景是哪一类再去找匹配度最高的产品。2.2 上手成本的可量化评估数据接入、配置效率、学习曲线“好用”这个词听起来主观但完全可以量化成三个可测试的指标。第一个是数据接入时长。拿真实业务数据源过去测记录从配置数据连接器到跑通第一张基础图表一共花了多长时间。我们之前测过一家产品号称“支持百种数据源”结果连自家企业最常用的某个数据库版本都要写脚本二次加工光数据接入就折腾了两个礼拜这就不叫好用。第二个是配置效率。理想状态下一个熟练的实施人员搭建普通主题看板8到10个图表一天之内应该能完成从数据接入到页面发布的全流程超过这个时间说明产品在配置层的学习成本偏高。第三个是业务人员的自助能力。产品是不是只有开发人员才能玩得转业务人员经过半天培训能不能自己调整指标口径和布局如果所有改动都得提工单找IT那这个产品再强大在业务眼里也算不上好用。2.3 大屏不是炫技场信息密度、视觉语义、交互反馈的平衡大屏是驾驶舱看板最常见的落地形态但恰恰在大屏上大家最容易犯“为了炫而炫”的错误。真正做得好的大屏有几个共性信息分区符合阅读习惯核心指标区居中放大辅助分析区在两翼底部是趋势图或明细表颜色有语义红色代表告警、绿色代表正常而不是赤橙黄绿青蓝紫胡乱往上堆动效克制数据刷新和数据变化动效是加分项但如果动效影响了数据可读性就是减分项。交互设计也很关键。看板不是静止的展示品用户在看大屏时经常需要点击某个区域查看明细或者联动调整筛选条件。这里要重点考验产品的交互反馈速度。我测过一套产品在大屏上点击某个省区联动刷出该省区的明细数据前后花了五六秒用户基本就失去耐心了。好的产品在交互反馈上应该做到一两秒内响应否则驾驶舱就成了“观赏屏”。2.4 性能与可扩展性10个图表和1000个图表是两种产品很多产品在Demo环境里跑得很流畅因为Demo只有几个图表、几千条数据。但到了真实环境企业的大屏往往要同时呈现几十个图表背后关联的数据量可能是几千万行还要支持多人同时在线访问。性能在这时候就成了“好用”的硬门槛。做性能测试的时候我建议直接要求厂商提供大并发、大数据量场景下的压测报告或者干脆让他们用你的真实数据搭一套原型来跑。重点关注两个指标一是页面加载时间从打开页面到所有图表渲染完成最好控制在3秒内二是刷新延迟数据更新到图表反映出来的时间差取决于产品是主动轮询还是通过消息推送机制后者的实时性通常更好。另外要考虑扩展性——看板从10个图表增长到1000个图表从单屏扩展到60多个主题页面产品的维护成本和性能衰减是否可控这决定了未来两三年你还要不要再做一次选型。3. “不贵”的成本账别被一次性报价带偏了3.1 看得见的钱产品许可、订阅费用、实施费用的对比逻辑选型比价的时候最常见的错误就是只比较产品报价单上的数字。但实际采购成本远不止这些。先看许可模式有的产品按用户数收年费有的按部署节点收费有的是整套买断。不同模式对企业的影响差异很大。按用户数收费的产品如果企业人数多、但真正高频使用看板的人只有几十个那按“并发数”或“大屏数”计费的模式可能更划算按部署节点收费的则要特别注意多环境生产、测试、灾备部署会不会被重复收费。实施费用也是一块容易被低估的钱。很多产品标价看起来不高但默认配置只包含标准功能想接入企业微信、打通OA审批、定制数据口径全部要算实施人天。我们在一个项目里产品采购费用只占四成实施服务费占了六成这个比例在行业内并不罕见。所以比价的时候一定要把实施范围清单拿到手明确哪些工作包含、哪些要额外收费、人天单价是多少。3.2 看不见的钱二次开发、运维投入、用户学习与替换成本隐性成本比显性成本更值得关注。第一款是二次开发成本。有些产品宣称“零代码”但真正用起来会发现稍微复杂一点的业务逻辑比如跨系统数据关联、复杂的指标计算公式还是逃不掉写脚本、做接口这部分工作量需要自己的技术团队消化。第二款是运维成本。私有化部署的产品版本升级、服务器监控、数据备份都是持续投入如果产品本身运维工具做得差这些工作会消耗大量IT人力。第三款是用户学习成本。一个反直觉但真实存在的现象是越便宜甚至免费的工具总学习成本反而可能越高因为使用者得自己摸索、自己趟坑、自己维护时间成本最终会折算成真金白银。替换成本更是一个容易忽略的大项。数据资产管理不好、看板指标口径混乱、页面配置和权限体系深度绑定这些问题一旦积累再想换平台就非常痛苦。我接触过一个客户旧BI系统用了五六年积累了上千张报表、几百个数据模型想换平台时一评估迁移成本高到团队直接放弃了更换念头。选型时不考虑替换成本未来就会被这个成本绑架。3.3 用三年总拥有成本来算账一个简单的估算模型我建议选型团队用“三年总拥有成本”Total Cost of Ownership, TCO模型来做预算评估而不是只看第一年的采购报价。TCO的粗略公式是三年总成本 首年采购和实施费用 每年订阅/维护费用 x 2 预估二次开发和运维投入 x 3 内部用户学习成本可按人天折算。举个例子A产品首年总费用20万年维护费4万预估内部年投入开发运维15人天按1500元/人天折算就是2.25万三年TCO大约是2086.7534.75万。B产品首年总费用35万年维护费可以忽略内部投入因为产品易用性好可以减半三年TCO大约是3503.438.4万。表面上看A的首次采购价更低但三年算下来两者差距并不大这时决策因素就应该转向产品能力和服务质量而不是单纯看报价单上的数字了。3.4 免费或开源的“真香”陷阱技术能力不足时免费方案反而更贵还有一个不得不说的选项开源免费方案。很多技术团队在选型时会倾向这个选择觉得代码在自己手里想怎么改就怎么改也不受厂商限制。这个思路本身没错但有个前提——团队必须有足够的数据可视化、前端工程化、性能优化和长期维护能力。开源方案意味着从图表组件选型、权限系统开发、数据源适配到服务器运维全部要自己扛。我们之前评估过一个开源方案从搭建到跑通第一个仿驾驶舱原型花了两个人整整一周时间。而如果按普通研发人天成本折算这一周的成本已经接近一套中低端商业产品一年的订阅费用了。这里不是说开源方案绝对不划算而是说要客观评估自身团队的工程能力和维护预算。如果你们有一个三人以上的专职前端和数据团队开源方案值得考虑如果只是IT部门顺带维护那就别在这个环节省钱“免费”的往往是最贵的。4. “有保障”的深层考量覆盖技术、服务、持续演进的全面保障4.1 技术保障部署架构、稳定性、性能兜底看板产品一旦进入生产环境就是每天都要跑的业务系统稳定性比功能多寡更重要。选型时要重点审查几个技术层面的保障能力。部署架构上要能支持高可用部署应用节点和数据库不能是单点否则一次宕机就可能让核心大屏集体黑屏。我们还遇到过更糟的情况一套产品部署后连基本的集群模式都不支持扩容必须停服务这种产品在规模上来之后会成为巨大隐患。稳定性还体现在故障恢复上。看板系统崩了多长时间能恢复有没有自动故障转移机制数据链路中断后页面是显示旧数据还是直接报错这些细节都是产品成熟度的试金石。性能兜底也很关键产品有没有对超大数据量查询的降级策略比如缓存、预聚合、异步加载而不是等用户把页面打开后一直加载转圈。4.2 服务保障从SLA到人服务能力才是长期使用的底气产品合同里的SLAService Level Agreement服务水平协议是服务保障的核心凭证。签合同之前至少把这几条看清楚系统可用性承诺是几个9响应时间要求是几分钟内故障处理有没有分级机制比如一级故障必须几小时内恢复运维期内产品升级谁负责、升级窗口怎么安排、要不要额外收费比SLA更实在的是服务团队。“本地有没有原厂支持”“实施顾问是不是固定人员”这些细则往往比产品本身更能影响使用体验。我们的经验是一定要在合同里约定“多级支持机制”也就是一线问题由谁响应、复杂问题由谁升级、产品缺陷由谁修复每一层都要有明确的责任人和时限。有些产品买卖前销售天天驻场一旦合同签完实施顾问就再也约不到了这种例子在行业里太多了。4.3 产品演进保障Roadmap、版本兼容、社区活跃度选型买的不是当下而是未来两三年能不能持续成长。考察产品团队的技术方向是否清晰产品Roadmap是否可预期版本更新的节奏是多久一次升级是不是需要另付一大笔费用。如果产品三个月不更新一次面对未来可能出现的新数据源、新可视化方式能力会越来越跟不上。社区和生态也是产品生命力的一部分。是否有活跃的官方社区、有没有丰富的模板和插件市场、问题反馈是否有人及时响应这些都能看出产品背后团队的长期投入意愿。对于开源生态更不必多说但如果选商业产品生态丰富度同样值得关注——好的生态意味着你遇到的大部分问题别人早就踩过并给出了解法而不是什么都靠自己和厂商反复沟通。4.4 数据安全与权限合规红线不能碰数据安全是选型中不可妥协的底线。评估产品时至少要看四件事一是权限模型是否精细能不能做到“不同角色看不同页面、同一页面不同人看不同数据范围”二是操作审计谁能改指标口径、谁改了、什么时候改的这些都需要有日志记录三是数据传输和存储的加密方式四是私有化部署时数据是否完全留在企业内网云服务模式下数据传输链路是否合规。审计日志这块很多企业在选型时完全不看上线后踩坑才发现问题。我们有个项目某个部门领导觉得某指标口径不对直接在生产环境改了配置改完也没有任何记录。后来财务复盘发现数据对不上查了两周才定位到是配置被改动这就是权限和审计缺失的代价。5. 一套可复用的选型实操流程六步走不踩雷5.1 第一步先梳理业务场景再用关键指标清单驱动选型选型不是IT部门的独角戏第一步必须是业务调研。盘点一下公司里哪些岗位需要看板他们现在怎么获取数据、作决策的有哪些痛点如果让你列一个“希望一打开就能看到”的指标清单每个岗位能列出什么这些信息的汇聚结果就是选型的起点。这一步的产出物是一份“看板需求说明书”。它不需要写得很长但至少要包含使用者角色清单、每个角色的核心指标、使用频率、使用场景办公室大屏、会议室投屏、电脑桌面、移动端。拿到这份说明书再去比对各产品时就能很快筛掉明显不合适的选项而且后续跟厂商沟通时也有据可依不容易被对方的Demo牵着鼻子走。5.2 第二步圈定候选产品建立评估维度和打分表根据需求说明书初步筛选4到6款产品进入候选池。筛选的原则是优先考虑已经在同行业、同规模企业有成熟案例的产品少碰那些听起来完美但根本找不到落地案例的“全能型”产品。然后制定评估维度我常用的维度有六个功能匹配度、易用性、性能与稳定性、成本三年TCO、服务能力、数据安全合规。每个维度设置权重权重根据企业的核心诉求调整。比如你们最看重成本那成本维度权重就调高如果最看重业务自助分析易用性配高分。打分不要只在会议室里凭印象打后续的POC测试结果要回填进来形成“演示印象分测试实测分”的复合评分这样才不会被华丽PPT影响判断。5.3 第三步POC验证是选型的关键环节用真实数据跑一遍对于走到决赛圈的两三款产品一定要做POCProof of Concept概念验证而且要用企业自己的真实业务数据不能只看厂商提供的那种十全十美的Demo。POC至少要覆盖这几个场景接一个真实数据源搭两条主题看板分别模拟高管驾驶舱和一线业务监控测试数据权限隔离模拟多人同时在线访问用你们最关心的性能指标压一下。整个POC周期控制在两到三周安排内部业务代表参与评测让他们从使用者角度评分。这个过程不仅是在测产品也是在磨合团队——看看厂商的实施顾问是否专业、响应是否及时这些体验会直接影响后续长期合作。5.4 第四步合同与服务条款不能只看法务业务和技术都要介入很多项目在合同环节翻车就是因为只看产品价格忽视了服务条款。合同评审时技术负责人要确认部署架构、性能指标、扩展性承诺有没有写进去业务负责人要确认交付范围、验收标准、培训计划采购和法务要盯着SLA条款、数据安全条款、违约和退出机制。我特别建议在合同里把“免费支持服务期限”和“服务期内的响应时限”写得清清楚楚。很多人在这一步会问这些细节厂商真的会写进合同吗其实正规厂商在标准合同里就有这些条款关键在于你有没有逐条核对。那些条款写得含糊其辞的供应商十有八九后续服务也靠不住尽早回避反而是省事。5.5 第五步试点先行用最小成本验证真实效果大范围推广前一定要先做试点。试点可以选择一个业务相对独立、数据基础较好、负责人配合度高的部门范围控制在1到2块看板、10到20个用户。试点周期通常四到六周目标不是“上线”而是验证几个问题数据能不能稳定更新业务人员看不看、用不用指标口径对不对有没有被业务挑战试点期间的反馈要形成书面记录特别是业务人员提出的“数据不准”“刷新太慢”“这个字段不是这个意思”之类的意见。这些反馈一方面用来优化看板另一方面也是和厂商谈后续服务质量的重要依据。如果试点阶段业务人员都叫好推广才是有底气的如果试点就骂声一片及时止损换方案还来得及。5.6 第六步上线后还要做持续的运营与迭代选型完成不是终点上线后才是考验的开始。看板上线后要建立一套常态化的运营机制包括指标口径变更流程、页面新增需求的排期、数据质量监控、季度使用情况复盘。很多企业上线时轰轰烈烈三个月后大屏上的数据还在但已经没人打开了——这就是缺乏运营机制的表现。运营机制的要点是“让数据生态保持活性”。引导业务部门提出新的指标和看板需求把这些需求纳入每季度迭代版本在业务稳定期可以主动分析用户的使用日志看看哪些看板是高频使用的、哪些是上线后就被遗忘的用数据来指导后续的迭代方向和优先级。6. 选型常见弯路与避坑经验那些在实操中被验证过的教训6.1 被炫酷Demo带偏忽略了日常使用的真实场景厂商的Demo设计得漂亮几乎是行业标配。漂亮的动画、动态的3D地图、流畅的联动交互会给人留下“这个产品很强”的印象。但Demo只是商品橱窗真实业务环境里不会有人给你精心打磨好每一个图表的配色和数据口径。我的建议是在选型现场可以看Demo但别让Demo主导判断。你可以主动要求厂商现场接入一个你们提供的数据源文件现场做一个最简单的看板这个过程最能暴露产品的真实上手难度。另外多问一些“刁钻”问题比如“数据口径计算能支持复杂的SQL逻辑吗”“移动端展示兼容性怎么样”“权限可以按行级控制吗”这些细节才是日常使用的常态。6.2 只比功能清单不比“生态服务”功能列表无意义有些企业选型时喜欢拉一张长长的功能对比表每个产品有哪些功能就打个勾。功能齐全的产品并不少但真正的问题在于每家公司默认的“功能”定义其实差异巨大。有的产品“支持地图”就只是静态地图有的产品则支持GIS自定义图层和轨迹回放有的产品“支持权限控制”只限于角色级有的则能做到行列级数据权限。这些差异化细节在功能清单上看起来都差不多实际用起来却是两个世界。比较好的做法是把高频使用的20个关键功能挑出来在POC阶段逐一验证验证结果直接打分比功能清单上的打勾可靠得多。6.3 定制化需求过多威胁到产品标准化升级大屏看板项目最常见的一个坑是前期定制需求失控。业务部门看到看板后总会有各种千奇百怪的想法“这个地方加个动画”“这个区域能动态轮播”“我们公司的Logo和主色调要定制上去”。如果所有定制都塞进第一版项目周期会被无限拉长更重要的是产品后续升级会变得极其困难——定制越深标准化版本的更新就越难平滑迁移。我有一次在项目管理中把一个部门的全部定制需求做了分类必须的、可以延后的、可以找替代方案的。最终真正进入第一版的定制项缩减到总需求的三成以下。这个做法的好处是既保住了核心业务价值也为产品的后续演进留了空间。把它作为一条选型原则优先选择那些“配置化能搞定大多数定制需求”的产品而不是“所有需求都要改代码”的产品。6.4 数据质量问题推给看板工具导致项目暂停甚至失败看板本身只是一个数据呈现的载体如果源数据有问题看板做得再精美展示出来的也是错误信息。数据质量问题通常表现为系统间数据不一致、字段口径不统一、数据更新不及时、历史数据缺失。这些问题在选型时很难暴露但在上线阶段会集中爆发。应对方式是在选型阶段就把数据质量检查纳入计划先梳理关键指标的数据来源和数据链路和业务确认统一的指标口径再考虑技术实现。如果数据基础太差建议先做数据治理项目或者在看板项目里单独划出一块时间做数据清洗和口径对齐。否则看板项目可能会变成数据问题的大曝光现场而不是决策利器。6.5 选型常见问题速查一张表帮你快速排查常见问题典型表现排查建议需求不明确就开始选型没有业务场景清单被Demo牵着走先做业务调研产出需求说明书只比功能清单和价格忽略二次开发、运维和替换成本用三年TCO模型做评估不看POC只用厂商Demo上线后才发现数据接入困难、性能不达标坚持用真实数据做POC合同服务条款模糊SLA、响应时长、升级费用未约定逐条核对SLA和分级支持机制定制过多威胁标准化升级升级困难、版本兼容性差控制定制范围优先选配置化产品上线即解散团队没有运营机制看板逐渐被遗忘建立常态化运营和数据更新机制6.6 一些容易被忽视但很关键的细节权限模型要细到行列级。驾驶舱看板经常需要给不同层级的人看不同范围的数据区域经理只能看自己区域的业绩总部能看到全国大盘这些都要靠细粒度的权限控制来实现选型时这个能力要重点测试。权限和审计日志要方便追溯。出了数据问题能不能快速定位到是谁修改了指标配置、什么时间改的、改之前的值是多少一款成熟产品应该在不影响性能的前提下记录完整的审计跟踪。移动端支持和消息推送值得重点考虑。很多企业的管理层不是每天坐在电脑前看的手机端的适配体验直接决定了看板的打开率。有些产品能通过企业微信、钉钉等入口把关键指标和异常预警推送到手机上这种主动触达能力比“等用户来看”有效得多。7. 一次实操经验与几点个人体会最后说说我印象最深的一次选型经历。那是一家年营收十几亿的制造企业IT团队在选型时纠结了大半年先后看了七八家产品。后来我们介入第一件事不是比产品而是花三天时间做了业务调研梳理出高管层、销售部、生产部、采购部四个核心场景并和各部门负责人逐一对齐了指标口径。调研结果出来后原来有些看起来“非做不可”的需求实际上只是某个部门领导一时的想法根本不用纳入第一版。然后我们选定两家产品进入POC一家主打炫酷视觉另一家功能均衡但界面朴素。用真实数据跑了两周后业务代表们给“朴素”那家的可用性打分反而更高因为数据刷新稳定、权限控制灵活、交互反馈快而“炫酷”那家在数据量稍大时页面有明显卡顿。最终选型结果帮企业省下大约三成预算关键是上线后业务使用率一直保持在比较高的水平。选型这件事本质上是在约束条件下做价值最大化。预算有限、技术资源有限、业务期望却很高这种张力会一直存在。我的个人体会是不要试图一次性找到“完美产品”而是找到“当前阶段最适配、且能陪你走一段的路”的那个产品。好用的产品让用户每天愿意打开不贵的方案让团队没有财务压力有保障的服务让产品在出问题时有人兜底。三者齐备驾驶舱看板才能真正成为企业数据决策的日常工具而不是面子工程。最后分享一个小技巧在POC阶段让厂商的顾问用你们的数据当场画一块“管理驾驶舱”的样板同时记录下从零到上线的全过程周期。这个数字比任何销售话术都有说服力——产品的实施效率、顾问的专业度、产品的配置灵活度全都浓缩在那一块看板的搭建时间中了。