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

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. 数据可以为决策提供有效的参考工具

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

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

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