上一个

在过去的十年时间里，从微软到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年，图灵发表了具有里程碑意义的论文《电脑能思考吗？》，在里面第一次提到了人工智能的概念。图灵对人工智能的描述就是，有一堵墙，墙上有一个小窗口，窗口的两侧，一边是人，一边是具有人工智能的机器。如果两方都认为对方是人的话，则实验成功。现在看起来，这样的日子真的不远了。:)

前段时间和一个医生朋友吃饭，聊到他最近几个月开始接触病历夹，觉得超级好用。我问他哪里好用，他给我讲述了他，做为多点执医的工作，要经常到处跑，使用OCR和语音录入快速整理病历，有效跟踪病人的经历。这里有个背景交代一下，作为一个技术工匠，我自己不是一个很擅长推销的人。所以身边好朋友即使知道我在做什么，也知道我的性格，如果他们自己没有发现优势，是不会推荐他们用的。这次和我这个朋友吃饭，他夸的我自己都有点不好意思。但今天回想起来，心里却是觉得美滋滋的，一种功夫不负有心人的感觉。做为工匠，我理解最重要的是对“完美”的追求。在病历夹过去的2年时间里，身为技术的负责人，在语音识别和图片识别方面投入了巨大的精力。从寻找合作商，到研习友商和国内、国际上的方法，再到如今，一步一步在公司一群兄弟的“打骂”中，一点点优化系统。从最开始大量的人工识别，全病历识别到如今，经历2.5次大规模的系统更迭，几十个迭代上线，杏树林的识别系统已经初步实现了自动化分类分拣、中转流程自动化、以病历信息安全为基础的碎片化处理、信息的预OCR处理＋分角色人工录入校验的一体化系统。这一系列的工作，不是一蹴而就的，也不是靠纸面能想出来的。它是一种工程技术和识别科学技术相结合的体系化工程。它是一种从实践到优化再到实践到优化持续不断的过程。可以说，强大的健康医疗类数据处理能力，在成立5年后的今天，已经成立杏树林站在大数据风口上的重要核心力量。因为这样的能力，我们那个月处理几千万字符的医疗健康数据。因为这样的能力，我们积累了中国可能少有的动态标准化医疗数据库，希望有朝一日成为国内最大的标准化数据库。因为这样的能力，我们为数据分析和研究打下了坚实的结构化数据基础，并且在持续的算法和人工清洗中，让数据称为进行精准化医疗基石。这里必须多说一句，感谢陪我走过这艰苦日子兄弟们，一起加班加点工程师、把我主持的一个个系统说的体无完肤数据分析师、争执争吵不停的算法工程师们。

说了些自夸的话，主要想顺着这个话题聊聊技术驱动医疗这个事情。互联网的发展，让越来越多的人们认识到技术在现代社会发展中起到的重要作用，工程师文化在成为了越来越多企业津津乐道的话题。那么针对医疗，是否真的能再次摇动起信息技术驱动的大旗让医疗进入新阶段吗？

• 互联网+医疗的门槛－医疗信息化vs信息化医疗
  见过不少的HIS系统（Hospital Informatioin System)，也曾经以前作为咨询师参与过朋友HIS的系统分析工作。就我所看到的，大量的医疗信息化系统，都是基本上完全照搬的现有医疗的实际工作方法或者工作模式。更多的人把计算机信息化当作了服务于原始工作的一种手段和工具。所以，曾经有一段时间，不光是医疗领域，在很多领域都流行一个词，叫做信息化或者数字化。而HIS也是在这段时期应运而生。但HIS本身，过分强调将已有医疗进行数字化，强调还原所谓的“医疗习惯”，因此造就了一系列其实很严重的数据结构。

  

  如上图，数据因为不符合关系型数据的存储，造成了大量医学统计上的困难。这种怪异的表格设计，从人类认知理解上并没有太大问题，但是作用到机器上就会出席比较大的麻烦。为什么会造成这种现象呢？在笔者看来，就是所谓医疗信息化在作祟。信息技术应该是一门重要的学科，它的重要作用是帮助人们重新认识这个世界。用机器的方式对世界进行组织和计算，这里面虽然会产生冗余，但是因为机器的大规模自动化应用，将是的大量数据的集体计算能力得到非常大的提升。

  所以笔者提出了信息化医疗的理念，这也是为什么说信息技术驱动医疗。原因在于，信息的信息化技术更加强调改造一种旧有的方法和工作模式，通过大量机器的参与，大幅度的提升旧有模式的工作效率。因此，在提到移动医疗的门槛时，笔者经常会说，这里的最重要门槛是使用新时代的信息技术方法，对医疗工作过程，方法进行重新梳理和重新定义，帮助医疗系统寻找方法进行优化。而不是遵从现有医疗方法，找一个电子化的道路，这样是不可能解决问题的。

