这些年，在互联网我学到的一些强大的思维模型

写一份高大上的IT简历，需加一些产品概念

可能你看到很多市面上的IT简历，都会写成下列这种款式：

栗子1错误打开方式：

• XX（全栈工程师）2013.06 — 至今

• 参与需求分析及实现方案设计。

• 设计数据库表结构，实现后台功能及web页面展示。

• 产品线上部署及运维。

• ay 配置管理工程师 2010.03 — 2013.03

• 负责公司产品性能测试，及线上数据分析

• 负责公司配置管理，环境维护等工作

点评：看不出来他做的什么事情，没有逻辑性，甚至不知道他做的什么技术语言。

或者是这种款式比较多：

软件架构：Maven+SpringMVC+Mybatis+Spring+Solr+CentOS+Nginx+Quartz+POI等

这种款式是最不推荐的，其实可以来想下这个问题，接简历的对象是谁？一般是hr并非懂技术的人员，写太多的技术架构会有这些问题：

a.没重点

b.对方是个hr，并不懂技术

c.一开始就把自己懂的技术亮点亮太多，没起到欲擒故纵的效果；

d.一个朋友曾给我说，如果是写技术堆叠式的描述，会让别人觉得没有多少项目经验；因为一个有多年经验的IT对于项目、产品有着自己的理解和认知。

栗子2正确打开方式：

北京XXX    

java大数据工程师— 2013.4月-2015.12月

1、负责实时流消息处理应用系统构建和实现

• 在调研了kafka的优势和我们的具体需求之后,用kafka作为消费者,保证高吞吐处理消息,并持久化消息的同时供其它服务使用,进行了系统的设计和搭建使用。本地日志保证消息不丢失,并通过记录游标滑动重复读取数据。

• 使用storm 负责搭建消息处理架构,并完成基于业务的消息落地,提供后续的数据 统计分析实时和离线任务,诸如pv、uv等数据,为运营做决策

• 网站用户行为埋点和基于js的日志收集器开发,定义接又和前端部门配合。主用go 2、hadoop集群搭建和数据分析处理

2、基于CDH的集群搭建工作,后期进行维护

编写MapReduce程序,能将复杂工作逻辑化,尽最大能力发挥大数据应用的特点, 对程序高要求,监控自己程序运行情况,使用内存合理,注重增量和全量运算的利弊

3、调度系统设计与实现 基于quartz2搭建调度平台,带徒弟实现相关功能并定期review代码

4、数据库调优 负责主从搭建,并掌握主从搭建的利弊,了解业界mycat原理,有数据库优化经验,能 正确并擅长使用索引,对锁有深刻的认识

5、网站开发 java web网站业务开发,并能很好的使用缓存技术,对重构有实际的经验,并对面向对 象开发有全面的实战经验。了解java数据结构的使用场景,虽然对于大并发没有太大的 发挥余地,但是掌握了数据结构,对于并发和阻塞等有自己的见解。

点评：非常清晰的告诉简历阅读者自己做了什么事情，负责了什么样的事情，用了什么技术栈，且逻辑连贯。

    其实在媛姐看来，想要写好一份简历，其实刚开始梳理自己做过的项目的时候，或者平常在工作中，就可以从产品角度为起点来梳理项目最终落地到技术。任何技术的产生或者公司的技术落地都是基于产品，用户的痛点，必须搞清楚技术最后落地后，能解决用户什么需求，什么痛点，所以简历基于需求背景去写。梳理出功能实现、技术模块，然后去告诉阅读者自己在哪块模块，做了什么事情，用了什么技术栈，这就是一个很好的简历，比简单的技术罗列会好得多。

       当然如果能加上一些自己已经做的，能够量化的增加公司收益的数据，会更加好。

02

—

面试、工作汇报，STAR法则助力

STAR法则,即为Situation Task Action Result的缩写

具体含义是:

Situation: 事情是在什么情况下发生

Task: 你是如何明确你的任务的

Action: 针对这样的情况分析，你采用了什么行动方式

Result: 结果怎样，在这样的情况下你学习到了什么

  总而言之，STAR法则，就是一种讲述自己故事的方式，或者说，是一个清晰、条理的作文模板。不管是什么，合理熟练运用此法则，可以轻松的对面试官描述事物的逻辑方式，表现出自己分析阐述问题的清晰性、条理性和逻辑性。

        这个法则在媛姐看来是个很强大的思维工具，包括在面试和工作汇报中都可以应用。比如在面试中，hr肯定是喜欢一个面试者能够逻辑清晰地表达自己过往项目中所承担或者负责的模块，在整个项目中的产出以及技术经验的输出。

比如面试用STAR法则：

说明自己过往的项目经验，这个项目是在解决什么用户痛点下产生，我的任务是怎么派出或者明确的，针对这样的架构或者技术安排，我做了些什么，达到了考核，并且做了哪些优化。在当中，个人学习或者提升了哪些认知。

比如STRA法则进行工作汇报：

