寫給程式設計師的管理入門課程(轉)

轉自：http://36kr.com/p/5047953.html

編者按：本文首發於微信公眾號“iOS開發”（ID：iosDevTips），內容總結於《葛洛夫給經理人的第一課》，作者唐巧，授權36氪釋出。

前方高能提示：本文特別特別長。我總結本文花了將近一個月，如果你在經歷從技術到管理的轉型，那麼本文值得你仔細閱讀。我從本書中收穫巨大，希望你能從這篇總結中也有所收穫。

本書的作者葛洛夫是一個技術出身的管理者，在本書中，我們甚至看到他多次用編譯器來舉例，所以這本書非常適合有技術背景的讀者。

《葛洛夫給經理人的第一課》最早出版於 2007 年，書原名為《High Output Management》。本書的作者葛洛夫是 Intel 的前 CEO，領導了 Intel 從一家瀕臨倒閉的儲存器公司，轉型為微處理器公司，並且在個人 PC 開始流行時，成功和微軟締結 Wintel 聯盟，主宰了整個 PC 電腦時代。

本書主要分為四大部分：

• 第一部分「早餐店的生產線」：用早餐店的經營故事，來類比企業的經營管理，介紹了一些資料分析、產品預測、產品檢驗的辦法，提出了管理槓桿率以及關注於產出的管理原則。

• 第二部分「打好團體戰」：展開論述管理槓桿率，並且討論了開會、決策和規劃。

• 第三部分「推動組織的巧手」：從企業組織架構入手，談混合型組織，雙重報告，CUA 模型，以及文化價值觀。

• 第四部分「謀事在人」：講人員管理。涉及激勵、工作成熟度、績效評估、招人與留人、報酬與培訓。

第一部分：早餐店的生產線

本部分用早餐店的經營故事，來類比企業的經營管理。介紹了一些資料分析、產品預測、產品檢驗的辦法。

第一章：“生產” 包含什麼？

葛洛夫認為，一個早餐店的生產線，就包含了一個現代軟體開發管理中的各種問題。一個合格的早餐店的生產線，可以在預定的時間內，用最低的成本，做出顧客需要的產品。而現代軟體的開發流程，也是希望在一個預定的時間內，用最低的成本，開發出符合產品經理定義的、合格的應用或服務。

這個過程，涉及一些最基本的專案管理工作：找出限制步驟，然後優化流程，形成一個最佳的策略。

在經營早餐店的故事中，限制步驟可能是人員數量、一些機器的產能、或者庫存量。通過分析這些限制步驟的成本和收益，你就可以找出一個最價收益的方案。

軟體開發中的專案管理也是這樣，你的限制步驟可能是人員數量、開發時間、產品功能點、測試時間、或者技術實現方案。找到限制步驟後，通過優化限制步驟就可以優化整個流程。

第二章：從早餐店的庫存談起

葛洛夫認為，我們應該確定和監控早餐店的核心指標，對於一個早餐店來說，核心指標包括：銷售預測、原料庫存、裝置狀況、人員情況、品牌評價（使用者反饋），並且每天檢視這些指標。

另外，作者提到，指標應該有相互的限制，這樣避免過度反應。就像軟體開發中的軟體質量與開發時間一樣，不能只追求質量而不管開發時間，也不能只追求時間還不管質量。

其實作者在這章強調的就是資料分析的重要性，在資料分析上，作者介紹了一些方法，包括：

• 先行指標，用於揭示未來資訊的指標，例如 NPS，機器故障記錄。

• 線性指標，用於分析進度的指標。

• 趨勢指標，用於分析變化趨勢的指標。

• 重影印證表，用於修正預測行為，提高預測準備性的指標。

作者接著提到了計劃生產。這個事情是預期未來的銷售額而提前生產（放到庫存）的一種行為。這裡面合理地預測未來是核心，否則要麼就會造成沒有商品可賣，要麼就會造成庫存過高。剛剛提到的「重影印證表」可以比較好地幫助我們做預測的調整。

作者接著提到了檢驗質量。檢驗質量應該在生產的每個環節都做，但是越早的環節，檢驗的成本越低。就像我們修復程式的 Bug 這件事情一樣，如果我們剛剛寫完程式碼就收到相應的 Bug 報告，那麼修復的成本會小很多。但如果我們寫完過了一週才收到 Bug 報告，那麼我們就需要花精力先回顧當時的邏輯，才能進一步找到有問題的程式碼。

作者提到了一些檢驗質量的辦法，用於節省檢驗本身的精力成本。

第一種檢驗辦法是：海關與監視器。海關簡單來說就是所有的東西都必須檢查，監視器簡單來說就是抽樣檢查。根據具體產品出問題的概率，以及出問題的危害程度，我們可以結合海關的檢驗方法和監視器的檢驗方法。

第二種檢驗辦法是：隨機檢驗。隨機檢驗的量應該隨著檢驗結果的好壞有所調整，使得檢驗有針對性。

本章的最後，作者提出了管理槓桿率的概念，並且用下面的漫畫來做了解釋。作者認為，通過定義管理的「產出」，我們可以專注於那些提高產出的管理活動，那些高投入產出比的管理活動被作者稱作「管理槓桿率」高，進而應該被優先安排和執行。

第二部分：打好團體戰

本部分介紹了管理的一些經驗技巧，涉及管理槓桿率、開會、決策和規劃。

第三章：管理槓桿率

作者首先在本章定義了經理人的產出：

經理人的產出 = 他直接管轄部門的產出 + 他間接影響所及部門的產出

葛洛夫介紹了他一天的工作，能夠看出來工作內容非常雜亂，也非常多，而且做不完。他說：

我的一天通常結束在我覺得累而決定回家休息的時候，而不是事情做完了。

像家庭主婦一樣，經理人永遠有忙不完的事情。

因為事情永遠做不完，所以我們更需要關注於工作的產出，把最高優先順序的事情找出來優先安排和執行。

1、管理工作的分類

我們從葛洛夫一天工作的介紹中，能看出來他的工作分為幾類：

• 資訊收集類。看郵件、看報告、開會、和同事聊天、看使用者反饋、看產品資料、試用公司產品等。

• 傳遞資訊。培訓或者分享觀點。

• 決策。通過、制定或者否決一些方案。

• 給予提示。傳遞一些觀點。

• 為人表率。提供行為示範。

在資訊收集方面，作者鼓勵在使用傳統的郵件和口頭直接溝通外，多增加一些非正式的溝通機會。比如多隨意在公司裡走走，找不同的人聊聊天等等。

在決策方面。作者認為決策分為兩類：「未雨綢繆型」和「亡羊補牢型」，前者是在規劃未來，後者是在補救當前問題。

關於給予提示，作者認為他與決策的差別在於，給予提示很多時候並沒有明確的方案，他是希望讓對方通過提示來做一些調整，而調整的具體的細節需要對方自己思考。

除了以上四類（資訊收集、資訊傳遞、決策、給予提示）工作，作者也提到，管理者的所有行為，同時也在以「榜樣」的作用被員工效仿。例如管理者隨意遲到，員工就會隨意遲到。管理者做事情認真，員工也會有認真工作的壓力。

2、管理槓桿率

在介紹完管理工作的分類後，葛洛夫給大家介紹了他的管理槓桿率公式：

經理人的產出
= 組織產出的總和
= 槓桿率 A 管理活動 A + 槓桿率 B 管理活動 B ……

與管理槓桿率相關的因素有很多，包括時效：一個員工有離職情緒時，及時溝通的時效就很重要。一個重要會議要開時，提前準備內容的時效就很重要。

另外，葛洛夫指出，也有很多管理活動的槓桿率是負的，例如：經理人情緒低下，影響員工士氣。經理人越權干涉別人的工作，影響別人積極主動性。經理人做出錯誤決策，浪費人力物力。

葛洛夫指出，高槓杆率的事情包括：

• 當一個經理人可以同時影響多個人的事情

• 當經理人一個簡單動作或簡短談話，會對別人產生長遠影響的時候

• 當經理人的技術、知識或資訊，對一群人造成影響的時候

作者也列出了一些具體的高槓杆率的事情：

• 關注使用者的反饋，特別是抱怨。

• 績效評估。

• 傳授知識、技能或價值觀給部署。

• 授權。

3、授權

關於授權，作者做了展開的介紹：

沒有完備監督計劃的授權等於瀆職。你絕對不能完全地抽身，即使你已經授權，你還是得負成敗責任。
全程監督整個被授權的案子是確保結果盡如人意的唯一方法。監督不是干涉，而是通過不時的檢查，來確定活動的進行一如預期。
因為監督你熟悉的工作比較容易，所以如果有機會，你應該把自己熟悉的工作授權給他人。但切記先前舉的例子—理智叫你鬆手，但情感上你可能老大不願意。

監督的辦法可以用上一部分提到的檢驗產品質量的原則：越早檢驗成本越小。例如對開發工作不熟悉的員工，讓他們在寫程式碼前就先給你講講他打算如何規劃，就比讓他寫完你再檢查要好得多。

監督的另外一個技巧也是檢驗產品質量的原則提到的：注意檢驗的頻率。對於新人，要增加頻率。對於信任的人，可以降低頻率。另外，監督的方法要具有多樣性，對不同的人採用不同的方法。

監督並不是說經理人一定需要替員工考慮好事情的方方面面，因為這畢竟需要付出大量的精力。對於某些事情，經理人只需要提出一些細節問題來測試員工的思考是否全面，則可以一定程度上評估出事情的靠譜程度。對於經理人不熟悉的領域，也可以用此辦法。

關於這方面的知識，我在指導 iOS 開發新人的時候體會很深。通常指導新人的常用辦法，就是將自己熟悉的工作交給新人完成。因為這些工作非常好通過監督（Code Review + 定期討論）來保證質量，所以風險可控，而我自己也會從中學習到指導別人的各種技巧和經驗。

最重要地，我需要打破我的舒適區，因為我需要放棄自己非常熟悉的工作內容，轉而做一些新的陌生的事情。而新人的程式碼質量和編寫速度往往是比我自己直接寫要慢得多的，我需要有耐心地等待他們犯錯，然後通過 Code Review 和討論來讓他們學習到相應的程式設計知識。

學會指導新人通常是一個有經驗的程式設計師轉向更高職位的第一個挑戰，不管是他是轉向偏管理的崗位還是繼續在技術崗位上深挖，都需要先將手中的工作交出去，才能夠承擔更重要，更有挑戰的事情。

提高效率

作者提出了一些提高效率的辦法：

• 找出限制步驟：重要的、緊急的事情優先安排。這樣的情況下有空餘，再安排別的事情。

• 類似的工作放在一起做。例如將郵件處理，QQ 資訊回覆的事情稍做積累再統一回復。

• 安排好日程表。對一些事情說不，對日程表的事情留上 Buffer。

• 建立指標。儘量估計自己在每件事情上的花費，儘管這件事情很難，也可能不太準，但是總是會有所幫助，而且有經驗了之後，估計時間會越來越準。

• 存貨法。留一些重要不緊急的事情，使自己不太忙的時候，可以做這些事。比如對於我來說，學習產品知識，試用各種 App 的功能，分析各種 UI 設計就是一個「存貨」。

• 標準化。對一些經常做的事情，制定標準化的流程就可以提高效率。這就類似我們制定的產品評審流程，上線流程一樣。標準化了之後，就不用每次想應該怎麼做了，按步就班地開展即可。

老被人打斷怎麼辦？作者認為「躲起來讓人找不出」或者「叫別人不要在某些時段打擾」的辦法都不太好，他介紹了很多有用的辦法，包括：

• 標準化。把一些常見的問題歸類總結。如果一類問題有歸類總結了，也就意味著它能夠被授權給員工來處理了，也很容易被進一步用於員工指導別人。

• 類似的工作放在一起做。每天固定時間處理員工的問題，或者固定在一對一溝通中處理相關問題。

• 運用指標。有指標就可以改進流程。看看自己花費在解決臨時問題上的時間以及常見問題，然後就可以看看能夠優化這些時間。

第四章：管理必經之路：開會

葛洛夫將會議分為兩類：過程導向會議和任務導向會議。

• 過程導向會議：關於知識技能和資訊交流，通常是例行的。

• 任務導向會議：會產生決策的，通常不是例行的。

1、過程導向會議

過程導向會議又可分為以下三類：一對一會議、部門會議，以及運營總結會議。過程導向會議要儘量規律化。

關於一對一會議，我之前專門寫過文章：《淺析一對一溝通》。（參考見文末）

關於部門會議，作者的經驗是經理人要注意大家討論的主題和效率，事先討論的主題需要明確，最好大家在開會前能做好準備。經理人要儘量讓討論是自由的，避免成為自己主宰的「一言堂」。部門會議的議題應該儘量讓部屬來負責，經理人的責任只是保證討論不要偏題即可。

運營總結會議是讓那些通常沒有機會開部門會議的同事提供互動的機會，讓他們有機會彼此學習及分享經驗。

2、任務導向會議

過程導向的會議一般有固定的開會時間和頻率，其效果也多是交流資訊為主。而任務導向會議一般沒有固定的開會時間和頻率，會議結束後一般也需要產出一份會議的討論結果用於後續執行。

這種需要決策的會議通常需要控制人數，如果超過 8 個人，很可能比較難以推動達成意見的一致。

3、網際網路公司實際的情況

就我的感受，網際網路公司其實為了追求效率，還是希望儘量少開會，我參與的會議主要分幾類：

• Scrum 相關的會議：包括計劃會議、每日站會、評審會議和回顧會議。我們的技術和產品工作都用 Scrum 的方式來管理。

• 過稿會議：產品的過稿會議，UI 稿的過稿會議。

• 一些臨時性的，需要討論的會議，類似葛洛夫提到的任務導向會議。

如果把一對一溝通算作會議，那麼這也是我常參與的。但是因為一對一溝通的場地經常是在非辦公室的區域，所以我其實不覺得這是一種會議。

第五章 不揮舞權杖的決策

由於在網際網路公司，科技類知識更新速度非常快，而相對於一線的技術人員，管理者並不能擁有更多決策所需要的專業知識，因此我們需要將具體的決策，下放到一線的員工手中。

葛洛夫在書中描述了一種理想的決策方式：

• 先是充分地討論和表達意見

• 然後是在意見充分被表達之後的決策

• 最後是一旦最後決策產生，那些少數不同意的同事，都應該在之後執行過程中全力支援。

第六章 規劃是為了明天

在你規劃行動方案之前，一定記得先問自己：有什麼事情我如果 “今天” 做了，可以讓 “明天” 更好，或者至少讓 “明天” 不會更糟。

在本章，葛洛夫首先介紹了 Intel 在流程規劃上的一些方法，但是個人感覺比較偏製造業，因為講的都是處理原材料，庫存與訂單之單的矛盾。

接著，葛洛夫介紹了目標管理，包括需要做到：1、有明確的目標。2、有向目標前進的具體方案。

當你將計劃落實為白紙黑字時，看起來最抽象籠統的總結即為你的戰略，而你用來實行戰略的行動即為戰術。

對於這章，我自己倒是有一些總結。就我在網際網路公司的經驗來說，我們做規劃和目標管理主要是分為以下幾類：產品規劃、開發規劃、運營規劃、人員規劃。

1、產品的規劃

我們通常需要計劃出未來至少 3 個版本的產品迭代計劃。然後，對於這些產品計劃，安排相應的產品 PRD 稿的撰寫和評審、UI 稿的製作和評審、技術評審、開發測試及最後的上線。

2、開發的規劃

開發的規劃主要是通過 Scrum，將產品和美術稿已經 Ready 的待做事項以 backlogs 的方式放在 Scrum 的管理中。然後在每一個迭代衝刺（Sprint）中，我們從 backlog 裡面選取部分工作到當個 Sprint 中。

每一個 Sprint 是包括完整的開發和測試工作，伺服器端通常在 Sprint 快結束時，就需要完成上線操作。客戶端由於版本釋出過於頻繁對於使用者也有一些打擾，所以我們通常兩週對外發布一次版本。

3、運營的規劃

大型的運營活動如果需要產品和開發的介入，就也需要相應的規劃。通常情況下，我們認為提前一個半月開始是相對充裕的方式。運營花大概兩週做活動的策劃，剩下的一個月用於技術的排期。

4、人員的規劃

作為團隊管理者，我們還需要在人員上做相應的規劃。這包括：

• 人員的招聘。預估未來業務增長對於人力的需求，以便提前做好相應的招聘工作。

