產品思維

產品思維的起源是使用者（或客戶）價值。使用者價值是通過技術手段以產品或服務的形態去解決使用者的痛點，或帶去爽點。毫無疑問，工程師在日常工作中應時刻關注並理清自己的工作與使用者（或客戶）價值的聯絡，並且應該通過聚焦於使用者價值去安排工作的優先順序和分配自己的精力。

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

所有產品都存在演進的過程，所創造的使用者價值也在被不斷地挖掘與探索，那時不同的細化價值需要通過產品特性去區分和表達。特性也是產品差異化的一種體現，特性也間接地確定了軟體實現層面的功能模組邊界。作為開發工程師，也需要對產品特性有非常透徹的理解，並能將其很好地抽象並轉化為軟體實現層面的功能模組。特性需要考慮通過售賣license等形式進行開啟或關閉去實現售賣，這一點對於2B的產品甚是必要。

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

技術思維

技術思維的源頭是需求。需求可以分成市場需求、系統需求、特性需求等不同層次，回答的是技術層面“做什麼”的問題。顯然，清晰表達的需求以及對需求的精確理解才能確保將事做對。毋容置疑，需求一旦出現偏差所導致的浪費是非常嚴重的，也正因如此工程師對於需求的質量相當重視。

需求一旦確立，會基於模組化的思想拆分成多個功能模組去降低實現的區域性複雜度，最終將所有功能模組“拼接”在一起去實現整體需求。每個功能模組會安排給一個人或一個團隊負責，由於功能模組是需求分解後的產物，容易導致工程師在實現的過程中只看到“樹木”而忘記了“森林”。

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

毫無疑問，一個正規的團隊，對於功能模組的開發工作多會以專案制、多個迭代的方式去完成交付。不少工程師這裡會有一個誤區，忘記了敏捷思想所倡導的“專案計劃的目的是為了適應變化”，而是將“按時交付”當作是天職，各種趕工爬到終點時卻毫不意外地看到了“一地雞毛”的景象。

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

工程思維

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

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

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

在網際網路行業，除了軟體產品的質量得可靠外，風險可控是另一個不能忽視的內容。而風險可控是建立於系統性機制和質量可靠之上的。對於服務端軟體來說愈是如此。風險往往出現於資源使用的極端場景，當從外部湧入的過多事務遠超軟體產品的處理能力時，需要有一定的機制讓整個產品能相對平滑地應對，或是擴充資源、或是限制湧入事務的流量。

軟體所需的機器成本是比較容易忽視的話題，軟體成本不只與軟體效能相關，還與軟體之間的依賴、技術方案等因素相連。當一個軟體需要從公司的內部對外輸出時，平時忽視對成本的關注就會暴露出成本問題。比如，為了執行某個軟體需要數量龐大的計算資源，所導致的資金開銷對於客戶來講很可能是無法接受的。

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

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