[[343284]]

今天這篇文章準備整理下我原來談過的和技術人員相關的思維方面的話題，整個內容實際上包括兩個方面。其一是我們可以從開發和技術中借鑒哪些思維方式；其二是技術人員本身不要受限于技術中，而應該跳出盒子培養價值驅動下的經營思維。

從編程思維談起

編程思維的本質究竟是什么？

談編程不可避免的要談到編程語言，而編程語言之所以出現，其最終的目的仍然是 提供一種抽象方法來解決現實中的問題 ，問題本身的復雜程度往往取決于抽象的種類和質量。

從匯編語言的出現解決了最初的抽象，而類似c或fortran語言出現則可以看做是對匯編語言的進一步抽象。這一步抽象的完成其實是很重要的一個進步，即我們在解決問題的時候不再需要關系復雜的機器模型或機器碼，而是可以更多的關注問題和解決方案本身。

在這個階段，從 編程本身來說最核心的還是算法和數據結構 。這也是任何程序最重要的兩個基本要素。既把問題域本身涉及到的數據映射到合適的數據結構，把通過程序解決問題的過程映射為具體的算法邏輯。

那么編程實際的難點在哪？

不是算法本身或數據結構本身，而是 當你拿到問題域的時候知道如何理解和分解問題，并將其映射到最適合的算法或數據結構上 。這個映射其實本身不是程序解決的問題，還是人腦在思維，程序本身僅僅是在實現自動化的過程。

那么程序在算法實現過程中最基本的是什么？

我們看不同的程序片段可以看到的還是if/else，或者for/while，然后才是數據或數據類型定義。而前者即寫任何一個程序中最重要的控制邏輯。那么編程里難的實際上不是控制語句本身，而是在把問題域分解后知道如何理解判斷邏輯，如何將問題域中重復的東西抽象為循環，如何從問題域中抽象出數據結構。

一個人編程能力本身的好壞，或者說編程思維能力，重點其實是體現在這種映射能力，也可以稱這種映射能力為數學建模能力。

舉個例子來說，如果一個問題你已經知道了可以映射到構建二叉樹，然后通過遍歷的方式來解決了，那么可以說然后一個掌握了語言語法的人都可以寫出程序來。那么實際編程思維或能力的強弱則在于前面談到的映射和建模。

對現實世界的抽象理解，從抽象歸納到演繹泛化

面向對象思想和面向對象編程語言的出現，可以說也是編程思維本身的第二次重大提升。

即原有的編程語言可以看到我們關注更多的已經是抽象后的解決方案，而面向對象的編程語言則首先關注的是通過類，通過繼承，通過接口定義等首先對現實世界進行很好的抽象描述，其次才是如何去解決問題。現實世界中所有的一切都是對象，而面向對象語言中的類本身就是對現實世界中對象的很好的抽象。

對于面向對象的核心特征談的比較多的是封裝，繼承和多態。這些可能比較偏技術詞匯，那么再簡單點來說面向對象編程思維其核心則是 找到問題域中的對象，將其抽象為類，識別類應該有的屬性和方法特征，同時去理清類和類之間的關聯和交互關系，將問題本身的解決過程映射到類和類之間的方法交互上。

如果從這個意義上來說，好像也不是很復雜，那么實際面向對象編程的難點實際在為了保持代碼足夠的健壯性，可維護性，可擴展性而做出的各種抽象，包括接口的提取和組合，控制或邏輯類的增加等，這些本質已經轉換到技術域類本身。

另外編程里面有一個重要的思想即是復用 ，從最簡單的函數，到模版庫，類庫，再到更上層的公共組件等，都在體現復用的思想，而復用本身的目的則主要是提升開發效率，提升可維護性和代碼的可讀性等。復用可以理解為編程過程中的編程思想更加恰當。

