很有趣，看了一下，刚好去年也是1月6号写的。嗯，2020，魔幻的一年过去了，如同每年一样，写个总结，既是回顾，又做展望。在去年的基础上，进一步分了三个篇章，回顾是对比2019年初的想法，看看2020年的思考有哪些延续性的不足；总结篇，如同上年度一样分成了方向，方法和技术的三段总结；最后是展望，对方向和技术的2020题一个要求

回顾篇-2020年的那些想法怎么样了：

2020年大概给自己定了技术和业务两个方向的目标，下面一个个分析一下

技术落地，CloudNative+AI增进工程效率提升

CloudNative的了解，相较之前应该有比较大的进步，微服务、DevOps、容器化、持续交付，除了一直以来想对比较深刻的持续交付意外，2020年对于微服务的学习和实践也日益加深了。

想了一下，2020年尝试了2个东西，一个是集成第三方公司邮件，通过自然语言读懂邮件，并将其结构化为需要的内容，这个在NLP领域被称为NER（named-entity recognition），看了些内容论文也因此大体了解了NLP领域常用的语义分析软件。但是很可惜停止在了数据集收集的地方。数据集始终没有准备好，这是个让人很头疼的事。确实也领略了当时有看到行业花大价钱去找人做表标示工作。这的确是个Lessons Learned。接下来这个方向肯定还是要做点什么，就这么放弃了感觉比较可惜。加油吧2021，需要给自己再plan一下

第二个是关于Menu的OCR，后来因为疫情就没继续。不过这块的确衍生出了接下来的Data方向，在数据vision上有了不少思考

业务思考

关于医生经纪人，算了吧，感觉目前还是没有这个动力去做。我觉得从技术出发做点事情可能会更靠谱一点。不过在此基础上，基本上明确了养老这个方向，当然这方向里设计很多上中下游的东西，而且我也知道这个方向不容易做。但是终归还是有这个心，希望做善事吧。接下来的更多思考肯定是做产品行业，还是服务行业

综合来看，2020面对疫情，整个工作出现了比较大的变化。所以在落地的工作方面却少了很多。但是思考的方面，却多了不少时间。所以还是有了不少的思考时间。包括学习了如何思考的方法，也是很不错的东西。

总结篇-2020自己取得了哪些值得骄傲的成就：

方法论：

• 今年的方法论核心应该是在战略安排上。今年最成功的事情是总结了技术上的stability strategy以及数据的Data strategy，这两个的总结提炼让我对与如何写一个让人看得懂的战略规划有了一个新的认识。在我看来这里可能需要分为如下的几个步骤

  • 根据远景定义核心目标，注意这个核心目标往往不是要解决某个问题，而是这个公司、部门或者这个方向存在的意义，比如技术就是提升研发质量，比如数据就是提供高质量、高价值数据

  • 将这种目标，增加需要执行目标的限定语句，比如对于提升研发质量，“Build sophisticated tools to Reduce developer mistakes significantly”，这里建立成熟的工具，就是后面降低错误的执行方法限定语句

  • 接下里的事情其实就简单了，那就是对这个限定语句进行解释和结构化。比如“Build sophisticated tools”，什么叫成熟的工具，这些工具的彼此支撑结构是什么。后面的东西就是我以前也表熟悉的规划了。特别是对于对词语的抽象能力，这是咨询师必备。

  所以我还挺兴奋于今年在战略规划上所学到的东西。因为以前我的工作模式比较偏线性，走到哪儿算哪儿，持续改进是我的长项。不过这次的战略策略实践，让我的视野上升了一层，有了更佳明确年目标级别的规划能力，这东西是一个产品战略能力，很庆幸！

• 提升质量方法论的进一步成型。从Code Protector，Scalable Protector到Process Automation，我觉得这三个的总结基本上涵盖了我现在触及到的形形色色的质量改进，并且关于Code Protector，有数据，有工具，有最佳实践，还是蛮成型的了。接下来可能更关注第二个吧，看看通过第二个的总结，2021年能有什么建树。

  

• 关于数据的理解以数据中台和DaaS数据业务为蓝本，虽然不一定完整，这里简单罗列一些吧，我相信这个也会在2021年有所演进

  • BI与BI成熟度模型
  • 数据分析师（data analyst）和业务分析师（business analytst）之间的skill set差别
  • 数据工程师（Data Engineer）和数据科学家（Data Scientist）实践中的交集与各自能力，以及他们需要处理的主要问题
  • 数据治理的困难以及如何提升数据质量的基本方法与指标

技术篇：

技术上，想象提升的的确比较少，找个借口就是可能数据那块儿想的比较多，确实看了不少书，也用了不少时间。但是这也不能算是接口，实话实说，刚刚过去的2020年，代码写的的确比较少。这一点可以从Github的提交记录可以看到，自从三月份以后，就鲜有提交了。归其原因也是AI这块儿一直没有突破，给自己比较强的挫折感。

如果一定要说2020学了哪些技术上的东西。我觉得SRE和微服务勉强算吧。之所以说是勉强算是因为自己不是亲身参与，更多的是从书籍以及团队的实践出发。但是这种实践，感觉上还远远不够。SRE嘛，我觉得还得再读，目前皮毛上，确实解决了我一些对于架构的衡量问题，但是具体下来的实际操作还是空白。这不利于给架构组定理合理的目标和预期。

展望篇-2021要干点啥：

方向上要思考的事情：

• 工程效率大方向应该不会有大的变化，我觉得目前让我百思不得其解的还是在为什么效率本身遇到的瓶颈问题。目前在40左右似乎遇到了非常大的瓶颈。我觉得接下来需要做更精细化的计算，计算到人，先把DO、研发和QA三个角色分拆开。总之得找到提升的核心问题。慢慢应该可以找到各个工种的效率，说白了就是要做细致

• 战略，2020可以说对于战略的规划有了实践，接下来需要一些书籍进行辅助和体系化，看看之前的实践有哪些问题，优缺点在哪里。从《好战略，坏战略》开始吧。之后进一步改造现有的战略安排

• 业务，就是养老这件事，继续。。。

技术方法论要提高的：

这个事儿还是得有些改变才行。立几个可能的flag吧

• Python转Go，Go的成熟度已经开始变高了，而且从外部判断来看，似乎对我而言更合适一些
• 容器化，做出两个Go容器吧，一个用来做web service，通过这个来学习一下基本框架的使用
• 把Protobuf要弄一下，刚好要做web service嘛，这个以后还是要自己搞过才行

附录本年度的主要工作结果

• NLP算法相关论文和材料目录

  

• 质量相关

  
• 成长模型

转眼一年过去了，总结一下。确实发现了不少问题。也想清楚了不少问题。花了不少时间在纠结和思考，乐观一点想，这算是一个蜕变的过程吧。

方向篇：

