阿里巴巴高級技術專家至簡：聊工程師思惟

摘要： 爲何想到寫這篇文章？做者是想經過對工程師思惟的分析和解讀，讓工程師能正確對待那些在現實工做中看上去與本職崗位無關，卻對團隊效能影響極大的一些點和一些事。 至簡：阿里巴巴高級技術專家，是集團Service Mesh方向的重要參與者和推進者。

爲何想到寫這篇文章？做者是想經過對工程師思惟的分析和解讀，讓工程師能正確對待那些在現實工做中看上去與本職崗位無關，卻對團隊效能影響極大的一些點和一些事。

至簡：阿里巴巴高級技術專家，是集團Service Mesh方向的重要參與者和推進者。曾出版《專業嵌入式軟件開發——全面走向高質高效編程》一書，堅信和倡導軟件設計是軟件質量之根本，並對軟件開發的複雜性本質有着深入的認識，對如何高質高效實施軟件開發有着本身獨到的看法和方法。

在社會分工的背景下，軟件行業的工程師羣體被劃分紅了開發、測試、產品等諸多崗位，以協做的方式共同完成價值創造。高度依賴軟件的互聯網行業正以全新的方式改善着人們的生活，同時在改善的道路上對價值創造的效能提出了更高的要求，而背後是對個體與團隊的協做效能有着更高的訴求。

專人專崗的協做模式在進一步改善團隊的協做效能時所面臨的最大挑戰在於「崗位牆」，即崗位間銜接不可避免會出現一些模糊地帶，而這些模糊地帶又很容易相互忽視，致使失去關注而很大程度地拉低了團隊效能。好比，開發工程師會認爲保證質量是測試工程師單方面的職責；開發工程師不關注用戶體驗而只需關注實現需求，等等。此外，這種協做模式也會固化個體的思惟和心智模式，將個體的思惟和心智框定在所處崗位以內，以至對於崗位以外的內容不能很好地理解，使得個體在整個協做活動中會缺少同理心、系統性，從而影響工做幸福感。

相信這些現實工做場景讀者並不陌生：

開發工程師對產品工程師所提出的用戶體驗方面的需求會認爲過於吹毛求疵；
產品工程師因不理解技術的實現原理而提出天馬行空、不接地氣的需求（咱們在此不討論創新這一特例）；
測試工程師由於不理解工程效率的內涵而將本身的工做變成了體力活；
開發工程師不清楚本身對於軟件質量的責任，而將那些本因本身作好的瑣碎工做問心無愧地交給測試工程師去作；
辛辛苦苦所開發出來的功能，用戶抱怨難用。

這些問題發生的最終結果，必定是團隊協做效能的低下。那麼在沒有找到比專人專崗更好的協做模式的情形下，咱們該如何發揮個體的力量去改善團隊的協做效能呢？做者認爲，改善的起點在於全面地梳理工程師思惟，幫助工程師個體在職場和職業發展中創建起更爲全面的思惟和視野，以促使每一個工程師在協做過程當中能最大程度地發揮個體能力去推進團隊協做效能的提高。

做者將工程師思惟分解爲產品、技術和工程三大思惟。每一個維度主要關注的內容經過幾個關鍵字去表達，以下圖所示。下面針對每種思惟須要關注的每一個詞以圖中從上至下的順序去解釋。因爲解釋是基於關鍵詞去展開的，因此段落之間的銜接可能會顯得生硬，還請讀者見諒。

產品思惟
產品思惟的起源是用戶（或客戶）價值。用戶價值是經過技術手段以產品或服務的形態去解決用戶的痛點，或帶去爽點。毫無疑問，工程師在平常工做中應時刻關注並釐清本身的工做與用戶（或客戶）價值的聯繫，而且應該經過聚焦於用戶價值去安排工做的優先級和分配本身的精力。

當用戶價值足夠時，產品可否在市場中立足並真正收穫收益，首先考驗的是產品的用戶體驗。良好的用戶體驗必定是站在用戶的角度，基於用戶心智來塑造概念，因爲概念存在理解和解釋成本，因此塑造的概念應足夠輕、少且易掌握。概念一旦塑造出來則概念間的關係也隨之肯定，這些關係基本上決定了產品與用戶的交互流程。好的產品體現於「易用」二字，其極致在於迎合用戶的本能反應並符合各類生活或專業常識。

全部產品都存在演進的過程，所創造的用戶價值也在被不斷地挖掘與探索，那時不一樣的細化價值須要經過產品特性去區分和表達。特性也是產品差別化的一種體現，特性也間接地肯定了軟件實現層面的功能模塊邊界。做爲開發工程師，也須要對產品特性有很是透徹的理解，並能將其很好地抽象並轉化爲軟件實現層面的功能模塊。特性須要考慮經過售賣license等形式進行開啓或關閉去實現售賣，這一點對於2B的產品甚是必要。

爲了產品更好地演進，須要經過數據閉環的形式去檢驗創造用戶價值的效果，讓產品的開發、運營、營銷工做作到有的放矢。在產品價值創造的道路上，最懼怕的事莫過於只顧低頭幹作加法，作得多卻無人關心收效。而咱們經過數據化閉環的形式，不只能讓整個產品大團隊聚焦於核心價值，還能幫助團隊在探索用戶價值的道路上理性地作減法。大多情形下，作減法遠難於作加法。

