微信号:infoqchina

介绍:有内容的技术社区媒体

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

2015-12-08 08:12 陈天

编者按

本文系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,半年后甚至更久才能跟客户(用户)见面。

使用了某开源 MIT 协议的第三方库或者某个新的技术(如 AWS lambda)做了个 feature,虽然解决方案大大简化,却被告知我们不希望引入更多的依赖,徒增加团队学习的负担。


5 辛辛苦苦做出来的成果,demo 时得到的都是负面的评价(而非建设性的意见,更别说赞许)。


6 想尝试 AWS 上的某个新的功能,却因为权限不足被阻挡在门外(申请权限又需要一个极其漫长的审批流程)。


7 手工部署上线一份新的代码,出了纰漏,造成了无法挽回的损失和影响,于是,当事的「实习生」被裁。


8 公司把你禁锢在某个工作岗位上,于此不相关的非机密项目的技术讨论不希望你参加(美其名曰不浪费你的时间),甚至,文档代码连读都读不到。


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


我们看上述例子,有些是在工程上有解的问题,比如 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)


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


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


推荐

StuQ技能图谱

经常有同学问小Q,自己从事IT行业,对自己的职业技能发展规划与技术方向没有头绪怎么办?小Q觉得这种问题得不到有效解决是有很大隐患的,可也一直没有太好的解决建议可以给到大家。这会给大家带来一个好消息,StuQ在Github 发起了一个开源项目“ IT 职业技能图谱”:把这段时间,他们和专家梳理的 IT 职业必备技能 0.1.2 版发布了出来。大家可以通过 GitHub 更方便的将自己的领域知识加入到这张图谱中。让技能图谱可以持续的细化和更新,变得更有意义。他们采用(CC BY-NC-SA 署名非商用相同方式共享)开源协议。点击阅读原文即可查看!

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 前端--最具文艺范的程序员。 【纪念李光耀】重视职业教育 打造人才航母 我所经历的大数据平台发展史-中篇 互联网时代 “天猫双11狂欢夜”启发广告和卫视圈的是创新模式,革新技术圈的是实时互动 Android 开发者需要知道的8个项目管理技巧