思维

download：受用毕生的产品思维无密分享内置文档哈希表查找哈希算法的定义与实现1哈希表查找定义哈希技术是在记录的存储地位和它的关键字之间建设一个确定的对应关系，使每个关键字对应一个存储地位。 存储地位=f(关键字) 对应关系称为哈希函数，也称为哈希函数。 哈希技术用于将记录存储在一个间断的存储空间中，称为哈希表或哈希表。哈希技术不仅是一种存储办法，也是一种搜寻办法。 Hash函数可能将两个或多个不同的关键字映射到同一个地址，称这些状况为抵触，而这些抵触的不同关键字称为同义词。 2哈希函数的构造方法3.1间接寻址办法对于关键字age，能够间接用age的数量作为地址，其中f(key)=key。 如果要统计1980年当前出世年份的人口，如下图所示，能够用年份减去1980作为出世年份关键字的地址。此时f(key)=key-1980。 间接关键字去除的线性函数值是哈希地址，哈希函数是: 间接寻址法的哈希函数简略、对立且不会引起抵触，但须要当时晓得关键字的散布，所以实用于小而间断的查找表。 3.2除法和余数法除余数法是结构哈希函数最罕用的办法。假如哈希表长度为M，取一个不大于M但最靠近或等于M的素数P，哈希函数为: 假如咱们有12个记录的关键字来结构哈希表，例如，咱们应用新办法，所以它存储在下标5处。 依据教训，如果哈希表长度为M，通常P是小于等于表长度的最小素数(最好靠近M)或者是不蕴含少于20个素数因子的合数。 解决哈希抵触的3种办法3.1凋谢地址办法3.1.1线性检测办法开放式寻址办法是一旦有抵触就寻找下一个空的散列地址。只有哈希表足够大，总是能够找到空的哈希地址，并且记录将被存储。 在一个简略的例子中，咱们的关键字集是，表长度是12。咱们应用散列函数。 计算前五个数时，都是哈希地址，没有抵触，间接存储。 计算key=37时，发现与25的地位抵触，于是从新计算，37存储在下标2的地位，如图。 当key=48时，咱们计算出和12所在的地位0抵触。持续算，和25的地位抵触，所以始终到都没有空缺，如图。 这种解决抵触的开放式寻址办法称为线性检测办法。 二次检测那时候叫二次检测法。减少正方形操作的目标是为了避免所有关键词都汇集在某个区域。 伪随机检测在有抵触的状况下，用随机函数计算位移，称为随机检测法。 3.2链接地址办法为了防止非同义词的抵触，所有的同义词都存储在一个线性链表中。 对于可能导致许多抵触的散列函数，链办法提供了不会找到地址的保障。 4哈希表的搜寻哈希查找依赖于三个因素:哈希函数、解决抵触的办法和填充因子。 填充因子表中记录的哈希表长度。 哈希表的均匀搜寻长度取决于哈希表的填充因子，而不是间接取决于或。 越大越满，抵触的可能性越大。 4.1哈希表搜索算法的实现哈希表的构造定义如下: 定义胜利1定义不胜利0define HASHSIZE 12 /将哈希表长度定义为数组的长度/定义NULLKEY -32768typedef int状态；/ Status是函数的类型，其值是函数后果状态码，如OK等。/ typedef构造{int elem/数据元素存储基址，动态分配数组*/int计数；/以后数据元素的数量/}哈希表； int m = 0；/哈希表长度，全局变量/哈希表初始化: /初始化哈希表/状态InitHashTable(HashTable *H){int I；m = HASHSIZEh-> count = m；h-> elem =(int )malloc(m sizeof(int))；for(I = 0；我h-> elem[I]= null key；退货OK；}作为哈希函数的余数办法: /哈希函数/int Hash(int key){返回键% m；/除法和余数法/}哈希表插入算法: /将关键字插入哈希表/void InsertHash(HashTable *H，int key){int addr = Hash(key)；/查找哈希地址/while (H->elem[addr]！= NULLKEY) /如果不为空，则抵触/{addr =(addr+1)% m；/凋谢寻址办法的线性检测/}h-> elem[addr]= key；/插入关键字，直到有空格为止/}在代码中插入关键字时，首先计算哈希地址。如果以后地址不是空关键字，则示意存在抵触。此时咱们应用线性检测的凋谢寻址办法进行重寻址，这里也能够改为链地址法等其余抵触解决办法。 ...

download：借助产品思维解决人生难题（含实际方法论+剖析工具）在java中应用中断来告诉线程进行失常进行螺纹公共类RightWayStopThreadWithoutSleep实现Runnable { @笼罩公共有效运行(){int num = 0；而(！Thread.currentThread()。isInterrupted() && numif (num % 10000 == 0) {System.out.println(num+"是1W的倍数")；}num++；}System.out.println("工作实现了！");} 公共动态void main(String[] args)引发InterruptedException {Thread Thread = new Thread(new RightWayStopThreadWithoutSleep())；thread . start()；//期待1sthread . sleep(1000)；//告诉进行线程thread.interrupt()。}}复制代码应用thread.interrupt()告诉线程进行。然而线程须要合作:应用thread.currentthread()。isinterrupted () in while来检测线程的以后状态。运行后果:…………21730000是1W的倍数。21740000是1W的倍数。21750000是1W的倍数。21760000是1W的倍数。21770000是1W的倍数。21780000是1W的倍数。21790000是1W的倍数。21800000是1W的倍数。工作实现了！ 过程完结，退出代码为0复制代码进行线程，以防它被阻塞。公共类RightWayStopThreadWithSleep {公共动态void main(String[] args)引发InterruptedException {runnable runnable =()--> {int num = 0；while(数字if (num % 100 == 0) {System.out.println(num+"是100的倍数")；}num++；}尝试{//期待1秒模仿阻塞。thread . sleep(1000)；} catch (InterruptedException e) {System.out.println("线程曾经进行！!");e . printstacktrace()；}}; Thread thread =新线程(runnable)；thread . start()；//等待时间应小于下面设置的1秒，否则线程会在执行到下一个thread.interrupt()之前完结；明码thread . sleep(500)；//告诉进行线程thread.interrupt()。}}复制代码在线程休眠1秒的过程中，中断信号被中断，在线程睡眠期间响应中断的形式是抛出InterruptedException。运行后果:是0到100的倍数。00是100的倍数。200是100的倍数。30是100的倍数。线程进行！！中断异样:睡眠中断at java.lang.Thread.sleep(原生办法)在进行线程处。rightwaystopthreadwithsleep . lambda＄main＄0(rightwaystopthreadwithsleep . Java:19)位于Java . lang . thread . run(thread . Java:748) ...

文章来源于优普丰麻利教练 Scrum，作者王洪亮大锤前言一页纸需要是指的业务方在提需要的时候篇幅很短的状况。有的时候极其状况下，原始需要只有一句话，甚至只有几个字。比如说：“开四限四“就是一个涵盖了十分多的要求的一种需要。 一页纸需要会让很多 BA 感到困惑。BA 也晓得一页纸需要表白的不全面，然而须要迷信的剖析才可能将细节进行欠缺。否则就会变成散点式补充需要内容，也无奈确认本人补充的内容是否残缺。站在业务方的角度来看，一页纸需要兴许是他们尽可能提出的最全面的内容了。业务方因为非 IT 背景，可能想提出更多的内容也无能为力。因而，须要 BA 承当对应的职责，将一页纸进行裁减欠缺。 个别状况下，BA 会通过头脑风暴的形式来梳理一些问题，向业务方提出问题，取得答案。然而头脑风暴的形式在这里可能施展的作用无限，即便是问了很多问题，依然不晓得本人是否梳理了所有该梳理的场景，是否还有场景脱漏。因而须要一个有条理，有脉络的形式进行一页纸需要的剖析。从而可能疾速而无效地建设起整个需要文档，以推动开发工作。 应答一页纸需要，大锤梳理了一个五步法，失去广泛应用，并且妥善的解决了一页纸需要的问题。五步法是指通过业务价值、角色梳理、术语定义、主业务流程梳理、纲举目张详细分析的形式进行需要剖析。 当 BA 接到一页纸需要时，能够依照五步法需要分析法进行： 五步法示意图 第一步应要确认该需要的业务价值，通过业务价值来判断该需要的外围性能以及确认需要的优先级。当前的需要都要围绕着这个业务价值进行开展剖析，这样才可能聚焦，才晓得设计的性能是否必须的，是否可能帮忙实现对应的业务价值。同时也可能判断对应的业务价值实现的形式是否迷信。 第二步应答该需要中所波及的角色进行梳理。很多时候因为短少对角色的梳理，并不可能正确的了解在业务中，各种角色如何实现本人的工作以达到实现业务价值的指标。如果脱漏了某些角色，那么会导致最初业务无奈闭环运行的结果。另外也可能因为角色梳理的缺失导致需要剖析后果的不正确。比如说，某个角色的性能都开发了，却短少了对应的性能入口。 第三步对需要的术语进行定义。在一些我的项目中可能波及业余词汇术语，因而在后期明确术语的定义，前期在与客户确认需要性能时，能够对立用词习惯。不会呈现一词多义或者一意多词的状况。并且，术语定义能够为开发工程师和测试工程师提供对立的用语，为开发过程的沟通效率进步奠定根底。并且因为术语定义的环节可能将术语的含意讲清楚，也对后续的需要剖析了解产生了不可磨灭的重要作用。 进行完前三步后，应答主流程进行梳理。一般来说，一页纸需要当中会蕴含必要的乐观门路的形容。通常形容主流程不会特地艰难。然而缺失往往都在于乐观门路，边界条件等环节，因而第五步，通过纲举目张的形式对需要的细节进行梳理补充。纲举目张示意渔民晾渔网的时候，将渔网挂起来之后，渔网的孔就会天然的张开。引申到写文章的时候，文章的纲要要是先定义好了，文章的内容天然就清晰了。同样的，在剖析需要的时候如果可能对于细节环节的梳理形式有个总体脉络，就能够清晰地梳理出各种隐含的需要。第五步能够包含：边界思维、对称思维、异样思维、发散思维、关联思维、并发思维等各种思维形式的利用，以梳理出各种需要的细节。 1. 业务价值1.1 什么是业务价值解决他人违心花钱解决的问题，就是业务价值。它通常是市场、企业、用户三方能够取得的价值主张，联合组织战略规划以及产品/我的项目生命周期进行定义。 1.2 业务价值解决的问题1.2.1 发现潜在需要干系人提供的原始需要可能蕴含的信息不充沛，如果 BA 照搬就可能产生场景脱漏，然而如果 BA 可能思考业务价值，从用户角度登程剖析需要，就会发现潜在的需要。因而咱们须要明确组织业务指标和价值，之后的剖析都围绕这个指标开展。 1.2.2 划分需要优先级需要的排序首先应该是按照业务价值来进行的，联合市场的趋势、产品所处的生命周期阶段、组织以后的产品/我的项目组合策略、研发的投入老本等进行综合思考。依据业务价值能够帮助咱们更好的对需要进行优先级划分。 1.3 如何实现业务价值1.3.1 建设业务指标BA 在进行需要剖析的过程中，会有很多想法和见解，但如果无奈将其进行串联和推动，那就会忙于交付而不晓得为什么交付。一般来说业务指标会有：赚钱、省钱这两大方向。赚钱又分为间接盈利（比如说：促成销售）和间接盈利（比如说：进步访问量，用户粘性等）。 1.3.2 满足外围业务首先要满足外围业务，才可能确保价值的交付。然而外围的业务辨认是一个绝对较为有难度的事件。其实现形式也有很多种。之后会撰写文章讲述如何辨认外围业务。比方在贷款业务中，还款模块能够分为：失常还款，提前划款，逾期还款，坏账还款等多个场景，而失常还款是最外围的业务。 1.3.3 满足正确优先级划分优先级的分级最为常见的是按紧急、重要关联词构建。下图是常见的优先级划分形式，然而如果不把握更具体的形式，就会陷入到，不晓得该如何排序的地步。咱们会在另外的文章中讲述如何进行正当无效地需要排序。这里先理解基本概念。 在用四象限法时同时，咱们要了解优先级划分的外围所在是最好的需要优先级还是跟着业务走。因而咱们也须要思考以下几个问题来对优先级进行判断： 1) 不做 - 是否会造成重大的问题和顽劣的影响？ 2) 做了 - 会产生的益处以及实现的指标？ 3) 是否跟外围用户利益无关？ 4) 是否跟大部分用户权利无关？ 5) 是否跟效率或老本无关？ 2. 角色梳理2.1 什么是角色梳理明确定义参加到业务和系统活动中的所有角色。 2.2 角色梳理解决的问题角色梳理能够帮忙咱们差缺补漏，缩小忘记场景的问题。存在有可能不应用零碎，然而对系统却有很大左右权的潜在角色。比方：老板给 HR 买了一套考勤打卡零碎，他不打卡，然而他却要关注如何通过打卡系统管理员工。 2.3 如何进行角色梳理2.3.1 进行角色剖析零碎为哪些类型的用户提供服务，他们都各自承当哪些不同的职责，并据此定义零碎边界，也就是零碎是对事实世界哪个范畴的内容进行的模仿，这影响到需要设计和实现的范畴以及工作。 2.3.2 利用角色性能矩阵进行梳理在需要剖析中，咱们能够利用角色性能矩阵进行角色梳理，角色-性能矩阵将角色和性能进行正交排布，从而梳理那个角色能够执行哪个性能。 ...

