2012年十月月 发布的文章

改善技术布道效果的几个实践

本文是笔者发表在《程序员》杂志2012年08期上的那篇“改善技术布道效果的几个实践”文章的完整版。

 
技术布道不易,想取得良好的效果就更难了。下面是笔者总结的几个有助于改善技术布道效果的有效实践,这里给大家分享一下。
 
自我认知
 
技术布道前,布道者首先要做好自我认知,这将有助于布道者确认自己是否胜任此次布道以
及采用何种布道策略以赢得更好的效果。认知的内容包括:自己是否精通这方面的技术。若
只知皮毛,布道效果将大打折扣;自己在组织内部是何种资历与角色。如果你是职场新人,
人微言轻,布道效果势必会受到影响。
 
环境认知
 
组织内的技术氛围对技术布道效果有着重要影响,因此布道前还要做好环境认知。这包括:
组织内成员是否拥有一个开放的心态,乐于接受新鲜事物;组织内部是否为大家建立起一个
有影响力的布道平台并设立奖励机制;管理者是否积极支持技术创新并接受因此带来的成本
损耗。最终布道者应根据环境认知的结果来选择适合该组织的布道策略和方式。
 
精选主题
 
技术布道的主题无疑是影响布道效果的最直接因素,因此在选择布道主题时务必谨慎而为。
选题时要把握住一个至关重要的原则,那就是你要布道的主题一定要能够给组织带来价值。
这些价值可体现在多个方面,比如解决了困扰大家已久的问题、提高了工作效率、降低了风
险或增进了理解等等。从笔者的多年布道的经验来看,从问题出发选题是个不错的选择。当
你对组织内部存在的问题深入分析和理解后,你的布道主题就很容易确定了。而且因为这个
主题与大家的日常工作息息相关,你可以相对容易地获得良好的布道效果。相比之下,那些
纯粹为了引入新技术而选择的主题就好比无源之水、无本之木,是很难获得良好效果的,其
布道的新技术在组织内也是不会有长久生命力的。
 
受众分析
 
技术布道的主题多数并不具备普适性,它只是在一定受众范围内是有生命力的,因此在谋划
布道之前要做好布道受众的分析,识别出适宜本次布道的受众。一旦确定了受众范围,布道
者就可以在布道之前先对受众以及他们所遇到的问题进行相关的分析和调查,使得布道更有
针对性,并取得事半功倍的效果。
 
把握时机
 
俗话说:“来得早不如来的巧”。技术布道也是一样:“布得早不如布得巧”。良好布道时机的
把握对赢得良好布道效果有着很大影响。如果你非要向一个下周就要做产品发布的产品线推广 JUnit,非要向一个工期仅有三个月、繁忙异常的产品线推广 CMMI 理论,那你肯定是自
找苦吃。人家都忙得脚打后脑壳了,你还给人家添乱,显然你选错了布道时机。
 
制定策略
 
制定一个适宜的布道策略对取得良好布道效果作用很大。这里介绍一些有效的策略,大家可
以参考。
 
- 以点及面。受众面越大,布道的效果可能越不理想。因此,最好先在小范围内进行试点,并在取得成果后再扩大布道范围。“事实胜于雄辩”,小范围布道取得的成功结果会让更多人见识到该主题的价值,并带着更加积极的心态参与到这个主题的后续布道中去。这点在说服上层管理者时也尤为有用。
 
- 划分阶段。如果布道主题涵盖范围较大,可将布道划分为多个阶段,并逐段实施。每实施一段后,还可以根据受众的反馈进行自我调整和完善,这有助于你在下一个阶段的布道中取得更佳的效果。
 
- 善于借势。如果你布道的主题在实施之前获得了管理层的认可,那不妨将你的布道过程名正言顺地打上官方之烙印。相比于职级对等的“水平布道”而言,借管理层之势的“垂直布道”势必更能引起大家的关注,提升大家参与的积极性。
 
心理建设
 
大多布道者都是技术专家,他们对技术充满热情,对布道乐此不疲,总是希望能够通过自己
持续不断的布道使得组织获得在技术能力等多方面上的提升。但布道的结果有成功也有失败,布道者也是人,失败的苦果并不容易下咽。因此布道者在布道前先要做好心理建设,最大可能地减少布道失败对自己的负面伤害。
 
- 建立信心和耐心。只要你认定某种布道会给组织带来价值,那么就不要放弃,要有些耐心,充分考虑使用上面所述的策略和方法。
 
- 降低目标预期。这是个心理把戏,在布道前适当降低些目标预期,那么即使布道效果未达到你的要求,带给你的伤害也不至于很大,有利于保留你热情的火种。
 
(全文完)

也谈Go语言代码包分发

Go语言目前(截至1.0.2版本)尚不支持直接链接.a文件(这里的.a文件指的不是传统静态共享库,而是对golang的非main包build后的产物)。这样一来Go的第三方库包或组织内部的公共代码库包只能以源码的形式分发了。

Go提供了get命令用于获取他人分发的代码包。我们通过get命令既可以获取一些知名代码托管站点上的代码,也可以获取组织内部版本控制服务器上的公共代码。

Go get支持的托管站点包括github、google code、BitBucket以及Launchpad,针对这类情况,我们可以得到“特殊”语法的照顾:

go get github.com/bmizerany/assert
go get bitbucket.org/bmizerany/assert
go get code.google.com/p/assert
go get launchpad.net/assert

