方法论

方法论是领导做事的根本准则，可能帮忙咱们疾速的涉及问题的外围并确定解决思路，好的方法论能让咱们事倍功半，上面就总结下我在阿里这几年学习到的局部方法论。 做事方法论5W2H咱们在做一件事时，常常须要和老板或者合作方去讲为什么要做这件事，筹备怎么做，以求取得来自老板和合作伙伴的认可及反对。5W2H是指WHY、WHAT、WHO、WHEN、WHERE、HOW、HOW MUCH。5W2H办法能够帮忙咱们搭建出一个清晰的表白框架，让表白的重点突出，易于了解，上面就对5W2H做个具体的介绍。 WHY：以前在学校里写论文时，首先须要论述的就是整篇文章的动机。同样地，在进行述职或降职问难时，也要向大家讲明确做一件事的起因和收益，如果答复不好这个问题，那你所做的事件就可能被质疑是没有价值的；WHAT：当咱们想分明了了做一件事件的起因，接下来要确定的就是做什么，以及指标是什么；WHO：想要做成一件事件，除了本人，通常须要其他人协同实现，越是简单的事件，须要协同的人员越多。此时，须要做到权责明显，确认好工作的一号位及所有人的分工；WHEN：做事件，通常咱们会有长期指标和短期指标。在什么工夫点实现什么样的事件须要一开始就确定好，后续能力以此为指标进行推动；WHERE：确定做一件事件的地点，如果波及横跨多个地区的合作项目，须要思考人员的办公地点，必要时需思考出差；HOW：做一件事件的具体方法和步骤；HOW MUCH：做一件事件的开销，包含人力、资源等各方面老本。做一件事件时，咱们要思考投入产出比，对于老本高收益小的事件，就须要再进一步对焦是否有持续推动的必要了；很多简略的事件即便不按上述流程合成咱们也能很好的实现，但对于简单的问题，如果没有成体系的办法作为参考，那事件就很难做成。在日常工作中，即使是小的事件，咱们也能够按这种流程推动来造就本人做事的能力，这样在遇到简单问题时，就可能很从容的做到抽丝剥茧，化繁为简。 STARSTAR是一种帮忙讲述故事的法令，能够让问题的形容更加清晰易懂，在面试过程中经常应用。STAR法令是情境(situation)、工作(task)、口头(action)、后果(result)的缩写。 情景：事件产生的背景和环境； 工作：承当的工作或职责； 口头：为了实现目标采取的措施； 后果：最终失去的成绩；学会STAR法令能够帮忙咱们更好的表白，让他人更好的承受。既要能做，也要会说！ 帕累托准则帕累托准则又叫做二八准则，用于量化投入与产出之间的关系。意大利学者帕累托发现社会财产在人口中的调配是不均衡的，20%的人占用了80%的社会财产，而这种不均衡景象在社会中普遍存在，因而二八准则就成了这种不均衡关系的简称。了解帕累托准则，能够帮忙咱们抓住问题的外围，通过优化外围的20%达到80%的成果。 长尾实践长尾实践和帕累托准则相同，认为80%长尾能够积攒成很大的份额，针对长尾进行优化有很大的晋升空间。对于帕累托准则和长尾实践的利用，须要结合实际场景进行剖析，两种实践没有对错之分，只是在适合的工夫做适合的事。 交付形式MVPMVP（Minimum Viable Product）即最简化可履行产品，其核心思想是每次交付给用户的是一个最小可用的性能汇合，依据交付后的用户反馈一直迭代，并最终转化成一个残缺的产品。通过这种形式可能以最低的老本疾速进行产品验证，防止投入大量资源后再进行产品方向调整。 思维形式六顶思考帽“六顶思考帽”(Six Thinking Hats)是爱德华·德·波诺(Edward de Bono)博士开发的一种思维训练模式，或者说是一个全面思考问题的模型，提供了“平行思维”的工具，防止将工夫节约在相互争执上。其核心思想在于从不同的角度思考同一个问题，每次只思考一个方面。它用六顶色彩不同的帽子作为比喻，把思维分成六个不同的方面，使每一个人在思考问题时都能够表演六种不同的角色。 第一性原理第一性原理最早来自于古希腊哲学家亚里士多德，他说：“在每个零碎中存在最根本的命题，它不能被违反和删除。”马斯克十分崇拜第一性原理，他曾说过：咱们使用“第一性原理”思维而不是“比拟思维”去思考问题。咱们在生活中总是偏向于比拟--他人曾经做过了或者正在做这件事件，咱们就也去做。这样的后果是只能产生细小的迭代倒退。“第一性原理”的思考形式是用物理学的角度对待世界的办法，也就是说一层层剥开事物的表象，看到外面的实质，而后再从实质一层层往上走。 SCQA麦肯锡大法——金字塔模型中一个结构化表达方法，即情境（Situation）、抵触（Complication）、问题（Question）、答案（Answer）。在应用SCQA时，并不需要严格依照“情境-抵触-疑难-答案”的程序进行表白，而是能够调换程序以适配不同的表白格调和情绪，个别能够分为以下4种模式： 规范式：（SCA）情境-抵触-答案； 单刀直入式：（ASC）答案-情境-抵触； 突出忧愁式（CSA）抵触-情境-答案； 突出信念式：（QSCA）疑难-情境-抵触-答案。 指标治理OKROKR中O示意指标Objective，KR示意要害后果Key Result。OKR自下到上聚焦，驱动员工进行翻新，并在组织中共享，公开通明，能够让整体员工对组织的指标有明确的理解。OKR需持续性更新反馈，并结合实际业务进行调整，让组织和员工及时理解指标停顿及危险。 KPIKPI即要害绩效指标（Key Performance Indicator)，是通过对组织外部流程的输出端、输入端的要害参数进行设置、取样、计算、剖析，掂量流程绩效的一种指标式量化治理指标，是把企业的战略目标合成为可操作的工作指标的工具，是企业绩效治理的根底。和OKR相比，KPI自上而下合成，更多关注后果，所有都须要以指标模式进行量化。KPI和OKR能够联合起来应用，KPI负责考核，OKR负责过程治理，KPI相当于仪表盘，OKR相当于导航软件。 SMART指标必须是具体的（Specific）； 指标必须是能够掂量的（Measurable）； 指标必须是能够达到的（Attainable）； 指标必须和总体目标具备相关性（Relevant）； 指标必须具备明确的截止期限（Time-bound）。 策略剖析PESTPEST是一种次要用于行业钻研的剖析工具，通过从政治（Politics）、经济（Economy）、社会（Society）、技术（Technology）几方面进行钻研，能够帮忙咱们从宏观环境中更为系统地剖析企业所面临的情况。 SWOT分析法SWOT剖析将与钻研对象相干的外部的劣势（ Strength ）、劣势（ Weakness ）和内部的机会（ Opportunity ）、威逼（ Threats ）等通过考察的形式列举进去，再把各种因素互相匹配并进行系统分析，从而得出迷信论断。应用 SWOT 进行剖析时，能够遵循四点准则。准则一：投入资源增强劣势能力、争取机会（ SO : 最大与最大策略）；准则二：投入资源增强劣势能力、减低威逼（ ST : 最大与最小策略）；准则三：投入资源改善弱势能力、争取机会（ WO : 最小与最大策略）；准则四：投入资源改善弱势能力、减低威逼（ WT : 最小与最小策略） 用户增长数仓分层数据是进行数据分析最根底的因素，而数据仓库用于存储不同起源的数据。通常，数据会定期从事务零碎、关系数据库和其余起源流入数据仓库。构建数仓时个别可将数据分为四层，别离为原始数据层（ODS）、公共明细层（DWD）、公共汇总层（DWS）、利用数据层（ADS）。 ODS层保留所有操作数据，不对原始数据做任何解决，要保留数据的原始性；DWD层的数据是经由ODS层数据通过荡涤、转换后的明细数据，满足对标准化数据需要。如对NULL值解决，对数据字典解析，对日期格局转换，字段合并、脏数据处理等；DWS层数据按主题对数据进行形象、归类，提供业务零碎细节数据的长期积淀。这一层是一些汇总后的宽表，是依据DWD层数据依照各种维度或多种维度组合，把须要查问的一些事实字段进行汇总统计。能够满足一些特定查问、数据挖掘利用，面向业务层面，依据需要进行汇总；ADS应用层是依据业务须要，由DWD、DWS数据统计而出的后果，能够间接提供查问展示，或导入至关系型数据库中应用。这一层的数据会面向特定的业务部门，不同的业务部门应用不同的数据，反对数据挖掘。海盗指标—AARRR概念介绍AARRR是McClure在2007年提出的，专一于获客(Acquisition)的用户增长模型，因为其爆炸性的增长形式通常又被称为海盗模型，其本质由Acquisition (获取)、 Activation (激活)、 Retention (留存)、 Revenue (收益)和 Referral (流传)5个阶段组成。 ...

