昨天中午收到图灵出版的《布道之道 – 引领团队拥抱技术创新》一书，晚上就迫不及待地翻看开来。这是我读过的第一本有关推动组织内部技术变更/创新实践方面的书，感觉书作者对受众的分类很是准 确到位，很多布道技巧也十分值得借鉴。但就我个人多年来的体验来看，组织内部技术布道的结果，不仅仅与受众的类型有关，还与布道者自身的资历、所担任的角 色、组织内部的文化和环境、布道路线以及布道时机和对象的选择有一定关系。下面就是我在这方面的一些粗略心得。

一、技术布道结果的影响因素

我个人也算是组织内部的一个技术布道者，经过多年的碰壁和反思，感觉技术布道的结果好坏与下面的一些因素或多或少有些联系。

* 布道者的资历

无论国内国外(国内可能尤甚)，职场资历这个因素在任何职场活动中都会是一个影响因素，技术布道也不例外。如果你是一个职场新人，也许工作年头不超过一两 年，甚至是刚刚进入职场，你势必人微言轻，并尚未在组织内建立起信任，更重要的是你可能并未深入理解大家面对某种新技术或新实践时遇到的真正困惑以及问题 是什么，这时如果你在组织内尝试大力推动某种技术或实践，效果可能不甚良好：你会发现关心你的提议的受众会很少(除非之前就赢得了上层领导的支持)，你会 受到大家对你的资历的质疑："你才刚来，这东西你自己用过吗？你怎么就知道这东西会对组织带来价值？你讲的这些我都知道，但我们遇到的问题你并没有真正解 决"。记得2007年一位刚刚入司不到半年的新同事(我们得承认这位同事很有技术潜质，也很有技术热情)就在项目组内部大力推广设计模式，并多次在项目组 内部以技术沙龙的方式分享设计模式相关的知识，但效果并不好，以至于若干个月后，这位同事离职后，大家依旧如故的行事，设计模式也并未真正被用到产品代码 设计中。

相比之下，一些组织内资深的布道者反倒更容易推动组织内的技术变革。

* 布道者的角色

一般来说，技术布道的发起者多为组织内的纯技术人员或技术管理者，但也不能排除非技术人员(如：过程改善人员或高层管理者)发起技术或优秀实践的布道。纯 技术人员或技术管理者因其技术背景并深处其中，布道过程中其同理心更强，布道思路更符合大家的胃口，但效果因人因地而异；而过程改善人员或管理人员多半采 用是行政命令的灌输式的方法，强行推进技术或过程改革，这样做常常会遇到抵触或反对意见，短期内可能有效果，但长期结果却往往不佳(当然也有例外)。

* 组织文化的开放度

如果你所在的组织内的成员都抱有一个Open的心态，那恭喜你，你真是太幸运了。你的布道实践一定是相对顺利的。但实际情况中，大多数组织的文化可能没有 想象中的那么Open，大家对变化的第一反应就是"抵触和反感"– 好好的，为什么要变？你也可以说这是人的天性 – 习于安乐。显然在这种文化下进行布道，阻力将会较大，布道者需要做足准备，方可开始实施，即使如此也未必能取得很好的效果。

* 布道路线的选择

布道的路线无非两种：自上而下和自下而上。普通技术人员(包括一部分技术管理者)，多是自下而上，通过布道，说服项目组成员以及管理层使用新技术/新实 践。爬坡总是困难重重的，要想取得良好效果，需更多努力；技术管理者或其他管理人员可能采用自上而下的方式，告诉大家我们应该更换技术，采用新优秀实践， 多半相对顺利。如果你的技术的确解决了大家的问题，让大家平时的工作更"舒服"，自然就更受欢迎，推行起来也就水到渠成。

* 布道时机和对象的把握

变化是需要用成本买单的，既有人力成本，时间成本，甚至包括机会成本。如果你非要向一个下周就要发布的项目组推广JUnit，非要向一个工期仅有三个月且 交付后无需维护的产品线推广持续集成/交付，那你肯定是自找苦吃。这些例子都说明了一点：把握好布道的时机和对象。人家都忙得脚打后脑壳了，你还给人加添 乱，显然时机掌握错了；你推广的东西除了增加成本并未带来任何好处，显然对象选择错了。正如《布道之道》一书中提到的那样：你推广的成果(技术或工具)应 该可以让受众至少感觉到如下价值之一才行：提高了效率；降低了风险；增进了理解。否则你就找错了推广对象。