編程的思想是自動化 ，不要簡單的理解為編程語言能夠幫助你解決建模和映射的難題，編程的自動化更多的還是體現在機器可以自動化的進行大量計算和運算，而這個運算是通過我們的程序進行的。程序中體現的一個重點我更喜歡把它理解為循環，從抽象中去發現一種可自動化的循環，這種循環的處理正是程序的強項。

任何人都應該有這種自動化的編程思維，即懶人思維，重復的事情一定不要手工重復完成。

架構思維

前面談了編程思維，里面談到了抽象，復用，自動化等關鍵內容。

接著再談下架構思維，對于架構思維本身仍然是類似系統思維，結構化思維，編程思維等諸多思維模式的一個合集。由于架構的核心作用是在業務現實世界和抽象的IT實現之間建立起一道橋梁，因此架構思維最核心的就是要理解 業務驅動技術，技術為最終的業務服務。要真正通過架構設計來完成業務和技術，需求和實現，軟件和硬件，靜態和動態，成本和收益等多方面的平衡。

分解是最基礎的 ，架構的重點就是要對復雜問題進行分而治之，同時保證分解后的各個部分還能夠高內聚，松耦合，最終又集成為一個完整的整體。分解核心是定義問題，因此架構首先仍然需要理解清楚需求。

集成是配合分解完成的動作 ，最終分解完成的各個組件或子系統，通過合適的接口設計，最終還能夠集成為一個完整的整體，分解僅僅是加速開發和降低問題復雜度，如果分解后的內容無法集成在一起，那么分解就沒有任何意義。

分解+集成可以理解為架構最核心的思考方式和方法。

動態+靜態： 一直是我強調的重要思維模式，架構思考里面一定要注意這兩者的結合，即涉及到流程，用例等動態分析內容，又涉及到數據，類等靜態建模內容，而是兩者要高度協作起來完成整個架構思考。

復用是另外一個重要的思維 ，也可以理解為SOA參考架構的核心思考模式，包括最近談的最多的業務能力組件化，組件能力服務化，平臺+應用，共享中心建設，共性能力下沉等都是談的復用的概念。即使你架構設計一個小系統，你也需要將各個模塊需要用的共性功能抽取為可復用的共性組件。

分層相對重要，架構在設計中要考慮分層，而核心仍然是資源+服務+應用的三大層 ，分為這三層仍然是SOA參考架構的核心思想。對于平臺+應用更多只是上面分層模式的一個變形。分層的目的是通過分層既理清了整個應用的構建過程，又保證了各層之間的獨立設計和松耦合。

模式匹配： 可以講是所有思維模式里面的一個重點，而架構設計中的模式匹配就是要將最終的業務域問題匹配到對應的技術實現上面。即根據業務需求來挑選最適合的技術，而不是用主流和最先進的技術去反推業務。

抽象是架構思維里面的一個重點 ，這里面包括了兩個層面的內容，一個是常說的歸納方法，即各種類似場景的實現見的太多了，自然就歸納了一個規則或方法出來供以后的設計用。但是抽象更加重要，即將非類似場景中的共性內容也總結出來，進一步抽象為類似的東西，以更加方便的適應變更和各種變化。

結構化思維是架構思維必須具備的 ，最常用的兩種結構就是二維的表格和樹模型，通過結構化思維引入了維度和XY概念后，可以幫助我們更好的分析和比對，結構化決策等。對于多維模型，我們也要有意識的將其轉換為多個平面二維模型，方便我們進行分析。

迭代思維是架構思考中需要考慮的另外一個重要內容 ，沒有最優的架構，只有不斷進化的架構，只有最適合的架構。因此架構本身也在隨著業務需求的變化不斷的迭代和演化，而不是追求用最新的技術一步到位。

最后即我們常說的系統思維 ，系統思維是架構思維中最重要的思維模式，一個架構師必須要有充分的全局思考的能力，做好前面談到各種平衡，追求整體的最優化而不是單個目標的最優。

從架構思維到大架構觀培養

