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

大家好，在上一篇原创长文《如何实现从技术骨干到管理精英的华丽转身》中和大家分享了如何成长为一名管理精英，今天再跟大家分享一下，在成为管理精英后，如何带领一支传统软件企业的研发团队走向成功！面对强势的业务部门，如何让他们不再瞎提需求？

一、面对强势的业务部门如何让他们不再瞎提需求？

背景

先给大家介绍下背景，当时我入职的这一家公司的主力产品的销售处于停滞状态，导致公司整体业绩也非常差，甚至可以说是已经动摇了根本。在这种情况下，急需研发另外一款产品，并且肩负着为公司带来新的业务增长点的重要意义。

我入职的时候，正处于这款新产品的初期版本开发完毕，只提供了基础功能，正处于公司高层想通过对这个产品的升级改造，从单一的产品变为更契合市场的平台型产品，更好推进市场。而且在当时，不管是从公司面临严峻的形势，还是市场有急迫的需求，都要求这个平台型产品要快速地推出。既然我入职了，自然也变成我当务之急要完成的事了。但我入职几天后，就敏锐发现了公司存在很多问题，而且已经到了严重影响日常工作的地步。

发现问题

比如业务部门的人员可以直接安排开发人员的工作，随便一个对于产品知识完全不了解的跑市场的人员过来都可以吆五喝六，逼着开发人员去完成一些非常奇葩的需求。    举个例子，比如我们这个系统其中有微信小程序，还有公众号，只要微信关注了就会有消息推送。例如你预约成功，有没有通过审核等等这些信息都会有相应的消息推送过来，那么手机号，就作为我们系统内一个非常重要的字段，这就要求相关的人员不管怎么样都要有一个手机号，并且对这个手机号我们要去进行验证，填的是否规范，是否正确。

有个业务人员，他的客户是养老院的，想用我们这个系统，说那些老人没有手机号，要我们这一个填手机号的字段必须兼容固定电话号码。但我们知道，每一个地方的固定电话号码位数不一样，规则又不一样，根本无法兼容。而且如果兼容了，那发短信的功能不能使用，微信公众号关注也不能进行绑定了，会影响整个系统基本流程的功能使用，把整个业务逻辑功能的流程给打乱了。

但这个业务人员就说，你们这个系统就是有问题，而且态度非常差，“我不管你们产品怎么做，反正你要满足我的这个需求。至于其他用户，我才不管，关我什么事，有什么问题也是你们技术差，但是你必须先满足我的要求”。

再从团队内部看，开发人员对待业务部门的需求和要求，基本上都是第一反应就是：改不了，这个不是我的事，这个我不清楚之类的。总之就是非常抵触，能拖就拖，能推就推，经常还会直接吵起来，基本都是被逼的没办法的时候暂时应付下来。而且团队内部互相也不怎么交流，每个人负责一块，这个任务落到谁头上那就是谁倒霉，工作气氛非常紧张和尴尬。

最后就导致了开发人员做得多错得多，不仅没有人说好，反而总是在背黑锅。业务人员为了尽快签单拿到提成，不管功能有没有、能不能完成，也不管客户提出多么无理的要求，一概全部答应，完全不与开发人员沟通。导致研发部门加班就变成常态，而加班大多是处理这里非常脑残的需求，工作变得毫无价值，没有丝毫的成就感，所以研发团队工作环境恶劣，人员流动快，以前的负责人、重要岗位的人都离职了，很多开发人员都是刚入职不久，离职率也高。

破解之法

面对这样的情况，我该怎么做呢？是先赶紧顺应市场要求，赶紧抓业务，加班加点不断迭代产品吗？

当然不是，我选择从团队建设入手，先解决研发人员的问题，这样后面他们才能集中精力放在产品开发上。如果一开始就把业务抓起来，后续的职责划分也会同样混乱，欲速则不达。

