CODING 告訴你硅谷的研發項目管理之道系列（6）

寫在前面

優秀的研發管理者是怎麼工做的，如何更加高效地管理研發團隊？這些一直是 CODING關注的重要話題，咱們不斷地打磨 CODING 研發系統來讓開發更簡單。近期咱們精心挑選了幾篇硅谷科技公司研發管理者的 README 進行翻譯。README 主要用來向團隊成員展現項目管理者的工做理念和工做方式，以便成員可以快速地融入到團隊當中。

原文地址：https://mattnewkirk.com/2017/09/20/share-your-manager-readme/
原文做者：Matt ，Etsy 研發經理
譯者注：Etsy 是一個網絡商店平臺，以手工藝成品買賣爲主要特點。

這是 README 翻譯系列的最後一篇。Matt 受到了 Slack 公司 Roy 的啓發，在此基礎上，他融入了本身的內容：軟件開發方面的價值觀、重視工做和生活的平衡、開放的日程表、重視和其餘團隊的工做關係。

正文

從管理者角度來看，不管你是初來乍到仍是有新鮮血液注入你的團隊，入職這段時間都會有些艱難，同時這個時間段也是相當重要的。如何更好地度過入職階段我認爲有兩個重點：

1. 分享指望
2. 創建信任

既來之則安之。知道你下一步須要作啥嗎？若是你知道團隊對你的指望，你就能夠開始着手進行了。若是不知道，那你須要必定程度的信任來詢問指望問題。

考慮到這一點，我寫了一份文檔和新下屬們分享。我和加入團隊的下屬以及我加入的團隊都分享過這份文檔。不管哪一種狀況，我都描述了：我是個什麼樣的人、我但願如何與他們互動。我給每位新人都強調了這點：我鼓勵討論和反饋。若是我加入了一個新團隊，我傾向於在第一次的 1:1 會議上提這一點而後再發送郵件給他們。若是他們是新員工，我會將其合併到一個更詳細的入職文檔，其中還包含了關鍵資源、要了解的專用名稱、以及第一個月至一年的工做輸出預期。

我從在 Slack 公司工做的 Roy Rapoport（ http://royrapoport.blogspot.com/ ）中發現了這招：我發現 README 是一個與新員工開始創建工做關係很是好的方式。
這是個人管理者自述文件。正如我鼓勵個人下屬作的，若是你有任何的問題或者反饋，請告訴我。

何時你能夠和新下屬開始創建信任關係？

做爲你的 leader

我很是但願經過聊天來更系統地瞭解你，在此以前事先了解個人工做理念可能對你更有幫助。
我來這裏是爲了幫助你、支持你、爲你的工做提供一個平臺，而且爲你和團隊成員搖旗吶喊。個人工做範圍看起來一應俱全，但其實我是爲你而來的。

個人日程表裏塞滿了會議，安排和我一塊兒的會議可能會讓人望而卻步。若是你在個人日程表上看到了空檔，請見縫插針（你不須要先問），而且我會按時出現（除了臨時會議，個人谷歌日程表是 99.9% 準確的）。若是發生了緊急事情你暫時無法和我見面，就給我發一個 Slack 消息或者短信，我會騰出其它時間。若是你須要從新安排會議，那也不要緊。我盡力開放全部日程的修改權限（我用的是這個插件：https://chrome.google.com/webstore/detail/google-calendar-guests-mo/hjhicmeghjagaicbkmhmbbnibhbkcfdb ）。你能夠按照默認值隨時修改咱們約定的會議日程，並將其移動到不與其它會議衝突的工做時間段內。

關於 DRI 模型

• 你來到這裏是由於你的經驗和技能，我不想推翻這兩個。我是來幫助你成功的，但不是規定你應該如何行動。
• 若是我認爲你判斷錯誤，我確定會儘可能勸阻你，但和我意見不一樣並不代表你作錯了什麼。
• 你仍然須要獲得隊友的共識、贊同和投入。 

軟件開發和進度

我堅信要讓團隊成員積極參與過程以及改變過程來達到咱們的需求和目標。 我曾和敏捷團隊以及非敏捷團隊合做過、也以 scrum 以及非 scrum 方式工做過。如下是個人價值觀：

