作为敏捷教练，在带领大家相继理解了敏捷思想精髓，落地了敏捷模式中的各项管理实践和技术实践并能有按此无缝衔接运转起来之后。我曾一度陷入迷惑。我是从传统软件项目管理领域转过来的，尽管在敏捷执行中，项目管理的点点滴滴被变换了形式重新组装在敏捷实践中，然而，其实项目管理范围和核心也还是没有逃离我们之前工作中总结出的点：规则、计划、划分阶段、分阶段验收、风险、度量、质量、干系人、评审、沟通等等...只是对局部点的重视程度不一而已。
不过，刨除这些管理的要点。我对于敏捷提倡的“团队自组织”概念倒是极其的追从...今天这篇文章也正是由“自组织”说开来...
一、什么是“自组织”？
直白的说，就是团队全体人员遵守共同的规则、节奏和模式，自我运转，自我管理。没有人去监督你到时间干没干，干的对不对、好不好...一切都在运转中检验，在团队产出中体现，在团队协同中数据说明...
然而，能真正做到这一步着实太难了...正所谓难，所以，多数团队标榜的状态始终也是“在路上...”
二、是什么阻碍了我们的“自组织”？
虽然"团队自组织"道路任重道远。然而这种境界对于任何管理者来说都是极具诱惑的。所以，我个人认为，在万人追崇做敏捷的大环境下，真正去看一个团队是否足够敏捷，一则看产能、质量和协同等可抽象出量化指标的点，二则就是这个团队自组织。
能实现团队自组织的团队，在我看来必定是突破了企业组织架构的桎梏、打破了业务产品技术等的“隐形墙”、建立了可灵活运转又行之有效的规则、同时人员是发自内心的追求自我卓越...
细细说来...
1、组织架构。
行走职场，组织架构的坑，谁人没有趟过。身为IT人接收来自职能部门的安排，同时更要听命于项目最高负责人的安排。他们之间没有矛盾还好，一点产生分歧，令我们首鼠两端，不知所从...
推敏捷的组织，必定是要先解决这个问题的。人在团队心也在团队，才是最重要的。否则谈何目标一致，谈何能行动一致...
另则，对于组织架构层级划分的诟病也是古已有之。申请-评审-批示-授权...这一套流程走完了，估计迭代时间箱也过完了。所以，最近几年大家都在说“扁平化”这个词，我对这个词本身没有过深的研究。但至少我知道。如果做敏捷解决不了古已有之的汇报审批流，很多事宜就会卡住，耽误整体团队的产出和产能...
2、“部门墙”与“业务敏捷”。
很多时候，企业花费很大力气将敏捷团队需要的组织环境解决之后，才发现，真正阻碍沟通和协同的矛盾继而是由“部门墙”引起的。看似业务和运营对团队很是支持，看似产品与技术相互理解、互相支撑...实际，各自尤其各自的小头头，都是暗藏心思，各为其主。直到发生相互的利益冲突，不可调和又找不到更好解决方案时候，大家才不得不反思，可能时本身这种业务与产品技术的分离就是一个问题。只做到了从产品到技术端的敏捷，业务是否理解了敏捷，是否适应了模式，是否发自内心的支持并遵守这一套行动方式？...
3、 团队规则。
这一点虽然浅显，但是同样也是一个难点。这种规则的串成和传承，仰仗有一个人去将其发现，记录，总结，供大家集思广益打磨继而试用、改善、固化、优化...
4、 成员的自我追求。
敏捷其实在项目管理的领域，像是一个贵族。不仅有一些形式化、仪式感的内容。更重要它隐含了对团队成员初始化能力的要求。团队如果都是刚毕业的大学生，其实是不适合做敏捷的。团队如果都是一些不求上进的人，也是做不好敏捷的。但是能找到一群或者说培养出一群能够持续孜孜不倦，追求自我的人去践行敏捷实践...这本身就是一道值得探寻的坎..后续我将花单独的章节，聊一下，团队中的“人才们”是如何也成为了团队的坑...
以上，是对于团队“自组织”的一些感悟。
还是那句话，自组织---我们一直在路上...加油~~
以上，感谢阅读。感兴趣可以加微信：js_alice
转载请微信联系先告知，谢谢~
网友评论