过程改进是研发管理的本质性工作，如果过程要改进通常意味着我们要引入变化，尤其对当前研发管理工作和流程尚不规范和完善的团队而言，引入变化是必须走的一步。但个人在实践过程中体会到引入变化有时候是一项非常有挑战的事情，如果把握不好可能反而会起到反作用。本文从研发团队如何有效的引入变化的角度出发，对思路和模式进行探讨。
关于团队引入变化，业界也有一些主流方法论，其中受Mary Lynn Manns和Linda Rising两位博士的著作《Fearless Change: Patterns for Introducing NewIdeas》启发最大，本文中也大量参考和引用该书中的一些思路和做法。本文面向的对象主要是研发管理人员，如组织中的高层、团队研发主管，如果组织设置了如QA等流程管理团队，则也供这些团队成员参考。
一．对引入变化的理解
1. 必要性
正如本文开头讲到引入变化是为了过程改进，通常管理层都能认识到引入变化的重要性和必要性，但很多中小型企业普遍重技术而轻管理，很少会有团队把引入变化作为一项专职工作来做，也就很少有流程和实践来指导相关工作。本文的初衷就是希望把引入变化作为团队工作中一项工作内容来管理，为过程改进的顺利开展提供可行的操作模式和实践。
2. 角色和流程
引入变化中建议设立专职角色（我们的第一个模式就是专职负责人）负责整个工作流程，引入变化的大致流程如下，其中每个步骤都需要专职角色进行负责和把控：
- 发现问题：针对团队中的“Smell”，抽象为需要引入变化进行解决和改善的问题点
- 找到切入点：通过收集、分析数据对问题点进行剖析并找到切入点
- 应用模式：组合应用文中提到的各种模式进行变化引入
- 跟踪与回顾：根据所引入变化的效果和团队的反馈进行总结和回顾
本文重点介绍上面流程中的“应用模式”部分内容，对如何发现问题、如何找到切入点以及如何开展回顾不做具体展开。
3. 误解
对团队引入变化，很多人可能存在一些误解，其中最大的误解就是认为新想法一旦引入就意味着已经成功。团队管理人员想了很多办法、做了很多工作找到了问题的切入点，跟各个利益方讨论之后终于引入了大家都赞同的变化，然后期望这个变化就能按照自己想的那样发挥效果，这是不对的。新想法一旦引入，我们还要做很多事情，很多变化引入的的失败并不在起点，而是在过程的持续性上。如果一个团队的自组织性较差，那没有流程进行约束，也没有专人进行跟踪和协调，变化的结果通常是不会令人满意的。
二．引入变化的思路
关于引入变化的思路这里主要讲两点：
1. 自下而上，全员参与
很多人认为变化应该有管理层发起，然后下面的人配合执行，这种观点个人认为没有错，而且有时候也是必要的。但反过来，自下而上进行变革，让所有人都能参与进来往往是一种更优解。我举身边的一个例子：开始时研发团队普遍没有过程资产管理这一概念导致开发交接上出现很多问题，后来部门里的一个小组开始推行基于OneNote的研发知识管理，把项目线、产品线和技术线上的很多内容都放到OneNote进行共享，效果非常好。旁边的小组看到这个情况，也开始推动研发知识的管理，后来扩展到整个部门，再后来整个组织的研发人员都会登录到OneNote知识管理平台上做分享和交流，公司领导知道后也非常欣赏。这个就是自下而上，全员参与的典型实例，我们用到了后文讲到的“自身经历分享”、“电子平台”、“小有成绩”、“不妨一试”等引入变化的模式。
2. 没有最好，只有最合适
通常我们要引入自认为不错的东西，首先都会去参考业界的成果以及别人成功的例子，这无疑是正确的。例如，现在敏捷开发很流行，然后我们就想把Scrum那一套也拿过来试试看，但实际上敏捷开发的很多模型都是有其特殊要求的；又或者现在团队人多了，团队问题也不少，需要探索一些过程改进模型如CMMI，但CMMI所需要的各种文山会海又让大家望而却步。所以如果只关注其中几个点而忽略整个流程支撑体系，通过照搬引入变化通常很难实施，这就需要我们做裁剪。裁剪的原则就是要适合团队发展现状和目标，不追求最好，只追求最合适。
三．引入变化的模式
站在前人的基础上，结合在研发管理过程中的点点滴滴，个人总结了以下15种在团队中引入变化的模式，下面对这些模式进行展开讨论：
1. 专职负责人
从流程执行、阶段评审、高效决策等角度出发，个人都深信有或没有专职负责人是不一样的，引入变化也是一样。对引入变化而言，对该变比持支持态度并有强烈兴趣的人无疑是专职负责人的候选，从这个角度讲，不同的问题和切入点、不同的模式的专职负责人都可能是不一样的，所以专职负责人通常是流动和不固定的，鼓励团队中的不同成员成为这个专职负责人也是一项最佳实践。专职负责人的作用和职责就是提供在团队内部引进新想法时的有效性，努力把新想法纳入正常工作并对该想法的落实、跟踪和调整有明确的思路。
2. 寻求帮助
这是看上去很容易但做起来并没有像看上去那么容易的一个模式，尤其对研发人员而言。很多研发人员包括处在研发管理岗位的Leader们，都很善于处理技术上的问题，但沟通和协作上总感觉有所欠缺。个人认为在组织中引入一个新想法在工作量上都不是一件小事情，尤其是对于那些刚工作的新人而言缺乏触类旁通的思路和技巧，想让所有人都高效参与到引入变化的过程中来是有难度的，这时候就需要找同事和资源协助你一起努力。这个看似可有可无的模式在实践过程中确实会起到一定作用，至少对我是这样的。
3. 关系网
关系网模式和上文提到的“自下而上，全员参与”这一思路有关，有时候变化想要获得大家的认可，需要有人来帮你造势和宣传。如果一个人在团队和组织中人员人缘很好，那由这个人去推动一项新想法无疑是有益的。当然，作为团队的管理者自然会有很多的机会接触到其他团队的做法和成果，所以把别的团队的新想法吸收到自己团队中或者把自己团队中好的做法推广到其他团队也是管理的一项内容，这个时候合理利用关系网这一模式会起到潜移默化的作用。
4. 团队培训
这点相信大家都没有异议，这一模式一般用在新想法的快速推广。如何快速、有效的把变革的思想和做法落实到团队，让团队中所有人都能达到统一认识水平，团队培训必不可少。通常由专职负责人起草新想法的推广方案，通过评审之后即可开展团队培训工作，方式也不一定限于传统的一对多培训方式，可以有发散和变通，如头脑风暴、焦点小组等效果都是不错的。
5. 电子平台
如果你想引入一个新想法，虽然这个想法很好，但缺少相关的工具可能实施成本会比较高。这时候，借助于某个工具平台是有帮助的，有时候可能是必须要有的。这方面的例子很多，例如团队中打算引入持续集成这个实践以提高代码自动构建和服务发布的效率，虽然所有人都觉得持续集成很重要，但如果没有找到Jenkins这样的容易上手而又功能强大的持续集成服务器，而需要我们自己编写很多脚本才能做到自动化构建，无疑在推广上会造成很多抵触和成本控制上的问题。这个模式把如Jenkins、OneNote等通称为电子平台，意指我们在引入变化是需要借助于工具的力量。
6. 回顾时间
关于引入变化流程中提到的“跟踪和回顾”这一步骤，有时候新想法已经引入但效果不一定理想，需要我们不断关注工作的进展并对实施过程中碰到的问题进行回顾总结。关于回顾，请参考我是另一篇文章: 《Retrospective--The Way To Make Things Better》，这里不再展开。
7. 自身经历分享
如果某个新想法你有类似的经验，那么恭喜你，这个专职负责人非你莫属。鼓励一些成功尝试新想法的团队成员分享他们的使用经历，有助于所有团队成员看到新想法的价值。这个时候，使用相对比较正式的“团队培训”是可以的，但个人更加鼓励大家在非正式的场合下以互助的方式分享对新想法的体会和心得。对技术人员而言，有时候并不是不愿意吸收新事物，而是苦于大家知识水平的局限而无从下手，所以如果有人愿意分享经验，作为管理者就要帮助创造这样的机会。
8. 不妨一试
如果团队成员有人提出了一个新想法，我通常会做出我的判断，想法不可行则罢，如果可行，我也不倾向马上就进行推行，因为我知道这是一个好想法，但我对这个新想法没有任何经验，那为了在组织中准备宣传该想法，要先把它用在自己的日常工作之中，发现和体会它的好处及其局限性。这就是“不妨一试”模式，该模式执行时间不一定会长，执行人有时候也不一定会是自己，通常选择团队中相对比较资深的成员进行短期尝试，然后根据尝试结果再做下一步计划安排是一项不做的实践，尤其对那些涉及面比较广的变化而言更是如此。
9. 适可而止
什么叫“适可而止”，说白了就是不要心急。在推出新想法时一个比较容易犯的错误就是希望大家都一口吃成胖子，既然新想法很好，就指望着所有内容都一股脑的推给团队成员然后希望大家都能按照自己想的那样出成果，这种思想实际上很普遍。一个新想法中可能存在很复杂的概念，把这些复杂的概念抛给初学者，只能让他们望而生畏，效果适得其反。所以在引进新想法时，个人倾向先集中于基本内容，相对复杂的概念点到即止，等这个想法已被团队广泛接受，考虑在提供更详细的内容。
10. 按部就班
“按部就班”可能和上面的“适可而止”容易产生混淆，但“适可而止”指的是从问题的难易角度出发需要控制节奏，而“按部就班”更强调做事情的计划。参考敏捷开发中的迭代思想，“按部就班”就是要我们制定一个引入变化的计划，然后一步一步去实施。使用一种叠加式的策略，在保持长期目标的同时分批实现一些短期目标，这就是这个模式的思想，当然具体实施的时候需要视情况而定，对于那些比较简单的新想法而言，一步到位也是很常见的；但如果实施时间预估较长，那就建议“按部就班”的去推行这些变化。
11. 个人沟通
如果你想让别人听你的，请你保持与别人的沟通，因为要想说服一个人接受新想法，一定要让他了解这个新想法对他个人的好处。如果你只是在团队培训时提到了这个新想法，大家都觉得它不错，然后你就指望所有人都能去实现这个新想法是不现实的。尤其是研发团队中往往存在不善交际的成员，他们在开会等群体活动中并不一定会把自己的想法说出来，但不代表他们没有想法，如果你不去找他们沟通，他们就不会把这些话说出来。研发团队中有时候出现的各种问题就是因为很多人没有把该说的话说出来导致沟通问题，这时候专职负责人必须要灵活使用“个人沟通”这一模式确保团队中所有人的想法都是公开和透明的。
12. 合适时机
广义上讲，做任何事情都有它的最佳时机，无非对有些事情而言时机并非那么重要。如果你想推行一个新想法，个人认为时机是一个关键因素，体现在两方面：一方面如果推行方还没有做好充分的准备就贸然抛出一个新想法，其推行风险无疑的要考虑的；另一方面，研发人员通常都比较忙，当他们面临紧迫的期限和太多事情的时候，首要考虑的问题自然是按时完成开发任务，其他事情都变得不重要。如果这时候我们去推一个新想法，效果可想而知。这就需要我们善于观察团队的运行情况并确定“合适时机”。
13. 小有成绩
当团队中引入变化已经小有成绩，不要忘了做一下团队庆祝，哪怕是看上去很小的事情，这是团队激励的一种表现，也是变革过程中一环。表扬和激励在引入变化中做的好的人和事，让团队觉得我们在朝正确的方向前进，通常成本很低但效果很好。时机上可以是总结和回顾会议等比较正式的场合，也可以是私下非正式的场合。引入变化毕竟是一件比较困难的事情，尤其是在碰到挫折和挑战的时候，“小有成绩”模式帮忙我们的团队调整和改善团队气氛。
14. 学习小组
很多组织会设立类似的“学习小组”，有些模型也主张要有一个小组来统领团队的过程改进工作，如CMMI的SPEG。我们这里的“学习小组”不强调类似正式的组织性架构，而是指一帮有共同兴趣的团队成员可以组成一个小组，让他们能够有机会持续的做一些学习和交流。当然个人认为管理工作不能少，所以定期/不定期的组织一下小组会议还是重要的，个人觉得最好这个组织会议的人不是来自学习小组中的成员。上面提到的“电子平台”、“不妨一试”、“自身经历分享”等模式都可以和“学习小组”配合使用。
15. 试行
最后一种模式大家都想得到：“试行”。对有些新想法而言，团队中会有不同的声音，总会有这样那样的反对意见，在决定正式采用新想法之前，让所有人都能认同和支持几乎不可能，这时候比较好的一种策略就是安抚这些持反对意见的人并建议团队先就新想法做一些实验和尝试，如果效果良好我们就正式推广，如果效果不好那再做其他打算，这就是“试行”。在试行过程中，专职负责人需要保持持续的动力，积极主动的策划使团队中所有成员都能持续关注新想法。
四．小结
本文重点阐述引入变化的模式，使用这些模式是需要把握以下几点：
- 场景：个人认为上下文环境是引入变化最重要的考虑因素，如果团队现状和公司战略与新想法不匹配，显然这个新想法是不适合引入的。
- 时机：可能大家会说研发团队一直都很忙，但个人在推行一些新想法的时候发现，如果这些新想法确实能为团队带来工作效率的提升或客户满意度的提高，通常都是很受欢迎的。时间确实都是挤出来的，关键是要有人去主导。
- 对象：针对某一个新想法都要找一个合适的专职负责人，这个专职负责人可能通常都是团队管理人员，但最好多培养团队普通成员；对团队而言，重点关注对变化漠不关心或不大参与新想法实施的成员。
对于引入变化的思路和模式很多时候见仁见智，本文仅从个人日常工作中的体会做一下梳理和总结，聊作参考。