• 我重視發生的事情、已經發生的事情以及將要發生的事情的透明度。
• 我重視速度以及主觀努力，幫助團隊快速前進 (例如，在新功能以前編寫測試代碼、重構遺留代碼、結對編程以提升咱們的代碼質量和下降公車因子）。

譯者注：公車因子（bus factor）描述的是因關鍵人物流失而產生的風險。

• 我重視學習，我知道在技術棧上進行培訓可能並非最快的產效途徑。
• 我重視你的時間，不但願你作任何既對你沒有益處也不符合政策法規的事情。

• 反饋是相當重要的

在建議匿名反饋的狀況下，您可能會聽到我依然建議你提供直接反饋，儘管匿名反饋總比不提供反饋要好。我致力於給你明確和及時的反饋，但願你對我也是這樣。我認爲持續的反饋須要三個屬性: 

• 安全(你應該感到安全， 給予和接受坦誠的反饋) 
• 努力(你和我都不該該對反饋感到防護) 
• 效益(接受反饋應該產生影響) 

在這些方面若是我作得很差請告訴我，感激涕零。

工做和生活的平衡

大部分員工從早上八點（最先）工做到晚上六點（最晚），除非有緊急狀況，不然我不但願在你的工做時間以外與你溝通。我儘可能在非工做時間不回覆郵件和 Slack 消息，而且在任何狀況下也不期望你這樣作，除非有緊急狀況。

1:1 meeting

我認爲 1:1 會議很重要，這些會議應該由你制定議程。你想談論些啥呢？最近發生了什麼？你在煩惱些什麼？除非您真的想談論項目狀態更新， 不然咱們不談它們。對於面對面聊天， 我真的很喜歡一邊步行一邊進行 1:1 ；對於遠程聊天，我很難集中注意力，除非我能經過視頻看到你的臉。若是有什麼事須要個人幫助，我會作， 但這是你的時間。長度、頻率和媒介也由你決定， 但我但願咱們每週至少有 30分鐘， 最好每週有 60分鐘，這個時間還能夠更長。被具體議程驅動的聊天我更喜歡安排單獨的會議（例如目標、查看項目反饋等）， 這樣咱們仍然有空間進行更及時的 1: 1 聊天。

工做關係

我會努力與你創建良好的工做關係， 我鼓勵你與同行、商業夥伴（在辦公室和你的團隊中）以及其餘辦公室的團隊創建良好的工做關係， 這樣能夠更好地瞭解咱們團隊事務的進展狀況。我很樂意爲您作介紹或提供在線建議。

回顧過去一週

我開始寫每週博客總結（雖然個人更新是超級罕見）。它包含了咱們的 1:1 中可能出現的一些主題。這是一個隨時更新的文件，能夠隨時評論， 問問題等等。

你的工做理念

我在這裏寫了不少關於個人理念的文章， 但個人大量工做都在適應你的須要和理念， 我期待和你談論它們。若是你感興趣能夠進一步閱讀：
一、http://randsinrepose.com/welcome-to-rands-leadership-slack/
二、http://larahogan.me/blog/why-cant-they-just/

到這裏 README 系列文章的翻譯內容已經結束了。在看了 6 篇硅谷研發管理者的 README 文件後，你是否也考慮嘗試寫你的自述文件，好讓你的新老闆或者新下屬更快地瞭解你的管理 風格。

寫下你的第一個自述文件

自述文件寫在哪兒呢？ CODING 提供了方便的 Wiki 和文件管理，試着在 CODING 項目當中寫下你第一個的自述文件吧，或者你但願被更多的人看到，能夠考慮經過 CODING Pages 傳遞你的個性、理念、工做方式。

自述文件寫什麼內容？ 幾乎全部的管理者自述文件都包括如下方面：

• 這篇文檔是什麼？

  解釋文檔的背景和目的，這可讓雙方更好地互相瞭解。

• 關於我以及個人工做

  你的工做職責是什麼。
  你的個性是否有什麼不同的地方。
  若是你想了解團隊的我的生活， 那就從分享你的我的生活開始。

• 我的原則/價值觀

  您對人員及其意圖的默認假設是什麼？
  你在合做時採用什麼樣的心態，你但願其餘人在團隊合做中採用哪一種心態？
  什麼事情你不能忍受？

• 一對一

  你但願一對一是什麼樣的風格？ 大多數人遵循每週或者雙週一次，一次 30 分鐘的節奏，由員工控制議程。

• 反饋

  你想要哪一種類型的反饋？
  若是人們對你直言不諱， 你以爲舒服嗎？
  你喜歡如何提供反饋？
  你指望你的團隊對反饋作出怎樣的反應？

• 如何解讀個人日程表

  幾乎上面每一個經理都但願下屬知道團隊是他們工做中最重要的部分，因此他們明確地這麼說。 若是你須要談話，請給他們留言， 他們會抽時間。

除了上述常見內容以外，還包括:

• 我的績效標準

  若是員工問「個人工做表現目前處在什麼水平？」 你將如何迴應？ 大多數經理會經過標記 紅/橙/綠的方式來進行迴應。 雖然綠色和紅色是明確的指標，橙色能夠解釋。 但這意味着什麼，你打算讓員工作出什麼反應？

• D.R.I 原則

  不是每一個人都信奉 D.R.I 原則，但若是你是，它能夠是很是強大的。 首先，你須要設定員工負責任的指望。

CODING 基於硅谷先進方法與中國團隊實踐共同打造一站式開發體驗，全面提高研發與管理效率。涵蓋了軟件開發從構想到交付的一切所需，使研發團隊在雲端高效協同，實踐敏捷開發與 DevOps，提高軟件交付質量與速度。

對往期 README 系列文章感興趣可訪問：
《CODING 告訴你硅谷的研發項目管理之道（5）》
《CODING 告訴你硅谷的研發項目管理之道（4）》