這二十個問題，多是你技術人生中已經或即將遭遇的痛點，怎麼解？

　　編者按：本文來自微信公衆號「InfoQ」（ID：infoqchina），做者周明耀

　　關於技術管理的系列文章，這是第三篇。沒有實踐支持的理論，容易流於空想。爲此做者特地設計了 20 個特定的場景，幫助你更好地去理解、落地技術管理這件事兒。這 20 個問題，不必定都適合你，但總有一個，是你已經遇到，或者即將遇到的痛點所在。想知道怎麼解決嗎？

　　寫在前面

　　最近針對技術管理工做寫了兩篇文章，分別是《程序員， 這是你想要的技術 leader 嗎?》和《別人家的技術 leader 是如何建設團隊、管理人員、溝通工做的?》。讀者針對技術管理提了不少問題，這裏我對這些問題進行回覆，既是出於對提出問題的朋友的尊重，同時這些問題也是不少朋友均可能正在遇到或存在的疑惑，書面回覆比較容易擴大交流範圍。一共 20 道問題，我儘可能用平實的語言回答這些問題。

　　1. 我在小公司作了 2 年的 Leader，請問如今應該繼續作下去，仍是去阿里這樣的大公司從程序員作起？

　　個人見解是，不管去阿里作程序員，仍是繼續留在當前的公司作 Leader，本質上都沒有錯，更多應該關注你所作的事情，是否有技術含量？是否符合你將來的職業發展方向？這兩點很重要，不管在哪一個環境，千萬不要習慣於安逸，這樣就比如溫水煮青蛙，慢慢地你會失去技術能力，進而失去成爲或繼續作技術管理的機會。

　　2. 內向的人如何管理？內向的人如何帶團隊？

　　這一題我想多講一些，由於，本質上我也是內向型的人。

　　外向的人天生善於交際，長袖善舞，更容易引發別人的關注，在團隊中表現更加活躍，因此他們更容易得到成功，也更討人喜歡；內向的人卻不容易獲得重視、關注，甚至快樂。

　　有些父母發現本身的孩子是內向的人，他們會以爲有點遺憾，甚至難過。還有一些會嘗試改變孩子這種性格特色，更有甚者，會認爲孩子有心理障礙。然而內向型人格真的是一種不太好的人格特質嗎？美國有一本暢銷書《安靜，內向性格的競爭力》，做者蘇珊. 凱恩列舉了許多性格內向的成功人士，他們安靜、穩重、深思熟慮，他們默默地帶給這個世界許多改變。若是他們不幸被強制改變成外向的人，這個世界會少量多天才，多出來許多「病人」。

　　回到工做中。內向的人表現爲很是沉默、內斂，幾乎感受不到他們的存在。他們能夠把工做完成得很出色，可是對團隊執行力或者在會議上幾乎沒有什麼貢獻。他們在一對一的時候能進行交流，但退回到人羣裏之後幾乎消失了。

　　在會議上讓他們發言時，當他們分享本身的意見或看法時，要給予正面的支持，這樣能夠逐漸幫助他們創建自信，讓他們感受到本身對於團隊是有貢獻的。找機會跟他們交談，當面承認他們的貢獻。與他們的交流要單獨進行，經過一些小事情與他們創建特殊的聯繫，例如分享工做經驗、交流管孩子心得。總之，想法設法創建更緊密的聯繫。

　　而做爲一名 Leader，你在生活中能夠繼續保持本身內向的本質，可是在工做中，你須要可以作出改變，承擔起全部技術管理者應該承擔的責任，勇敢地面對你所須要面對的複雜環境和事物，積極地與員工溝通，積極而高效地解決遇到的難題。回到家，你依然能夠是那個內向而細膩的你。

　　3. 如何評判一個 Leader 好仍是很差？

　　我以爲 Leader 沒有好或者很差之分，只有稱職和不稱職的區別。一位稱職的領導，他須要作好團隊的向下管理、向上管理、對外管理、自我管理等四個方面，管理的最終目標是：「不要讓你的下屬陷入困境，不要讓你的同事陷入困境，尤爲是在任何狀況下，都不要讓你的上級陷入困境」。

