如何带领传统软件团队走向成功（三）

面对缺乏安全感的成员，如何让他们走出舒适圈？

在前文我讲了如何通过提升研发成员的质量意识，来提升开发阶段的质量水平，减少返工。

其实，这也是最困难的阶段，因为我们要关注到成员质量意识和能力两个方面，两手都要抓，这其实非常耗费时间跟精力，所以一开始，我会自己亲自带着团队做测试、重构级回顾、写自动化测试Demo、定规范和总结最佳实践等等。

幸好，我们的努力总算是没有白费，产品在投入市场后，迅速占领了市场，取得了非常好的市场业绩。

同时，团队成员的能力也提升了，对于敏捷思想和价值观认可度也有较大的提高，迭代的整体执行也比较顺畅。

但是，这个时候又有新的问题出现了。

困局

当我开始引入一些高级敏捷实践的指标时，比如测试覆盖率、燃尽图、累积流量图、缺陷循环时间、缺陷益出等等，我就可以明显感觉到部分成员的抵触心理。

甚至有一次，我听见成员几个人在嘀咕：“我们之前一直按传统瀑布式开发来的，也不见有多大的问题，现在搞这些有的没的，我都不会做事了，之前这么多年的经验也用不上。”还有的人说：“以前我们按确定好的流程做产品，多好。现在老大要搞敏捷，一点都不注重正确的文档，也无视以前流程和规定，我不想继续这样改变了”。

其实，听到大家这样的声音，我都能理解，这也是非常正常的反应，每个人对敏捷的认知有多有少，有理解的当然也会有误解，况且一般当人面对一个新的知识或者一个新的环境时，会产生不安全感，又会缩回自己的舒适圈里面，甚至可能还是恢复最早期的状态。

破局

那么当我发现了这种情况的时候，没有生气，也没有气馁。

我迅速地又把工作的重点放回到了团队内部，继续巩固敏捷和scrum的价值观，重申敏捷的四宣言及十二原则，带领大家一起重复学习和体会scrum的三大支柱：透明、检视和适应，以及“勇气、承诺、尊重 、 专注、开放”五大价值观。并且结合我们进行敏捷转型以来的实际情况与转型之前的情况做对比，事实与理论相结合，充分的让大家亲身感受到转型带来的好处。

同时强调和澄清设立这些敏捷指标，是为了更好的帮助我们进行敏捷实践，更直观的了解我们迭代的工作情况，帮助我们更好的解决所碰到的问题，提高团队绩效，提高我们的生产力和敏捷力。而且，这些指标是针对团队的，而不是说跟踪和面向个人的。

同时，我继续引入一些更加深入的敏捷实践，比如在“团队即我，我即团队”的基础上引入代码共有。代码共有，其实就是“共享与进步”。同样是敏捷思想的体现，它意味着每个人写的代码都是属于团队的，并且每个人都可以去修改任何代码。代码共有，可以增强团队对于代码的ownership。

一开始，成员们在代码这方面，常常会遇到修改困难、重构困难、甚至重复代码等情况的出现，成员们也会私下吐槽，说“技术债务又增加了，代码量实在太大了，让我编写代码越来越困难，代码质量也被破坏得惨不忍睹。”可随着我鼓励代码共有，在这样的氛围下，团队每个人可以为项目的所有部分贡献新的想法，可以更改任意一行代码去增加新的功能、修复缺陷、改进设计或重构。没有人会成为变化的瓶颈。

在全员成为代码的负责人，代码共有制的环境里，成员互相监督，信息共享，没有上下级，没有权威。这样公平公开的环境，让我们回到最本质的工程师文化里面，使得团队开始有了自组织团队的影子。

建设自组织团队

但这远远不够，我们也是经历了组织干涉、工作散漫的困局，才慢慢建立起真正的自组织团队。

怎么回事呢？我们先来说说来自组织的干涉。公司要求产品组每个人每天都要写日报，详细描述当天的工作情况，遇到什么难题，具体是怎么解决了。

其中有一次，某个高层领导看到某个团队成员在某项具体内容没有按照他的想法进行，他就忍不住直接指挥团队成员，你该怎么怎么做，直接进行干预。这与敏捷的“最好的架构、需求和设计出自自组织团队”这一原则明显违背，所以我们不能让这种情况出现，要委婉让高层领导知道，“我们出于什么考虑选择了这样的解决方案，当然，你的方案也很好，但请先让我们试试自己的法子，实在撑不住了，我们一定会向您求教”。

还有一点，因为自组织团队需要考虑团队的多样性、持久性和平衡性，这不仅仅是针对成员的性格方面，还需要考虑他的专业和领域知识的深浅和掌握的多少。

但一开始，我就走了误区，认为自组织是成员随意组合就行，然后也放手让他们去干，结果整个团队都变得特别散漫。有的成员说：“这部分工作我做得很吃力，给某某人做吧”。也有人觉得：“老大不会检查我的代码质量，那我就随便弄弄就交差，应付得过去就行了”。

这样下去肯定是不行的，我及时出手了，把个别不适合自组织的成员果断换掉，保证每个人都是专业、靠谱的，愿意为同一个交付目标努力。

随着工作的开展，我又在自组织团队的基础上，引入全团队一专多能，比如我们的开发人员前后端都可以编码，这样有效解决了前端等后端，后端等前端的尴尬局面。鼓

