一 、架構師與技術管理者

架構師是一個綜合性的角色，需要熟練掌握架構設計方法和開發技術，同時具備良好的組織管理能力。

在《深入剖析架構師角色》中我們分析了架構師的主要職責和所開展的活動，無論這些活動是偏向技術還是偏向管理，架構師都處於一個特定的環境中。

活動的開展也不是架構師一個人的戰鬥，需要與他人進行協作和互動。因此，除了各種專業的業務技能之外，架構師還需要掌握一些額外的技能。

在很多時候，我們也把架構師歸為一種技術管理者角色。技術管理者的工作包括設計行業與解決方案、推進業務結構與產品化、架構設計和技術創新、開展軟體專案管理和研發過程體系建設等。

視環境的不同，架構師也會在這些工作中發揮一定的推動作用。我們把這些推動能力統稱為軟能力，並從向上管理、向外管理和自我管理的角度出發簡要討論架構師所應具備的軟能力。

二 、向下管理

向下管理是組織管理最重要的一個方面，作為技術團隊的負責人，通常技術管理者會花費大部分時間在向下管理。

這裡“向下”的含義不僅僅是指你的直接下屬，在大中型團隊中，還可能包含你的間接下屬，也就是說技術管理者不僅僅需要管理下面的人，也需要指導下面的人去做向下管理，從而提高整個團隊的工作效率。

管理應該有好的思路和方法論，但期望這些思路和方法論能按照自己想的那樣發揮效果，通常只是一種理想。

在職權的範圍內充分利用人力和客觀條件，並以最小的成本辦成所需的事情還需要團隊負責人的領導力（Leadership）。

同時，領導力和激勵（Motivation）是兩個相輔相成的因素，對於軟體開發這一特定領域而言，領導力最主要的表現或者說最能發揮其作用的切入點是激勵。

1. 領導力

業界關於領導力的定義有很多，我們這裡引用大師 Gerald M. Weinberg 的說法，即所謂領導力，就是創造這樣一個環境，每個人都能在其中發揮出更多的能力。從這個定義上講，領導力就是催生其他人身上的創造力和生產力。

領導力針對的物件一般也可以分為人和過程，其目的是創造一種特定的環境，對環境中的人做出反應，向他們提供選擇，並給他們一定的自由度。

我們對領導力進行梳理，會發現其首先體現在用人上，找合適的人並進行管理是領導的第一步。

其次，我們會形成團隊的價值觀，並希望團隊中的所有成員共同遵守，團隊負責人在形成這種價值觀時會起到主導作用。

同時，提出優化流程的建議並付諸於實施能顯著提升領導力，團隊成員會在優化的流程中發揮越大的作用，領導力也就會產生越大的影響力。

最後，要注意個人在演講、聚會、會議上的表現，努力提升個人魅力。

對於提升領導力過程中應該遵循的原則，我們有我們的思路。我認為資訊透明和授權是領導力相關的兩條核心原則。

資訊透明在這裡可以理解為包含自我透明化、專案透明化和關係透明化三層含義。

自我透明化指的是表現自身的優點和缺點、承認自身的實力和興趣並積極參與上下級溝通，讓別人瞭解你是讓產生信任的基礎。

很多技術人員由於工作環境以及自身性格原因，在自我透明化上存在明顯缺陷，難以成為一個技術負責人，或者即使成為團隊的負責人之後，因為缺少與團隊成員的相互瞭解導致領導力大打折扣。

專案透明化主要體現在讓領導看到你的困難，對時間和進度上的透明度做把控，不能太透明也不能不透明。

同時，對專案中技術體系進行合理的的透明化有助於各種外部干係人對技術團隊的瞭解，提高協商過程中的籌碼。

建立自身的風格並保持不變，在做事情之前進行有效傾聽，同時提供讓別人透明化的場景和機會是關係透明化相關的實踐方法。

授權往往是技術人員所不擅長的一個領域，很多技術負責人在緊急情況下都傾向於自己出手，而忘了整個團隊。

身體力行，讓別人看到你在做事情是提升領導力的一種方法，但在有些場景下，通過授權讓團隊成員去完成有難度的任務恰恰更能提升領導力。

建立信任關係是授權的第一步，需要在平時進行不斷經營。而對某個具體場景，在授權之前確保團隊成員與團隊負責人達成共識。

資訊透明化的具體實現可以藉助於一些工具來展現視覺化資訊，而授權的切入點在於使問題簡單化。無論採用何種原則，嘗試在團隊中推銷自身的想法，並對核心問題和痛點保持關注。

追求平衡性（Balance）可能是提升和發揮領導力過程中最重要的策略，也可以理解為一種思維模式。

對於軟體開發而言，圍繞平衡性有兩個概念需要展開，一個是成功，一個是完美。對技術人員，很多時候我們會追求一種完美，對一個設計進行反覆提煉、重構並試圖找到所謂的最優解是很多技術人員的做事風格。

而對於管理人員而言，從思維模式上更傾向於確保專案和產品取得成功。成功和完美有時候可能會成為一對矛盾體，因為成功的事物不一定完美，完美的事物也不一定成功。