　　做爲一名 Leader，千萬不要覺得不讓員工承擔較重的工做負擔就等同於好領導。在技術圈，好人不等於好領導。技術是須要實際工做環境進行積累的，若是不讓他們參與到技術難度較大的項目裏，那麼他們工做幾年可能都是在原地踏步，這樣會讓熱愛技術、對職業發展有本身的規劃的有志之士選擇離開你，他們要的不是一個單純的好人，而是一位可以教給他們知識、引領他們不斷提高技術的 Leader。

　　4. 你有遇到過怎麼樣的很難處理的人或者事情？

　　有。在我過往的職業生涯中，我有遇到致使團隊奔潰的奇葩，也有遇到因爲沒有及時搞定技術問題，致使領導層對技術能力不承認的狀況發生。

　　先說奇葩這件事。我有遇到過一心想當「老大」，不擇手段壓制同伴的奇葩，也遇到過對人很粗魯、思惟方式很自個人奇葩，還遇到過處處借錢的奇葩。對於各種奇葩，換成如今的我，我必定會在第一時間讓他們走，不管他們的水平有多高，都不會猶豫，也不會指望本身可以改變什麼，他們的性格是受了家庭或者經歷的嚴重影響的。讓這些人儘快遠離團隊，這樣整個團隊都會輕鬆不少。在我做爲技術管理者還不成熟時，我沒有處理好，致使了團隊的負能量激增，這是個人過錯，不會再犯。

　　再說後面那種狀況。對於從事技術管理的人來講，技術和管理的比重最好可以保持在 8:2 的狀態，這裏不是說只拿出 20% 的時間進行管理，而是須要你可以天天只用 20% 的時間作完應該用 50% 時間作的管理工做，只有這樣你纔可以有足夠的時間處理技術問題、不斷提高本身的技術能力。不管出現什麼技術問題或難題，必定要第一時間引發注意，將這件事的優先級派到較高地位，第一時間帶領團隊成員分析問題緣由、明確解決思路和方案，安排相應人員着手進行技術調研或測試、編碼等工做，用最短的時間找到切實可行的解決方案，並付諸實施。

　　5. 平級的人，很難相處，怎麼辦？

　　米歇爾在去年美國大選以前的民主黨全國表明大會上，這樣描述本身的想法，「When they go low，we go high.」。當你遇到你以爲很難相處的人時，你須要告訴本身，保持本身的職業素養，不要輕易被別人激怒、煩惱，依然保持一顆日常心，努力把本身的工做作好。

　　對於平級的人，你確實拿他沒辦法，個人建議是找大家共同的領導反映你的困惑，或是經過你的領導找到他們的領導，由領導層溝通。對於全部的管理類問題，我以爲首先要自我檢查，確保不是自身的問題，而後是溝通，保持高效、簡單的溝通，這樣能夠幫助你至少說出本身的困惑，最後是放鬆自我，不要被不值得的事情或人所煩惱，過好本身的每一天，全力作好本身的工做，不斷提高自我價值，抽出時間陪伴家人，這纔是你應該作的。

　　6. 技術爲主的公司和非技術爲主的公司，技術管理有什麼區別？

　　首先，技術爲主的公司和非技術爲主的公司，技術管理者所作的工做是有明顯區別的，所以，對於技術管理者的技術背景也是有明顯差別的。非技術爲主的公司，團隊領導能夠不是程序員出身，他可能來自業務部門，也可能來自運營部門，只要他過往的經歷能夠幫助他 Hold 住這個崗位。而對於技術爲主的公司，技術管理者若是不懂技術，那基本上參加會議時一句話也插不上，別人又怎麼對你有技術尊重呢。

　　技術爲主的公司，程序員不少。從許多方面看，程序員之間的差別很是大，只有很瞭解程序設計的人才能徹底理解這一點，事實上，程序員之間的差別主要來自我的內在因素，而不是外在屬性。微軟公司的 Bill Gates、Adobe 公司的 John Warnock、FaceBook 公司的 Mark Zuckerberg 都沒有犯這樣的錯誤，由於他們本質上也都是程序員。這也是爲何我以爲某些大型軟件企業須要變革的緣由，我的認爲，在科技界你最好不要讓非技術出身的人擔任 CEO。

