07 解决了很多技术问题，为什么你依然在“坑”里？
在前面的内容中，我给你介绍了几个体现“以终为始”原则的实践，包括怎样界定工作是否完成的 DoD、怎样判定需求是否完成的验收标准、还有怎样验证产品经理给出的产品特性是否合理的精益创业理念。
了解了这些内容，可能你会想：我为什么要关心这些啊？
我是程序员啊！难道我不应该安安静静地写程序吗？为什么要操心其他人的工作做得好坏？
如果我管了那么多事，我还是不是一个程序员，到底哪里才是我的“终”呢？
今天这一讲，我们就来聊聊这个让许多人困惑的问题。
因为只有要跳出程序员的角色看问题，工作才会变得更加高效。
“独善其身”不是好事
在需要与人协作的今天，独善其身可不一定是好的做法。我先给你讲一个发生在我身边的故事。
有一次，我的团队要开发一个数据服务层，准备作为一个基础设施提供给核心业务系统。开发没多久，一个团队成员和我说，他的工作进展不顺利，卡在了一个重要问题上，他想不明白该如何在多个实例之间分配 ID。
我听完之后，有些疑惑，为什么要考虑这个和功能无关的问题呢？
他解释说，因为我们的系统需要保证消息的连续性，所以他设计了消息 ID，这样下游系统就可以通过消息 ID 识别出是否有消息丢失。
这是没错的，但我奇怪的是，他为什么要在多个实例之间协调呢？
他给出的理由是，这么做，是出于考虑应对将来有多实例并发场景的出现。然而事实是，我们当下的需求应对的是单实例的情况。
我了解情况之后，马上跟他说清楚这一点，让他先把第一步做出来。这个同事还是有些担心未来如何做扩展。我告诉他，别纠结，先把第一步做出来，等后面真的有需求，我们再考虑。
同事欣然答应了。
其实，这个同事的技术能力非常强，如果我不拦着他，他或许真能实现出一个完美的技术方案，但正如他自己所纠结的那样，这个方案可能要花掉他很长时间。
但这真的是我们想要的吗？以现阶段的目标来看，根本没有这样的需求。
我们一直在强调“以终为始”。所谓“终”，其实就是我们的做事目标。虽然大家工作在一起，朝着一个共同的大目标前进，但真的到了一个具体的问题上，每个人看到的目标却不尽相同。
我之所以能把同事从一个纠结的状态中拉出来，是因为我看到的是需求，而他看到的是一个要解决的技术问题。
所以，我们俩在对目标的理解上是有根本差异的。
你也许会认为，我和同事之所有这样的差异，是角色上的差异，我在项目里承担的角色要重一些，而且我的工作时间比同事要长一些。
但不知道你有没有想过，不同角色的差异到底在哪里呢？
角色的差异
作为一个在职场工作的人，每个人都有一颗渴望得到认可的心，希望自己在职业的阶梯上步步高升。
假如今天就让你往上走一个台阶，比如，你原来在项目里打杂，现在成为项目的主力，或者，你已经对项目细节驾轻就熟，即将委任你为项目负责人。你是否能胜任呢？
你需要补充的东西是什么？
换句话说，你和你职业台阶中的上一级那个人，差异到底是什么？
也许你会说，他比我来的时间长，或者说，他每天的主要工作就是开会。如果真的是这样，那是不是只要你凑足这个条件，就可以到达他的位置呢？显然不是。
不同角色工作上真正的差异是上下文的不同。
这是什么意思呢？
以前面的问题为例，你在项目里打杂，你只能关注到一个具体的任务，而项目主力心目中是整个系统。虽然写的代码都一样，但你看到的是树木，人家看到的是森林，他更能从全局思考。
同样，项目负责人的工作，虽然包括在项目组内的协调，但还有一部分工作是跨项目组的，他需要考虑你们项目组与其他组的互动。
所以，他工作的上下文是在各组之间，包括技术和产品等方面。
再上升一个层面，部门负责人要协调内部各个组，同时要考虑部门之间的协调。而公司负责人考虑的上下文甚至要跳脱公司内部，进入到行业层面。
你可能会问，好了，我知道不同角色的上下文有差异了，但这对我意味着什么呢？
我们先从工作角度看。回到前面我分享的那个故事，你可能注意到了，我并不是靠技术能力解决了问题，而是凭借对需求的理解把这个问题绕过去了。
之所以我能这样做，原因就在于我是在一个更大的上下文里工作。
类似的故事在我的职业生涯中发生过无数次，许多令程序员愁眉不展的问题，换个角度可能都不是问题。
技术是一把利刃，程序员相信技术可以改变世界，但并不是所有问题都要用技术解决。
有这样一种说法，手里有了锤子，眼里都是钉子。花大力气去解决一个可能并不是问题的问题，常常是很多程序员的盲区。
之所以称之为盲区，是因为很多人根本看不见它，而看不见的原因就在于上下文的缺失，也就是说，你只在程序员的维度看问题。
多问几个为什么，交流一下是不是可以换个做法，许多困惑可能就烟消云散了。而能想到问这样的问题，前提就是要跳出程序员角色思维，扩大自己工作的上下文。
虽然我不是项目主力，但不妨碍我去更深入地了解系统全貌；虽然我不是项目负责人，但不妨碍我去了解系统与其他组的接口；
同样，虽然我不是项目经理，但我可以去了解一下项目经理是怎样管理项目的；虽然我不是产品经理，但了解一个产品的设计方法对我来说也是有帮助的。
当你对软件开发的全生命周期都有了认识之后，你看到的就不再是一个点了，而是一条线。
与别人讨论问题的时候，你就会有更多的底气，与那些只在一个点上思考的人相比，你就拥有了降维攻击的能力。
现在你知道为什么你的工作总能让老板挑出毛病了吧！
没错，工作的上下文不同，看到的维度差异很大。单一维度的思考，在多维度思考者的眼里几乎就是漏洞百出的。
当扩大了自己工作的上下文时，我们的目标就不再局限于一个单点，而是会站在更高的维度去思考，解决问题还有没有更简单的方案。
许多在低一级难以解决的问题，放到更大的上下文里，根本就不是问题。
我的职业生涯中经常遇到这样的情况，在一个特定的产品设计下，我总觉得设计的技术方案有些不优雅的地方，而只要产品设计微调一下，技术方案一下子就会得到大幅度提升。
在这种情况下，我会先去问产品经理，是否可以这样调整。只要不是至关重要的地方，产品经理通常会答应我的要求。
在更大的上下文工作
扩展自己工作的上下文，目光不再局限于自己的一亩三分地，还可以为自己的职业发展做好布局。
在这个方面，我给你分享一个不太成功的案例，就是我自己的故事。
我是属于愚钝型的程序员，工作最初的几年，一直把自己限定在程序员的上下文里，最喜欢的事就是安安静静地写代码，把一个系统运作机理弄清楚会让我兴奋很长一段时间。
我的转变始于一次机缘巧合，当时有一个咨询项目，负责这个项目的同事家里有些事，需要一个人来顶班，公司就把我派去了。
到了咨询项目中，我自己习惯的节奏完全乱掉了，因为那不是让代码正常运作就可以解决的问题，更重要的是与人打交道。
有很长一段时间，我一直处于很煎熬的状态，感谢客户没有把我从这个项目赶出来，让我有了“浴火重生”的机会。
为了让自己从这种煎熬的状态中摆脱出来，我必须从代码中走出来，尽量扩大自己思考的边界。
经过一段时间的调整，我发现与人打交道也没那么难，我也能更好地理解一个项目运作的逻辑，因为项目运作本质上就是不同人之间的协作。
突破了自己只愿意思考技术的限制，世界一下子宽阔了许多。所以，后来才有机会更多地走到客户现场，看到更多公司的项目运作。
虽然我工作过的公司数量并不多，但我却见过很多公司是如何工作的。
再后来，我有机会参与一个新的分公司建设工作中，这让我有了从公司层面进行思考的角度。
对于员工招聘和培养，形成了自己一套独立的思考。
这些思考在我创业的过程中，帮我建立了一支很不错的团队。
而创业的过程中，我又有了更多机会，去面对其他公司的商务人员，从而建立起一个更大的上下文，把思考从公司内部向外拓展了一些。
回过头来看自己的生涯时，我发现，因为不愿意拓展自己的上下文，我其实错过了很多职业发展的机会。
所幸我还有机会突破自己，让自己走出来，虽然走的速度不如理想中快，但至少一直在前进，而不是原地打转。这也是我告诫你一定要不断扩大自己工作上下文的原因。
机会总是垂青那些有准备的人，尤其在公司规模不大的时候，总有一些跳跃式的发展机会。
我见过有人几年之内从程序员做到公司中国区负责人，只是因为起初公司规模不大，而他特别热心公司的很多事情，跳出了固定角色的思维。
所以，当公司不断发展，需要有人站出来的时候，虽然没有人是完全合格的，但正是他的热心，让他有了更多的维度，才有机会站到了前排。
当然，随着公司规模越来越大，这种幅度极大的跳跃是不大可能的。
江湖上流传着一个华为的故事，一个新员工给任正非写了封万言书，大谈公司发展，任正非回复：“此人如果有精神病，建议送医院治疗，如果没病，建议辞退。”
因为一旦公司规模大了，你很难了解更大的上下文，很多关于公司的事情，你甚至需要从新闻里才知道。
本质上，一个人能在自己的工作范围内多看到两三级都是有可能的。
在公司规模不大时，从基层到老板没有太多层级，跳跃就显得很明显，而公司一大，层级一多，从低到顶的跳跃就不太可能了，但跨越级别跳跃是可能的。
所以我希望你跳出程序员思维，这不仅仅是为了工作能够更高效，也是希望你有更好的发展机会。
总结时刻
程序员总喜欢用技术去解决一切问题，但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案，很多时候原因在于程序员被自己的思考局限住了。
不同角色工作真正的差异在于上下文的差异。
在一个局部上下文难以解决的问题，换到另外一个上下文甚至是可以不解决的。所以说无论单点有多努力也只是局部优化，很难达到最优的效果。
想把工作做好，就需要不断扩大自己工作的上下文，多了解一下别人的工作逻辑是什么样的，认识软件开发的全生命周期。
扩大自己的上下文，除了能对自己当前的工作效率提高有帮助，对自己的职业生涯也是有好处的。随着你看到的世界越来越宽广，得到的机会也就越来越多。
如果今天的内容你只记住一件事，那请记住：扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。
最后，我想请你分享一下，在你的工作中，有哪些因为你扩大了工作上下文而解决的问题呢？欢迎在留言区写下你的想法。
08 为什么说做事之前要先进行推演？
经过前面的学习，想必你已经对“以终为始”这个原则有了自己的理解。
你知道接到一个任务后，要做的不是立即埋头苦干，而是要学会思考，找出真正的目标。
那目标明确之后，我们是不是就可以马上开始执行了呢？
先不着急给出你的答案，今天的内容从一个技术任务开始。
一个技术任务
你现在在一家发展还不错的公司工作。随着业务的不断发展，原来采用的关系型数据库越发无法满足快速的变化。
于是，项目负责人派你去做个技术选型，把一部分业务迁移到更合适的存储方式上。
经过认真的调研和思考，你给负责人提出了自己的建议，“我们选择 MongoDB。”
出于对你的信任，负责人无条件地同意了你的建议，你获得了很大的成就感。
在你的喜悦尚未消退时，负责人进一步对你委以重任，让你来出个替代计划。
替代计划？
你有些不相信自己的耳朵，嘴里嘟囔着：“把现在存到数据库的内容写到 MongoDB 不就成了，我就一个表一个表地替换。难道我还要把哪天替换哪个表列出来吗？”
刚刚还对你欣赏有加的负责人，脸色一下子沉了下来。“只有表改写吗？”他问你。你一脸懵地看着他，心里想，“不然呢？”
“上线计划呢？”负责人问。
“我还一行代码都没写呢？”你很无辜地看着负责人。
“我知道你没写代码，我们就假设代码已经写好了，看看上线是怎样一个过程。”
“不是发新版本就好了吗？”你还是不知道负责人到底想说什么。
“你能确定新版代码一定是对的吗？”
虽然你已经叱咤编程很多年，但作为老江湖，一听这话反而是有些怯的。
“不能。”你痛快地承认了。
“一旦出错，我们就回滚到上一个版本不就成了。”常规的处理手段你还是有的。
“但数据已经写到了不同的存储里面，查询会受到影响，对不对？”负责人一针见血。
“如果这个阶段采用两个数据存储双写的方案，新代码即便出问题，旧存储的代码是正常，我们还有机会回滚。”
你一下子就给出了一个解决方案，咱最不怕出问题了。
“对。”负责人认同了你的做法，一副没看错人的神情。“让你出上线方案，就是为了多想想细节。”
你终于明白了负责人的良苦用心，也就不再大意。很快，你就给出了一份更详尽的上线方案。
你把这个方案拿给负责人看，信心满满，觉得自己够小心，一步一步做，没有任何问题。但负责人看了看你的上线计划，眉头逐渐锁了起来，你知道负责人还是不满意，但不知道还差在哪里？
“原有的数据怎么办？”负责人又问了一个问题。你一下子意识到，确实是问题。“
没有原有数据，一旦查询涉及到原有数据，查询的结果一定是错的。
所以，还应该有一个原有数据的迁移任务。”你尴尬地笑了笑。
负责人微笑着看着你。“好吧，从我的角度看差不多了，你可以再仔细想想。然后，排一个开发任务出来吧！”
你当然不会辜负负责人的信任，很快排出了开发任务。
看着排出的任务，你忽然困惑了。最开始只是想写个读写新库的组件，怎么就多出这么些任务。
此外，你还很纳闷为什么负责人总是能找到这么多问题。
一次个人回顾
你想起之前的工作里有过类似的场景，那个负责人也是让你独立安排任务。
通常，你最初得到的也是一个简单的答案，从当时的心境上看，你是很有成就感的。
只是后来的故事就不那么美妙了，上线时常常出现各种问题，你和其他同事们手忙脚乱地处理各种异常。
当时顶着巨大压力解决问题的场景，你依然记忆犹新。解决完问题离开公司时，天空已经泛起鱼肚白。
而似乎自从加入了现在的公司，这种手忙脚乱的场景少了很多。
你开始仔细回想现在这个负责人在工作中的种种。从给大家机会的角度来看，这个负责人确实不错，他总会让一个人独立承担一项任务。
只不过，他会要求大家先将任务分解的结果给他看。
拿到组里任何一个人的开发列表之后，他都会问一大堆问题，而且大多数情况下，他都会问到让人哑口无言。说句心里话，每次被他追问心里是挺不舒服的，就像今天这样。
本来在你看来挺简单的一件事，经过他的一系列追问，变成了一个长长的工作列表，要做的事一下子就变多了。毕竟谁不愿意少做点活呢！
不过，你不得不承认的一点是，加入这个公司后，做事更从容了。
你知道无论做的事是什么，那些基本的部分是一样的，差别体现在事前忙，还是事后忙，而现在这家公司属于事前忙。
于是，你开始把前一家公司上线时所忙碌的内容，和现在负责人每次问的问题放在一起做对比。
这样一梳理，你才发现，原来负责人问的问题，其实都是与上线相关的问题。包括这次的问题也是，上线出问题怎么办，线上数据怎么处理等等。
你突然意识到一个关键问题，其实负责人每次问的问题都是类似的，无论是你还是其他人，他都会关心上线过程是什么样，给出一个上线计划。
即便我们还一行代码都没有，他依然会让我们假设如果一切就绪，应该怎样一步一步地做。
你终于明白了，之前的项目之所以手忙脚乱，因为那时候只想了功能实现，却从来没考虑过上线，而且问题基本上都是出在上线过程中的。你想到了上次参加一个社区活动，其中的一个大牛提到了一个说法：“最后一公里”。
想到这，你赶紧上网搜了一下“最后一公里”，这个说法指的是完成一件事，在最后也是最关键的步骤。
你才意识到，“最后一公里”这个说法已经被应用在很多领域了，负责人就是站在“最后一公里”的角度来看要发生的事情。
嗯，你学会了一招，以后你也可以站在“最后一公里”去发现问题了，加上你已经具备的推演能力，给出一个更令人满意的任务列表似乎更容易一些。
把这个问题想清楚了，你重新整理了自己的思路，列出了一个自己的问题解决计划。
-
先从结果的角度入手，看看最终上线要考虑哪些因素。
-
推演出一个可以一步一步执行的上线方案，用前面考虑到的因素作为衡量指标。
-
根据推演出来的上线方案，总结要做的任务。
不过，更令你兴奋的是，你拥有了一个看问题的新角度，让自己可以再上一个台阶，向着资深软件工程师的级别又迈进了一步。
通往结果之路
好了，这个小故事告一段落。作为我们专栏的用户，你可能已经知道了这个故事要表达的内容依旧是“以终为始”。
关于“以终为始”，我们前面讲的内容一直是看到结果，结果是重要的。
然而，通向结果的路径才是更重要的。
这个世界不乏有理想的人，大多数人都能看到一个宏大的未来，但这个世界上，真正取得与这些理想相配成绩的人却少之又少，大部分人都是泯然众生的。
宏大理想是一个目标，而走向目标是需要一步一个脚印地向前走的。唐僧的目标是求取真经，但他依然用了十几年时间才来到大雷音寺。唐僧西天取经有一个极大的优势，他达成目标的路径是清晰的，从长安出发，向着西天一路前行就好。
对比我们的工作，多数情况下，即便目标清晰，路径却是模糊的。所以，不同的人有不同的处理方式。有些人是走到哪算哪，然后再看；有些人则是先推演一下路径，看看能走到什么程度。
在我们做软件的过程中，这两种路径所带来的差异，已经在前面的小故事里体现出来了。一种是前期其乐融融，后期手忙脚乱；一种是前面思前想后，后面四平八稳。我个人是推崇后一种做法的。
或许你已经发现了，这就是我们在“以终为始”主题的开篇中，提到的第一次创造或者智力上的创造。
实际上，早就有人在熟练运用这种思想了。
在军事上，人们将其称为沙盘推演，或沙盘模拟。军队通过沙盘模拟军事双方的对战过程，发现战略战术上存在的问题。这一思想也被商界借鉴过来，用来培训各级管理者。
这个思想并不难理解，我们可以很容易地将它运用在工作中的很多方面。比如：
-
在做一个产品之前，先来推演一下这个产品如何推广，通过什么途径推广给什么样的人；
-
在做技术改进之前，先来考虑一下上线是怎样一个过程，为可能出现的问题准备预案；
-
在设计一个产品特性之前，先来考虑数据由谁提供，完整的流程是什么样的。
最后这个例子也是软件开发中常遇到的，为数不少的产品经理在设计产品时，只考虑到用户界面是怎样交互的，全然不理会数据从何而来，造成的结果是：累死累活做出来的东西，完全跑不通，因为没有数据源。
很多时候，我们欠缺的只是在开始动手之前做一遍推演，所以，我们常常要靠自己的小聪明忙不迭地应对可能发生的一切。
希望通过今天的分享，能让你打破手忙脚乱的工作循环，让自己的工作变得更加从容。
总结时刻
即便已经确定了自己的工作目标，我们依然要在具体动手之前，把实施步骤推演一番，完成一次头脑中的创造，也就是第一次创造或智力上的创造。
这种思想在军事上称之为沙盘推演，在很多领域都有广泛地应用。
在软件开发过程中，我们就假设软件已经就绪，看就绪之后，要做哪些事情，比如，如何上线、如何推广等等，这样的推演过程会帮我们发现前期准备的不足之处，进一步丰富我们的工作计划。为了不让我们总在“最后一公里”摔跟头，前期的推演是不可或缺的，也是想让团队进入有条不紊状态的前提。
如果今天的内容你只记住一件事，那请记住：在动手做一件事之前，先推演一番。
最后，我想请你思考一下，如果把你在做的事情推演一番，你会发现哪些可以改进的地方呢？欢迎在留言区写下你的想法。
09 你的工作可以用数字衡量吗？
今天的分享从日常工作开始。请你回想一下，你每天到岗之后做的第一件事是什么呢？然后你来猜猜我的答案是什么？你可能猜不到，我每天到公司之后，第一件正事是看数字。
我现在服务于一家做数字资产的公司，我们提供的是一个24小时运行的服务。
从加入这家公司的第一天开始，公司的人就给我不断灌输一个重要理念——看数字。
在我座位的正前方，摆着一个巨大的显示器，上面展示着各种不断变换的曲线、柱状图和数字，这些数字反映的是各种系统运行的指标。
我们就是每天看着这些指标，来发掘一些线上系统问题的，一旦某些指标出现自己不能理解的异常，就要着手调查。
你或许会纳闷，我们不是在探讨“以终为始”吗？怎么变成了一个关于监控的讨论呢？
别急，我们确实还在讨论“以终为始”，因为数字是诠释“终”的最好方式。
我们前面讨论了各种“终”，但通常靠语言定义的“终”，或多或少都会存在一些模糊的地方，也就是容易产生误解的地方。而数字却是一个明明白白的“终”。
比如，测试覆盖率要求100%，即便你做到了99.9%，不达标就是不达标，没什么好说的，说破天也是不达标。
再比如，之前内容我们讲到精益创业时，提到了一个重要的反馈循环：开发（build）-测量（measure）-认知（learn）。
你会发现，在这个循环中，开发（build）是可控的，认知（learn）必须是得到反馈之后才能有的。
所以，这里面最需要我们回答的问题是测量（measure）。而这里的测量，最好的检验标准当然就是数字。
或许你会说，数字我们都很熟，还用讲吗？不过在我看来，你还真的未必习惯于使用数字。
熟悉而陌生的数字
从进化的角度来看，人们做事更多是依赖于直觉的。
数字，是人类在非洲大草原上奔跑了许久之后才创造出来的东西。著名科普著作《从一到无穷大》的开篇有这么一个故事：
两个匈牙利贵族决定做一次数数的游戏，看谁说出的数字大。- 一个贵族说：“好，那你先说吧！”- 另一个绞尽脑汁想了好几分钟，说了一个数字：“3”。- 现在轮到第一个贵族苦思冥想了，他想了一刻钟，然后说：“好吧，你赢啦!”
这个故事听起来有些荒诞，但一些非洲探险家证实，在某些原始部族里，不存在比3大的数词。
如果问他们有几个孩子，而这个数字大于3的话，他就会回答“许多个”。
虽然我们中华民族是一个重视教育的民族，现在也都承认数学是一门重要的基础知识。但我们还是习惯性地观其大略，因为在日常生活领域里，除了买东西发工资，需要对数字斤斤计较的场合并不多。
历史的车轮在不停地滚滚向前，当今社会所面临的复杂度已经远远超过凭直觉就能把事情做好的程度。
一些人说，自己靠直觉就能把事情做好，其实这是一种误解，因为那种所谓的直觉，通常是一种洞见（Insight），洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累，而这其实是某种意义上的大数据。
我们都在说，人类马上就要进入智能时代了。之所以这么说，主要是现在人工智能技术不断地向前发展着。
而人工智能作为一门在50年代就已经问世的技术，直到最近几年才得到大踏步的前进，主要归功于基础设施的发展。
在人工智能领域，基于统计的方法早就在学术界提了出来，但由于当时的技术条件所限，人们的数据采集和存储能力都有限，当时的“大”数据和今天的大数据完全不是一个量级的概念。
直到进入到互联网时代，随着处理数据量的增加，基础设施在不断地拓展，进而促使人们采集更多的数据，这个正向反馈也造就了今天的大数据。
原本因为缺乏足够数据支撑，难以施展拳脚的 AI 算法，在今天一下子有了足够的表演空间，从一个边缘角色成为了舞台中心的主角。
今天谈到人工智能，人们主要会谈三件事：算法、算力和数据。
算法几乎是行业共有的，而算力在云计算普及的今天也不再是稀缺资源，所以，数据几乎成了兵家必争之“物”。
于是，我们看到的现象是各个公司都在努力地搜集各种数据，让数据成为自己的竞争力。所以，在大方向上，数据采集是一个行业共识。
但是，作为这个世界上最了解数据价值的一批人，我们程序员只是在努力地把数据用于不断改善别人的生活，而对于自己日常工作的改善，则思考得少之又少。
我们更习惯的讨论方式依然是靠直觉。
比如：增加了这个特性可能会让用户增长，做了这个调整应该会让系统的压力变小。
在一些简单的情形下，或者说大家信息对称、知识背景相差无几的情况下，这样的讨论是很容易得到认同的。而当事情复杂到一定程度时，简单地靠感觉是很难让人相信的。
所以，在我们的工作中，经常会发生的一个现象是，一个人说，我觉得这个有作用，另一个人说，我觉得那个没有。
几个“觉得”下来，双方就开始进入了隔空对话的环节，谁也无法说服谁。
如果换成用数字的方式进行讨论，效果就会更好。
有一次，为了改善用户体验，我们准备进行一次主页改版。产品团队希望在主页上加上大量的内容，而开发团队则认为太多的内容会导致主页加载变慢，进而造成用户体验下降。
正当这个对话即将进入“空对空”的讨论之时，我们找到了一个测量指标：主页加载速度。只要保证主页加载速度，产品团队就可以按照自己的理解来做调整。
于是，一个即将不可挽回的讨论，变成了在一定约束条件下的讨论，双方谁也不再思维发散，讨论就能继续推进了。
如果你认同了数据本身的价值，那么再结合“以终为始”的理念，我们就应该在着手做一件事之前，先来想怎么去测量。
无论是在讨论产品特性，还是功能开发，“信口雌黄”是容易的，落到数字上，人们就会多想一下，这是对彼此的约束。
从数字出发
前面的内容我们都是在说应该重视测量指标，重视数字。
接下来，我就分享下几个我在实际工作中运用数字的案例，让你看看习惯用数字去思考问题之后，会拓宽哪些思考的维度。
首先是基于数字进行技术决策。
有一次，我们打算做一个技术改进，给系统增加一些缓存，减轻数据库的压力。
大家一起设计了两个技术方案。如果查询是特定的，我们就准备简单地在某些方法上加上缓存；如果查询是五花八门的，就准备用一个中间件，使用它的查询方案。
系统现在的情况到底是什么样的呢？我们发现并不能立刻回答这个问题。
于是，大家决定在系统中增加一些统计指标，让数据给我们答案。然后根据数据反映出的情况，进行具体的决策。
其次是一个准备上线的案例。
当时，我们是要做一个影响力比较大的系统升级，因为这是一个系统的关键模块，上下游系统都会受到影响。
谁也不能确定哪个模块会在上线过程中出问题。于是，设计了一个全新的数据面板，将相关的几个模块的核心指标都摆在上面。而我们要做的就是在上线的同时，观察这些指标的变化。
所幸的是，这次上线影响不大，几个指标一路平稳，而大家的信心就源自这些提前准备好的指标。
再次，看一个从数字中发现问题的例子。
由于各种历史原因，我们的重点指标面板上，会有几个指标表示的是类似的东西。
比如，某个模块的处理能力，一个指标是站在这个模块内部度量的，而另一个指标则是由这个模块上下游系统度量的。在大多数情况下，它们的表现是一致的。结果有一天两者突然出现了很大的差异，内部度量表现依然良好，而外部度量则出现了很大的延迟。
于是，我们开始追问为什么。一路追寻下来，我们发现，是这个模块内部需要定期将内部状态持久化下来，而在那个时间段内，这个模块就会停止从上游读取数据。所以，在内部看一切正常，而外部看则延迟较大。随后，我们找到了方案，解决了这一问题。
最后再说一个行业中的例子，据我所知，行业里的某些公司已经开始做所谓的 AIOps，也就是通过人工智能的方式，从数据中，发现更多运维的问题。
无论哪种做法，都是为了从数字中发现问题，让系统更稳定。
我的一个同事有个观点非常值得玩味，他说，从数字上看，好的系统应该是“死水一潭”。
我是赞同这个观点的，因为出现波动尤其是大幅度波动，又不能给出一个合理解释的话，就说明系统存在着隐患。而让系统稳定，正是我们工作的一个重要组成部分。
回到这一讲的开头，我说每天工作中的一个重要组成部分就是看数字，其实就是在尝试着从数字的趋势中发现问题，如今团队已经习惯了“给个数字看看”这样的沟通方式，内部扯皮的机会也相应地减少了一些。
总结时刻
随着智能时代的来临，人类社会开始逐渐认识到数据的重要性。
但我们这群 IT 人在通过数据为其他人服务的同时，却很少把数字化的思维带到自己的工作范围内。这也是工作中很多“空对空”对话的根源所在。
结合着“以终为始”的思考，如果我们可以在一开始，就设计好测量工作有效性的指标，那么就可以更有目的性地去工作了。
而如果我们习惯了用数字去思考，就可以在很多方面让数字帮助我们。
我举了几个小例子，比如：基于数据进行技术决策、预先设定系统指标，以及发现系统中的问题等等。希望你也可以把数字思维带到你的日常工作中。
如果今天的内容你只记住一件事，那请记住：问一下自己，我的工作是不是可以用数字衡量。
最后，我想请你分享一下，你的工作中，有哪些应用数字解决问题的场景呢？欢迎在留言区写下你的想法。
参考资料
http://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/10x%e7%a8%8b%e5%ba%8f%e5%91%98%e5%b7%a5%e4%bd%9c%e6%b3%95/04%20%e6%8e%a5%e5%88%b0%e9%9c%80%e6%b1%82%e4%bb%bb%e5%8a%a1%ef%bc%8c%e4%bd%a0%e8%a6%81%e5%85%88%e5%81%9a%e5%93%aa%e4%bb%b6%e4%ba%8b%ef%bc%9f.md