• 人員的培養。新人的培養、重要崗位人員的培養。

• 人員的激勵或開除。對一些表現優秀的人員，給予更多的關注和溝通。對一些表現不佳的人員，除了需要明確地指出他們的問題外，也需要根據改進情況選擇後續的處理方案。

第三部分：推動組織的巧手

本部分介紹一些實踐經驗，作者從早餐店的發展作為故事，引出企業管理中涉及的混合型組織架構，從這種架構帶來的問題出發，提出了雙重報告這種解決方案，由從雙重報告需要的企業文化出發，介紹了影響人們行為的 CUA 模型，最後得出高 CUA 因素的工作，需要員工用文化價值觀來指導行為。

比較可惜的是，對於如何增強大家的文化價值觀，葛洛夫並沒有展開討論，只是說領導應該以身作則。

第七章 當早餐店開始繁衍

在實務中，這種有關管理上集權及分權的分歧到處可見，幾已成為今日管理上最重要的課題之一。

本章只講了一個故事，當早餐店做得越來越好時，分店越來越多，帶來的管理上的複雜度也越來越大。不管是採購，還是人事，還是資產，我們都需要專門僱傭人員來負責。

但是除了這個故事外，本章並沒有涉及任何解決方案的內容。

第八章 混血型組織

斯隆總結他在通用汽車數十年的經驗時說：好的經營管理，是中央集權和地方分權間的折中產品。

本章討論了兩種組織形式：「任務導向組織」和「功能導向組織」。

任務導向組織是以具體的完成某件事情為目標而形成的組織。功能導向組織是以完成某個細分功能而形成的組織。這兩種組織各有優缺點，很多時候需要以混合的形式存在於一家公司，而具體如何混合，在不同的公司差異相當大。

拿網際網路公司來舉例，我所在的猿題庫是更偏向「任務導向組織」的公司，我們公司旗下有三款產品：猿輔導、猿題庫、小猿搜題。這三個產品下面，各種有著完整並且獨立的運營、產品、開發、測試、UI 團隊。而我之前工作的網易有道，就是一家更偏向「功能導向組織」的網際網路公司，因為在網易有道，有著全公司統一的測試團隊、UI 團隊。還有一些公司，他們甚至將全公司的移動端開發都集中成一個移動開發團隊。

兩種組織方式各有優缺點，我們來看看作者葛洛夫的分析。

1、功能導向組織

「功能導向組織」的部門更像是內部的分包商，相比外部的外包商，內部的分包商因為同屬於一家公司，所以提供的服務會更好，而且還有：

• 規模經濟。以運維為例，全公司統一的運維部門，有利於在公司內部建一統一的運維規範和運維繫統，節省運維成本。

• 根據需求，轉移或分配企業資源。以測試為例，全公司統一的測試團隊，在某些產品有更多臨時測試需求時，更好地調配人員。

• 共享知識。全公司統一的測試團隊、UI 團隊有利於他們更加方便地交流相關的專業技術，測試團隊可能在測試流程上更加優化，UI 團隊可能在全公司範圍內統一 UI 設計規範和準則。

但是，「功能導向組織」的缺點也很明顯，包括：

• 不同部門之間會爭搶「功能導向組織」的資源。比如測試團隊如果是公共的話，每個部門都會為自己的產品爭取儘量多的測試資源，但是誰能夠證明自己的優先順序肯定比別人的高呢？所以這其中會產生更多的溝通和決策成本。

• 責任心減弱。這一條並不是葛洛夫總結的，而是我自己感受到的。拿移動開發團隊舉例，如果移動開發團隊是「功能導向組織」，那麼某個移動開發者對於一個臨時的開發工作很可能並不能做到付出 100% 的全力，因為他很可能只在這個專案做兩個月。那麼他很可能著眼於「把當前的工作做完」，而不是「整個產品本身的利益」來考慮問題。

舉一個具體的例子，當一個產品設計對一種特殊情況考慮不完整時，一個「功能導向組織」的開發者很可能基於按時「把當前的工作做完」這個目標，而選擇忽視這些未定義的產品細節，按照「怎麼方便就怎麼開發」的方式來做，因為產品沒定義清楚本來是產品的責任，與他無關。如果他找產品討論這些細節，很可能使得實現方案變得更加複雜，對於他「把當前的工作做完」這個目標產生衝突。

但是，如果是一個「任務導向組織」的開發者，因為他會長久地負責這個專案的開發，這個專案的好壞最終會決定大家的績效，他當前沒有處理好這個產品細節，以後很可能也會是他來再次重構相應的程式碼。那麼他就有更大的可能去和產品溝通和協調，確定這些未定義的產品細節。

2、任務導向組織

「任務導向組織」的優點是什麼呢？優點是需求更加明確，決策更加靈活，人員也更加有凝聚力。

「任務導向組織」也有缺點，主要是這種方式會使得大家在共享專業知識上更加困難。對此，我們公司增加了很多全公司範圍內的技術分享會，通過這些分享活動，我們希望增加大家在技術上的交流。

那麼，猿題庫公司的具體混合型組織是什麼樣的呢？我們的「功能導向組織」僅包括：運維團隊、演算法研究團隊、資料分析團隊、財務和行政團隊。而我們將產品、運營、測試、客戶端開發、Web 前端開發、UI 設計人員都分拆放到了「任務導向組織」中，而我們按產品將「任務導向組織」分為了三個：猿輔導團隊、猿題庫團隊、小猿搜題團隊。

第九章 雙重報告