思维是架构师的根底吗？2021-8-12的了解应该是说实话，模板办法模式太简略，抽象类这货色也太根底广泛，个别应届生都会晓得。然而对于初入职场的新人来说，还真不太能果决利用在理论生产中。因而揭示各位：肯定要有一个抽象思维，防止代码冗余反复。 另外，要再啰嗦几句，即便工作有几年的工程师也很容易犯一个谬误。就是把思维局限在明天的需要，比方老板一开始只给你一个mysql数据源查问的需要，压根没有if-else，可能你就不会放在心上，间接在一个类中写死，不会思考到后续的扩大。直到前面越来越多的新需要，你才豁然开朗，要全副重构一番，这样节约本人的工夫了。因而揭示各位：做需要不要局限于明天，要思考到将来。 从一开始就做到高扩展性，后续需要变更和保护就十分爽了。 Java的23种设计模式，每一个都是经典。明天咱们就用模板办法模式+工厂模式(或者反射)解决了让人解体的if-else。Spring是附属品，能够用Java的原生反射机制 摘自：https://www.cnblogs.com/liuya...

简介：为后果买单，为过程鼓掌。作者：不拔每年各个部门都要进行布局，布局能让指标更聚焦，让咱们清晰地晓得今后咱们要做什么、如何去做。并非每个人都会参加布局中去，但须要把握布局的办法，否则让你来做布局时，你会发现很苦楚，找不到什么脉络，要么布局进去的内容都是散点，要么布局进去的太形象。在本篇文章中，提到了布局的2种思维模式，并分享本人在布局中用到的4个布局办法，让开始做布局的你显得不那么迷茫。 你应该学会布局布局不只是高层的事布局不仅仅是高层的事，每个人都要学会布局，只是每个人布局事件的格局不一样，高层做战略规划，上面的人做战术布局。布局也是分档次的，有战略规划、部门布局、团队布局、集体布局，站在每一层中，你看到的内容是不一样的，个别都是高层布局蕴含底层布局，底层布局撑持高层布局。有些人认为布局是主管的事，本人只有依照布局去做事就行，这是一种被动承受干活的心态，你很有可能不理解做这件事的背景是什么，要解决什么问题，深层次的指标是什么。当你的输出更多时，你所做的方案设计也就不一样了，技术选型也会不一样，架构设计也会不一样。 布局具备重要的意义笔者认为布局有三个重要的意义： • 聚焦指标：布局一个最为重要的作用就是让指标更清晰。团队里的人晓得要做什么，有一部分人感觉迷茫，很大水平是指标不分明，如同晓得要做什么事，又不晓得如何下手。这个指标可大可小，小的方面就是要实现一个我的项目或一个需要，大的方面就是要建设一套体系。笔者已经就有这样的切身经验，有一段时间显得十分迷茫，不晓得本人要做什么，人一迷茫就会焦虑。一旦有这样的状态，就要思考是不是指标不够清晰，指标度量是不是不够细。当指标明确之后，大家"心向一处想，劲往一处使"，这样的工作状态效率是十分高的，团队的气氛也是十分好的。 • 洞察背地逻辑：布局进去的内容是后果，最为重要的是思考为什么要做这些事，背地的逻辑才是外围。剖析以后的现状、痛点、业界倒退情况等，联合业务自身，去做一些决策、取舍。不同的人思考出发点不一样，大家在一起碰撞时，会有一些的想法闪现进去，也是思维的交换。咱们做事不仅仅要懂理how，更要懂得why，当把why讲清楚之后，how也就是瓜熟蒂落的事，往往咱们的一个困惑是不晓得why。 • 通晓将来方向：布局有短期布局，也有长期布局，个别笔者是先思考长期布局，思考3年之后，咱们要具备怎么的能力，再回到短期上，咱们当下这个阶段要做到怎么的水平。有些事不紧急，但很重要，能够放晚一点做；有的事十分重要，又什么紧急，优化级就要进步。 当咱们晓得了方向之后，即便当下没有去做一些事，也晓得未来咱们要做成什么样。以笔者的过往经验，一个团队有一两年的长远规划之后，团队里的成员达成共识之后，这个团队在一两年内是稳固的，因为大家晓得两年之后咱们会做成什么样，远方始终有一个指标在照亮着咱们，大家一起致力一直迫近那个指标。 布局的2种思维演绎思维布局应用的第一种思维是归纳法，这是大家最罕用的办法，个别是从现状登程，去思考当下有哪些问题、业界是怎么做的等等，从这些输出中去演绎咱们须要去做什么。比方当下工单征询比拟多，那么就须要对工单进行分类，如演绎成产品设计问题、程序代码问题、依赖方问题、交互设计问题，针对每类问题，再去思考咱们应该要做到哪些工作。在店铺平台建设中的布局中，咱们就梳理了当下的一些痛点问题，如平台只有一些根底的能力，没有给业务方提供弱小的能力撑持，那么接下来就要增强店铺能力建设，丰盛店铺能力。 演绎思维有一个毛病就是就事论事，解决了表层的问题，比方竞品有什么，咱们没有该项能力，是不是咱们就要去做同样的事。演绎思维要配合深度思考一起做规划设计，真正挖掘出咱们当下的痛点是什么，比方一个工单，用户只会提出他遇到了什么问题，此时就要深入分析它的root cause，有的时候一个清晰的提醒文案就可能解决了用户的问题。 演绎思维布局应用的第二种思维是演绎思维，演绎思维是一种更高级的思维模式，它须要一个人对事物有十分粗浅的意识，当洞察出了底层的法则之后，再去思考咱们要做什么。个别的人并不习惯用这种思维模式，它对人的要求十分高，一旦把握之后，布局也就容易得多，很多科学家更偏差应用演绎思维。 在店铺布局中，笔者就使用了演绎的思维。比方在布局之前，笔者就思考两个问题：店铺的实质是什么、店铺要提供的商业价值是什么。当把这两个问题想分明之后，沿着价值方向去思考咱们应该要给用户提供怎么的能力，这是一步一步推导进去的。店铺的实质是一个"场"，它连贯了卖家和买家。 针对这两种角色，卖家最为关注的是怎么应用得好店铺，蕴含应用得爽、店铺转化好；买家最为关注的是怎么通过起码的钱、起码的工夫买到心仪的商品。沿着卖家和买家关注点，持续思考咱们怎么让卖家用得爽、用得好呢？其中一个点是咱们要晓得卖家当初有哪些不好的体验，肯定要能度量得进去，而不是定性地去剖析，当定量地度量出体验指标之后，这样就十分有针对性去做一些体验优化工作。站在买家的角度，能够给买家一些优惠，让他更违心购物，这也即是咱们布局店铺营销的初衷。 布局的4个办法同类思考办法同类思考的办法是通过以后一个的点，去思考还有没有并列的事物。比方在优惠体系中，优惠券是十分常见的营销伎俩，那么就要思考，有没有与优惠券等同的营销伎俩呢？这样思路一下子就关上了，除了优惠券外，还会有积分、奖励金、卡等，这样就造成了卡、券、分、金的根底优惠体系。同类思考的办法是最简略的，也是最容易实际的，只有在现有的事物上，进一步去思考同类事物就行。它最好的特点就是丰盛能力，尤其在平台型业务建设的过程中，丰盛能力始终是一个重要的布局，当把同类的能力都补齐之后，整个平台的能力就十分丰盛。同类思考的办法除了用在布局上，还能够用在解决具体的问题上，比方，咱们承受到一个工单：创立店铺时提醒"service error"，这个提醒就十分技术化的表白，用户基本不晓得出错的起因是什么。那么就要思考，在其它的交互流程中，是否也有相似的问题，咱们在解决问题时，不要只单点地解决问题，至多要造成一条线，解决一类的问题。 升维思考办法升维思考的办法是往向形象一层，屏蔽上层的实现细节，实质来讲是简化意识和晋升意识的维度。还是回到下面优惠的例子，有了优惠券、积分、奖励金这些优惠工具，内部业务零碎怎么去感知呢？不可能每次新减少一种优惠能力，还要让业务侧去感知，如交易在下单时，要扣减优惠金额，十分不好的体验是交易别离去调用优惠、奖励金零碎的接口，往后只有新减少一种优惠能力，交易扣减逻辑就要批改，显然不合乎"开闭准则"。解决这个问题就要应用到升维思考的办法，往上形象优惠计算的能力，交易、导购只用关注优惠计算接口就行，至于有多少种优惠它并不关怀。 升维思考十分有用，再比方优化卖家店铺装修体验，咱们能想到一些具体的措施：优化交互、优化流程、减少用户文档等。然这些具体的措施对晋升卖家装修体验是有益处的，但有一个问题咱们始终没有定义分明：到底什么在影响着卖家装修体验？换句话讲，咱们须要晓得影响卖家装修体验的定量指标，只有把定量的指标找到之后，就十分有针对性去做一些体验优化的工作。 升维思考的格局比同类思考的格局要大一些，同类思考只是站在同类的维度去思考还有什么，而升维思考站在的维度更高，它能够往下拆解出不同的子项进去，如稳定性建设，它能够拆解出稳定性监控、稳定性预案、稳定性应急解决等等。如果说同类思考是横向思考，那么降级思考就是纵向思考，这两者联合在一起就造成了一个立体。 降维思考办法降维思考的办法与升维思考的办法相同，它是往下一层去思考。这种办法比拟实用于指标十分明确的场景，去思考具体要去做什么事。比方店铺营销，它相当是一个命题，店铺营销须要哪些能力去撑持，如何体系化地表达出来就十分重要。降维思考更像是一种逆向思考，指标曾经有了，怎么去推导须要哪些能力去撑持，这些能力就是须要去建设的。回到例子自身，店铺营销，至多要蕴含：店铺优惠、店铺互动、店铺投放、店铺权利履约、店铺触达，还能够往下细分去思考每块的内容，如店铺互动，须要思考有哪些不同的店铺互动类型，常见的有新人进店支付优惠券、关注店铺支付优惠券、玩游戏支付优惠券等，一层层地往下细化，整个体系就搭建起来了。 如果说升维思考更适宜做平台类的建设，那么降维思考就适宜场景类的建设，一个面向形象布局，一个面向具体布局。降维思考办法也是十分有用的，比方店铺域要用到营销能力，自身底层的营销能力又是营销域负责的，那么店铺营销能做的事就是将营销能力利用到具体的场景上，如关注店铺支付积分、积分兑换装修模板等等。 平台思维和场景思维是两个不同的思维形式，平台思维偏通用类的规划设计，更多的是使用演绎的思维，而场景思维是偏具体业务的规划设计，更多的是使用演绎的思维。 精专思考办法精专思考的形式是专一于特定畛域，将某一件事做到极致。比方做芯片，5nn就是一个技术挑战，在这个畛域没有足够多的钻研，是很难达到5nn的规范。精专思维利用到布局上，更多的偏差具体度量指标的晋升上，比方性能优化，RT从xx降到xx，QPS从xx晋升至xx……；研发效力，研发工夫从xx降到xx，效率从xx晋升至xx……；SLA从99.99%晋升至99.999%……这样的布局案例十分多，精专体现的是深度，当把根底的能力都建设得差不多之后，要么抉择更广大的空间，要么抉择做得更深，比方营销中怎么去预防资损就是一个深度问题，还有怎么去晋升研发效力上，是通过架构降级，还是流程改良，亦或是框架优化……，越往底层，对业余能力的要求就十分高。 降维和精专又是从另外一个角度去思考问题，和后面两种办法形成了平面的视角。如果布局中能灵活运用这四种办法，整个布局的内容就丰盛，既有广度的内容，又有深度的内容。 布局办法只是一个工具不要过分沉迷办法办法只是一种工具，让咱们更好地去工作，但咱们不能过分去强调办法，实质上还是要回归到业务意识上，正所谓"巧妇难为无米之炊"，同样的情理，对业务没有思考，空有办法也是没有用的。笔者的倡议是不同的人有不同的布局办法，真正汲取一两个人的办法之后，真正去实际，从实际中再总结出适宜本人的办法。不同的人对办法的表述不一样，实质上是大同小异的，真正把握4、5种办法就足够用了，不必贪多，把办法的原理、思路理解好了，多去实际，在实践中再去领会，多布局几次，你也就懂了。 业务深度思考才是邪道在上一节中也提到不要过分地沉迷于办法，深度思考业务才是邪道，个别懂一个业务是须要工夫的，要一直去思考业务的实质是什么，业务的商业价值是什么，从实质和商业价值中去寻找咱们的机会。比方笔者就花了很长时间去思考店铺的实质是什么，它的商业价值是什么，不论是业务实质还是商业价值都是简略的，如果不可能用一两句话讲清楚，很有可能你还没有深刻理解（有可能你晓得但没有表达出来）。 以店铺业务为例，站在卖家的视角，店铺给卖家的商业价值就是让卖家用得爽店铺、用得好店铺，用得爽就是卖家在装修店铺的过程中，他的体验是好的，这也是人情世故，你用一个货色，很用得不通顺，你也就不想去用它；用得好就是装修进去的店铺，买家更违心在店铺里购物，即转化率要高。 在布局时，应该多关注业务，多思考业务上的痛点问题、业务的实质、这个业务的初衷是什么，所要做事的方向就会清晰一些，咱们所做的布局肯定是有目标，解决一个痛点，解决一个难题，新减少能力……，背地是有决策依据的，当把背地的思考讲清楚之后，大家的指标感、方向感就会更清晰。 让布局落地布局能看得出一个人的格局不同人看到的问题不一样，所承受的输出信息也不一样，思维模式也不一样，因而不同人思考的出发点不一样，他所做也的布局也就不一样。有的人思考粗浅，思考周全，布局的内容十分有体系化；有的人专一于某一个畛域，一直摸索底层的问题，布局的内容十分有深度；也有的人思考得问题比拟繁多，布局的内容比拟零散…… 从布局进去的内容，能够看得出一个人的格局，这个格局或大或小，或深或浅，它间接影响着今后一段时间工作的方向。咱们更心愿有大格局的布局，就像国家有5年布局、10年布局、100年布局，能清晰地晓得咱们要驶向何方，将来是什么。布局的内容要有肯定的挑战性，去挑战一些未知区域的内容，这样也就有微小的劣势，在这个赛道上，很早就开始布局了，即便他人要追上来，也不是一两年的事。在这个畛域上放弃着领先地位。要达到这样的成果，相对不是漫无目的做进去的，肯定是很早就开始布局，一步一步走到明天才能够。 体系化的布局布局要体系化，而不是散点去布局，散点做事不成体系，东一榔头西一棒槌，散点布局并不能看出清晰的指标。比方在布局度量装修体验的度量指标时，它所蕴含的内容就十分多，如确定业务指标、业务指标拆解、数量埋点、接口监控、行为路径分析、问卷设计、实时反馈通道、指标相关性计算等，整个造成一个体系，从逻辑上是自洽的。不成体系的布局，往往会受他人的质疑，很显著短少一些能力撑持。 重点落地当有了布局之后，接下最为重要的就是把布局里的内容实现进去，咱们最为牛逼的就是一两年后把咱们当初设计的布局都实现的，那个时候是最有成就感。咱们布局的格局要大，同时落地要实，实实在在地实现布局的内容，否则即便布局再好，最终也不会有很好的后果，阿里有一句话："为后果买单，为过程鼓掌"。个别PM要承当项目管理的角色，把控我的项目进度，及时发现危险并且协调资源解决问题。以咱们团队为例，会有一些专项去落实布局的内容，做好需要剖析、方案设计，每周会有我的项目周报，跟踪我的项目进度和项目风险，没有治理的我的项目，延期的危险是微小的。原文链接 本文为阿里云原创内容，未经容许不得转载。

