前言後端
方法論的重要性，不言而喻。
對方法論的提煉，就是我的不斷成長過程。
方法論有別於方法，方法論每每道理淺顯，可是靈活運用很是難，而且是作事中可以解決一列問題的指導原則，而方法是如何作完成一件或相似相對較爲具體的任務。
方法論，在精而不在多。
下面，就是我本身最受用的4個方法論：
微信
大圈小圈：指導職場晉升的方法論 721原則 ：指導我的發展的方法論 人無完人：自我驅動的方法論 抽象問題具體化，具體問題抽象化：解決實際問題的方法論
大圈小圈markdown
在工做中，我常常碰到兩種極端人：
架構
「我以爲我作的很好了，我很負責任的把我負責的系統作得不錯了；並且我以爲別人也差很少，爲何績效會比別人差？」
「我不想作這種瑣碎的工做，我想作技術含量更高的任務！」
運維
第一種典型的就是：踏實型，通常性格是偏悶騷型。學習
第二種典型的就是：抱怨型，通常是剛畢業優秀同窗，對本身預期很高，而且總有種「懷才不遇」的感受。
那麼大圈小圈方法論，就是能夠用來指導避免讓本身陷入這兩種困境。測試
那麼下來介紹，大小圈：
如上圖所示，大小圈分別是指：
spa
小圈，即影響圈。影響圈是指：你當前可以影響到的範圍的一個區域範圍。
舉例而言：做爲一個初級開發者，他負責某一個模塊開發，那麼他所能影響的就是這個模塊；由於他能夠把這個作的更好，或作的很差。可是他不能，影響到：其它模塊開發好壞。
而做爲一個小組組長，每每所能影響的是一個大的項目，或者某一個業務方向。可是，他沒法對另一個部門的項目，產生任何影響。
.net
大圈，即關注圈。 關注圈是指：你所能看到的，可是沒法影響的，或者影響微乎其微能夠忽略的範圍。
舉例而言：此處舉一個不太恰當的例子：做爲研發者而言，產品設計好壞你是沒法左右的。由於這個是產品設計師的職責，你通常的很難影響。固然，你也能夠在某些產品設計細節方面，吐槽、提出本身的想法或建議；可是你很難左右產品的發展方向。設計
在工做中，簡單說：影響圈便是本身的本質職責；關注圈便是非本身本質工做以外的。所以通常的，影響圈的大小，反應了我的的能力的大小。
上圖中，咱們能夠看到：影響圈擴大，是向關注圈範圍擴展。那麼這裏揭示關注圈擴大的兩個步驟：
影響圈的擴大前提是，把當下的關注圈作的最好，打好基礎當影響圈作好後，纔會嘗試去將本身可以夠得着的關注圈範圍（每每圍繞本身的影響圈的關注圈部分），擴展爲本身的影響圈，從而實現影響圈的擴大。
影響圈是本身本質，是基礎；關注圈是擴展區域，是下一步發展；只有把影響圈作好才能進一步擴大影響圈；雖然關注圈對你當下的績效產出每每沒有很明顯的價值，可是隻有提早關注關注圈，你纔有機會，也纔有可能擴大影響圈。
因此，當你抱怨「本身懷才不遇」的時候，請首先反思的問題是：我當下的「影響圈」作到極致了嗎？
那麼實際工做中，這兩個圈的時間投入比是多少呢？咱們先看兩個極端的狀況：
100%時間投入到影響圈：把本身的所負責的事情作的很好了，可是也僅限於此，對於其它事情都一律不考慮，只從本身的角度思考。也就是文初提到的第一個典型狀況。
100%時間投入到關注圈，即文初提到的第二個典型狀況。
那麼這裏給一個時間配比建議：
721原則
721原則方法論是：
技能得到：70%是由實踐得到，20%是學習得到，10%是培訓（被指導）得到。
此處：學習是指狹隘學習，僅僅只從書本、互聯網等方式主動獲取到的知識點。而實踐，簡單我認爲是指：本身運用所學來的知識，解決某個實際問題或任務的過程。
721原則方法，看上去很簡單，可是做用卻很大；這個方法論不斷指導我如何快速學習，以及在重大決策判斷上起到了相當重要的做用。
看看有這個方法論，我我的認爲以爲頗有用的的兩個推論：
推論一：最快學習路徑是：優先選擇學習，可以馬上或者即將實踐的知識或技能
這個推論看似簡單，可是周圍，每每有不少人都沒有注意到這一點；好比他們每每更注重於：更前沿知識（專刊、博客），而忽略了那些可以直接在工做中實踐的知識點。
一我的的從小白成爲某項領域的專家，所須要學習的知識會很是多；若是你規劃好總體學習知識點後，其實如何讓本身快速的成長，就是一個路徑選擇問題。
可是，若是再把「機會」因素考慮進來，最優路徑的選擇每每並非一個很是簡單的事情。可是這個不影響「推論一」，爲一個很好的指導原則。
推論二：請不要嘗試，只經過學習或者培訓方式，可以掌握某項技能或者成爲某方面的專家
若是你想盡快真正的成爲某方面的專家，這個方法告訴你的是：最重要的首先要考慮如何實踐或者哪兒能夠找到實踐機會。
人無完人
人無完人，是我本身總結的；用於不斷自我驅動的一條方法論。
「人無完人」道理很簡單：沒有一我的是十全十美的。它的另外一個推論，就是：「每一個人都有問題」。
引用一次實際工做中的對話，引出這個方法論的邏輯：有一次和一個自驅力，能力很強的同窗進行one one溝通，談到他本身的一個困惑：
ASK：「我有一個困惑：我天天晚上完成了任務以後，有時候不知道本身選擇該作什麼或者學習什麼？因此想問下你，看看你天天晚上通常都作什麼？」我 ：「我天天晚上、地鐵上最多作的是不斷思考問題；固然有時候是在學習。」ASK：「你天天在思考什麼問題？」我 ：「好比，半年前，我再思考xx、xx問題，最近我在思考xx、xx、xx問題。」ASK：「你要是問題解決完了，那怎麼辦？」我 ：「那說明我處境如今很危險了，須要立馬思考：**爲何我沒有問題**？」我 ：「至於如何解決「爲何我沒問題」這個問題就是另外一個層次問題。這並非重點，暫不細聊，簡單說解決方案有：向上、橫向、向下溝通問題收集；橫向對比，和高階同窗對比思考差距在那裏；思考學習哪些知識來開拓本身的當前面臨的視野侷限問題等等，。。。。。。」1234567891011
用流程圖畫出邏輯以下：
ps：學習也是一種問題解決方法。
從圖中能夠看到，一旦你進入思考，實際上是一個死循環，是永遠沒有結束。我相信大部分的人，當有問題的時候，都會作到中間第一個循環。可是當全部問題解決差很少的時候，就會開始出現「我以爲我作到極致了，我沒有太多問題須要解決了。」。其實這就代表，你忽略了第二層循環。
有不少人都能感覺到，能力提高的過程有點兒像：洋蔥圈，是一層一層的；而且由一個層次提高到上一個層次，不是簡簡單單的學習問題，難度最大，每每須要突破的是一個瓶頸（而這時高工指導的話：每每發出「一句話勝讀十年書」的感嘆）。因此，若是用洋蔥圈好比的話，那麼上圖中：
第一層循環：在層次內，提高的過程 第二層循環：是突破層次的瓶頸，達到上一個層次的過程
因此我認爲，第二層循環每每比第一層更爲重要，並且更難！可是兩層循環是相輔相成的，只有經過第一層，是本身提高到當前層次內最高點後，而後經過第二層循環思考，纔有可能突破到下一個層次內起點。
具體問題抽象化，抽象問題具體化
這條方法論，是我從他人身上學習和借鑑的。可是至今仍然尚未徹底消化，達到靈活運用的地步。因此在此仍然是談談本身的見解和認爲。
這條方法論，至少在技術、管理兩個方面起到不可忽視的做用。
具體問題抽象化
具體問題抽象化，主要是爲達到觸類旁通的目的。將來的問題咱們沒法預料，可是已經發生的同類事情是不容許發生第三次的。那麼具體問題抽象化，便是從問題出發，找到問題本質，從根上解決問題。網上也能夠找到此類問題的解決方法，可是這裏我講一下我我的的方法。
具體問題抽象化，在個人方法中分爲如下幾個步驟：
問題收集=》問題歸類=》問題分析=》問題提煉抽象
問題收集和問題歸類，我每每是在腦子裏完成。並非我腦子很好使，而是有一套方法。
問題收集：問題收集的關鍵在於渠道，好比包括：郵件、QQ、微信、BUG反饋渠道、用戶反饋渠道等；自下而上反饋渠道、橫向交流、跨團隊調研、向上溝通等；朋友圈等。
問題歸類：對於大量渠道的話，天天可能收集到的問題很是多；因此此時，對如何抓住重點問題&以及問題本質，難度較高。最土的辦法就是把問題所有記錄下來，而後最後彙總分析。可是我我的方法不是這樣，目前不多會用比記錄，除非特殊狀況。
這得益於方法：「3 Why」。具體講就是：每當一個問題反饋後，我會針對這個問題，進行連續追問3個爲何，從而初步找到問題的類別A；因而在腦海中創建一個映射，類別A問題發生了一次xxx事情。這樣一樣類別A的第二個問題發生時，一樣「3 Why」分析後，就找到了似曾相識的感受。而這時，就會開始警覺起來，接着就是對這個重複出現的兩個問題進一步，深刻分析。
「3 why」方法，舉一個淺顯易懂的例子： 好比「一個新同窗上線的項目回滾了。」，那麼我就會問： 一、爲何項目回滾了？ answer：新同窗不仔細，測試不全，致使了上線後，迴歸發現問題，趕忙回滾。 二、是發現了，可是沒測試？仍是根本就沒發現？ answer：是根本沒有發現。 三、爲何新同窗，沒有發現修改的代碼，可能會影響另一個功能？ answer：模塊A和模塊B是耦合在一塊兒的，致使新同窗沒注意到忽略了這個點。
OK，到此爲止。通常的我發現大部分的狀況 3 why，基本可以找到問題本質。好比這個問題，可能的確有新人疏忽、測試流程問題等狀況，可是最後咱們抓到的問題一個點：模塊A和模塊B耦合問題。
雖然經過「3 why」找到的問題，這不必定是個比較大的問題，由於頗有可能就是新人問題或者測試流程問題；可是這個沒關係，我只須要在腦海裏創建這個映射：模塊AB因爲耦合問題=》發生了一次新人回滾。
當下次因爲「開發延期現象」，挖掘到一樣「模塊A和B耦合的問題」時，那麼就此時就會，徒然思考：發生了兩次了，那麼「模塊A和B耦合的問題」可能性很大。所以有必要深刻細分析下這個問題。
問題深刻分析和提煉抽象，就沒有特別要說的，只有注意兩點：
1、在問題分析時多從全局觀進行思考，而不是侷限在問題自己。 2、問題最後抽象到的最後只有兩類：技術問題 or 管理問題（流程）。切忌把一切問題都歸到「人的問題」上。
抽象問題具體化
一般經過「具體問題抽象化」後，找到一個高大上的解決方案，或者會考慮一個看似很完美的解決方案。是否是就是就必定對了？實際經驗告訴咱們，當咱們抽象化以後，每每會過少考慮一些現實因素，或者忽略最初自己問題，或者忽略了新方案可能對其它方面形成的影響（好比：管理）；若是隻是第一步，每每會出現不少問題。
因此，第二個方法論，是判斷方案可行性，是否解決問題自己來看，是很相當重要的。
抽象問題具體化的方法，就是「演繹」。
如何「演繹」的更全面、具體就是須要不斷鍛鍊的本事；此外這個和看問題的角度有較大關係；「演繹」是須要一個實操的過程，很難給出一個很是具體的方法；演繹過程當中，越具體越好；可是這裏也要提到，在「演繹」中，須要重點關注驗證的兩個方向：
1、是否最佳的解決了咱們最初提到的幾個問題，而且是最首要的？ 2、是否會產生：技術（開發、測試、上線、運維） or 管理上（項目管理、團隊配合、職責劃分）新的問題
本文分享自微信公衆號 - 互聯網後端架構（fullstack888）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。