在一开始，我毕竟对于公司的整体情况和部门的情况不熟悉，所以也试着接受运营总监的建议，对部门进行比较传统的管理方式，比如说利用老板的授权，行政级别高、更优秀的能力和更丰富的工作经验等等，寄希望于通过传统管理手段中的地位、奖惩权力、施加压力和硬技能等快速的建立权威，以便能够快速的改造研发部门。结果我发现，这样做根本没用，感觉处处掣肘，成员各种不配合，工作基本上开展不了。我规定严了人跑光了，规定松了他们又变得天天摸鱼划水。我当时真的又急又恼，毕竟我很着急要做出实绩，结果入职都一两个月了，什么成效都没有，成员还更不配合了，这是在打脸啊！

我后面才意识到，我手下这帮成员都是90后95后，他们思想自由，追求平等，颠覆传统，不认可权威，但同时又期待被迅速的读懂、认可和肯定，喜欢速成，快速看到结果。传统的管理方式已非常不合时宜，想改变公司现存的这些情况不仅仅是换一个人就可以的，是需要改变思维，导入一个新的价值观，引入一整套开发方法，而敏捷不正是天生符合90后想法的价值观和开发方法吗？当我向老板汇报完情况并提出这个想法时，两个人一拍即合，因为老板本人也曾研究过敏捷，只是并没有太深入，也因为种种原因并未正式实施。

既然跟老板确定好了解决办法，那我就开干了。首先，我先明确了我在团队敏捷转型扮演的是一个什么样的角色？我不单是研发中心经理，更重要的是，我充当着Scrum Master的角色，既是敏捷教练又是领导者。那问题来了，我首要的目标是什么？是给团队建立敏捷规范，给研发人员营造安全空间。

采取措施

我先按照scrum的规范结合目前的实际情况，制定了《敏捷实践规范》，在里面给大家详细说明了迭代计划会、迭代评审会、迭代回顾会、每日站会等组件的内容和形式，也明确了开发人员、PO、SM等角色的职责，同时也详细说明了scrum团队、迭代（冲刺）、自组织团队、scrum价值观等等概念。并且，我还会通过每日站会，持续的灌输敏捷思想和承诺、专注、开放、尊重、勇气五大价值观。团队成员在我的熏陶下，也稍微明白了敏捷是怎么一回事，对比之前传统的管理方式，的确是比较适合他们。

同时，我自己兼任产品负责人也就是PO，对所有外来需求进行需求分析并建立需求全景图（史诗故事），拆分成用户故事并排列优先级；制定用户故事编写规范，用户故事价值流和建立用户故事看板。依托于敏捷开发工具，让团队每个成员知道自己要干什么，能直观了解敏捷流程的运作方式，并身体力行地按照敏捷流程运作。前面这些，都是比较容易操作的事，毕竟具体措施的主导者是我，费精神的是跟团队成员沟通。

我也会单独和他们进行一对一沟通，倾听他们自己工作和个人职业发展的一些真实想法，并结合我自己的经验，给出一些诚恳和接地气的建议，让他们感受到我的真诚和善意。同时借助一切机会去让他们感受到工作过程是在创造价值以及成就感。同时，我也会不厌其烦地通过正式或者非正式的机会，对他们进行关于敏捷思想、责任感、团队协作、沟通等方面的思想灌输和培训，并结合实际的例子加强他们对自组织团队的理解，去激发工作积极性和热情。

获得成果

我这样一连贯操作下来，行事风格也符合了他们的价值观，不仅展示出自己的专业能力，还让他们感觉到我真正站在他们角度考虑问题。自然而然，我获得了团队成员真心的认可、信赖和依靠，整个团队的凝聚力和向心力也大大提高。
此时，我在团队当中已经获得了最高话语权和领导权，这时我就要求团队成员的所有工作全部由我统一安排。虽然老板之前也是这么要求他们的，但是强制和自愿，你懂的，完全是两种不同的效果。我当时就规定，任何其它部门的任何人，单独给你们安排的任何任务，都先经过我的同意。其实关于业务部门随便提需求，这一点也是他们最烦恼的地方，而通过我这样强硬的要求，本质上是替他们挡住很多的麻烦和无聊的事情。毕竟研发人员，相对来说都是属于高知人群，按照麦格雷戈的Y理论，他们希望能做一些有价值的事情。

夯实成果

