参考：
百度百科
https://blog.csdn.net/destiny_ac/article/details/44131517
工作中的方法论
前言
方法论的重要性，不言而喻。
对方法论的提炼，就是个人不断成长过程。
方法论有别于方法，方法论往往道理浅显，但是灵活运用非常难，并且是做事中能够解决一列问题的指导原则，而方法是如何做完成一件或类似相对较为具体的任务。
方法论，在精而不在多。
下面，就是我自己最受用的4个方法论：
- 大圈小圈：指导职场晋升的方法论
- 721原则 ：指导个人发展的方法论
- 人无完人：自我驱动的方法论
- 抽象问题具体化，具体问题抽象化：解决实际问题的方法论
大圈小圈
在工作中，我经常碰到两种极端人：
“我觉得我做的很好了，我很负责任的把我负责的系统做得不错了；而且我觉得别人也差不多，为什么绩效会比别人差？”
“我不想做这种琐碎的工作，我想做技术含量更高的任务！”
第一种典型的就是：踏实型，一般性格是偏闷骚型。
第二种典型的就是：抱怨型，一般是刚毕业优秀同学，对自己预期很高，并且总有种“怀才不遇”的感觉。
那么大圈小圈方法论，就是可以用来指导避免让自己陷入这两种困境。
那么下来介绍，大小圈：
如上图所示，大小圈分别是指：
小圈，即影响圈。
影响圈是指：你当前能够影响到的范围的一个区域范围。
举例而言：作为一个初级开发者，他负责某一个模块开发，那么他所能影响的就是这个模块；因为他可以把这个做的更好，或做的不好。但是他不能，影响到：其它模块开发好坏。
而作为一个小组组长，往往所能影响的是一个大的项目，或者某一个业务方向。但是，他无法对另外一个部门的项目，产生任何影响。
大圈，即关注圈。
关注圈是指：你所能看到的，但是无法影响的，或者影响微乎其微可以忽略的范围。
举例而言：此处举一个不太恰当的例子：作为研发者而言，产品设计好坏你是无法左右的。因为这个是产品设计师的职责，你一般的很难影响。当然，你也可以在某些产品设计细节方面，吐槽、提出自己的想法或建议；但是你很难左右产品的发展方向。
在工作中，简单说：影响圈即是自己的本质职责；关注圈即是非自己本质工作之外的。因此一般的，影响圈的大小，反应了个人的能力的大小。
上图中，我们可以看到：影响圈扩大，是向关注圈范围扩展。那么这里揭示关注圈扩大的两个步骤：
影响圈的扩大前提是，把当下的关注圈做的最好，打好基础
当影响圈做好后，才会尝试去将自己能够够得着的关注圈范围（往往围绕自己的影响圈的关注圈部分），扩展为自己的影响圈，从而实现影响圈的扩大。
影响圈是自己本质，是基础；关注圈是扩展区域，是下一步发展；只有把影响圈做好才能进一步扩大影响圈；虽然关注圈对你当下的绩效产出往往没有很明显的价值，但是只有提前关注关注圈，你才有机会，也才有可能扩大影响圈。
所以，当你抱怨“自己怀才不遇”的时候，请首先反思的问题是：我当下的“影响圈”做到极致了吗？
那么实际工作中，这两个圈的时间投入比是多少呢？我们先看两个极端的情况：
100%时间投入到影响圈：把自己的所负责的事情做的很好了，但是也仅限于此，对于其它事情都一概不考虑，只从自己的角度思考。也就是文初提到的第一个典型情况。
100%时间投入到关注圈，即文初提到的第二个典型情况。
那么这里给一个时间配比建议：
721原则
721原则方法论是：
技能获得：70%是由实践获得，20%是学习获得，10%是培训（被指导）获得。
此处：学习是指狭隘学习，仅仅只从书本、互联网等方式主动获取到的知识点。而实践，简单我认为是指：自己运用所学来的知识，解决某个实际问题或任务的过程。
721原则方法，看上去很简单，但是作用却很大；这个方法论不断指导我如何快速学习，以及在重大决策判断上起到了至关重要的作用。
看看有这个方法论，我个人认为觉得很有用的的两个推论：
推论一：最快学习路径是：优先选择学习，能够立刻或者即将实践的知识或技能
这个推论看似简单，但是周围，往往有很多人都没有注意到这一点；比如他们往往更注重于：更前沿知识（专刊、博客），而忽略了那些能够直接在工作中实践的知识点。
一个人的从小白成为某项领域的专家，所需要学习的知识会非常多；如果你规划好整体学习知识点后，其实如何让自己快速的成长，就是一个路径选择问题。
但是，如果再把“机会”因素考虑进来，最优路径的选择往往并不是一个非常简单的事情。但是这个不影响“推论一”，为一个很好的指导原则。
推论二：请不要尝试，只通过学习或者培训方式，能够掌握某项技能或者成为某方面的专家
如果你想尽快真正的成为某方面的专家，这个方法告诉你的是：最重要的首先要考虑如何实践或者哪儿可以找到实践机会。
人无完人
人无完人，是我自己总结的；用于不断自我驱动的一条方法论。
“人无完人”道理很简单：没有一个人是十全十美的。它的另一个推论，就是：“每个人都有问题”。
引用一次实际工作中的对话，引出这个方法论的逻辑：有一次和一个自驱力，能力很强的同学进行one one沟通，谈到他自己的一个困惑：
ASK：“我有一个困惑：我每天晚上完成了任务之后，有时候不知道自己选择该做什么或者学习什么？所以想问下你，看看你每天晚上一般都做什么？”
我 ：“我每天晚上、地铁上最多做的是不断思考问题；当然有时候是在学习。” ASK：“你每天在思考什么问题？” 我 ：“比如，半年前，我再思考xx、xx问题，最近我在思考xx、xx、xx问题。” ASK：“你要是问题解决完了，那怎么办？” 我 ：“那说明我处境现在很危险了，需要立马思考：**为什么我没有问题**？” 我 ：“至于如何解决“为什么我没问题”这个问题就是另一个层次问题。这并不是重点，暂不细聊，简单说解决方案有：向上、横向、向下沟通问题收集；横向对比，和高阶同学对比思考差距在那里；思考学习哪些知识来开拓自己的当前面临的视野局限问题等等，。。。。。。”
用流程图画出逻辑如下：
ps：学习也是一种问题解决方法。
从图中可以看到，一旦你进入思考，其实是一个死循环，是永远没有结束。我相信大部分的人，当有问题的时候，都会做到中间第一个循环。但是当所有问题解决差不多的时候，就会开始出现“我觉得我做到极致了，我没有太多问题需要解决了。”。其实这就表明，你忽略了第二层循环。
有很多人都能感受到，能力提升的过程有点儿像：洋葱圈，是一层一层的；并且由一个层次提升到上一个层次，不是简简单单的学习问题，难度最大，往往需要突破的是一个瓶颈（而这时高工指导的话：往往发出“一句话胜读十年书”的感叹）。所以，如果用洋葱圈比如的话，那么上图中：
第一层循环：在层次内，提升的过程
第二层循环：是突破层次的瓶颈，达到上一个层次的过程
所以我认为，第二层循环往往比第一层更为重要，而且更难！但是两层循环是相辅相成的，只有通过第一层，是自己提升到当前层次内最高点后，然后通过第二层循环思考，才有可能突破到下一个层次内起点。
具体问题抽象化，抽象问题具体化
这条方法论，是我从他人身上学习和借鉴的。但是至今仍然还没有完全消化，达到灵活运用的地步。所以在此仍然是谈谈自己的看法和认为。
这条方法论，至少在技术、管理两个方面起到不可忽视的作用。
具体问题抽象化
具体问题抽象化，主要是为达到举一反三的目的。未来的问题我们无法预料，但是已经发生的同类事情是不允许发生第三次的。那么具体问题抽象化，即是从问题出发，找到问题本质，从根上解决问题。 网上也可以找到此类问题的解决方法，但是这里我讲一下我个人的方法。
具体问题抽象化，在我的方法中分为以下几个步骤：
问题收集=》问题归类=》问题分析=》问题提炼抽象
问题收集和问题归类，我往往是在脑子里完成。并不是我脑子很好使，而是有一套方法。
问题收集：问题收集的关键在于渠道，比如包括：邮件、QQ、微信、BUG反馈渠道、用户反馈渠道等；自下而上反馈渠道、横向交流、跨团队调研、向上沟通等；朋友圈等。
问题归类：对于大量渠道的话，每天可能收集到的问题非常多；所以此时，对如何抓住重点问题&以及问题本质，难度较高。最土的办法就是把问题全部记录下来，然后最后汇总分析。但是我个人方法不是这样，目前很少会用比记录，除非特殊情况。
这得益于方法：“3 Why”。具体讲就是：每当一个问题反馈后，我会针对这个问题，进行连续追问3个为什么，从而初步找到问题的类别A；于是在脑海中建立一个映射，类别A问题发生了一次xxx事情。这样同样类别A的第二个问题发生时，同样“3 Why”分析后，就找到了似曾相识的感觉。而这时，就会开始警觉起来，接着就是对这个重复出现的两个问题进一步，深入分析。
“3 why”方法，举一个浅显易懂的例子：
比如“一个新同学上线的项目回滚了。”，那么我就会问：
1、为什么项目回滚了？
answer：新同学不仔细，测试不全，导致了上线后，回归发现问题，赶紧回滚。2、是发现了，但是没测试？还是根本就没发现？
answer：是根本没有发现。3、为什么新同学，没有发现修改的代码，可能会影响另外一个功能？
answer：模块A和模块B是耦合在一起的，导致新同学没注意到忽略了这个点。OK，到此为止。一般的我发现大部分的情况 3 why，基本能够找到问题本质。比如这个问题，可能的确有新人疏忽、测试流程问题等情况，但是最后我们抓到的问题一个点：模块A和模块B耦合问题。
虽然通过“3 why”找到的问题，这不一定是个比较大的问题，因为很有可能就是新人问题或者测试流程问题；但是这个不要紧，我只需要在脑海里建立这个映射：模块AB由于耦合问题=》发生了一次新人回滚。
当下次由于“开发延期现象”，挖掘到同样“模块A和B耦合的问题”时，那么就此时就会，徒然思考：发生了两次了，那么“模块A和B耦合的问题”可能性很大。因此有必要深入细分析下这个问题。
问题深入分析和提炼抽象，就没有特别要说的，只有注意两点：1、在问题分析时多从全局观进行思考，而不是局限在问题本身。
2、问题最后抽象到的最后只有两类：技术问题 or 管理问题（流程）。切忌把一切问题都归到“人的问题”上。
抽象问题具体化
通常通过“具体问题抽象化”后，找到一个高大上的解决方案，或者会考虑一个看似很完美的解决方案。是不是就是就一定对了？实际经验告诉我们，当我们抽象化之后，往往会过少考虑一些现实因素，或者忽略最初本身问题，或者忽略了新方案可能对其它方面造成的影响（比如：管理）；如果只是第一步，往往会出现很多问题。
所以，第二个方法论，是判断方案可行性，是否解决问题本身来看，是很至关重要的。
抽象问题具体化的方法，就是“演绎”。
如何“演绎”的更全面、具体就是需要不断锻炼的本事；此外这个和看问题的角度有较大关系；“演绎”是需要一个实操的过程，很难给出一个非常具体的方法；演绎过程中，越具体越好；但是这里也要提到，在“演绎”中，需要重点关注验证的两个方向：
1、是否最佳的解决了我们最初提到的几个问题，并且是最首要的？
2、是否会产生：技术（开发、测试、上线、运维） or 管理上（项目管理、团队配合、职责划分）新的问题