之前也在和不少人谈，觉得这些年，做了业务，做了技术，但是自己的定位到底在哪儿呢？年轻时候，一直想着做寄一个技术的领导者，去改变世界。这之后可以说一直在沿着这个轨迹走，一个技术的BU head，两任CTO都是技术领导者，但这一年，很明显的感到瓶颈来了。这个瓶颈就在于前半句做到了，但是后半句一直没有，怎么也做不到。我到底改变了什么？在这件事情上，就很纠结。团队一直在50人上下徘徊，似乎这也成了自己一个无法逾越的坎儿。从某种意义上讲，我的公司挑选是正确的，地域的选择也没有问题。这是薪酬一路上涨的原因。也确实随之能力也在不断提升。不过忽略了业务与行业的选择问题。也就是后面一件事，去“改变”。从业务也就是公司（或者个人），到行业，自己是否应该把更多精力放到寻求改变里面呢？回到了一个老生常谈的问题，一到业务发展瓶颈期，就退缩了。在TW当时面临的是创建的业务，因为边界不清，始终得不到认可。然后在杏树林，吸取了经验教训，但其实问题并没有得到改善。刚开始做数据业务的时候，其实更多还是波哥在做，要不是他后来离开了，可能也轮不到我来主导业务。但问题存在于销售端的控制上，缺了这个部分，总觉得不踏实。后来药企这摊事儿，也是努力了好久，做了好多，但是最后因为认可问题，一拍两散。准确的说并不能说一拍两散，遇升还是在最后妥协了的。说明有些事情，力争发展是有可能。然而退缩的是自己，一方面担心搞不定。一方面对财富的增值太看重了。我觉得这可能导致了自己长期上的发展僵局。所以目前自己最重要的是对于方向的决心和信心。

2020年，有两件事情是一定要做的。第一个就是作为技术领导者本身，在AI上一定要取得突破。我觉得自己选择的这个技术数据驱动，提升技术团队效率这个方向蛮有意思的，确实很喜欢。应用Cloud Native + AI技术实现真正的效率提升，代码和测试等一系列自动化编写。我觉得这个的确有可能改变世界些什么。说真的，我是笃信的。然而这个会遇上另一个矛盾，那就是作为业务领导者，因为改变技术本身似乎并不能改造社会，创造多么大的社会价值。或者，我知道机器人的引用，的确是各个公司需要的，因为他们的确在改造传统行业。可技术人员是个相对高级的工种，改造他们，作为技术领导者，他们愿意吗？当然这里也有一个分支方向，就是通过AI赋能Ops，不断寻找和提升Ops的效率，提升系统自动操作性（而不是restaurants，我不觉得restaurants的owner会为更多的功能买账，他们不是搞IT的！！！

2020年，另一件事情，就是纯业务，比如医生经纪人这样的纯业务领域。很有趣，自己之前做了不少，但想想，可能和数据项目当时的状态类似。我有一个很信任我的人，很愿意和我工作的好朋友在。然而我好像也贡献不了太多的东西。哦，也许运营是我可以做的。不过最关键的医院销售端，似乎还没太搞定。这么说来，这个的确有点意思，这不就又是当年的搭配么，我（用户运营），金尹（医生），华丰（私立医院）。不过这个东西和技术差异真的蛮大的，也是一直下不了决心的原因。2020年，需要考虑考虑。最后还有一件和业务相关的事情，就是我的关于美容美发行业的技术化改造。again，这事儿因为没有初期的伙伴。可能更是八字没一撇。

这两个想法，四个子想法，接下来要做个计划，留给2020年！否则肯定达不成结果！

方法论：

• 提升管理OKR方法论：对于国内还摸不着头脑的OKR来说，可能OKR的掌握自己越来越有效了。运用OKR来指导团队管理，还是很明显的。
• 提升质量的方法论：自己开始能够运用Tech Solution的四个基础方法，来规范技术解决方案。2020年，有望通过这一些列的技术解决方案提出技术的质量体系。我一直认为，研发的质量体系，应该是可以穷尽的。如果能够积累出一整套tech solution的方面，以后就可以不用这种bug一点一点出的笨办法，就可以把数据和案例驱动，变成最佳实践驱动，这样会大大加快速度。所以这也是2020年，有可能实现的一个重要目标
• 提升的纯技术管理方法论：Cloud Native：这个应该是最近要重点攻读的部分，因为感觉做了这么久的技术敏捷，一直没给自己找到个合理的原理来解释。Cloud Native因为继承了大量技术方法和管理方法。觉得应该会有点突破。

技术篇：

• 云端函数计算：2019年做了两个函数计算的项目，都有始有终了。虽然都不大，但是让自己对于函数计算有了比较好的初始实践。一个是部署在Aliyun上的团队index，一个是部署在GCP上的Jenkins每天总结和Wunderlist总结。Serverless的场景在我看来比较适合DevOps和数据团队做定期数据ETL和数据计算。至少这是目前我认为很合适的领域。至于其他的目前不打算探索。
• 从Code Function到Excel再到Data Studio的数据提取、计算到展现闭环打通。未来很多自动化都可以在这个基础上搞了。这回事OKR的重要基础，让OKR的数据收集工作变得相当简单。我认为这个以被写进OKR方法论。
• 开始对Python做了一些系统性的总结，这两年用python也比较多了，每次总是要去查，很烦。当然一方面说明还是用得少。训练太少。另一方面，觉得有可能形成一些自己的机械记忆会更好些。

展望篇：

最后展望一下2020年的几个可能的成果

方向上要思考的事情：

• Cloud Native + AI完善的管理方法（可以自己不是大公司的管理者，或者没有被大公司管理者认可，在这方面也许可以明确一下方向）
• AI帮助Ops（算了，这个方向是在没精力就算了，虽然有趣，但还是在给别人做嫁衣，最后的结果还是要依靠于业务的发展）
• 医生经纪人，这个先写，等等华丰
• 美容美发（算了，在有医生经纪人之前，暂时不考虑）

技术方法论要提高的：

• 解决质量问题，有没有可能出现最佳实践
• Cloud Native方法
• Python进阶语法和编程的进一步总结，需要做些题
• 对AWS有更深入的使用，（估计是有八九没戏，虽然是公司使用的主要AWS平台，但是交集太少）
• 对GCP有更深入的使用，这个如果AI能做的话，就比较有可能。

所以综合来说，2020年，属于自己的AI项目势在必行。这个会让自己在2020的技术上进一大步。加油吧2020！

附录本年度的主要工作结果

上回留了个伏笔说：“做业务的技术原则：远景－目标－指标－做事；对应工作方法：监控－报警－处理－优化”

如果说，之前我懂得的更多是如何根据不同的业务发展节奏，搭建与之相配套的技术体系的话。15-16年度，可以说是我说是重要的一年，让我对于什么叫做“工程技术体系”有了一层更佳深入的认识。这层抽象，让我更懂得回到技术的本源去看事情和问题。从这里一层层扩展开去。

工程技术的本质

我最近特别喜欢在技术前面加上工程两个字。因为这些年的工作我其实经历了一个去工程化的过程，那就是太多的人开始说到互联网，说起研发开始弱化工程师这个概念，更多的是在突出“技术”这个说法。但正是对“工程”的弱化，让我们在很多时候忽视了从传统工程领域借鉴经验的机会。事实上，传统工程和如今的IT工程确实存在区别，但本质上，作为工程化理论，就永远摆脱不了一个话题：一个关于“质量”和“速度”之间永恒的矛盾。如果细想想，对于每一个Tech Lead而言，其实就是在不断的针对这两个问题进行抉择和平衡。没有什么需求是真的做不出来，只是怎么做，才能在质量和速度之间寻求一种平衡。我们知道，在相同产能条件的情况下，

