CODING 告诉你硅谷项目经理的项目管理之道（2）

优秀的项目管理者是怎么工做的？如何帮助研发团队高效工做？这一直是 CODING 关注的重要话题，咱们不断地打磨 CODING 研发管理系统来让开发更简单。
近期咱们精心挑选了几篇硅谷科技公司研发管理者的 README 进行翻译。README 主要用来向团队成员展现项目管理者的工做理念和工做方式，以便成员可以快速地融入到团队当中。

原文地址：https://bit.ly/welcometonetfl...
原文做者：Roy，现任 Slack 研发主管，曾就任于 Netflix。

上一篇咱们翻译的 README 来自一位走“民主路线”的管理者（ https://zhuanlan.zhihu.com/p/... ），这一次的 README 来自一位“硬核风”的管理者——Roy。Roy 在 Netflix 与 Slack 前后有两个 README，下文是他在 Netflix 时使用的。这也是你能够在网上找到的首批管理者自述文件之一，许多人从 Roy 身上获得了启发。

欢迎来到 Netflix，致个人新下属。
Roy Rapoport
2016 年 2 月 13 日

文档说明

免责声明：如下内容不适用于 Netflix 或其它组织的在职经理。

我但愿经过这份文档快速地向你们介绍 2016 年我是如何在 Netflix 管理研发团队的。它仅表明了 Netflix 文化与个人管理风格的独特融合，并不能表明我在其它组织或者 Netflix 其余管理者的方式。经历过了种种快乐，我在 2018 年 1 月离开了 Netflix，从那时起这份文档彷佛就变得不实用了。但有很多人但愿可以继续参考它，所以它依然开放给你们。

写这么个文档貌似是有点奇怪，不要紧，咱们还会有不少机会相互了解。这是我目前能想到的高效介绍一些事情的最好方式。它不只仅是一个 PPT（译者注：原文是 PPT 格式，为优化阅读体验译者改成文章格式，但内容不变），更是一个信息公告。进入正文前你最好先阅读并熟悉下 Netflix 公司文化（ http://jobs.netflix.com/culture ）。

关于个性冲突

我不认为在工做上存在不可调和的个性冲突，咱们或多或少都会有一些实质性的观点差别。在调整个性方面，我认为管理者应该适应下属的个性风格，毕竟管理者能在工资中获得“委曲求全”的部分报酬。

D.R.I 原则

译者注：Directly Responsible Individuals 直接责任我的，为每一个项目分配一个 DRI，最终要对该项目的成功或失败负责，欲进一步了解推荐阅读：https://originalfuzz.com/blog...

我理解 D.R.I 原则意味着：

• 要么你作决定，要么是我，但绝对不是咱们两个一块儿作决定
• 咱们各自的责任范围不会重叠
• 我不能覆盖你的决定
• 当我不认同你时，我会尝试去说服你
• 若是我不相信你的判断是合理的，我能够解雇你
• 不要由于担忧判断错误，就不敢提出你的意见

做为一个 DRI 意味着

• 没必要和其余人达成共识
• 没必要获得其余人的赞成

做为一个 DRI 并不意味着：

• 你作事能够不通过大脑
• 你没必要解释你为何作出某种决定
• 没人会事前过后指出你犯了错误

个人工做职责

• 吸引和留住世界一流的人才（别左顾右盼了，就是你）
• 协调内外部资源，为团队提供良好的平台

若是我作了什么事让你不太想留在公司，或者让你以为我在对你指手画脚而不是提供平台，恳请你必定要尽快告诉我。

关于反馈

我爱死反馈了，反馈是你和我在 Netflix 取得成功的关键。 人们通常须要三个维度的条件都知足才能持续给出反馈：

• 高安全感：不会由于给出负面反馈受到惩罚
• 低成本：没必要由于要给上级反馈、也没必要由于收到反馈时和他人争论耗费大量时间
• 高收益：给对方反馈以后，有多大可能性会让对方有行动上的改变

你们都叫我“钢铁直男”。 比起言辞上的善意，我会优先关注表达上的效率，但我也会在保证正确传达信息的状况下尽可能维持善意。由于确保你完整收到个人反馈是个人重要工做。

工做时间

• 我尽可能不在工做时间（8:00～18:00）外和你谈论工做。
• 我有时也偷偷懒，请请假。
• 除非我清楚地代表这是紧急状况，不然当我在私人时间发你消息，你次日上班回复我便可。
• 理性来说，即便在工做时间里，你也无需全天候回复我。
• 在工做时间外我并不肯意打电话给你，若是我打了，必定是紧急状况。从目前来看，这种状况不多，低于 1 次/年/人。
• 以上这些仅限于我联系你的状况，不包括 on-call 职责和生产环境的紧急呼叫。

个人日程表

若是你想跟我聊聊尽管来找我。

虽然我在这儿干不少杂七杂八的事情，但当你想谈话时，几乎没啥事情比花时间和你沟通来的更重要。因此你能够随时在个人日程表上安排谈话时间。（实际上，在 Netflix 你们都这样，只要发送会议请求就行，不用额外征询他人赞成。）

把事务放在日程表上的万无一失了？那也只是口头承诺。下图是我在 2016 年 2 月随机一周的日程表。日程表目前只有 8 个空格是空闲的，它们不久也会被填满。也不用太执着于个人日程表，可能你在表格上找不着任何空闲时间，但若是你想沟通，咱们就沟通。让我知道你的电话号码或者其它联系方式，我会想办法推掉一些事情来找你聊聊。