那么内部处理好了之后，我就可以腾出手来处理部门之间的问题。因为业务部门大部分不合理要求都被我挡回去，无法像以前一样肆意妄为提需求，市场部门的部分人员反应异常激烈，直接在公司公开大声抱怨，我们公司是开放式办公场地，声音大一点就可以听到，虽然他们并没有指名道姓，而是用研发部来代指我，但谁不知道他们这是想当众打压我，逼我放弃。甚至有几个好事的人放话要让我过不了试用期，并串联搞些小动作，还向运营总监及市场部负责人轮番告黑状。

最后运营总监、老板都顶不住压力而找我面谈，希望我能为了公司的稳定，向其他部门妥协。我当时给了两个选择：

第一，我坚持这么做，短时间内可能造成大家的误解，但是从中长期看，这只会对公司有好处这也是老板为什么要找我来的原因，老板必须明确公开的给予支持。

第二，我也像上一任研发经理一样，做个老好人，谁的要求我都满足，把黑锅推给开发人员，让他们背锅走人，其它部门一定说我好，但这样做对公司没有好处。

最后老板还是选择了长远考虑，专门召开了部门的主管会议，召集了所有部门的负责人，单独建立起了技术支持部门，负责研发和市场部门的中间协调工作，所有市场部门的需求和问题都需要先通过技术支持部门分析和审核，确认需要提交到研发中心的需求也由技术支持部门通过工单的形式提交。而且，随着规范的实施，我们几个部门间的关系反而有所缓和。

总结回顾

那么到这个时候，我感觉我作为敏捷教练，第一部分工作差不多是告一段落了，团队培养了敏捷价值观和思维，对内建立了敏捷规范和流程，对外处理好部门关系，建立了相对安全的环境。对组织帮助建立好规范的机制，同时也保护好了团队成员。

我们再来回顾整个过程，我作为新领导空降进入一个以市场为主导的传统型软件开发公司，面对业务部门非常强势，常提出各种奇葩需求来“折腾”研发人员，出现了问题还把锅甩给研发部，研发人员工作环境恶劣的困境，我是如何站在Scrum Master的角度彰显敏捷精神，来破局的呢？

首先，为了给团队成员营造安全的工作环境，我建立《敏捷实践规范》，向团队成员灌输敏捷的价值观，让他们认识、了解敏捷。同时，也通过各种正式或者非正式对他们进行培训，让他们对敏捷思想、责任感、团队协作、沟通等方面有更深的体会；

其次，就是在建设团队这方面下手，单独跟成员沟通，了解他们的真实想法，激发他们的工作积极性，让他们感受到工作的价值、成就感，同时也培养他们自身必须具备的条件；

最后，也就是最重要的一步，要求团队成员的所有工作由我统一安排，谁来提需求，请按规范和流程来，不是什么需求我们研发部都给做。

这样操作下来，我们研发团队的面貌焕然一新。在内，团队成员有了敏捷价值观，也拥有了相对安全的工作环境，不再苦恼怎么处理业务部各类奇葩需求，能多做一些有价值的工作，跟以前那种“我不想做，我想跑路”的态度有着天壤之别，大家都鼓足干劲，觉得终于可以做自己喜欢、而且有价值、有意义的工作；在外，业务部门一手遮天的地位被打破，没办法像之前一样，为了自己的业绩客户要啥就答应啥，然后指手画脚跟研发部门提需求。

现在起，如果你业务部要提需求，请按规范和流程来。随着规范和流程的建立与实施，业务部门习惯了这样的提需求流程，与研发部门关系也缓和了不少，不再像之前的位一样，一个天一个地，沟通起来就发生尖锐矛盾。

二、面对频繁需要返工的困境如何提高交付质量？

困局

当我团队建设工作告一段落，同时也要求公司给团队提供了一个相对来说安全的环境。那么，我们理所当然地要有产出，要交付出一个高质量的产品。