• 第一、质量越高，要求的精细度越高，对应生产难度也就越大，速度也会因此而降下来。人不是机器会疲倦，会出错。
• 第二、而如果对生产速度要求较高，那么质量的下降往往不可避免。但是可以大大提高产出结果
• 第三、虽然是最后，但是很重要，那就是长期低质量对产品速度必然产生负面影线。

由这三点，演化出来一系列方法和理论和话题。我在这里把“质量”与“速度”的矛盾叫做“工程技术本质”，以说明它的地位不可撼动性。

针对业务的技术原则

那么既然Tech Lead们需要不断解决的是“质量”和“速度”的矛盾问题。于是乎，这里面就衍生出一个很有意思的话题—如何做技术决策，如何判定自己的决策是合理。在我的这个理论里，若要做好这个决策，第一部分就是要了解业务。可能这对许多人来讲不可理解，作为技术人员，我做好自己的事情就好了，为什么要了解业务呢。这件事源于以人为中心的互联网模式。随着物质的极大丰富，供给模式，从最早的粗放型生产、分销、渠道，转变通过网络快速的寻找人的需求，根据需求进行快速迭代演进从而精细化的扩充人们在某一个或几个点上的消费习惯。在探寻过程中，其实对于互联网业务来讲，就是不断的实验过程。既然是实验，那么快速看到实验结果和实验深浅的把握就显得尤为重要。所谓实验结果，就是“速度”，即越快速度看到结果，越好进行决策是更进一步实验还是改换新的方向。实验深浅，对于技术而言就是实验的“质量”

那么作为每天坐在IDE前面思考代码和逻辑思路的技术人员而言，我们无法接触真实的用户，没有时间思考和观察用户在干什么，如何才能有效的了解业务呢？我把技术人员了解业务的方法分成了四个基本过程：

• 远景，大多指一个业务长远的，或者一段时间的方向性目标。远景的很重要，它是指导一切的原则。当然，对于一个大的业务方向来说，形成商业收支目标是核心。但是拆解下来，不同时期，对于形成收支目标的要求不一样，有的是有也不一定是要在财务上展现。比如作为如今的滴滴，当下的最大远景就是实现盈利，但是对于在Nasdaq上市的京东而言，快速增长可能比盈利更重要。作为一个公司而言，远景往往和公司的核心管理人员以及投资人的想法相关。但是，对于一个业务的远景，往往会小许多。比如病历夹工具业务线，他当下远景就是用户活跃的持续增长。所以，绝大多数功能让用户有更强的黏着性。

• 目标，通常和当下所做的工作直接相关。为了实现远景，任何的业务都会拆成几个小步工作。那么目标，就是每个小步要完成的结果。这个结果可能是让用户在上传病历过程中使用不会产生疑问，也可能是让用户更快捷的在医口袋中搜到药品。作为每一个小步而言，多数业务会设立唯一的目标。当然如果优化功能都比较小，也不排除建立几个目标的可能。目标往往是团队的负责人做的定义，但是对于远景的优化角度不同，思考方式不同，小步目标也不一定是单一的。在互联网的实际环境中，目标也是可以被拿来讨论的。从这里开始，有兴趣的技术工程师，便可以参与深入的讨论。

• 指标，既然订立了目标，就一定要寻找可以进行衡量的目标完成好坏的指标。我们拿“让用户在上传病历过程中使用不会产生疑问”这个目标来说，这里可以建立的核心指标是“用户上传病历数增加”，这是核心业务指标。分解下来，可能还有一些其他指标，比如上传服务器反应时间在200ms以下，上传成功了70%以上等等。做任何一件事情，都应该是可衡量的，没有量化的工作，就是刷流氓好么:)。定义指标的工作，需要技术工程师的重度参与，这里包括订立那些指标，以及如何将指标反馈给BI系统或者其他数据报告系统。这一点非常重要。也是后期业务、技术团队跟踪做事好坏的核心。

• 做事，在了解远景，目标达成一致，以及订立好合适的指标后，大家就要开始基于指标工作了。那么指标从某种角度上讲，就是质量的衡量方法，这个一般说来，叫做质量底线标准。任何的速度，在底线标准前，都必须服从。而做事，就是考虑，如何在保证质量的基础上，尽量的提升速度。这里就是Tech Lead们的专业技能体现了。具体的方法有很多，比如XP，Scrum等的工程实践，比如新技术的引用提升研发效率，再比如团队的文化气氛等。

总结一下，技术工程师，Tech Lead都很难真的完全深入业务细节去思考逻辑关系和用户使用习惯。但是经过以上的四个步骤，可以大体梳理每一个小步的背后的逻辑，并通过一系列指标进行有效的质量监控，用一系列工程方法指导做事，提升速度。

针对工程的技术原则

上面谈到了做事，谈到了比如工程方法、新技术的引用、团队文化等，那么针对技术工程，是不是可以衡量呢？答案当然是肯定的。任何工作都应该是可以衡量的，只是指标不同。这里我总结下来还是四个步骤：监控－报警－处理－优化

为什么要衡量？

在解释具体工程上的四步方法之前，先解释一个问题。可能又不少人会问，为什么你总是说衡量。看看我说的做事顺序，其中最后一步叫做“优化”。人类进行工程实践可能有几千年的历史了，很难说哪些事情是没有干过的。但是，问题的关键在于，对于每一次“质量”和“速度”博弈的实验中，如何进行优化，才是人类和动物最大的分别。我们在不断积累经验，寻找更好的方法。这就是实验的本质，也是任何事物前进的源头。“做事”的方法许多，根据团队、实践、节奏、个人知识能力等等不同，有太多的优秀实践可以应用，但是哪种是最好的，只有在指标定一下进行有效优化，才能得到越来越好的效果。所以下面说的四步，不仅仅适用于业务开发，也适用于技术工程人员对一切问题的抽象解决方案中。

• 监控，在针对业务的技术原则中，我们说到了指标。我们说技术人员要深度参与指标的定义，并做好指标的数据向BI或其他数据报告系统反馈工作，这就是监控的一种，主要应用在业务的指标监控中。其实，针对技术本身也有一系列的可以做的监控指标，比如线上Bug的数量、Crash率、服务器Apex指标，应用可用性等等。但是这里需要需要特别注意的是，在我看来，监控不是目的，是为了解决问题而存在的，特别是解决上面说的业务目标。比如有段时间业务目标是满足双11的客流访问量，那么Apex、网络带宽、负载均衡的资源使用这些就是重要的监控，可能需要秒级别的信息收集。那么这个时段，其他的比如CPU数量、客户端Crash率、网页兼容性，在这个目标面前，就不需要被严密监控，可能是天级别监控就可以了。所以监控是分级别，也是分时段的。
  人曾经问我，我是一个Android起家的Tech Lead，对于iOS、Java服务端，我不是很了解，要怎么才能做到很好对团队工作进行有效的带领和优化。这里我想说，通过指标监控，就可以达到目的。与相关的Tech Lead讨论针对特殊目的而细化的监控指标。

