从搞笑到高效，构建敏捷团队的基础原则

 

翁云峰 --稿定科技敏捷教练，厦门敏捷社区组织者

在印度有这么一个神奇的团队，他们有5000名左右的员工，每天要运送20多万份餐，一份盒饭要经过3-4个人的手才能抵达目的地，交通工具只有火车，自行车，板车和双腿，没有任何单据，甚至都不需要客户填写地址。

在这样的状况下，每6百万次运送中只有1次错误，准时正确到达率却超过99.99999%，这远超六西格玛的标准。在业界，如果一个企业能达到 六西格玛，就说明它能接近完美地达成顾客要求。在这一点上，达巴瓦拉甚至远远超过了联邦快递等使用现代技术和工具的快递公司。

 

 

大家可能在想，能够把事情做到这么好，他们一定很贵吧？他们团队的管理水平这么高，是不是成员的基础素质很高？

答案却不是如此，这个团队基本上都是半文盲或者文盲，每个月的收入也很低，平均每人400-500人民币。

这个神奇的团队，叫做达巴瓦拉。

 

 

大家有没有注意到，外卖的每一个饭盒上都有编号？没有英文单词或者太复杂的词，只有一串编号而已（因为他们很多人都是半文盲，所以编号信息也力求简单）。这些彩色代码告诉这些外卖小哥饭盒来自何处，输送过程中经过了哪些火车站，最终要投递到哪个建筑物的哪一个办公室。这个代码就是他们的通讯协议，可以保证饭盒并准确无误的送达。如果出错了，是谁出了错可以非常精准被定义到。

他们获得成功的法宝是时间管理，简单的色彩分类体系和团队协作。

我们很多的研发团队，文化程度都很高，我们能不能做到这样的准时交付率？很难。我们的团队可以在发生问题的时候，能不能非常精确的定位问题和处理？也很难。

虽然达巴瓦拉是属于另外一个行业的案例，相信也会对我们软件研发有重要的参考意义。我想通过这个案例的分析提出一个关于团队协作的观点，也是我今天想谈的东西。

1-团队协作的境界

现在我们来看一张图，大家试着想一想，我们团队目前经常沟通的频道是哪一个？

 

 

我们大部分的时候，都是在公开象限里进行协作。而公开象限的大小，反映了团队协作中的“信息披露”和协作水平。

假如我们都在一个团队里，一般大家都很乐意谈隐私象限，因为你需要把你知道的跟别人进行沟通，让他们配合你。你需要贡献一些秘密，一些私人的信息，让别人更加了解你。

当你不太清楚你自己的时候，比如你不知道有哪些东西需要改善，你需要请求反馈。你不知道你的代码写的如何，这时候有个人跟你说你的代码写得还不错，他是在给你反馈，接触你的潜能象限，这样的人是教练。

教练在鼓励你做自我揭示，你在不断请求教练给你反馈，让你知道你的潜能是什么。

 

 

喜欢天文学的人应该都知道“熵增”这个概念。举个例子，大家觉得你家是PPT左边的样子还是右边的样子？如果是左边，那就特别好。如果你是右边的状态，怎么办？你需要整理。

大家有没有意识到，你的团队也可能是右边的这种状态？出了问题不知道原因是什么，效率很低不知道怎么改进，流程无法预估，交付总是看天气。我们需要做的事情是什么？教练除了帮你揭示自我帮你反馈之外，还需要帮你做整理，把过去无序的东西变得有序。梳理流程，梳理团队，梳理产出，暴露问题并推动问题的解决，这个过程是“反熵增”，防止协作系统陷入到混乱和无序中。

增强沟通，反熵增之后，我们希望团队协作达到什么样的境界呢？

 

 

我想要用八个字来总结，叫做“既定规则，无脑执行”。

规则是什么？规则就是做事的方法和标准，比如DoR（就绪的标准）, DoD（完成的标准）和很多的working agreement（团队一起制定的工作公约）。

为什么是无脑执行？这里不是真的说在执行的时候，我们只需要找到一堆idiot来按部就班执行就行了。这里的意思是，当我们有了协作的规则和方法的时候，根本不需要占用大脑的带宽，不需要让团队在执行过程中耗费宝贵的计算资源，把有限的精力投入到最需要全神贯注的工作事项中去。

无脑执行的另外一个意思是，事情必须非常流畅，减少在执行过程中的摩擦，减少无谓的人力物力投入。

“以神御刀，不以目视刀。”
《庄子》

