在社會(huì)分工的背景下，軟件行業(yè)的工程師群體被劃分成了開發(fā)、測試、產(chǎn)品等諸多崗位，以協(xié)作的方式共同完成價(jià)值創(chuàng)造。高度依賴軟件的互聯(lián)網(wǎng)行業(yè)正以全新的方式改善著人們的生活，同時(shí)在改善的道路上對價(jià)值創(chuàng)造的效能提出了更高的要求，而背后是對個(gè)體與團(tuán)隊(duì)的協(xié)作效能有著更高的訴求。

專人專崗的協(xié)作模式在進(jìn)一步改善團(tuán)隊(duì)的協(xié)作效能時(shí)所面臨的最大挑戰(zhàn)在于“崗位墻”，即崗位間銜接不可避免會(huì)出現(xiàn)一些模糊地帶，而這些模糊地帶又很容易相互忽視，導(dǎo)致失去關(guān)注而很大程度地拉低了團(tuán)隊(duì)效能。比如，開發(fā)工程師會(huì)認(rèn)為保證質(zhì)量是測試工程師單方面的職責(zé)；開發(fā)工程師不關(guān)注用戶體驗(yàn)而只需關(guān)注實(shí)現(xiàn)需求，等等。此外，這種協(xié)作模式也會(huì)固化個(gè)體的思維和心智模式，將個(gè)體的思維和心智框定在所處崗位之內(nèi)，以致對于崗位之外的內(nèi)容不能很好地理解，使得個(gè)體在整個(gè)協(xié)作活動(dòng)中會(huì)缺乏同理心、系統(tǒng)性，從而影響工作幸福感。

相信這些現(xiàn)實(shí)工作場景讀者并不陌生：

開發(fā)工程師對產(chǎn)品工程師所提出的用戶體驗(yàn)方面的需求會(huì)認(rèn)為過于吹毛求疵；

產(chǎn)品工程師因不理解技術(shù)的實(shí)現(xiàn)原理而提出天馬行空、不接地氣的需求（我們在此不討論創(chuàng)新這一特例）；

測試工程師因?yàn)椴焕斫夤こ绦实膬?nèi)涵而將自己的工作變成了體力活；

開發(fā)工程師不清楚自己對于軟件質(zhì)量的責(zé)任，而將那些本因自己做好的瑣碎工作心安理得地交給測試工程師去做；

辛辛苦苦所開發(fā)出來的功能，用戶抱怨難用。

這些問題發(fā)生的最終結(jié)果，一定是團(tuán)隊(duì)協(xié)作效能的低下。那么在沒有找到比專人專崗更好的協(xié)作模式的情形下，我們該如何發(fā)揮個(gè)體的力量去改善團(tuán)隊(duì)的協(xié)作效能呢？改善的起點(diǎn)在于全面地梳理工程師思維，幫助工程師個(gè)體在職場和職業(yè)發(fā)展中建立起更為全面的思維和視野，以促使每個(gè)工程師在協(xié)作過程中能最大程度地發(fā)揮個(gè)體能力去推動(dòng)團(tuán)隊(duì)協(xié)作效能的提升。

我將工程師思維分解為產(chǎn)品、技術(shù)和工程三大思維。每個(gè)維度主要關(guān)注的內(nèi)容通過幾個(gè)關(guān)鍵字去表達(dá)，如下圖所示。下面針對每種思維需要關(guān)注的每個(gè)詞以圖中從上至下的順序去解釋。由于解釋是基于關(guān)鍵詞去展開的，所以段落之間的銜接可能會(huì)顯得生硬，還請讀者見諒。

產(chǎn)品思維

產(chǎn)品思維的起源是用戶（或客戶）價(jià)值。用戶價(jià)值是通過技術(shù)手段以產(chǎn)品或服務(wù)的形態(tài)去解決用戶的痛點(diǎn)，或帶去爽點(diǎn)。毫無疑問，工程師在日常工作中應(yīng)時(shí)刻關(guān)注并理清自己的工作與用戶（或客戶）價(jià)值的聯(lián)系，并且應(yīng)該通過聚焦于用戶價(jià)值去安排工作的優(yōu)先級和分配自己的精力。

當(dāng)用戶價(jià)值足夠時(shí)，產(chǎn)品能否在市場中立足并真正收獲收益，首先考驗(yàn)的是產(chǎn)品的用戶體驗(yàn)。良好的用戶體驗(yàn)一定是站在用戶的角度，基于用戶心智來塑造概念，由于概念存在理解和解釋成本，所以塑造的概念應(yīng)足夠輕、少且易掌握。概念一旦塑造出來則概念間的關(guān)系也隨之確定，這些關(guān)系基本上決定了產(chǎn)品與用戶的交互流程。好的產(chǎn)品體現(xiàn)于“易用”二字，其極致在于迎合用戶的本能反應(yīng)并符合各種生活或?qū)I(yè)常識(shí)。