• 报警，许多人谈论监控，更多的是一套漂亮的报表，线图、饼图、柱图、箱图各种上。这是我以前常犯的错误，以为报表意味着监控。其实，在过去一年，我学会的最重要的知识就是，展现的目的更多是为了给别人看的直观，用以表明优化的成果，是一种回朔和预测型的工具。但是做事的时候，却不应该作为工具，回到计算机或者生物的本质上，0和1才是我们认识事件最直观的方法。因此，报警在我看来是工程监控最有效的手段（工具）。这种被动式相应能够大大加强响应效率和工作效率，根据响应的情况再去寻找相应的报表或者内容数据进行分析，从而得出有效的处理方案。
  设立报警的过程本身并不难，最难的是适当报警阀值的斟酌。太高起不到监控的效果，太低虚报误报使得报警无法有效应用。这个时候需要对技术有比较深入理解，对不同阶段对应指标有比较深入理解的技术人员（这里就不是一个纯工程问题，而上升到技术本身能力上），对报警阀值进行准确的把控，并持续优化。

• 处理，这块儿没太多可说的，这是每一个工程师的老本行，根据报警问题，使用数据综合分析，数据不全可能需要进行场景复现，如果是紧急问题可能还需要采取紧急方案、备份方案、临时方案等进行解决。总之是确保报警状态恢复到正常的水平。这个时间会根据不同业务和级别的不同，处理时间也会不同。

• 优化，最后来到了前面说的，工程技术原则的核心，就是优化。前面说到互联网的最大特点就是实验，不断的、快速的实验，了解和提升用户的体验，帮助用户解决问题。所以，无论是对业务指标的优化，还是技术指标，或者别的什么指标的优化，总之优化是技术工程师做事的终点，也是新的一轮工作的起点。研发工程由此不断迭代向前，帮助解决一个又一个业务目标。

最后做个总结，在过去的一年里，对于上面方法的理解和应用真正改变了我将近十年的认识。过去的我，一直在学习，学习各种技术、学习各种最佳时间、学习各种方法论来解决一个又一个的研发问题。记得刚进微软那会儿，我的最大收获是如何通过互联网快速解决问题，把Google用的炉火纯青。在英国的4年里，我明白了从0到1的建设过程和研究方法。ThoughtWorks的3年让我懂得什么叫做研发体系和最佳实践。如今，在杏树林，很高兴能遇到一群志同道合的人，至少现在吧，感觉自己的理解又上升了一个新的高度，实践因什么而存在，要解决哪些问题，如何才算真正解决，解决问题的为了什么。这是我2015-16年度，最有收获的部分，共勉。

通常我会在每个年中对从上一年的7月到这一年的6月的工作做一个总结。主要原因是年终的时候大家都在总结，但绩效、年终奖、年会、圣诞、新年等等，其实是一年中时间最紧张的时候。我不喜把事情都堆到一块儿做。刚好英联邦的财年就是年中，所以索性就选了这个时间做总结。

本次总结分成两大部分，第一个是工作篇，主要陈述上一个总结中的预期工作在这一年里的开展情况和变化情况。本次总结多增加了一个学习篇，主要是觉得进入创业中期的工作状态是日新月异，学习到的东西越来越多，而不知到的东西也越来越多。希望通过总结暨给自己一个交代，也给未来一年一种鞭策。在一个创业公司，如果你的成长速度慢过于公司，那就坐等淘汰。

工作篇

一般来说，我对CTO的工作理解都会在我的xmind里面不断增加，也会根据实际的公司运行情况做优先级的处理。下面的总图基本反映了我各部分工作优先级预期和状态。其中数字代表在15年6月份的时候我对这几部分工作的优先级安排。而脸谱代表了对所有工作我现在自己看来的满意度。作为一个overall的评价来说，我觉得还是挺满意的。尤其是在商业战略、团队、研发和技术团队运营这几部分。

对于用户，这一年碰的主要是一些企业用户，大体有所了解，更多的接触还是间接的，通过销售或者面试过程中谈话。医生用户几乎没有接触过。所以这块儿我对自己的工作是相当不满意的。任何事情不站在前台需求的角度，即使我现在有了数据的武器，也不会产生全面的印象和理解。在品牌塑造方面，写了些文章，但是感觉效果不佳，无论是传播力度还是广度并没有达到我预期的效果。

下面会针对每一个做逐一分析。

• 先从优先级最高的商业战略开始。这里在新的一年我改一下名字，应该叫做技术战略，是指应对公司发展需要而做出的技术类总方向的决策。之前预期这一年的三个大事儿基本上都做了。

  

  第一个是安全管理，这块儿在15年的下半年里，引入了安全宝的安全审计，做了渗透测试，确实发现了不少问题。服务端和运维一起最终将安全审计出来的问题，一一解决掉。让杏树林在安全防范上迈出了一个小步，但同时也是安全体系化的重要一步。接下来的安全工作出过一次事故，但是主要原因不是技术本身的安全隐患，而是出现在业务上的密码过于简单而产生的暴力破解。根据这个，对公司的VPN网络，请求时间间隔，各个系统验证码服务做了升级。接下来一年这一块儿肯定还是要做，但是可以从安全管理，上升到安全体系的高度，对一些安全工作进行常规化管理。

  第二块儿是团队的结构化。终于在杏树林走到50人技术团队的时候，我们迎来了业务化改造。这是我一直希望的事情。在我看来，一个团队，若想保持高效的战斗力，必须团队数量足够小，团队关注点足够专一。只有这样，才有可能把事情打透，把业务做到底，所以我在年度之初就策划了这个改革，好在的是，我们的COO也足够给力，快速的推动了我的改革。让我这个目标得以实现。

  第三块儿是核心技术能力的建立。这里包含了纯工程技术能力和基于业务的技术能力两大部分。纯工程是对原有公司的技术升级。包括了JS大方向的引入，Docker化和AB测试。但是很可惜，AB测试并没有完成，我觉得原因有两个，第一个是如果做AB测试，工具是一方面，但最重要的另外两个方面是基础数据，还有业务需求。这两块儿目前都在建立之中，随着数据驱动的演进，杏树林开始有计划的加功能，减功能。AB测试的需求正在起步，但是在过去的一年，因为数据驱动不到位，所以这部分没有太多需求。所以，这块儿掌握的一个核心是

  只有有了数据驱动，才有AB测试的需要。

  另外，除了工程技术外，业务技术当时15年中订立的是OCR的核心技术能力，以及数据结构化。前一个OCR能力基本上已经形成规模，有人持续为之进行优化。后一个数据结构化目前并没有很好的方法，这也是新一年的重点工作。在去年数据结构化里，学到的重要教训是，数据其实本来不需要结构化，关键是有效的检索和回馈。因此搜索引擎，将会成为新一年工作重点。

• 优先级第二的是R&D，研发体系，无论何时都是技术研发的重点部分。基本上当时的计划都完成了。公司从一个对技术仅是零散开发，到如今有了比较成型的各方面技术研发体系。新的一年，研发体系会往基础架构方面进行比较多的拓延。通过公共服务体系持续提升研发能力。但是这块儿，其实很多公司干得并不好，至于我们能不能，拭目以待。

  

• 同为第二优先级的是Client，这里其实是一个对用户和客户的共同说法。15-16年度，主要的工作在客户那里。15年下半年做了最重要的事情就是云学院产品的研发，经过内部产品和外部销售的反复沟通，完成了第一版云学院的基本体系和工作方式。从此云学院摆脱了无形态，minisite各类的方式，开始往产品化方式发展。但是在用户方面，确实没做什么，这部分将会作为接下来工作的方向

  

