本文共2103字，预期10分钟阅读完成，我是张飞洪，感谢您的阅读。

01 尴尬的交付

不知道你是否遇到过交付不被认可的尴尬。工作这么多年，不管是向上汇报，还是任务下发，你会发现扯皮总是无处不在。

老板可能会告诉你我要做数字化，然后巴拉巴拉一堆需求：

1、类似ERP风格：包括业务模式，风格，类型(流程，表单，权限，组织架构等…)。

2、数据需求：无处不来，无处不去，有过往必留痕（必须进行存储），无处不支持，数据必须独立存在，要成为核心驱动能力。

3、集成需求：对别人的集成，充分开放、集成便捷、数据全面；集成别人，兼容性好、多样、高效、方便。

你胸有成竹，因为你都做过这些事情，ERP风格见多了，数据需求不就是数据库设计和存储吗？集成需求就是WebAPI接口。

等你吭哧吭哧干了半年，老板看了说这是什么破玩意儿？我要的不是信息化系统，是数字化系统，怎么没有大数据的影子？

确认后才知道，原来老板要的是数字化的智能系统，所谓的数据“无处不来，无处不去，有过往必留痕”在老板的认知世界里就是大数据，数据仓库的东西。

打开百度APP看高清图片

虽然这是一个简单的案例，但反映的却是我们日常面对的真实工作场景：许多人都是刚刚听到别人要求做的一个功能，就开始脑补接下来的一切。导致的结果，就是付出的努力毫无意义。那么问题出在哪呢？因为我们欠缺了“以终为始”的思维习惯。

02 倒过来想

所谓的以终为始，就是倒过来想问题，把时钟拨到里程碑的终点，并问自己三个问题：

• 最后我们交付的东西到底长什么样？

• 我们的客户会如何验收我们？

• 验收能通过吗？

如果结果是不可验收的，那么不论我们如何努力都可能变成白费。因为双方的认知没有共频，或者是一个假共频。

回到老板对数据提出的需求：“无处不来，无处不去，有过往必留痕”。显然这种需求是抽象和不可量化的。我们可以进一步向上求证：

• 这个东西有没有类似的系统；

• 是要做数据库还是数据仓库；

• 最终目的是想达成什么？

当我们倒过来想的时候，我们不自觉地会有种追问，因为我们是要交付产品的，模糊的需求最后会导致双输的局面。

以终为始，说起来很简单，但做到并不容易。因为我们习以为常的思维模式是顺序的，第一步做完，做第二步；第二步做完，做第三步。这也情有可原，我们人类都是从远古时代演化而来，在那个食不果腹的时代里，倒着思考的用途并不大，人们甚至不确定自己能否见到明天的太阳。

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

03 量化

当我们明确了最终的交付物，我们才刚刚迈出长征的第一步。假如我们要设计一个系统架构，业务需求到位了，我们准备开始规划我们的架构需求。于是你很快就罗列了成熟架构需要的素质：

我们先看第一个高可用设计，几乎没有系统不希望是高可用的，对用户来说高可用当然是永不宕机最好了。但是成本和投入太高，无法承担。于是如何定义高可用就是一个大问题。

我们看下如何用数字来设计度量指标：

我们应该根据什么来选择到底要几个9呢？

• 首先，我们要问业务能否满足？

• 其次，我们要问时间能否满足？

• 最后，我们要问人力能否满足？

这是一个权衡和妥协的过程，当业务刚刚起步，资源不足的时候，我们可能会折中，选了三个9，当系统接入支付系统，我们会选择五个9。

以上就是一个量化的过程，另外性能也是可以量化的，这里不再举例。人类之间是存在认知墙的，不量化不开工。

04 文档化

需求量化后可能散落在钉钉、微信等聊天记录里面，而且各自整理记录后，表述各不相同，这也是一个极大的风险。

从规划的角度看，如何把集体的共识无偏差地落实下来，文档化是唯一的依据。另外，文档的选择也很重要，如何确保文档是唯一的，现在有很多的云文档，比如飞书、钉钉、石墨、Office365等等都很不错。

不同种类都有自己的规范：

项目管理文档规范

该文档包含了项目管理的整个生命周期，形成了一个闭环。对于经常写文档的人来说，当你在动笔之前，不妨问问自己或者和团队讨论一下：

• 文档的大纲应该是什么样的？

• 大家是不是使用同一种协作文档？

05 业内实践

事实上，在今天的软件开发实践中，已经有很多采用了“以终为始”原则的实践。

比如测试驱动开发。测试是什么？就是你这段代码的“终”，只有通过测试了，我们才有资格说代码完成了。当然，测试驱动开发想要做好，并不是简单地写写测试。

再如持续集成，我们是要交付一个可运行的软件，倒着来想，最好的做法就是让软件一直处于可运行的状态，那就是持续地做集成。

有段时间，网上流传亚马逊 CTO 介绍亚马逊是如何开发产品的：简单来说，他们采用向后工作的方法，开发一项产品的顺序为：

• 写新闻稿；

• 写 FAQ（常见问题解答）；

• 写用户文档；

• 写代码。

当你了解完“以终为始”的思维模式，再回过头再来看这种做法，相信你就能理解为什么亚马逊要这么做事情了。

06 总结

今天，我带你了解了为什么会出现尴尬的产品交付，我们是如何通过以终为始，倒过来想问题的方法来解决交付目标，同时我也讲解了量化、文档化和行业的最佳实践来辅助理解，希望我的讲解能帮助到你，如果今天的内容你只能记住一句话，这句话是：凡事发生，逆向思考。

最后，我想请问下你，在平时的工作或生活中，你是如何解决交付的尴尬的？欢迎在留言区写下你的想法。

感谢阅读，我是张飞洪，如果你觉得这篇文章对你有帮助的话，也欢迎把它分享给你的朋友

标签：以终,无处,为始,文档,交付,符合,我们
来源： https://www.cnblogs.com/jackyfei/p/15423513.html