　　7. 小公司裏項目很是多，項目流程怎麼走？

　　通常狀況下，企業開發軟件時會按照基線和定製兩塊並行方式執行項目開發工做。不管什麼公司，都須要聽從一套成熟的產品研發過程體系，才能作出質量較好的產品。所以，若是出現項目較多的狀況，應該合理地安排基線和定製以前的里程碑，讓基線產品可以儘可能多地收集用戶的通用型需求，爲定製項目進度實現技術支撐，減小定製項目中大量更改代碼、須要新增模塊狀況發生。此外，產品研發過程體系也須要按照業務實際時間要求變化，不要拘泥於必定要按照瀑布方式，或是敏捷方式進行管理，凡事都須要找到契合本身的方式。鞋合不合腳，只有腳知道。

　　8. 如何使技術開發的人願意從事產品業務開發？

　　確實存在這樣的狀況，技術開發人員不太願意理解產品業務。咱們要從另外一方面來引導他們，每一個人都會對本身作的產品有特殊的關注，若是你能不斷地收集用戶使用後的反饋，特別是正面的反饋，那樣就能夠激發起技術人員對於產品的熱情。我據說雙 11 時，阿里會在辦公室掛上電子地圖，動態實時反饋各個城市的銷售量，這種方式會讓技術人員頗有讓系統保持穩定運行的動力。

　　9. 老是控制不住情緒，產品有些簡單問題，老是來問，怎麼辦？

　　慶祝你的成功，在失敗中尋找幽默。別太把本身當回事兒，你放鬆，你周圍的人才能放鬆。享受樂趣，並始終保持激情。——Sam Walton，沃爾瑪創始人

　　不要對別人過於苛刻，這樣會讓你控制不住本身的情緒，你會認爲別人很愚蠢，但在你作出這樣的判斷以前，你應該學會理解別人，由於你沒有站在他的位置上，他所承擔的壓力、所面對的困惑，是你所不瞭解。因此，首先學會和人溝通，學會理解別人，不管對方是你的上級、接口人，或是下級。

　　若是你以爲不少問題一遍遍地解釋，那我以爲有必要抽象出一份資料，Word 或者 PPT 均可以，形式不限，往往遇到這類狀況時，你就能夠甩出文檔，避免本身的時間被這類狀況消費了。

　　10. 公司沒有項目獎、年終獎，如何激勵下屬？

　　亞伯拉罕. 馬斯洛在 20 世紀中葉提出了需求層次模型。在 1954 年首次出版的《動機與人格》（Motivation and Personality）一書中，他將該理論引入了商界。馬斯洛認爲，人的需求能夠按層次劃分，從最基本的對事物和居所的需求，到最高的追求自我完善，在低層次需求還沒有徹底知足以前，更高層次的激勵沒有多少用武之地。

　　直到今天，需求層次理論依然使人信服，在理解人的動機和我的發展的管理培訓中常常會引用它。事實上，馬斯洛圍繞需求層次理論所提出的觀點，今天依然在促使咱們不斷改善工做環境，鼓勵員工充分發展，自我實現。

　　一旦生理需求知足後，人們就會尋求更高層次的知足。佛雷德里克. 赫茨伯格在 1959 年出版的《The Motivation to Work》一書中描述了他認爲的激勵因素，包括成就、承認、工做自己、責任、發展，只有當這些都獲得實現和知足時，人們才能獲得真正的激勵，這樣來看，這些因素意義重大，表明着更深層次的成就。

　　回到咱們的問題。我以爲，他們家老闆開公司到底想不想賺錢了？搞了一個大鍋飯環境，連基本的激勵都不存在了，還怎麼讓員工作出成績。

　　11. 領導要求工做時間 996，怎麼看待？

　　我我的以爲並非以待在辦公室的時間長短評判一我的的工做是否稱職，咱們須要堅持的是以任務結果導向爲主要評判標準。對於重大問題，好比阿里的雙 11，若是系統出現問題，那麼意味着全部的供應商都有可能由於系統問題致使破產、失業，進而你的職業生涯也結束了。因此，咱們仍是要看本身所從事的工做的複雜性，若是確實須要，即使是通宵待在辦公室或客戶現場，我以爲也是必要的。

