浅谈如何成为技术一号位
作者 | 賀科學
前言
絕大多數的人都有自己的思維定式，都有無形的枷鎖束縛著自己的思維，從而導致行為也被束縛，所以在他人看來會有這樣的現象：有些事情該做卻沒有做，有些事情不該做卻做了很多。我們拋開公序良俗、社會道德、法律法規等等這些約束人在社會活動中必須遵守的束縛的情況不談，只談論在工作方面、或者說“做事”方面可能有哪些無形的東西在束縛著大家，和大家一起探討如何看到這些束縛，打破這些束縛，從而獲取站到更高層次的機會，完成自身角色的轉變。
認清每個人自己在日常工作中的思維定式非常重要，有助于轉變自己對很多事情的認知，而這種轉變也會從根本上帶來行為上的變化。也就是說，可以通過理論分析和實踐，來共同完成對個人實際生活的影響。
所以今天這篇文章，我們會先討論業務研發同學，或者說大多數的業務研發同學的自我認知是什么，再看下這種普遍的自我認知之內，是否已經存在著大家視而不見的思維定式；然后再討論思維定式產生的原因是什么，如何突破這種由認知不到位而導致的自我束縛；最后再探討業務研發同學應該存在什么樣的認知，如何通過實踐完成自己從普通開發到技術一號位的角色轉變。
業務研發同學普遍的、存在思維定式的自我認知&產生的原因及解決辦法
1、業務研發同學普遍的、存在思維定式的自我認知是什么
從上大學選擇專業開始，“編程”、“做技術”、“大牛” 仿佛對理工科的人有極大的吸引力。所有信息化相關專業的人畢業以后，這種“成為大牛”的情結依然發揮著重要的作用，讓畢業生們從校園走到工作崗位上以后，仍然能夠驅動自己不斷地在工作中學習和積累（當然驅動研發同學努力提升自己能力的也有可能并不是“大神”情節，而是“殘酷的現實” —— “不懂”、“不會”、“做不了” 可能會被“現實打臉”），提升自己的技術水平，朝著自己崇拜的“大牛”的方向持續努力，完成個人成長的第一階段。
也正是這樣的發展路徑，逐步地讓研發同學自己形成了 “技術人” 的角色認同。
于是，絕大多數的業務研發人員會把 “寫代碼”、“做技術” 當成是自己工作的主要內容，認為自己是“做技術的”。這種認知的形成，是周圍環境和個人日常行為共同促成的。這種自我認知本身是正確的，但是只有這種認知，是錯的，是對個人角色片面的理解。在這種自我認知的驅使下，研發人員的目光會關注編碼規范，關注代碼性能，關注編碼技巧，關注研發效能，也會關注新的技術，關注各種高大上的技術名詞及背后的實現原理；但是如果一個研發人員只通過這種認知驅使自己做出實際行動，那么這種行動本身和行動獲取的結果，都是不能滿足研發人員所處的外部環境對他的要求的。這是為什么說現在大多數的業務研發人員對自己的認知是存在思維定式的原因。
客觀來看，大多數研發同學的這種認知，其實只是關注了自己默認角色（研發）對自己的要求（有足夠高的技術能力），而沒有關注周圍環境對自己的需要，這種關注上的偏差，造成了 “實際行動” 和 “環境要求” 兩者之間的不匹配，會帶來很多問題，并且這些問題只從原來的認知層面做出行動是解決不了的。
2、研發同學的這種自我認知和環境不匹配的原因是什么呢？
一種情況是，你所處的環境發生了變化，而從最開始你就對環境的要求有錯誤的認知，沒有意識到差異，導致了這種“環境要求和個人行為結果”不匹配的矛盾隨著時間的推移越來越大，一直大到無法被忽視的情況下，才會被重視起來，才會做出反思和調整。但是這種調整是被迫的，不是主動的，可以理解為是一種無意識的應激反應，下次再遇到同樣的問題的時候，不同境界的人會有不同的反應：
- 沒有悟性的同學，會任由這種不匹配繼續造成無法忽視的問題以后，再去“無意識”地解決；
- 悟性高一些的人，會通過之前的經驗，在問題處于一個可以被明顯感知但是尚未到達影響無法忽視的階段即可化解。不過憑借經驗并不是一個穩定可靠的辦法，因為總有很多事情是沒有事先經歷過的，在沒有經驗的支撐下，還是會出現和沒有悟性的同學一樣的問題；
- 悟性最高的同學，會通過現象看到本質，總結出相關的方法論，在事情來臨的時候使用方法論分析問題，判斷事情發展的趨勢，仿佛可以站在更高的視角和維度，去旁觀整個過程發生了什么，怎么避免再次發生，怎么降低這種問題的影響或者直接避免這種問題的發生。
針對這種情況，舉個例子，比如剛畢業的學生往往不能適應社會工作和生活，再比如男女朋友結婚以后，敏感的一方會覺得另外一方變了，這些都是因為個體所處環境發生了變化，因而對環境中的個體的要求也發生了變化。所以，當你個人所處的環境發生變化以后，比如去了新的公司，比如換了新的團隊，比如下屬變多了，比如業務換了方向，比如負責一個新的業務等等，要對這些環境的變化有足夠的敏感度，要檢查環境的變化是否對自己產生了新的不一樣的要求。說白了就是要檢視自己的角色是否因為環境的變化而發生了變化，需要用變化以后的角色去處理事情。
另外一種情況是，你所處的環境沒有變，但是你自己隨著時間的推移發生了變化，從而導致環境對你的變化產生了新的要求，但是由于你沒有感覺到這種由自身變化而引發的環境要求的變化，沒有做出對應的及時的調整，那么就會導致新的不匹配的出現。針對這種情況，舉個例子，比如剛晉升的同學，環境對你的要求隨著你的能力的提升是變化的，要以新的角色去響應這種變化以后的要求，而不能繼續用原來的角色和做事方式去做。所以，大家也要對自己個人的變化有足夠的敏感度，要檢查自己的變化是否引起了環境的不一樣的要求，要檢查自己現有的做事方式能否滿足這種要求的變化，如果不能滿足，要分析什么樣的角色能滿足，然后轉變個人認知，以這種角色去做事。
綜上所述，“環境變了你沒變，或者你變了環境沒變”，都需要分析環境對自己的要求是什么，要判斷現有的認知驅動的行為是否能匹配這種要求；如果不能匹配，那么要分析什么樣的行為可以匹配新的要求，要分析這種行為是哪種角色應該做的，然后就能知道自己要轉變的方向了。這個理論和結論不止適用于業務研發，而是普世的，是單純地討論“個人和其所處環境的要求是否匹配”的問題的。這些理論分析，實質上是在使用《矛盾論》的理論方法分析 “人與環境” 中的 “人的行為及結果與環境的要求” 的矛盾的分析，這種矛盾是對立統一的，也是隨著時間、隨著環境、隨著個人的變化都會發生變化的。
我們從枯燥的理論分析回到業務研發同學的問題上來，業務研發同學從開始入職到成長成為一個技術不錯的技術骨干，往往兩種情況都經歷過了。
第一種情況，從學校畢業到參加工作，經歷環境變化以后，經歷了“社會的毒打“ 以后，大多數人都是通過提升個人技術能力來度過這個階段的，而這種解決問題的辦法也為大家經歷第二種情況的時候帶來了很多麻煩：按照經驗，提升個人技術能力即可應對環境要求，但是事實上，隨著你個人的成長，環境對你不再僅僅只有技術方面的要求了，繼續提升技術能力只能起到提升你個人技術能力的作用，不能彌補環境對你的要求和你的行為之間的不匹配的問題。很多研發 leader 或者技術骨干有過這樣痛苦的經歷，認為自己技術好就會被賞識，就沒問題。但是問題其實本身跟你個人技術好不好沒關系，跟你是否能滿足環境對你的要求有關系。技術好，只是獲取周圍環境對你提出新的要求的“資格”，而不是解決方案，而繼續提升個人技術能力，不是真正的解法。真正的解法，是認知上的改變，而由認知的改變帶來的實際行動的改變。
3、如何做到個人的行為及其結果匹配環境對個人的要求？
如果說，絕大多數的研發同學都有這種認知誤區，并且未來一定會經歷“隨著個人能力的提升而環境對自己的要求會變化”這種事情。那么如何解決這個問題呢？簡而言之就是 “開始要有正確的認知，后面要隨時調整自己的角色”。
首先，問題（環境要求和個人行為及結果不匹配）產生的原因是什么，我們上面已經說得非常清楚了，在已經知道原因的前提下，首先要做的其實很簡單，就是“正確認知環境對自己的要求”。
業務研發同學面對的環境要求是什么，是 “寫代碼”、“搞技術”嗎？不是，“寫代碼”、“搞技術”只是你的工作內容（而且只是非常小的一部分），不是環境對你的要求，環境對你的要求是：幫助客戶實現業務數字化（不接受任何反駁和討論，因為理論上的討論沒意義，但是歡迎以任何形式通過實踐來檢驗）。也就是說，所有做業務開發的同學，從你認可了這個理論分析這一刻開始，你不再僅僅是一個“研發工程師”，更是一個“客戶業務數字化工程師”，你默認的角色——研發工程師，在目前的大環境下，附加了新的角色和與之對應的職責，在認知上需要改變自己過去畢業就形成的舊的認知，要嘗試轉變到新的認知上來，理解新的角色所蘊含的要求和期待是什么。
所以，過往我們都說研發工程師，JAVA 開發，前端開發，全棧開發，go 工程師，這些分類都是從你個人掌握的技能來劃分的，而不是從你的職責劃分的。這種傳統的劃分方式，對你也起到了很多誤導和禁錮作用。要知道，如果你是在業務團隊，除了以上的崗位角色以外，不論你的技術棧是什么，你更應該被稱為“業務數字化工程師”，這是你過往沒有關注過但是其實一直都存在的“新角色”，這個“新角色”會從過往的隱形變為現在的可見、從幕后走到臺前。這一角色和與之對應的責任，會讓你在原來的工作內容的認知上，感知到新的維度。
在這個認識下，你會意識到，業務面的知識學習、需求分析、領域建模、模型落地、流程優化這些東西的比重和基礎性，不低于寫代碼的比重，甚至更高。雖然我們所有的論述都是在講業務研發同學，但是本質上，做純技術平臺開發的同學也是一樣的道理，你們的任務是幫助業務研發同學數字化，或者更高效、更低成本地讓我們幫助客戶業務數字化。你的業務需求是技術性的，如果你不能對技術平臺的業務需求有足夠的建模分析能力的話，技術系統與業務系統相比而言更高的邏輯復雜度和更高的抽象性，一樣會給你造成極大的困難。
“幫助客戶實現業務數字化”這個要求，并不是讓你停止發展你自己的技術，而是要求你對“業務”兩個字投入更多的精力，要對它有新的理解，而不是把它當做“妨礙我寫代碼的事情”。所以用一個比喻來形容，就是：做業務開發的研發同學，不論是什么水平，什么等級，帶不帶人，都需要“技術”和“業務”兩條腿走路。這是所謂的“正確地認知環境對業務研發同學的要求”的意義：讓業務研發同學找到并重視修煉自己另外一條“走路的腿”，并且要利用做業務的過程鍛煉這條腿的力量，通過掌握適當的方法論，加速力量的形成，加強這條退的強度，因為終將有一天你需要靠著這兩條腿帶著很多“一瘸一拐”的業務開發同學往前走。為什么說“一瘸一拐”的開發同學？因為目前來看絕大多數的業務開發同學都只是“在做業務需求”，而不是“在做業務”，做業務方面的能力和技術能力不匹配，因此還做不到“兩條腿走路”，最多是一瘸一拐。
舉一個所有研發同學都能看明白的例子，來最后概括一下上面的意思：如果你認為自己只是寫代碼的，做技術的，你只關注寫代碼，只關注怎么提升你的技術能力，而不去關注業務能力的提升，那么你就陷入了自己認知上的偏見給自己埋下的坑里，這種偏見和以下兩種你一看就知道有問題的事情本質上是一樣的：
1. 產品經理只需要做產品原型就好了。
2. 運營同學只需要向用戶端推送廣告就好了。
現在能感受到“研發同學只需要寫代碼就好了”是一種偏見吧？需求分析？要做！各種溝通的會議？要開！業務發展規劃？要做！很多原來被大多數研發同學看成是“干擾我寫代碼”的事情，其實都是你的角色必須做的事情，而且這些事情的比例甚至比寫代碼還高。因為幫助客戶業務數字化的過程，寫代碼、做技術只是第一步而已。
下面兩個圖，是普通的業務研發人員的視角看問題和技術一號位看問題的視角。
普通研發人員看問題的視角，是以資源的視角來看問題的，以資源的視角看問題，就只能對一件事情做有限的行動，最終就只能被當做資源：
技術一號位的看問題的視角，必須轉換為 Owner 的視角來看問題，即和你相關的事情就是需要你為之負責的（并不一定是負主要責任，但是一定是要負責任的）：
需要關注的就是上面第二個圖中的“職責范圍圈”，普通研發同學受限于自己的認知，只能做最里面的寫代碼的事情，隨著技術能力的提高職責范圍可以逐步外擴，但是永遠接觸不到其他角色的職責范圍圈，而技術一號位的職責范圍圈會逐步擴大到與之相關聯的各方的職責范圍圈上，甚至有一部分的重疊。這是最能直觀表現兩者由于認知差異導致的角色扮演的差異，導致的行為及結果上的差異。
業務研發同學如何成為技術一號位
在認識到自己做的事情是“幫助客戶業務數字化”以后，在“做業務”方面的要求就會變得和“做技術”方面的要求一樣重要了。關于“做技術”，可以在大學里面學到基礎的技術領域的專業技能，工作以后也有大量的書籍和項目可以學習，所有的研發對此毫不陌生；但是對于 “做業務”，似乎沒有那么多可以參考或學習的東西，更多的是個人經驗的積累，那么想要成為技術一號位，怎么辦？
我們先做一個這樣的假設 —— “我們可以通過分析一個事物的組成，觀察這個事物的生命周期，以及了解這個事物在整個全生命周期內和外界發生的關系及相互作用來全面認識一個事物”。
我們既然想要學習 “做業務” 的知識，來讓自己有能力變成技術一號位，所以我們必須全面認知一個事物，在認知的過程中知道它需要什么樣的能力，而這些能力是我們需要通過各種手段逐步鍛煉的。
所以要想回答研發同學如何成為技術一號位，首先要搞懂一個業務包含什么，它有怎樣的生命周期，它和外界的關系影響是什么？
在數字時代，個人總結分析，從抽象的角度來看，一個業務會有以下方面的信息需要大家了解：
1、什么是業務
涉及一個以上組織，按某一共同的目標、通過信息交換實現的一系列過程，其中每個過程都有明確的目的，并延續一段時間。
2、業務存在的目的和價值是什么
通過創造價值給企業帶來收益（可能是經濟上的收益，可能是其他方面的收益，例如品牌、口碑、社會形象等）
3、信息時代常規業務涉及哪些方面
4、業務有怎樣的生命周期
5、業務和外界有什么關系，有什么相互影響
6、讓一個業務誕生，盡可能實現它的目標并延長生命周期，需要具備的能力
7、哪些是技術一號位的職責
我們在了解以上內容的基礎上，需要知道一個客觀事實：“做業務”需要的知識，和“做技術”需要的知識，本質上沒有區別，都是個人實踐的經驗+前人經驗總結（書本上的知識），所以做業務的知識會在知識形態上和技術知識一樣，具備以下一些特點：
- 可以被學會
- 可以通過個人實踐獲得
- 知識分布的形態以知識樹的形式被外界感知
- 知識樹的分叉意味著知識會有不同的細分領域，有一定的廣度；知識樹的層次意味著會有一定的深度
- 系統性學習知識的人，可能會比其他人更深入地掌握某個分支的知識（知識的深度）；也可能比其他人更廣泛地掌握多個分支的知識（知識的廣度）
技術領域常常會討論如何權衡個人發展路線上的深度和廣度兩個方向。同理，在“業務學”上也有同樣的情況。不過由于現在所處的數字時代，業務本身就包含著數字技術，所以大家作為業務研發人員天然在 “業務學” 的技術細分領域上有深度的積累，產品人員天然在“業務學”的產品細分領域上有深度積累，運營人員天然在“業務學”的運營細分領域上有深度積累，職業經理人天然在 “業務學”的綜合管理細分領域上有深度積累。所以大家要想成為一個業務的技術一號位，要做的是加強 “業務學” 的廣度的積累，圍繞業務的全生命周期，熟悉它的組成，參與掌握、把控它對外界的影響和交互的過程，并且在自己負責的細分領域內做到全面的負責，就能夠成為一個業務的技術一號位。
這個結論目前只是為了讓大家在思想上認識到對技術一號位的整體的要求，轉變過去的 “研發本位” 的認知誤區，至于怎么一步一步通過實踐變成技術一號位，還需要繼續看其他文章來掌握對應的知識，依靠掌握的方法論來指導實踐，避免走彎路。
﹀
﹀
﹀
解決方案咨詢技術交流群：搜索釘釘群號 31704055?加入，可獲取云原生詳細解決方案資料與專家答疑。
原文鏈接：https://developer.aliyun.com/article/785947?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的浅谈如何成为技术一号位的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Dapr 在阿里云原生的实践
- 下一篇： 虚拟背景背后的技术：直播时各种背景是怎么