2012年四月月 发布的文章

也谈技术布道 – 影响因素及有效实践

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

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

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

* 布道者的资历

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

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

* 布道者的角色

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

* 组织文化的开放度

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

* 布道路线的选择

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

* 布道时机和对象的把握

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

二、技术布道的有效实践

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

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

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

* 选择合适的受众与时机

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

* 以点及面,划分阶段

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

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

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

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

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

* 降低目标预期

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

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

buildc 0.1.7版本发布

最近针对buildc又有了一些新想法,于是今天上午又对buildc进行了多处修改,并相继发布了0.1.6版本和0.1.7版本。

 
一、0.1.6版本的主要改动点
 
* 对buildc cache upgrade的实现进行了修改。
在执行全量更新本地cache前,先对本地cache的情况进行一些检查,并判断是否与当前.buildc.rc中的配置相符。如果两者是一致的,那么只进行update操作;否则则执行真正的upgrade(remove and re-init)。
 
* 调整了整个buildc源码目录的结构。
原先所有代码都放在build_utils目录下,这次我把代码分为两类:一类是核心逻辑(core);另外一类则是工具库类(utils),因此我删除了build_utils目录,同时增加了core和utils两个目录,分别存放不同类别的源文件。
 
在进行这项改造时遇到了一个小问题,那就是Python模块(比如core模块)中的源文件导入(import)另一个同级别模块(比如utils模块)中的符号的问题。以core模块的core.py为例,core.py中导入了env文件中的符号。原先core.py和env.py在同一个模块(build_utils)下,直接import env即可;但现在core.py和env.py分别放在了core和utils目录下,直接import env就会出现导入错误。这里涉及到了Python的模块搜索路径(sys.path)。默认的sys.path只是包括执行脚本的当前目录以及一些Python相关的安装目录(比如/usr/lib/python2.6、/usr/local/lib/python2.6/dist-packages等)。这样Python解释器无法找到core.py所在目录的上层目录utils下的env.py文件。为此我们需要在sys.path中增加一个路径,即'..',core.py文件的代码截取如下:
 
import sys
import os
import shutil
 
sys.path.append('..')
 
from utils import env
 
这样Python解释器就可以在core.py所在目录的上一层目录下寻找模块了。
 
* 将samples中的模板文件统一移到了templates中,删除samples目录
最初设计templates目录下只存放Make.rules相关模板文件,当时考虑的是支持多Make.rules模板。但目前只考虑支持一种,至少目前是这样(也许后续会有变化,但不能肯定),而samples目录下的文件其实也都是各种配置模板,因此将两个目录合二为一。
 
二、0.1.7版本的主要改动点
 
* 修改buildc init的执行语义
原先buildc init在初始情况下会在$(HOME)目录下创建.buildc.rc以及在当前目录下创建buildc.cfg;.buildc.rc是用户级别的配置;而buildc.cfg是项目级别的配置,放在一个init里显然有些不合适,因此0.1.7版本及以后版本在执行buildc init时只会创建$(HOME)/.buildc.rc。
 
* 增加buildc config init
对于项目级别的配置bulidc.cfg,我们使用新命令buildc config init来创建,即初始化一个项目级别的配置。
 
* 用buildc config make替代buildc config-make
顺水推舟,我们去掉了config-make这个command,进而改用buildc config make来生成或重新配置Make.rules文件。
 
做完以上修改后,感觉buildc看起来和用起来都更舒服些。

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats