前言

当你是junior时，每次交给你一个任务你大概可以想像要怎麽样达成目标，对於丢给你的问题，即使不知道要怎麽解，但你也大概有方向知道怎麽样做是对的。然而世界没有想像中的美好，随着seniority的增加，你处理问题scope越来越大，问题越来越复杂，大部分状况其实是没有清楚的答案的，更多是也没有所谓「正确的答案」存在，在这种情况下你要如何做决策？

这篇文章蛮适合给Senior或者Leader来看，特别是当你发现你的工作充满着未知与不知道怎麽做决策的问题时，可以看看这个演讲提供的建议是否对你有帮助。

演讲总结

这篇演讲的主题是告诉我们如何做困难的决定以达到远大的目标，特别是那些你没经验也毫无概念的任务。

做决定的困难点

为何随着年龄增长，你处理的问题会越来越趋困难？

• 因为问题本身越来越模糊，并不像junior的任务这麽清楚定义好。
• 要花的时间越来越长，你要完成任务的时间可能从一两周变成，一两个月一两季甚至变成一两年。
• 下决定的成本越来越高，一旦走错路可能要改正回来非常的困难。

在这样复杂模糊与困难的状况下，我要怎麽知道我做的决策是对的？
讲者表示基本上没救，当下你拥有的资讯不可能让你知道最後决策是否是正确的。

因此，与其思考怎麽样做「对的决定」，不如思考怎麽「修正错误」。

如何做决定？

讲者建议我们可以使用「精益方法（lean approach）」去达成长期与高不确定性的目标。接下来就是要细讲这三个部分。

（图片来源：原演讲投影片）

Step 1. 拟定计画（Form a plan）

1. 写下问题的描述、限制、与动机

   不同於那些你已知或熟悉的任务，这种计画很难拟定就是因为你根本也没有经验，所以首要之事就是先厘清问题本身与记录下来，因为它已经超过你脑袋的记忆体容量了。

2. 指定负责人（DRI，Directly Responsible Individuals）

   通常在做困难决定时都会一群人一起讨论，大家会彼此争论观点，也因此很容易就会形成争论半天但毫无结果的状况，所以这时候这位DRI的目标就是确认整个决策过程是有在向前进迈进的。

3. 打击分析瘫痪（analysis paralysis）

   跟上一点雷同，基本上就是要防止无进度的讨论。在做决策时人常常过度分析事情本身而苦於做出决定。所以尝试跳脱这个循环，确认每次meeting都是有在向前进的。

而我们希望在拟定计画的部份能获得以下成果：

• 以文件记录下来问题的所有相关资讯
• 确认负责人是谁
• 达成共识选择一个方向向前迈进

这里的方向不用是确定的解法（其实你也无法得知确定解法），只要是一个可以尝试的小赌注就可以，下面来解释这点。

Step 2. 做小赌注（Place small bets）

小赌注的特徵：

1. 尽量简单与越小越好
2. 一个月内可以获得feedback
3. Bonus: 可以平行操作的话更好

做小赌注的目的很明显，我们希望多样性的尝试不同的方向（diversification），利用类似MVP（Minimum viable product）的方式去理解哪个方向比较适合。如此一来我们便可以

1. 获得更多资讯帮我们做决策
2. 帮助我们思考风险
3. 降低处理问题的复杂度。

这边有几个常见的方式是这种小赌注的实现方式

• 可行走的骨架（walking skeletons）：其实就是MVP或者说可以动的prototyping XD。
• 部分上线（Partial releases）：释出一小部分的功能，利用feature toggle或whitelist控制会受到影响的用户。

Step 3. 吸取教训（Get feedback）

最後吸取教训的部份就是从一次又一次的小赌注中，尝试做到

• 获得feedback确认方向是否正确
• 尝试早点修正与解决问题

总结

当初美国在拟定「登月计画（Project Moonshot）」的时候，没有人知道到底该怎麽做，更不知道怎麽做才对。但为了快速达到这个目标，前人做的尝试就是不断的利用MVP去尝试：尝试发射火箭到太空，尝试回收火箭，尝试在太空生存...。不断的利用快速的feedback loop去逼近目标。

如果大家有兴趣可以看看google的X company，他们把各项登月计画变成一次又一次的登屋顶计画（roofshots），也才能不断的达成各种不可能。