由于Go已经“内置”了github、google code等的版本控制工具类型,因此我们无需再做任何额外指定,只需用代码的url(去掉http://)即可。

执行get后,代码会被下载到GOPATH环境变量配置中的第一个路径下的src目录下面。例如:我们的GOPATH=/home/tonybai /goworkspace1:/home/tonybai/goworkspace2,执行go get github.com/bmizerany/assert后,我们将在/home/tonybai/goworkspace1下看到github.com 目录,而assert包在本地的完整路径就是/home/tonybai/goworkspace1/github.com/bmizerany /assert。这样我们在代码中直接import "github.com/bmizerany/assert"即可使用assert这个第三方包了。

在组织内部我们也会有自己的私有公共代码库,一份代码库可能被多个项目所使用。在每个项目中都保存一份公共库代码显然是不利于后续版本升级维护的,这样就需要各个项目统一从同一个地方获取或更新公共库代码。这种情况我们同样可以用go get命令来做。

假设内部使用subversion作为版本控制工具,公共库架设在10.10.12.13/svn0/share/golib。这时我们不能简单地的通 过"go get 10.10.12.13/svn0/share/golib"来获取到代码,我们需要告诉get我们采用哪种版本控制工具,而这种信息的传递是通过在库名称后面加上后缀的方式进行的。比如:

go get "10.10.12.13/svn0/share/golib.svn"

这样在/home/tonybai/goworkspace1下就会出现10.10.12.13/svn0/share/golib.svn目录结构。我 们在代码中可以直接import对应的包,比如import "10.10.12.13/svn0/share/golib.svn/assert"。

通过对get命令特性的了解,我们也可以确定分发的代码包到底应该如何组织。从上面的例子我们可以看出我们分发的代码包结构不需很复杂,直接在库的 repository下建立包目录即可,比如上面例子中库repository为golib,assert就是直接建立在下面的目录,同时也是包名。

go get可自动识别http_proxy环境变量,这样Go也可以通过代理获取外部代码包。

使用外部代码包的项目可以通过go get -u url来更新代码包版本为最新版本。

由一个软件库存问题想到的

近期产品线出现这样一个“怪现象”:许多已经完成编码并具备提交给测试组的版本没有测试人员对应。测试部那边给出的策略是:按版本优先级从高到低依次测 试。这样一来一些重要版本需要到3个月甚至更长时间之后才能开始测试。可以肯定这种现象是生产环节的一个问题,但用什么理论去解释和分析这个问题呢?我想 到了“库存” – 软件库存。

Joel说软件》的那个Joel曾写过一篇名为《软件库存》的文章,也正是看了那篇文章后,我才第一次了解到软件库存这个概念。库存似乎是传统制造业中 的一个概念,但软件开发其实也是广义产品生产的一种,虽然有其特殊性,因此有些产品制造方面的理论是可以应用于软件生产过程中的,软件库存就是其中之一。

传统制造业的库存较为容易理解,零件、原材料、半成品以及未卖出去的最终产品这些都可以理解为库存。而软件生产中的库存都包含哪些内容和环节呢?一旦形成库存,利弊又有哪些呢?

* 未纳入开发的需求/特性

这里所说的需求/特性是经过决策后将来要开发的且能带来价值的,而不是为了大而全而滥芋充数的那种。这类需求/特性可理解为已经采购并存放在库中尚未投入 生产的原料库存。这类库存如果变得很大,则很可能说明产品市场场景甚好,但也可能是现有的生产能力出现了不足;如果这块库存过小或没有,则会导致后期开工 不足,或者说产品的持续成长前景黯淡,市场对其的需求也不乐观了,组织对此情况应做出迅速反应。

* 已经开发完毕但未经测试的半成品

开发人员开始投入,根据需求/特性疯狂编码、单元测试,生产出未经专业测试的半成品。这些半成品因其中潜在的许多缺陷而不能作为最终商品投放市场,因此无 法收回成本并赚取利润。一旦这个环节形成库存,则说明后续质量验证环节的生产能力与软件开发环节的生产能力出现了不匹配,这将导致版本中的问题不能尽快地 暴露,使得问题流向其他版本或其他系统中,直到测试开始后才能发现,后续要花费更多的工作量做关联的修正。这也是我所在产品线所遇到的棘手问题,唯一的方 法就是提高质量验证环节的生产能力,至于如何提高,因地制宜,这里不表。而较小的库存或这个环节无库存,也会导致后续质量验证环节的开工不足,或衔接出现 节奏性的问题。

* 未上市或未卖出的成品

当产品顺利通过质量检测部门的测试后,便可正式发布,变成最终产品- 成品,交付到最终用户那里。但如果这个环节出现库存,问题将变得严重得多。要么是前期市场估计过于乐观,要么是行销人员不给力,要么则是生产过剩,没有做 好库存管理等等。如果这个环节库存过小,则最终客户依旧无法及时得到产品,不利于保持客户粘性,客户很可能退而求其次,选择其他厂商的产品了。

以上简要分析既提到了不能忽视库存的存在,也说到了无库存的危害。传统制造行业一直在追求着一种“零库存”的概念,所谓“零库存”,是指物料(包括原材 料、半成品和产成品等) 在采购、生产、销售、配送等一个或几个经营环节中,不以仓库存储的形式存在,而均是处于周转的状态。它并不是指以仓库储存形式的某种或某 些物品的储存数量真正为零,而是通过实施特定的库存控制策略,实现库存量的最小化。在软件生产领域也可借鉴这一概念,在各个环节努力维持合理且适当的库 存,这对整个生产过程是大有裨益的。

可以看出“零库存”的一个精要就是及时收回产品的投资,获得利润,保持生产过程的持续有效进行。这让我想到了当今软件过程的演化:从最初的瀑布过程到目前 流行的迭代和敏捷等过程,以及流行的持续交付等概念,它们似乎都是在追求“零库存”,追求快速回流价值。或者说库存理论潜在地催生了敏捷、持续交付等概念 的迅速发展,并让人们看到其中的裨益所在。




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

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

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

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多