葛洛夫在本章中，推薦用雙重報告來解決混合型組織的管理問題。混合型組織中，一個人如果在一個「任務導向組織」，那麼他很可能在專業技能上無法得到 Leader 的指導，葛洛夫希望通過讓這個人在專業技能上報告給一個專業技能上的 Leader，使得這個人在專業技能上有所成長。

但是，葛洛夫也提到，這種雙重報告很多時候是模糊不清的，「含混是解決問題之道」。所謂的含混，就是指專業技能的 Leader 在實際上並沒有明確的權力。有些時候，雙重報告的存在形式是一些「同級群體」或「同級委員會」，這些群體可能由於一些專業問題自發地形成，但是自主地決策解決一些 Leader 無法解決的問題。

我自己就親自經過多次「同級群體」決策。例如，蘋果規定 2016 年 6 月 1 日之後的應用必須支援 IPv6，這意味著我們可能需要升級全公司共用的網路庫，於是我就在群裡面發起了這個問題的討論，一些人（主要是相關產品的 iOS 負責人）自發地參與了這個討論，然後大家討論出了一些方案和結論。

這種「同級群體」決策的成功，更大程度上不是某個規則的作用，因為我們很難明確出哪些事情需要跨部門討論，也很難明確出這些討論的負責人。所以，我們只能用一些企業文化或者做事方式影響大家。

所以，我感覺葛洛夫在本章其實並不是強調雙重報告，而是強調在「任務導向組織」中，還應該有一隻看不見的手，讓大家在織織之間，產生協同、討論和決策。

葛洛夫在本章中沒有描述清楚這隻看不見的手，他只把它稱作「企業文化」，而這正是他在下一章將要展開闡述的內容。

第十章 每個人都聽命於三個 “長官”

葛洛夫通過一個故事（故事中涉及買輪胎、遵守交通規則、主動幫助車禍的人）來說明一個人的行為，受三方面的影響：

• 自由市場因素：大家簡單地以自己的利益作為行為指導，例如挑選商品時大多隻會考慮價格和質量。

• 契約義務：通過事先達成的一致，然後履行契約義務。例如我們上班，就是和公司的一種契約義務。

• 文化價值觀：一種為了組織利益，犧牲自我短期利益的行為，通常這種行為長遠來看對個人也是有利的。

葛洛夫引入了 CUA 指標來幫助我們選擇用以上哪方面的因素來指導人們的行為。CUA 分別指：工作環境的複雜性（Complexity）、不確定性（Uncertainty）、指令的模糊度（Ambiguity）。

程式設計師的工作就充滿了複雜性，因為程式設計師需要不斷地學習新知識，程式碼的邏輯和架構也可能很複雜。而市場的工作充滿了不確定性，很多時候上司也無法幫你想出有新意的市場推廣方案。

葛洛夫認為，如果一個工作的  CUA 因素高，而個人關注的是團體利益，那麼就只能用文化價值觀來作為行為的指導。但是如果個人關注的是自身利益，那麼就會如下圖顯示的那樣，情況變得「一籌莫展」。

葛洛夫舉了一個例子，當海灘上發生災難時，每個人都只顧及保全自己的性命，而救援工作需要極高的 CUA 因素，所以現場只會是一片混亂。

按這個理論思考，我們就能理解為什麼要做火災演習了，多次火災演習可以極大地減少火災發生的 CUA 因素，因為大家在演習中對於火災已經有著明確的處理方案了，需要做的只是按之前演習中的契約行動就行了。

葛洛夫認為該理論對於指導新人也有意義：

讓我們把這套理論套用在某個剛進公司的新人身上。由於初來乍到，他無疑比較關心自身的利益。因此，你應該給他明確的工作架構，降低複雜性及不確定性。

另外，該理論對於空降的高管也有意義：

對於空降的高管來說，就像起用任何新人一樣，一開始他還是比較關心自身利益。但身為高階經理，他難免會被指派管理一個有問題的部門—畢竟這是我們從外面找人的原因。此時對這個經理人而言，他面臨的不僅是燙手山芋，還有環境裡很高的 CUA；同時，他也尚未建立起屬於這個企業的價值觀與行事準則。在此狀況下，大家只能求老天保佑他能趕緊忘卻私利，以大我為前提，並設法降低 CUA。如果他做不到這些，恐怕很快就會被撤掉。

文化價值觀也不是銀彈，在 CUA 因素低的時候，選擇用自由市場因素或契約義務，都比文化價值觀來得有效。所以，根據具體工作的 CUA 值，選擇具體的控制模式，是經理人需要關注的。

不過話說回來，我仔細想了想網際網路企業裡面的各種職位，不管是產品、技術、還是運營，似乎都是高 CUA 因素的職位，所以文化價值觀應該是網際網路公司管理員工的基本方式。

很可惜，葛洛夫在本章中並沒有詳細介紹如何增強大家的文化價值觀，他只是認為，管理者自己的行為示範，比把文化價值觀掛在口頭上有效。但是本書的第四部分，詳細討論了企業管理中人的問題。

第四部分：謀事在人

本部分涉及激勵、工作成熟度、績效評估、招人與留人、報酬與培訓。

第十一章 激勵部屬參加比賽

葛洛夫將員工的問題分為不能和不為兩類：

• 不能：能力不夠。

• 不為：能力夠，但是不夠努力。

針對這兩類問題，他提出了培訓和激勵兩種解決方案。在本章作者並沒有講培訓，主要詳細討論了激勵相關的問題。

作者認為，激勵應該和馬斯洛的需求金字塔理論相符。

在「歸屬感與認同感」這一層，我們應該讓同事們都喜歡當前的工作環境和同事關係，認同當前公司做的事情。同事之間的合作應該是愉快和融洽的，同事中還會有自己欣賞的牛人，有自己的好朋友可以一起吃飯、聊天。