　　12. 如何提高團隊的技術氛圍？

　　團隊的技術氛圍，咱們能夠依靠創建技術分享制度、要求資深工程師參與或主導開源項目等方式增強技術氛圍，但歸根到底仍是要有需求。只有當你團隊所負責的業務需求迫使你不斷作出技術更新，你纔會真正意義上去不斷自我學習，進而造成濃重的技術氛圍。人，都是被逼出來的。

　　13. 對於態度不是很好的員工，應該如何解決，溝經過幾回，也沒有效果。

　　表現不好的人給團隊拖後腿的方式不少。他們佔用了預算的一部分，可是卻沒法交付出有效的成果。其餘人若是看到他們差勁的表現，也會消極得失去動力或者失去對你的尊重。表現差的人可能會影響項目的進度，從而對項目中的每一個人都產生不利影響。他們也會佔用會議中的大量時間。所以不論如何，這種狀況必須儘快解決。

　　雖然很難開口，但一般，終止合同對你和員工都是件好事。不少表現不好的員工都知道本身不好。不多有人會看不到現實狀況，還幻想本身表現很出色。他們天天上班和睡覺都揹負這這個沉重的負擔。對大多數人來講，負擔會沉重到難以忍受。因此，當你最終直面他們，並開始終止合同的流程時，員工一般會感到一種放下包袱的輕鬆。不少人會選擇離開，也有一些人會選擇嘗試績效改進，若是選擇後一條路，你必定要按期與這個員工會面，審查績效狀況並討論結果。

　　14. 技術管理者的 Coding 能力須要有多強？

　　這一題和第 6 題相似。對於技術爲主的公司，若是你沒有很強的代碼編寫經驗或者能力，你實際上會缺乏對於技術方向的把握、對於技術細節的指導能力，進而失去程序員對你的技術尊重，可能只剩下管理尊重了，也就談不上合格的技術管理稱呼了。

　　對於非技術爲主的公司，例如銀行，我據說有研發團隊的 Director 是由測試出身的人擔任，也擔任得很好，這是由於他可使用業務知識（多是他工做以外積累的）、較好的英語能力，贏得客戶的信任。

　　15. 沒有考覈權利怎麼辦？

　　仍是溝通。不少狀況下，你確實沒有直接的考覈權利，那就和你的領導進行溝通，但願至少給予你參與考覈的權利，即以他爲主，以你爲輔，這樣你就能間接地參與所管理者的考覈。萬事，學會溝通，高效、有效地溝通。

　　16. 創業型公司給配了一些能力不好的程序員，讓我來領導，怎麼辦？

　　不管 Starbucks，仍是臺灣的一點點奶茶店，他們所僱傭的員工素養通常都較高，尤爲是 Starbucks。正是因爲這一點，造就了這兩家公司分別在咖啡零售店和奶茶零售店的絕對優點，至少在杭州是這樣的。

　　創業型公司，若是認爲技術人員的投入太多，而轉而選擇能力不好的程序員，那麼最終也會落得和上面所說的例子之外的其餘咖啡或奶茶零售店同樣，永遠不可能作成行業領頭羊，而是很容易被淘汰。這是一個科技的時代，只有擁有技術，你纔有可能最快、最好地作出產品。

　　17. 公司政治鬥爭激烈，如何避免捲入？

　　真正熱愛技術的人是不肯意參與政治鬥爭的，由於那樣會很耗費本身的精力，讓本身深陷其中，致使技術不能深刻研究。

　　我以爲避免捲入的最好方式是，成爲技術大牛，成爲一位讓公司高管、中層所尊重的技術人員，用你的專業能力證實本身。

　　18. 怎樣引導 / 協調好各個部門的關係？

　　若是你想要建造一艘大船，不要立馬號召你們開始收集木材，也不要立馬分配任務和工做，而是應該先教會他們去憧憬廣闊無垠的大海。——Antoine de Saint-Exupéry

