工作中的方法论

论如何高效且有质量的处理工作

• 目的 预测 实践 反馈
• SMART原则构成
  • 绩效指标必须是具体的（Specific）
  • 绩效指标必须是可以衡量的（Measurable）
  • 绩效指标必须是可以达到的（Attainable）
  • 绩效指标是要与其他目标具有一定的相关性(Relevant)
  • 绩效指标必须具有明确的截止期限（Time-bound）

其它待整理的方法论

• 大圈小圈：指导职场晋升的方法论
  • 影响圈是自己本质，是基础；关注圈是扩展区域，是下一步发展；只有把影响圈做好才能进一步扩大影响圈；
  • 虽然关注圈对你当下的绩效产出往往没有很明显的价值，但是只有提前关注关注圈，你才有机会，也才有可能扩大影响圈。
  • 所以，当你抱怨“自己怀才不遇”的时候，请首先反思的问题是：我当下的“影响圈”做到极致了吗？
  • 80% 的精力 用与关注影响圈内部，20%的精力用于关注影响圈外部
• 721原则 ：指导个人发展的方法论
  • 技能获得：70% 是由实践获得，20% 是学习获得，10% 是培训（被指导）获得。
  • 推论一：最快学习路径是：优先选择学习，能够立刻或者即将实践的知识或技能
    • 推论看似简单，但是周围，往往有很多人都没有注意到这一点；比如他们往往更注重于：更前沿知识（专刊、博客），而忽略了那些能够直接在工作中实践的知识点。
    • 一个人的从小白成为某项领域的专家，所需要学习的知识会非常多；如果你规划好整体学习知识点后，其实如何让自己快速的成长，就是一个路径选择问题。
  • 推论二：请不要尝试，只通过学习或者培训方式，能够掌握某项技能或者成为某方面的专家
    • 如果你想尽快真正的成为某方面的专家，这个方法告诉你的是：最重要的首先要考虑如何实践或者哪儿可以找到实践机会
• 人无完人：自我驱动的方法论
  • 简单说解决方案有：向上、横向、向下沟通问题收集；横向对比，和高阶同学对比思考差距在那里；思考学习哪些知识来开拓自己的当前面临的视野局限问题等等
  • 第一层循环：在层次内，提升的过程
  • 第二层循环：是突破层次的瓶颈，达到上一个层次的过程
• 抽象问题具体化，具体问题抽象化：解决实际问题的方法论
  • 1、在问题分析时多从全局观进行思考，而不是局限在问题本身。
  • 2、问题最后抽象到的最后只有两类：技术问题 or 管理问题（流程）。切忌把一切问题都归到“人的问题”上

如何思考与有效工作

• 该如何更高效地工作，怎样才能把时间和精力尽可能地放在处理本质复杂度的事情上，减少在偶然复杂度上的消耗

我们在哪 我们要去哪 我们怎么去 这种方法论

• 如果一个人能够清晰地回答出这三个问题，通常意味着他对要做的事有着清晰的认识
• 优秀程序员的开发效率是普通程序员的 10 倍

四个思考原则

• 以终为始
  • 真正的目标
• 任务分解
  • 分解越细致，工作越轻松
• 沟通反馈
  • 是为了疏通与其他人交互的渠道。一方面，我们保证信息能够传达出去，减少因为理解偏差造成的工作疏漏；
  • 另一方面，也要保证我们能够准确接收外部信息，以免因为自我感觉良好，阻碍了进步。
• 自动化
  • 就是将繁琐的工作通过自动化的方式交给机器执行
  • 形成完善的层次，完善到可以自动化代码生成

当面对一个新需求时

• 为什么要做这个特性，它会给用户带来怎样的价值？
• 什么样的用户会用到这个特性，他们在什么场景下使用，他们又会怎样使用它？
• 达成这个目的是否有其它手段？是不是一定要开发一个系统？
• 这个特性上线之后，怎么衡量它的有效性？

总结