1. 什么是5WHY5why分析法，又叫5问分析法，是对一个问题间断屡次诘问为什么，直到找到问题的根本原因。这里尽管说叫5why，可是并不一定是真的问5个问题，有可能更多问题也可能更少，依据理论状况来确定。 那如何确定到底应该几个问题呢，那就是一直诘问上来，直到你的问题变得毫无意义为止。 5why法的关键所在：激励解决问题的人要致力避开主观或自负的假如和逻辑陷阱，从后果着手，沿着因果关系链条，顺藤摸瓜，直至找出原有问题的根本原因 2. 为什么要5WHY如果只是惯例的，浅层的思考，是很难发现问题的根本原因，那也就象征这你的解决方案，并不一定真正解决了问题。可能是当下解决了，而后某一天一样的问题又突然呈现。 3. 如何使用5WHY5why的概念很简略，其实就是中文的打破沙锅问到底的精力。可是要使用好5why分析法却是很不容易的。 咱们先看一个正确应用5why办法解决问题的例子：一个博物馆的东边外墙面上有十分重大的侵蚀，须要常常涂刷新的油漆。这一天，博物馆的主管发现墙面又侵蚀得很重大了，当初他须要决定怎么解决这件事件。 兴许，局部人的第一直觉是，那就再喷刷一次油漆呗。可是这个答案显然太浮浅了。咱们尝试着用5why分析法来剖析这个问题。 1.为什么墙面有十分重大的侵蚀？ -> 因为清洁工要用高侵蚀度的清洁2.为什么清洁工要用高侵蚀度的清洁？ -> 因为东边的墙上常常有很多鸟粪粘着，用个别的清洁剂洗不洁净。3.为什么东边的墙上有很多鸟粪？ -> 因为墙上有很多蜘蛛，而这些鸟以蜘蛛为食4.为什么墙上有很多蜘蛛？ -> 因为墙上有很多小虫子，而蜘蛛以这些小虫子为食5.为什么墙上有很多小虫？ -> 因为东面墙上有几扇窗子，早晨，博物馆里的光会从这里透出去，而这些趋光性很强的虫子就被光吸引过去了解决问题的正确办法应该是，在窗户那里装置遮光性很强的厚窗帘，每天太阳落山之前拉上窗帘，这样就能彻底解决问题了。 5Why分析法的注意事项:要朝着解决问题的方向进行剖析要找可控的因素多个起因的时候，每个起因都要剖析问问题要彻底应该是不带情绪的疑难，而不是质问小心逻辑谬误 （问和答之间）接下来咱们再来看几个背面的例子，更粗浅的理解如何应用5why。 3.1 要朝着解决问题的方向进行剖析例如：无尘室的灰尘量超标 为什么无尘室的灰尘量超标？ -> 灰尘是设施带来的为什么设施带来这么多灰尘？ -> 因为设施的挪动很多为什么设施挪动很多？ -> 因为工作量很大为什么工作量很大？ -> 因为订单增大为什么订单增大？ -> 。。。如果依照这个方向问上来，公司的经营就不要进行了。你会偏离主题越来越远，想要剖析出起因机会是不可能。 回到后面的外墙的例子，对于第4问“为什么墙上有很多蜘蛛？”，如果改成“为什么鸟要吃蜘蛛？” 那这个问题就开始偏离解决问题的方向了。 3.2 要找可控的因素要找可控的因素，基于组织外部，找外部的因素，而不是从内部找起因。对于找借口，内部因素等，这些都是不可控的因素 例如：小朋友在商场受伤 不好的例子：为什么会受伤？ -> 因为撞到商场固定玻璃门为什么撞到商场固定玻璃门？ -> 因为没有留神到后面为什么没有留神到后面？ -> 小朋友迷迷糊糊依照这个思路，你的解决方案很可能就是小朋友要进步本身警惕性，不要迷迷糊糊，这个显著不是咱们可控的。所以失去的解决方案是无奈解决问题的。 好的例子：咱们须要从可控的因素着手，比方外部的因素。咱们改成这样发问 为什么会受伤？ -> 因为撞到商场固定玻璃门为什么商场固定玻璃门没有爱护解决？ -> 。。这样咱们将会失去的解决方案是设置爱护栏杆，贴警示语 3.3 多个起因的时候，每个起因都要剖析不好的例子： 好的例子： 这样失去的解决方案才是残缺的。 3.4 问问题要彻底问的不够彻底，进去的不是根本原因。 不好的例子： 好的例子： 3.5 应该是不带情绪的疑难，而不是质问比方 “为什么会犯这种谬误？” ， “为什么不好好钻研窃密条款？”，“为什么窃密这样重要的工作没有引起你的器重？”这样的问题都是质问，而不是疑难，是不利于找出问题的根本原因的，须要防止。 ...