所有產(chǎn)品都存在演進(jìn)的過程，所創(chuàng)造的用戶價(jià)值也在被不斷地挖掘與探索，那時(shí)不同的細(xì)化價(jià)值需要通過產(chǎn)品特性去區(qū)分和表達(dá)。特性也是產(chǎn)品差異化的一種體現(xiàn)，特性也間接地確定了軟件實(shí)現(xiàn)層面的功能模塊邊界。作為開發(fā)工程師，也需要對產(chǎn)品特性有非常透徹的理解，并能將其很好地抽象并轉(zhuǎn)化為軟件實(shí)現(xiàn)層面的功能模塊。特性需要考慮通過售賣license等形式進(jìn)行開啟或關(guān)閉去實(shí)現(xiàn)售賣，這一點(diǎn)對于2B的產(chǎn)品甚是必要。

為了產(chǎn)品更好地演進(jìn)，需要通過數(shù)據(jù)閉環(huán)的形式去檢驗(yàn)創(chuàng)造用戶價(jià)值的效果，讓產(chǎn)品的開發(fā)、運(yùn)營、營銷工作做到有的放矢。在產(chǎn)品價(jià)值創(chuàng)造的道路上，最害怕的事莫過于只顧低頭干做加法，做得多卻無人關(guān)心收效。而我們通過數(shù)據(jù)化閉環(huán)的形式，不僅能讓整個(gè)產(chǎn)品大團(tuán)隊(duì)聚焦于核心價(jià)值，還能幫助團(tuán)隊(duì)在探索用戶價(jià)值的道路上理性地做減法。大多情形下，做減法遠(yuǎn)難于做加法。

技術(shù)思維

技術(shù)思維的源頭是需求。需求可以分成市場需求、系統(tǒng)需求、特性需求等不同層次，回答的是技術(shù)層面“做什么”的問題。顯然，清晰表達(dá)的需求以及對需求的精確理解才能確保將事做對。毋容置疑，需求一旦出現(xiàn)偏差所導(dǎo)致的浪費(fèi)是非常嚴(yán)重的，也正因如此工程師對于需求的質(zhì)量相當(dāng)重視。

需求一旦確立，會(huì)基于模塊化的思想拆分成多個(gè)功能模塊去降低實(shí)現(xiàn)的局部復(fù)雜度，最終將所有功能模塊“拼接”在一起去實(shí)現(xiàn)整體需求。每個(gè)功能模塊會(huì)安排給一個(gè)人或一個(gè)團(tuán)隊(duì)負(fù)責(zé)，由于功能模塊是需求分解后的產(chǎn)物，容易導(dǎo)致工程師在實(shí)現(xiàn)的過程中只看到“樹木”而忘記了“森林”。

性能是工程師在實(shí)現(xiàn)一個(gè)功能模塊時(shí)不得不關(guān)注的，特別是當(dāng)功能模塊被運(yùn)用于高頻、時(shí)效性敏感、算力有限的場合時(shí)性能將尤其被關(guān)注。在現(xiàn)實(shí)中有時(shí)會(huì)存在工程師樂于追求性能的極致去體現(xiàn)自己的技術(shù)實(shí)力，甚至出現(xiàn)過早追求性能而滑入過度設(shè)計(jì)的誤區(qū)。

毫無疑問，一個(gè)正規(guī)的團(tuán)隊(duì)，對于功能模塊的開發(fā)工作多會(huì)以項(xiàng)目制、多個(gè)迭代的方式去完成交付。不少工程師這里會(huì)有一個(gè)誤區(qū)，忘記了敏捷思想所倡導(dǎo)的“項(xiàng)目計(jì)劃的目的是為了適應(yīng)變化”，而是將“按時(shí)交付”當(dāng)作是天職，各種趕工爬到終點(diǎn)時(shí)卻毫不意外地看到了“一地雞毛”的景象。

在邁向第四次工業(yè)革命的道路上，人工智能、大數(shù)據(jù)、機(jī)器學(xué)習(xí)，Kubernetes、Istio、Knative、Go、Dart、Flutter等新技術(shù)不斷沖擊著工程師已掌握的技能。快速跟上技術(shù)的迭代步伐是每個(gè)有追求的工程師不斷提升自己專業(yè)素養(yǎng)的表現(xiàn)之一。工程師的內(nèi)心一定不缺乏對新技術(shù)的追求，憧憬自己所掌握的技術(shù)具有一定的先進(jìn)性。