最後总结整个演讲的点

• 建立一套迭代进步的流程
• 审慎思考，但偏向着重目标（bias toward action）
• 建立护栏，早日发现问题与修正它
• 从小赌注中重新调整与协调
• 不需要等到你真的知道怎麽做之後再开始

个人心得

这篇的主题真的意外的蛮有趣的。

虽然他在讲的是做决策，但其实跟解决问题是同样的道理。一般人可能都会想说解决问题的方法是：先列出你想达成的目标，然後想办法分成小阶段去完成这个目标。但现实状况是你可能根本对於问题本身都不够清楚，也没有前人的经验，那在这种资讯不完全的状况下你要怎麽达成你的终极目标。

超越工作本身的哲学

我自己觉得这个approach其实不只是套用在工程上，也是一种很好的生活哲学。

工作的目的其实就是在教导你如何面对世界。

你怎麽处理工作上的未知，其实就跟你怎麽处理生活上的未知是很一样的道理。工作模式的抽象，其实完全是可以套用在生活上的。

例如你工作觉得无趣而想尝试转领域当工程师看看，但你知道这个成本很高，不确定该如何做决定好？那你或许可以套用上述的方法，加入个bootcamp认真花个一两个月学个coding感受一下，或许可以有更多资讯帮助你做最终决定。

再例如我自己也曾经尝试改进我的时间管理，而时间管理有各种framework可以套用那我应该选择哪个呢？我也不知道，所以我就先乱选了Get Things Done（GTD）试试看。在密集的尝试一个月之後，我发现几件事：

1. 我不适合GTD。主要是因为中间的review process花的时间有点多，我有点难建立这个习惯。
2. 我内心或许也没把时间管理当成first priority，动机不够高，所以我愿意投下去的时间精力没有想像中的高，我想这也是某个会失败的原因。

就像这个铁人赛也是一个对自己的尝试，看看写文章是不是个适合我的路线XD，目前已经写了2/3，流程上的收获蛮多，希望我最後一天有时间好好整理这些东西。

关於如何做决策

当Leader常常发生的事情是，当大家遇到两难、难以下决定的状况时，常常会请Leader来决定到底要怎麽做比较好，但其实很多问题Leader本身也不太知道答案。例如说两个性质相近的API到底要合成一只还是分成不同的？例如这个DB要使用Mysql还是用HBase？例如我们到底该不该把commit code gen出来的code还是只在deploy的时候dynamic的gen出来？

其实这些大方向决策的问题，我也都没答案，其实也无法得知哪个比较好。因为**「系统设计本来就是一项预测未来的过程」**。好的设计只是这个设计对於预测的未来刚好比较match，而不好的设计或设计错误，往往只是当初的预测跟未来走向不同而已。

所以很多时候与其花时间讨论哪个决策是最好的，不如就选择一个方向做下去，因为计画总是赶不上变化的。我们自己到最後决策的重点，往往考虑的是当这个决策是错误时，有没有办法修正？或者这个决策的风险有多高？只要这些小赌注的後果是自己可以承担的，那我们就可以先往这些方向前进。

所有决策都是最好的决策

不要追求最好的决策，将你的决策变成最好。

虽然与上文写的没有什麽关系，但我觉得人生其实就是一连串的决策过程。很多时候你不见得需要像上面那样做各种小的尝试，更多时候是快速做决策後，尝试把下定决心的结果变成最好。

心思细腻的人往往会多想到底哪个决策是最好的？花了很多时间分析优劣，但是却迟迟不愿意下决定。我自己其实也是这样的人：在考虑要不要换手机前就会思考各种换手机的优劣，在出去玩就会各种比较哪个地方会玩的比较尽兴，租房子的时候有两个各有优劣的选项苦苦无法选择，究竟要待在现在公司还是换去其他地方，到底应该要跟喜欢的人告白还是不要(?)。花了很多的时间分析优劣却还是不知道怎麽下决定。

我觉得分析是必要的，但是过度分析只会导致更加难以抉择，因为其实大部分选择的优劣，都是无法比较的。所以与其继续苦恼无法做决定，还不如选定一个方向做下去，然後慢慢的把你的决策调整成最好。但要记住的是这里的最好不是指如预期结果的最好，而是你自己能接受的最好。因为我们无法控制外界事务，但是我们可以控制自己面对事物的心态。