所以当时我们就引入敏捷开发，形成定期迭代，每两周发布一定的产品增量，让客户也好、业务部门也好，有一个预期。那问题也来了：在产品最初的几次迭代当中，交付的新功能非常的少且零碎，而且经常会因为要修复一些紧急的bug和缺陷给打乱节奏。并且因为之前遗留的一些历史问题，研发人员经常需要返工，偿还技术债及技术债带来的利息，这往往占用了他们大量的时间，还将整个迭代计划完全打乱。

而且当时还有一个很重要的问题暴露出来，团队里面一直缺少测试人员，真的很难想象一个软件开发团队居然没有一位测试人员。团队里面的每个开发人员互相不沟通交流，闷声只做自己的，然后就直接提交代码，不仅提交的时候经常互相覆盖代码，而且Bug非常多，很多时候做出来的东西和实际业务部门需求的是两个东西。

所以，当时产品虽然定期迭代，但质量特别差。差到什么程度？好多代码都是那种硬代码，直接写死了，比如说我给A客户的某个值写死成“123”，当b客户的这个值变

“234”的时候就不行了，就要把代码重新拿出来改成“234”后，再重新去发布一次。

还有最常见的就是功能的核心流程操作经常被打断，业务闭环走不通。还有很多体验方面的，比如点了一些按钮没有反应，跳出一堆乱七八糟字符等等，甚至很多客户都在不停的吐槽我们的系统界面太难看了，杂乱无章，风格不一。

破局

虽然质量问题不是由Scrum Master操刀负责的，但我既然作为领导者，我有能力也有义务来解决频繁返工，交付质量低下的难题。我当时是怎么解决的呢？

首先我还是要从研发人员的思想入手，让他们充分认识到外部失败成本对于组织、对于团队所造成的严重后果。后面，又该怎么解决？那就要求我们研发人员在开发阶段，就要达到高质量水平。这其实，就涉及到怎么建立，提升开发人员的质量意识。

我当时就还引入了精益开发的一个核心概念“质量内建”，也就是要求软件生命周期之间，参与的各个角色都需要实时的对软件的质量负责，也就是说，从我们产品经理开始，从产品到UI到开发到测试，我们每个职能都要去对这个产品负责，确保软件在交付到下一环节前已经有了基础的质量保证，这样才能减少因为质量问题导致的返工，避免浪费大量人力成本。

其次，我一直在灌输“我即团队，团队即我”的思想。之前面对产品的质量问题，尤其是被客户投诉，被业务嘲讽时，团队成员的第一反应就是，“这个功能不是我开发的，这个锅我不背”，“这个跟我什么关系，当时是谁谁叫我这么做的”。

比如有一次，这个产品的人脸识别功能出现故障，用户使用时一直提示错误。其实这只是个小问题，很快就能修复好。但是为了避免以后出现类似的问题，所以我把团队成员聚在一起开会，讨论为什么会出现这个问题，以后也避免犯这种低级错误。但是大家都是一一副“这个锅是某某人的，你跟某某人说就行了，我不需要听你讲这些”的态度。

可把我气得厉害，我该怎样办呢？从思想层面来说，要让研发团队的成员们在工作中深刻贯彻“我即团队，团队即我”。团队要为质量负责，也就是每一个人都要为质量负责，而不是说这个功能不是我开发的就不关我的事。

落地

那具体如何去做呢？我首先就是要求增加测试岗并配备人员，通过迭代计划会保证PO、开发人员和测试同学对于用户故事和验收标准的认知是一致的，并且让测试同学提前介入测试，及早的发现缺陷并及时修复，或者在合适的时候采用TDD（测试驱动开发）的方法，来将Bug扼杀在在摇篮状态。但是这里需要特别说明的是，TDD会增加大量的工作量，所以说我们需要在合适的时机恰当使用。

随着大家对于质量意识的提升，我继续在产品的更新迭代中引入单元测试、集成测试和回归测试。我当时设想得很完美，单元测试、集成测试不仅可以提升代码质量，还能提升开发人员的代码设计能力、质量主人翁意识，让开发阶段的交付质量有所提高。但我没有料到，如果在一个没有测试文化的团队里面引入这些，阻力会这么大，团队的成员都跑来问我这提出异议：

