Chinaunix首页 | 论坛 | 博客
  • 博客访问: 763573
  • 博文数量: 61
  • 博客积分: 2315
  • 博客等级: 大尉
  • 技术积分: 2560
  • 用 户 组: 普通用户
  • 注册时间: 2011-11-22 18:00
文章分类

全部博文(61)

文章存档

2015年(3)

2014年(3)

2013年(9)

2012年(23)

2011年(23)

分类: IT职场

2014-01-05 17:25:42

亲爱的同事,


转眼我在这个团队工作已有一年的时光,这一年也完成了我从通讯行业转入互联网圈的过渡。过去的一年给了我很多观察(团队)的机会,也带给了我不少思考,从我过去一年的寥寥几篇博文你应当能看到部分。


今天,我想借这篇文章与大家聊一些内容,以便你更加明白:为什么我在工作中对自己和大家的要求都那么高?为什么我强调责任与重视培养工作好习惯?为什么我会直接批评和积极表扬人与事?希望你的其它“为什么”也能在这里找到答案的线索!


现实与虚拟

现实社会中有很多让人恼火的事:想排队按序办事,却总有些人插队;想维护家里楼梯走道的卫生,却发现总有人乱扔垃圾和随地吐痰;车祸明明缘于对方过失,但他却百般否认与狡辩;想喝上干净的自来水,不求助于净水器似乎没有可能;等等。林林总总!


对于一名构建虚拟世界的软件工程师,我们不得不变得“性格分裂”,因为我们不能将现实中的脏、乱、差带到我们所构建的虚拟世界里。这种“不能”并非我们一厢情愿,而是现实所迫,因为“脏乱差”的虚拟软件世界一定会给用户带来糟糕的产品使用体验,也会为我们的工作生活增加额外的成本(加班等)。一旦明白这一点,你就会理解我为什么在工作中的要求会那么高,而且是多方位的!


面对现实与虚拟,我们不得不适时进行模式切换。在社会生活中,不要过于较真而影响自己的健康;在工作生活中,我们应力求构建完美的虚拟软件世界。


刚加入团队之时,发现大家所写代码多了些随意,团队知识管理也没有“官方”途径而是各自写在自己的文档或记在头脑中(那时作为新人的我还是为此经历了不必的痛苦)。为了改变编码随意这种现状,几个月前我决定着手实施编码规范。坦白说,这是我的职业生涯中首次大张旗鼓地推行编码规范,以前我一直认为写出有质量的代码(和文档)是软件工程师所应做的本份之事,无需过于强调。当时决定推广的另一大主因是,我们产品所基于的开源项目的根基非常好,除了自身代码就是一个优秀的参照外,更有着完备的编码规范和规范检查工具。然而,编码规范的最高境界并非“格式”,而是我们的“态度”,因为规范解决的只能是形式问题,而无法规避不恰当命名等非形式问题。也正因如此,你们所写的大部分代码我都会走查,通过不断指出问题并帮助改善的方式培养大家的认真态度。最近,每当我看到代码中存在你们改善质量的痕迹时,都会会心一笑;面对大家指出我所写代码中所存在的改善点时,我更加高兴并给予肯定和感谢,因为我坚信这是我们团队所应倡导的文化。大家回头看一看,过去的几个月我们团队在这方面取得了质的进步。


谈及团队知识管理,不得不说到我所带头编写的《软件开发指南》和《技术白皮书》。《软件开发指南》中的内容一方面很好地指导了我们的工程实践(涵盖软件设计、流程等大大小小的各方面),另一方面为新人上手起到了积极作用。前者从目前我们的项目中基本杜绝了模块混乱、加速了新版本合并速度和使得软件开发活动更规范化可以看出,后者则从最近WL在晨会上说“《指南》写得很好”得以佐证。


值得强调的是,所有这些进步都是我们共同创造的,没有你们的积极参与和快速跟进根本不能取得现有成绩,也很难轻松走得更远。还记得我在项目总结会上所说的“我为人人,人人为我”吗?


现实如此不完美,我们能否从构建的虚拟软件世界多找到些完美呢?!


面子与责任

面子的重要性无需多言,“捍卫面子”的意识也深入了我们的骨髓。然而,正如我曾在邮件中所提到的,以我在外企工作时的观察发现,美国的工程师之所以更富质效在于他们不是将面子放在首位,取而代之的却是责任。也正因如此,美国的工程师很喜欢发问且有时的问题让人觉得 “尖锐”,这一特质无论他们是面对同行、还是“领导”都一致。


我坚信,一个讲面子与一个讲责任的团队将形成截然不同的两极。讲面子的团队大多低效并很有可能集体无能,而讲责任的团队将运作得务实、高效;重视面子的团队看到问题采用的是回避态度,讲责任的团队看到问题会指出并较真甚至承担。责任之所以重要,是因为它会促使我们在工作中有所作为——用心按时、按质完成工作。一个讲责任的团队也不容易出现“技术军阀”和“管理官僚”,这两者对于团队的杀伤力都可称为是“核武级”。