只有產生了歸屬感與認同感，員工才會追求更高一層的「地位與尊重」。我們給那些表現優秀的員工更重要的事情，更高的職位，使得他能夠在這一層上產生明確的目標。很多公司都會做職業發展的內部評級，其實就是給大家一個明確的地位與尊重的目標，讓大家為此努力。

但是，「地位與尊重」的目標一旦達到，人們工作的動力又會下降。一些更牛的人，就會追求馬斯洛需墳金字塔的頂端：「自我實現」。「自我實現」這一層的需求的差異性在於：

一旦某個人受激勵的來源是自我實現，他工作的動力將不再受侷限。這是自我實現有別於其他激勵模式最重要的特點。其它的激勵來源一旦在需求滿足之後便不再生效，但是自我實現將不斷激勵個體向上突破。

有兩種自我實現的動力可以促使個體將能力發揮到極致：精益求精型和成就導向型。

精益求精型的例子是音樂家、運動員，也包括程式設計師。拿程式設計師來說，一個程式設計師如果不斷追求寫出更牛逼的程式碼，那麼他可以像阿里的多隆那樣，成為合夥人級別的重要人物。

成就導向型的人常常懷有達成任務的決心，對於困難，他們喜歡挑戰自我。其實做很多事情，剛開始都是需要面對失敗的。成就導向型可以坦然地面對失敗，然後再次挑戰目標。

對於較高需求層次的人，失敗的恐懼大多數是來自於內心而不是外界，如果不能克服自我內心的恐懼，那麼這個人就會從自我實現的層次往下降。

一般而言，在較高的需求層次時，恐懼通常源自內在而非外在的威脅。人們經常因為過不了自己那一關而導致行動上的退卻。但如果老是如此，這個人很快就會從自我實現的層次往下降落。

在具體實施激勵時，葛洛夫認為，一個好的激勵應該是目標明確的，並且這個目標應該是比較難以達到的，這樣大家才會全力以付，發揮出儘量大的潛力。

如果我們想要讓員工都能提升自我實現需求的層次，便必須先創造出一個講求產出的環境。

另外，可以合理使用一些競賽，讓大家把競技場上的爭勝的心態應用到工作中。

工作的概念天生就不如競技，我們乾脆將運動場上的競爭精神融入工作。最好的方法便是先制定遊戲規則，並讓員工有衡量他們表現的尺度。

關於競賽，我自己也有一些真實的感悟。我們公司很多人中午都會去游泳，之前大家都自己隨便遊，後來有一個同事說，我們分成兩組，搞接力賽吧。雖然這是一個沒有任何獎勵的比賽，但是大家因為比賽，就會不自覺得更加努力游泳，連續多日下來，大家的體力都上升了很多。

關於激勵，葛洛夫最後總結道：

經理人的角色在此便極為明顯：他應當是個教練，身為教練，首先必須不居功，團隊的成功來自於隊員對教練指導的信賴；其次，他的訓練必須嚴格。通過當一個鐵面教頭，他努力激發出隊員的潛能，並刺激團隊做出最佳表現。一個教練應該曾經是個好選手，因此他了解競賽的規則以及選手在練習及比賽時可能面臨的問題。

第十二章 工作成熟度

令人驚訝的是，即使較早建立起的管理理論多半靠直覺，後來的實證科學也並沒有辦法將它們推翻，或是證實某種管理風格確實較其他的更勝一籌。研究學者似乎必須下沒有所謂最佳管理風格的定論。

葛洛夫首先通過英特爾在輪換經理人上的故事，引出了用「工作成熟度」（Task Relevant Maturity，TRM）來評估個人或部門。

根據工作成熟度的不同，葛洛夫建議用不同的辦法來指導：

• 工作成熟度低時，指導應該是明確和具體的。包括做什麼事情，何時完成，如何著手等。

• 工作成熟度中時，指導應該從具體的事情，轉移到溝通、情緒上的支援與鼓勵。

• 工作成熟度高時，指導只需要關注努力方向是否正確上。

葛洛夫說，我們在指導小孩的時候，也是符合這套理論的。剛孩子還小的時候，我們只會說做什麼，不做什麼；等他們長大一些之後，我們變成一些叮囑和指導；等他們成人之後，我們基本上不再管教他們了。

指導的時候，我們應該注意建立共同的價值觀。我們在猿題庫也在這方面做了很多具體的嘗試，比如我們強調：按時釋出產品、程式碼質量、資訊儘量共享、指導新人比日常開發工作更重要。這些都是在努力建立共同的價值觀。

一旦員工瞭解了組織的營運價值觀，又具有較高的工作成熟度時，主管便可以開始分權，進而提高自身的管理槓桿率。

葛洛夫在本章中也討論了一個非常有意思的話題，管理者是否應該與員工建立友誼。他對此有兩個觀點：

1. 我們不應該把友誼相關的社交活動與工作上的指導混為一談。因為社交活動並不能直接在工作上產生幫助，當然，友誼對工作是有一些間接幫助的，因為它使得你們之間在溝通的時候會更加有效一些。

2. 命令朋友其實是一件不愉快的事情。當你需要批評或直接命令朋友時，友誼可能會是一個阻礙。葛洛夫舉了一個例子：當你需要給你的朋友打很低的績效時，你是否感覺到非常難受？

對此我個人的感受是，適當的友誼還是非常有必要的，對於一些同事，經過一段時間的合作，我們其實是能夠比較清楚地判斷出來他們的潛力。如果我們認為他們的潛力是足夠大的，在建立友誼的同時，在工作上也給予更多的指導，應該是一個更好的做法。

