软件工程原则
软件工程管理与协作是个永恒的难题。从人月神话、软件估算的五大定律都可以佐证。如何才能管理好整支团队呢？我们看看Trey Stout的经验之谈。其经验是首先大家要把自己的想法说出来，然后把共识部分写下来，再不断在实践中完善。
从1997年开始我就一直在写软件了。我试过自己写。也试过跟数千人的团队一起写。这么多年的辛苦教会了我一些东西。下面我打算把它们分享出来，你们要用心记。
程序员有三大美德：懒惰、不耐烦，以及傲慢
——Perl之父Larry Wall
看看第一段表现出来的傲慢！我的懒惰指导我做出了这个清单，这样我就能让工程师跟上我的组织思想。它有很多个化身：比如一个.txt文件，一个markdown文件，一个wiki页面，现在则是一篇博客文章。此前这些都只跟我的开发团队分享。网上有关工程领导的文章很多，但大多是针对开发者或领导，不是整支团队的。而这篇针对的是整支团队。
阐明团队原则带来的优化令人惊讶：高度连贯性的决策，没有层级之分。换句话说如果你的团队知道并遵循相同的指导原则，他们会做出跟你一样的决策。这意味着我（作为懒惰的管理者）不需要进行微观管理了。意味着我已经交代清楚了什么事情对我这里管理者来说是重要的，而那些事情也是得到了团队的认可的。
这些原则是动态的。尽管在本文中它们是一个静态的快照，但它们真正的家在git库里面，pull请求是欢迎的。我们甚至有一个slack插件可以通过数字或全文检索去引用它们。
这些原则在我介绍给每一家公司之后都被改动过。我自己是怕麻烦的，所以就把我们的工程原则列出来了。希望它们也能适用于你！
1、开发有意义的东西
工程计划是稀缺品。应该用到能令公司取得进步的事情上。
2、成为科学家
科学是一家体系化的企业，它树立和组织知识，以可测试的方式解释与预测宇宙。我们应该基于研究得出客观数据而不是直觉或迷信来进行决策。改善就是改变。
3、了解你的敌人
康威定律，睡眠剥夺，主观信仰，宽松验证，糟糕的依赖，不可靠的网络，范围蔓延等等，要了解它们，并要有击败它们的计划。
4、不要忍受破窗理论
只要发现就要纠正不好的设计、错误的决策以及糟糕的代码。
5、不要重复自己
系统内的每一个知识/流程都应该是单一的、清晰地、有权威性的。
6、清晰的代码胜过聪明的代码
不要写凌晨3点醉酒时无法调试的代码。永远不要把变量命名为“data”或“info”。如果实现难以解释清楚，那就是个糟糕的想法。
7、说什么和怎么说同样重要
好想法如果不能沟通清楚就没有意义。要注意你的用语和语气。
8、成为工匠
木桶理论决定一个产品的品质取决于最薄弱环节。这可以体现在模块文档上，体现在开源工具上，或者体现在你午餐会时的产品介绍上。
9、捍卫你的文化
观点的多元化是好事。尊重科学方法找到组织性问题的最佳答案可以在团队之间树立其更牢固的纽带。只招我们希望明天出现在办公室里的人。
10、协作（Collaborate）而不是互证（corroborate）
工作已完成80%的时候要求输入对于评审者来说是不公平的。不要为了让自己感觉更加良好而要求同伴支持。我们鼓励在做了20%的时候请求同伴支持，这样的协作才更有意义。
11、不要收集需求，要挖掘需求
需求很少会自己浮出水面。而是深深埋藏在层层假设、错误的想法以及政治之下。要像用户一样思考，要跟用户一起工作。
当然了，这些原则每一条都可以用一篇文章来论述，但记住下面的话就可以有好的结果：这些原则是对团队重要的东西的基础和出发点。过去曾经是重要的东西，如果现在仍然如此的话，可以添加进来。这就是我们所重视的，也是我们的决策方式。
根据我的经验，这一声明之后应该就是价值观的讨论，这些东西每个团队成员都有，但从未编撰称法典。引入原则永远都能带来更强的凝聚力。
——————————
【招聘】36 氪招聘全职编译编辑，工作内容涉及翻译国外互联网科技、创投类文章；对国外科技动态进行原创报道；管理兼职译者团队。要求中英文功底扎实，对科技行业有了解、有热情，具有一定翻译基础和经验，工作责任心强，沟通协调能力强。简历及网络科技类翻译作品请发送至 lixue@36kr.com