• 大多数人工作低效是由于工作中偶然复杂度太多造成的，只要能够更多地将注意力放到本质复杂度上，减少偶然复杂度造成的消耗，我们“真实”的工作效率自然会得大幅度提升。
• 我们不是一个人孤独地在工作，而是与其他人在协作，想要做到高效工作，我们就要“抬起头”来，跳出写代码这件事本身。 所以，程序员解决的问题，大多不是程序问题。
• 面对问题 现状 目标与路径

五级工程师理论

第五级工程师

• 能够独立设计和实现一项功能的人

• 这是对工程师的基本要求，如果一个人只是懂一点工程实现的手段，需要别人告诉他怎么做，那最多算是助理工程师或者技工。虽然能独立写出一项功能，关于业务的内容完全都是问需求经理啊，技工是说的好听，其实就是最底层开发人员，以后要加强工程师的概念，努力向上一级跃进。

第四级工程师

• 需要有些产品头脑

• 在做一件事之前，要知道所做出来的东西是否有用 、易用，是否便于维护，是否性能稳定，等等。除了要具备产品设计方面的基本知识，还要具有一定的领导才能，能在整个产品的生命周期从头到尾将一个产品负责到底。这在很多硅谷的公司里，基本上是一个高级工程师所应有的基本素质。对大部分工程师来讲，这些素质不是一个工学院就能培养出来的，而是需要在工业界实际锻炼三四年甚至更长时间。当然。个别天赋很好的年轻人在学校里就具备了这种素质，但这是可遇不可求的。

• 这需要长时间的锻炼和自己的悟性，这个阶段的工程师就像是组内的开发组长、系统架构师之类的角色，对技术使用纯熟，并有产品经理的素质，会从用户角度考虑产品的易用性，会从运维工程师角度考虑系统的可维护性，会从下批搞二次开发的程序员角度考虑系统的可读性与可扩展性等。这个确实需要时间和精力去锤炼技术水平和产品意识。

第三级工程师

• 可以做出行业里最好的产品

• 他们与第四等工程师有着质的差别，这不仅反映在技术水平、对市场的了解 、对用户心理的了解以及组织能力等诸方面，而且也反映在悟性的差异上。当然这种悟性很多是后天培养出来的，但这就需要更长的时间了。有些人从工作一开始，可能需要十年八年，经过多次失败，不断总结，终于在某个时间点豁然开朗。而另一些人可能非常幸运，在一开始就有幸和最优秀的人一起工作，加上善于学习，五六年下来就能达到第三等的水平。在硅谷，有极少数工程师只花了五六年时间就达到了这个水平。但是即使一个人再聪明，基础再好，也需要在工程上花够足够的时间才能达到这个水平，一个年轻人工作了四五年就开始做行政管理工作，基本上就和这个水平无缘了。

• 到这一级别的工程师，由于心智坚定加上长期的刻苦努力再加上个人的天赋和一些机遇，终于一飞冲天。都说机会是给有准备的人的，这类人其实就是被机会垂青的一类人，因为他们确实有准备，也准备的很充分。他们是行业内的佼佼者，对技术、产品都有自己的一套感觉、系统，都有自己独到的认识，并做出过业内称赞的产品。我觉得在一等的工程师里也可以分三等，初级、中级和高级。初级就是经过自己的长期努力，对技术掌握扎实，对新技术也有很快的理解能力和应用能力，能够胜任一般公司产品经理、CTO的角色。中级就是在初级的基础上，加上了个人的艺术修养，加上了个人长期经验、经历、感悟的总结，形成了一套完整的对技术、产品、美学、用户、包括市场的基础正确的认识，这超越了大多数技术好的工程师。这一级别高段位的工程师，就有点需要借助些小的时运了，比如刚好移动互联网兴起，刚好加入移动互联创业公司，刚好开发出了能行业执牛耳的产品。

第二级工程师

• 刻意给世界带来惊喜的人

