在開始講任何的細節之前，我想先談談為什麼要寫這樣的系列文章。眾所周知，從事專業工作的人士，無論掛著什麼樣的頭銜，就其日常工作 的根本性質而言，基本上可以分為兩大類，不妨就稱為技術人和管理人吧。不用說，他們分別從事著的當然就是技術工作和管理工作。有關這兩者的區別，說法很 多。但說到底，它們之間的根本區別在於技術工作的物件是物，而管理工作的物件是人。技術工作的成功標誌，是利用物性達成目標；而管理工作的成功標誌，則是 發揮出人的潛力。一方面，由於技術人不懂管理以及管理人不懂技術，是大量實際問題的根本來源，甚至也是企業和專案失敗的主要原因，因此為彼此開設專門講座 來普及一下，是件挺有意義的事。另一方面，無論是技術人還是管理人，看看站在不同視角闡發的觀點，也是件挺有意思的事。萬一哪天自己的角色有了變化，也好 先有點兒準備。那麼，就先從給技術人上的管理課開始講起。
管理的最大祕密
很多名字裡面帶有“管理”的工作實際上是技術工作，例如伺服器管理、資產管理等。還有很多人生生地把真正的管理工作，例如專案管理、運營管理等 做成了技術工作。雖然說技術工作沒有什麼不好，但把管理工作做成技術工作，意味著把作為管理物件的人看作是隻有一系列屬性差異，卻並無人性和生氣的物了。 大概沒有什麼人情願被這樣對待，因此以這樣的方式從事管理工作的人大抵會以失敗而告終。而技術人在日常工作中，也免不了時不時地要做些管理工作，要尤其避 免這種把人看作是物的傾向。管理，永遠意味著管理活生生的人。離開了這一點，就談不上什麼管理，無論是否將其冠以管理之名。
千軍可以奪帥也，匹夫不可奪志也。管理無常的人心，比起給個輸入就能大致知道有怎樣輸出的軟硬體系統，可控性差了何止千萬倍。這也是很多剛上任 的，甚至已經從事了很多年管理工作的朋友們始終感覺搞不清答案的一個問題：到底怎麼樣才能在人心這樣不可知的條件下，有效地實施管理？換個更通俗的說法， 為什麼有些人可以做到在一大群人中令行禁止，人們著了魔一般聽其指揮而動，締造出軟體帝國和傳世之作，而偏偏自己想組織幾個人乾點從技術角度看很簡單的 活，都搞不定呢？
前面說過，管理的成功，體現在發揮出人的潛力。這就使得我們思考：在怎麼樣的條件下，人能夠發揮出自己的潛力？如果說沒有管理他人的經驗，那就 反過來想想自己好了。在下面幾種情景下，你一般都能夠較好地發揮自己的潛力：異地的老闆突然說明天要大駕光臨，要求你安排好接待和工作彙報；上面下達通 知，一個月內網站訪問量若突破日均 10 萬 PV，你可以拿到五倍的季度獎；一場對你來說很重要的演講即將開始，你突然發現裝著 PPT 的U盤丟在計程車上，只能裸講。
以上這些情景有兩個共同特點：第一，迫於壓力、耽於獎金或礙於面子，你有了強烈的意願想達到某種目的；第二，你有機會發揮出自己的自由意志，或者說主觀能動性，來組織接待、優化網站，或是即興發揮。
反推回去，想一些非常簡單的成功說服他人按自己的意志行動，並且取得了甚至比預期更好效果的例子，是不是無一例外地也具有這兩個特點：對方出於某種原因，有了達成你想要目的的強烈意願，但他們在行動時卻是通過發揮自己的主觀能動性完成的。
再推而廣之，觀察執行比較成功的組織，即能夠發揮出組織中的個體潛力的，也無非就是每個個體都或多或少地帶有組織目的，並能夠較好地發揮主觀能動性的結果。
但這麼說來，似乎有哪裡不太對勁。在一般人的印象中，管理似乎帶有相當的強制性。既然是要管理某人，要達到的是管理者的目的，要體現的是管理者的意志，為何前面說的，好像達到了的是被管理者的目的，體現了的是被管理者的意志呢？
這並不難理解，因為每個人都是一個有著自我意志的平等個體。為著自己的目的而採取行動，而在行動過程中發揮的也必然是自己的主觀能動性。如果想 要脫離這個前提來實施管理，百分之百地達不到目的，即使被管理者被迫採取了一些行動，也只是做做樣子罷了。這個看似簡單的道理，其實卻包含了管理的最大祕 密：管理的終極目標就是不要管理。
涉及到較強專業性的技術管理是不是例外？完全不是。在最優秀的技術驅動型的組織裡，管理者幾乎都是把 100% 的時間用於服務、支援甚至取悅被管理者，讓他們為著自己的想法，盡情地發揮自己的天才。無價的技術產品幾乎都是在這樣的氛圍中誕生的，這包括C語言、 UNIX、Gmail 等等，這就是很好的證明。
控制之禪
雖然我們已經瞭解了管理的最大祕密，其實根本上是要靠被管理者的自覺，而不是管理者的主觀意志。可是，這樣的效果不是天然存在的，甚至也不是一 朝一夕能達成的。因為人的想法不可能完全一致，所以想指望他人能夠自然而然地讀懂自己想要什麼，不太可能。那怎麼辦呢？這就需要把自己想要的，傳達給對 方。
此即所謂的控制，雖然可以換個較為委婉的說法，但我還是更願意用這個術語。換句話說，管理中的控制就是要把目的溝通清楚、傳達到位，而並不是要控制人的思想和行動，因為後者是無論如何辦不到的。
在技術一線長年工作的人，往往在上手管理時，感覺莫大的困難。這裡面的問題就在於把握不好控制這個環節，具體來說，就是經常會把溝通和傳達的內容，從目的變成了手段。
例如，很多人喜歡通過直接閱讀全部原始碼的方式，對於寫程式碼的程式設計師實施控制。這樣做究竟好不好，值得商榷。但有一些客觀規律，卻是很難違反。 首先，一個人寫的程式碼，另一個人理解起來存在不小障礙；其次，一個人每天能夠生產和理解的程式碼的總量是有個上限的；再次，同樣一個功能，實現它的程式碼可能 存在多種思路，而優劣的判斷標準不僅失之主觀，更是極其複雜的。更重要的是，實現要求的功能，這是目的，而寫怎麼樣的程式碼來實現該功能，這是手段。很多技 術人做管理的方式，就是簡直是替人把工作做掉了。而這麼一來，非但被管理者不能因此而領會到底工作之目的何在，而且下一回還是無所適從。你可以把飯喂到別 人嘴裡，但是想讓人不要餓死的話，最好還是讓他感覺飢餓了自己學會怎麼吃飯。
這就是為什麼有時候，非技術出身又來管理技術人的，反而比科班出身的，效果還要更好些。因為他們不懂到底為了達到目的，可以採取什麼手段，這反 倒迫使他們把精力集中在把到底要達成什麼目的講得更清楚、更到位些。被管理者反而對於採取的手段有了自由空間，把主觀能動性發揮了出來。
非技術出身的人來做管理也有問題，但問題不一樣了。它變成了由於對於技術不夠理解，而不能夠很好地定義目的，甚至定義出很可笑的目的來。程式設計師 這個群體裡，用於調侃經理不懂技術而鬧出的笑話，那是夠多的了。所以管理技術人和技術工作的，如果原先技術不過關的，還是有必要補一補技術課，不過這些是 後話。
因此，控制這件事，看起來好像很容易，其實卻很難操作。不過，有一條原則卻是無論如何都成立的，那就是管理者自己要明確到底目的何在。如果是連自己都不清楚的工作，想把別人置於控制之下，那就幾乎完全不可能了。
只自己明確了目的還遠遠不夠，傳達到位才是實施控制的關鍵。如果站得太高或業務不熟，很容易造成傳達的偏差和背離，但如果管得事無鉅細，結果亦 適得其反。那究竟最到位的控制應該是怎樣的呢？一個可行的建議，也是幾乎百試百靈的建議是：在目的和手段的交界處，落下控制的閘門。比如，如果目的是實現 某個功能，而手段是寫程式碼，那麼控制的最好尺度就是把所要的功能描述得全面、準確，而把寫程式碼的充分自由交給接受這個任務的程式設計師；如果目的是大規模改進 系統的效能， 而手段是修改配置和伺服器引數以及新增資源，那麼控制的最好尺度就是把效能改進的指標以及是否達標的評判標準，以及採購預算描述得全面、準確，而把具體的 技術和採購任務交給對應的運維和採購部門工作人員去考慮和斟酌。當然，在必要的場合下，也不是絕對不能深入細節，特別是在需要示範和教育的階段，但如果對 於管理有著長期打算，就一定要在某個時間點完全地放手讓別人來做事。這就又得出了一個所謂的控制之禪：你什麼都想控制嗎？那就想方設法把你的目的傳達到位，然後徹底地放手吧。
計劃悖論
把目的傳達到位，其實對於一個有長期打算的組織來說，也就差不多夠了。因為這樣的管理必然會在某個時間達成效果，原因就是人一旦有了目的，那麼 發揮出主觀能動性的力量是非常可怕的，可以說這是宇宙間最大、最持久，也是唯一可靠的力量。然而，絕大多數的實際情況中，管理者面臨的挑戰不僅有要做什麼 的問題，還有什麼時候要做完的問題。後一個問題，就不能僅靠控制，還要靠計劃。
計劃是一種對於管理結果的預期，無論它以時間、成本、效益還是怎樣的形式出現，都是一樣的。因為要達到預期的各種資源，都可以在一定條件下相互轉換。
幾乎每次作為諮詢師參加技術公司的計劃會議的時候，我都忍不住想笑。因為計劃會議還沒有結束，我就知道計劃的所有內容都百分之百地不可能按照會議上討論的那樣發生了。
為什麼呢？因為我聽到了這樣的有關計劃的對話。
- 功能A需要多久做完？開發需要兩週，測試需要一週，那就三週以後上線吧。
- 這個統計怎麼那麼慢？是用 Ruby 做的，換 C++ 吧，效率可以快一倍。
- 一共有六個模組，現在用了三週做了兩個，那就是說還要六週？是的，老闆！
在第一段對話中，有兩個做開發的程式設計師的日曆顯示，他們分別要請三天和四天的事假，而開發團隊一共只有五個程式設計師，但在會議上這件事被完全忽略 了。在第二段對話中，統計演算法顯然存在極大的問題，本來應該線性增長的時間複雜度，成了近乎二次方的，換成組合語言也不會對效率的改進有明顯影響。在第三 段對話中，六個模組中，已經完成的兩個是最小的，餘下的四個加起來，工作量幾乎是已完成的十倍。
這些例子給我們以教訓：制定管理計劃是非常困難的事，因為它需要關於未來的充分資訊，以及關於目的的充足知識。但計劃還會帶來一個非常要命的管理問題，那就是：一旦計劃未能兌現，並且沒有一個對此的合理解釋，從此以後就不會再有人把計劃當回事。
但短期的計劃往往非常跟不上變化。資訊瞬息萬變，今天一個好好的人，明天就可能會臥病在床。對於開展工作所需要的知識，更是隻可能隨著時間的推移才掌握得越來越多，等到全部掌握的時候，無論成敗，結果已經很明顯，也用不著再計劃什麼了。
因此，真正有意義的計劃，只有相對長期的計劃。計劃必須能夠容忍對於未來的未知，以及必要知識的缺失。而要克服未知和無知，投入時間和資源是必要的，計劃的週期越長，就越有可能在結果最終鉚定之前，積累起預見所必須的資訊和知識。
可是人們有強烈的傾向想要制定短期的計劃，比如 30 天減肥，21 天學會程式設計，等等。這其實是人類的惰性所致，想要付出微小的代價換取巨大的成果。但這樣的計劃一來是很難實現，二來意義也很小——30 天減了肥的人往往又胖了回去，21 天學會了一點程式設計皮毛的人往往沒過多久就又忘記得一乾二淨。企業裡面計劃會議多如牛毛，但真正堅持下來做成偉大事業的產品或專案卻寥寥無幾。經過多年的觀 察，我發現了一個特別有意思的現象，不妨稱之為計劃悖論：先有了計劃再上馬的事業，大抵無疾而終；先有了很多積累最終計劃才開始成形的事業，反而很有希望做大。
這個悖論有一個古老的版本：在雞蛋孵出小雞之前，不要去數你能賺多少錢。未來會有怎樣的變數，你要從事的水有多深，都不是一開始能知道的，計劃做得再漂亮也是枉然，只會讓人覺得你不靠譜。
小結
大家可能注意到了一點，這堂課裡充滿了很多矛盾，這正是技術和管理工作的根本區別所衍生的。技術人對於確定性的工作內容會感覺習慣，甚至駕輕就 熟、得心應手。計算機只會按照指令行事，就算是執行異常，也可以一步步地排查出原因。但人性就太不一樣了，它充滿了矛盾，並且很難有什麼確定性的規律，可 以讓他人像機器一樣服從管理。事實上，管理的魅力也正在於，不是讓他人唯命是從，而是發揮人的主觀能動性，激發出自身的潛力，解決管理者甚至都沒有想到過 的各種問題，並創造性地帶來巨大的附加價值。
因此，和技術工作根本不同的是，管理不是要親自照顧一切細節，而是要委託這些細節給被管理者，由他們自己來發揮才能。控制他人，將自己的意志傳達到位，然後徹底地放手，從指揮和命令的地位調整為服務和支援的地位，這就是最高明的管理者們唯一應該做的。
計劃是一把雙刃劍，不要先有計劃再做事，因為這個時候還不知道未來會發生什麼。先積累一些經驗，吃一些虧，朝向著目的推進一些，然後再一點點地 形成一些長期的計劃，這是做大事的節奏。如果計劃未能實現，就要在結果出現之前想辦法彌補，至少要做必要的解釋來調整計劃，否則團隊的信心會受到挫折，對 於管理者的信任也會下降，而這對於管理工作來說是非常不利的。
摘錄文章表達幾個關鍵觀點：
1、從指揮和命令的地位調整為服務和支援的地位，這就是最高明的管理者們唯一應該做的。
這個觀點讓我對應想到：美國有本書《管理是什麼》提到，管理者首先是服務者的心態
我以前在那家遊戲公司那個運營總監雖然只有中專文化，談不上高深管理理論，但他與大家打成一片，不是靠職位來壓制，擺在自己的心態了
在最優秀的技術驅動型的組織裡，管理者幾乎都是把 100% 的時間用於服務、支援甚至取悅被管理者，讓他們為著自己的想法，盡情地發揮自己的天才。無價的技術產品幾乎都是在這樣的氛圍中誕生的，這包括C語言、UNIX、Gmail 等等，這就是很好的證明。
3、作者強調：管理者的責任是如何調動他人的主觀能動性
為著自己的目的而採取行動，而在行動過程中發揮的也必然是自己的主觀能動性。如果想要脫離這個前提來實施管理，百分之百地達不到目的，即使被管理者被迫採取了一些行動，也只是做做樣子罷了。