• 第三优先级的是品牌建设，这块儿这一年里花了不少时间。写了前后10片左右的文章，但是文章覆盖面主要是医疗这边，更加偏向于给行业和VC这类人看。但是并没有起到很好的作用。品牌建设的核心应该是面向技术人员。所以，接下来的思考是将之前类的文章数量降下来，像“大数据分析报告”这类的对企业具有一定价值报告。还是考虑在技术类演讲上增加曝光度，并且把团队加入进去。

  

• 第四优先级的是团队，这里团队之所以被列为较低的优先级，主要是因为一个相对完整的体系已经建立起来。大家可以看看作为参考吧。我觉得以目前团队的规模，短时间在超过100以前，这套体系应该不会有大的变化。还有一个最关键的，不想做大团队。坚信小而精的团队才能爆发最强的小宇宙。

  

• 最后的部分是团队运营。团队运营主要指的是一些和基础财、物相关的工作。这一块儿属于维持，本来的工作就不是重点。主要是在流程上做了一些努力，其中包括了线上事故和Bug的处理流程，这部分对公司有一定的影响。

  

学习篇

埋个伏笔吧，上关键词，“做业务的技术原则：远景－目标－指标－做事；对应工作方法：监控－报警－处理－优化”

这两周干的最有意思的一件事，莫过于搞清楚数据录入时效性这个衡量指标了。先讲讲故事吧：

故事起源于数据录入时效性的一个分析，可以看下面的图。以前我们认为通过所谓每天完成百分数这个数据可以实现对时效性的有效评估。说白了就是，当时的一个假设是，如果1天的当天数据完成100%，那么就意味着数据可以在一天内完成，处理时效是24小时。

但是，真实的用于工业生产，你会发现，其实每天的数据不可能达到理想的100%，而是会有各种差异，比如图里面的70%，98%等等。于是乎问题就来了，看了这个数据，我知道我们并没有完成我给用户承诺的48小时返回的指标完成情况这件事情，但是我距离这个目标差距有多远呢？于是乎我们使用了下面一个图的数据指标。

看了17%，50%，作为24小时和48小时的处理时效。刚开始的时候这个数字吓到我了，于是想各种办法改进，当然效果是有的，但是改来改去还是回到问题的原点，我到底和我当初的预期差距有多远？就着现有的数据，我只能模糊的感觉到很远，但是我要如何解释用户那一端获得的真实感受呢？每天一大堆同事抱怨数据录入时效太慢，到底这个感受是否真实呢？真实到什么程度呢？

就着这个问题，我和公司的数据分析老大做了半个下午的深入探讨。得到了如下的一番答案。首先，我得到的答案是，要解决什么问题，就要重新回到问题的原始场景，那就是我所有的问题，其实是来源于我关心用户的真实使用感受。那么我关心的所谓时效性，是返回到用户那里的时间感受，而不是作业机器和车间里的完成百分率。按照这个理论，我们重新画了一下正常作业的数据处理方法，大体是满足泊松分布的。

根据这个分布，大部分的数据会在前面的相对比较短的时间内快速完成，后面的数据将呈现比较明显的长尾效应。于是根据这个图，如果真的想得用户的感知，其实需要的不是计算某个时段处理的比例数，而是应该反过来，看某个固定比例数所处的时间段是多少。比如某个月最后算出来是80个小时，那么就意味着我实际返回给用户的感知是在80个小时以内。这样就很明确的界定了用户对于数据录入返回时间的感受。也解释了为什么用户反馈增加的原因。于是我们后来做了一些从后端到前端的改进方案。

那么好了，说到这里大家可能觉得这个故事的结尾的确实现了数据驱动，但故事的主体，那个翻来覆去，改了三遍的指标到底意味着什么呢？这就是这两周，我特别兴奋于学会的东西，即数据背后的那个建模过程。这才是所谓数据的Insight能够产生的核心原因，也是数据驱动的基础。

往往过去我们对数据驱动可能是这样认识的：

1. 我们要看数据，数据是重要的交流沟通工具，是一个可以形成共识的语言
2. 我们要了解各种数据，以帮组我们检验所做工作的好坏
3. 数据可以为决策提供有效的参考工具

这在我现在看来依然是非常重要的底层基础。但是随着真实使用的场景，我渐渐发现，仅有这些是不够的。随着信息爆炸，我们每个人身边的数据都可以说是海量大，可以说各种各样的数据充斥在我们耳边。尤其是大数据的兴起，更让一群人对这方面趋之若鹜，争相希望把更多的数据展示出来。然而，随着实际工作中的经验我发现，仅仅展现数据是远远不够的。公司的统计系统里面，有超过几十个报表，成百的数据项目在平台上进行统计，可是每当我问道业务部门你们为什么不看数据时候，得到的答案往往是，我无法从数据里看出问题。

这个事情曾经让我百思不得其解，直到我做完上面的故事，我才豁然开朗。原来数据驱动不是简简单单拿着数据去指导下一步的事情，而是数据是为了解决问题而产生的，它的源头应该是解决问题驱动。这就对了，因为事实上，这也是一个公司，一个团队存在的意义，就是为了解决一个又一个的问题。那么这些问题，需要经过合理的，有效的抽象，最终形成一套完整的数据指标。数据的诞生是为了提供证据，而正确的寻找证据，就能破案，能解决问题。但是如果只是数据的罗列，或者不去追踪数据的合理性，和是否能够为问题服务的特性，数据驱动其实是无法发挥价值的。

所以，在数据驱动里，除了收集数据，展示数据之外，还有重要的一个部分叫做数据建模，正是通过这个部分的工作，我们把原始的问题进行剖析，寻找对问题相应的证据，这就是数据驱动的真正意义，也是解决问题的根本。

OKR已经尝试了3个季度了，感觉从一团迷雾里渐渐看出了点眉目，我很难说现在的一切是对的，但是总结出一些东西，为了今后更加努力的改进。既然OKR是目标，既然OKR是数据驱动的基础，那么就要坚持演进下去。以下想表达的，更多是基于自我OKR回顾的一种总结，并不是OKR完成的组成。只是像以此描述我在定义OKR的过程中所走过的那些坑坑洼洼。

OKR疑问有所斩获：

• Align目标
  这个话题其实以前是知道的，但是体会不深。直到上一次我遇到了一个世纪的问题。当时所有“基础架构”团队的OKR基本上都是1on1来制定的，基本上纯从每个人的想法出发，我这边进行了一些修改和补充。然后，后来做到一半，技术团队OKR出来了，发现之前定义的好多和技术团队OKR关系不大。包括后来又改过几次，才发现慢慢上到。所以OKR以上上下下做做右右信息透明为第一要务，为的就是让大家目标能够algin到一起去。
  具体改进方法：OKR一定要从公司级别开始定义，以此来推导出与公司目标align的技术团队OKR，这个OKR，理论上还应该回过头来和其他业务团队的OKR（针对杏树林而言，可能更多是业务团队）进行align。不过在实际目前的操作中可能并不需要从一开始就这么做，毕竟所有团队也都是为了公司的OKR完成的。因此，出于效率考虑可以继续下去。那么接下来就是小组或者个人级别的工作了。最终，通过一系列的OKR制定工作，可以保证每个季度大家都在一个方向上工作，帮助公司完成商业目标。

