One take,可望而不可即

  One take,是几年之前看综艺节目听林志炫提到的一个词,就是说录制一首歌曲一次性完成,无需后期的各种修音。这个概念听起来就很酷,对不对?

  作为一个程序员,我经常也希望能够One take:一次性把事情做好,不用反复。但逐渐发现,追求One take是很难的。

  本文地址:https://www.cnblogs.com/xybaby/p/9607331.html

关于读书

  坦白的说,我看书不多,不管是技术书籍还是人文。除了本身不够热爱、不能坚持的主因,忙碌是不可忽视的客观原因,现在大家都提倡碎片化阅读,这对于非技术书籍还行得通,但对于技术书籍,尤其是自己不是很擅长的领域,还是需要大块集中的时间去阅读。

  因为花在阅读上的时间少,我就特别希望One take:一本书读一遍就基本掌握,至少掌握我所感兴趣的部分。但事实上,基本是不行的,读完一遍之后经常是一遍空白,究其原因:(1)年纪大了,记性变差,这是自然规律;(2)碎片化阅读,捡了芝麻丢了西瓜,缺少连贯性;(3)也许阅读本来就不是一件能一蹴而就的事情。

  那么我也在继续努力,试图最高效的阅读一本技术书籍。我自己目前的阅读大约是这样的:首先看前言(Preface),看看这本书想要讲得是什么,重点在哪里;第一遍通读全文,做好笔记,包括写得好的地方以及暂时不明白的地方;第二遍,结合书籍的目录和笔记,以及每一章的总结(summary),回顾整本书的内容,有一个全面的掌握,梳理内在逻辑关系。第三遍:整理成读书笔记或者思维导图,以便之后检阅。

  当然,实际情况是,之后用到的时候,还得去查看原文(毕竟原文比笔记详细)。

  书读百遍,其义自见,古人诚不欺我。在阅读(精读)这件事情上,似乎并没有什么捷径,想要One take,太难。

关于需求

  程序员与产品经理之间不可调和的矛盾,是大家津津乐道的话题。

  作为程序员,自然经常会骂:PM傻逼,啥都不懂瞎指挥,鄙视!当然,PM也在骂:程序搓逼,这都实现不了,鄙视!

  要和谐相处,其实需要双方的努力,尤其是在知识背景差异很大的情况下顺畅地沟通,以达到共识。不过,在这里,仅从程序员的角度出发,讨论PM改需求的问题。

  让程序(或者还有UI、美术)最为头疼的事情,就是PM改需求。对于改需求,程序自然是深恶痛绝的。不过,这不就是追求One take吗?希望策划的需求一次性确定,程序实现之后就不要再改动了,这是最好的、最理想的状态,一气呵成,不过现实基本都不是这样的。

  对于PM,当他有一个idea的时候,仅凭脑补是很难验证的,这个时候就得需要程序帮忙实现一个原型,帮助去验证、完善想法。在《你的灯亮着吗》里面提到,无论表面上表现得如何,在你提供他们所要求的东西之前,他们极少知道自己想要什么。即使在需求实现之后,在老板的要求下、在与其他同事的交流中、在用户的实际体验反馈后,都会发现一些需要完善、调整的地方,这个时候就会有需求的改动。换个角度思考,一个功能、产品实现出来之后,如没有任何进一步的迭代需求,那么多半是没有用户使用。因此,不是说PM不想一次性搞定,而是根本就做不到。

  在《怎样才算得上合格的程序员》一文中也提到,一个合格的程序员需要在业务的角度去思考、讨论需求,既能帮助自己和PM搞清楚真正需要解决的问题,又能为之后可能的需求变化做一定的准备。

  另外,对于程序写代码这件事情,也是不存在One take的。因为不能一次做好,才会有重构、才会有敏捷开发、才会有大牛说“好的架构不是设计出来的,而是演化而来的”。只不过,重构这个事情,是由程序员自身去驱动的,在程序员看来觉得是合理的、值得投入的;但是在PM上看来,也可能会觉得是浪费时间。而该需求这件事,在程序看来可能是浪费时间,但对于项目、对于业务来说是值得的。

  有的时候,我们应该反思,自己是否“严以律人,宽以待己”了。  

  也许,当明白,提需求--实现需求不大可能One Take之后,可以互相体谅吧

posted @ 2018-09-08 09:45  xybaby  阅读(790)  评论(1编辑  收藏  举报