前言 技术项目管理的宏观理论很多,而我在本次分享中以我在谷歌从事软件开发和技术项目管理的角度,介绍一下我们采用的一些具体的、细化的实践方法和工具。由于 Google 内部系统庞大,不同的团队在不同的时间会采取不同的方案,我这里只列举一些常用的方法实践,起到抛砖引玉的作用。 OKR 是指 Objectives and Key Results,与 KPI (Key Performance Indicator) 相比,OKR 更融入了战略性的目标和计划的成分。顾名思义,OKR 的制定分为两个部分:Objectives 和 Key Results。 一个简单的 OKR 例子: Objective: 实现向新一代容器管理平台的迁移
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 内不少团队采用三层规划的方式来把控项目进度:
除了外界熟悉的 Scrum, Pivotal Tracker 等敏捷开发管理方法和工具以外, 不少 Google 内部技术开发团队会采取一种 planning poker 的模式来对任务进行把控,具体流程如下:
谷歌内部非常注重开发与运维的分离;对于传统的运维我们定义为手动的、重复性的、没有长久附加价值的人工劳动。因为,谷歌内部鼓励通过 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 和测试流程,除了和大家所熟悉的开发、测试、生产环境的搭配使用以外,想突出两个特点:
下面我简单举几个有意思、有特色的内部人员管理机制实践: 谷歌的绩效考评被称为 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%项目有些名存实亡。 |
|
来自: longabcdyui > 《待分类》