团队里面的每一位成员在他擅长的领域不断提升精进，成为一名专家，同时在其它方面也能够为团队提供支持的T形人才。

同时，在这个阶段，我也改变了对团队的指导风格，以指导为主，而不过多干涉团队成员。我对于团队的直接控制逐渐减少，更多是利用软技能去激发和鼓励团队成员自学。

这时候，可能成员们一开始会不习惯，会问：“老大，你怎么什么都不管了？你这样放手，我们都不知道要怎么做，我们很怕出错”。这时候我们不能因为成员一时的迷茫，就心软，什么都自己一手包办，要用言行让他们明白，正是因为大家都成长了，有足够的实力独当一面，大家一定要有自信，放心大胆地做。

在必要时刻，我们可以拿出之前的数据佐证，“看看，我们现在产品的BUG是不是少很多？是不是不需要经常返工？这些都是大家的功劳，大家要相信自己的能力。当然，我们还要不断学习进步，有些问题今天解决不了，通过学习，咱们明天就能解决”。同时，我也没有停止对敏捷和scrum的思想和价值观的输出，让成员持续学习。

其实，团队在这个时候已经变成一个较为成熟的自组织团队，已经有自我提升的意识，并且团队也逐渐建立起了自我改进的习惯。那么，为了进一步的提升团队敏捷力，同样也是遵循“客户合作高于合同谈判”，“业务人员和开发人员必须相互合作，项目中的每一天都不例外”等原则，我们团队还必须贴近业务。

贴近业务

什么是贴近业务，当然肯定不是像《如何带领传统软件团队走向成功（一）》中所讲的无条件服从业务部门，不然我们的辛苦就白费了。

而是从团队可以更好理解业务，同时给业务提供更有价值的建议的目的出发，可以尝试让相关业务在决策早期，就会引入研发团队的成员，让研发成员主动参与，讨论与技术相关的内容。并且也会在我们开发的过程中，尽量早地邀请业务人员一起进行工作。虽然一开始，在实际接触中，开发人员看不惯业务人员的随意和感性，业务人员看不惯开发人员逻辑思维太严谨，不肯将就，爆发了几次冲突，使得两个部门的紧张关系又加剧了。

这一度让我头痛，不知道怎么办。后面我发现，其实就是双方的出发点不一致。开发人员从自己的工作量出发，业务人员从自己的提成角度出发，肯定会爆发不可调和的矛盾。

这个时候你要切记，我们作为整个敏捷转型团队的领导者，即不能偏袒开发，也不能迎合业务。既然双方角度不一致，那我们就来调整成一致。如果调整成从为客户创造价值的角度出发，从精益开发避免浪费的角度出发，就可以很好的去解决这个问题。这样，研发团队也能少走弯路，更好做出客户想要的产品。随着工作的进行，迭代的继续，研发团队肉眼可见的能力变强，研发部门也与业务部门建立起了信任与默契，为公司产出更好的产品，业绩也是有了非常明显的提升。

所以在这个阶段的主要目标就是培养成员的自我提升意识，提升团队的自我改善能力，并帮助团队建立自我改进的习惯，形成自组织团队。

那么，该如何达到目标，让缺乏安全感的团队成员，放下传统开发模式，走出舒适圈，自我提升呢？主要有三方面：

• 推动更高级能力培养

团队进入到这一阶段，说明已经具备了支撑快速变化业务的基本能力，因此可以推动更高级的能力建设，比如引入微服务、代码共享、全团队一专多能等等；

• 领导以教练指导为主

在这阶段，我作为领导者，坚决贯彻“少微观管理，多宏观管理”的管理理念，学会放手，通过软技能来指导的内容会变多，让团队自己组织更多的分享，鼓团队成员自学，并建立学习型文化；

• 贴近业务

产品不能脱离业务，所以研发部门需要跟业务部门建立起密切联系、相互信任的关系，在业务决策早期就可以引入研发团队的成员，同样的，在开发的过程中，也应该尽早邀请业务人员一起工作。

总结

不知道你有没有注意到，在整个团队敏捷转型道路上，我扮演的是一个仆人式领导的角色。一开始，成员身处恶劣工作环境中，我带着同理心鼓励、支持他们，也主动帮助他们解决难题，这让我们双方都建立起了深厚的信任感，成员们也很服气我做的所有决定。所以，在这里要提醒你，如果你充当敏捷教练这种角色时，记住你一定是一名仆人式领导，这样才有利于团队转型，让团队变得高效。

当我们团队走到这一步时，研发团队已经是一个成熟的自组织团队，有自我提升的意识，并且团队成员也愿意走出舒适圈，逐渐建立起自我改进的习惯，主动去学习新技术、新知识。

所以你会看到，成员不会像以前一样从心里面抵触敏捷、只愿呆在舒适圈，而是遵循敏捷实践来进行实际工作，实现全团队一专多能。

另外，研发团队从要么无条件服从业务部门，要么敌视业务部门的态度转变过来，学会如何有分寸地贴近业务，能从研发角度出发更好理解业务，还能给业务提供更有价值的建议，两个部门建立起了信任与默契，为公司产出更好的产品，也更好提升了业绩，也为客户创造出了更大的价值。