• 团队／个人对OKR负责
  说到OKR，就不得不说到很多技术团队的同学们反应，在公司缺乏团队感，不知道向谁汇报，谁该有权利给谁分配任务。其实OKR就是很好的一个衔接点。每一个人为自己的OKR负责，OKR的来源可能是多方面的。在初期一定会有个人帮助他订立OKR，收集需求和反馈。对于业务团队内部来说，往往这件事情比较简单，就是业务团队的技术Lead和业务本身。对于基础架构或者跨团队支持的技术同事，往往这个时候技术同事的级别本身都比较高，那就需要对技术总监团队负责。总体而言，谁帮助订立OKR，就应该谁是负责人。但是OKR一旦被制定下来，每个人应该为OKR负责。

• OKR为了制度改变
  OKR不是绩效目标。因为假设人是优秀和自驱动的，不满足这个条件的人，可以不存在于OKR体系，而实用类似KPI等其他体系。这个话题缘起于对OKR Review的一次讨论，集体内容不说。反思大概是这样。如果OKR的订立前提是，组织内每一个人都是积极的，主动的，乐于思考和勇于承担的，那么OKR的作用是为了帮助大家，对没有做到或没有做好的问题，寻求解决方案。而这种解决方案在实践中，往往就是公司的一些制度和方法的演进。也就是说，任何事情一定要寻找一种新的积极的流程去解决掉。这个前提就是去寻找当时订立OKR之后，发现执行过程中没想到的东西。然后寻找方法，避免掉没想到问题的再次发生。这样可以将OKR订立的更好。

  

时间计划值得坚持：

• 定理时间的经验
  根据Q1的经验，我们在给Q2定力OKR的时候做了一些改动

  • 为了更高效的完成OKR，我们采用组级别进行OKR定义，分为基础架构，公共服务组，PTL团队。
  • 将技术总监团队先完成OKR的制定，然后是基础架构团队，然后是PTL团队。
  • 先进行上季度OKR Review，然后进行新季度OKR制定
  • 继续讲人员限定在基础架构组＋PTL范围内，力图通过Q2完成人员培训工作

• 双周回顾的经验
  技术团队目前还无法形成单周回顾，效率过于频繁可能导致精力分散，而且实践执行中发现难以完成。主要还是大家没有养成这类工作的习惯。所以目前还是我一个人在推广，测算下来，基础架构组＋公共＋PTL的总人数目前有12个人，接下来Q2可能会有15个人，数量庞大，而且没有一个标准，所以尚无法完成扩展。但是下面的表格值得推广，确实效果很好。

  

回顾方法有待改善：

• Q1本季度感觉回顾方法有待改善。学习了一下文亮的OKR Checklist，打算应用到接下来的制定和回顾工作中。接下来会专门做一个表来进行工作。

_OKR检查表_

1. Key Result 是否能够实现Objective，套用句型：通过实现XXX（某一条具体的KR），就能促进XXX（某一条具体的O）的实现。
2. Objective 和 Key Result 描述的是达到什么，而非做了什么
3. 检查是否满足基本明确定义和可度量的要求
4. 检查是否完整反映了个人的主要工作
5. 提醒合作方、同事来给出反馈
6. 检查是否和团队的目标一致
7. 检查是否和个人能力一致 (过易和过难都不好)
8. 检查是否足够专注、优先级是否清楚

还没有完成的话题：

• OKR如何打分，如何数据结果导向

这个周发生了几件小事情。

• 首先和杨宇、张诚有过一次讨论，觉得事情推进困难，一个随访的小红点问题似乎N久也得不到解决。关于operation和admin等后台不知道谁管也不知道该怎么办。
• 在本周由于同事离职反馈了两点信息，公司创业气氛不够，总觉得推动不足，以及责任心的一场讨论。而团队的同事另一方面觉得，自己没人管，没有人安排工作和关心。
• 第三个事情是周末一早出现的一个产品事故，业务负责人很难受；另一方面其实我能感觉到，事情相关的技术同事也都是公司数一数二有责任心的人，怎么会出现这个结果呢？

以上的事实，可能很多人都会归结成一句挺伤人心的话，叫做“责任感意识不强”。于是，这个似乎就理所应当成为了一个“人”的问题，更进一步说成了“别人”的问题。但说实话，在我心里，我挺认同文亮常说的那句话，“一个事情成功了找客观原因，失败了一定要找自己的问题”。这和我的为人风格也很像，说白了，任何事情，无论成败，都应该称为自己前进的阶梯，只有这样我们才能从中成长，不断颠覆打败那个曾经的自己。

于是周末和同事的一场讨论，一场回顾会，让我好像悟出来点什么。话题开始与《格鲁夫给经理人的第一课》。这是一本像“德鲁克”系列的经典管理书。（虽然会不屑于一些陈旧的言论，但是经典总归是经典里面的宝藏，在不断的实践中会一点点露出来）

书中有提到的一个观点。作者收集了自己工作中的时间和工作内容，概括起来大概分为四类，在这些事件中，时间的分配变少是最合理的。

在我们的讨论中，我发现，其实各个公司做得越好，越必须遵循这个原则。如果以这个原则我得到了一些新的想法：

• 从我们几个所谓技术管理的四个人的思想里，我们坚持认为，管理的目的是为了更好的帮助大家工作成长和提高，而不是为了“分配任务”，这一点我坚持认为是正确的，而且会一直坚持下去。所以，团队的人觉得没人管这个事情是错误的，而是让团队理解，他们不是要被管理，而是自我管理，做和公司方向一致的，并且自己认为争取的事情。有问题向周边人询问，这才是“杏树林”的文化。
• 既然是这样，我们是一批支持格鲁夫模型的人，那么问题出在哪儿了？在我看来，我们希望尽量少的做决策，多一点给大家建议，和引导大家的事情，而管理团队目前最缺乏的，反而是上面两个，那就是“传递”和“收集”
• 关于“收集”目前还没到这个高度，所以尚待完善，但是关于“传递”这个事情我们却真实应该做许多。其实我们总希望大家主动来问我们问题，但是如果我们没有传递足够强的信号给他们，如果我们传递信息不够多，大家在做事情的时候，就很难实现问问题这件事情，因为有太多他们所不了解的东西。所以你就可以理解，为什么ThoughtWorks，这么在乎每个月的monthly update，在乎buddy／sponser的1on1吃饭，在乎早上的站会，在乎物理墙，包括在乎老大不能有自己的座位，需要到处做，在乎小组一张大桌子进行随时随地的交流。这些都是信息充分传递的表现，只有信息传递了，大家才能拥有互动。（同理，关于OKR，我们也得出了类似的结论，那就是，每一次OKR指定的过程，恰恰是公司自定向下传递信息的过程）因此，信息的快速、健康、准确的传递，是企业管理者面临的重要责任。
• 于是乎我想到了关于7-10人管理边界的问题，《How Google Works》里面提到，Google认为管理边界应该不低于7个人，而不是像传统企业不超过7-10个人的上限。我以前的理解是，这是为了扁平组织的需要。但随着理解的深入，这原来是一个非常高的管理要求，说白了，传递效率是人类社会最大的障碍（推荐看三体，或者星际争霸，来了解哲学意交流的方法）。也正是因为此，人类单人传播能力大体在7-10个人之间。如果要实现更佳广泛的传播，就要借助各种“OKR”，“看板”，“monthly update”等等现代管理方法，从而最终实现管理扁平化。