要成為架構師，大量的項目和設計編碼積累是必須的，而且這種編碼積累還不能是簡單重復，還是必須得有抽象，復用等各種思維，不斷重構的設計意識。走的路多了，各種業務到實現的匹配方式驗證的多了，各種大型項目經歷和解決復雜問題多了，你自然就有了這種能力。

一個架構，很多時候并不是說創新或學習能力就有多強，而是他們的實踐經驗積累的知識庫很強大，見多才能夠識廣，大量的模式匹配庫隨時可以使用，而對于一般人你經常發出的感慨就是我怎么沒有想到那里去？知識經驗庫很值錢，但是這個是長期大量的實踐換來的，投入的是大量的時間和金錢成本。

經驗庫的積累一定是知識理論到實踐，再到總結復盤，再到抽象形成在自己腦海里面的。這個過程本身就是循序漸進，反復迭代，并沒有什么捷徑可走。

而今天談大架構觀，那么首先還是說的架構思維，對于架構思維即前面談到的 分解，集成，抽象，復用，組合，系統化等多方面的思維能力 ，這些思維能力都相當重要，但是本質都是我們看待和理解事物的方式。

大架構觀本質就是我們如何看待和理解一個產品，那么最終這個產品的實現就是按照你理解或建模的方式進行開發和產出。所有產品后期可能出現的問題都可能是我們理解出現了問題。

架構首先要解決的是 產品內部組件如何高效協同，產品和外圍系統間如何高效協同并滿足業務和用戶需求的問題 。這就是最基本的功能性需求，架構必須要搭建這種業務場景和需求和最終產品實現之間的橋梁。這么多年下來，我們還是發現，很多人對架構的理解有很大的偏差。

即我會用多層框架了就是J2EE架構師，會用SpringCloud了就是微服務架構師，會Hadoop了就是大數據架構師，這是對架構一個巨大的誤解。能夠基于開源項目或框架來搭建一個基礎開發平臺確實是一個架構師應該具備的基本能力，但是這個能力僅僅是架構能力很小的一部分，因為技術框架不是業務需求，而實現在技術框架上的業務功能組件才能夠滿足業務需求。

在業務需求沒有最終實現前，技術框架本身并沒有得到充分的驗證，也沒有和最終的業務需求匹配，這種空框架搭建并沒有很高的技術含量。

或者說 大部分人將架構理解為技術架構，而忽視了業務抽象和建模能力 ，但是脫離業務的技術架構，連自己都無法驗證最終架構原型對現實業務的支撐能力，即架構師最終設計的東西無法自己進行實證，這本身就是一個要命的事情。架構師變成了紙上談兵，設計的模型變成了空中樓閣，這顯然不是我們想要的。

一個好的架構師，應該是給出在當前業務場景和需求下，最合理的架構模型設計 ，而不是什么理想化的模型，什么網上順手搬來的現成架構模型。架構師追求的不是理想化，而是當下最合理。

我們如何分析和理解產品，這里的大架構觀的一個重點就是能夠深入細節又能夠跳出盒子的雙重思維， 既能夠宏觀全局又能夠微觀局部，既能夠分解又能夠集成回去 。既追根究底又不求甚解，置身產品之中又能夠跳出產品做用戶視角的思考。要具備這種架構能力，需要的是業務建模，業務到技術分解轉化能力，隨時都是業務和需求導向，技術為需求服務。沒有盲目的技術堆積，只有合理的技術采用。沒有理想化的模型，只有驗證過的技術。

一個好的架構一定是 同時解決功能性架構和非功能性架構兩方面的問題 。

而非功能性架構包括了可靠性，性能，高可用性，高擴展性等多方面的內容。這些都需要架構師在搭建模型的時候進行考慮，好的架構就是穩如泰山，靈活擴展，具備彈性的以不變應萬變的能力。好的架構就是充分考慮到各種異常邊界，并發峰值，安全攻擊等場景下，系統仍然能夠平穩可靠運行。

