女博士工程师:聊聊硅谷互联网公司的开发流程

之前很多文章或多或少已经说了一些点,现在很多国内公司也参考了一些流程,最近从始至终参与并负责了两个比较大的项目。这篇文章就系统的说一下开发始终吧。总的说来,我们的开发流程包括如下阶段:

  • OKR 的设立
  • 主项目的确立,子项目的确立
  • 每个子项目的生命周期
  • 主项目的生命周期
  • 收尾、维护、复盘

由于篇幅问题,这里就和大家分享下前面三点,对后面也感兴趣的读者,可以直接扫码订阅我的专栏《朱赟的技术管理课》。这个专栏,分享了我从技术到管理的心路历程和经验总结,为你讲解最新技术实战与硅谷文化。

第一点,OKR 的设立

所有项目的起始,应该都是从 roadmap 做起的。硅谷公司一般 OKR(Objectives and Key Results)都是自顶而下的。也就是说,先有整个公司的 OKR,然后有每个部门的 OKR,再有大组的 OKR,再到小组的 OKR,确保整个公司有着一致的目标。在这过程中,技术驱动就反映在哪些方面呢:

首先,确定Roadmap 的过程,我们会采用( Survey)模式,确保工程师的声音可以准确地触达到管理层。比如:工程师会觉得基础架构比较薄弱,公司就会加大这一块的支持力度。如果大家觉得开发环境很低效,就会把这个也放到 OKR 的考虑。硅谷的公司一般会分为产品组和系统架构组。总的说来,系统架构组的 OKR里,工程师的声音会很大。

其次,项目怎么做,怎么规划,一般是由工程师来决定。OKR 只确立目标。是不是要起新的服务,是不是要沿用现有的架构,技术选型等等,这些不是 OKR 的组成部分。

最后,估算 OKR 里的目标工期的时候,我们会除去一些用来做技术创新和支持的时间,比如编程马拉松,开源支持等的事务。谷歌的员工会给自己留 20% 的自由项目时间,这些都是时间缓冲区。

