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