重面子的团队还有另一个突出表现:团队成员很“听话”,上级说什么就做什么,不想不问,但承担不良后果。这种团队往往会凸显出“领导”的“重要性”,因为没有“领导”团队就不知要干什么、要向哪走。与之相反的是,重责任的团队即便短时没有领导者也能有序运作,甚至倒逼管理者有所作为。


另外,责任不应只是对于自己和团队,还有对于家庭的部分。比如,通过尽可能少加班多与家人在一起、陪伴孩子成长。意识到这种责任,你往往会花更多的时间去提高自己的能力和效率,而不会一味地想着加班是解决工作问题的万能药。我一直不能理解那些没事却在加班的人,他们对于家人如此,在工作中真的可靠吗?在业务发展不需要的情形下,频繁的加班不是个人能力有问题,就是管理出现了问题。


再者,讲责任会促使团队的成熟,使得成员重视承诺,这对项目的有序运作至关重要。重视承诺的含义是:我们对于无法按期完成的工作不承诺,而一旦承诺就要努力达成。


理解了我对面子与责任的看法后,相信你能明白为什么我会在晨会上不时提问,也能理解为什么我敢说且主动承担非职务之内的(管理)工作、会私下找你聊工作上的事和很少加班。这一切都是责任使然,是我应该去做的!


批评与表扬

人追求完美是无极限的,无论我们多么有经验、专业和职位多高,始终能做一个更好的自己而获得成长。显然,成长的过程中不可避免地会犯错。矛盾地,在纠错的过程中我们又有惰性而阻碍前行。面对自身错误惰于纠正的情况下,我们如何向前?需要来自他人的批评!


说到批评很容易让人想到《人性的弱点》中所倡导的“不要批评他人”观点,也很容易让人浮想“说话的艺术”。我对于批评有着不一样的看法和使用方法!


首先,我们得对批评的反应调低一点敏感度,不要一听到批评就什么都听不进,甚至出现逻辑混乱地狡辩的状况(比如,人家批评你的是事,但你说人家批评你时的态度不对。其实,只要人家事批评得对,即使态度有点不妥也得包容,可以将之理解为“我做错了而导致别人的情绪”)。其次,碰到批评先深呼吸,之后想一想所批评的问题确实存在吗?在一个讲责任的团队中,批评不光很少出现,一旦出现大家也能平常心面对(注:批评出现多了很可能表明团队管理出现了问题,不作为的事多了。从团队对于批评的态度可以看出这个团队是重面子的还是讲责任的)。在使用批评的方法上,我主张批评的目的不是让人难堪,而是帮助他人改进,在实施批评之前先友好地提醒对方错在什么地方和如何改进。如果友好提醒还解决不了问题,那只能实施批评了。被批评虽让人难过,但也会让人记忆深刻而避免下次再犯同样的错。对于批评的艺术问题我并不想多谈,因为工程师大多很单纯、是非少,只要各自心态摆好真的无需复杂到将批评“艺术化”。


谈及批评不得不说说表扬。表扬是一种对他人付出的肯定与欣赏,但中国的工程师好象不大擅长使用这种方法去表达自己的情感。我发现表扬很容易出现“礼尚往来”的现象,你今天表扬了别人,过几天可能也会收到对方的表扬回报。这种事情如果在团队出现得多了就很容易带来轻松的氛围,也容易让人体会到自己对于团队的重要性,这样不好吗?


与表扬相似的是,我们在工作中还可以:当因自己的工作失误而给人带来麻烦时说声“对不起”;获得别人的帮助后道声“谢谢”;向他人咨询问题时用“请教个问题”开头。这些小细节做起来很容易,但对团队建设的贡献却很大!


出色的团队离不开批评,且是通过表扬而培养的!


质效与习惯

我在美国工作的(累计)半年时间里,所涉项目周末从未见人加班,即使项目非常紧张依然如此。周末行驶在高速公路上,时不时能看到房车或被拉着的游艇从车旁驶过,很是感叹。人家不加班又何以如此高质效且过着丰富的周末生活呢?


在软件行业,质量与效率是一个永恒的话题,但却鲜有人真正了解它们从何而来。也往往迷失于SCRUM、CI、ET等诸多方法论中。


要做到有质效地工作,首先离不开各位承担应有的责任,其次是良好的工作习惯。前者会促使我们持续变得更专业、善于思考和较真,后者则使我们高效,两者一结合质量也随之有了。以我的观点,中国的工程师只要没有将责任和工作好习惯落实好,谈其他的方法论都没用,谈了也白谈。


说到工作好习惯很容易让人觉得发虚,有点看不见摸不着的感觉。我也一时很难在这说清楚,需要大家在工作中多观察,了解我是如何做和思考的。培养工作好习惯的另一个值得一提的好处是,它有助于杜绝技术问题演变成管理问题,从而使得团队更加轻量和高效。


精品产品是有气质的,是团队责任与工作好习惯的折射!



最后,过去的一年我们一同收获了不少,在这个伟大的开源项目上工作也让我觉得很有乐趣。谢谢你在碰到问题时主动与我讨论、谢谢你曾经授予我的技术决定权,因为尽管你们有的不说,但我能感受到你对我技术能力的肯定和信任!同时,也谢谢你们曾经给予我的帮助!


阅读(5561) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~