(注:OKR 是企业进行目标管理的一个简单有效的系统,能够将目标管理自上而下贯穿到基层。

扫码即可订阅我的专栏

第二点,主项目及其子项目的确立

一旦确立了 OKR,下一步就是确立主项目和子项目了。主项目是主要的技术或商业产品,一般由产品经理、技术经理和一些技术骨干经过产品需求和技术讨论之后,确定要做什么(Scope),不做什么(Non Scope)和大的里程碑(Milestone);后面我会在“工程师、产品经理、数据工程师是如何一起工作的”一文中更详细地介绍不同角色之间的合作细节。

一旦主项目确定了,就需要安排不同的人做不同的模块,也就是子项目。一般团队协作有两种方式:一种是每个人负责一个子项目,从始至终;另一种是大家先一起完成基本框架,然后逐个需求、逐个模块推进,最终一起完成整个项目。

下面,我来谈谈两种协作方式在实践中的优缺点对比。

第一种协作方法:每人完成一个子项目。

优点:责任清晰,每个人都知道自己的职责,工程师们也有更多的拥有感,他们可以独立负责产品的设计、实现、测试和维护,工作贯穿整个项目过程。

缺点:如果负责某个子项目的工程师设计或者实现能力不足,由于比较独立,这个子项目很容易成为路障或者瓶颈,工程师之间也缺乏互相学习的机会。

另外,因为是按人并行推进项目,需要根据每个人设置里程碑,管理的时候,技术管理者需要常常跟进每个人的进度,管理代价更高。代码审核往往也只是有限的几个人参与。

第二种协作方法:所有人一起逐次完成每个模块或需求。

优点:工程师之间合作最大化,可以彼此协调、彼此学习、在对方有事的时候相互补位。项目管理有明确的统一的里程碑,每个工程师都有机会接触更多的工作,每个人的代码可以有更多人参与审核。

缺点:每个工程师的责任不是那么明显,很容易出现能者多劳、勤者多劳的现象。一些新人总是做一些执行或打杂的事,得不到锻炼。

这两种模式我都曾亲身经历过,感觉两者各有利弊。现实中可以根据情况组合使用。比如,两到三个人合作负责一个模块,也可以在每人一个模块的基础上,将小模块组合成大模块。然后每个大模块有个技术负责人(Tech Lead),对一些能力不足的工程师给予指导和支持等。

第三点,每个子项目的生命周期

子项目一旦确认,它的生命周期就融入到工程师们的日常工作中,内容如下。

1 开发初期的设计文档。一般使用可以共享的谷歌文档(Google Docs),Quip 等。不同的人可以编辑或者评论、阅读。一般设计文档会先由组内工程师和产品经理审核,然后到大组评审(包括 Legal,Compliance,Finance 等等)。

如果涉及公司的整体架构,还需要发给全公司审核。参与审核的人员是所有的工程师。很多人会有选择的参与一些设计的审核,通常技术骨干会预留时间审核所有的技术设计文档。设计文档不仅包括怎么实现,还有选型的理由、考虑的因素、支持和不支持的属性、时间线等等。

2 设计测试实验,这是可选的,如果针对某个产品需求我们想知道用户的反馈,就需要数据工程师参与设计实验,也就是 A/B 测试。实验中的数据埋点也会在下一步的实现中完成。

3 一旦设计文档锁定,就可以开始实现了。不论是单人负责还是多人合作,实现都是按照多次代码提交(Pull Requests)来迭代的。每次代码提交要写清除代码改动的摘要和测试。并通知不同的工程师审核。

4 所有的实现都要加入监控、日志、预警代码。

5 所有实现都是隐藏在一个开关后。当代码都就位后,就开始灰度发布。通常是先发布给几个开发人员测试,然后到项目组,然后到其他员工(Google 称之为 Dog Food,因为他们可以大量使用自己的产品),最后按照百分比推给用户。

推送的过程中会结合 A/B 测试,只有测试结果显示对用户体验、公司主要的指标( Metrics )没有明显的负面影响,才会正式发布给所有用户使用。

6 对一些需要重构的关键产品链路,有时候也会使用双重写入(Dual Write),就是新特性和旧特性都写入数据库,并通过不同方式比较两个实现的结果。只有验证结果一致时,才会将交易(Traffic )从旧实现切换到新实现。

7 最后是一些扫尾工作,包括移除用来做 A/B 测试和灰度发布的代码开关等,有时候还会有一些次要需求的实现。

我是朱赟,极客时间专栏《朱赟的技术管理课》出品人,计算机博士,前Airbnb技术经理,公众号“嘀嗒嘀嗒”作者。

此专栏囊括了技术管理、技术实践、硅谷文化、个人成长等5个维度的内容。无论你是初入职场的程序员,还是正面临技术转管理选择的职场中人,相信都能在此专栏中有所收获,找到成长跃迁的最佳路径。

原文发布于微信公众号 - 芋道源码(YunaiV)

原文发表时间:2018-08-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏PPV课数据科学社区

大型网站架构系列:电商网站架构案例

大型网站架构是一个系列文档,欢迎大家关注。本次分享主题:电商网站架构案例。从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型。除具备功能...

5217
来自专栏CSDN技术头条

视频监控“入云”11个理由

VSaaS(视频监控作为一种服务),是指基于云托管的视频监控。该服务通常包括视频录制、存储、远程查看、管理警报、网络安全等内容。据统计,93%的企业已经采用了云...

8075
来自专栏纯洁的微笑

HRMS(人力资源管理系统)-SaaS架构设计-概要设计实践

https://www.cnblogs.com/hegezhou_hot/p/9753733.html

3831
来自专栏新智元

GitHub重磅年度报告:JavaScript最热,中国开发者贡献稳居第二

在昨日举行的GitHub Universe 2018开发者大会上,GitHub发布了一款重量级产品:GitHub Actions,可直接运行部分代码的产品,彻底...

1022
来自专栏智能计算时代

微软保护物联网的新颖方法

Sopris项目希望创建一套可以保护硬件和通信的安全层,并且可以刷新受影响的设备。 ? 事物部署工业互联网面临的主要问题之一是常年问题:安全。当您在组织周围部署...

2745
来自专栏CSDN技术头条

SDCC 2015架构专场札记:一线互联网公司的架构实践

【编者按】11月21日,为期三天的SDCC2015中国软件开发者大会成功闭幕,主办方总计邀请了95余位演讲嘉宾,为参会者奉献了10个主题演讲,9大技术专场论坛(...

2177
来自专栏BestSDK

如何以更少的成本、更便捷的方式构建私有云?

这些选项与传统的服务器部署模式类似:你可以部署在自己的服务器上,也可以在一个联合本地中心部署,你甚至可以在“托管但是专用”的基础上使用一个传统的托管服务。   ...

3477
来自专栏云计算D1net

保护共享技术的云安全贴士

公共云服务解决方案仍然还将继续保持其强劲的增长势头,因为他们可以快速的实现部署实施,有比私有云更低的成本,而且仅仅只需企业组织的IT工作人员提供最少的支持。然而...

3414
来自专栏云计算D1net

从内部部署到云存储的演变

22310
来自专栏WeTest质量开放平台团队的专栏

建一座安全的“天空城” :揭秘腾讯 WeTest 如何与祖龙共同挖掘手游安全漏洞

《九州天空城3D》上线至今,长期稳定在 APP Store 畅销排行的前五,本文将介绍腾讯 WeTest 手游安全团队在游戏上线前为《九州天空城3D》挖掘安全漏...

1700

扫码关注云+社区

领取腾讯云代金券