by zhimaxingzhe from 如何接手他人的零碎-遗留零碎重建之道法术器势志 欢送分享链接，转载请注明出处，尊重版权，若急用请分割受权。 https://zhimaxingzhe.github.io前言成熟的公司会有大量的存量零碎，程序员不免接手别人开的的零碎。万一不小心接手的零碎过于腐烂，祖传代码难以破译，一边吃力不讨好艰巨保护老零碎，一边在下面做新业务，出了问题要背大锅，一头包，难有好问题，满身疲乏，终成大冤种。本文尝试探讨如何接手遗留零碎的方法论，重建遗留零碎的道法术器势志，使得遗留零碎跟上组织内零碎演进和满足业务需要，逐渐从泥沼中走脱。 什么是遗留零碎？接手他人开发的零碎，能够是各种起因导致的零碎建设、保护工作的交接，对于接手人来说就属于是遗留零碎；严格意义上来说任何已存在的零碎都能够是遗留零碎。 接手一个遗留的零碎并非肯定要重建它，如果是一个行将辞别历史舞台的零碎，咱们没有必要探讨，只须要把它“送好最初一程”即可。本文探讨的领域是遗留零碎将要长期退役上来，并且会在下面倒退更多业务，长出新性能的零碎，也就是图中将遗留零碎变成一个现代化的零碎。 那么首先，在拿到交接的资料中根本理解零碎后，咱们从业务需要、零碎性能、零碎框架，特地是对系统设计有了整体的意识之后，咱们就应该思考一个问题，该零碎是否合乎古代零碎的要求，技术上应该连续现有设计，还是重构、重写、重搭、迁徙。如果是连续现有零碎设计，则本文往下就没有必要再往下看了。 当你认为该零碎切实是烂，交到你手里保护你就要做大冤种了，这个时候就应该思考重建该零碎的办法（套路）了，最好能做到私人订制。如何能做到私人订制？咱们从业界成熟方法论说起，再以笔者教训实战状况，总结梳理出能抡的三板斧。心愿能帮忙到各位，若有帮忙，请一键三连。 以术载道，以道驭术，以法固道，长于驭器，勤于练术，术器生势，趁势成志。本文的内容较多，先来一览目录，源道法术器势志都蕴含哪些内容，随后再具体开展陈说。 一、源起-为什么要重建首先要明确重构的动机，把动机详分明，痛点在哪，拿进去和组内的同学一起探讨，切记要主观。是零碎框架太老旧？还是零碎架构难以为继？还是有很多坏代码的滋味？还是因为零碎太过简单，没方法短时间内理解到全，出于处于懈怠，抉择回避？还是遗留零碎太过腐烂，历经N手开发人员后，基本没有人员、文档、任何资料能撑持起你去意识该零碎，导致你无奈从旧零碎中取得常识，所以想要尽快与遗留零碎划清界限？ 01、遗留危险 1.业务不能满足倒退从业务角度来说零碎的能力无奈反对业务倒退的须要，功能设计落后于业务倒退，须要革新现有性能的能力。 2.零碎能力不能满足倒退如零碎部署架构不能满足业务规模的倒退，无奈撑持用户量、访问量。 3.新需要交付工夫长在不理解的零碎上做需要会遇上或多或少的未知状况，须要在一直踏坑、填坑中调整，实现工作的工夫须要一直加长，交付工夫经常比预估的要长。 4.缺点多，到处救火团队长期处于救火状态，每天白天做消防员，早晨做施工员。不论是业务团队还是技术团队都处于较大压力的工作环境中，长期以往精神状态会受到影响，不利于团队建设。 5.交付周期不可控，业务无奈按期发展因为第3、第4点导致交付工作的投入有余，须要缩短排期打算，无奈及时上线新需要，新业务也无奈按计划发展。 02、研发价值1.研发老本高居不下 这个不言而喻，不须要解释了吧。 2.架构落后古老 如利用是单体的，须要集群化、微服务化、分布式化。 3.模块设计不合理 模块间边界不清晰，开发人员不能很好辨认模块分层，不能正确安顿类的寄存门路，导致模块边界越来越不清晰，远来到闭准则。如采纳MVC架构，没有严格依照MVC模块划分准则，controller 调用 dao的状况；采纳DDD架构，domain之间有相互调用的状况等。 4.模式设计凌乱 模式设计乱用，没能联合业务来正确应用设计模式，导致接口拓展矛盾重重。 5.代码腐烂 代码年久失修，堆积成山。 6.新增、批改代码艰难 N代的祖传代码，每个开发人员都依照本人的用意增加代码，远离繁多职责，接手人想要增加一个简略批改，却须要同时思考N多种状况。 7.没有足够的测试 遗留代码没有写测试用例，没有用例代码，代码不可测试，或者没有足够的测试用例验证已有性能的正确性。 8.没有足够的常识（人/文档） 团队中找不到对系统足够理解的人，可能此前的开发团队成员全都来到了，或者只有多数不理解全局状况的人员留下来了，或者组织架构调整，零碎没有追随人员变动调整，全都交给了新的团队来负责。没有跟上零碎现状的文档，没有能够理解零碎现状状况的文档，甚至没有文档。 9.难以定制让人释怀的交付打算 对于不理解的零碎，始终会有坑在前头，打算赶不上变动，何况这些坑就不是打算的一部分。 10.界定批改带来的影响 A: 一处小批改，把零碎搞垮了？批改前怎么不评估影响？ B: 我不晓得这点批改会影响到另一个模块，没有文档没有正文，我甚至不晓得那个外围模块有依赖这里。 A: 没做集成测试？ B: 只改了这点，单测没问题，在这个模块范畴下也是没有任何问题的，所以没有做全局的测试。 A: ...... 11.难以管制交付危险 既然不晓得影响，那就更不晓得交付进来的产物是不是牢靠的，如果经常出现问题，会打击团队士气，开发人员信念会丢失，兴许终日都在放心线上跑的代码会出问题，变成祷告式开发，神学运维，玄学经营。 03、业务价值让业务可能衰弱倒退，或者能够从新设计零碎性能。不被技术债连累，不被古老技术限度倒退，无效牢靠的交付周期，更牢靠更现代化的业务能力，用户体验更好。 04、重建危险重构若不做好危险管制会带来难以管制的危险的状况下。须要列出危险TODOLIST，盯紧危险因素在重构过程中的解决状况。 还有一种非凡的危险是重写后的代码与原来的十分类似，因为要思考简单的需要场景，为了防止这一问题，就要从旧零碎吸取到足够的常识，来判断该性能的实现是否河里了。这里除了从浏览代码、查找文档之外，最好的形式是从构建测试开始，依据测试来理解性能\接口的行为。 1.工作量超预期 重建自身是简单的工作，须要依据零碎就地取材设计方案，遇到意料之外的状况也是常态，工作量超出预期就不言而喻了。 2.卡住业务倒退 无奈按期交付，以后重构带来的变动使得零碎版本没方法交付业务需要。因为不能在重构的版本上做业务需要的开发，如果在重构前的版本上开发业务需要，又会导致业务代码在交付后还要合并到重构版本上，带来联调、测试、验收、验证等工作量；如此一来，团队取舍艰难，从而可能卡住业务倒退。 3.逐渐变成老零碎的样子 有的时候看到整个模块十分复杂，容纳了十分多的状况，逻辑点十分多，接口代码简短不堪，开始着手重构，但越重构越发现新的实现越来越靠近老零碎的实现，因为要实现的业务场景自身就是很简单的。 4.切换后回退艰难 重建带来的批改，在研发的各个阶段都可能导致回退，一些较高层面的重构回退的老本也会升高，导致回退难度大。如将零碎架构从新布局，本来处于特定业务畛域的服务该当积淀为根底服务，在公布后发现实际效果带来更多问题，还不如原来的形式解决来的简略；又如将模块从新划分，将局部接口实现迁徙到更内聚的模块中，之后又做了接口代码的批改，增加了许多类，在对理论状况更加理解后，认为这些接口归属在原来的模块下是更加正确的；此时想要回退就会比拟麻烦。如批改了代码的目录构造后，又批改了接口代码，此时想要保留接口代码的批改，还原代码目录构造就不能通过退回来实现。 还有更麻烦的奖数据库重建后，新库在线上运行遇到较多问题，此时如果没有做好退回的方案设计，将会陷入两难地步。 05、重建老本软件开发总成本 = 开发成本 + 保护老本；软件维护老本 = 了解老本 + 批改老本 + 测试老本 + 部署老本。若是没有梳理重构老本，会导致工作总是超出预期工夫。 ...