我的毛病&转变形式：非常容易受他人影响，我会想本人浪费时间，而后就感觉我做的不好，我会从踊跃转换为消极的态度。 改良：无论我做什么，或他人做什么，我的状态全是我本人决定的，你开心机体就会很无效的运作。你消极你的机体就会效率很低。受他人影响的起因是因为咱们把别的不是咱们的货色当成了是咱们本人货色，其实所有的外界的货色都不是咱们的不是吗？咱们须要的就是好好看看这个身材，把这个身材养好，平时口头和思考能够迟缓一点，给这个身材一个适应的工夫，你吃饭快是因为你不够理解这个身材，你不冥想因为你感觉这样浪费时间，不对，冥想可更无效的晋升你的思维境界。 不存在浪费时间一说，任何精进的常识都须要很粗浅的去了解，这个过程十分迟缓，不能急于求成，不要把注意力放在学习上，要把它看做晋升，乐趣，信奉。我会很容易受到思维的影响，我时刻把思维当成了我本人，我不是我的思维，思维为什么会产生这么多，因为咱们的大脑无自主的抉择，你要做的就是本人去专一你要思考的事件。

我的毛病&转变形式：非常容易受他人影响，我会想本人浪费时间，而后就感觉我做的不好，我会从踊跃转换为消极的态度。 改良：无论我做什么，或他人做什么，我的状态全是我本人决定的，你开心机体就会很无效的运作。你消极你的机体就会效率很低。受他人影响的起因是因为咱们把别的不是咱们的货色当成了是咱们本人货色，其实所有的外界的货色都不是咱们的不是吗？咱们须要的就是好好看看这个身材，把这个身材养好，平时口头和思考能够迟缓一点，给这个身材一个适应的工夫，你吃饭快是因为你不够理解这个身材，你不冥想因为你感觉这样浪费时间，不对，冥想可更无效的晋升你的思维境界。 不存在浪费时间一说，任何精进的常识都须要很粗浅的去了解，这个过程十分迟缓，不能急于求成，不要把注意力放在学习上，要把它看做晋升，乐趣，信奉。我会很容易受到思维的影响，我时刻把思维当成了我本人，我不是我的思维，思维为什么会产生这么多，因为咱们的大脑无自主的抉择，你要做的就是本人去专一你要思考的事件。

