在掌握这套方法之前，我一直是个蠢货(慎入！该文阅读有一定难度)。

这两天这一直在聊决策类的知识，

今天和大家聊聊实战的东西：如何解决问题。 尤其是和行动相关的问题。

为此，我特意把2004年的一本书翻了出来。 这是一本编程书。

当初正是这本书打开了我解决问题的视野。

你不需要具备编程知识。

我要讲的和编程无关。

你完全可以忽略代码的部分，就当是一堆图片好了。

我之所以坚持采用这个编程案例，是想把我当年大脑突然开窍的场景还原给你看。

现在让我们开始吧。

1

假设我们接到了一个大项目：为巴菲特所在的伯克希尔.哈撒韦公司编写一套财务管理系统。他们昨天刚刚出手了大约30%的IBM股份，需要计算一下这次抛售为公司回拢了多少资金。

如果我们的公司不像哈撒韦那么大的话，只需要一台计算器，一个乘法就可以轻松搞定了。然而，这家公司的生意遍布全球。像中国石油、比亚迪都是他们投资的对象，前者为他带去了500%的回报率，后者回报率更是高达745%。所以在他们的计算系统里还需要包括一些关于汇率对换之类更复杂的东西。

在系统里，我们需要标识出哪些是用美元交易的，哪些用的是人民币或者越南盾。

现在我们在编辑器里，敲入一段代码。

(再强调一遍，你不需要了解代码)。

这是一段测试代码,用来计算资金额度的。

我们假设每只股票的价格是5美元，

Dollar five = new Dollar(5)；

出手了2只，five.times(2)。

所以回拢的金额应该是10美元。

assertEquals(10,five.amount)；

代码中红色的部分，表示这个东西(对象)不存在。

它是我要和大家分享的第一部分内容。

很早之前，我思考问题的方法是：

这个问题需要什么技能(素材)，我拥有哪些技能(素材)，准备好，然后组织在一起。

注意，是 提前把这些素材准备好，然后组织在一起。

我们再看这段代码的解决思路：

要想解决这个问题需要什么。

我不关心你有没有这些素材(技能)。

我要的东西应该长成这样。

我不知道是不是说明白了。

再啰嗦一遍吧。

以前是我会什么，有什么，然后怎么做，以满足用户的需求。

现在是用户想要什么，所以你需要做到什么。至于你有什么？怎么实现？那是后面考虑的。

2

看出来了吗？

从结果出发，将一个大问题拆解成"以目标作为导向"的若干个小问题。

让我们回到代码。

有3处是标红的：

Dollar、

times、

amount。

这意味着，要想解决这个问题，我们需要先把这3个红色的部分处理掉。( 一个问题被拆分成了3个任务 )

在软件开发领域，我们将这种方法称之为『测试驱动开发』。 将它扩展到其它领域，就是：

『 目标驱动行为(任务) 』。

还记得我之前讲营销的那篇文章吗？

怎么把东西卖出去？

不是你有什么，然后怎么做。

而是，

想把东西卖出去，必须搞定哪几件事。

3件：

1、让人知道

2、使人感兴趣

3、引导人买单

假设我想在我家楼下开一家肉夹馍的外卖店，拆分出来的任务就是：

1、接收用户订单

2、准备好馍

3、把馍给用户送过去。

至于烤馍用的炉子有没有准备好？

可能是个任务，也可能不是。

当下我们关心的是：

1、接收用户订单

2、准备好馍

3、把馍给用户送过去。

是的，

我又重复了一遍。

其实我应该再重复一遍的。

3

基于任务需求，

我们完成了那3个部分的代码。

你不需要知道它是怎么完成的，反正就是完成了。

让我们跑一遍测试。

测试的意思就是看看这个实现是不是靠谱的？

答案是否定的。

你期望的是10，然而返回的结果却是0。

必须做些改动，才能让这个测试通过。

以证明我们当下做的工作是可用的。

然而，让我吐血的事情发生了。

Kent Beck，对，就是写《测试驱动开发》的那个哥们，居然直接返回了一个10。

没有任何算法，没有任务逻辑。

就是直接返回10。

他的目标仅仅是让这个测试通过，

当时我真的有点接受不了。

