CODING 告訴你硅谷項目經理的項目管理之道

寫在前面

*優秀的項目管理者是怎麼工做的，如何把一個研發團隊的績效激發到最大？
咱們精心挑選了幾篇硅谷科技公司研發管理者的 README 進行翻譯。
README 主要用來向團隊成員展現項目管理者的工做理念和工做方式，以便成員可以快速地融入到團隊當中。
下文的 README 來自 Slack 的研發總監 Rand。
原文地址： http://randsinrepose.com/archives/how-to-rands/
原文做者：Michael Lopp (又名 Rands)，Slack 的研發總監
（譯者注：Slack 是美國一款基於雲端的團隊協做工具。）*

你好，歡迎加入團隊。很高興在 Slack 碰見你。

你至少須要一個穩定的季度把這個團隊和業務弄清楚。我理解一位新人來到公司時急於表現本身的心情。但這是一個複雜的地方，充滿了一樣複雜的人。你能夠慢慢來，先從與每一個人見面開始，參加每次會議，記錄會議內容並提出你碰到的問題——特別是那些看不懂的縮略語和表情符號。

咱們之間的關係是首先須要定義的工做關係之一。如下是個人「用戶指南」以及個人工做方式。它涵蓋了咱們一塊兒工做的平常周裏你能得到的內容、我喜歡的工做方式、個人北極星原則、以及個人個性特色。我但願經過這份文檔爲咱們的工做關係快速預熱。

平常工做周

除了高警惕狀態（見下文）以外，咱們每週至少須要 30 分鐘來進行 1:1 （一對一）交談，這個會議只討論實質性內容。我爲咱們兩人建立了一個私聊羣組用來討論 1:1 的主題，同時可以方便地查看咱們討論的歷史記錄。當咱們想到某個主題時，能夠直接發到這個羣組中。

咱們團隊內部每週都有 60 分鐘的碰頭時間。與 1:1 不一樣的是，咱們有一個涵蓋整個團隊議程主題的共享文檔。與 1:1 相似的是，咱們不討論事務的狀態，而是討論影響整個團隊的實質性問題。

你能夠一天 24 小時發消息給我，我習慣當即回覆消息。

若是我有旅行計劃，我會提早通知你。儘管可能有時差，咱們以前預約的全部會議仍然按時進行。

我在週末有時也會工做，但這只是我我的的選擇，我不會強制要求你週末去上班。我有時也會懈怠，除非事情緊急，不然老是能夠等到週一再處理。

我會使用年假，我建議你也應該使用。專一於私人事務時，我將不處理工做。

北極星原則

譯者注：北極星原則指的是團隊明確同一個方向前進，保持一致的願景。

團隊第一。我相信快樂、透明、高效的團隊會創造出色的產品，因此個人工做主要是不斷優化團隊。其餘團隊的管理者可能選擇最大化商業、技術或任何其它重要方面。但我也認爲思惟多樣性是高效團隊的關鍵，並且全部觀點都是相互關聯的，因此咱們需有這些想法不一樣的管理者，但個人我的觀點仍是高效團隊第一。

人人皆可領導。個人妻子常常提醒我：我討厭職業生涯裏頭十年的會議。確實如此，我已經被糟糕的經理們舉辦的糟糕會議浪費了大量時間。做爲一名工程師，即便也是一位經理，我仍然對經理持懷疑態度。雖然我認爲管理者是大型組織的重要組成部分，但我不認爲他們壟斷了領導力。我努力在團隊中創建機制和創造機會，以便非管理者也能夠高效地領導團隊。

系統地看待事物。我習慣把將全部複雜的人員和事務整合一個到系統中，再用流程化的方式思考。我很是樂於瞭解這些系統和流程圖是如何組合在一塊兒的。當我發現系統中存在大大小小的低效率時，但願你能和我一塊兒修復它們。

公平對待團隊。我相信大多數人都努力公平地對待他人，但無心識的偏見會致使他們的行爲出現誤差。我也在努力解決偏見，由於我知道偏見會製造出不平等的現象。

心動不如於行動。花長時間不停地討論潛在方向固然是有價值的，但我相信行動是開始學習和取得進展的最佳途徑。固然這也並不老是正確的，這種策略經常遭到一些喜歡辯論的人的反對。

不要忽視每次小改進。我理解不斷地改進小事情的複雜性，但我也相信質量保證是每一個人的責任，而且待改進的錯誤真的是無處不在。

在事務開始前，我會預設全部參與者都是想要積極參與的，這對個人職業生涯有很大的幫助。

