阿裡妹導讀：不同崗位、不同職責的技術人對工程師思維的深度要求是不一樣的，但從多元度去思考卻應是每個技術人都應該具備的素養。本文整理自阿裡巴巴進階技術專家至簡在團隊内部的個人分享，希望通過對工程師思維的分析和解讀，讓大家能正确對待那些在現實工作中看上去與本職崗位無關，卻對團隊效能影響極大的一些點和一些事。
作者簡介：至簡，阿裡巴巴進階技術專家，是集團Service Mesh方向的重要參與者和推動者。曾出版《專業嵌入式軟體開發——全面走向高質高效程式設計》一書，堅信和倡導軟體設計是軟體品質之根本，并對軟體開發的複雜性本質有着深刻的認識，對如何高質高效實施軟體開發有着自己獨到的見解和方法。
在社會分工的背景下，軟體行業的工程師群體被劃分成了開發、測試、産品等諸多崗位，以協作的方式共同完成價值創造。高度依賴軟體的網際網路行業正以全新的方式改善着人們的生活，同時在改善的道路上對價值創造的效能提出了更高的要求，而背後是對個體與團隊的協作效能有着更高的訴求。
專人專崗的協作模式在進一步改善團隊的協作效能時所面臨的最大挑戰在于“崗位牆”，即崗位間銜接不可避免會出現一些模糊地帶，而這些模糊地帶又很容易互相忽視，導緻失去關注而很大程度地拉低了團隊效能。比如，開發工程師會認為保證品質是測試工程師單方面的職責；開發工程師不關注使用者體驗而隻需關注實作需求，等等。此外，這種協作模式也會固化個體的思維和心智模式，将個體的思維和心智框定在所處崗位之内，以緻對于崗位之外的内容不能很好地了解，使得個體在整個協作活動中會缺乏同理心、系統性，進而影響工作幸福感。
相信這些現實工作場景讀者并不陌生：
開發工程師對産品工程師所提出的使用者體驗方面的需求會認為過于吹毛求疵；
産品工程師因不了解技術的實作原理而提出天馬行空、不接地氣的需求（我們在此不讨論創新這一特例）；
測試工程師因為不了解工程效率的内涵而将自己的工作變成了體力活；
開發工程師不清楚自己對于軟體品質的責任，而将那些本因自己做好的瑣碎工作心安理得地交給測試工程師去做；
辛辛苦苦所開發出來的功能，使用者抱怨難用。
這些問題發生的最終結果，一定是團隊協作效能的低下。那麼在沒有找到比專人專崗更好的協作模式的情形下，我們該如何發揮個體的力量去改善團隊的協作效能呢？改善的起點在于全面地梳理工程師思維，幫助工程師個體在職場和職業發展中建立起更為全面的思維和視野，以促使每個工程師在協作過程中能最大程度地發揮個體能力去推動團隊協作效能的提升。
我将工程師思維分解為産品、技術和工程三大思維。每個次元主要關注的内容通過幾個關鍵字去表達，如下圖所示。下面針對每種思維需要關注的每個詞以圖中從上至下的順序去解釋。由于解釋是基于關鍵詞去展開的，是以段落之間的銜接可能會顯得生硬，還請讀者見諒。
産品思維
産品思維的起源是使用者（或客戶）價值。使用者價值是通過技術手段以産品或服務的形态去解決使用者的痛點，或帶去爽點。毫無疑問，工程師在日常工作中應時刻關注并理清自己的工作與使用者（或客戶）價值的聯系，并且應該通過聚焦于使用者價值去安排工作的優先級和配置設定自己的精力。
當使用者價值足夠時，産品能否在市場中立足并真正收獲收益，首先考驗的是産品的使用者體驗。良好的使用者體驗一定是站在使用者的角度，基于使用者心智來塑造概念，由于概念存在了解和解釋成本，是以塑造的概念應足夠輕、少且易掌握。概念一旦塑造出來則概念間的關系也随之确定，這些關系基本上決定了産品與使用者的互動流程。好的産品展現于“易用”二字，其極緻在于迎合使用者的本能反應并符合各種生活或專業常識。
所有産品都存在演進的過程，所創造的使用者價值也在被不斷地挖掘與探索，那時不同的細化價值需要通過産品特性去區分和表達。特性也是産品差異化的一種展現，特性也間接地确定了軟體實作層面的功能子產品邊界。作為開發工程師，也需要對産品特性有非常透徹的了解，并能将其很好地抽象并轉化為軟體實作層面的功能子產品。特性需要考慮通過售賣license等形式進行開啟或關閉去實作售賣，這一點對于2B的産品甚是必要。
為了産品更好地演進，需要通過資料閉環的形式去檢驗創造使用者價值的效果，讓産品的開發、營運、營銷工作做到有的放矢。在産品價值創造的道路上，最害怕的事莫過于隻顧低頭幹做加法，做得多卻無人關心收效。而我們通過資料化閉環的形式，不僅能讓整個産品大團隊聚焦于核心價值，還能幫助團隊在探索使用者價值的道路上理性地做減法。大多情形下，做減法遠難于做加法。
技術思維
技術思維的源頭是需求。需求可以分成市場需求、系統需求、特性需求等不同層次，回答的是技術層面“做什麼”的問題。顯然，清晰表達的需求以及對需求的精确了解才能確定将事做對。毋容置疑，需求一旦出現偏差所導緻的浪費是非常嚴重的，也正因如此工程師對于需求的品質相當重視。
需求一旦确立，會基于子產品化的思想拆分成多個功能子產品去降低實作的局部複雜度，最終将所有功能子產品“拼接”在一起去實作整體需求。每個功能子產品會安排給一個人或一個團隊負責，由于功能子產品是需求分解後的産物，容易導緻工程師在實作的過程中隻看到“樹木”而忘記了“森林”。
性能是工程師在實作一個功能子產品時不得不關注的，特别是當功能子產品被運用于高頻、時效性敏感、算力有限的場合時性能将尤其被關注。在現實中有時會存在工程師樂于追求性能的極緻去展現自己的技術實力，甚至出現過早追求性能而滑入過度設計的誤區。
毫無疑問，一個正規的團隊，對于功能子產品的開發工作多會以項目制、多個疊代的方式去完成傳遞。不少工程師這裡會有一個誤區，忘記了靈活思想所倡導的“項目計劃的目的是為了适應變化”，而是将“按時傳遞”當作是天職，各種趕工爬到終點時卻毫不意外地看到了“一地雞毛”的景象。
在邁向第四次工業革命的道路上，人工智能、大資料、機器學習，Kubernetes、Istio、Knative、Go、Dart、Flutter等新技術不斷沖擊着工程師已掌握的技能。快速跟上技術的疊代步伐是每個有追求的工程師不斷提升自己專業素養的表現之一。工程師的内心一定不缺乏對新技術的追求，憧憬自己所掌握的技術具有一定的先進性。
工程思維
工程思維的起點是流程。流程的背後是科學，以既定的步驟、階段性的輸入/輸出去完成價值創造，通過過程控制確定最終結果讓人滿意。由于流程涉及每一個工程師的工作品質與效率，其含義不隻在于定義、工具化、檢查等内容，而是應基于工程師的日常工作習慣，将流程與工程師的工作環境無縫整合。“無縫”展現于流程中的概念與工程師群體已建立的專業常識相一緻、沒有增加毫無價值的負擔，根本仍是確定易用性。
機制的含義是通過對所需解決問題的分析，以一種模式去解決同類問題。機制應展現一定的系統性，而非“頭痛治頭，腳痛治腳”。系統性不是一開始就能被洞察到，可能在演進的過程中逐漸發現和完善的，因而需要工程師在工作的過程中不時回顧并付諸實踐去落實。對于工程師來說，機制是通過系統性的軟體設計去達成的。
可以說産品品質直接決定了工程師的工作和生活幸福感。一個品質不可靠的産品一定會給使用者和工程師自己帶去麻煩，甚至造成無法挽回的經濟損失并造成負面的社會影響。對于工程師來說，那勢必打亂個體的工作與生活節奏。為了讓産品的品質做到可靠，單元測試、靜态分析、動态分析等確定工程品質的手段應成為工程師的基本工作内容，通過将這些手段與CI（Continuous Integration）流程進行整合去持續建構起對軟體産品的品質信心。
在網際網路行業，除了軟體産品的品質得可靠外，風險可控是另一個不能忽視的内容。而風險可控是建立于系統性機制和品質可靠之上的。對于服務端軟體來說愈是如此。風險往往出現于資源使用的極端場景，當從外部湧入的過多事務遠超軟體産品的處理能力時，需要有一定的機制讓整個産品能相對平滑地應對，或是擴充資源、或是限制湧入事務的流量。
軟體所需的機器成本是比較容易忽視的話題，軟體成本不隻與軟體性能相關，還與軟體之間的依賴、技術方案等因素相連。當一個軟體需要從公司的内部對外輸出時，平時忽視對成本的關注就會暴露出成本問題。比如，為了運作某個軟體需要數量龐大的計算資源，所導緻的資金開銷對于客戶來講很可能是無法接受的。
至此，大緻介紹完了自己所了解的工程師思維。
延伸
了解工程師思維的價值在于，工程師個體需要在工作中逐漸建立起産品、技術和工程三大思維，以便用更為全面的視角去看待日常工作中所面臨的困境和困惑。當站在單一的思維去看待所面臨的問題時可能覺得不合理，但從三大思維層面去審視時所得到結論可能完全相反。從團隊協作的角度，隻有團隊中有更多的個體從多元度去進行思考，才容易發現崗位間銜接的那些無人問津的灰色地帶，進而通過補位、助攻去更大程度地發揮團隊的效能。
顯然，不同崗位、不同職責的工程師對于這三大思維的深度要求是不一樣的，但從多元度去思考卻應是每個工程師都應該具備的素養。
最後，我也給讀者留下一些問題，同樣期待您在留言區分享自己的思考。
原文釋出時間為：2018-12-13
本文作者：至簡
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。