通常我会在每个年中对从上一年的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的处理流程，这部分对公司有一定的影响。

  

学习篇

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

因为要和许多中国／国际企业合作，我们需要一套更加完备的信息安全认证。所以这两个礼拜搞ISO27001搞的很心烦，于是写写27001的概念，顺便聊聊认证体系。

• 关于ISO27001:

  ISO27001认证，由英国标准协会（BSI）于1995年2月提出，中文全称《信息安全管理实施细则》（BS7799-1:1995）。它提供了一套综合性的、由信息安全最佳惯例构成的实施细则，目的是为确定各类信息系统通用控制提供唯一的参考基准。1998，提出了第二个部分，中文全称《信息安全管理体系规范》，它规定了信息安全管理体系的要求和对信息安全控制的要求。2005年被ISO国际标准化组织采纳，形成了ISO/IEC 27001:2005。完整的ISO27001包括了11个方面、39个控制目标和133项控制措施。是一个不折不扣让一个互联网人晕到吐血的管理制度。主要11个方向包括：

  1. 安全方针
  2. 信息安全组织
  3. 资产管理
  4. 人力资源安全
  5. 物理和环境安全
  6. 通信和操作管理
  7. 访问控制
  8. 信息系统获取、开发和维护
  9. 信息安全事故管理
  10. 业务连续性管理
  11. 符合性

  通过对整个ISO27001这11个方面的落地，实现一个ISMS(信息安全管理系统)。这里特别说明，这个系统不是互联网概念上的系统，指的是一个体系化的东西，包括了上面所属管理、行政、人事、信息技术等各个方面。详细的就不在这里说了，实在是好多。目前这个工作已经在做了，这里给大家看一下我们的列表，这里面大概60%是技术团队要做的。

  

• ISO27001与HIPAA

  之前有不少人问HIPAA的事情，现在估计也会有不少人问ISO27991和HIPAA的区别。所以这里简单说明一下。从概念上说，ISO是一个标准，可以由相关评级机构进行评级，办法符合标准的认证证书。这个证书可以用来和企业进行合作，以表明我司在信息安全方面的准备和能力是充分的。而HIPAA是一个法案（也可以说是一个法律），就是每个医疗相关企业遵守是必须的，不遵守如果被举报就要吃官司。哦，对了，这里还要特别说明，ISO和医疗无关，HIPAA是专门为医疗信息保护准备。所以ISO主要讲的是信息保护这个系统工程要做哪些和怎么做；而HIPAA虽然原则上提供了一些强制性的标准和工作方法，但是其核心内容更加强掉哪些信息是禁止泄露的。

  所以说，本次公司的ISO27001认证，我们也是请了相关具有评估资质的公司来进行评审。

• ISO27001我们所做的和下一步需要做的事情

  下一步主要要做的事情就是完善文档和制度了。这里我想特别说明，之所以我会很重视这件事情，不是为了完善文档和制度，反而是从一个专业技术的角度，想想怎么从里面尽可能找些方法，避免繁琐的文档和制度。在我心里，过于完善的制度和方法，对研发和快速迭代，快速试错本事是有害的。所以，尽最大程度的减少ISO27001对互联网团队的伤害，是我最近想研究的一个话题。有了结果的话，可以再写一篇博文了，呵呵。看一下一片标准的ISO27001文档的样子，像下面这种文档理论上是每次都要写的。做过企业软件的人，应该知道。

  

总之，ISO27001确实是一个挺麻烦的东西。但是，从企业合作的角度，又不得不去做，并且也可以成为公司系统安全方面比较好的一个PR背书，从这一点上看，质量体系的工作比HIPAA的工作实际上在中国更有公信力。所以吧，对于我来讲对于这东西属于虽然很反感，不屑，但是又知道很有用，不得不去做的东西。希望看到文章的技术兄弟，也是对此表示一种尊敬吧。我自己承认，了解还是有必要的，只是要做多少，大家根据实际情况做到心中有数就好。

上一个

在过去的十年时间里，从微软到ThoughtWorks，再到后来做了杏树林，历经了Symbian，Windows Mobile，然后的Blackberry和Android，直到后来的iOS，WP，设计了一个又一个从前到后的系统架构，差不多经历了大半个移动时代的发展。还算完整的工程师生涯让我对用户体验和人机交互有着格外的感情。直到有一天，一场争论让我陷入了沉思。

事情缘起于对后台运维系统的设计。在最开始季度初的时候，我雄心勃勃给DevOps团队定义了一个目标，让运维同学学会使用Axure作出产品设计原型，推演操作路径。这在我们这种搞移动产品设计起家的人眼里是顺理成章的事情。然而，技术专家的反对，却给了我一闷棍。后来想来，UI设计对于运维系统而言简直是极大的浪费。原因如下：

• 运维系统的核心任务，是提升运维人员的工作效率，提升运维质量（降低运维差错率）
• 运维系统的面向对象，熟练的操作人员（研发、运维）
• 运维系统的研发目的，以最快速度，解决现有问题

第一个很重要的原因就是，正是因为如上所述，要快、要高效的面对熟练人员。如果是工作效率在运维系统中可以使用机器来尽量多的完成任务的话。那么“快”在运维系统的研发中就显得格外的重要。其实，当今世界上最简单的，也是最早出现的交互见面便是Terminal。在Terminal的情况下，大量的UI工作和交互工作都转化成了基本的命令，不再需要写表单，调整在不同窗口大小情况下的适配，也不用做繁琐的IE，Chrome等浏览器适配工作。这让DevOps研发更多的关注于“核心任务”，就是用机器方法提升工作效率本身，让出了核心功能外的代码降低到最大程度。

第二个原因，其实，随着后移动时代的到来，越来越多的人已经开始从2007年手机触屏所带来的一股极大的UI交互体验旋风中走了出来。渐渐的，一种更加方便简易的形式在兴起。Cortana, Google Now和Siri，人机对话。其实，早在Symbian时代，就有一家著名的公司Nuance公司，从事语音识别，而且效果已经很高了。不过微软、Google和苹果在识别的背后加入了更加强大的语音分析引擎，让识别结果更加语意化，可以基于场景来从事更多的工作。因此，如果说过去我们在交互这个领域，还在苦苦追求更加简单、易于理解和上手的人机交互的时候。新的机遇自然语言或者简易自然语言的交互，很可能会在不远的未来改变我们的生活，而这一切，一定会从技术本身开始。

Github去年发布了非常有意思的办公自动化软件Hubot，他通过添加adaptor的方法，想Hubot注入更多语言交互指令，让Hubot可以通过一系列在Chat过程中的指令模式完成操作。其实本质上说Hubot和Terminal的工作原理并没有多大不同，但是这一次，对话不再仅仅限制在Terminal上，更加无需了解很复杂的ip地址和命令。如今的交互在IM软件上，通过一些预先设定的语言类指令来完成。

前段时间，Google发布了他们的语言搜索系统，WWDC在新版的macOS上面加入了语义搜索功能。可以想见，ChatOps，ChatOffice，ChatXXX为代表的一系列人工语音交互模式，将会实现。那么如今，我们要做的，就是把业务内核准备好，剩下的就是不断探索更新的技术所带来的便捷。

最后，写到这里的时候，我忽然想到了一个事情－－图灵实验。1950年，图灵发表了具有里程碑意义的论文《电脑能思考吗？》，在里面第一次提到了人工智能的概念。图灵对人工智能的描述就是，有一堵墙，墙上有一个小窗口，窗口的两侧，一边是人，一边是具有人工智能的机器。如果两方都认为对方是人的话，则实验成功。现在看起来，这样的日子真的不远了。:)