• 互联网+医疗的创新－业务创新vs技术创新vs技术化创新
  以Google为首，创立了新的数据分类检索的搜索算法。以Facebook为首，创立了新的人与人的连接算法。以Apple为首，创立了新的人与机器的交互技术。这几件事情，是笔者认为具有跨时代意义的技术发展，他们可以说是真正的技术创新。当然正在到来的无人机远程图像传输技术、AR/VR技术等，也可能正在成为具有划时代意义的技术提升。

  但是有不少人说，不能所有公司都围绕着技术本身来进行创造性工作。是的，各行各业也都需要许多的业务创新。但是如今，在互联网的时代，任何的创新，或者说基础创新工作，还是有章可循的。这个章，就是对技术改变传统方法的总结和实践。用这套新的方法，来指导创新。因此笔者强调技术化创新，并不是认为互联网时代的引领者一定要做什么前无古人的新技术，也不是传统模式里面寻找新的业务增长点，而是从技术发展中，寻找使用革命性的技术，对领域进行创新改造。在这个过程中，实现业务价值，引导领域效能提升。因此，笔者认为，用现代化技术寻找医疗领域的增长点，是创新的关键。

• 互联网+医疗的明天－大数据vs数据分析
  笔者最近出席一些论坛，也看了不少文章，发现有个词现在被反复提及“大数据”。这里笔者Quote一句最近特别喜欢的话。

  Big Data is like teenage sex:
  Everyone talks about it, nobody really knows how to do it,
  everyone thinks everyone else is doing it, so everyone claims

  为什么这么说？笔者还不敢说自己对“大数据”有多么深的造诣，但是就已有的技术理解而言，“大数据”不等于“大量数据”这是两码事。大数据是一种根据大量数据的统计结果进行分析的方法。举个例子来说，百度用大数据对地图两点之间距离进行统计分析，预测百度到家的送餐时间。这其中百度大数据使用了很好的大样本情况下的统计学方法。这套方法，其实在医学领域早就已经有所使用，但是这里面有一个重要的问题。现代医学有一个重要的概念，叫做循证医学，其核心思想是医疗决策（即病人的处理，治疗指南和医疗政策的制定等）应在现有的最好的临床研究依据基础上作出，同时也重视结合个人的临床经验。

  这个临床依据怎么来，就成了现代医学的最重要课题。于是现代医学研究，包括药理分析，开发出了一大套排除干扰，单一化的统计方法来完成数据的分析工作。这里很重要的一个词，叫排除干扰。而恰恰是这个词，和大数据的模糊化统计理念有出入。所以，有不少人说大数据是医疗的明天，这点笔者很难认同。原因恰恰是技术驱动互联网+医疗。因为如果是驱动，就要看看被驱动本体到底是什么。如果如笔者所说，大数据是一套统计方法论的话，那么除非医疗统计方法论出现了革新，否则很难说大数据是医疗明天这样的事情。

  那么明天到底是什么，在笔者看来要技术驱动，就要驱动信息化的医疗自身工作，那就是研究数据分析的过程，这一块儿虽说很难，但却是可以、也值得解决。从这个角度而言，也是笔者所引导杏树林努力实现的目标。

总结下来，回到文章一开头写的。最近的信息技术互联网，可能由于某滴、某信的快速发展变得有点浮躁，好像今天做了投资，明天就能有几千万的用户，后天就能继续融资几亿，周而复始，大家就觉得技术驱动了。笔者眼里的技术，是一个持续话提升和解决的事情。人工智能这个词从上个世界70年代提出，经历了20年的起伏，10年的低潮，如今又慢慢随着技术的提升重新进入了“代表未来”的词语。如果一定要问，技术的发展模式，在笔者看来，是踏踏实实的，做好一个又一个优化，把现在需要10个人的事情，自动化起来，变成2个人。这就是技术的发展模式，来不得半点“大跃进”，来不得半点虚假。而是踏踏实实，一步一个脚印的去优化，去改造，不盲目遵从，也不妄自菲薄。这就是技术驱动互联网医疗的核心。只要有了这个核心，大部分争论其实都是伪命题而已。做好事，让医疗真的提升，才能让我们的兄弟姐妹父母子女更多人看到病，看好病。

写Python2的人，很多人都见过下面这行Error

1
2
3
4
5
6

Traceback (most recent call last):
  File "/Users/Jack/Documents/ApricotForestDoc/2_product_rnd/redspiderlily/mailfetcher.py", line 35, in <module>
    if is_reply_mail(subject):
  File "/Users/Jack/Documents/ApricotForestDoc/2_product_rnd/redspiderlily/module/mailutil.py", line 46, in is_reply_mail
    return ("回复" in subject_.lower()) or ("re:" in subject_.lower())
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe5 in position 0: ordinal not in range(128)

