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