写给同事的一封信

亲爱的同事，

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

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

现实与虚拟

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

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

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

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

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

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

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

面子与责任

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

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

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

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

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

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

批评与表扬

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

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

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

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

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

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

质效与习惯

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

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

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

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

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

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