前言
技术项目管理的宏观理论很多，而我在本次分享中以我在谷歌从事软件开发和技术项目管理的角度，介绍一下我们采用的一些具体的、细化的实践方法和工具。由于 Google 内部系统庞大，不同的团队在不同的时间会采取不同的方案，我这里只列举一些常用的方法实践，起到抛砖引玉的作用。
OKR 是指 Objectives and Key Results，与 KPI (Key Performance Indicator) 相比，OKR 更融入了战略性的目标和计划的成分。顾名思义，OKR 的制定分为两个部分：Objectives 和 Key Results。
一个简单的 OKR 例子：
Objective: 实现向新一代容器管理平台的迁移
KR1: 在 3 个实验数据中心里实现应用全部都运行在新的容器平台上
KR2: 实现 99%以上的故障可以通过容器平台自动修复
OKR 的制定是分层级的, 首先公司会制定一个公司级别的战略 OKR，然后围绕着这个目标，各个 PA（Product Area）、一直到各个行政组、一直到个人都会制定更细化的 OKR。一般 OKR 是按照每个季度制定一次，而公司层面通常会有更长远的年度 OKR。
在每个季度结束时我们会审核 OKR 并给 OKR 做打分，由于 OKR 在制定之处是从公司到团队到个人，在审核时我们同样查看在不同层面、不同领域、不同团队的完成情况。并在各个层面打出 0 到 1 的一个分数（1 表示完全完成，0 则表示没有开展任何工作）。在打分时，我们十分强调功能上线并经过验证；仅仅是代码开发好但并未上线经过验证的功能／任务，得分不会超过 0.6。OKR 的打分会影响到产品、团队的绩效和个人的 performance review，我们也会将当前季度的 OKR 与以往季度的 OKR 进行对比，来分析走势。
一个有意思的问题是 Google 认为最理想的 OKR 平均得分是多少。答案并不是 1，而是 0.7。我们在制定 OKR 的时候，强调要有 stretch goal，要 be aggressive，所以大家很难把所有的目标都实现，而留有未完成的空间则会充分激励大家尽量去缩小和“1”的差距。事实上，Google 整个公司的 OKR 是 0.67 左右。
Google 内不少团队采用三层规划的方式来把控项目进度：
季度 OKR 层面：如上所述，每个季度根据 OKR 结果来跟踪进度。
Sprint 层面：一个季度内制定多次的 Sprint（冲刺），一般与每次发布对其，周期为 1 周到几周不等。
每周的层面：每周的技术 Sync 保证当前的 Sprint 进展顺利。
每天的层面：有的团队会每天（或隔天）进行比较敏捷的 “standup”，小组内大家站在一起，各自用简短的语言汇报工作并确保“路障”能被及时清除。有意思的是，为了确保这个 standup 简短有效，有的团队要求大家在发言期间采取 “Wall Sit” 的姿势（一般人 Wall Sit 一分钟就会比较吃力），迫使大家或者简洁或者好好锻炼身体：）
除了外界熟悉的 Scrum, Pivotal Tracker 等敏捷开发管理方法和工具以外， 不少 Google 内部技术开发团队会采取一种 planning poker 的模式来对任务进行把控，具体流程如下：
首先，在每一个 Sprint 周期伊始，我们按照优先级把该 Sprint 内所需完成的任务列表列出来，并赋予优先级排序。
其次，我们拿几个写有斐波那契数字的牌：1, 2, 3, 5, 8, 13，其中数字代表一个任务的工作量的权重。
对于上述任务列表，团队中的每个成员独立打出一个牌来代表自己对于该任务的任务量评估。对于一个任务，当大家给出的分数不同时，会有给出最低分的人和给出分数最高分的人来辩论，而且大家进行二次投票。
一旦任务的权重被分配，我们会将会记录每个 Sprint 周期内团队所能完成的点数。几个 Sprint 以后，我们就会有一个不错的对于团队效率的计算（例如一个 Sprint 平均能完成 80 个点），便于后面的任务安排和规划。
谷歌内部非常注重开发与运维的分离；对于传统的运维我们定义为手动的、重复性的、没有长久附加价值的人工劳动。因为，谷歌内部鼓励通过 Devops 的方法逐渐减少传统运维的成分。例如谷歌内部采用自动化的集群管理平台（基于容器技术和容器集群管理平台 Borg 等工具），使得一名运维人员（与传统运维人员不同，谷歌内部称之为 Site Reliability Engineering）平均可以管理上万台服务器。谷歌具体的开发与运维分离方法包含两种：
将开发者（SWE：Software Engineer）与运维者（或者谷歌特色的 SRE: Site Reliability Engineer）分岗，SRE 转岗负责更多的平台级别的维护。同时，即使在 SRE 岗位内部，谷歌也严格控制每名 SRE 所参与的手动运维时间，尽量将其控制在 50%一下，保证 SRE 能有一半的时间投身于自动化运维工具、系统、平台的研发。当然，SRE 也有 oncall，当接收到紧急任务时（被传呼），当值的 SRE 需要在 10 多分钟内到达键盘前做出响应。
在开发者中也不可避免的从事一些运维或者处理应用突发事件的时候。例如当某个线上服务出现问题时，SRE 往往会找到对应的开发团队协助调查原因并提交修复补丁。为了减少此类突发事件对于开发人员的研发任务影响，不少开发团队采用 interrupts 轮岗制：在每一个产品版本发布周期内，轮流由一名开发者来担当 interrupts 角色，并与 SRE 团队协调，成为 SRE 的 point of contact，负责处理外来 interruption 和 bug 的初步诊断（triage）。
此外，谷歌的产品新版本上线有着严格的 QA 和测试流程，除了和大家所熟悉的开发、测试、生产环境的搭配使用以外，想突出两个特点：
谷歌的产品测试不依赖于专门的测试工程师，而是要求软件作者自己要去进行一系列的单元、整合测试，以及在测试环境的测试等。软件作者在极大程度上是自己代码的负责人。
在新版本的发布过程中，我们深度采用了不同形式的灰度测试机制。例如如果是平台软件更新（例如容器集群平台，服务器基础镜像升级），是按照一定的速度逐渐更新到不同的数据中心，例如第一天发布到一个数据中心，第二天发布到 5 个数据中心，以此类推，并在过程中不断进行 A/B 测试和对比。如果是面向用户的产品（例如广告、购物等），则会采用基于用户流量分流的灰度发布法，例如先选择 5%的用户流量使用新的版本，并且自动收集 metrics 来进行新、旧版本的比对。
下面我简单举几个有意思、有特色的内部人员管理机制实践：
谷歌的绩效考评被称为 Performance Review，通常是每个季度或半年进行一次。其中很大的亮点就是该考评主要依赖于同事之间互评（peer review），同事的级别越高，review 越有份量。这样的初衷是避免将员工的绩效打分大权完全交给顶级上司，同时也为了促进健康的同事间关系和积极的互帮互助。Performance review 分为 below expectation, meets expectation, exceeds expectation, strongly exceeds expectation 和 superb 几挡，其中每次 performance review 达到 meets expecation 以上的有近 40%左右。
为了保证技术人员的创新活力，谷歌内部鼓励一定程度的项目轮换。一般在同一个产品线或团队中待满一年并且绩效考评达到要求后，可以自由的换岗。寻找新的产品团队时既可以通过谷歌内部的招聘大会和招聘平台，也可以通过口口相传。
谷歌一直以来有一个 20%的传统，就是允许每一个工程师拿出 20%的时间去做一些对公司长期发展有利的“副业”，包括学习新技能，参加培训课程，参加学术研究，做有意思的新产品等。这个制度的初衷是保持员工的技术积极性，同时保持谷歌的创业创新文化，例如 Gmail 就是从 20%项目发展而来的。然而今年随着 20%项目在 Performance Review 中受重视程度降低，导致 20%项目有些名存实亡。
联系客服