另外，建立共同的「就事論事」的價值觀也是非常有必要的。大家是朋友，但是工作上應該批評就批評，如果大家有著對事不對人的共同價值觀，批評就不是那麼不可接受了。

第十三章 再難也得做：績效評估

葛洛夫認為績效評估是一個高槓杆率的工作，可以使得優秀的員工得到激勵，從而更加努力。但是績效評估又是一個非常難的事情，因為很容易產生衝突和爭議。

績效評估大致可以分成兩部分：評估部屬的績效，以及將評估的結果告訴部屬。作者認為，一個有效的評估報告應該包括：優點（需要有例項證明），缺點（需要有例項證明），如果在未來提高績效。其實對於很多公司來說，績效評估都是含混過去的。我現在所在的公司也沒有詳細到葛洛夫描述的那樣的績效評估報告。

不過，葛洛夫介紹瞭如何向一個完全不合格的員工傳達績效評估，我感覺很有價值。葛洛夫用解決問題的階段來描述不合格員工的狀態。

這些階段具體解釋如下：

• 忽視：表現不佳的員工最初會忽視問題。所以你需要找到具體的證據，讓他無法抵賴。

• 否認：當員工開始否認問題時，事情其實已經有進展了，因為至少問題被提出來了。

• 責怪別人：責怪別人是一種很有效的防衛機制，因為員工可以以此為理由拒絕承擔責任。所以這一步是關鍵，如果讓他意識到不是別人的問題，那麼就很容易進入到擔起責任階段。責怪別人到擔起責任涉及的是克服心理障礙的問題，而從擔起責任到尋找解決方案是能力問題，後者要簡單得多。

• 擔起責任：承認問題。

• 找出對策：雙方一起找出問題的解決方案，並且實施。

葛洛夫把階段分得很多，其實我倒覺得關鍵的階段就是從否認責任到承擔責任的過程，這個過程中，經理人需要收集到足夠多的證據，儘量客觀地溝通，另外強調就事論事的工作態度，才可能幫助員工克服心理障礙。

另外，即使到了最後的「找出對策」階段，大家也可能無法達成一致，這個時候，葛洛夫建議不必在這階段強求一致，只要員工承諾按經理的方案實施即可。我們不應該強求說服別人，因為這更多是一種心理上的需求。

你當然希望看到部屬心悅誠服地同意你的看法，但如果他不是完全同意，只要他願意採取改進行動，你就不該再在這上面傷腦筋。不要混淆了情緒問題和工作的需要。為了完成任務，你最需要的是部屬願意施行你決定的行動方案，至於他是否與你抱持同樣的想法則是其次。期望別人凡事都和你想得一樣其實並不是件好事，在工作上我們主要追求的是績效，而並不是心裡舒不舒服。

我們在做績效評估時，也應該把重點放在那些重要的員工身上，他們已經非常優秀了，所以找出他們的問題將會相對困難，但是他們在未來很可能承擔更重要的工作，所以把心思花在他們身上是值得的。

葛洛夫在本章的最後建議，應該提前把評估報告發給員工閱讀，之後再組織討論，這樣會使得員工對評價有所思考，之後的討論更加有效率。

第十四章 招人與留人

關於招人，葛洛夫提到，僅僅靠一小時的面試，根本就不足以客觀地評價面試者的水平。對此我是非常同意的。但是企業的成本有限，確實也沒辦法花費更多時間來考查面試者了，所以這是一件非常難，但是又不得不做的事情。

關於如何招人，其實無非就是建立一套方法論，然後希望以「較大概率」招到滿意的員工。我聽過很多別的公司的方法論，大家的面試方法都差別很大，但是我覺得都是做到了剛剛說的原則。我自己長久以來針對程式設計師、產品經理、產品實習生面試分別都有總結，在此就不展開介紹書中的辦法了。

關於留人，書中提到最麻煩的就是重要的優秀員工想離開。對待想離職的優秀員工，第一步需要做到的是足夠的傾聽。

你應該馬上放下手上的事情，請他到辦公室坐下來談，問他為什麼要辭職。讓他暢所欲言，千萬不要和他起任何爭執。相信我，你的愛將已經在不止一個失眠的夜裡將這套詞兒演練過千百遍。等到他講完所有他要辭職的理由（沒有一個會是好理由），你再多問他一些問題。先讓他說個夠，因為當他講完了事先準備好的那一套詞兒後，真正的理由也許才會顯現。千萬不要爭辯，不要說教，也不要動氣。

傾聽之後，找到離職真正的原因，只能站在對方立場上考慮，如果是薪水問題，看看是否合理，該調整的話就調整。如果是工作內容，看看能否做一些公司內部的工作變動來幫助他找到更喜歡的工作。如果是當前公司的一些具體的問題，看看能不能做一些改進。但是，這些做法的前提都是：這是一個優秀的、重要的員工。如果是一個表現普通的員工提出的不合理要求，那麼傾聽之後可能也只能做一些形式上的挽留了，因為我們不能破壞公司的薪酬體系來挽留他。

第十五章 報酬的誘惑

大部分人的薪資都是結合他的工作表現+工作年限的綜合評價，這其實是建立員工穩定期望和公平的一個方案。在我們公司，有一些優秀的應屆生能夠比一些老員工貢獻更多的產出，但是我們確實無法一下子就給他老員工那樣的薪水，大部分的時候，我們會給他超出同樣工作年限的人的薪水。

