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

如果说，之前我懂得的更多是如何根据不同的业务发展节奏，搭建与之相配套的技术体系的话。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里面交流的一个最主要形式之一，将站会和某个特定测试人员联系在一起，可以大大增加该测试人员的归属感。

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

给自己一个定位。在杏树林做CTO有一段日子了，过去的很长一段时间，都在做着自己最擅长的事情。我承认，这个对现在的杏树林来讲是非常重要的，无论是流程改造，团队结构化，前端技术和团队精益化的建立，包括对产品经理运营团队的培训，这些东西对我来讲确实太熟悉了，虽然有各种不容易和辛苦，但无论是思路、方法还是执行，都是我擅长的。那么接下来，要做点什么特别的了，我觉得。

最近大约几个月前成立了公司的数据平台中心，好吧，这个中心目前确实还很初级，初级到我们甚至不知道应该以一个什么形式做项目。但是不断的摸索，数据平台中心在成长，我们开始越来越有门路，包括我自己也在成长，是时候给自己接下来的几年做个定位。作为一个CTO，一个行业领域的CTO数据是行业的核心，更是技术的核心。大家都在谈大数据，我不觉得自己在做什么大数据，更多的是研究数据，研究医疗，我希望自己在有限的时间里能够快速成长为一个医疗互联网中最了解数据的人。目标包括以下几个方面：医生的行为数据，病例的基本资料数据，那么接下来还有什么，拭目以待吧。

为什么，我认为自己应该是这个定位，刚刚也说了，作为一个CTO，我是技术团队或者是杏树林发展方向的重要领航者。领航员用罗盘仪和地图领航，而我所有的就是纷繁复杂的数据，虽然他们还不是一个完整的地图。其二，三年专业咨询师的训练，对学习的敏锐和对知识的快速拼接能力是我最起码的职业素养。其三，身为一个从小就是数学爱好者，博士研究数据的数字敏感人士，这是我的最爱。责任，教育和兴趣。Just do it!

我希望：王哲，医疗互联网数据专家，杏树林CTO