写给同事的一封信

亲爱的同事，

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

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

现实与虚拟

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

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

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

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

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

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

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

面子与责任

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

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

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

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

再者，讲责任会促使团队的成熟，使得成员重视承诺，这对项目的有序运做相当重要。重视承诺的含义是：咱们对于没法定期完成的工做不承诺，而一旦承诺就要努力达成。

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

批评与表扬

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

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

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

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

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

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

质效与习惯

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

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

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

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

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

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