创业及管理：构建利于探索的工作环境

编者按：本文系InfoQ中文站向陈天的约稿，在硅谷的日子里，陈天常参加一些meetup和聚会，这些活动有时会有工程师介绍他们团队的文化和处世之道；平时他也会经常看各种有关创业团队文化的文章/视频，来充实自己的管理思想。这是「创业及管理」系列文章的第一篇。以后会有更多文章刊出，但并无前后依赖的关系，每篇都自成一体。

写在前面：创新是需要不断摸索的，一个公司的文化越有利于员工的探索，就会越有利于创新。敏捷（Agile），如今是个让每个科技公司恨不得天天挂在嘴边的词语。然而，很多公司搞敏捷，只不过是在流程上引入了一些敏捷的实践，却未曾从工作环境和文化上注入敏捷的原力。 本文介绍experiment-friendly的公司文化的意义，以及如何实施这样的公司文化。

正文：

敏捷（Agile），如今是个让每个科技公司恨不得天天挂在嘴边的词语。在这个 CMM (Capability Maturity Model) 已褪去光环，敏捷大行其道的时代，如果一家科技公司不搞些敏捷的实践，仿佛就成了旧时代的破落户一般。然而，很多公司搞敏捷，只不过是在流程上引入了一些敏捷的实践，却未曾从工作环境和文化上注入敏捷的原力。我见过有公司从 waterfall 转向 scrum，培养了 scrum master，培训了员工，投资了各种新生工具，daily standup 做得有声有色，甚至真的通过 planning poker 的方式过家家般来做软件工程里面最难搞定的决策：estimation。

可是，工程文化层面上的反敏捷，导致这一切徒劳无功，敏捷的实施往往就这样虎头蛇尾、无疾而终了。

公司文化的反敏捷

那么，究竟什么是公司文化层面的敏捷呢？我认为是以一个对团队而言最合适的迭代速度持续地探索、学习和改进。其实很多敏捷的实践都是围绕着这个目标而努力的，只是使用者在使用的过程中迷失了方向，比如说每日例（晨）会。本文从探索这个主题讲起，讨论我们该如何构建一个友好的工作环境，让工程师能够最大可能地不断摸索，解决各种各样的工程问题。

有人看到这里会不禁莞尔：作为工程师，我们工作的目的就是不断摸索出解决各种问题的方案，难道真会有公司愚蠢到压制工程师的探索欲望么？

我们先看一些反例：

1. 改两行代码，却要花费几十分钟编译链接。
2. 测试一个新想法（新功能），没有 sandbox 或模拟器，只能在实体硬件上完成（想象一下 iPhone 开发没有模拟器，每次都要将编译好的 ipa 安装到手机上）。
3. 修复了一个 bug，只有几十行代码，code review 却要花上数周和无尽的催促才能被 approve。
4. 做好了一个 feature，半年后甚至更久才能跟客户（用户）见面。
5. 使用了某开源 MIT 协议的第三方库或者某个新的技术（如 AWS lambda）做了个 feature，虽然解决方案大大简化，却被告知我们不希望引入更多的依赖，徒增加团队学习的负担。
6. 辛辛苦苦做出来的成果，demo 时得到的都是负面的评价（而非建设性的意见，更别说赞许）。
7. 想尝试 AWS 上的某个新的功能，却因为权限不足被阻挡在门外（申请权限又需要一个极其漫长的审批流程）。
8. 手工部署上线一份新的代码，出了纰漏，造成了无法挽回的损失和影响，于是，当事的「实习生」被裁。
9. 公司把你禁锢在某个工作岗位上，于此不相关的非机密项目的技术讨论不希望你参加（美其名曰不浪费你的时间），甚至，文档代码连读都读不到。

这些例子都是真实的例子，想必很多读者，尤其在各种大公司打工的读者，也都会遭遇到类似的场景。它们就像某种慢性的毒药，一点点把员工的激情和探索欲望消磨殆尽，而这些消逝的激情和欲望，纵使用豪华的办公环境、米其林大厨精心烹饪的午餐，也很难挽回。