（译者注：原图做者已打马赛克）

关于解雇

是否是开始担忧被解雇了？放心吧，在你工做的头 3 个月里，你会高度怀疑本身随时会被炒鱿鱼。 问问最近刚加入 Netflix 的工程师们是否是也经历过这种恐惧。颇有可能至少有两我的回答“是的”，有这种恐惧的心情再正常不过。若是你在 Netflix 快待满 3 个月，那么恭喜你，很快就不用担忧被解雇了。除非我已经明确直接告诉你，你有被解雇的危险。

关于个人炒人记录。直到 2016 年 2 月 14 日，我已经担任研发管理者三年多了，在这段时间里：

• 招聘了九我的
• 有两我的被我调岗
• 解聘了三我的

让我兴致盎然的是：如何让员工在得知本身因业绩问题被我解雇时不会感到惊讶。目前为止我在这方面很成功。主要是由于个人直言不讳，你才不会感到惊讶。

绩效断定表

我认为每个向我汇报的人，在任何特定时间点都处于如下三个特定表现水平之一 。

• 绿色：你可能有些事情想要改进，有些事情我但愿你能改进。但若是你什么都不改变，也行吧。考虑到咱们目前的用人要求，你想在这工做多久就工做多久。
• 橙色：长远来看，你目前作的事情让你的发展轨迹受阻。若是不改变，那么估计事情的结局不会太好，你须要改变一些事情。
• 红色：短时间来看，你的发展轨迹是受阻的，并且咱们会有一个具体的时间窗来改变它。你和我会明确地讨论问题出如今哪儿了，以及如何去修复它。

有时候我过后会意识到你实际是处于橙色状态而不是绿色，可是红色历来不会是后见之名。若是你问我：“如今我处于红色状态吗？”我会回答：“若是你非要问的话，那答案就算不是吧。”

变成橙色状态了？赶忙准备下家吧。
开玩笑的啦。橙色状态彻底是能够恢复过来的。 在过去的三年里，做为研发主管个人绩效已经变橙 2～3 次了，但每次我都恢复过来了。我从橙色中迅速恢复的能力提升了上属对我完成工做和自我纠正能力的信任。 这对我手下的人也是同样。若是你陷入橙色状态，你能够努力恢复，一旦你将其恢复过来，将会提升我对你的信任。

即便进入红色状态也不意味着必定会被解雇。也有一些人曾陷入红色，努力挣扎而出，最终在 Netflix 得到了事业成功。

若是你还在这里工做， 那是由于我对你仍然充满信心。若是我失去了信心，我不会再浪费时间管理你，而是给你至关慷慨的离职金——解雇你。

自我认识

个人优点：

• 常常给你反馈，不管是正面的仍是负面的。（换言之我很坦率）
• 确保个人信息可以正确传递。（换言之我很直白）
• 当我接受到反馈后，我会采起行动，而不是左耳进右耳出。

我已知的缺点：

• 有人指责我对“提供支持而不是指手画脚”有着极端的见解。
• 直到你证实了你具有不须要我“指手画脚”的能力时，我才可能在你作事时保持沉默。（若你提出问题或寻求意见时，我依然会倾囊相助。）

关于 1:1

咱们团队的 1:1 囊括了各类频度和长度的会议（每周 1 小时或者双周 15 分钟）。对于新员工，咱们会以一个高频度、高时长的会议开始 1:1，它是专门为你进行的。除非你想要报告事务的状态更新，不然咱们在 1:1 上是不会谈什么事务状态的事情。咱们中的任何一我的均可以迟到 5 分钟。5 分钟的迟到在咱们公司见怪不怪，但我仍是会努力不迟到。

关于坦率

公司也许会要求我在指定日期前向你保密一些事情（例如经理们会比公告时间提早一个星期知道股票期权的变化），这在我管理团队的三年里也只发生过一次。公司不能要求我骗你，这之前没发生过，之后也不会发生（我也从没被要求这么作过）。咱们倾向于透明与坦率，你能够问任何问题，大部分时间我会回答，少数状况下我不会回答你。但我承诺我不会对你撒谎。

最后

若是你向我汇报（不管是直接仍是非直接），你都有编辑这个文档的权限，这是我特地向你开放的。

译后记

Roy 是位让人印象深入的领导人，这也和 Netflix 总体精英化的团队氛围有关。Roy 鼓励员工进行独立决策、很是强调彼此坦诚相待、高度重视反馈，他在团队中只保留高效的人才，但他也重视下属的进步。 开发者成长的路径有许多，能够是技术架构、售前解决方案、运维支持等等。关于研发项目管理，CODING 也有几个理念与你们分享：

• 增强研发团队间协做，打破壁垒与部门墙。 结合敏捷开发思想，CODING 提供全面而又灵活性极高的任务协同工具。从用户故事开始，到需求池管理以及任务拆解、缺陷管理、测试管理，覆盖整个敏捷研发管理所需，为项目管理者提供全面详尽的统计报告，助力团队研发效能提高，实现 Scrum 迭代式开发。
• 自动化的研发流程，减小人力的重复劳动。 CODING 提供持续集成到自动部署的全过程工具：自动构建、自动化测试、构建物管理、部署交付。支撑项目的快速迭代，保证软件稳定、持续构建和发布。能够无缝对接第三方运维管理工具，支持多种软件交付过程，实现 DevOps 持续交付全流程应用。

CODING 助力开发者轻松成为管理者。