以工作年限作為薪資的重要衡量手段，算不上特別公平，但是確實也沒有特別好的辦法。不過，當前網際網路公司已經有一些創業公司開始打破這樣的規則，他們給那些工作一兩年的優秀員工非常高的薪水，因為事實上，這些員工的產出和那些工作五六年的員工差別不大，但是從價效比上講，他們比那些工作五六年的員工要價少得多，所以多給一些也沒關係。

在網際網路公司搶人的時候，這種策略被大量的採用了。這造成了網際網路人才薪資水平的差異被進一步縮小，大部分人的年薪都集中在某一個很小的範圍區間。而那些工作多年的人，如果不能進一步提升自己的能力，就會陷入薪資基本停止不前的怪圈。

在本章，作者也提到，一般職務的提升都會面臨工作內容的巨大變化，很多人處理不好，反倒會表現得很差勁，這便是著名的“彼得原理”。

一名稱職的教授被提升為大學校長後無法勝任；一個優秀的運動員被提升為主管體育的官員，導致無所作為。對一個組織而言，一旦相當部分人員被推到其不稱職的級別，就會造成組織的人浮於事，效率低下，導致平庸者出人頭地，發展停滯。

但是，對此我們又有什麼辦法呢？我們不提拔優秀的員工，難道提拔糟糕的員工嗎？所以除了對提拔的員工悉心培養之外，也沒什麼好辦法。

如果一個員工實在對新工作不感興趣，作者建議還是讓他回到以前表現優秀的崗位上。雖然剛開始有一些難堪，但總比他主動離職要好得多。

第十六章 別等火燒眉毛才培訓

作者認為經理人應該是培訓的責任人，不應該把培訓交給外面的公司負責。因為經理人本身在公司內部具有權威性和可信度，他的培訓內容更容易被理解，另外，每個公司的做事方式和文化都不太一樣，自己參與培訓才能夠把正確的做事方式傳遞給大家。

設計培訓課程花費的精力相當大，我當前就在設計產品實習生的培訓課程，還好我之前有一些總結，否則第一次課可能都會耗費我大量時間。就算這樣，我也不知道培訓能否一直按計劃進行下去。不管怎麼樣，只要開始了，總歸是有產出的，而且我相信多做幾次之後，我就可以建立起優秀的、系統的培訓課程。

最後的問題列表

作者在最後留了一些很棒的問題，值得大家回答一翻。

如果你能從下列各項檢驗中拿到100分以上，以這本書的標準，你算是個傑出的經理人了。
1、試著將你工作中的操作分為編制流程、組裝及測試三個步驟。【10分】
2、針對你手頭開展的方案，找出限制步驟，並依此設計你的工作流程。【10分】
3、找出你工作中最適合進行驗貨、線上檢驗與最終檢驗的地方。決定這些檢驗應該採用“海關”還是“監視器”的方式。然後考慮在什麼時機下，你可以升格至“隨機檢驗”。【10分】
4、找出至少6項以上的新產出指標。這些指標應該要能衡量產出的質與量。【10分】
5、將這些新的指標變成工作上的例行事項，並在部門會議中定期審視。【20分】
6、你現在正尋找的最重要的戰略（行動計劃）是什麼？描述你面臨的環境需求以及計劃進度。如果計劃能成功地執行，是否能將你或你的公司帶到理想中的境界？【20分】
7、簡化你最煩瑣、最耗時的工作。至少讓原有的步驟減少30%。【10分】
8、找出什麼是你真正的產出？你所管理的部門及影響力所及的部門的產出元素為何？按重要順序排列。【10分】
9、實際在公司中走動走動。然後，列出這次“出巡”中和你有關的事項。【10分】
10、找一些藉口讓你一個月可以在公司內巡視一次。【10分】
11、描述下一次你授權給部屬時會如何督導。你將以什麼為標準？怎麼做？督導的頻率是怎樣的？【10分】
12、列出你可以利用零碎時間進行的專案。【10分】
13、列出和每一個部屬“一對一會議”的時間表。（在會議之前向他們解釋會議的目的，並要求他們作準備。）【20分】
14、找出你上星期的日程表，將做的活動分為高、中、低槓桿率三類。設法多做一些高槓杆率的活動。（有哪些活動該減少或乾脆不做？）【10分】
15、預測下週有哪些事要瓜分你的時間。有多少時間要花在開會上？其中有多少是過程導向會議？多少是任務導向會議？如果後者佔去的時間超過25%，你該如何設法刪減？【10分】
16、列出你的組織在未來三個月中最重要的三個目標，並一路驗收成果。【20分】
17、在與部屬充分討論過以上目標後，要他們也“依葫蘆畫瓢”—制定他們的目標並一路驗收。【20分】
18、寫出“懸而未決”需作決策的事項。找出其中三項，試著運用決策制定過程的架構以及“六點問題”的方法。【10分】
19、依據馬斯洛的需求理論評估你自己的需求層次。併為部屬找出他們所屬的層次。【10分】
20、給部屬勾畫他們的跑道，並找出每一個人的績效指標。【20分】
21、列出你給部屬各種形式的工作所給予的相關回饋。他們是否能借著這些回饋來測量自己的進度？【10分】
22、將你部屬的工作成熟度分為低、中、高三類。並針對個人選出最適當的管理風格。並在你的管理風格及最適當的管理風格之間作比較。【10分】
23、評估你上一次收到的或你對部屬所作的績效報告。這些報告對提高績效有多大的影響？在上司告訴你報告內容或你告訴部屬時，你們的溝通形式是怎樣的？【20分】
24、如果有哪一份報告不夠理想，重做。【10分】

寫在最後

我整理這份筆記花費了好幾周，我從本書中收穫巨大，希望你能從這篇總結中也有所收穫，祝大家玩得開心～