一、多团队共用看板的冲突问题
在软件开发或者项目管理过程中，多团队共用一块 Kanban 看板是很常见的情况。但这种共用往往会引发一些冲突。
比如，有两个团队，团队 A 和团队 B，共同使用一块看板来管理任务。团队 A 负责开发新功能，团队 B 负责修复线上问题。在看板上，有一个“待处理”列，两个团队的任务都会被放入这个列中。然而，由于没有明确的职责边界，团队 A 可能会把一些本应由团队 B 处理的问题也放入“待处理”列，而团队 B 可能会认为这些问题应该由团队 A 先进行初步分析。这样一来，就会导致任务处理的混乱，降低工作效率。
再比如，在看板的“进行中”列，团队 A 的成员可能会在没有告知团队 B 的情况下，把团队 B 的任务从“待处理”列移动到“进行中”列，这可能会让团队 B 的成员感到困惑，不知道自己的任务状态到底是怎样的。
二、职责边界的划分
2.1 明确团队职责
要解决多团队共用看板的冲突问题，首先要明确各个团队的职责。还是以上面的团队 A 和团队 B 为例，应该明确规定团队 A 负责新功能的开发，从需求分析、设计、编码到测试的整个流程。而团队 B 负责线上问题的修复，包括问题的诊断、修复和验证。
可以通过制定详细的文档来记录每个团队的职责范围。例如：
- 团队 A：
- 新功能需求分析
- 功能设计
- 编码实现
- 单元测试
- 集成测试
- 团队 B：
- 线上问题接收
- 问题诊断
- 修复代码
- 回归测试
这样，每个团队都清楚自己的工作范围，在看板上处理任务时就不会出现职责不清的情况。
2.2 任务归属判断
在将任务放入看板之前，需要明确任务的归属团队。可以通过一些规则来判断。比如，如果是关于新功能的需求，那么就属于团队 A；如果是线上出现的 bug 报告，那么就属于团队 B。
例如，当收到一个用户反馈的问题时，首先要判断这个问题是新功能的需求还是线上 bug。如果是新功能需求，就把任务分配给团队 A，并在看板上创建一个新的任务卡片，注明是新功能开发任务。如果是线上 bug，就分配给团队 B，并在卡片上注明是 bug 修复任务。
2.3 跨团队协作
虽然明确了职责边界，但在实际工作中，还是可能会出现跨团队协作的情况。比如，团队 A 在开发新功能时，可能需要团队 B 提供一些关于线上系统的历史数据或者技术支持。这时，就需要建立跨团队协作的流程。
可以通过创建专门的跨团队协作任务卡片来处理这种情况。例如，团队 A 需要团队 B 的数据，就在看板上创建一个“请求团队 B 数据”的任务卡片，将其放入“待处理”列。团队 B 看到后，处理这个任务，并将结果反馈给团队 A。
三、共享列权限划分
3.1 不同团队的权限差异
在看板上，不同团队对共享列应该有不同的权限。以“待处理”列为例，团队 A 和团队 B 都可以向这个列中添加任务，但是对于已经存在的任务，只有任务的归属团队或者有特定权限的人员才能进行修改或移动。
比如，团队 A 创建的任务，团队 B 只能查看，不能直接移动到“进行中”列。只有团队 A 的成员或者经过授权的人员才能进行这样的操作。
3.2 权限设置示例
以一个基于网页的看板系统为例，假设使用的是 JavaScript 技术栈。可以通过以下方式来设置权限：
// 定义团队 A 和团队 B
const teamA = {
name: '团队 A',
canAddToTodo: true,
canModifyOwnTasks: true,
canMoveOwnTasks: true
};
const teamB = {
name: '团队 B',
canAddToTodo: true,
canModifyOwnTasks: true,
canMoveOwnTasks: true
};
// 定义任务对象
const task = {
id: 1,
title: '新功能开发任务',
team: teamA,
status: '待处理'
};
// 模拟团队 A 成员操作
function teamAMemberOperation() {
// 团队 A 成员可以添加任务到待处理列
if (teamA.canAddToTodo) {
console.log('团队 A 成员添加任务到待处理列');
}
// 团队 A 成员可以修改自己的任务
if (task.team === teamA && teamA.canModifyOwnTasks) {
console.log('团队 A 成员修改任务');
}
// 团队 A 成员可以移动自己的任务
if (task.team === teamA && teamA.canMoveOwnTasks) {
console.log('团队 A 成员移动任务');
}
}
// 模拟团队 B 成员操作
function teamBMemberOperation() {
// 团队 B 成员可以添加任务到待处理列
if (teamB.canAddToTodo) {
console.log('团队 B 成员添加任务到待处理列');
}
// 团队 B 成员不能修改团队 A 的任务
if (task.team!== teamB &&!teamB.canModifyOwnTasks) {
console.log('团队 B 成员不能修改团队 A 的任务');
}
// 团队 B 成员不能移动团队 A 的任务
if (task.team!== teamB &&!teamB.canMoveOwnTasks) {
console.log('团队 B 成员不能移动团队 A 的任务');
}
}
// 调用团队 A 成员操作函数
teamAMemberOperation();
// 调用团队 B 成员操作函数
teamBMemberOperation();
通过这样的权限设置，可以确保每个团队只能在自己的权限范围内操作看板上的任务，避免冲突的发生。
3.3 动态权限调整
在项目进行过程中，可能会需要对团队的权限进行动态调整。比如，当团队 A 的某个成员临时加入团队 B 进行协作时，需要给他赋予团队 B 的一些权限。
可以通过系统管理员或者特定的权限管理流程来进行动态权限调整。例如，系统管理员可以在后台修改该成员的权限设置，使其能够在团队 B 的任务范围内进行操作。
四、应用场景
多团队共用看板在很多场景下都有应用。比如在一个大型软件项目中，有多个开发团队、测试团队和运维团队。开发团队负责不同模块的开发，测试团队负责对开发完成的模块进行测试，运维团队负责线上系统的维护和问题修复。
这些团队可以共同使用一块看板来管理任务。开发团队将开发完成的模块任务放入看板的“待测试”列，测试团队从该列获取任务进行测试，测试完成后将任务放入“待上线”列，运维团队从“待上线”列获取任务进行上线部署。
再比如，在一个敏捷项目中，有多个小组同时进行不同特性的开发。每个小组都可以将自己的任务放入看板的共享列中，通过看板来协调工作进度和资源分配。
五、技术优缺点
5.1 优点
- 提高工作效率：通过看板可以直观地看到任务的状态和进度，团队成员可以快速了解项目的整体情况，从而更高效地进行工作。
- 促进团队协作：多团队共用看板可以让不同团队之间更好地沟通和协作，避免信息孤岛的出现。
- 便于管理和监控：管理者可以通过看板实时监控项目的进展情况，及时发现问题并进行调整。
5.2 缺点
- 冲突风险：如前面所述，多团队共用看板可能会引发职责边界不清和权限划分不当等冲突问题。
- 系统复杂度增加：为了解决冲突问题，需要对看板系统进行更复杂的配置和管理，增加了系统的维护成本。
- 学习成本：团队成员需要学习如何正确使用看板以及相关的规则和流程，这可能需要一定的时间和精力。
六、注意事项
6.1 建立清晰的规则
在多团队共用看板之前，必须建立清晰的规则，包括职责边界、权限划分、任务处理流程等。这些规则应该明确、具体，并且得到所有团队的认可。
6.2 培训团队成员
要确保所有团队成员都了解看板的使用方法和相关规则。可以通过培训、文档说明等方式来进行。
6.3 及时沟通和协调
在使用看板的过程中，团队之间可能会出现各种问题和冲突。这时，及时沟通和协调非常重要。可以通过定期的会议、即时通讯工具等方式来进行沟通。
6.4 持续优化
看板的规则和权限设置不是一成不变的，需要根据项目的进展情况和团队的反馈进行持续优化。
七、文章总结
多团队共用一块 Kanban 看板在提高工作效率和促进团队协作方面有很大的优势，但也面临着职责边界不清和权限划分不当等冲突问题。通过明确团队职责、合理划分共享列权限、建立清晰的规则和流程、培训团队成员、及时沟通协调以及持续优化等措施，可以有效地解决这些问题，使看板在多团队协作中发挥更大的作用。同时，在应用过程中要注意权衡技术的优缺点，遵循相关的注意事项，以确保项目的顺利进行。
评论
围绕“多团队共用一块Kanban看板引发冲突，职责边界与共享列权限划分经验谈”参与讨论