综上总结，管理扁平化，不是一个简单的规定或者想法。身为团队的Lead们，大家肩负着“收集”和“传递”信息的使命。在这方面，我们不应该把责任简单的归结到人不行，不能充分的提问，甚至没有责任心。自己的工作没有做好，才是这些事情的核心。

因此，我自己打算给自己设定一个目标，要在未来的半年里，第一，变成一个大喇叭，不断传播公司各个级别的信息，学习更多的方法，让信息传播更有效率。第二，让周边的管理者们，尤其是技术总监们，管理团队们，更佳立即信息传递的重要性，让公司文化真正得到落实。我理解这也是所谓工程师文化必不可少的组成部分。

摘要：

• 指数型组织是一系列信仰MTP和为之奋斗人组成的集合
• 指数型组织是以一套可复制的“内核”为基础而存在的
• 指数型组织一定是“不完整的”，甚至不一定是一个公司，可能只是一个部门

今天来一起聊一本书。EXO（Exponential Organizations）指数型组织。书已经送人啦，所以完全靠着记忆来写。记录下我所理解这本书的精华部分。

这本书最让我惊讶的部分是他描述了一个新时代下的公司需求模型和与之相配套对应的组织模型。书中认为，过去我们在理解商业需求，往往是基于稀缺化的理解。认为企业的目的就是占有稀缺资源，并以低廉的成本来销售稀缺资源从而获得收益。简言之，企业的目的就是“出售稀缺性”。

• 首先必须承认这是对的，毕竟在过去的生产工具情况下，任何一个单体的个人都很难靠自己去触及到所有生活必需的来源。那么能触达人越少，资源也就越稀缺。几个例子，就是钻石，其实钻石这个东西本身在自然界并不稀缺，甚至人类都能加工出钻石。而依照“出售稀缺性”的理论，事实上几家国际钻石企业垄断了全球所有的钻石矿藏，并不断通过政府关系，广告媒体，对外宣传纯自然钻石的难度和少有，造成了一种“人为稀缺性”的假象。所以现在的钻石才卖的如此之价格高昂。

• 其次必须承认这是错的，因为在现代互联网发展到今天，个体世界已经在出现变化。在这方面首当其冲的就是信息稀缺性在被日益打破，信息爆炸，如今在Google上已经可以找到几乎所有碰到问题的答案。在信息富足的基础上，所谓互联网＋，O2O在做的，就是通过信息的富足尝试激活更广泛意义上的富足资源。比如Uber，其方法是通过信息的快速传播，将满大街跑和停在停车场的汽车的剩余座位开放出来，让更多人使用。据说全世界每时每刻，有除去驾驶员之外的93%的汽车乘坐位是空的。

因此，现代社会随着互联网的发展，企业从“出售稀缺性”开始进入到“出售富足性”。用两句话解释我的理解：

• 出售稀缺性：这个世界上只有我这里有，你来买吧
• 出售富足性：我告诉你这个世界还有哪里有，你去买吧

也正是因为这种变化，于是有了新时代企业所谓互联网公司“独角兽”类型公司的发展方法。我不买产品，我买“算法”，这里的算法是一个广泛意义上的含义，可以是一种“流程”，可以是一种“自动化方法”，可以是一种真正的“算法”，也可以是一种“产品”。所以问题就来了，既然我是一个“告诉你哪里有”的内核，那我必然是要靠可大规模复制的“量”来取胜的，这和薄利多销有点像。不一样的是，新时代企业要做的是把销售的边际成本降到最低，甚至0的地步，来取胜。这就是EXO这本书告诉我们的一个新的商业逻辑。也是互联网的主要逻辑。

说到我们的数据采集部分，对于数据采集，这是个很慢的工作传统的方法是尽量多的占有低端录入人员，销售大量的“稀缺”人员时间。但是，随着众测，机器自动化的发展，新型数据采集工作，销售的是广泛人的“富余时间”，同时通过算法，找到拥有“富余时间”的人，和降低这种购买“富余时间”所使用的成本。

讲完商业思路的主旨，下面就是这本书让我非常欣赏的部分，就是将如果要实现“富足”销售，企业需要具备的几个基本要素。书中简化为了两个词，SCALE和IDEAS，这也是这本书非常值得推荐的原因。

简单讲几个，其他的大家可以看书。书中认为，SCALE是外部属性。

• 其中C，是Community&Crowd，社群和大众。书中认为，既然组织售卖的是富足性，那么这种富足性的来源一定是组织外部，因为组织的增长永远呈现的是线性模型，很难呈现大的指数型增长，这和招聘是相关的。因为优秀的人员是有限的，所以就需要广泛的通过外部合作来创造增长。传统意义上认为，外部合作是不稳定的，而如果读过《失控》的人都知道，一个完全有序的可控制体系是不存在的，有的就是一种混沌的平衡，而一个系统（企业或大自然）一定可以自我完善，最终形成一个稳定形态。对社群和大众的使用，主要就来源于这个思想。认为只有通过最大限度的网络和不多扩张社群资源，最终才可以实现组织利益的快速指数型发展。比如众包就是这样一种模式，通过平台调度算法，和各种企业运营手段，让一个广泛的人群使用这个平台，最终完成数据的采集工作。

• 关于A，是Algorithm，算法。这个其实挺明白的，举例说Uber之所以能够实现快速扩张，是因为算法本身是不变的，同样的算法是可以大规模扩展的。这里我想说的是自己的一个理解，那就是，算法这个东西可能许多人都会想象的比较抽象。但是如果说广义的“算法”其实就比较好理解了。因为一个写在纸上的流程，第一步、第二步、第三步做什么也可以称之为一种“算法”。这种算法帮助管理和执行变得简单，降低了反复沟通不标准所造成的成本浪费。产品模块，其实也是一种算法，因为从某种程度上，产品模块就是自动化了的“纸面流程”。讲大量人的工作变成了机器，通过自动化的方法进一步降低了成本。当然，狭义算法，比如对比，查询，搜索，推荐，学习，这些都是更进一步的算法部分。还拿数据采集做例子，最早的采集系统是

说了两个外部属性，再来说说内部，在IDEAS部分，

• 关于D吧，是Dashboard，意思是说对于一个组织而言，既然数据的重要性不言而喻，那么接下来的问题就是如何表现，所以“仪表盘”就显得格外重要。它是数据的基础，也是工作赖以进行的保障。在后来和公司数据老大的了解中，我更加能明白仪表盘本身还要分成几类

当然，书中还描述了许多别的东西，特别是如何执行和实施方面的东西。比如一个企业在关于实验要如何做，如何通过数据预期来规范实验的方向和效果。这里不打算一一陈述。想再多一些内容谈谈自己的感悟吧。

• 指数型组织是一系列信仰MTP和为之奋斗人组成的集合。他们在一起的原因不再仅仅是为了更好的更高效的进行生产，而是基于一个理想。比如SpaceX的一个让交通变的更容易。杏树林我理解之所以让我信仰，就是那句“让医生更轻松”。因为我总是喜欢加上后半句，如果“医生每天效率提升1%，那么全中国，我们的兄弟姐妹将有上千万人次能够享受到更好的医疗”。这才是杏树林我理解里的伟大。

