如何建设好的工程师文化(2)

　　5. 保持一个尊重的工作环境

　　彼此间的尊重会促进沟通。一个可以挑战任何人观点的地方，一定是一个可以产生好主意的地方。一个容易被攻击的地方，是会抑制反馈的。

　　在过去的几十年里，头脑风暴(Alex Osborn 在1948年创立)风靡于工作场合，同事们聚集在一起，放弃批评和负面情绪，不用担心被评价，提出各种创造性的想法。充满敬意，推迟评价是头脑风暴的关键。但最近的心理学研究，正在颠覆Osborn的方法，新的研究鼓励在头脑风暴中争论，这样实际上能避免团队思想的僵化，从而产生更有效率的想法。根据这个理论，一个尊重的环境，能够产生更好的主意。

　　工程的领域一般都很广(系统，机器学习，产品等等)，不是每一个人在每一个领域都有相同的经验。实际上一个强有力团队里的每个人都应给在某个领域很强，即使在其他领域可能很弱。一个系统工程师不应该和一个产品工程师放在一起评估，在一个健康的工程师团队里，这是很重要的，尊重彼此的差异，不用单纯用一方的强项去评判另一方。

　　6. 建立共享代码所有权

　　没有人对代码的某部分熟悉后，就觉得他应该独自拥有或是维护这段代码。在短期内，某个人成为产品某个部分的专家，在一年或更长的时间里也许会提升效率,但长期来看，这种方式最终会带来伤害。

　　有组织的共享代码，会带来三个好处。第一，保持公开，能够更好的减低维护者的压力，也能够降低维护者离职，给团队带来的风险。这也让无忧无虑的休假变得不那么困难。我不会忘记，在我独自维护Ooyala's 日志处理系统的时候，有次我在夏威夷穿越，结果不断的收到报警短信的那些日子。

　　第二、共享所有权，能帮助那些没能参与某个领域的工程师，扩展新鲜视野。而且这样也可以避免工程师有“我必须扎根一个项目”的想法，可以鼓励他们参与多个项目。这个可以帮助保持工作兴趣，增进雇员不断学习和保持动力。长期来看这样也可以降低工程师感到停滞而辞职的风险。

　　第三，共享代码还有这样一个功能，当有一个战略级的目标需要更快速的完成时，多个团队成员可以云集在一个高优先级的问题上，优先解决它。如果私密化代码，那么责任只能落在一两个人身上。

　　一个工程师团队容易犯得的错误是：在整个team不大的时候，就把团队分成了若干子团队。子团队会垒砌一堵墙，妨碍共享代码，因为每个人会受到子团队目标的影响。Ooyala在我在的时候，就分了小团队，这使我失去了和另一个团队的人一起工作的机会，对此我非常遗憾。因为那个团队采用了一种敏捷开发方法，他们很关注共享代码所有权，我听说这给工作满意度和工作效率带来了很大的提升。而我热爱Quora的一个重要方面，就是我们强调项目属于整个团队，这让我有机会参与，用户增长，机器学习，监督工具，推荐，分析，站点提速，垃圾判断等项目。

　　7. 在自动化测试上投资

　　单元测试加集成测试，是那些大型的，产品相对稳定的团队，仅可用的控制大型代码质量的方法。而对于那些为了提高代码质量进行的大规模的重构，自动化测试可以提供一种可靠的保护。如果缺乏严格的自动化测试，那么用工程师团队自己测试，或者聘用外包团队测试，时间成本都会变得很高。而且这样容易陷入一种害怕通过重构提升代码质量的不良文化。

　　在实践中，自动化测试伴随着团队的成长，需要不断的开发。代码数量随着的产品的成长在不大增大，但是由于新人的加入，团队成员对代码的熟悉程度却在降低。对工程师对代码还有印象的时候进行测试，比起几个月或几年后再进行测试要容易的多。所以鼓励加强单元测试的文化，能让作者更有责任感，能保证产品质量。

　　8. 自由支配 20% 的时间

　　Gmail 来自于Paul Buchheit的20%项目，他第一版的开发时间加一起不超过一天。 Google News，Google Transit，Google Suggest 也都开始于20%项目。我在google的时候，用20%的时间，写了一个python框架，它能够很容易的搭建一个搜索页面原型。虽然现在google20%时间的效率可能比早期低了，但是这种观念，容许工程师花费20%的工作时间在其他项目上的观念，依然会是小工程师团队创新的摇篮。

　　Ooyala没有官方的20%时间，至少我在的时候没有，但是我仍然想办法，写了一个命令行Flex和Actionscript编译工具，它能提高团队编译的时间，其实就是一个 Adobe's Flex Builder工具的降级版本。虽然现在工程师团队已经增长了三倍，但是这个工具仍然在被使用。 Atlassian在尝试了一年以后，正式才用了20%时间。 有个facebook创立的20%时间的变种，Ooyala后期也采用它，是周期性的hackathons，--整夜的干，规则就是你可以干任何事情，除了你的本职项目。

　　从上到下的指定计划的方式，在关注整个公司的方向的时候是非常必要的，但是不适合管理众多的来自紧贴现实的工程师的创意。只要工程师负责的对待20%的时间，并且专注在那些可能产生重大影响项目上，那么这个过程中可能会产生重大的进步。没有官方认可的20%时间，这些仍然是可能的，但是更加的困难，设计和工程师想去实现那些疯狂的想法，就必须要牺牲周末和假期的时间了。

　　9. 建立一种持续学习提高的文化。

　　学习和有足够的挑战，是心理学教授Mihaly Csikeszentmihalyi所说的达到“FLOW”所需要的要素，在“flow”里人们关注他们所做的事情，并且被它激励着，甚至都忘记了时间的存在。快速迭代带来的直接反馈循环是达到flow的另一要素。

　　每周的技术讲座，为工程师提供了一个论坛分享他们的设计，他们的构建，也为工程师提供了一个为自己工作感到自豪的机会，而且这样也能让其他工程师学到他们领域以外的知识。内部(知识管理系统)，诸如，email系统如何工作，搜索服务如何排序等，也能鼓励工程师学习和发布他们掌握的知识，以及更好的完成 20%的时间。在Quora，我们跑了一个内部的Quora服务来做这个事情，在上面我们提一些产品或开发的相关问题。

　　建设学习文化的目的，是通过教育和训练，确保每一个人都具备做好工作所需要的“基本算法”、“系统”、“产品”等技能。随着工程师团队的成长，团队会把越多的精力放在招聘上(尤其是校园招聘)，那么，就需要更多的在指导和训练上投资。在新雇员到来的头四个星期，导师每天花一个小时来辅导，这可能对导师来说是一个负担，但是，这个只花费了导师一年工作时间的1%的投资，会有显著的杠杆效用，这会决定，新雇员是否会取得成功。

原文转自：http://www.ltesting.net