需要将工作或者项目，按照场景，任务，行动和结果的方式进行描述。对每一个项目，“场景”需要描述清楚项目的背景，“任务”需要描述清楚在该项目中面临的任务和目标，“行动”需要描述清楚，面对这样的场景和目标，你都采取了哪些行动来达成和实现目标，“结果”需要描述清楚你取得的结果，以及对项目目标的达成情况。

以这样的方式进行汇报，可以将我们做的项目比较清晰的汇报出来。但是，有时候，我们面临的问题，可能是我不知道自己都有哪些项目。这里，你可能会疑问，怎么可能连自己都有哪些项目都不知道呢？

这里说的项目，并不仅仅指一个软件开发项目，项目也可以是你日常工作中做的一些零散的，甚至是每天都做的事情。我们需要对日常工作进行总结提炼，找到日常工作可以分类的方式，让每一个分类中的琐碎事件，具有一个统一的目标。通过这种方式，可以帮助我们从日常工作中提炼出项目来。

03

—

数据指标分析落地，需要一个麦肯锡金字塔思维

     

      金字塔原则（Pyramid Principles）源于Barbara Minto在麦肯锡早期的研究工作，是一项层次性、结构化的思考、沟通技术，可以用于结构化的写作过程。虽然这个思维模型只是用于写作，但是现在演化为被众多的数据分析人士用来设计指标和指标拆解，进行落地。

常见的数据指标分析思维三大利器是：结构化，公式化，业务化

结构化思维

结构化思维就是麦肯锡提出的著名的金字塔思维，通过找到核心论点（可能是假设，问题，原因等），结构拆解（自上而下将核心论点层层拆解成分论点，上下之间呈因果关系），相互独立，完全穷尽（MECE），避免交叉，尽量完善；验证：都是可量化的，可验证的，用数据证明。分析问题的标准程序：收集信息--描述发现--得出结论--提出方案。其实这个模型就和从结果出发，然后一步步地倒倒推出原因，是一致的。

举个例子：现在有一个线下销售的产品，我们发现8月的销售额度下降，和去年同比下降了20%。我想先观察时间趋势下的波动，看是突然暴跌还是逐渐下降；再按照不同地区的数据看一下差异，有没有地区性的因素影响；我也准备问几个销售员，看一下现在的市场环境怎么样，听说有几家竞争对手也缩水了，是不是这个原因。

用结构化思维梳理，就是：

       用这种方式思考，能确保思考的点成体系，逻辑严谨，要素相互之间不凌乱不打架，思考的点都穷尽。

      长期练习这种方法，不仅更容易找到逻辑结构，也更容易培养你的结构化思维。

       这几天梳理非结构化数据，请教一个老师核对下发表结构文件，老师教了一个特别有效的思维模型，用来调整表结构，即使是EXCEL表结构字段的调整，因为公司的业务很特殊，做的是教育这块的，学位建设的。在整合几个excel文件的数据到一个文件中时，会有很多相似字段、数据冗余，而且字段顺序有待调整。老师在我面前一顿操作猛如虎，我顿时明白了，老师的底层逻辑其实就是基于故事线、情景线的逻辑。

比如：教育专题中的项目，那么就可以围绕这个故事线来展开，将字段合并、顺序调整，显得特别有逻辑性，在什么年份、国家开展了一个什么项目，有着什么项目编号，这个项目现状怎么样？投了多少资金，在什么地块，占地多少面积，解决了多少学位问题等等。

可能这种故事线思维，常常是产品经理们用的一个思维模式，但是在我看来，在数据库的表设计、数仓主题设计中其实也适用。当然技术有技术的做法，也得考虑表关联，还有主键、三范式，还有数仓模型是选择星型、还是雪花型、星座模型等问题。

      这些好做法或者好礼仪，来源于项目经理、产品经理的传授，作为一个IT人，不仅仅要把技术要搞好，商务沟通这块也要学习下，和其它方才能有效沟通，或者说不会出现技术和产品打架的悲哀。

1.  尽量尊称对方为老师或者XX工或者XX博(每个人都是渴望被尊重),IT都喜欢直爽地去表达，可以试着用更柔和的语气去表达，比如多带些客气的词语等；

2. 感恩对方的所做，即使是对方的份内之事；

3. 如果手里头的问题都是针对于同一个人对接，可以在短期内汇集到一起，那么尽量汇集到一起，一起汇报对接，集中处理，对方会更加接受或者效率更高；

4. 向领导或者他人汇报结果、原因，先说结果、再说原因1、2、3；

     5. 尽量先找自己团队的资源，比如要客户基本信息邮箱等，再找对方要这个信息会更好些；

     6. 关于数据、文件涉及敏感信息的，微信群里确认信息后，最好邮件发给对方，这样避免更多的人接触到敏感信息，保证数据的安全性。

最后分享一句，我最喜欢的一句话，来自前百度产品架构师俞军的一句话，俞军，曾任百度产品副总裁、首席产品架构师，网名“搜索引擎9238”，有“百度贴吧之父”之称。

追求质量，不做没思考的东西。     ---俞军

让我们有更多的深度思考，让自己未来更好。