敏捷2001年2月11日至13日，在美国雪鸟滑雪胜地，17位软件大师聚到一起，讨论了各自提出的那些轻量级软件开发方法的异同点，希望总结出它们的共性，以及与重量级瀑布方法的不同之处。参会者们包括来自极限编程、scrum、动态软件开发方法、自适应软件方法、水晶系列方法、特性驱动开发、实效编程的代表们，还包括希望找到“文档驱动、重型软件开发过程”替代品的一些推动者。会议的最终成果就是《敏捷软件开发宣言》。同时还总结了敏捷软件开发方法的十二原则，它们包括：1、尽早地持续交付有价值的软件，以便让客户满意，这是优先级最高的事情2、即便在开发阶段后期，也欢迎需求变化。为了让客户获得业务竞争优势，利用敏捷来应对变化3、频繁交付可工作的软件，建议采用较短的交付周期4、在整个项目过程中，业务人员和开发人员能够一起工作一段时间5、围绕积极的个体，建立项目团队。给他们需要的环境和支持，并相信他们能够完成工作6、无论团队内外，传递信息效果最好和效率最高的方式是面对面交谈7、可工作的软件是项目进度的首要衡量标准8、敏捷过程促进可持续发展。项目主要干系人、开发人员和用户应该能一直保持节奏9、持续关注技术卓越和良好的设计，提高敏捷性10、以简洁为本，它是极力减少不必要工作量的艺术11、最好的架构、需求和设计会从自组织团队中涌现12、团队要定期的反思“如何变得更有成效？”然后相应地调整自身行为 敏捷软件开发方法不是一种体系完整的方法论，而是满足上述宣言及原则的一簇轻量级软件开发方法的集合 持续集成（CI）持续集成作为敏捷开发方法中的一个工程实践，率先被更广泛的IT组织所接受，即使那些没采纳敏捷开发方法的团队也会使用它，因为其强调的频繁自动化构建和自动化测试减少了质量保障团队的重复工作，也排出了开发团队与质量保障团队之间的沟通障碍。 CI场景起源于开发人员向代码库提交源码，CI场景中的步骤通常是这样的：1、首先一名开发者向版本控制库提交代码。同时集成构建计算机上的CI服务器正在轮训检查版本控制库中的变更2、在提交发生之后，CI服务器检测到版本控制库中发生了变更，所以CI服务器会从库中取得最新的代码副本，执行构建脚本，该脚本将对软件进行集成3、CI服务器向指定的项目成员发出电子邮件，提供构建结果的反馈信息4、CI服务器继续轮训版本控制库中的变更 CI的特征与版本控制系统的连接 版本控制库的目的是通过一个受控的访问库来管理源代码和其他软件资产的变更。为开发者提供了一个“单一源码位置”，这样所有的代码都可以从一个权威位置得到，还可以沿着时间回溯，取得源代码和其他文件的不同版本构建脚本 构建脚本是一段简单的脚本或一组脚本，可以利用它来编译、测试、审查和部署软件某种类型的反馈机制 CI的一个关键目标就是要提供集成构建的反馈信息集成源代码变更的过程（手工或CI服务器）CI的价值减少风险缺陷的检测和修复变得更快 软件健康程度可以测量：通过在自动集成过程中包含持续的测试和审查，这些软件产品的健康属性如复杂度等可以随时追踪 减少重复过程减少重复劳动的过程，让人们有时间做更高价值的工作； 通过对一些重要过程自动化，克服项目中某些成员对实现改进的抵制 在任何时间、任何地点生成可部署的软件增强项目的可见性有效的决策：CI系统可以对当前的构建状态和品质指标提供及时的信息，或者对缺陷率和功能完成情况的统计 注意到趋势：CI系统经常进行集成，我们就能够注意到一些趋势，例如构建成功或失败，总体品质以及其他相关的项目信息 持续交付（CD）DevOps运动DevOps的萌芽源于2008年8月敏捷大会多伦多站的一个临时话题“敏捷基础设施”。当时比利时独立IT咨询师Partrick Debois非常感兴趣，并且分享了关于“将敏捷实践应用于运维领域”。2009年10月，Patrick在比利时的根特组织了一个“DevOpsDays”社区会议，并正式启用了“DevOps”这个术语。 DevOps在维基百科的定义为：DevOps是一组软件开发实践，它结合了软件开发（dev）和信息技术操作（ops），以缩短系统开发生命周期，同时根据业务目标频繁地交付特性、修复和更新。 DevOps并非一个标准、一种模式或者一套固定的方法，而是一种IT组织管理的发展趋势，也就是说，通过多种方式打破IT职能部门之间的隔阂，改变IT组织内部管理的发展趋势，使之更紧密结合，从而促进业务迭代速度更快。这种发展趋势将会引起IT组织内部原有角色与分工的变化，甚至范围更大，会影响到相关的业务组织。对互联网公司来说，其软件产品对业务发展起到极其关键的作用，业务结果与IT效能强相关，因此顺应这一发展趋势的动力更加明显和迫切。 持续交付1.02006年，Jez Humble、Chris Read和Dan North共同发表了一篇题为“the Development Production Line”的文章，文中讨论了软件部署带来的生产效率问题，并首次提出“部署生产线”模式。如何使自动化部署活动更轻松有以下4条基本原则：1、每个构建阶段都应该交付可工作的软件，即对于中间产物的形成（例如搭建软件框架）不应该是一个单独的阶段2、用同一个制品向不同类型的环境部署，即将其与运行时配置分开管理3、自动化测试和部署，即根据测试目的，分成几个单独的质量关卡4、这个部署生产线设计也应该随着应用程序的发展而不断演进 持续交付1.0提供的很多原则及方法是DevOps运动的具体实操指引，它们可以为企业的IT团队将DevOps运动落地实施提供非常具体的指导。 从所涉及的角色来看，敏捷开发更多地涉及产品需求方、软件开发工程师、和软件测试工程师。DevOps更多地涉及软件研发团队（开发、测试工程师）与运维工程师，而持续交付1.0涉及产品需求方、软件研发团队和运维工程师。 持续交付2.0精益思想持续交付1.0关注从提交代码到产品发布的过程，并且提供了一系列工作原则和优秀的实践方法，可以提高软件开发活动的效率。但在实际场景中，一些软件功能在开发完成之后，对用户或者业务来说，并没有产生什么影响，有些功能根本没有用户来使用。这些功能可能花费了团队的很多精力才设计实现，这是一种巨大的浪费，这种无用的功能生产得越多，浪费就越大。 1996年Womack、Jones和Roos在《精益思想》中指出，精益思想是指导企业根据用户需求，定义企业生产价值，按照价值流来组织生产活动，使价值在生产活动之间流动起来，由需求拉动产品的生产，从而识别整个生产过程中不经意的浪费，并消除之。 2011年出版的《精益创业》其核心思想是，开发新产品时，先做出一个简单的原型——最小化可行产品，这个原型的目标并不是马上生产出一个完美的产品，而是为了验证自己心中的商业假设。得到用户的真实反馈后，从每次试验的结果中学习，再快速迭代，持续修正，在资源耗尽前从迷雾中找到通往成功的道路，最终适应市场的需求。 在精益管理理论中，浪费是指从客户角度出发，对优质产品与良好服务不增加价值的生产活动或管理流程。在归为浪费的活动中又包括必要的非增值活动，如质量检查，和纯粹的浪费，如因质量问题导致的返工。 双环模型持续交付2.0是一种产品研发管理思维框架。它将精益创业与持续交付1.0结合起来，强调业务与研发之间的快速闭环，以精益思想为指导，贯彻“识别和消除一切浪费”的理念，通过一系列工作原则与实现，帮助企业以一种可持续方式高质量、低成本、无风险地快速交付客户价值。持续交付2.0是一个从业务问题出发，到业务问题解决的完整业务闭环，它由两个相连的环组成：第一个环为探索环，其主要目标是识别和定义业务问题，并制定出最小可行解决方案进入第二个环；第二个环为验证环，其主要目标是以最快速度交付最小可行方案，可靠地收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动。

