02 以终为始：如何让你的努力不白费？
你好，我是郑晔。
今天内容的开始，我希望你可以先来思考一个问题：如果让你设计一个登录功能，你会怎么做？
我曾在公司内部做过这样一个练习，我扮演客户，让大家帮我设计一个登录功能。同事们一听就高兴了，登录不就是用户名加密码嘛，我熟啊，我还可以设计出验证码、找回密码、第三方登录等等功能。
更有个别动作快的同事，甚至已经开始设计数据库表，考虑用Redis做缓存了。整个过程下来，大家彼此讨论得热火朝天，唯一没人理会的就是我这个“客户”。
讨论结束，扮演客户的我告诉大家，作为一个“土豪”，我打算做一个打车软件，用户可以通过手机号接收验证码的方式进行登录。你可以想见，同事们一副“被套路了”的表情。是的，他们设计那套用户名密码登录完全是文不对题。
虽然这是一个简单的练习，但反映的却是我们日常面对的真实工作场景：许多人都是刚刚听到别人要求做的一个功能，就开始脑补接下来的一切。导致的结果，就是付出的努力毫无意义。
那么问题出在哪呢？因为我们欠缺了“以终为始”的思维习惯。
一种反直觉的思维方式
以终为始，就是在做事之前，先想想结果是什么样子的。
说起来很简单，但做到并不容易。因为我们习以为常的思维模式是线性而顺序的，第一步做完，做第二步；第二步做完，做第三步。
这也情有可原。我们人类都是从远古时代演化而来，在那个食不果腹的时代里，倒着思考的用途并不大，人们甚至不确定自己能否见到明天的太阳。几十万年的进化留给我们很多短视的行为和思考习惯，因为这样的做法最为节省能量，把目光放长远是需要额外消耗能量的。
“以终为始”是一种反直觉的思维方式，是大多数人不具备的。所以，日常生活中，我们看到很多有趣的现象。
比如，大学毕业时，有很多人想考研，如果你问他为什么要考研，得到的理由通常是为了找个好工作。但考研真的能帮他找个好工作吗？不一定，因为找工作和考研根本就不是同一棵技能树。
如果真的是想找个好工作，那你就应该了解工作的要求是什么，怎样才能掌握工作要求的技能。
从后面这个角度出发，你会发现考研只是通往工作诸多道路中的一条，其他的路径也是可以到达的。比如，你应该找个实习的地方锻炼一下职业技能。这就是“以终为始”思考问题的方式。
回到前面“设计登录功能”的例子，对比“以终为始”的思维，你也许会替我的同事抱不平，他们或许也有“以终为始”的思路，只不过，他们的“终”和我这个客户的“终”不一样罢了。这就要说到做软件，本质上是在构建一个“集体想象”。
想象的共同体
如果你读过尤瓦尔·赫拉利的《人类简史》或《未来简史》，有一个说法你一定不陌生：想象的共同体。作者认为，人类历史发展的一个重要因素是“集体想象”，无论是国家、宗教，还是法律、习俗，都是人们达成的“集体想象”。人类就是认同了这些“集体想象”的一个共同体。
我们这些做软件的人其实就是一个想象的共同体，这个“集体想象”就是我们要做的软件，任何想象都需要一个载体将其展现出来，我们编写软件的过程就是将这个“集体想象”落实的过程。
既然是“集体想象”，那么在载体将想象呈现出来之前，我们的想象很难统一起来，都或多或少存在差异。
所以，任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）。
我们在工作中遇到的很多问题，其实就是在于第一次创造没有做好，就进入到第二次创造。所以，我们在工作中会遇到很多“惊喜”，准确地说，是惊吓。
相比于第一次创造，第二次创造是一件成本很高的事。我们知道，软件开发最费时费力，一旦投入大量精力做出来，却发现与理解偏差甚大，所有人都会欲哭无泪。
所以，在动手做事之前，我们要在第一次创造上多下一些功夫，将相关各方的“集体想象”统一起来。以建筑为例，就是先在图纸上构思各种细节。对应到做软件，我们也可以做很多事，比如：
- 要给用户看产品的样子，可以用原型工具把它做出来，而不是非得把完整功能开发出来；
- 要呈现服务接口的样子，可以用模拟服务器搭出一个服务，而不用等后端全部开发完毕；
- 要让程序员知道要开发产品的细节，可以在任务上描述出软件各种场景给出的各种行为。
再回到前面“设计一个登录功能”的例子上，我的同事们在构建的其实是他们自己的想象，而不是我们共同的想象。这其中最大的一个区别就在于，没有人会为他们自己的想象买单的。
所以说，他们看到的“终”不是真正的终，只是一个自我的“终”，至于看到什么样的“终”，这取决于每个人的见识。
对做软件的人来说，我们应该把“终”定位成做一个对用户有价值的软件，能够为别人带来价值，自己的价值才能体现出来。
至此，你对“以终为始”已经有了一个初步的认识，有了这种思维方式，我们可以在工作中怎样运用它呢？
规划和发现
软件行业有很多英雄传说，一个人或者一个团队连续奋战一段时间，写好了一个软件，在上线前夜发现了一个问题，然后冒着“不成功便成仁”的风险，通宵达旦解决了问题，一战成名。
这种故事听起来让人热血沸腾，但仔细想想，为什么总在最后一刻发现问题？除了时间压力确实大的情况以外，大多数情况，他们还是一开始没有想好就动手了。
在团队内部，我一直坚持“以终为始”，让大家在执行任务之前，先倒着想想再动手规划，这样规划出来的工作更能瞄准真正的目标。举一个之前做产品的例子，当年在创业的时候，我们打算做一个物联网开发平台，但具体应该做成什么样子呢？
有了“以终为始”的思维，我们考虑的是别人会怎么用我们的平台。我们设计的方式是，用户到我们的网站，阅读相关文档，然后参考文档一步一步照着做。
这其中的一个关键点是：文档，特别是《起步走》的文档，这是用户接触我们这个平台的第一步，决定了他对我们产品的第一印象。
所以，我们决定从写《起步走》这个文档开始，这个文档描绘了用户怎样一步一步使用我们的开发平台，完成第一个“Hello World”级别的应用。请注意，这个时候，我们一行代码都没有写。
写好了这个《起步走》文档，团队的所有人对于我们的平台要做成什么样子，已经有了一个比较初步的认识。更重要的是，我们可以拿着这个文档，去和外部的人讨论这个尚未出世的平台。
人类是一个擅长脑补的群体，一旦有人看到了这个文档，他就已经可以构想出这个平台已经存在的样子，进而给出各种各样的反馈：“我认为这个地方可以这样做”“我觉得那个地方可以改改”。
所有这些反馈都是真实的，因为他们已经“看到了”一个真实的东西。正是这些真实的反馈，让我们逐渐地锁定了目标。之后，我们才开始动手写代码。
“以终为始”的方式，不仅仅可以帮我们规划工作，还可以帮我们发现工作中的问题。
有一次，我的团队在开发一个大功能，要将现有的系统改造成支持多租户的系统。也就是说，别的商家可以到我们的平台上发起申请，拥有和我们现有平台一样的能力。
功能来了，各个团队将任务分解，然后就各忙各的去了。但我有着习惯性的不安，总担心丢点什么，于是催着项目经理梳理一下上线流程。
是的，上线流程，虽然我们的代码还没开发完，但是本着“以终为始”的态度，我们就假设各个部分已经开发好了，来想一想上线应该怎么做。
果不其然，一梳理上线流程，我们便发现了问题：怎么识别不同的租户呢？有人给出的方案是设置一个HTTP头。但谁来设置这个HTTP头呢？没人仔细想过。于是，一个潜在的问题就这样被发现了，至少不用在未来为它加班了。至于解决方案，作为程序员，我们有的是办法。
事实上，在今天的软件开发实践中，已经有很多采用了“以终为始”原则的实践。
比如测试驱动开发。测试是什么？就是你这段代码的“终”，只有通过测试了，我们才有资格说代码完成了。当然，测试驱动开发想做好，并不是先写测试这么简单的。
比如持续集成，我们是要交付一个可运行的软件，倒着来想，最好的做法就是让软件一直处于可运行的状态，那就是持续地做集成。
概括地说，践行“以终为始”就是在做事之前，先考虑结果，根据结果来确定要做的事情。
这是“以终为始”这个内容版块的开篇，后面我会给你介绍这个原则在不同场景下的应用，也会引入一些现在行业内的最佳实践进行解析。相信会对你的实际工作有帮助。
总结时刻
有一段时间，网上流传着一个帖子，亚马逊 CTO 介绍亚马逊是如何开发一项产品的，简单来说，他们采用向后工作的方法，开发一项产品的顺序为：
- 写新闻稿；
- 写FAQ（常见问题解答）；
- 写用户文档；
- 写代码。
今天我带你了解了“以终为始”的做事思路，回过头再来看这个帖子，相信你不难理解为什么亚马逊要这么做事情了。
人们习惯采用顺序思考的思维方式，几十万年的进化将这种思考模式刻在了我们的基因里。要成为更好的自己，我们要克服自身的不足，而这个做法很简单，那就是“以终为始”，做事倒着想，先考虑结果。
人类是一个想象的共同体，做软件的团队更是如此，而我们写出来的软件是我们将“集体想象”落地的载体。
任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的或第二次创造（Physical/Second Creation）。我们应该在第一次创造上多下功夫，统一集体想象，让目标更明确。
“以终为始”的思维可以帮助我们更好地规划我们手头任务，也可以帮助我们发现过程中的问题。
如果今天的内容你只能记住一件事，那请记住：遇到事情，倒着想。
最后，我想请你思考一下，在实际的工作或生活中，你有运用“以终为始”的思维方式吗？帮助你解决过哪些问题？欢迎在留言区写下你的想法。
感谢阅读，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友。
- arronK 👍（193） 💬（8）
以终为始，我刚毕业准备找工作写简历的时候就是这么干的。 1. 先确定我想要找到的工作是什么样的， 2. 然后收集很多招聘网站上给出的对应需求，整理划分成一份简历的技能树 3. 写好最终的简历 4. 按照简历上的要求去学习和提升 这个方法我自己用起来百试不爽，也推荐给了身边的朋友。哪怕不是要去面试，想提升自己的技能和价值，也可以假设写一份想要达成的简历，然后以终为始去执行。
2019-11-16 - Gojustforfun 👍（100） 💬（11）
前段时间遇到一个事，领导派给我一个任务——做一个XXXX功能，没太细说就告诉我：你自己去想，自己去看别人怎么是实现的，把他弄出来 我经过一番调研，这个大功能可以拆分为8个小功能。于是我将4个必备小功能（编号1~4）实现并提交； 领导看了说：还少……功能呢。我一看哦还要加上6号小功能，实现并提交； 领导看了又说:我们的业务我是这样……所以需要……。我理解后发现要加的不是8号小功能的变种嘛，实现并提交； 领导看了没说什么算过了。几天后接到领导QQ弹窗：怎么没有……功能呢（我一看是7号小功能，还不等我说什么）你是怎么回事，总是少这少那的，非得我说的那么细吗一步一步告诉你怎么做？…… 真是日了🐶了，他不详细告诉我他头脑中的想象，但却要实现他要求的功能，问多了觉得你能力不行需要嚼碎了喂你，按我自己的想象实现后要经常返工，次数多了最终还是落在能力不行、做的太少啊等等负面评价 现在接任务我都是战战兢兢，不知道该怎么办了，想听听老师和小伙伴们的意见和建议 看来今天的文章，我觉得可以尝试原型，但考虑到地位的不对等以及我的“人设”已经定型了，实施起来有点难度
2018-12-28 - yu 👍（25） 💬（2）
延伸出来的思考。 拿到一个需求先写接口文档，评审过了再开发代码。争取做到接口文档就是最终的实现方案，不需要做着做着再去沟通方案。而不是拿了需求文档，直接就写代码。 好处： 1. 写接口文档，可以更好的规划工作量和时间。 2. 梳理的过程中，可能会发现一些考虑不周的技术问题，提前排雷。 3. 评审的过程也是自我提高的过程，说不定沟通中有比自己认为的有更好的技术解决方案。
2019-02-14 - Zopen 👍（23） 💬（1）
以终为始 遇到一位喜欢的女孩，先想象她已经成为我的女朋友，然后列出她喜欢做的事情，兴趣爱好，尽量去做；列出她不喜欢的事情，尽量避免；保持沟通，最后，她成为了我的女朋友。
2021-03-07 - Y024 👍（18） 💬（1）
“以终为始”，最常见的一个实践就是计划倒排了。先定时间，然后看功能是不是做不过来得砍掉一些，人力是不是不够需要补充一些，提前预知规避风险。
2018-12-28 - 大力 👍（11） 💬（2）
最近在复习10x程序员，并且在将每一课都做成思维导图，不知道郑老师有没有兴趣读读呢？实在不知该如何上传至极客时间。
2019-05-12 - 陈斯佳 👍（10） 💬（2）
《高效能人士的七个习惯》中也指出了以终为始的重要性，不过老师这里又进一步对程序员的“终”加以定义:做一个对用户有价值的软件。你价值的大小取决于你能为他人提供多少的价值。
2019-08-01 - Beluga 👍（9） 💬（3）
我最近最受益的地方在于亲密关系，疫情期间看了《高效能人士的七个习惯》，根据以终为始原则。我就在想最终我是要和她成为更好的自己，也更好的成为自己。最我的目标是两个人幸福，相互帮助，相互鼓励和成长的过一生。所以追求她的时候我很耐得住性子，确认关系以后我也很包容她。因为我知道结目标是最重要的。
2020-08-13 - 大力 👍（9） 💬（2）
以终为始，令我想到了“先订家具再装修”的套路，这样可以避免供电位不合适要返工等情况。
2019-05-14 - 周孟 👍（7） 💬（1）
"以终为始"是不是就是所谓的"结果导向"。以前经常听到说"结果导向"，但不是很明白，现在感觉有点明白了：无论是哪项工作最好的结果应该都是最终达到相关“共同体”的”集体想象“，所以工作中最优先的就应该去搞清楚这个“集体想象”
2019-04-24 - 斯盖丸 👍（5） 💬（1）
请问老师怎么把握一开始通盘考虑和敏捷开发的度？现在都提倡敏捷，总感觉想多了就成了瀑布型的了…
2021-01-15 - Stephen 👍（4） 💬（1）
以终为始的例子：以结婚为目的的恋爱😀
2021-04-17 - 尼格尔的叶子 👍（4） 💬（1）
联想到刚工作那段时间，在遇到技术问题时，第一时间想到的是请教别人，然而并不能准确的描述问题的根源，所以会浪费两者的时间。如果我们能以结果为导向，那么在请教别人的时候就能更精确的描述问题，提出你想要什么，需要别人提供怎样的支持，会比一句：“你帮我看看”来的更有效果，与此思想有相似之处。
2020-03-22 - 王维 👍（4） 💬（1）
这确实是一种思维方式，从结果反推前导，这条原则不仅适用于工作，而且还适用于生活。在具体的开发工作中，我也使用过这个原则，例如在做一个功能之前，我会画一个原型图，先让要使用的人确认，如果ok我们就动手开发。 其实我们在生活或者工作中有意或者无意都用到了这个方法。
2019-01-08 - 小小杨 👍（3） 💬（1）
第一次负责一个系统时，由于没有任何经验.不知道如何下手 当时就和产品沟通这个系统最终要做成什么样，要达成的目标.一起梳理出几个迭代版本 最近迭代版本的功能范围和时间要求，感觉一下子就清晰很多. 有对任务进行了分解，开始没想清楚就直接分解，验收标准不清楚，全凭感觉.第一个迭代效果很不理想，很多任务表面完成实际留着尾巴. 后来对第一个版本的目标大块分解成产品 架构 开发 测试最终要达成的目标和验收标准.各个团队对各自负责的进行分解 任务粒度 验收完成标准 比如设计 要求设计方案文档 设计方案牵涉关键技术研究文档输出，设计方案评审记录，最终设计文档.
2021-03-24