“单元测试仅仅是证明这些代码做了什么，我觉得太浪费时间了。”    “我是很棒的程序员，技术能力这么强，我是不是可以不进行单元测试？”    “后面的集成测试将会抓住所有的bug，单元测试的成本效率不高，我把测试都写了，那么测试人员做什么呢？”    “公司请我来是写代码，而不是写测试。测试代码的正确性，不是我的工作啊”

……

对此，我只能不厌其烦地跟大伙解释，单元测试虽然是所有测试中最底层的一类测试，是第一个环节，也是最重要的一个环节，也是唯一一次有保证能够代码覆盖率达到100%的测试。我也拿出数据说明，之前我们产品大部分的错误，是在软件设计阶段引入的，我们为了修正一个错误所需的费用，将随着产品生命期的进展而上升。我们错误发现得越晚，修复它的费用就越高。

我们作为编码人员，是唯一能够做到生产出无缺陷程序这一点的人，其他任何人都无法做到这一点。最后我也小小吓唬了他们，“如果你能百分百确定在开发后期，不会因为bug过多而失控，那你就可以别做，后果自己负责。”好在团队的小伙伴都明白我讲的是有道理，也都认真执行了。

如果说单元测试、集成测试是开发人员来做，那回归测试，通常由团队一起来完成。因为回归测试重复枯燥，我们通常都是借助一些工具自动完成。如果是带页面的项目，那么也会要求测试人员进行UI测试，帮助团队提高回归测试的效率。

当然，我们也会设立CI服务器，将以上测试定期运行，并且生成可视化报告，让所有团队成员都看到，并且要求团队第一时间修复CI。

我们使用Git管理代码，并建立Git的规范和分支策略，并且充分利用GIT的一些高级功能和规范流程帮助我们提升代码质量，同时解决一些疑难杂症。我们也鼓励开发人员设计更好的部署架构和技术架构，帮助团队做更好的决策。

强化

除了以上这些测试工作，还有一个我认为也是非常重要的工作，那就是代码回顾。对于代码回顾的重要性，想来也不需要我再做过多的说明，代码回顾的好处几乎不存在争议。代码回顾既是质量的一道门槛，也是知识分享的一个很好途径。

那么如何保证代码回顾本身的质量呢？

首先，我们要在团队的技术能力的不同阶段，采用不同的代码回顾策略。比如团队稳定，编码规范掌握的比较好，使用的语言也是熟悉的语言，那么可能代码回顾的重点就会放到业务逻辑方面；如果团队新成立，还在磨合，可能编码规范就需要多注意；如果是团队新换了一门编程语言，那么语法本身可能也会是代码回顾的重点。

在公司业务发展的不同阶段也需要采用不同的回顾策略。比如To B的业务在稳定推进，那么代码回顾可能需要更加仔细严格，保证质量和代码的可读性、可维护性；但是如果是在互联网行业，业务发展初期，在快速试错阶段，那么代码回顾需要Leader去平衡回顾力度和业务交付的要求。

这些我们做到了，代码回顾就没问题了吗？当然不是。当时团队在开始代码回顾这块也出现问题了。具体咋回事？听我来说说。

一开始我们进行代码回顾时，我会发现，做代码回顾的成员交付出来的东西很差，乱七八糟的。有一次我终于忍不住指出他的问题，没想到他直接说，“这代码回顾我能力不够，做不了，老大你换人吧”。

我当时真的挺惊讶的，没想到他这么排斥这项工作，我立刻态度缓和，真诚的问他是遇到什么困难，稳住他的情绪。他这才说，平时工作量也不少，现在做这个代码回顾，很难一下子挤出很多时间来做，而且还经常是一次性提交大量的代码来回顾，他很难抓住重点。

我没想到，我认为理所当然的操作，也很好操作的代码回顾竟然给他带来这么大的困扰。作为Leader，我首先控制了每次需要回顾的代码量，避免对大量、无意义的代码进行回顾的现象存在。

同时，要求提交代码的人在commit note中应该写清楚提交代码的目的。例如：这个实现的是什么功能？做的是什么优化？修改的是什么bug？这样才方便负责代码回顾的人有的放矢，清楚代码改动的上下文。

解决了这个问题，你以为代码回顾就可以高枕无忧了吗？