• 比如实现第一台实用化个人电脑的沃兹尼亚克(这个在池老师的《跨越边界》里有专门一章讲他，并他合照)、DSL之父约翰西奥菲、iPhone和Google Glass的总设计师，以及前面提到的鲁宾、迪恩等。他们与第三、四等工程师的差别在于其工作的原创性以及对世界的影响力。当然他们的工作不是科学研究，这一点和科学家毕竟不同。

• 关于这一点，吴军博士还专门介绍过硅谷的公司有多元的文化，开发产品会立足于世界，多语言版本不会比英语版本晚六个月。因此公司的很多产品就是世界级产品，还提到微信的国际化走的不顺畅，只是在国内是爆品。

第一级工程师

• 开创一个全新行业的人

• 历史上有爱迪生（直流电等）、特斯拉（交流电等）、福特，二战后有保时捷博士、本田宗一郎和硅谷的诺伊斯（集成电路等）等人。这些工程师不仅在技术和产品等各个方向与第二等工程师有质的差别，而且在经验和管理上也是好手，他们通常是企业家，并通过自己的产品改变了世界。这一类人常常是可遇而不可求的，正如朗道列出的第一等物理学家只有个位数一样，第一等的工程师也是如此。朗道认为每一等物理学家之间的贡献相差十倍，每一等的工程师差距也是这么大。当然很多企业家都希望能够遇到一些第二等甚至第一等的工程师，这就需要由工程师构建的完整金字塔：要想出几个第一等的工程师，就需要有足量的第二等工程师作为基础；同样，产生第二等工程师要靠大量的第三等工程师为基础。在一个产业里，不可能指望在一大堆第五等工程师的基础上突然冒出一两个第一或者第二等的工程师的。甚至有时，即时高薪聘请来一个第二等的工程师，如果没有第三、第四等的工程师与之配合，他也很难直接依靠第五等的人做出一流的产品。

• 第一等的工程师，完全是和推动人类文明进步最有力的人归为一类的，他们永远是时代的先行者，时代的开拓者，处于时代的浪潮之巅。

• 和马斯洛的五层需求理论类似，永远都是一级依靠一级，每上层级都需要大量的下一级作为支撑与配合，然而在大多中国IT企业里，大家喜欢当领导，也有许多在选择做技术还是管理两者间纠结的人，所以在第五等工程师上会有断层，影响到产品开发的质量和原创性。

以终为始

• 遇见事情，倒着想，远见不是天生会有的，不断预测，失败后加以复盘，整理自己思维误区才能走的更远
• 构建一个共同的想象
• 测试驱动开发，
• 践行“以终为始”就是在做事之前，先考虑结果，根据结果来确定要做的事情。
• 向后工作的方法，开发一项产品的顺序为：
  • 写新闻稿；
  • 写 FAQ（常见问题解答）；
  • 写用户文档；
  • 写代码。
• 拿到一个需求先写接口文档，评审过了再开发代码。争取做到接口文档就是最终的实现方案，不需要做着做着再去沟通方案。而不是拿了需求文档，直接就写代码。
• 定好目标后，倒推时间表，安排好每一步要做的事情。梳理出关键节点，提前发现问题。

对于完成的定义不一致

• DoD 对于完成的定义 Definition of Done
  • DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况。
  • DoD 的检查项应该是实际可检查的。
  • DoD 是团队成员间彼此汇报的一种机制。别把“汇报”想复杂了，最简单的汇报就是说一句“这个功能做完了”。
  • 当我们有了 DoD，做事只有两种状态，即“做完”和“没做完”。
• 它不仅局限在团队内部协作上，如果你可以放开思路，会发现 DoD 的思维在工作中用途非常广泛。
• DoD 是一个的思维模式，是一种尽可能消除不确定性，达成共识的方式。
• 人与人协作，总会有这样或那样的理解差异。开始协作之前，我们最好先同步一下彼此的理解，确保之后不会因为理解不一致，而让协作方措手不及.