➢ 写作平均每天花费0.5小时-2小时的时间，可以依次发布到各大自媒体平台。 可以收集到的反馈有： 推荐算法的反馈，哪怕一开始什么观众都没有，算法也会按一定的数量推送给观众，如今日头条编辑审核的反馈，哪些是当前舆论下的敏感词，哪些是不能审核通过的内容。大数据统计的反馈，收集关于文章被阅读时的机型，受众，观看数，转发数，点赞，收藏等。读者评论的反馈，不同于基本数据，评论的内容来自读者的表达，有很强的自我意识。赞赏和广告的收入，没有什么比金钱来得实在，来得更刺激。相似的还有录制在线课程，写一个app产品等 ➢ 健身平均每天花费1小时左右的时间，建议优先采用跑步的方式来健身。 可以收集的反馈有： 跑完身体会有明显的饥饿感，吃饭更香，更容易接受吃水果，排斥油腻。跑完头脑会更加清新，身体会更有活力，身体的状态短时间会感觉很不错。跑完脸型立马会瘦一些，尤其是比较肥胖或者虚胖的人群，很明显看到变化。➢ 听歌建议无线耳机，方便随时随地听歌 手机里要有一些歌单，在不同的场景下，能够产生不同的效果。尤其是在工作中比较疲惫的时候，或者人比较丧的时候 ➢ 知乎、stackoverflow问答式社区 交流想法收集别人好的优秀的答案解决别人的问题➢ 饮食不只是饱腹。 吃的太少和吃的太饱都会让人身心疲倦，容易昏睡。心情不好的时候来一份冰淇淋或者火锅能让人立马好起来。多吃饮食和蔬菜让人保持精神好的状态，反之越油腻越影响身心。➢ 社群高质量才行，线下社区质量更优 社群的即时沟通社群的共同任务社群的其他机制➢ 学习快餐式学习，针对某个问题的学习 学习某些视频课程，解决某个实际中的问题，如重装电脑，PPT的制作等。看书，同上，如旅游指南，生活技巧，饮食烹饪，健身，学习方法，服饰搭配等。把别人花了很久的经验，在短时间运用，避免一些九死一生的坑 ➢ 记录和整理每天都有新的数据，也有垃圾要处理 对自我的数据的记录，财务，工作和生活上的事情等。对物品的整理，房间的收纳，虚拟软件、邮件和照片录音等。