当然不是。当时我们团队还陷入了成员互相挑错的陷阱当中去。例如当时我们在回顾一个页面设置的代码，有人指出了小张这个代码写得太啰嗦，还出错了，犯了低级错误。小张当下心里就不舒服了，“你居然当面这样说我，我不要面子的吗。你等着，我现在就要挑你的错处”。

这样的事情再多发生几次就会造成恶性循环，面对代码回顾，大家都会将内心封闭起来，抗拒那些针对自己的批评意见，团队气氛越来越紧张。一说到又要开展代码回顾，大家都情绪低落，特别排斥。到了最后，不仅代码回顾工作没有做好，还严重地影响正常的开发工作。

到了这个时候，我意识到不能放任大家有这样的情绪存在。我开始遏制挑错现象的蔓延，改变用代码评审、代码走查等“审、查、评字眼”，跟成员强调代码回顾重点是在共同学习和建设性上面，而不是批评。

让大家以开放的心态来面对代码回顾，它不是设置障碍，或者挑毛病，而是一个必不可少的质量保证过程，同时也是一个互相学习的过程，只是需要对于编程规范有一个共识，避免因为编程习惯发生不必要的异议。

最后，还要提醒你一点，一定要让成员将代码回顾养成习惯，让它成为我们工作中的一部分，当然，对代码回顾者的时间要有所保证，每个人在一个迭代中有自己承诺的任务，只有在预留了代码回顾的时间的情况下，代码回顾才能作为一个日常任务被执行。可以把代码回顾作为DoD（完成标准）的一部分。

总结

这一部分的信息量有点大，我再简单的回顾一遍。之前研发团队交付的新功能非常的少且零碎，研发人员常常因为返工被占用了大量时间，迭代节奏、迭代计划经常被打乱。而且产品的质量常常被诟病，也成了业务部门攻击我们的重点。面对这些困局，我具体在团队内部做了什么举动来破局，减少团队的返工，提升交付质量呢？

我们分为三步走：

第一步，要求团队各个角色都要实时对软件的质量负责，给他们传递“我即团队，团队即我”的思想，也就是提升大家的质量意识；

第二步，引入单元测试、集成测试和回归测试，提升开发人员的代码设计能力、提升代码质量，让开发阶段的交付质量有所提高；

第三步：开发人员要做好每日代码回顾，提高质量和团队整体效率。

这样一操作下来，我不仅获得了团队内外的肯定、还获得老板的赞赏，他觉得我作为一名空降领导，这一顿操作猛如虎，看到了我是如何发挥自己的敏捷领导力，用行动推动和促进了团队变革。

为什么这么说呢？因为我通过行动，提升了研发成员的质量意识，从而也提升了开发阶段的质量水平，尤其在经历了几个迭代后，效果非常的明显。不仅减少了之前返工带来的对迭代节奏的破坏，让迭代顺畅又有质量。产品的缺陷跟BUG率有了明显的降低，使得我们团队有更多的精力投入到新功能中。还能帮助开发人员写出更好的代码，培养他们开发处理复杂和疑难问题的能力，大伙也不再因为产品质量被人诟病，相互甩锅，而是想着如何一起处理缺陷，避免类似问题再次发生。

同时，也间接开阔了团队视野，让团队成员了解更多的技术，学习如何利用新技术提升自己效率，甚至大家面对代码回顾这种枯燥又繁琐的工作，都不会抗拒，浪费自己时间，能明白其中起到的重要作用。

正因为研发团队对产品控制度有了上升，公司内外部成本也明显降低，业务部门的抱怨也明显少了，并且关系也更加的融洽，客户好评率呢，也上升了不少。

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

舒适圈

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

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

幸好，我们的努力总算是没有白费，产品在投入市场后，迅速占领了市场，取得了非常好的市场业绩。    同时，团队成员的能力也提升了，对于敏捷思想和价值观认可度也有较大的提高，迭代的整体执行也比较顺畅。

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

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

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

走出舒适圈

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

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

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

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

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

自组织团队

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

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

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

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

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

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

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

