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

前言：
本文爲 CODING 教你一步步從一個程序員變身成管理者系列文章的第三篇，文章內容來自 Unity 的一位研發總監，詳細敘述了他的管理風格和處事態度，同時列舉了不少擴展閱讀材料來幫助讀者更全面、更深刻地瞭解不一樣的管理風格，解決職位轉變帶來的困惑。

系列文章地址：

《CODING 告訴你硅谷項目經理的項目管理之道
https://segmentfault.com/a/11...

《CODING 告訴你硅谷項目經理的項目管理之道（2）》
https://segmentfault.com/a/11...

原文地址：https://github.com/angrywease...
原文做者：Alan，現任 Unity 研發主管

正文

對於在我手下工做的人來講，請把這份材料看成一份如何與我互動的說明手冊。其實在差很少一個月的相處時間後，你都能或多或少地摸清楚門道，可是考慮到你剛剛加入到 Unity 這個你們庭，會有超多的事情須要學習和關注（遙想當年我剛剛加入的時候，一把辛酸淚），所以我整理了這份文檔，但願能幫你快速入門，瞭解咱們作事的風格。

對了，即便你已經在公司工做一段時間了，但對我還不是很瞭解，也歡迎仔細看看，對你們都好。

1 on 1 Meetings

我認爲在組內保持信息通暢是很是重要的。每一個組員應該每週與我預定一次約 30 分鐘的 1 對 1 會議，建議提早選好時間（根據你的時區來），這樣能夠避免給其餘會議或者工做帶來衝突。

即便在我出差的時候，我也會按照預約的時間跟你聊聊，但若是咱們之間的時區相差太遠致使沒辦法如約進行，咱們也能夠找個其餘時間經過 slack 或者視頻的形式進行。由於做爲一個管理人員，我須要瞭解並知足你的需求。個人工做中最重要的部分就是要助你成功，讓你在 Unity 的時光有所收穫，因此請善用這一點。

你，做爲領導者

我作的管理人員的工做是去培養更多具備領導力的人。不管是在管理團隊，仍是在解決客戶問題，你都應該經過自身的領導力來推進團隊作出改變，選用更好的工做，採用更高效的流程等等。在推進團隊改進研發效率的這個過程當中，你會提升領導力並逐步改變對自身的定位。

我會盡全力幫助你成爲更好的領導者，在咱們每週的 1 on 1 中，咱們也會常常討論領導力相關的話題。我但願你能帶着問題來，把你最近在領導力方面的挑戰拿出來，我會盡我所能地幫助你克服這些挑戰。

只有極少數狀況下我會用個人頭銜來壓人，我主要仍是以給你提供建議和解決你遇到的問題爲主，從產品質量角度來講，我絕對信任你和你的團隊。

個人管理準則

我在讀質量控制方面的書的同時也看了大量的管理學和領導力方面的書籍。總的來講，一部分觀點仍是很不錯的，另一些觀點我以爲不行，不過我如今已經有能力能取其糟糠去其糟粕，並逐步開始造成我本身的管理哲學。我也不清楚究竟是這些書中的理論在指導我，仍是由於我本身的觀點獲得了書中的確定從而帶來了自信。

長話短說，有 4 個觀點能比較完整的歸納個人管理準則。

1. 咱們以前是同盟關係

咱們之間的關係不僅僅只是管理和被管理這麼簡單，咱們的關係應該是互惠互利的同盟關係，並且目標一致，爲對方創造價值和幫助對方成功。在你的工做爲 Unity 創造更多價值的同時，我會幫助你在職業規劃上和技能提高上帶來更好的發展。

若是你想更深刻的瞭解這種同盟關係，能夠看看 http://www.theallianceframewo...， LinkedIn 的創始人 Reid Hoffman 創立了這種新的管理人員/員工的關係框架，我認爲其中有不少值得借鑑的價值觀。

2. 指導和獨立性

