如何让你的努力不白费

先来思考一个问题：如果让你设计一个登录功能，你会怎么做？

我曾在公司内部做过这样一个练习，我扮演客户，让大家帮我设计一个登录功能。同事们一听就高兴了，登录不就是用户名加密码嘛，我熟啊，我还可以设计出验证码、找回密码、第三方登录等等功能。

更有个别动作快的同事，甚至已经开始设计数据库表，考虑用Redis做缓存了。整个过程下来，大家彼此讨论得热火朝天，唯一没人理会的就是我这个“客户”。

讨论结束，扮演客户的我告诉大家，作为一个“土豪”，我打算做一个打车软件，用户可以通过手机号接收验证码的方式进行登录。你可以想到，同事们一副“被套路了”的表情。是的，他们设计那套用户名密码登录完全是对不对题。

虽然这是一个简单的练习，但反映的却是我们日常中对的真实工作场景：许多人都是刚刚听到别人要求做的一个功能，就开始脑补接下来的一切。导致的结果，就是付出的努力毫无意义。

那么问题出在哪呢？因为我们欠缺了“以终为始”的思维习惯。

一种反直觉的思维方式
以终为始，就是在做事之前，先想想结果是什么样子的。

说起来很简单，但做到并不容易。因为我们习以为常的思维模式是线性顺序的，第一步做完，做第二步；第二步做完，做第三步。

这也情有可原。我们人类都是从远古时代演化而来，在那个食不果腹的时代里，倒着思考的用途并不大，人们甚至不确定自己

能否见到明天的太阳。几十万年的进化留给我们很多短视的行为和思考习惯，因为这样的做法最为节省能量，把目光放长远是需要额外消耗能量的。

“以终为始”是一种反直觉的思维方式，是大多数人不具备的。所以，日常生活中，我们看到很多有趣的现象。

比如，大学毕业时，有很多人想考研，如果你问他为什么要考研，得到的理由通常是为了找个好工作。但考研真的能帮他找个 好工作吗？不一定，因为找工作和考研根本就不是同一棵技能树。

如果真的是想找个好工作，那你就应该了解工作的要求是什么，怎样才能掌握工作要求的技能。

从后从这个⻆度出发，你会发现考研只是通往工作诸多道路中的一条，其他的路径也是可以到达的。比如，你应该找个实习的地方锻炼一下职业技能。这就是“以终为始”思考问题的方式。

回到前面“设计登录功能”的例子，对比“以终为始”的思维，你也许会替我的同事抱不平，他们或许也有“以终为始”的思路，只不过，他们的“终”和我这个客户的“终”不一样罢了。这就要说到做软件，本质上是在构建一个“集体想象”。

想象的共同体
如果你读过尤瓦尔·赫拉利的《⼈类简史》或《未来简史》，有一个说法你一定不陌生：想象的共同体。作者认为，人类历史发展的一个重要因素是“集体想象”，无论是国家、宗教，还是法律、习俗，都是人们达成的“集体想象”。人类就是认同了这些“集体想象”的一个共同体。

我们这些做软件的其实就是一个想象的共同体，这个“集体想象”就是我们要做的软件，任何想象都需要一个载体将其展现出来，我们编写软件的过程就是将这个“集体想象”落实的过程。

既然是“集体想象”，那么在载体将想象呈现出来之前，我们的想象很难统一起来，都或多或少存在差异。

所以，任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的构建或第二次创造（Physical/Second Creation）。

我们在工作中遇到的很多问题，其实就是在于第一次创造没有做好，就进入到第二次创造。所以，我们在工作中会遇到很 多“惊喜”，准确地说，是惊吓。

相对于第一次创造，第二次创造是一件成本很大的事。我们知道，软件开发最费时费力，一旦投入大量精力做出来，却发现与 理解偏差甚大，所有人都会欲哭无泪。

所以，在动手做事之前，我们要在第一次创造上多下一些功夫，将相关各方的“集体想象”统一起来。以建筑为例，就是先在图 纸上构思各种细节。对应到做软件，我们也可以做很多事，比如：

1. 要给用户看产品的样子，可以用原型工具把它做出来，而不是非得把完整功能开发出来；

2. 要呈现服务接口的样子，可以用模拟服务器搭出一个服务，而不用等后端全部开发完毕；

3. 要让程序员知道要开发产品的细节，可以在任务上描述出软件各种场景给出的各种行为。

再回到前面“设计一个登录功能”的例子上，我的同事们在构建的其实是他们自己的想象，而不是我们共同的想象。这其中最大的一个区别就在于，没有人会为他们自己的想象买单的。

所以说，他们看到的“终”不是真正的终，只是一1个自我的“终”，至于看到什么样的“终”，这取决于每个人的见识。

对做软件的人来说，我们应该把“终”定位成做一个对用户有价值的软件，能够为别人带来价值，自己的价值才能体现出来。 至此，你对“以终为始”已经有了一个初步的认识，有了这种思维方式，我们可以在工作中怎样运用它呢？

规划和发现
软件行业有很多英雄传说，一个人或者一个团队连续奋战一段时间，写好了一个软件，在上线前夜发现了一个问题，然后冒着“不成功便成仁”的风险，通宵达旦解决了问题，一战成名。

这种故事听起来让人热血沸腾，但仔细想想，为什么总在最后时刻发现问题？除了时间压力确实大的情况以外，大多数情况， 他们还是在开始没有想好就动手了。

在团队内部，我一直坚持“以终为始”，让大家在执行任务之前，先倒着想想再动手规划，这样规划出来的工作更能瞄准真正的目标。举一个之前做产品的例子，当年在创业的时候，我们打算做一个物联网开发平台，但具体应该做成什么样子呢？

有了“以终为始”的思维，我们考虑的是别人会怎么用我们的平台。我们设计的方式是，用户到我们的网站，阅读相关文档，然后参考文档一步一步照着做。

这其中的一个关键点是：文档，特别是《起步走》的文档，这是用户接触我们这个平台的第一步，决定了他对我们产品的第一 印象。

所以，我们决定从写《起步走》这个文档开始，这个文档描绘了用户怎样一步一步使用我们的开发平台，完成第一个“Hello World”级别的应用。请注意，这个时候，我们一行代码都没有写。

写好了这个《起步走》文档，团队的所有人对于我们的平台要做成什么样子，已经有了一个比较初步的认识。更重要的是，我 们可以拿着这个文档，去和外部的人讨论这个尚未出世的平台。

人类是一个擅长脑补的群体，一旦有人看到了这个文档，他就已经可以构想出这个平台已经存在的样子，进而给出各种各样的反馈：“我认为这个地方可以这样做”“我觉得那个地方可以改改”。

所有这些反馈都是真实的，因为他们已经“看到了”一个真实的东西。正是这些真实的反馈，让我们逐渐地锁定了目标。之后，我们才开始动手写代码。