高度戒備狀態。當公司處於高度戒備狀態時，團隊的運做會變得和平時不太同樣，我平常的許多實踐和原則開始有了例外。進入高戒備狀態一般是由於內外部出現了對咱們公司的實質威脅。在抵禦這些威脅期間，平常的團隊管理、流程和產品原則都成爲了次要事務。若是高警惕狀態不是很明顯，我會提醒你們咱們處於這種狀態，同時我會給出何時結束這個狀態的預估。若是我一直處於這種狀態，極可能是發生什麼大事了。

反饋方式

我堅信，反饋是在團隊中創建信任和尊重的核心。

Slack 每一年會有兩次的正式反饋週期。在咱們第一次經歷這個週期，咱們會爲你起草下一個審查期間的 OKR。這些不是產品或技術 OKR，這些都是你的職業成長 OKR。在咱們開審查會議以前，我會把 OKR 以及團隊總體反饋發送給你，這樣你就能夠提早了解狀況。

譯者注：OKR(Objectives and Key Results) 全稱爲「目標和關鍵成果」，是一套定義和跟蹤目標及其完成狀況的管理工具和方法：可以將目標管理自上而下貫穿到基層。1999 年英特爾公司發明了這種方法，後來被 John Doerr 推廣到甲骨文、谷歌、領英等高科技公司並逐步流傳開來。

在咱們第一次的面對面會議，除了肯定下一週期的 OKR，我還會徵求你對我日常工做的意見。在以後的審覈週期又會有很大的不一樣，我將對照咱們以前既定的 OKR 對你進行審覈，若有必要我將引入新的 OKR，按照這種方式持續調整並重復。

審覈期不是咱們交換反饋的惟一時間點，這將會是咱們日常 1:1 中反覆出現的主題。我將在 1:1 裏按期向你詢問反饋。不管你多少次告訴我你沒有反饋，我永遠不會中止個人詢問。

分歧就是反饋，咱們越早學會如何有效地表達彼此的意見，咱們就越早相互信任、相互尊重。簡單的「贊成」不會讓想法變得更好。

會議約定

我天天會參加大量的會議，因此我將日程都共享給大家。若是你對日程上的會議有疑問能夠隨時與我溝通。若是是私密或保密的會議，你可能不會看到會議的相關內容，但這種會議是極少數的。

我認爲一個標準會議須要包括具體議程、預期目標、適當數量的高效與會者，以及會議主持人。不管是參加會議仍是主持會議，我都但願會議可以按時開始。若是我不清楚爲何要參加某個會議，我會要求會議發起人澄清須要我出席的緣由。

若是你在會議開始前一個合理的時間給我會議材料，我會提早閱讀，並準備好個人問題。若是我沒有提早看會議材料，我會如實告訴你。

若是在計劃時間點以前完成預期目標，我建議提早結束會議，把時間還給你們。若是很明確沒法在規定的時間完成預期目標，我建議在規定時間以前中止會議，肯定一個時間來討論未完成的議題。

我的癖好與改進

我是一個內向的人，因此我很是社恐。對於處於我這種位置的人來講還挺奇怪的吧，在我看來三我的的會是完美的，三到八我的也還不錯，可是八個以上的會你就會發現我表現得出奇的安靜。可是也別由於我安靜就認爲我沒上心。

當 1:1 話題都聊完了但還有些剩餘時間的時候，我老是喜歡把我最近碰到的一些有趣的問題拿出來頭腦風暴一下，雖然有些問題聽上去光怪陸離地彷佛跟如今的工做毫無關係，但這些的確都是個人一些想法，並可能會在將來有所實現。

當我給出的需求不太明確時，你應該讓我澄清事情的重要性並給出更詳細的說明。由於我可能還處在頭腦風暴階段，你的提問能夠爲雙方都節省大量時間。

關於和個人對話方式我也想稍微提一下。當你須要讓我作某事時，最好是經過詢問的方式，我能夠很是好地回答這類問題（好比：「Rand，你能幫忙下嗎？」）。可是我對命令式的話語會炸毛（好比：「Rand，把這個作下。」）。我從小就這樣，可能我須要看看心理醫生。

我有時也表現得很誇張，但基本都是由於我對這個話題感到興奮。我有時也說髒話，抱歉。

我喜歡新事物，但當我可以完整預見到事情將來的進展時，我可能會失去興趣。抱歉，我在這方面會愈來愈好。

若是我在會議期間使用手機超過 30 秒，請作些什麼來提醒我，由於我可能開始開小差了。

我討厭人們將觀點陳述爲事實。

我也討厭處處八卦的人。

最後

這份 README 是會實時更新的。目前可能不完整， 我會常常更新它，很是感謝你的反饋。

CODING 助力開發者輕鬆管理研發團隊。