不管你是就坐在我身邊仍是 1000 千米之外的辦公室，你的成功都依賴於你獨立解決問題的能力和主觀能動性。我做爲管理人員的工做僅僅是給你提供必要的框架內容（好比目標和角色之類的），而後我就會從你的眼前消失。在 Unity 工做的你們應該都能很好的跟人共事和解決問題，我只會在須要提供一點方向性指導，或者你有什麼須要我幫忙解決的時候出現。固然，有些時候我也可能會插手一些具體事務，這並不表明你作錯了什麼，僅僅是我以爲我看到了一些新的機會，這麼作可能會幫助到你。

One Minute Manager (https://en.wikipedia.org/wiki... 囊括了不少相關的內容。

3. 我的提高是最重要的

我會使用兩種理論模型來輔助組員的我的成長。第一個模型是是 Max Landsberg 模型（出自 Managing Humans：http://managinghumans.com/)。這個模型將工做的難度和員工對這份工做的接受度做爲兩個象限搭建一個四象限圖。每一項工做都能歸結到某一個象限上。個人目標是讓你儘量作一些最想作同時難度要求又比較高的工做，這樣你就能在爲 Unity 提供最大價值的同時得到很高的我的成長。

另一個模型跟這個也很相似，我稱之爲 ACM（Ambitious, Comfortable, Mundane）模型，這個模型關注的重點在於工做的分配問題。每次你完成了一週的工做或者一次敏捷衝刺，能夠停下來分析一下哪些工做是比較具備挑戰性的（Ambitious）、哪些工做是作起來比較順手的，慣例性的工做（Comfortable）、哪些工做可能比較無聊且對於你來講過於簡單（Mundane）。

咱們須要常常溝通，確保有足夠多具備挑戰性的工做來確保我的成長，若是有時候你以爲工做上失去了挑戰，就應該來跟我溝通，根據具體狀況調整你的工做內容。同時咱們也但願能儘可能減小對於你來講簡單的工做，術業有專攻，有些時候對於你來講比較簡單的工做可能對其餘人來講還挺具備挑戰性的。

一個簡單的實踐方式就是把一個週期內的工做都羅列一遍，而後將每項工做分級。理想狀態下，這個單子上應該有適量的具備挑戰性的工做，讓你保持不斷學習的同時也不至於被搞的焦頭爛額，還應該沒有或者有一點兒無聊的工做，而後剩餘的工做爲常規性工做來保持平衡。若是你以爲平衡被打破了，就應該找我來討論一下，經過發現新的工做、改變現有工做內容的形式來恢復平衡。

4. 有效的反饋是關鍵

關於反饋，除了 Unity 自身的反饋規則外，我還會使用 Radical Candor (https://radicalcandor.com) 中提到的模型。

我會很頻繁的給你關於工做和影響力方面的反饋。根據個人經驗越及時的反饋價值越高。因此我會盡可能在本週的 1 on 1 會議中及時給出反饋。咱們會常常性地進行 3Q （https://3qcheckin.com/why-3q）方面的對話來確保及時的反饋。固然若是事情特別緊急我會直接跟你說，而不是等到 1 on 1 的時候。

固然，我也很歡迎關於個人反饋，我也但願經過錯誤來學習和成長。

譯後記

從技術人員到團隊管理者的轉型所帶來的不只僅是身份上的變化，更多的是思惟方式和處事態度的轉變。Alan 做爲一個資深的技術總監，在他的分享中不單是本身的管理哲學和管理方式，同時也指明瞭一條通往管理者的道路，好比他提到的要從初期開始就進行領導力相關的培養、如何利用好身邊的資源等等都在幫助但願走上管理崗位的技術人員梳理脈絡。同時他還給出了大量的延伸閱讀材料，可供參考，能夠說是誠意十足。

另外值得注意的一點是，Alan 對工做分配的要求很高，要減小甚至消滅無心義的重複勞動，這就須要高效的工具來實現——CODING 就能很好地解決這些問題，經過自動化的研發流程，減小人力的重複勞動。 CODING 提供持續集成到自動部署的全過程工具：自動構建、自動化測試、構建物管理、部署交付。支撐項目的快速迭代，保證軟件穩定、持續構建和發佈。能夠無縫對接第三方運維管理工具，支持多種軟件交付過程，實現 DevOps 持續交付全流程應用。

CODING 助力開發者輕鬆成爲管理者。