题目：3X4的方格 从左上角A走到右下角B 只能向右向下走 一共有多少种走法？图形：题目转化为图形之后就是，从(1, 1)方格走到(3, 4)方格有多少种方案（每次走一格）？分析：1、根据题目我们知道只能往右走或者向下走，那么从(2， 4)格子走到(3， 4)格子只有一种方案，从(3， 3)格子走到(3， 4)格子也只有一种方案。2、以此类推，到某个格子A的走法 = A上面的格子走法 + A左边的格子走法；3、如果碰到第一行或者第一列的格子，那么走法只有一种4、如果碰到第一个格子，我们认为不需要走，即走法为0总结：1、这种把一个复杂的问题分解成若干个有相同规律的子问题的方法，我们称之为递归。2、递归由递归条件和递归出口组成，其中递归出口非常重要。3、分析中的第2点我们称之为递归条件。4、分析中的点3、4点我们称之为递归出口（返回明确的值）。代码：// N X M的方格 从左上角A(1, 1)走到右下角B(N, M) 只能向右向下走 一共有多少种走法？function calc(x, y){ // 坐标(1, 1) 递归出口 if(x == 1 && y == 1) return 0; // 坐标(x, 1) (1, y) 递归出口 if(x == 1 || y == 1) return 1; // 递归条件 if(x > 1 && y > 1) { return calc(x-1, y) + calc(x, y-1); } // 不符合条件，直接返回0 return 0;}calc(3, 4); // 10问题：根据上面的分析，我们知道在递归的过程中，会有很多重复的格子，非常浪费性能，当计算的数字越大，递归的性能也会越低，怎么提高递归的性能呢？下次我们再介绍（剪枝）。

