最近，我参与了一场激烈的对话，起因是一个简单的评论：“团队必须被管理。” 这个评论让我意识到我与对话者不在同一个频道上。
我当时正在讨论设计组织角色的重要性，这些角色不会成为瓶颈（不会阻止组织高效交付或快速适应变化的的角色）。在经典的组织设计中，我们倾向于认为在组织结构图上设计方框并安排优秀的人员负责就能解决我们所有的问题。这种方法可能在静态环境中有效，在静态环境中，您要交付的内容是一劳永逸地确定的。
但是，如果您的环境不断变化，您需要使您的价值主张适应这些变化。您的组织需要具有适应性。
我的对话者正在设计新组织的方框。他关注的是将对某些群体负全部责任的经理和对组成这些群体的团队负全部责任的团队领导。静态的群体、静态的角色、静态的职能。
但是，如果您依赖于超负荷的人员处理多项职责，您就无法在组织中实现适应能力。我提出了一个替代方案：围绕非瓶颈角色设计的自组织团队，团队成员可以全职或兼职承担这些角色。
不幸的是，我的对话者跳到了结论，认为我的目标是从组织中移除所有经理和团队领导——好像自组织团队和管理在某种程度上是互斥的。
不完全是。
管理自组织团队
《开放组织定义》列出了五个特征作为开放性的基本条件
- 透明度
- 包容性
- 适应性
- 协作
- 社区
在尝试实现大规模透明度和协作时，我最近讨论了使工作可见的重要性。在这里，我更关注适应性——创建没有单点故障的团队，能够更好地适应动态环境中不断变化的条件的团队。
我同意团队必须被管理，并且我认为我们视为经理或团队领导的唯一责任的许多活动实际上可以直接委托给团队——或者委托给可以有效交付服务于团队的活动的团队成员。
因此，从我的角度来看，团队必须被管理，但很大一部分管理工作可以由团队自身完成，从而创建一个自我管理的团队。
让我们回顾一下其中的一些活动
- 理解业务和组织发展的生态系统
- 理解我们为什么提供解决方案、产品、功能、服务并制定清晰的愿景
- 定义需要交付什么以及何时交付
- 确定如何架构
- 确定如何实施
- 定义如何进行文档记录、演示和测试
- 在团队成员之间分配工作
- 交付工作
- 实施文档记录、测试
- 进行演示
- 收集来自用户和利益相关者的反馈
- 确保工作成果持续流向客户或用户，并确保每次更改都自动触发测试
- 改进团队的工作方式，提高其影响力和可持续性
- 提高由不同团队组成的更大系统的效率
- 支持使用该产品的客户和合作伙伴
- 促进用户、客户和合作伙伴在定义和实施产品或服务方面的协作
- 定义团队成员的薪酬
- 控制团队成员的绩效
- 支持和发展团队中的人员
- 招聘人员
当我查看这些活动时，我看到有些活动可以委托给团队自身建立的系统——例如，工作的分配。只需让每个人都看到工作，就可以使团队成员清楚地了解工作的分配情况。
我还看到有些活动很难从管理者手中转移，例如管理团队成员的薪酬（因为这需要建立一个更透明的薪酬系统，当您不是从头开始时，由于人们薪酬方面预先存在的差异，这很困难）。
我看到有些活动侧重于用户以及团队交付的原因和内容。在我工作过的一些团队中，这些活动被委托给担任用户倡导者或产品负责人（使用 Scrum 术语）等角色的团队成员。
我看到有些活动侧重于团队的工作方式。这些活动被委托给担任团队催化师或 Scrum Master 等角色的团队成员。
在这两种情况下，他们的角色都是确保活动由团队完成，而不一定是自己处理一切。
通过更详细地查看这些活动，我可以预见其中许多活动可以由团队成员作为其当前角色或新角色的一部分来处理。
让经理或团队领导能够考虑他们负责的活动以及他们可以委托给团队的活动，可以消除某些组织中目前存在的瓶颈和单点故障。
在您的组织中，哪些活动最适合由自组织团队处理？我的清单遗漏了什么？我很想听听您的意见。
5 条评论