很有趣，看了一下，刚好去年也是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！

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

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

  

学习篇

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

刚好在回答一个知乎话题，但是觉得挺值的分享一下的，供有兴趣的童靴，尤其是开始关心业务的童靴参考

IT背景的人想做移动医疗应该怎么做准备？我觉得其实最重要的就是同理心。IT技术是一个用作所有行业皆可的东西，但是正因为他的“干什么都行”，也就决定了如果不是爱自己所做的产品或者方向的话，也很难把一个行业做好做好。前几天，碰到一个做女性社区的CTO，聊起来说自己的团队不喜欢和产品一次思考，不喜欢往前跨一步去为用户考虑。当然我们也交流了许多执行层面的方法，但我问他了一个我很看重的话题，就是“作为一个男人来讲，你对帮助身边的女性解决她们（比如化妆、美甲等）的问题是否有兴趣”。他沉默，没有给我一个明确的答案，其实我大概也能猜的出来，至少我自己不是很有兴趣吧。那我说，如果作为技术的最高负责人，你对所做的业务没有力图改变的兴趣，那很难说你的技术团队能真正感兴趣于为用户提供服务。不如做点技术的事情，让团队先对技术产生兴趣吧，虽然这件事的投入产出比相对比于前者有点低，但也算是一种选择。

就我而言，对医生的同理心感受从很小就有了，各种因素不多说了。总是医生和技术人员一样，是工匠文化的典型代表，说深一点是Geek文化的典型代表。为啥？因为技术人员可以自己写各种好玩的应用，做Demo，但是脱离了业务，其实技术本身什么也不是。同理，医生也一样，你看医生自己可以做实验，研究片子，研究药理等等吧，但是本身医生离开了病人，其实也什么都不是。无论医生宣称自己有再高的成就，如果他没治好一个病人，恐怕没人相信。同理，一个技术人员无论宣称自己有在高的技能，做出fancy的页面，通过高压力的测试，外人也很难确信他所做的工作有多牛。说“医生是把患者背过河”，其实技术也一样“是把一个个严峻痛苦中的业务背过河”。说的好像有点高尚，但这就是医生，这就是技术。技术领域有活跃的Geek，也有混口饭吃的，甚至被迫从事这个行业的普通人。同理，医生领域也一样，只不过他们有两个更加对应的名字“神医”和“庸医”。

所以，我深信医生和技术在工匠文化的表现上是如此的一致。也是因为此，我相信，既然Github，Stack Overflow，Heroku，Amazon Cloud成就了一批又一批技术，让技术迈向新的台阶，那么我相信医生也可以有属于自己的医疗自动化存储、研究、交流、服务平台。所以，我做了病历夹，就像Github一样让医生存储自己的“代码”，让感兴趣的人互相交流，做了诊疗圈，让医生可以互相提问实现能力提升。我还会做更多，做更多让医生这群工匠变得更加方便的事情，成就更多医疗领域的Geek。我解决不了每个医生的工作问题，但我相信通过我的努力，能够让更多人知道、辨别什么人是好医生，是爱医疗这门学科的医生。这就好像我们现在招聘必看面试者的Github和博客账号一样。

如果这个问题是在问要不要投身于医疗这个行业，那么请准备好同理心，和真的想要颠覆一个行业去解脱那些痛苦中的医生们，让好医生获得人们更广泛的尊重，得到本来就应该属于他们的名誉和利益，让庸医无地自容。因为帮助了他们，也就帮助了作为患者的我们自己。这里多举一个身边的例子，我的一个同事，好兄弟，家里姨妈因为胃痛去了一家医院，医生针对胃炎给了些药打发回家了。偶然的机会，姨妈陪兄弟的妈妈检查癌症，于是在子女的要求下，自己也做了个检查，结果发现是早起胃癌，好在发现的早，应该无大碍。我们每个人，不可能每天去医院挂专家。但是如果这类庸医变得越来越少，我想至少他能想到让这位姨妈去做个检查；如果这类庸医变得越来越少，也许我们的兄弟姐妹父母子女会多一分生存的机会。

说回到话题，如果关注点不在医疗这件事情，也没什么对错的；那就关注在技术本身，医疗领域里面好玩有趣的技术也很多，比如和很多其他行业类似的用户体验方面，数据处理方面等等，可以做出很多不错的方面事情。但至于具体是不是要投入移动医疗，或者什么其他行业，那就没有什么特别的了。