这套系统里的工作如何运转？
各部门的诉求以卡片进“需求”列，讲的是问题而不是现成方案：哪个流程卡壳、谁受其苦、白耗多少时间。卡片移入“分析”列，分析师与提出部门坐下来弄清实际流程，把需求与验收标准写上卡片。获批后进入“开发”列，工程师分阶段交付；再到“测试”列，由提出部门的用户亲自试用并记录意见；成熟后“上线”面向全员。旅程不止于上线：卡片进入“推广”列，跟进员工使用与培训；再到“效果评估”列，记录工具对其目标流程的真实改变。
聊天用于工程师的日常协同，以及与提出部门之间的紧急需求确认。论坛留档技术决策、重大需求讨论与上线后复盘，让后加入的同事看得懂设计取舍的来龙去脉，同样的争论不必重来。
应用负责人接收需求、排优先级、签批进入“开发”；分析师从“分析”到“测试”验收全程陪护卡片；工程师开发并处理意见。“效果评估”的结果回到应用负责人手里做决定：二期迭代、维持现状，或没人用就正式下线。
谁负责什么？
这套系统中的运营角色，以及每个角色在日常工作中的职责——可以原样指派给你的团队，也可以按你们的实际情况调整。
内部应用负责人
接收各部门需求并排优先级，签批从“分析”进“开发”、从“测试”进“上线”。
业务分析师
分析提出部门的诉求，把需求与验收标准写上卡片，陪用户测试直到验收。
开发工程师
在“开发”列卡片上建造应用、处理“测试”意见，技术决策在论坛随做随记。
推广与培训协调员
上线后带员工认识并用好工具，在“推广”与“效果评估”列收集使用数据。
从第一天起就为你准备好什么？
系统单元
- 任务 — 带有工作流列和执行卡片的看板
- 聊天 — 团队快速日常协调频道
- 论坛 — 在有序版块中留痕的讨论——决策与知识永不丢失
论坛版块 (4)
- 技术决策内部应用建造中架构与工具选型的留档及理由——后来接手代码者的依据。
- 需求与部门讨论与提出部门就重大需求的深入对话，成熟后再转正式分析。
- 上线后复盘每次上线哪些顺、哪些卡——为后续项目留档的教训。
- 创意与改进新内部工具或存量工具改进的建议，来自团队与用户反馈。
«本系统工作规则» — 已在论坛置顶
1. 无获批分析不动工：没有成文需求与验收标准，卡片不得进“开发”。 2. 提出部门的当事业主参与测试——未经其验收不上线。 3. 技术决策在论坛随做随记，不事后补。 4. 上线须走完推广与留档的成效衡量，才算完成。 5. 没人用的工具以留档决定正式下线，而不是任其荒废。