不論出現任何的突發情況，產品都能夠靈活應對，這往往就是靠的架構師設計產品時候的架構能力。就如建造一座高樓，外部上看上去都一模一樣，但是有的高樓刮大風都能夠吹倒，但是有些高樓卻能夠扛住10級地震，這要的就是內功積累，否則就是繡花枕頭。

越是復雜的業務，往往構建的業務系統和架構設計也就越復雜，但是對于架構師而言一定要意識到， 任何架構的復雜性都應該作為黑盒，屏蔽在架構設計內部 。即架構的復雜性應該在架構設計的時候被隱藏掉，通過粗粒度的接口將這種復雜性屏蔽在內部。即對于最終的開發人員往往并不需要關心這些復雜性，而只是按照架構原則和開發指南進行開發即可。這本身也是架構設計的一個重要考慮點。

大架構觀，本質就是我們分析和理解事物的思維觀 。

而架構本身解決的是從業務需求到技術實現間的關鍵銜接，而這個銜接的呈現是模型，解決的關鍵問題是抽象。大架構觀，既需要我們通過分解和集成來理解事物的組成和內部運作協同機制，更加重要的是需要我們跳出盒子來看待整個事物或產品的運行。

從開發和技術實踐中可以借鑒哪些思維？

在前面我一直在強調思維中最重要的是模式匹配，今天接著這個話題展開談下從開發和技術實踐中類似SOA，面向對象等技術思想中可以借鑒的思維方式。