代码的逻辑在哪儿？

你怎么可以这么不付责任呢？

当时是2004年。

现在我早已经习惯了。

而且经常这么干。

让我们回到之前肉夹馍的那个例子。

要解决的3个问题是什么来着？

1、接收用户订单

2、准备好馍

3、把馍给用户送过去。

1、接收用户订单。

或许我们应该搞一个网络订单系统。

还有一种选择是，也许没必要那么复杂。

先复印几张传单，在上面留下我们的电话。

如果他/她需要，可以打电话给我们。

2、准备好馍

或许我们应该租个店面，

准备好烤馍用的炉子，

面粉，

还有肉

… …

也可以去西少把馍买上，

然后换上我们的包装。

3、把馍给用户送过去

以百米冲刺的速度，去西少那儿买上馍，然后马不停蹄的送给用户。

等等，难道我们不是应该卖自己的馍吗？

当然。

但

在此之前，

让我们先把这个模式走通。

4

每一笔订单都会让我们陪掉几块钱。

但到目前为止，我们还没有租赁厂房，没有买烤馍用的炉子，没有投入大量的人力成本去开发系统。

假如，我是说假如，没有多少人使用我们的产品。

太好了。

我们还没有为这件事投入太大的成本。

还有机会重来。

如果用户多得有点忙不过来，

太好了，

去买最好的烤炉和面粉吧。

让我们大干一场。

重新回到代码。

很显然，单单返回10是不行的。

它只是让这个流程能够快速得以通过。

现在，我们需要用真实的代码搞定它。

Kent Beck是怎么实现的呢？

2是什么？

卖出去的份数。

multiplier代表的不正是份数吗？

five.times(2)。

所以这段代码就变成了：

5又是什么？

每只股票的单价。

它不是由外部传入的吗？

Dollar five =  new Dollar(5)；

于是最终这段代码就变成了：

一开始，我们没有能力也没有时间把事情做得那么完美。

可以先找来一个替身，

让整个闭环运转起来。

我们应该有一个基于网络的订单系统。

但，

一开始，它可以用一个纸质的订单来代替。

我们应该支持微信、支付宝、所有的网上银行支付系统。

不过等待他们的回复、审批实在是太慢了。

所以一开始我们可以不走系统，让用户直接扫描我们个人的二维码就好。等商业协议落实下来，再切换到系统上的付款模块。

我们不是不追求完美。

我们要做的是先让一切能够跑起来。

证明它是可行的。

然后再一步一步打磨细节。

Facebook有一句特别著名的话：

完成好过完美。

它们就是这么干起来的。

顺便说一句，Kent Beck是Facebook的编程教练。

我接触这本书的时候是2004年。

当时书里的很多理念和我的日常习惯都是相悖的。

也不好接受。

还好，我没有沉浸在自己固有的思维里，

反复试验和练习。

当我真正掌握它的时候，给我带来的最大帮助反而不是在编程方面。

我几乎可以用它解决所有的行动问题。

这么多年下来，

我已经养成了这种『测试驱动开发』(目标驱动行为)的工作方式。

简单总结一下，

这套方法大概可以分为4步：

一、以结果为导向，描述出想要达到的结果，必须完成什么？而不是我有什么？

怎么把东西卖出去？

1、让人知道

2、使人感兴趣

3、引导人买单

二、将问题以『目标驱动』的方式拆解为若干个小任务。

1、让人知道

2、使人感兴趣

3、引导人买单

三、通过打桩快速让问题得以解决。

完成好过完美。

怎么让别人知道？

先印两张传单，在附近的几个办公楼试一试。

四、拆桩。

持续打磨细节，使它趋于完美。

这附近的办公楼都是一些年青人，

文化素质也比较高。

可以有针对性的拍摄一些抖音视频。

在午饭前投放。

故事的脚本应该是这样的...

这套方法是我在编程中学到的。

送给你。

呀！今天真早。

突然有点不适应。

这是之前的几篇文章：

如何让你的"资产"升职？

推荐两部影片给你，好看，还能提升职场竞争力

把大象装到冰箱里，拢共分几步？

直接向大佬学习。不要钱，还有得挣。

如果想和我聊聊，我在这里：