为了让协作更加顺畅，我建议大家可以参考这个“协作金字塔”。也就是教练，或者团队管理者，或者有志于改善团队协作的任何一个人，需要关注的一些要点。

 

 

我们需要定义一些规则和方法。

 

 

我们需要不断提高信息饱和度（提高团队的公开象限）。

 

 

让信息流可视化（提高公开象限；无脑执行）

 

 

及时反馈，及时校准。

 

 

2-敏捷教练是什么

这是一个教练在分享会提到的，他说敏捷就是快速迭代，他分享的主题是《敏捷是骗人的》。

 

 

这个事情告诉我们什么？有一些说法认为敏捷是万能的，或者说敏捷可以做很多事情，但真的是这样吗？不一定。

 

 

上面我也提到了一些教练需要做的事情，比如需要不断扩大沟通视窗，制定规则，减少执行摩擦等，我再提出几个观点。

敏捷教练应该是好销售。我们卖什么？卖“概念”。如果你在团队推敏捷方法和敏捷流程，你可以参考以下的销售思路，会让你的整个过程更容易，大家不妨试试。

 

 

敏捷教练应该是防火队员，更侧重于做防火的事情，而不是做救火队员（在问题发生前，提前感知到，提前准备预案，最好提前解决掉。）

 

 

教练应该是算法工程师，为什么？概念只是概念，最终落地的效果好不好，是需要在真实环境下，根据实际情况来做“调参”，通过不同管理算法的引入，通过不同的实践和结果反馈，不断迭代优化的过程。

 

 

 

 

3-管理的算法

敏捷教练是算法工程师，那么，他应该负责什么样的算法？

 

 

比如我们应该要确保团队持续不断的做正确的事情，如何做？

我们可以把敏捷和精益创业、设计思维做链接，形成一套从问题发现，到问题的分解和试验，到敏捷交付用户价值的闭环。

比如我们有各种各样的模式。

包括瀑布流程，PMBOK流程。

 

 

敏捷流程，看板流程。

 

 

敏捷界的网红Scrum流程和精益流程。

 

 

这些都是管理的算法， 都是敏捷教练这个“算法工程师”的“算法库”，或者说“兵器谱”。必须非常熟悉，并且知道在什么样的场景下，该如何使用。

4-极简之道

 

 

我们听过很多道理，依然过不好这一生。

在这么多方法论的基础上，我们如何用于团队？我们如何帮到团队提升效能？

我们要让团队更加高效，而不是让团队搞笑。从搞笑到高效方法很多，比如在个人级别的GTD时间管理，清单方法，个人和团队级别的“番茄工作法”等，都是在你尝试敏捷方法前的有益尝试。在切入敏捷实践后，可以先从kanban方法开始，慢慢转移到scrum方法（如果适用的话），再根据实际情况，转换到SoS（Scrum of Scrum），LeSS，SAFe等大规模敏捷实践上。

在选择某一个具体方法实施之前，以下几个问题值得思考。

首先，我们为什么要提高效率？为什么效率重要，如果没有想清楚为什么，怎么做可能都不对。比如我们为什么要两周交付？如果产品本身的属性，支持边开发，边测试，测试通过后可以直接灰度上线，我们就不一定要选择两周的交付周期，比如可以保持在一周的周期来交付。如果团队的基础设施还没有准备好，比如单元测试，自动化测试，持续集成都还做不到，固定两周交付可能会是一个灾难。

其次，我们需要区分什么行为是高效，什么是低效，什么是无效。我们可以通过对整体流程进行分析（比如使用value stream mapping等方法，来统计流程效率），获得基础数据，制定效率提升的目标。

再次，区分清楚后，我们可以采取措施和策略，来放弃无效的事情，减少低效的部分，提高有效工作的占比。

最后这一点是区分于流程之外的，我们需要提升团队的“沟通带宽”，需要不断扩大团队的社交连接。比如一个小组可能互相都不太认识，或者在平常的工作里还没有形成很好的协作模式，在这样的情况下，应该着力于让团队更多的沟通，加深在项目级别，和在非正式形式的沟通和协作（比如团队建设等），让团队加快融合。这是你无论采用哪种方式方法，都应该考虑的基础的部分。

 

文章来源：Worktile敏捷博客

欢迎访问交流更多关于技术及协作的问题。

文章转载请注明出处。

标签：高效,流程,搞笑,教练,协作,敏捷,团队,我们
来源： https://www.cnblogs.com/worktile/p/11008776.html