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

我入职的时候，这款新产品的初期版本开发完毕，只提供了基础功能，公司高层想通过对这个产品的升级改造，从单一的产品变为更契合市场的平台型产品，更好地推进市场。不管是公司面临严峻的形势，还是市场急迫的需求，都要求这个平台型产品快速推出。既然我入职了，自然也变成当务之急要完成的事了。几天后，我发现公司存在很多问题，而且已经到了严重影响日常工作的地步。比如业务部门的人员可以直接安排开发人员的工作，随便一个对于产品知识完全不了解的跑市场的人员过来都可以逼着开发人员完成一些非常奇葩的需求。

比如系统有微信小程序、公众号，只要微信关注了就会有消息推送。例如预约成功，有没有通过审核等信息都会有相应的消息推送，那么手机号就作为系统内一个非常重要的字段，要求相关人员不管怎么样都要有一个手机号，并且对这个手机号要进行验证，填写规范、正确。

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

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

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

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

面对这样的情况，我该怎么做呢？是顺应市场要求，赶紧抓业务，加班加点不断迭代产品吗？当然不是，我选择从团队建设入手，先解决研发人员的问题，这样他们才能将精力放在产品开发上。如果一开始就把业务抓起来，后续的职责划分也同样混乱，欲速则不达。

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

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

既然跟公司负责人确定好了解决办法，我就开干了。首先，我明确了自己在团队敏捷转型扮演的是一个什么样的角色？我不仅是研发中心经理，更重要的是，我充当着敏捷专家（scrum master，简称SM）的角色，既是敏捷教练又是领导者。问题来了，首要的目标是什么？是给团队建立敏捷规范，给研发人员营造安全空间。

12.1.1 建立“敏捷实践规范”

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

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

12.1.2 单独和成员沟通

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

一连贯操作下来，我的行事风格也契合了他们的价值观，不仅展示出自己的专业能力，还让他们感觉到我真正站在他们角度考虑问题。自然而然，我获得了团队成员真心的认可、信赖和依靠，整个团队的凝聚力和向心力也大大提高。

12.1.3 统一安排成员工作

此时，我在团队中已经获得了最高话语权和领导权，这时我就要求团队成员的所有工作全部由我统一安排。虽然公司负责人之前也是这么要求他们的，但是强制和自愿，完全是两种不同的效果。我规定，任何部门的任何人，单独给你们安排的任何任务都先经过我的同意。其实，关于业务部门随便提需求，这一点也是他们最烦恼的，而通过我这样强硬的要求，本质上是替他们挡住很多麻烦和无聊的事情。毕竟研发人员都属于高知人群，按照麦格雷戈的Y理论，他们希望能做有价值的事情。

内部处理好了，我可以腾出手来处理部门之间的问题。因为业务部门大部分不合理的要求被我挡回去，无法像以前一样肆意妄为地提需求，市场部门的部分人员反应异常激烈，直接在公司公开大声抱怨。我们公司是开放式办公场地，声音大一点就可以听到，虽然他们没有指名道姓，而是用研发部来代指我，但谁不知道他们这是想当众打压我，逼我放弃。甚至有人向运营总监及市场部负责人轮番告状。最后，运营总监、公司负责人都顶不住压力找我面谈，希望我能为了公司的稳定向其他部门妥协。当时有两个选择。

第一，我坚持这么做，短时间内可能让大家误解，但是从中长期看，这对公司有好处。这也是公司负责人找我来的原因，负责人必须公开给予支持。

第二，我也像上一任研发经理一样，做个老好人，尽量满足市场部的要求，把“锅”推给开发人员，但这样做对公司没有好处。

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

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

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

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

（2）从建设团队方面入手，单独和成员沟通。了解他们的真实想法，激发他们的工作积极性，让他们感受到工作的价值、成就感，同时培养他们自身必须具备的条件。

（3）最重要的一步，要求团队成员的所有工作由我统一安排。不管哪个部门的人来提需求，都要按规范和流程来做。

这样操作下来，研发团队的面貌焕然一新。对内，团队成员有了敏捷价值观，也拥有了相对安全的工作环境，不再苦恼怎么处理业务部各类奇葩需求，能多做一些有价值的工作，跟以前那种“我不想做，我想逃跑”的态度有着天壤之别，大家都鼓足干劲，觉得终于可以做自己喜欢、而且有价值、有意义的工作；对外，业务部门强势主导的地位被打破，不会像之前一样，为了业绩满口答应客户的需求，然后来跟研发部门提要求。随着规范和流程的建立与实施，业务部门习惯了这样的流程，与研发部门关系也缓和了不少。