抽象一步是理想和现实之间一座坚实的桥梁

Void

<p class="ql-block">抽象一步是我相当喜欢的一种工作态度。</p><p class="ql-block"><br></p><p class="ql-block"><b>抽象</b></p><p class="ql-block"><br></p><p class="ql-block">什么叫抽象?抽象就是在有一件事情出现的时候,稍微跳脱一点,用一种更加通用化,更加根本的方式解决问题。“授之以鱼不如授之以渔”,“磨刀不误砍柴工”,“釜底抽薪”,“治标治本”等等所描绘的场景都是一种抽象。</p><p class="ql-block"><br></p><p class="ql-block">对于技术领域,如果需求是改一个文案,并且可以预见这样的需求会是比较频繁,一定要对这样的需求进行抽象,抽象为一个方便的内容管理工具,而不仅仅做体力活。若是没有这个能力,今天拿到需求写了个A,明天改成B,后天再改成C,改了一个月以后就会吐槽产品经理需求变化多,吐槽业务没想明白。这些都是抽象的功力不够。</p><p class="ql-block"><br></p><p class="ql-block">外界的需求,遇到的问题如同大海表面的波浪,一味跟随会晕船,稍微抽象一点就下沉了一些,波动就少了。需求一直在变,而他背后的抽象的意图相对稳定;技术的方案中这一点体现得更加明显,越通用,越抽象的东西越稳定。</p><p class="ql-block"><br></p><p class="ql-block">我在看很多同事的工作,都会问一句话:这里有没有抽象一步的可能性。单单这一个问题常常开启更高效更深层解决问题的道路。</p><p class="ql-block"><br></p><p class="ql-block"><b>抽象一步</b></p><p class="ql-block"><br></p><p class="ql-block">抽象其实并不难理解,很多人也在做,而我发现真正的关键的是抽象到什么程度。</p><p class="ql-block"><br></p><p class="ql-block">我认为最好的抽象是仅仅抽象一步。既不能不抽象也不能抽象超过一步,走到两步三步去。不能从一个需求出发,然后就进入深邃的思想世界,不断的抽象,思考到问题的终极情况并且根据这个终极情况做事情。</p><p class="ql-block"><br></p><p class="ql-block">比如刚才提到的改文案的例子,显然一次抽象就是做一个可以很快改文案的工具。但是聪明的工程师灵机一动,仅仅是改文案还不够抽象,应该把改banner也一起考虑进来,变成一个更加通用的内容管理系统,这叫抽象两步;进一步抽象下去,这不仅仅是可以管理内容,更加通用的解题方法是一个系统里面所有资源的编辑系统等等。。。沿着这个思路不断进行下去就是多次抽象。</p><p class="ql-block"><br></p><p class="ql-block"><b>多次抽象的问题</b></p><p class="ql-block"><br></p><p class="ql-block">多次抽象的问题在于:</p><p class="ql-block"><br></p><p class="ql-block">第一:它需要的资源过多。每多抽象一步,所需要的资源常常大幅增加一次,复杂性也是大幅增加。很有可能所需要的时间比较明显的超过了一次抽象的时间,更是远远的超出了最初需求的时间。持有这种想法的实施者尝尝会面对想做没有时间的困境,常常梦想等什么时候空下来,需求少一点的时候再来做这个终极大杀器,然后,常常就是没有然后了。</p><p class="ql-block"><br></p><p class="ql-block">第二:它无法获得支持和理解。对于合作方(包括需求方,包括团队成员,包括支持方),一步的抽象清楚干脆,所有的人很容易理解,很容易达成一致并且获得支持。对于多于一步的抽象,整个思考过程就变得晦涩,不稳定,达成共识的可能性降低,因为那是一个完全在自己脑子里面的世界,是基于现实构建出来一层抽象,在这个还没有被大家认知的一次抽象上构建二层抽象,就如同《盗墓空间》里面的第二层梦和第三层梦一样,非常的不稳定。没有可见的事实摆在所有人的面前,沟通成本和说服工作明显提升。持这个想法的人常常会苦恼于别人无法理解自己的工作,无法预见自己所预见的未来。然后,也是没有然后了。</p><p class="ql-block"><br></p><p class="ql-block"><b>一步抽象的好处</b></p><p class="ql-block"><br></p><p class="ql-block">与多步抽象相比,一步抽象的好处恰恰就是在这里:</p><p class="ql-block"><br></p><p class="ql-block">第一:它所需要的资源较少,可能仅仅比头疼医头的方法多了可以接受的一些资源。磨刀不误砍柴功,我觉得就是比较好的一步抽象,若是临时做一把刀,一定要耽误开柴功了,要是开柴先从炼铁开始,估计这个时间成本没有人能够接受。</p><p class="ql-block"><br></p><p class="ql-block">第二:它容易达成共识。因为“来源于生活又高于生活”,一步抽象方案比来什么做什么方案更容易被大家看到好处,但同时因为只抽象了一步,这个好处是看得见的,摸得到的,立刻就是有成效的,所有的人都会把帽子扔向天上大呼万岁。在所有人的期待中做事情总比在不理解中做事情要幸福得多。</p><p class="ql-block"><br></p><p class="ql-block"><b>一步抽象是通向多次抽象的必由之路</b></p><p class="ql-block"><br></p><p class="ql-block">那这里就会有很多聪明人感觉到一步抽象过于简单,虚伪,妥协。但我反而认为,一步抽象是走向最终的多次抽象的必由之路。</p><p class="ql-block"><br></p><p class="ql-block">人不能没有宏大的终极的目标,但把这个目标拆解成一步一步是一种能力,在实现了一步以后所有人自然的会看到下一步抽象的机会。我们看到的社会的推动者大多都是这样的实用主义者。他们的过人之处就是想到了最终的宏大目标,却把它们隐藏起来,而用大多数人能够接受的对于现实的一步改造开始,慢慢的积累动量,越改越快。</p><p class="ql-block"><br></p><p class="ql-block">好多人,尤其是工程师会面临一个两难的苦恼:现实被迫做着重复工作,因为时间所限写着不够优雅的代码,而且在一个泥潭里面挣扎;同时心里有着美好的梦想,希望做些很厉害的大产品。这个时候,几种自然的不切实际的幻想就会产生:</p><p class="ql-block"><br></p><p class="ql-block">幻想一:啥时候能够给我三个月的时间我好把以前的东西理一理;</p><p class="ql-block"><br></p><p class="ql-block">幻想二:啥时候能有一个靠谱的产品经理/业务经理/公司/高管等等;</p><p class="ql-block"><br></p><p class="ql-block">幻想三:啥时候需求能够稳定下来,啥时候有人能告诉我一年以后我们要到哪里我好提前准备。。。</p><p class="ql-block"><br></p><p class="ql-block"><b>死结</b></p><p class="ql-block"><br></p><p class="ql-block">现实就是有很多死结。有影响力的人是去解这些死结人。解绳结,需要这根绳抽一点点,腾出一点点空隙,然后给另外一根绳一点点的空隙,让它也挪动一点点,这个空隙反过来让原来的那根绳有了更大的空隙;就这样一步一步,很多的死结都是这样通过这样的迂回和迭代解开的。</p><p class="ql-block"><br></p><p class="ql-block">历史上的大的死结也是这样子去解的:中美对抗的死结,先打个乒乓球吧,打了球再让球队访美,一来二去最终建交了;二战后德法冲突的死结,先成立个管理两国煤炭和钢铁资源的委员会吧,建了这个委员会以后发现可以干比煤炭钢铁更多一点的事情,一来二去,煤炭钢铁委员会最终改名叫欧盟了;新加坡的经济困境,先去做鱼钩吧,这个能做,鱼钩能做了,自然的下一步就是更多的产业,一来二去成了今天的强国。要是这些最终成就的推动者不是从所有人都能可以理解并且支持的第一步开始,留下的只能是历史的遗憾。我曾经着迷于莫奈,李光耀这些人的愿景,但最近我更加钦佩的是他们在一个充满无解的死结的世界里面,通过优化一步的方法让事情发生的能力。</p><p class="ql-block"><br></p><p class="ql-block">一步抽象就是现实和理想之间的非常坚实的一个桥梁。既不能在泥潭里面破罐子破摔,也不能愤然离去在一个远远的地方自己建城堡,而是永远怀着正面的意图,做一些比现实高,但是只高一步的东西,并且持续去做,时间长了,每个人都会惊讶于这一次一次迭代带来的显著效果。</p><p class="ql-block"><br></p><p class="ql-block">谨以此文和那些努力创造着一些东西的同学共勉。</p><p class="ql-block"><br></p><p class="ql-block">题图:Sonoma, CA, 2011</p>