技術人員為了追求完美導致專案延期，或者管理人員為了追求成功使用各種非技術手段的現象並不少見。

而對於團隊負責人而言，我們認為很多時候需要做到結果導向，也就是需要在成功和完美之間追求一種平衡性。

領導力的表現形式有很多種，如帶隊育人的教導力、合理分配資源的組織力、綜合思考的決策力、人心所向的感召力等，技術管理者自身能夠快速成長的能力也是領導力的一種表現。

2. 激勵

業界關於如何進行激勵存在一些主流的認知體系，儘管這些體系偏於理論，但作為技術管理者而言，仍有必要充分理解並進行鍼對軟體開發領域的思考。

激勵的主流理論包括馬斯洛需求層次理論、麥格雷戈的 X-Y 理論、赫茨伯格的雙因素理論等。掌握激勵理論的目的是為了實施激勵措施。

因為基本的激勵理論面向所有人，所以我們需要針對軟體開發人員做進一步分析才能獲取相應的激勵措施。針對軟體開發人員，我們認為典型的激勵因素包括以下幾個方面：

• 學習成長

在軟體行業，技術變更如此迅速，沒有專業上的持續學習和成長，就可能很快被淘汰。這一點技術人員心知肚明，所以追求學習並不斷成長就成為首要激勵因素。

對技術人員進行學習成長上的激勵，最基本的手段就是營造良好的學習環境。

提供進修機會、提供培訓和自學的途徑、購買專業書籍、為每個新手開發人員指定導師、分配開發人員從事可以擴充套件其技能的工作都可以是行之有效的工作設計方式。尤其是人員培訓，需要有人員培訓計劃。

從入職開發，提供全生命週期培訓，不應該只包括技術類培訓。確保定期組織，形成一定模式並鼓勵全民參與。如果有條件形成專業培訓講師團隊，對培訓講師進行考核，並提供一定獎勵和報酬。

• 技術工具

技術提升當然也屬於學習成長的一方面，這裡單獨抽離出來是想強調為技術人員提供先進的工具、框架、技術體系上對他們的激勵作用。這可能是最容易做到的一項激勵措施。

確保為技術人員提供專業的開發工具，並在技術框架的選型和技術體系的建立上採用目前最流行的相關框架和架構有助於激發技術人員的開發熱情。

• 發展方向

對於那些已經或者即將處於瓶頸期的開發人員而言，為其指明發展方向並提供相應的發展機會將是一項非常有效的激勵措施。

以開發人員向技術管理者發展為例，開發人員比管理人員更重視技術管理的機會，針對成為技術管理者這一目標，指派每個人分別作為業務模組、資料庫、報表等某個特定領域的技術負責人，或者指派每個人分別作為持續整合、程式碼重構、系統整合等某個任務的技術負責人都是工作設計上的考慮點。

• 認可程度

技術管理工作的一個重要組成部分，是確保技術人員的工作得到認可。技術開發不像營銷，很少有直接的物質獎勵，要做更多精神層面的激勵。

技術人員內心渴望被認可，認可的場合可以是公開場合也可以是私下場合，認可的方式可以是簡單的口頭稱讚，也可以是具體某件事情的詳細展開。

對技術人員工作的認可，將對其工作態度、職業道德以及其他開發人員產生激勵效果。

• 工作環境

工作環境對技術人員的激勵在網際網路行業表現非常明顯。無論是靈活打卡或不打卡制度、加班補助制度，還是上文所提到的學習環境等，都對技術人員有良好的激勵作用。

這些激勵因素往往是一種相對的附加效果，沒有屬於正常，但有的話就能讓技術人員高度認可並更加容易融入到工作環境中。

• 直接利益

直接利益一直是個人績效的重要因素，傳統意義上的利益就是指工資、獎金、股票、期權等。高工資和可能拿到的高獎金是最基本的激勵因素，但這需要建立在個人以及團隊績效的基礎之上。

• 管理風格

團隊管理者的管理風格可以說對開發人員的工作表現有至關重要的影響。管理風格的一大表現形式就是對技術的重視程度，技術人員通常希望得到技術上的尊重並希望有一定的自主權。

當開發人員為實現自己設定的目標工作時，會比為別人更加努力的工作，這就是從成就感的角度來設定激勵目標。

體現在工作設計上，專案中的開發進度計劃首先應儘可能讓開發人員自己把握，這也是一項可以實施的激勵措施。

3. 績效管理

作為向下管理的重要一環，績效管理是對團隊成員進行工作評估和激勵的過程。

國內中小型研發團隊往往是從作坊式開發模式中發展而來，通常對績效管理的意識比較淡薄，或者乾脆沒有績效管理的理念和流程，管理層憑自身主觀判斷確定員工的績效結果。

當團隊發展到一定規模時，管理層發現靠自己的判斷已經不行了，所以就要搞一下績效管理。

這時候的績效管理可以理解為，團隊需要進行過程改進的一種預示。我們都知道過程改進領域有一個 PDCA 環，而績效管理本身實際上也是一個 PDCA 環（見下圖）。