• 指数型组织是以一套可复制的“内核”为基础而存在的。通过内核极大限度的降低旧有生产工程的边际成本，来实现高价值。所以新兴公司一定是“小的”，并且以类似“算法”和“产品”为中心而存在。所以，指数型组织一定要问自己一个问题，我的工作边际成本是不是足够低，远远低于同业。我的方法是否是极低成本复制的。如果不是，那么请审视一下自己你的工作。作为数据平台团队，我希望做到这一点，我们的每一个产品都可能量的极大降低已有工作的负荷，提升工作效率，并且如果可以，将它转化为商业产片，也就意味着，让他进行更加广泛意义上的复制。

• 指数型组织一定是“不完整的”，现代互联网通过连接联系万物，那么公司也一样，他不再是一个必须拥有所有部门而存在的结构体，而是为了一个MTP（书里说这是公司的目标也是）而努力的一群人。那么他的工作不是让整个xxx提升，而是让一个属于自己的MTP得到提升。每个人都无法解决链接那一头，但是可以解决的是，将许多东西进行链接，最终形成指数型成长。

所以机遇这个，也是为什么我想把保险和数据整合。一个是HAVE，一个是READ，两者互相都在做这一点彼此的事情，但是又各有重点。只有互相合作，减少重复建设，才能真正把实现“杏树林数据价值化”这件事情走下去。这就是我想做的。我会相信，如果数据平台当成一个连接体，把公司内部作为一个客户，把公司外部做为其他平等的客户，这样，一个指数型组织才有可能真正成长起来。因为组织的内部所有工作，都将围绕着最大限度降低边际成本这件事情来完成，这样就一定能突出价值的最大化！加油吧！

本周三XTA讨论，发生了一件事情，让我不禁感慨有些东西说起来容易，真做起来却没那么简单，或者说比较容易被忽视。事情的大体经过是这样的：

XTA每周三例行周会上，我们聊到了一个话题，是否将部分诊疗圈repo牵往github上。主要原因表述为，目前武鹏和文迪在诊疗圈推行一种更先进的部署方法，部署可以直接从repo里已用写在其他repo上的依赖modules（如果我理解没错的话）。目前青云环境到公司内网环境之间的数据并没有打通，所以导致在内网使用的gitlab，无法被青云访问到。所以得到了将部分repo牵往github上的一个方案，交由XTA共同讨论。

在会上，大家为了是否迁移这件事情讨论了许多。包括是否采取架设青云到内网的访问管道，迁移github带来的权限管理成本，整体gitlab到github迁移的可行性等等。事后，虽然大家名义上达成了一致，认为可以在青云上搭设一套gitlab环境，交由ldap进行统一权限管理。但回过头来想想这个决策的讨论过程，总觉得不太对。

• 讨论的基础
  这里就不得不回到一直以来给团队设定的基线是：

  1. 科学的做事儿
  2. 使用数据和并努力作出合理优化

  之所以定义了这两条基线是源于读那本著名的《How Google Works》，我认为这本书对我的影响是相当深刻的。其中，关于文化一章有这样一个说法

  “Establish a culture of Yes

  We are both parents, so we understand through years of firsthand experience the dispiriting parental habit of the reflexive no. “Can I have a soda?” No. “Can I get two scoops of ice cream instead of one?” No. “Can I play video games even though my homework isn’t done?” No. “Can I put the cat in the dryer?” NO!

  The “Just Say No” syndrome can creep into the workplace too. Companies come up with elaborate, often passive-aggressive ways to say no: processes to follow, approvals to get, meetings to attend. No is like a tiny death to smart creatives. No is a signal that the company has lost its start-up verve, that it’s too corporate. Enough no’s, and smart creatives stop asking and start heading to the exits.”

  Excerpt From: Eric Schmidt. “How Google Works.” iBooks.

  对于一个公司而言，树立Say Yes的文化是很重要的。那么如何树立这种文化，书里也给了比较明确的解答，那就是书里基线，一个大家都认同，并愿意为之遵守的基础。同样是参考这本书里，关于

  “Decide with data

  One of the most transformative developments of the Internet Century is the ability to quantify almost any aspect of business. Decisions once based on subjective opinion and anecdotal evidence now rely primarily on data. Companies like ours aggregate anonymous signals from mobile phones to provide accurate traffic data in real time. London’s water pipes are monitored by thousands of sensors, reducing leakage by 25 percent.119 Ranchers embed sensors into their cattle that transmit information about the animals’ health and location; each cow transmits about 200 megabytes of data per year,120 allowing ranchers to fine-tune what, when, and how much they feed their cattle. That’s a cattle list for change!”

  Excerpt From: Eric Schmidt. “How Google Works.” iBooks.

  基于事情和数据的决策，我认为是非常好的一种工作方式。在书里写到Google在任何一个会议室都会有两个投影仪，一个用来交流，另一个用来展示数据。这充分显示了一个公司对数据的重视。问什么呢？曾经听《罗辑思维》讲，关于数据这部分，深感认同，数据是人类进行合作的重要工具，是跨时空合作得以展开的基础。有了数据其实大家都是聪明人，也就明白很多事情的决策是什么原因了。

  

所以，说回本次周三XTA的讨论。其实我们是没有做好讨论准备的。对于这样的一个迁移，一定是选取几套方案，并根据“运维时效”、“工作时效”共同加起来，完成一个比较好的讨论。让讨论的多方理解，为什么要做这个决定，为什么是那个决定。我觉得坚持以事为中心，坚持那数据来做决策是对的，应该在任何情况下必须坚持的。接下来应该更进一步讲数据细化，2016，我一定要让运维有一整套能拿得出来的数据，2016，要让杏树林的人都拿数据来讨论问题，我们的数据平台，也要更加为主的建立起来。把这个形成公司的行为习惯。在这点上，我一定要坚持，不动摇，并且学习更好的实践。

哦，对了，也给自己和所有人说，2016，新年快乐！

对于测试团队管理是个循序渐进的过程，传统的测试团队，尤其是从大公司来的，比较习惯于一体化的测试团队。所有测试人员和开发相对立，测试人员有一套独立的考核体系（经常是发现bug多，就越好）。但是这样的方式，实际上是在一个团队中树立了一层层的壁垒和对立关系，这与产品和运营的对立，技术和产品的对立，测试和技术的对立一样。所以作为管理者，作为新时代的团队管理模式，是无论如何要消除这种壁垒的。而这个过程中面对的第一个问题，就是测试团队管理者的思想问题。

要解决这样的问题其实并非容易，我做的方法就是尝试分开，首先，如果你想把一个群人分开，就要去让他们地理上分开。于是把测试团队分开成两个小块儿，让一块儿的测试团队和项目组坐在一起。并不是完全，而是有一点点间隔的坐在一起，这样开始的时候会好接受学多。然后再通过给测试团队的压力，这种压力，往往可以做成多头压力，即让不同的产品在同一时间发布和讨论需求，往往这个时候管理者一个人很难做到兼顾，所以渐渐形成有人带劳的事实。第三个就是交流，站会scrum里面交流的一个最主要形式之一，将站会和某个特定测试人员联系在一起，可以大大增加该测试人员的归属感。

无论如何，这些尝试都不是为了分解测试团队，而是让这个团队更加的高效，这本身慢慢也希望测试团度的管理者能够学习和理解