ASCII，全称American Standard Code for Information Interchange，是一个字符编码标准。使用0-127（2^7)的数字代表不同的英文字符，这里包括大小写字母，空格，特殊字符等。这是一个大家都比较熟悉的字符集标准，可以看看下面图中的内容。这里不做赘述。

但是，ASCII因为标准内含有的有限，带有音标的字符‘é’就无法很好的表述，更别提汉字了。到了1980年代，计算机技术发展，那时候大家已经开始使用字节（byte）来作为计算机基本计数单位。1byte＝8bit（2^8=256）,所以可以表述的字符变多了。那个时候开始出现了实用128-255这些数字表示发音单词。所以直到今天，你去看word里面的字符表，Latin依然可以看到这个顺序关系，大体就是这个原因。

再之后，当世界各地的语言发展出了各自不同的字符集体系，比如中国简体（GBK，GB18030），中文繁体（Big5，以前有个特别扯的名字叫做大五码），法语（Latin1），日语等等。本来各种语言字符集各自写互不干扰，倒也相安无事。但是，世界大融合嘛，于是问题来了。有人需要在中文里写上一段日语，就像这样 ++“日本語にほんご”++ 。于是问题就来了，怎么才能在同一个文件里现实不同的字符集的字符内容呢？1980年，人来开始尝试解决这个问题，并制定了一个新的计算机工业标准用以规范的处理、表示和编码全世界主要文字。这个标准叫做Unicode（全称是The Unicode Standard）。目前，Unicode标准是8.0，已经包含了全世界已经有超过12万个字符，覆盖129种现代和历史上的语言种类。在这里面需要说明一个额外的概念叫做Universal Coded Character Set (UCS，也叫做ISO 10646)。按照Wiki对于Unicode和UCS的说法，目前两套字符集应该是完全相同的。同一个数字在两个字符集里所代表的字符应该是相同的。但是Unicode的外延要多一些。USC仅仅是一个字符集，而对应的Unicode同时还规范了校对、标准化、表示顺序的算法等。就如同本文提及对Unicode的定义一样，Unicode出来包括了字符集，还有表现和处理方法的部分。因此Unicode应该说是一个更加广泛含义上的标准。

理论上说，Unicode字符集或者UCS有110万字符点数可以被分配，目前时机分配成16个Plane，其中Plane0，被叫做BMP（Basic Multilingual Plane），一共65536个，其中绝大部分是中文（Chinese），日文（Japanese）和韩文（Korean），三者合称CJK。

这里需要特别提一下Chinese Simplified（GBK，GB18030），自从2000年以后，中国政府规定，所有在中国售卖的软件产品必须支持Chinese Simplified（GB18030）字符集。因此在我国，就出现了一个神奇的事情，就是Unicode和Chinese Simplified双字符集并行的问题。

有趣的是，笔者大概调研了几大中文网站的编码如下：

感觉上各个大厂也是自说自话，不是不是很一致要遵守政府规定或者不遵守规定。这么说来，国家对这块儿在申请xxx备案的管理也不是很严格。

话有点扯远了，咱们再回来。目前Unicode字符集共设定16个Plane（数字从0x000000-0x10FFFF）对应(2^16+2^20)对应（1,114,112）。刚刚说的Plane0，基础语言集定义是从0x000000-0x00FFFF(2^16)。其他的大家可以查，Plane1和2用了一些，其他基本上用的很少。因此总共来说目前分配的字符大约是12万。

但是这样庞大的数字和计算机的比特（byte）之间并不统一，把一个Unicode字符串转换成Byte的过程，这里引入了一个叫做Encoding，编码的概念。1992年，为了兼容不同处理器和C语言，人们引入了一个编码标准，这就是大家广泛知道的UTF-8。截至2016年5月份，在WWW上的统计，UTF-8的使用率已经达到86.9%，对比GB2312（0.8%）。同时W3C也把UTF-8作为XML和HTML的推荐编码。

下面我们来阐述一下UTF-8的实现原理（同时可以结合下图来看）：

如果是7位以内表述的字符表数字，就只占用一个自己，表现为（0xxxxxxx），这样刚好和ASCII码的描述相一致，这样就不会造成原有ASCII的识别错乱，特别是针对C语言的strlen()和strcopy()。从第8位，也就是十位数的256开始，采用两字节表述模式（110xxxxx 10xxxxxx),最多可以表示11个bit位，也就是2^8(256)到2^12-1(4095)。以此类推。是不是一种很有趣的编码模式 :)