工程思維

工程思維的起點(diǎn)是流程。流程的背后是科學(xué)，以既定的步驟、階段性的輸入/輸出去完成價(jià)值創(chuàng)造，通過過程控制確保最終結(jié)果讓人滿意。由于流程涉及每一個(gè)工程師的工作質(zhì)量與效率，其含義不只在于定義、工具化、檢查等內(nèi)容，而是應(yīng)基于工程師的日常工作習(xí)慣，將流程與工程師的工作環(huán)境無縫整合。“無縫”體現(xiàn)于流程中的概念與工程師群體已建立的專業(yè)常識(shí)相一致、沒有增加毫無價(jià)值的負(fù)擔(dān)，根本仍是確保易用性。

機(jī)制的含義是通過對所需解決問題的分析，以一種模式去解決同類問題。機(jī)制應(yīng)體現(xiàn)一定的系統(tǒng)性，而非“頭痛治頭，腳痛治腳”。系統(tǒng)性不是一開始就能被洞察到，可能在演進(jìn)的過程中逐步發(fā)現(xiàn)和完善的，因而需要工程師在工作的過程中不時(shí)回顧并付諸實(shí)踐去落實(shí)。對于工程師來說，機(jī)制是通過系統(tǒng)性的軟件設(shè)計(jì)去達(dá)成的。

可以說產(chǎn)品質(zhì)量直接決定了工程師的工作和生活幸福感。一個(gè)質(zhì)量不可靠的產(chǎn)品一定會(huì)給用戶和工程師自己帶去麻煩，甚至造成無法挽回的經(jīng)濟(jì)損失并造成負(fù)面的社會(huì)影響。對于工程師來說，那勢必打亂個(gè)體的工作與生活節(jié)奏。為了讓產(chǎn)品的質(zhì)量做到可靠，單元測試、靜態(tài)分析、動(dòng)態(tài)分析等確保工程質(zhì)量的手段應(yīng)成為工程師的基本工作內(nèi)容，通過將這些手段與CI（Continuous Integration）流程進(jìn)行整合去持續(xù)構(gòu)建起對軟件產(chǎn)品的質(zhì)量信心。

在互聯(lián)網(wǎng)行業(yè)，除了軟件產(chǎn)品的質(zhì)量得可靠外，風(fēng)險(xiǎn)可控是另一個(gè)不能忽視的內(nèi)容。而風(fēng)險(xiǎn)可控是建立于系統(tǒng)性機(jī)制和質(zhì)量可靠之上的。對于服務(wù)端軟件來說愈是如此。風(fēng)險(xiǎn)往往出現(xiàn)于資源使用的極端場景，當(dāng)從外部涌入的過多事務(wù)遠(yuǎn)超軟件產(chǎn)品的處理能力時(shí)，需要有一定的機(jī)制讓整個(gè)產(chǎn)品能相對平滑地應(yīng)對，或是擴(kuò)充資源、或是限制涌入事務(wù)的流量。

軟件所需的機(jī)器成本是比較容易忽視的話題，軟件成本不只與軟件性能相關(guān)，還與軟件之間的依賴、技術(shù)方案等因素相連。當(dāng)一個(gè)軟件需要從公司的內(nèi)部對外輸出時(shí)，平時(shí)忽視對成本的關(guān)注就會(huì)暴露出成本問題。比如，為了運(yùn)行某個(gè)軟件需要數(shù)量龐大的計(jì)算資源，所導(dǎo)致的資金開銷對于客戶來講很可能是無法接受的。

至此，大致介紹完了自己所理解的工程師思維。

延伸

了解工程師思維的價(jià)值在于，工程師個(gè)體需要在工作中逐步建立起產(chǎn)品、技術(shù)和工程三大思維，以便用更為全面的視角去看待日常工作中所面臨的困境和困惑。當(dāng)站在單一的思維去看待所面臨的問題時(shí)可能覺得不合理，但從三大思維層面去審視時(shí)所得到結(jié)論可能完全相反。從團(tuán)隊(duì)協(xié)作的角度，只有團(tuán)隊(duì)中有更多的個(gè)體從多維度去進(jìn)行思考，才容易發(fā)現(xiàn)崗位間銜接的那些無人問津的灰色地帶，進(jìn)而通過補(bǔ)位、助攻去更大程度地發(fā)揮團(tuán)隊(duì)的效能。

顯然，不同崗位、不同職責(zé)的工程師對于這三大思維的深度要求是不一樣的，但從多維度去思考卻應(yīng)是每個(gè)工程師都應(yīng)該具備的素養(yǎng)。