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