從緊耦合到松耦合(解耦的最終目的是靈活組裝和匹配）

在軟件設計開發里面，我們經常會談到松耦合和解耦，其原因就是今年保證各個模塊充分自治，受外部其它模塊影響最小。而在SOA架構里面如果談到松耦合，其核心的原因是松耦合是進行靈活組合和編排的基礎。

思維的最終目的是解決問題，當我們面對一個具體的問題解決后，就有了問題和解決方法：

問題A-》解決方法A

那可能在我們頭腦里面就存儲了這么一個關系，即遇到問題A用解決方法A去解決。

如果我們頭腦里面都是去存儲這種信息，那就是我們說的緊耦合，試想一下問題成千上萬，我們得存儲多少解決方法和知識點？這種窮盡和大量記憶存儲的方法顯然是不現實的。那我們實際要做什么呢？即將解決方法分解為細粒度知識點。

問題A-》解決方法A（知識點A1, 知識點A2,知識點A3）

即任何問題的解決都是已有的知識點的組合和組裝。問題和知識點之間是完全松耦合的，而解決方法只是知識點的靈活組合而已。我們只要有了最基本的知識點，就不怕任何形式的問題。

就類似我前面談售前技術建議書一樣，客戶的招標要求千差萬別，但是你只要有了（業務方案，技術方案，部署方案，實施方案，運維，人員，案例，報價單模板）等基礎知識點，你就可以應對所有的售前方案，你唯一需要做的就是將客戶的招標要求或需求分解為一個個的需求點，同時將這些需求點映射到你已有的知識點上。

通過解耦，我們沒必要去存儲和記憶大量粗粒度的解決方案內容，我們只需要關系問題能否分解到已有的知識點上，只需要培養知識點如何根據問題進行組裝和編排的能力即可。也正是這個原因，任何一個問題解決后，你都要思考有哪些可復用的知識點可以入你的知識庫，而不是將該問題的解決方法入庫存儲。

從靜態到動態（動態的目的是知其然并知其所以然）

第二點我們想談的是從靜態到動態，因為最近我們在做PPT匯報材料評審的時候發現一個關鍵問題，即靜態內容多，而動態內容少，講最終結果多而講分析過程少。

在講PPT制作的時候我曾經談到過，對于PPT的呈現只有兩類，一類是動態呈現（階段，流程，活動，演進），一類是靜態呈現（組成，架構）等。而這兩類呈現必須相互結合，相對來說動態呈現更加重要，只有動態呈現能夠說明一個事物實際內部各個組件之間是如何運作的，而只有了解了內部運作你才可能洞悉事物內部機理。

從PPT的呈現回到我們思維邏輯上也是同樣的道理。

當我們去了解任何一個事物的時候，一定要注意前期我們可能只是了解下事物的結構和組成，但是如果你真想去深入了解事物，那么就必須從這種靜態的組成轉變到對動態的組成過程的研究。即事物是如何動態發展演進到當前這個結構的？只有這樣你才能夠洞悉事物內部各個組件之間是如何協調運作的。

我們平時太注重結果，而忘記了對這種科學思考過程的關注。而實際上再好的結果本身都不具備可復制性，而只有科學的思考過程和方法本身是可以復制的。你得出一個好的結果不代表你就很牛逼，中間有很多偶然性；但是當你自我論證是通過很好的方法和過程，得出了這么一個結果，那這種過程本身就具備了舉一反三能力。

原來我寫過一篇文章，談搜索引擎之毒，為啥這樣談？所有千奇百怪的問題，你到互聯網一搜馬上就搜索到答案并解決掉了，那么這個時候你不會再去深究回答者是如何進行問題分析和思考而得出答案的，即你隨時搜索到了答案，但是你沒學會是思考和解決問題的方法。

從靜態答案到去尋找答案是如何分析出來的，本身也是靜態到動態的過程。

從泛化到抽象（抽象的目的是最小化記憶，并提供為了演繹的入口）

在互聯網時代，當前人和人比較的一定不是記憶能力，而是問題分析和解決能力。而這個能力里面最重要的一點就是 當你拿到問題后，你知道從哪里入手去解決，即問題的入口在哪里。

我原來談到過，互聯網是一個海量的知識庫，每個人都可以獲取到，你自己的電腦里面可能也有一個你自己歸納整理好的大的經驗庫。這么多信息一定是不需要記憶的， 需要記憶的僅僅是能夠通達知識的索引。 通俗點來講就是當問題來了的時候，你知識在哪里拿到最能解決問題的資料。

泛化和抽象，實例和類都是偏IT領域的一些詞匯。但是這些詞對于思維領域同樣適用。你平時看到的東西，實踐的東西，學習到的知識都很多，你需要做的就是進行歸納和抽象，形成你自己的概念模型，形成自己能夠記憶的最小知識集，這個知識集最后就是索引信息。

有了索引我們就能夠按圖索驥。

索引類似于軟件設計中最高的抽象層次，即接口的定義。接口中只有方法，沒有具體的實現。而索引就是這個道理，我們只需要知道不同的問題究竟應該用什么的方法來解決，這個方法究竟是怎么解決的？我們不需要記憶，我們只需要找到我們存儲或網上存儲的資料即可。

不同場景下不同的問題究竟應該用什么樣的方法解決，正是我們在思維里面談到過的，對于一個人最有價值的能力，即模式和方法論。所有的實踐我們都在積累我們自己的模式庫和匹配庫。

比如你原來做開發工作，轉到做軟件需求和業務顧問工作，你的模式庫做一次更新。你從做財務域的顧問，轉到做供應鏈域的顧問，你的模式庫做二次更新，后續再轉域無任何問題。

一生二，二生三，三生萬物，但是萬物沒法全部窮舉和了解，我們要做的是記憶1這個索引。

橫切思維-聚合本身帶來價值

對于AOP即是指可以通過預編譯方式和運行期動態代理實現在不修改源代碼的情況下給程序動態統一添加功能的一種技術。AOP實際是GoF設計模式的延續，設計模式孜孜不倦追求的是調用者和被調用者之間的解耦,提高代碼的靈活性和可擴展性，AOP可以說也是這種目標的一種實現。

AOP編程的核心意圖是將日志記錄，性能統計，安全控制，事務處理，異常處理等代碼從業務邏輯代碼中劃分出來，通過對這些行為的分離，我們希望可以將它們獨立到非指導業務邏輯的方法中，進而改變這些行為的時候不影響業務邏輯的代碼。

對于橫切思維，我們還是給一個簡單的定義：

即在分析諸多事物的生命周期發展過程中，分析端到端流程業務的流轉過程中，在關鍵的階段點進行攔截形成有價值的聚合點，通過聚合點來實現各類統一管控和增值服務。

橫切思維需要徹底打破我們傳統動態單事物動態發展觀察視角，從單事物到事物群，充分去識別共性，將共性進行抽象和聚合，形成有價值的服務能力。

我們可以來看下橫切思維模式具體有哪些實踐

01-在項目型或強矩陣型組織中的橫向管理協同

在一個強矩陣管理下，可以看到對于UI，架構，測試等各種資源全部歸屬到產品線和項目，這些資源完全是按照產品生命周期進行聯動也最敏捷響應客戶需求。但是也可以看到容易導致的就是各個產品線的UI不統一，架構和設計標準不統一等各類問題。因此需要考慮橫向建立各類跨產品線貫通的工作小組，類似UI工作組，TPG工作組等來實現共性資源的整合和復用，一個是標準化，一個是避免各類重復投入。

02-全生態鏈的運營服務類平臺構建和運營

在互聯網里面，我們可以看到很多全生態鏈構建和運營的平臺，類似的供應鏈端到端服務平臺，電商類平臺，二手車交易平臺等。而這些服務平臺里面可以看到在對各方資源進行整合后，其核心不再是簡單的賺取簡單的交易或服務費用，而是在資源整合后，橫向切分后充分挖掘有價值的能力聚合點。

類似你做供應鏈運營服務平臺，你可以推出統一的大宗交易集采，你做58同城你可以推出你自己的58到家自營服務。你做二手車交易，你可以推出你自己的信貸或保理平臺等等。即通過資源整合后，充分去發掘整個生態鏈里面的關鍵節點并進行橫切，來聚合和形成自營的服務能力。

03-企業各種類型的服務共享中心

對于企業來說，各類共享服務中心是一直以來的一個熱點，類似人力資源共享中心，財務共享中心，采購共享中心等，而所有共享中心建立本質就是將原來企業類的涉及到的各類流程中的共性資源抽取出來，充分分析后形成可共享的服務能力再開放出去提供服務。

共享可以是簡單的對已有能力的聚合，但是更多是類似云化的思路，即對已有能力進行徹底剝離，在剝離后充分重構形成完整的統一能力提供。這才是共享中心最終的價值體現。

思維轉變-從技術驅動到經營和價值驅動

最后再談下技術人員思維轉變，或者說叫從技術到管理，從技術走到項目經理或產品經理的時候你應該有的一些思維轉變。對于技術人員在技術上專注和精進本身是沒有問題的，但是如果技術人員沉迷在技術里面那么很難真正走向管理或成為一個打造好產品的產品經理。

培養客戶驅動和經營意識

個人理解首先要培養的就是客戶驅動和經營意識，做任何東西首先要考慮的是是否是真正客戶想要的，還是說為了自己的技術興趣要去學習和研究。

對于我們經常看到的一個情況就是，我們的技術組件和技術開發框架選擇不斷的在追逐新技術不斷的在變化，但是客戶需求或并發往往并沒有到必須使用這些先進技術框架的程度。同時由于技術框架不斷的變化，導致我們的業務系統穩定性反而下降，這就是我們常見的一種技術驅動。

客戶需要的產品沒有做好，但是技術人員自己新技術學了不少，公司出現啥問題了自己反而可以很容易跳槽到新的好公司。這種技術人員總結來說完全是為了個人利益而損害了公司本身的產品和經營。

其次是我們說的經營意識，如果你要轉產品經理或項目經理，你一定要有經營意識，就是我們研發的產品究竟有沒有客戶買單，究竟能不能賺錢，你研發的產品技術再先進，功能再強大，如果沒有最終的客戶，沒有訂單，那么仍然是沒有任何產品價值可言。唯一的用處仍然僅僅是研發人員自己獲得了技術經驗和技術積累。

所以我們研發的功能一定要去思考是否真正是客戶需要的，是否有真實的客戶需求。所有功能的新增和改進，都不能為了技術而技術。包括我們經常談到的微服務架構轉型也一樣，及時做架構轉型也是實際企業業務發展情況下傳統的IT架構無法滿足，需要我們技術架構做出改變，而不是為了迎合新功能，新技術。

完全自研和拿來主義

對于技術人員，最容易犯的毛病就是為了體現自己的技術能力，總是希望所有的東西都要自己從頭到尾做一套，很多時候不屑于采用已經的成熟的開源解決方案或已有的一些成熟產品。

在一個稍微大型一點的公司我們經常就會看到，技術同樣一個技術，類似消息或緩存，往往不同的開發團隊都有自己的解決方案和定制化技術組件。為何出現這種情況？技術人員最常說的就是其他團隊的技術組件不能滿足我們的個性化需求，因此我們要重頭自己搞一套。

那么為何不能是提出個性化需求，然后由對方進行優化和改進呢？

實際上如果真正能夠做到技術平臺和組件的通用化和復用，一個公司必須由類似TPG的平臺型技術組織和團隊，專門來做這件事情，構建企業組織范圍內共享的技術平臺和組件，而且在企業內給出強制性的要求和約束，對于技術組件選擇必須從公司組件庫中選項，對于技術組件類需求必須提交到TPG進行統一評估等。

技術人員思維的另外一個轉變就是我們說的拿來主義，有現成的東西一定不要去從頭到尾去搞，特別是技術走到后期更多的能力應該是在架構和技術組件整合上面，而不是單個技術組件的研發。因為這樣是最快，最敏捷的能夠交付技術平臺和產品的思路。

市場機會往往稍縱即逝，技術團隊需要的就是在最短的時間拿出對應的可用產品，然后在可用產品的基礎上不斷的迭代和優化。而不是用很長的時間才交付一個客戶已經跑掉的，無人問津的自認為完美產品。比如我們提出要在1個月內給出一個快速上線的迭代產品，那么這個就是業務目標的強約束，沒有任何可以商量的余地，那么技術人員要思考的就是在這個約束下進行研發和交付。

做好研發和市場的協同

技術人員需要做好研發和市場的協同。當有了經營意識的時候我們就需要考慮我們的產品如何進行市場策劃和推廣，如何進行新功能和亮點的宣傳，如何拓展相關的渠道和合作伙伴，在這個過程中需要準備哪些產品介紹，宣傳材料，售前PPT等文檔材料等。

市場工作實際和研發工作本身也是迭代交替進行的，任何一個產品都不可能是完全研發出來后我們才去考慮如何進行市場推廣。因此市場策劃推廣和產品研發工作必須并行，而且需要市場和策劃宣傳先行，從市場項目機會到最終落單本身也有一個比較長的周期，因此只有這樣兩者才能夠配合協同起來。

而我們的技術人員往往有時候很難理解，為何產品沒做出來就開始進行市場宣傳已經具備這個功能，這也是典型的沒有市場和經營意識的表現。

用最適合的技術來解決問題而不是最好的技術

一個好的技術人員，或者說技術走向管理的時候一個重要的思維變化就是不能還是原來的技術狂熱型，技術本身是沒有價值的，技術的價值一定是附屬在產品上，讓產品產生了價值。但是產品是否真正有價值并不一定體現在技術先進性上，而是體現在功能是否滿足客戶需求上面的。

任何一個產品運營或者售賣，首先考慮的是在滿足客戶需求的情況下賺取最大化的利潤，技術發展太快，不存在最先進最好的技術，只存在面對當前客戶需求和場景最適合的技術。

任何選擇技術上的超前性往往帶來的問題都是投入更大的研發成本和精力，其次就是新技術往往并不是最穩定的技術反而導致產品不穩定，這些都是技術人員需要思考和綜合衡量的地方。