技術思惟
技術思惟的源頭是需求。需求能夠分紅市場需求、系統需求、特性需求等不一樣層次，回答的是技術層面「作什麼」的問題。顯然，清晰表達的需求以及對需求的精確理解才能確保將事作對。毋容置疑，需求一旦出現誤差所致使的浪費是很是嚴重的，也正因如此工程師對於需求的質量至關重視。

需求一旦確立，會基於模塊化的思想拆分紅多個功能模塊去下降實現的局部複雜度，最終將全部功能模塊「拼接」在一塊兒去實現總體需求。每一個功能模塊會安排給一我的或一個團隊負責，因爲功能模塊是需求分解後的產物，容易致使工程師在實現的過程當中只看到「樹木」而忘記了「森林」。

性能是工程師在實現一個功能模塊時不得不關注的，特別是當功能模塊被運用於高頻、時效性敏感、算力有限的場合時性能將尤爲被關注。在現實中有時會存在工程師樂於追求性能的極致去體現本身的技術實力，甚至出現過早追求性能而滑入過分設計的誤區。

毫無疑問，一個正規的團隊，對於功能模塊的開發工做多會以項目制、多個迭代的方式去完成交付。很多工程師這裏會有一個誤區，忘記了敏捷思想所倡導的「項目計劃的目的是爲了適應變化」，而是將「按時交付」看成是天職，各類趕工爬到終點時卻絕不意外地看到了「一地雞毛」的景象。

在邁向第四次工業革命的道路上，人工智能、大數據、機器學習，Kubernetes、Istio、Knative、Go、Dart、Flutter等新技術不斷衝擊着工程師已掌握的技能。快速跟上技術的迭代步伐是每一個有追求的工程師不斷提高本身專業素養的表現之一。工程師的心裏必定不缺少對新技術的追求，憧憬本身所掌握的技術具備必定的先進性。

工程思惟
工程思惟的起點是流程。流程的背後是科學，以既定的步驟、階段性的輸入/輸出去完成價值創造，經過過程控制確保最終結果讓人滿意。因爲流程涉及每個工程師的工做質量與效率，其含義不僅在於定義、工具化、檢查等內容，而是應基於工程師的平常工做習慣，將流程與工程師的工做環境無縫整合。「無縫」體現於流程中的概念與工程師羣體已創建的專業常識相一致、沒有增長毫無價值的負擔，根本還是確保易用性。

機制的含義是經過對所需解決問題的分析，以一種模式去解決同類問題。機制應體現必定的系統性，而非「頭痛治頭，腳痛治腳」。系統性不是一開始就能被洞察到，可能在演進的過程當中逐步發現和完善的，於是須要工程師在工做的過程當中不時回顧並付諸實踐去落實。對於工程師來講，機制是經過系統性的軟件設計去達成的。

能夠說產品質量直接決定了工程師的工做和生活幸福感。一個質量不可靠的產品必定會給用戶和工程師本身帶去麻煩，甚至形成沒法挽回的經濟損失並形成負面的社會影響。對於工程師來講，那勢必打亂個體的工做與生活節奏。爲了讓產品的質量作到可靠，單元測試、靜態分析、動態分析等確保工程質量的手段應成爲工程師的基本工做內容，經過將這些手段與CI（Continuous Integration）流程進行整合去持續構建起對軟件產品的質量信心。

在互聯網行業，除了軟件產品的質量得可靠外，風險可控是另外一個不能忽視的內容。而風險可控是創建於系統性機制和質量可靠之上的。對於服務端軟件來講愈是如此。風險每每出現於資源使用的極端場景，當從外部涌入的過多事務遠超軟件產品的處理能力時，須要有必定的機制讓整個產品能相對平滑地應對，或是擴充資源、或是限制涌入事務的流量。
軟件所需的機器成本是比較容易忽視的話題，軟件成本不僅與軟件性能相關，還與軟件之間的依賴、技術方案等因素相連。當一個軟件須要從公司的內部對外輸出時，平時忽視對成本的關注就會暴露出成本問題。好比，爲了運行某個軟件須要數量龐大的計算資源，所致使的資金開銷對於客戶來說極可能是沒法接受的。

至此，大體介紹完了本身所理解的工程師思惟。

延伸
瞭解工程師思惟的價值在於，工程師個體須要在工做中逐步創建起產品、技術和工程三大思惟，以便用更爲全面的視角去看待平常工做中所面臨的困境和困惑。當站在單一的思惟去看待所面臨的問題時可能以爲不合理，但從三大思惟層面去審視時所獲得結論可能徹底相反。從團隊協做的角度，只有團隊中有更多的個體從多維度去進行思考，才容易發現崗位間銜接的那些無人問津的灰色地帶，進而經過補位、助攻去更大程度地發揮團隊的效能。

顯然，不一樣崗位、不一樣職責的工程師對於這三大思惟的深度要求是不同的，但從多維度去思考卻應是每一個工程師都應該具有的素養。

讀者讀完這篇文章後若有什麼感想歡迎分享。也歡迎經過留言告訴我您所關心的其餘職場問題，做者將酌情經過後續文章分享本身的思考。最後，也給讀者留下一些問題，一樣期待您經過留言分享本身的思考。

問題1：爲何互聯網行業對於團隊效能的要求更高？背後有什麼必然緣由嗎？問題2：有些互聯網企業進行產研測（指產品、研發和測試）融合的探索，融合的本質是什麼？如何代表產研測作到了真正融合？