阿里妹导读：不同岗位、不同职责的技术人对工程师思维的深度要求是不一样的，但从多维度去思考却应是每个技术人都应该具备的素养。本文整理自阿里巴巴高级技术专家至简在团队内部的个人分享，希望通过对工程师思维的分析和解读，让大家能正确对待那些在现实工作中看上去与本职岗位无关，却对团队效能影响极大的一些点和一些事。作者简介：至简，阿里巴巴高级技术专家，是集团Service Mesh方向的重要参与者和推动者。曾出版《专业嵌入式软件开发——全面走向高质高效编程》一书，坚信和倡导软件设计是软件质量之根本，并对软件开发的复杂性本质有着深刻的认识，对如何高质高效实施软件开发有着自己独到的见解和方法。在社会分工的背景下，软件行业的工程师群体被划分成了开发、测试、产品等诸多岗位，以协作的方式共同完成价值创造。高度依赖软件的互联网行业正以全新的方式改善着人们的生活，同时在改善的道路上对价值创造的效能提出了更高的要求，而背后是对个体与团队的协作效能有着更高的诉求。专人专岗的协作模式在进一步改善团队的协作效能时所面临的最大挑战在于“岗位墙”，即岗位间衔接不可避免会出现一些模糊地带，而这些模糊地带又很容易相互忽视，导致失去关注而很大程度地拉低了团队效能。比如，开发工程师会认为保证质量是测试工程师单方面的职责；开发工程师不关注用户体验而只需关注实现需求，等等。此外，这种协作模式也会固化个体的思维和心智模式，将个体的思维和心智框定在所处岗位之内，以致对于岗位之外的内容不能很好地理解，使得个体在整个协作活动中会缺乏同理心、系统性，从而影响工作幸福感。相信这些现实工作场景读者并不陌生：开发工程师对产品工程师所提出的用户体验方面的需求会认为过于吹毛求疵；产品工程师因不理解技术的实现原理而提出天马行空、不接地气的需求（我们在此不讨论创新这一特例）；测试工程师因为不理解工程效率的内涵而将自己的工作变成了体力活；开发工程师不清楚自己对于软件质量的责任，而将那些本因自己做好的琐碎工作心安理得地交给测试工程师去做；辛辛苦苦所开发出来的功能，用户抱怨难用。这些问题发生的最终结果，一定是团队协作效能的低下。那么在没有找到比专人专岗更好的协作模式的情形下，我们该如何发挥个体的力量去改善团队的协作效能呢？改善的起点在于全面地梳理工程师思维，帮助工程师个体在职场和职业发展中建立起更为全面的思维和视野，以促使每个工程师在协作过程中能最大程度地发挥个体能力去推动团队协作效能的提升。我将工程师思维分解为产品、技术和工程三大思维。每个维度主要关注的内容通过几个关键字去表达，如下图所示。下面针对每种思维需要关注的每个词以图中从上至下的顺序去解释。由于解释是基于关键词去展开的，所以段落之间的衔接可能会显得生硬，还请读者见谅。产品思维产品思维的起源是用户（或客户）价值。用户价值是通过技术手段以产品或服务的形态去解决用户的痛点，或带去爽点。毫无疑问，工程师在日常工作中应时刻关注并理清自己的工作与用户（或客户）价值的联系，并且应该通过聚焦于用户价值去安排工作的优先级和分配自己的精力。当用户价值足够时，产品能否在市场中立足并真正收获收益，首先考验的是产品的用户体验。良好的用户体验一定是站在用户的角度，基于用户心智来塑造概念，由于概念存在理解和解释成本，所以塑造的概念应足够轻、少且易掌握。概念一旦塑造出来则概念间的关系也随之确定，这些关系基本上决定了产品与用户的交互流程。好的产品体现于“易用”二字，其极致在于迎合用户的本能反应并符合各种生活或专业常识。所有产品都存在演进的过程，所创造的用户价值也在被不断地挖掘与探索，那时不同的细化价值需要通过产品特性去区分和表达。特性也是产品差异化的一种体现，特性也间接地确定了软件实现层面的功能模块边界。作为开发工程师，也需要对产品特性有非常透彻的理解，并能将其很好地抽象并转化为软件实现层面的功能模块。特性需要考虑通过售卖license等形式进行开启或关闭去实现售卖，这一点对于2B的产品甚是必要。为了产品更好地演进，需要通过数据闭环的形式去检验创造用户价值的效果，让产品的开发、运营、营销工作做到有的放矢。在产品价值创造的道路上，最害怕的事莫过于只顾低头干做加法，做得多却无人关心收效。而我们通过数据化闭环的形式，不仅能让整个产品大团队聚焦于核心价值，还能帮助团队在探索用户价值的道路上理性地做减法。大多情形下，做减法远难于做加法。技术思维技术思维的源头是需求。需求可以分成市场需求、系统需求、特性需求等不同层次，回答的是技术层面“做什么”的问题。显然，清晰表达的需求以及对需求的精确理解才能确保将事做对。毋容置疑，需求一旦出现偏差所导致的浪费是非常严重的，也正因如此工程师对于需求的质量相当重视。需求一旦确立，会基于模块化的思想拆分成多个功能模块去降低实现的局部复杂度，最终将所有功能模块“拼接”在一起去实现整体需求。每个功能模块会安排给一个人或一个团队负责，由于功能模块是需求分解后的产物，容易导致工程师在实现的过程中只看到“树木”而忘记了“森林”。性能是工程师在实现一个功能模块时不得不关注的，特别是当功能模块被运用于高频、时效性敏感、算力有限的场合时性能将尤其被关注。在现实中有时会存在工程师乐于追求性能的极致去体现自己的技术实力，甚至出现过早追求性能而滑入过度设计的误区。毫无疑问，一个正规的团队，对于功能模块的开发工作多会以项目制、多个迭代的方式去完成交付。不少工程师这里会有一个误区，忘记了敏捷思想所倡导的“项目计划的目的是为了适应变化”，而是将“按时交付”当作是天职，各种赶工爬到终点时却毫不意外地看到了“一地鸡毛”的景象。在迈向第四次工业革命的道路上，人工智能、大数据、机器学习，Kubernetes、Istio、Knative、Go、Dart、Flutter等新技术不断冲击着工程师已掌握的技能。快速跟上技术的迭代步伐是每个有追求的工程师不断提升自己专业素养的表现之一。工程师的内心一定不缺乏对新技术的追求，憧憬自己所掌握的技术具有一定的先进性。工程思维工程思维的起点是流程。流程的背后是科学，以既定的步骤、阶段性的输入/输出去完成价值创造，通过过程控制确保最终结果让人满意。由于流程涉及每一个工程师的工作质量与效率，其含义不只在于定义、工具化、检查等内容，而是应基于工程师的日常工作习惯，将流程与工程师的工作环境无缝整合。“无缝”体现于流程中的概念与工程师群体已建立的专业常识相一致、没有增加毫无价值的负担，根本仍是确保易用性。机制的含义是通过对所需解决问题的分析，以一种模式去解决同类问题。机制应体现一定的系统性，而非“头痛治头，脚痛治脚”。系统性不是一开始就能被洞察到，可能在演进的过程中逐步发现和完善的，因而需要工程师在工作的过程中不时回顾并付诸实践去落实。对于工程师来说，机制是通过系统性的软件设计去达成的。可以说产品质量直接决定了工程师的工作和生活幸福感。一个质量不可靠的产品一定会给用户和工程师自己带去麻烦，甚至造成无法挽回的经济损失并造成负面的社会影响。对于工程师来说，那势必打乱个体的工作与生活节奏。为了让产品的质量做到可靠，单元测试、静态分析、动态分析等确保工程质量的手段应成为工程师的基本工作内容，通过将这些手段与CI（Continuous Integration）流程进行整合去持续构建起对软件产品的质量信心。在互联网行业，除了软件产品的质量得可靠外，风险可控是另一个不能忽视的内容。而风险可控是建立于系统性机制和质量可靠之上的。对于服务端软件来说愈是如此。风险往往出现于资源使用的极端场景，当从外部涌入的过多事务远超软件产品的处理能力时，需要有一定的机制让整个产品能相对平滑地应对，或是扩充资源、或是限制涌入事务的流量。软件所需的机器成本是比较容易忽视的话题，软件成本不只与软件性能相关，还与软件之间的依赖、技术方案等因素相连。当一个软件需要从公司的内部对外输出时，平时忽视对成本的关注就会暴露出成本问题。比如，为了运行某个软件需要数量庞大的计算资源，所导致的资金开销对于客户来讲很可能是无法接受的。至此，大致介绍完了自己所理解的工程师思维。延伸了解工程师思维的价值在于，工程师个体需要在工作中逐步建立起产品、技术和工程三大思维，以便用更为全面的视角去看待日常工作中所面临的困境和困惑。当站在单一的思维去看待所面临的问题时可能觉得不合理，但从三大思维层面去审视时所得到结论可能完全相反。从团队协作的角度，只有团队中有更多的个体从多维度去进行思考，才容易发现岗位间衔接的那些无人问津的灰色地带，进而通过补位、助攻去更大程度地发挥团队的效能。显然，不同岗位、不同职责的工程师对于这三大思维的深度要求是不一样的，但从多维度去思考却应是每个工程师都应该具备的素养。最后，我也给读者留下一些问题，同样期待您在留言区分享自己的思考。本文作者：至简阅读原文本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。