二、技术布道的有效实践

弄清楚上面的影响因素后，我们就可以谈谈一些利于收获良好结果的技术布道的有效实践了。

* 从问题出发，选择要布道的技术/工具

前面说过，你布道的成果(技术/工具/优秀实践)是需要给大家带来价值的，这其中主要的方面就是为了解决大家目前所面临的问题，比如开发效率不高、系统部 署繁琐、人工回归测试工作量巨大等等。因此只有当你觉察到这些问题，并对这些问题深入理解后，再去选择你要布道的技术/工具/最佳实践；否则如果只是为了 引入新技术而引入新技术的话，那么引入的技术和工具就好比无源之水、无本之木，没有长久的生命力。

* 选择合适的受众与时机

布道所推广的技术和工具多不具有普适性，它在一定受众范围内是有生命力的。因此在谋划布道之前就要考虑好对象。甚至可以在布道之前先深入到选定的受众当 中，对受众以及他们所遇到的问题进行相关的调查和分析，这样做才能事半功倍，布道的结果才可能更佳；另外在确定受众后，就是选择布道时机的问题了，时机的 选择因情况而异。但无论如何也不能犯上面提到的那些错误，否则你的努力将付之东流。

* 以点及面，划分阶段

受众面越大，布道的结果可能越不易理想。因此，最好先在小范围内布道并给予持续支持，直到该技术/工具/实践在小范围内变得不可取代并看到了成果，再向更 大的受众范围推广，此时之前那些已经尝到甜头的受众将会成为你下一阶段布道的强力助手。另外阶段性的布道还有助于你进行自我挑整，修正之前的不足，找到更 为合理的策略和方法。

* 利用局部布道成功结果的影响力说服更广范围的受众

人们都信奉"眼见为实"，因此将前期小范围布道的成功结果会让更广范围的受众相信你推广的技术/工具/实践将会给自己带来价值。这要比你口若悬河般的说教好上百倍。特别是在说服管理者时，这尤为有用，甚至决定成败的那个最重要的因素。

* 建立信心和耐心，潜移默化中布道，甚至先斩后奏

对于一些之前布道失败(无论是否是你推广的，包括那些被管理者否定的)的技术/工具/实践，只要你认定(在对问题的深入理解的前提下作出的判断)它会带来 价值，那就不要放弃，要有些耐心。并运用上面那条实践，先在局部尝试，影响小范围受众；收到显著成果后，再扩大受众面，用现有的成果说服他人，或甚至直到 当管理者问及你是如何取得这个成果时，你再告诉他：是因为我用了XX技术/工具/实践。

* 降低目标预期

最后这点算不上什么有效实践。对于布道者而言，如果要想保持一个持续向前的心态，保持持续关注前沿技术的动力，降低布道结果对你的负面打击，那就在布道之前降低你的目标预期吧。

最后切忌犯一个错误，那就是：只懂皮毛，就去布道推广(多数都并非出于解决问题之目的)。这样做的结果只能是失败，并很可能让大家失去对你的信任。这个错误自己犯过，见过职场新人犯过，也见过牛人犯过。

近一两年来我在博客少有提及公司项目的事情，除了一些技术bug引起我对问题的思考。这样一是为了“避嫌”，公司年初发生了多次因员工在个人博客泄露源代码或者客户资料的事件，公司管理层也加强了对公司“信息安全”的管理，无非是学习华为那一套-“封锁”：使用websense限制员工上外网，使用桌面监控系统监控员工电脑系统，封掉一切可能泄露机密信息的接口。还特地发挥了一下“数字课件”部门兄弟们的聪明才智，搞了一个在线信息安全课件，规定员工都要完成课件学习，并在学习完进行在线测试。说实话，这个课件做的真的不错，只是大家对这种学习丝毫不感兴趣，一切为了应付。二呢还是为了“避嫌”，记得去年年末的一篇文章就引起了一个小风波，结果换来了与“顶头上司”的一次“对话”。作为老员工你的所说说写，直接影响了周围的人，虽然我的博客访问量不大^_^。

而今天我要说说身边的事，说说项目上的事。