過程改進如同專案計劃需要進行階段性規劃和控制，績效管理也是一樣。通常績效管理具有周期性，即以一段時間為限形成上面的 PDCA 環。

實際操作過程中以一個月或一個季度作為基準的情況較多，最好不要超過一個季度，否則 PDCA 環的時效性將大打折扣，下文統稱這一週期為績效週期。

結合績效管理的 PDCA 環及其週期性，績效管理的規程如下：

• 制定績效計劃

目的是根據團隊的專案和研發任務，在績效週期開始時確定績效週期內的個人工作計劃，確保為績效分析和溝通提供輸入。

主要角色是團隊中的每一個人。主要步驟上，團隊成員根據績效週期內團隊整體工作目標進行分解和細化，確定個人的績效計劃，並形成《個人績效表》。

• 收集績效資料

目的是在績效週期結束時根據個人在績效週期內的工作情況，收集績效資料並形成績效結果，為績效溝通提供個人的自評。主要角色同樣是個人。

主要步驟上，團隊成員基於在績效週期初確定的《個人績效表》中的績效計劃，結合績效週期中的具體工作完成情況進行自評，並填充《個人績效表》中的自評績效資料。

• 評估績效

目的在於根據績效週期內的績效資料以及團隊整體計劃對團隊成員的績效進行評估，從而明確績效結果，為績效溝通提供他評。個人直屬上級會主導這一過程。

主要步驟是：團隊成員的直屬上級基於《個人績效表》中的績效計劃以及績效週期中的具體工作完成情況進行他評，並填充《個人績效表》中的他評績效資料，他評資料中包括對績效的整體評分。

• 溝通績效

目的是根據績效計劃、員工自評和上級他評，對結果進行分析並明確改進思路和措施。個人及其直屬上級會和人事專員一起參與這一過程。

主要步驟為個人及其直屬上級進行面對面溝通，對該績效週期內的結果展開討論，主要針對其中存在的問題觸發團隊成員自身的思考並找到改進的切入點。

三 、向外管理

在任何團隊中，任何場景都可能會有“扯皮”現象。扯皮現象有利有弊，很多結果有時並不是做出來的，而是協商出來的。有些事情看上去很難，但一協商發現並沒那麼難，而一點小事如果沒有協商可能變成一件大事。

對於協商，換位思考或者說同理心可能是消除協商過程中出現過多扯皮現象的一大原則。

站在對方的立場上思考問題，然後再丟擲符合對方立場的言論，並能引導到己方利益的觀點，這需要技巧性，這種技巧性的培養需要循序漸進的把握協商過程，而不是對任何問題都直奔主題。

同時，在協商過程中，不要掩蓋問題，尤其是對雙方都有影響的問題確保在協商過程中明確的提出來，並得出確切的結論。最後，關於協商原則記住一句話，態度要和藹但立場要堅定。

有一些障礙會導致協商過程的正常推進，其中包括組織中的政治因素，對架構師而言，可能也會面臨很多技術性障礙。面對障礙，儘量尋找雙方的共同點，並採用“足夠好”而不是“最完美”的方案。

我們把整個協商過程分成協商前、協商中和協商後三個環節。其中，協商中的過程具體問題具體分析，對協商前和協商後則可以採取一些通用的手段和策略。

在協商前，最重要的是明確此次協商的目標，包括最低和最高目標。梳理哪些內容是可以或不可以協商的，明確相關干係人，團結一切可以團結的力量。

另一方面，充分的準備是協商成功的一大關鍵，關於這次協商的資料、文件、環境等因素都在考慮範圍之內。

對於某些預想中比較難以協商的內容，協商前對關鍵干係人或某些關鍵檔案資料等進行私人或內部團隊之間的預演也是必要的一些環節。

當協商完成之後，不管協商結果如何，記錄是必不可少的。對於本次協商中重要的決議確保進行文件化和郵件化，如有必要也可以納入版本控制系統之中進行管理。

對決議的執行過程中，明確決議的邊界，執行自身相關的任務。但對於架構師而言，還要嘗試學會委派下面的人進行任務執行。

四 、自我管理

自我管理也是一種管理，而且執行起來可能比上面幾個管理都要困難。

作為技術管理者，最重要的工作並不是衝到一線做各種技術研發，而是要處理技術以及一些非技術相關的各項事宜。

所以處理事情是自我管理中除了個人風格外的又一個重要主題。處理事情需要做到對時間的合理利用以及對事情的管理和跟蹤。

技術管理者作為整個技術團隊的統一入口和出口，在對每件事情所持有的態度上應該有基本的原則。

• 重要且緊急的事情應該立刻去做

• 重要但不緊急的事情可以有計劃的做

• 不重要但緊急的事情應該學會委託他人去做

• 不重要不緊急的事情就儘量別做

以上通過時間管理的理念對事情的優先順序做了分析，時間管理的關鍵在於有一份每天的待辦事項清單，同樣的，跟蹤這些待辦事項也很重要。正如你向上級彙報一樣，需要時刻關注工作完成情況。

一般需要維護日常任務清單，這份清單可以通過一些電子化工具在你的工作電腦或手機移動端進行提醒。