随着工作的开展，我又在自组织团队的基础上，引入全团队一专多能，比如我们的开发人员前后端都可以编码，这样有效解决了前端等后端，后端等前端的尴尬局面。鼓励团队里面的每一位成员在他擅长的领域不断提升精进，成为一名专家，同时在其它方面也能够为团队提供支持的T形人才。

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

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

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

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

贴近业务

什么是贴近业务，当然肯定不是像第一小节中所讲的无条件服从业务部门，不然我们的辛苦就白费了。

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

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

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

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

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

• 推动更高级能力培养

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

• 领导以教练指导为主

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

• 贴近业务

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

回顾

不知道你有没有注意到，在整个团队敏捷转型道路上，我扮演的是一个仆人式领导的角色。一开始，成员身处恶劣工作环境中，我带着同理心鼓励、支持他们，也主动帮助他们解决难题，这让我们双方都建立起了深厚的信任感，成员们也很服气我做的所有决定。

所以，在这里要提醒你，如果你充当敏捷教练这种角色时，记住你一定是一名仆人式领导，这样才有利于团队转型，让团队变得高效。

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

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

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

四、持续优化改进建立强有力的自组织团队

走出自己的敏捷之道

如果你读完前面三节，相信你也能感觉得出来，团队的持续改进之路其实就是团队的敏捷转型之路。

我讲的整个团队转型的过程，其实就是我作为一名新领导，空降到一个传统研发团队里，通过发挥自己的敏捷领导力，在不偏袒开发也没有迎合业务的基础上，不仅给开发人员营造安全的工作环境，培养他们的敏捷价值观，而且在质量提升方面我也发挥了作用，减少迭代返工。

并且引导和教练团队中的人员自身综合能力逐步提升，思想也随之改变。慢慢演变成团队所有人都能对什么是正确的事，如何正确的做事，作出更好的判断，继而走向持续改进的道路，建立起能自己做持续改进的自组织团队。

但这就圆满落幕了吗？当然不是，没有人能告诉我们敏捷的终点在哪里。Mike Cohn曾经说过：“你不是变敏捷了，而是变得更敏捷了”。敏捷或Scrum没有任何终极状态，变得更精通Scrum或更敏捷是一个持续的、永无止境的过程，追求的是日益精进。“我们终于实现了敏捷” 这样的说法没有任何意义，所以，我们团队的敏捷，还是需要继续坚持。

这里还也要跟你强调一下，虽然我讲述的案例中用的是敏捷的方法，而且也获得了很好的成效，但这并不代表我的敏捷实践是唯一的解决途径，或者说你自己团队的敏捷转型，就一定要照搬我的方式，一模一样来。每一个组织所处的环境各不相同，开发的产品也千差万别。

变革之路注定充满荆棘

另外，也不要指望Scrum过程不会出现问题。我敢肯定地说，到某个时候，肯定会出现阻碍敏捷顺利实施执行的障碍。

面对内部障碍，我们要依靠我们的自组织团队，充分地信任他们能够自己解决问题。

而对于大多数组织而言，维持现状是一股强大的力量，为了抵制这种倾向，要坚定、耐心，在组织变革中充当中坚力量。

要明白这种抵触很正常。给他们讲讲敏捷的价值观、基本原则和我们的想法，和他们共同工作，帮助他们走出困境。

不要与他们对立，而是和他们一起扫除障碍，让团队、开发工作和组织从敏捷的实施中获取最大收益。变革之路注定充满荆棘。

解决问题的核心是人

说了这么多，总结起来，其实我想表达的是：

敏捷本身就是由价值观、思维方式和最佳实践组成的，但是，这些本身并不能去解决我们所遇到的问题，解决问题的核心还是人，是一支贯彻敏捷价值观、用敏捷思想进行思考、充分贯彻敏捷最佳实践的自组织团队。所以，当我们在使用敏捷时，不要担心事先是否能做够一次性到位。没有人做得到！绝大多数团队在前几个迭代都不会做得很好。这没有关系，我们只需要持续优化改进，建立起强有力的自组织团队，让Scrum团队在下一个冲刺都能比前一个冲刺做得好，就行了。