在一个项目(或者叫产品也不为过)上持续做了整整三年，说长不长，说短也真的不短了。三年间见证了系统从杂乱变为有序和规范的历程，也见证了自己逐渐成长和成熟的过程。而整个系统的架构也在经历着不断的演进。去年年末我们策划并对系统进行了有史(历史<=3年)以来最大的一次架构调整，今年下旬实现了部分调增的新架构系统上线。但我们心里知道架构演进还远没有达到我们期望的结果，演进还没有接近终点。对于一个中等规模的后台服务系统而言，高性能、大容量以及良好的稳定性和良扩展性一直是终极目标，达到这个目标谈何容易。

记得04年入司时，部门的一个核心产品A正在做革新性的架构调整，听更资历老一些的同事说：A产品在2000年诞生后在线运行了4年，问题也伴随了四年，随着客户业务量的增长，亟需对A的架构进行调整，部门也决定投入大量人力在这个拳头产品上。就这样新架构迭代式的做了近三年，人也换了一批又一批，终于在07年A产品上线了。A产品的架构演进走的是从无到有的革新路线，即整个产品基本都是重写的。这样的路线风险较大，新代码较多，测试过程中发现的缺陷势必也较多，为了保证产品研发人员能专心于研发，且保证现有产品维护能及时，部门还另分出一组人单独做既有产品维护。A的新架构上线后，也出了较多问题，但是架构本身经受住了考验，但是随着系统的运行，也发现了架构的一些弊端。

我所从事开发的产品B应该与A算是姊妹产品，第一版的B产品的一个子系统B-1就是从A未进行架构调整之前的系统修改过来的,也就是说B-1等价于A产品前身。与A产品不同的是，B产品增加了另一个核心系统B-2。这里用图示更直观。

A产品    A前身      — 演化 —> 新架构A
B产品:   B-1        — 演化 —> 新架构B1
            B-2        — 演化 —> ?

B产品初期，我一直投入在B-2上，完成了B-2初始版本的开发以及后期一年半的演化。在将B-2当前架构演化到一个高度后，我退了出来，开始负责B-1的研发。现在回头看来B-2最大的架构有点就是简单清晰，但是由于前期的经验不足，在内部代码结构上留下了比较恶劣的smell，后来人也“效仿”了我的风格，以致现在我再看B-2代码，只能用“惨不忍睹”来形容了，Dreamhead的fanfou中曾经提到过“给予程序员最佳的惩罚便是让他维护自己一年前编写的代码”。当然这都是我的错误，与后人无干。可惜的是我现在没有精力再去精化B-2的结构了。

前面说到B-1就是A产品前身，同样与A前身遭遇问题相同，B-1在处理能力上遇到了瓶颈。B-1的架构进化也就从此开始了。由于有了A产品架构演化的经验与教训，B-1采用了与A不同的架构路线，这期间A产品开发负责人给了我们莫大的帮助，提供了我们所缺少的经验和教训，可以说我们的架构演化是站在“前人的肩膀上的”。而且与A架构调整的轰轰烈烈不同的是，我们B-1后台的核心开发人员一直就保持在三人左右，再带着两三个新员工。人力虽少，但是效率却不差，小步快跑，达到相同目的。我们在去年年末架构演化方案确定后，制定了阶段发布计划，架构调整分阶段进行。一个阶段release后，deliver给客户，上线运行调整，虽说每个版本都不完美，有缺憾，有局限，但是风险也降到了最低，这种平滑过度对客户体验的影响也最小。更重要的是阶段性的deliver，加快了反馈的频率，使我们开始对前期架构演化的优缺点的了解也更多了。架构演化计划也随之调整。但随着对架构理解的深入，我们遭遇到了处理能力和扩展性上遇到了“天花板”，不得不暂停下来反思和讨论。

曙光就在昨天的那次反思和讨论中得以重现，在这之前我们的眼光一直停留在B-1架构蓝图的内部，无论我们如何调整都无法让大家满意，始终觉得“别扭”。这时A产品负责人的一个观点，让我们茅舍顿开。一个虚拟域或组的概念将蓝图组合、叠加和交叉，一副更大的图景展现在我们面前，而这幅图似乎让我们看到了架构演化的终极目标，以至于我昨晚连夜画出了一副架构草图。

这篇文章用“曙光”作为题目也许只有我自己才能体会到其深意吧。