優秀的專案管理者是怎麼工作的？如何幫助研發團隊高效工作？這一直是 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 助力開發者輕鬆成為管理者。