下面看一个栗子。以杏树林的“杏”字为题。

所以总结一下，Unicode和ASCII是一个字符集的概念，他们是随着电信发展而产生的编码本。只不过Unicode有多包涵了表示和处理部分，范围会更广泛。为了让计算机能读懂编码，适应计算机的计算，我们有了诸如UTF-8类的编码方法。

值得参考的一系列词条出处
https://docs.python.org/3/howto/unicode.html
https://en.wikipedia.org/wiki/Character_encoding
https://en.wikipedia.org/wiki/Unicode
https://en.wikipedia.org/wiki/Universal_Coded_Character_Set
https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane
https://en.wikipedia.org/wiki/UTF-8

最近，主要是想集中把这次的改造写完，早日上线。这次主要干了两件事情。第一是升级Python3，这里面顺带写一点学习总结。算是个misc文章吧。下一篇主要是想聊聊没有后台的系统到底是如何搭建以及为什么要做这个实验。

OK，先说这次Python3升级吧。想了很久了，受制于各种阻力，总是担心升级会出问题。但是Python3既然已经嚷嚷了这么多年。而且还是有越来越多的系统在往Python3上迁移，所以还是用用看。至少知道坑在哪里，以后会遇到哪些问题。

总结一下本次修改较多的几个部分：

• Print语法：Python3最有名的一个表征就是print的括号问题。在Python2里面是没有的，在3里加上了（）这个语法。所以导致从2向3升级的过程中print，成了修改最多的语法之一。

• Pip2（Python2）和Pip3（Python3），一般来讲，如果之前装的是2的，升级到3时候Python和Pip两个命令依然表示的是2，如果要是使用3.x的话，需要加入pip3或者python3，来作为命令开头。为了简单期间，或者用env来定义。还有一种就是在bash_profile里面增加python的alias

  1 2	alias python='python3' alias pip='pip3'

• MySQL-python包的使用。这个很讨厌，因为目前这个包还不支持Python3。不过也没什么着急的，换一个呗。PyMySQL这个是Python官方对于MySQL的支持包。对于基本的增删改查操作，用法基本上是一样的。只不过要特别注意的是连接时要加入“charset=”utf8””来实现对中文的支持。这个在MySQLdb里面好像是默认，至少我当时没有设置。

  1	db = pymysql.connect(host=host, port=int(port), user=username, passwd=password, db=database, charset="utf8")

• 关于unicode，这里说道大头了哈。因为绝大多数人对于Python2中文支持都是一个噩梦。文字，被在--之间转换。但在Python3里面，很重要的一点是对中文做了很好的支持。消除了unicode这一层环节。所以现在就可以比较明确的说“中文.encode(‘utf-8’)”就是解码环节，无需再顾忌其他。

  

• 也正是因为这个unicode的转变，其实造成了Python2里面很多原始代码都要进行一系列的和字符集相关的变化。比如一个buildin的函数open，在以前2的时代，是不需要对字符集进行指定的（话说，其实也是因为那个时代就没有什么字符集）。现在要特别说明打开字符集类型才可以进行有效的读写操作。

  1	open(filename, 'w', newline='', encoding='utf-8')

• 另外很赞的一点是，Unittest对Python的支持非常好。我自己实际用了unittest2和mock两个库。基本上都没有出现什么相关的修改。非常赞！所以说测试还是要加哦，很不错滴。

这次升级，确实花了些时间，处理问题。但确实得到了不少有益的实践。总结下来是两点吧

1. 单元测试很重要。整个过程中，升级后的第一件事情就是运行单元测试，其中大量的错误，但是不可怕，一个一个的改就好了。因为我的程序设计web、邮件、数据库等多方通讯，没有单元测试，效率会大打折扣，而且还有可能遇到因为网络问题而导致的联调失败
2. Python2到3的升级并不可怕，主要问题恰恰是来自于unicode这块儿的改变。只要记好了字符集utf-8这件事情。你会发现大量问题，都和这个有直接关系。

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

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

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

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

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

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

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

故事起源于数据录入时效性的一个分析，可以看下面的图。以前我们认为通过所谓每天完成百分数这个数据可以实现对时效性的有效评估。说白了就是，当时的一个假设是，如果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，两者互相都在做这一点彼此的事情，但是又各有重点。只有互相合作，减少重复建设，才能真正把实现“杏树林数据价值化”这件事情走下去。这就是我想做的。我会相信，如果数据平台当成一个连接体，把公司内部作为一个客户，把公司外部做为其他平等的客户，这样，一个指数型组织才有可能真正成长起来。因为组织的内部所有工作，都将围绕着最大限度降低边际成本这件事情来完成，这样就一定能突出价值的最大化！加油吧！