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

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

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

上一篇我们翻译的 README 来自一位走“民主路线”的管理者（ https://zhuanlan.zhihu.com/p/65147030 ），这一次的 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/blogs/magazine/83782148-the-directly-responsible-individual

我理解 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 助力开发者轻松成为管理者。