　　團隊技術管理者工做中的一個重要部分是引導事情走向正確的方向，並確保團隊成員之間以及團隊之間有正確的溝通方式，這就須要協調團隊成員之間、團隊與團隊之間工做。須要注意的是，引導 / 協調的最終目的是爲了讓事情完成，而不是把關注點放在如何完成。

　　對於一個團隊管理者來講，要想最大化地利用本身的時間和技能，就要引導程序員本身作出正確的決定，而不該該本身就把決定作了。想要協調好全部人，你首先須要學會傾聽別人的想法，只有理解了他們的困惑，你纔可以把引導 / 協調工做作好。這樣作，能夠幫助下屬員工培養技術、積累經驗、創建自信，還能得到那些具體執行決定的員工的認同。

　　若是你發現本身常常須要討論很是具體的命令如何執行，那說明你沒能很好利用你的管理技能，或者沒能賦予下屬員工足夠的權利。做爲團隊管理者，你必須指出大方向，而後作好充分的檢查，以確保員工作出正確的決定和實現。及早檢查下屬員工作出的重要決定，不然當你想中途接入並修正時，員工可能已經作了不少無用的工做。這也是爲何我在「進度管理」一欄中強化本身的天天進度跟蹤、討論的重要性。

　　記住，優秀的主管要有足夠的自制力，不在下屬員工工做時瞎指揮。

　　19. 領導不懂技術怎麼辦？

　　領導是你的上級，因此你須要作好本身的向上管理。向上管理取決於你是否可以正確地理解你的老闆，以及其餘你可能間接或隱式彙報的人。若是你是向工程副總裁彙報，那麼溝通和彙報多是技術性的，若是你是向首席執行官或者產品副總裁彙報，那麼你的彙報可能就要減小技術性，增長信息性，也許還要多加一些與產品相關的內容。除此以外，你老闆的級別越高，你的報告就越要精簡，越要注重大局，細節更少、局面更大，文字更少、項目符號更多。

　　對於一位對技術不敏感的領導，你應該去深刻了解這位領導的擅長領域，或者他過去的從業經歷。經過將技術與這位領導的關注點相結合，例如產品出身的領導比較關注產品，那麼你能夠從技術爲產品發展帶來了什麼好處提及，吸引他的興趣，這樣你纔可以繼續不斷地深刻技術研究。

　　20. 個人 Leader 生病了，請了長病假，CTO 直接管團隊，可是幾個月都不開團隊會議，咱們很迷茫！

　　我曾經參加過一次技術管理者培訓。培訓課上看了一段小短片，講述的是一位盲人報名參加一次野外馬拉松賽。短片中這位盲人有一位導師，這位導師用繩子將本身的手臂和盲人的手臂綁住，比賽開始後兩人同時出發，比勝過程中他不斷地提醒盲人須要注意什麼，例如前面是平路，咱們用怎樣的步履跑步，前面有個坑，我喊一二三就跳過去，等等。

　　一路上，盲人始終聽從着導師的指導，順利完成了馬拉松賽。咱們做爲技術管理者，對於員工的指導，也和這個短片中的導師與盲人的角色相似，須要給予指導，而不是僅僅下發工做安排，或是插着手站在邊上看着他們陷入困境。

　　回到這個問題，個人認知是，不管你是 CTO，仍是 CEO，甚至是 UFO，既然你承擔了團隊負責人的實際工做，那麼你就應該天天召開例會，就應該不斷地抽時間和你們一塊兒討論架構、業務流程、技術難點、技術方向，這是你的職責，不要來談你有多忙，你的職務有多高，若是真的很忙，你能夠任命臨時團隊管理者替你承擔責任，而不是讓團隊處於流浪狀態。簡而言之，這位 CTO，你失職了，無論你喜不喜歡，既然你直接管理團隊，就要以身做則。

　　做者介紹

　　周明耀，2004 年畢業於浙江大學，工學碩士，國外投資銀行 12 年工做經驗，4 年分佈式系統，物聯網工做經驗，10 年技術團隊管理經驗。IBM 開發者論壇專家做者，Infoq 專欄做者。著有《大話 java 性能優化》，即將出版著做《深刻理解 JVM 和 G1 GC》，已提交分佈式計算領域發明專利超過 15 項。微信號 michael_tec。

 

來自: InfoQ