我们看上述例子，有些是在工程上有解的问题，比如 1，2，8；有些是流程上有解的问题，比如 3，4，7；还有一些是文化上需要改变才能得到改观的问题，比如 5，6，9。然而，工程上有解而不去解决，流程上有解却没能解决，归根结底还是公司文化层面的问题。公司在文化上不重视打造利于探索的工作环境（experiment-friendly environment），反映在日常的工作中，便是掣肘丛生，前进三步却要付出倒退两步的代价。就好比在玩三国杀，满腔热血的忠臣，拿着一副好手牌，意图大展拳脚，忠君报国，绞杀反贼，却不料前有主公冷嘲热讽，后有小内暗箭伤人，只能堪堪自保。

讲了这么些反例，想必大家对 experiment-friendly 有一个更好的理解了。 公司需要为员工的高效产出扫清组织上，流程上，沟通上和工具上的障碍，让工作变得更有成就感，让探索和创新随时随处可达。

这事说起来容易做起来难，每个公司都有各自不同的「国情」，很难找到一种“放之四海而皆准”的文化。我们可以学习一些公认的敏捷的公司，如 Facebook，但很难将其文化直接照搬。依我看，如果做好下面的一些事情，那么，公司文化会离 experiment-friendly 更近一步。

敏捷文化之工具流

我们先说工具。工具上的问题是最容易看到收获的，效果也比较好量化。比如说引入各种自动化工具。凡是有过软件项目经历的人都知道 —— 任何严丝合缝的流程，其中最薄弱的一环肯定是人。对于重复性的机械劳动，人是最容易犯错的。这时候要尽可能地把流程工具化。比如说：

• git commit 时设置 commit hook 对代码做 lint 和 static analysis。有多少公司的 codereview 把时间和精力浪费在了 code style 这样本可以用工具来完成的事情之上？
• 使用 CI 工具自动化构建。有多少团队在产出 iOS / Android 的版本时还在本地构建？
• 使用更合适的测试工具来测试你的系统。有多少 android app 的开发者还在吭哧吭哧完全依赖手工对各个机型进行 acceptance test，而非借助 AWS device farm，以及 calabash 等测试工具的力量？
• 使用可反复执行的脚本来部署一个软件系统（如 ansible，cloudformation）。有多少 ops 还在纯手工地上线系统，然后惴惴不安地期待没有问题？

当然，并非所有的工具都能取代人工处理，但我们需要尽可能地借助工具的力量，减少重复性地手工劳动。只有如此，才能节省出更多的时间和减少各种愚蠢的问题，从疲于奔命到处救火中解脱出来，把精力集中到其他更值得解决的问题上。

工具的完善不是一蹴而就的，而是在每个研发周期里不断改进的。一开始，很多事情不得不靠手工完成，可同样重复的事情做了几次之后，就该考虑将其工具化。

流程的敏捷之道

前面提到的 codereview 反馈周期长的问题，就是一个典型的流程问题。当团队或者个人处在自顾不暇的地步，哪有功夫去读别人的 diff？于是就放在一边，能拖多久就拖多久。

这样还会形成一个恶性循环：code review 的作者（reviewee）得不到 reviewer 的快速响应，只好减少发送 review 的频次，导致 code review 的代码量变大，进而导致 reviewer 更不愿意在短时间内做出决策。就这样，本来一个个小的 pull request、代码量控制在三五个文件、几十或者顶多几百行代码内、一到几个 reviewers 应该每日完成的 review 工作，最后变成了跨越若干个模块、几十个文件、成千上万行代码、需要几个 team 联合 review 才能完成的工作，这样不拖到好几周才怪！

所以 第一步是稍稍减轻每个人的负担 ，使其每周有 4～5 个小时时间（可根据情况增减）用于 code review。code review 可以分成两个部分：pre-review 和 post-review。对于一个 pull request，在 pass CI 之后（CI 应该做了 lint，static analysis 和 test），reviewee 要求和 reviewer 坐在一起花个 10～30 分钟走读代码，然后当场决定是否允许 merge，这就是 pre-review。pre-review 不花费 reviewer 过多时间，也不过多阻碍 reviewee 后续的工作，还可以能够扫除大部分潜在的问题。

