前言后端
方法论的重要性，不言而喻。
对方法论的提炼，就是我的不断成长过程。
方法论有别于方法，方法论每每道理浅显，可是灵活运用很是难，而且是作事中可以解决一列问题的指导原则，而方法是如何作完成一件或相似相对较为具体的任务。
方法论，在精而不在多。
下面，就是我本身最受用的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源创计划”，欢迎正在阅读的你也加入，一块儿分享。