不求完美,先让事情开始,然后再完善它

2016-12-25   出处: 8thlight  作/译者:Nick Dyer/思雨

你曾经遇到过难以开始一件事情吗?我不是在谈论在冬季启动一辆汽车,而是一些工作,可能是一个新项目或一篇博客。启动新项目不容易。你还记得你曾经思考过,说过或听过下面的一些事情吗?


 “我还在计划这件事。”

 “我需要做更多的调查。”

 “我的想法还不够完美。”

 “我还不确定哪种方式最好。”


症结


这些片断有个共同点。最好的情况显示为犹豫不决,最坏的情况可能是分析瘫痪。这个情况(对某些点的思考和分析无法前进)并不少见。

作为一名软件开发人员,有两种情况在这种状态里会经常出现:选择做什么和怎么做。在同时扮演产品经理和开发人员的个人项目里,我们必须两种情况都处理。合同方往往不必处理“做什么”,因为产品经理或业务经理会做这个决定。怎么做,通常要开发人员花大量时间在上面。


开始写程序不久,我们意识到通常有更多方式来解决“怎么做”这个问题。这意味着一名程序员要花一些时间来考虑不同的实现方式。这个思考过程肯定有价值-通常一些想法很快就会被排除而被其他简单的想法代替。当一些明显的选择被排除后困难的部分就来了。从这个职位出发,我们想要一种方式来决定最好的选择。


选择的矛盾


Barry在他2005年的Ted演讲中说到选择的矛盾。他确认当自由选择是一个好机会时,社会上的大量选择“留给我们的不是更自由而是更无力,不是更快乐而是更不满。”为什么选择更多反而不是好事?


无力分析让人压力很大-自带焦虑和自我怀疑。这些感情,尽管没有有形输出,但却使用了有价值的认知资源。开车时使用手机被认为很危险,因为这会分散我们对路上危险的注意力。与此类似,当我们因为担心而精力分散时,对于我们手头的问题,我们深入考虑或创造性思维的能力会降低。


第二个关键因素是选择疲劳。我们做的决定越多,决定就变得越困难。众所周知,成功人士包括Steve Jobs, Carrie Donovan和Mark Zuckerberg每天穿同样的衣服。当这一点被质疑时,Zuckerberg回应到:


“我真的想梳理我的生活来实现对任何事情做尽可能少的决定,除了如何最好地服务这个社区之外。”

反复分析后给出所有这些负面结果,我们怎么做能避免选择的矛盾呢?

 

快速决定


将一个实现决策过程分解成一些明智的选择,我们怎么做能防止做出无效的分析?一个点子是抛硬币决定:


 “当面临两种选择时,只是抛硬币来决定。这种办法有用不是因为它为你解决了问题,而是因为当硬币在空中的短暂时刻,你突然明白了你想要的是什么。”

—Kevin Purdy


然而这个引用倾向于做不太重要的决定,我认为这个概念有效。有时候当我们花太长时间分析我们的决定时,我们的直觉会变得模糊。当决定不明显时,抛硬币能使一些模糊的东西变得明确。在某些情况下潜在的本能选择没有直接出现,抛硬币吧,因为这是一个结果同样可行的好机会。另一个好处是减少了我们的思考时间。这样做我们可以最大化我们获取更多信息的时间。


 “但是如果我做了错误的事情或者错误的决定怎么办?”


在软件开发中,不像许多其他情况,在初始阶段作出错误决定的成本是非常低的。当前版本控制系统的能力意味着对实际的影响是微不足道的。当我们做了错误的决定我们只是失去了时间。我们可以通过减少我们花费在分析一个决定上的时间来减少我们失去的时间。然而,那不意味着我提倡每次遇到选择困难时就用不够好的代码直接冲进生产环境。做决定是第一步,不是最后一步。


然后完善


我们也可以利用这次机会来提高我们的代码质量。看到实施可能带来的重构、改善命名规范或者让代码更精炼的机会。


这个观点和许多现有软件实践相似。在干净的代码里,Robert Martin描述了一个他叫做持续改善的过程,其中有人在对代码质量改善之前先写了粗略的代码。通过他的测试驱动开发的三个规则,他加强了代码,这有助于确保你不用去做一个大的决定,但是采取一些小的改进措施来引入测试过的产品代码。


类似地,遵循Kent Beck的四大简单设计原则,我们确保我们的代码在再次代码迭代之前以可能最简单的方式通过测试。


不清楚是否这些原则的设计是为了抵御决策失误,但是其中每一个用某种方式来避免决策失误。

 

最终决定


思虑过多对我们的产出是不利的。为了避免这一点,我们应该尽可能减少我们选择的数量,减少我们做决定的时间,最终将一些东西列在纸上来加固它。

做一个小跳跃来尝试第一个选择产生的证据,在此基础上,我们可以做出更好的决定。通过小迭代措施,我们确保我们的决定是成本低而又可变的。我们不是为了避免难题而做一个无聊的决定,我们是为了做一个更好的决定而做一个快速的决定。


好了,现在我们下定决心尝试“快速的抉择”而又不影响产品质量。同时在迭代过程中,快速的选择停止来控制住质量。



【英文原文:https://8thlight.com/blog/nick-dyer/2016/11/17/dont-make-it-perfect.html


{测试窝原创译文,译者:思雨}
译者简介:思雨,长期从事软件测试职业


声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
280° /2809 人阅读/0 条评论 发表评论

登录 后发表评论