以终为始:如何让你的开发符合预期

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

01 尴尬的交付

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

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

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

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

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

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

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

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

打开百度APP看高清图片

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

02 倒过来想

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

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

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

  • 验收能通过吗?

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

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

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

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

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

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

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

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

03 量化

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

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

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

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

  • 首先,我们要问业务能否满足?

  • 其次,我们要问时间能否满足?

  • 最后,我们要问人力能否满足?

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

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

04 文档化

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

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

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

项目管理文档规范

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

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

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

05 业内实践

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

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

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

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

  • 写新闻稿;

  • 写 FAQ(常见问题解答);

  • 写用户文档;

  • 写代码。

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

06 总结

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

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

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

原文链接:,转发请注明来源!