在 pre-review 中，坐在一起（或者通过 google hangout 等视频方式）共同走读代码很重要。很大一部分 code review 的时间花费在 reviewer 领会理解 reviewee 的代码的意图上面，一起走读对双方而言是时间最优的方式。走读还有一个好处是：reviewee 在讲解的过程中自己就能意识到一些错误。不知道大家是否有这样的经历：自己写的代码，自己反复 review 的时候都没有感到有任何问题，但当把这个代码讲给别人听时，即便别人还将懂未懂，尚在斟酌思度，你自己已经发现了各种问题。这是因为自己读时，思维还是撰写时候的思维，而读给别人时，切换到了想方设法让对方理解的思维上，换了个角度，也就更容易发现问题。

post-review 更多地用于从宏观上发现隐患。一周下来，或者一个 sprint 下来，代码积攒了不少，feature 虽说可以正常工作，但难保没有全局的问题。这时候，多个工程师坐在起，花 1～3 小时（可根据情况增减）把这段时间里团队的所有 diff 过一下，查漏补缺既是一种好的事后补救也是一个相互学习的过程。

简言之，pre-review 工作量小，易于快速完成，为后续工作扫清障碍；post-review 虽然工作量很大，但能够查漏补缺，弥补 pre-review 的缺陷，同时还能促进团队内的相互学习。

一个公司没有合适的流程注定只能小打小闹，上不得台面；但如果把流程抠得太死，明明已经不适应工作的需要，还强行使用，只会降低公司的效率。我们知道，流程其实是在不断解决问题的过程中发现的模式（pattern）。当这些模式固化成流程后，下次遇到类似的问题便可以快速处理。这就好比软件中的 fast path 和 slow path 一样。然而，流程不能一成不变，必须随着公司/文化/人员的变化而变化。上述的 code review 的流程，如果放在一个跨时区的 distributed team 中，就会遇到很多问题。所以，流程一定要随需而变、不断调整，找到对团队而言最合适的点。

同时，我们还需要很 聪明地设置流程 。比如上述的问题 7（想尝试 AWS 的新功能却权限不足），流程制定者的目的是为了安全性而牺牲了易用性。那么，有什么方式能够兼顾安全性和易用性呢？我们可以使用沙箱（sandbox），把安全等级高的行为和安全等级低的行为区别开来。对于 AWS 而言，multiple accounts + consilidation billing 就是对此最佳的解决之道，公司可以开设不同的 account 对应不同的使用场景，比如说：production, development & backoffice。production 和 backoffice 只授予 devops / IT 高级权限，而 development 可以授予任何工程师高级权限。这样，即兼顾了流程对于安全性的需要，又使得工程师可以在一个安全的沙箱内随意尝试，一石二鸟。

在构建 experiment-friendly 的工作环境的过程中，只要肯扩大眼界，用心思考，工具和流程会是比较容易实施且很好看到效果的方法。

一些思考

最后是文化层面的考虑。也就是对于人的管理，授权和培养。对于本文而言，我觉得三点很重要：

• 信任优于控制（Trust over control）
• 承诺优于服从（Commitment over Compliance）
• 数据优于权威（Data over authority）

拿「数据优于权威」来说，它其实解决这样一个问题：究竟是上级（权威）的个人品味重要，还是真实的、有说服力的数据重要？相信没有人会认为权威比数据重要，然后在实际工作中，往往是「官大一级压死人」，领导的喜恶常常决定了产品的方向。这个只能靠自上而下推行的文化层面的努力来消弭了。

文化是一个很大的主题，且很难找到又具体又放之四海而皆准的经验。在这里就不展开讲了。

感谢魏星对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群 （已满），InfoQ读者交流群（#2） ）。