by pluskid, on 2012-01-23, in 
喜欢看书的同学，放假回家的时候都会带几本书呢？然后开学回学校的时候发现真正打开看了的又有多少本呢？反正我从前回家带的书总是看不完的，不止回家，甚至是去自习室或者图书馆，带的书也总是会超过我的处理能力——而且我还没次都是仔细计划过的。当然造成这样的原因有多方面的，比如多带几本书的话，在一本书看不下去的时候可以换一本；又比如也许是因为执行力不够没有能把计划实施（比如中途开小差去了什么的）。但是似乎有一个重要的原因在生活中其他地方也非常常见——就是我们对于时间或精力的估计上，似乎经常存在相当大的误差。
我想来想去，觉得大部分人进行估计的时候，由于无法预料和处理所有的细节，因此会将注意力集中在几个重要的因素上，然后忽略剩下的那些琐碎的细节。这是非常自然的方法，然而问题出在哪里呢？考虑哪些琐碎细节所占的时间，虽然它们单独都小到可以忽略的情况，但是各种各样的小细节加在一起如果总时间非常多呢？是不是就不成了？
比如，要写一个程序，主要的部分当然是在写代码部分喽，但是琐碎的部分呢？比如配置一下工程环境啊，做个 Makefile/automake/CMake 之类的啊，为编辑器选一个新的字体和配色方案来换一下心情啊，找个工具来高亮和清晰化编译器的编译错误啊，更新某个库到最新版本并解决一下相关的依赖关系带来的麻烦呀，去 reddit/twitter 之类的地方看看呀，去找一个“最适合 coding 的时候听的音乐专辑”之类的，等等等等。似乎根本就列不完，也没有办法事先想到所有的事，但是这些乱七八糟的事情加在一起就会悄悄地占去了想到“可观”的一大段时间，以至于最后计划中的任务可能只完成了一半。
当然，这样子来看似乎最大的问题还是这个人注意力不够集中，在这个观点上似乎有两派分歧的意见，因为有些人认为这些琐碎的时间是必要的，特别是在关于开发工具的 tweak 方面或者“不必要的”重构等方面所花的时间；而另一些人则相反。不过，且抛开这些问题不说的话，在写程序这个问题上，还有一个大问题就是 debug ：bug 的出现基本上是完全不可预料的，结果“乐观”的人通常倾向于假设 bug 可能是不会出现的；而“悲观”的人则会假定 bug 会出现，当然，这类人中也分为两类：假定 bug 即使出现也可以很快解决掉的人和觉得 debug 非常费时费力的人。结果呢，不管人们持什么观点，似乎最后项目中 debug 所消耗的时间总是远远大于真正 coding 所消耗的时间。而且由于 bug 总是各式各样的，所以导致对项目的时间估计成为一个非常困难的问题。所以每次老板问道“这个东西多久能写完”的时候，我都非常希望回答“我希望是一万年”…… =.=!!
类似的问题在画画中也会出现。我现在根本不知道自己画一幅画到底需要多少时间，因为根据我自己的记录，有些画是要画七八个小时才能画完的，但是有时候花个不到十分钟画出来的东西似乎也看起来挺不错的，然后我就很诧异，画画的时间都消耗在哪里的呢？这次过年无心工作的时候准备画一个小圆，于是趁机把各个部分所花费的时间大致记下来看看：
先是草稿部分，似乎经过 15 分钟的描绘，虽然还有许多细节都是粗略勾一下（比如手），但是整体形状以及有了，可以说修修补补一下基本上就大功告成了。后面 5 分钟的基本色的结果其实在最后没有用到，大概只是为了给自己一个概貌吧。然而实际上还差得远呢：
头部上色大概花了半小时，不过看起来似乎并不需要花那么多时间啊，就是头发、脸、眼睛和蝴蝶结嘛。然后是衣服也花了半小时，手和裙子更多（绿色的背景是辅助上色临时加上的）。最后差不多就只剩下脚而已，结果，在我都不知道到底画了些什么（所以我用“其他”来标注呢）的那段时间竟然用去了 40 分钟。然后是细节修改部分：
是不是基本看不出任何变化呢？然而却花去了 15 分钟——可以勾画出完整草图的时间。不过确实是有一些细小细节变化的，但是其实主要的时间是花在尝试添加一个背景上，由于画背景相当麻烦，我希望在网上找一张现成的图贴上去，然而找了好几张都由于视角和光线问题看起来不合适最后干脆放弃了。所以说，这部分可以算做是“不必要的”时间，就好比我们做作业，预计一个小时做完，然而突然出现一道题我们做错了或者老师做不出来，就产生了预期外的不必要的时间，然而，这些时间是不能忽略不计的。
最后，我决定把小圆的忧郁表情稍微修改一下：
其实就是把眉毛重新画了一下，当然（至少我看起来）表情还是有变化的（关于绘画中细微修改引起的强烈变化的问题，之前曾经专门讲过），不过这个过程居然耗时 20 分钟。其实也可以类比到写程序里，并不是看到只有 5 行代码就觉得是一下子搞定的事，也许是尝试了无数种解决方案之后才得出的这 5 行代码呢。
结果呢，关于时间的谜题似乎明白了一些，也许随着经验的积累，就会慢慢开始注意到那些消耗时间的小细节吧。
我画画一般有数个小时都是花在不知道什么地方了，修细节是永无止境的……在掌握不了长尾能有多长的时候只能是用一些硬的约束来调整时间分配了……
对啊，有时候发现大量的时间就是花在修一些细节上，有时候修整半天就会感叹，其实画画的过程似乎并不总是很有趣的哇，就像钓鱼大部分时间都是在那里干坐着一样……
不过我一般不限什么硬约束，而是画到自己烦为止…… =.=
kid新年好啊！
对细节估计不准是一方面，对大多人来说，专注力不够可能是造成类似看书计划完不成的更主要原因。毕竟如果做过一遍某件事，总能够大致估算出再做类似事情需要的时间。
新年好！
虽然专注力是一个重要的原因，但是目前我不同意你的说法。我觉得，即使是像公司里那样子严格的 deadline 控制，虽然表面上看起来是把时间估计和控制做得很好了，但是实际上很多时候应该是以赶 deadline 为目的从而损失和放弃许多东西才得以实现的，特别是在项目中，有些特性可能就暂时不加了，或者有些 bug 暂时不修复了，或者用一种后患无穷的临时解决方案之类的。
当然，如果老是做高度相似的工作那又另当别论了。
嗯，「专注力」是就看书计划完不成来说的，要是讨论软件工程就复杂了。发布成本、发布日期、功能集合、缺陷许可等等，可能都是要考虑的因素，项目经理要根据哪些是关键驱动因素，哪些是约束和浮动因素取舍。如果deadline（发布日期）是关键驱动因素，其他因素做妥协是常态啊。《Manage It!》讨论了这些问题。
更复杂的项目，比如《Show Stopper》描述的Windows NT，这些因素之间的关系就更错综复杂（人和事都掺杂其中）。
哈哈……还是你是专业的，谈到书籍还是说不过你……
你还会画画！真是全才啊！
从小就羡慕会画画的人
确实也surprise到了我。博主威武
普拉斯基君真是有才啊！
构图居然那么快就可以完成了! o.o
如果把眉毛所在的线稿单独放在一个图层里，和头发分开的话，改起来应该会容易些吧…
对，分开的话要好改很多，但是事先又不知道哪些地方会需要改，如果把太多东西都放在单独的图层里，那样会变得非常混乱。就本身这个样子也偶尔会弄错，上色的时候切换来切换去突然会发现自己原来在衣服的图层里在涂裤子或皮肤的颜色，那时候一般索性就将错就错了……
所以还是绘图软件太弱了 ^_^ 如果图层可以按照树形结构组织起来，拥有 PowerPoint 自选图形那样的“组合”和“取消组合”功能，取消组合可以到每一笔为一个单位就方便许多了。
图层树形结构倒是可以的，但是组合取消组合之类的那样就变成矢量图了吧。用矢量图的方式来绘制这种图画是不行的，一幅复杂一点的上完色的图，Photoshop 格式的话，经常要上百兆了，当然从理论上来说是可以用诸如 PS 的钢笔路径这样的工具（实际上 SAI 里有那样的钢笔工具，而且不像是 PS 那样需要用拖动的方式，而是可以直接画出来）使得每一个笔画都是一个可以修改的 component ，但是一个复杂的图案的话，那个笔画的数目可就难以想象了，那是无法管理的……
Linux 下常见的 svg 图标体积小渲染快，Photoshop 是不是为每个图层保存了整图大小的点阵版本，我还是觉得软件有改进余地。不过现在对这类软件是不了解了，若干年之后我如果也有设备的时候可以玩玩看 -.-
对啊每个图层都要保存的嘛，本来就是位图啊。不过可能 PS 它对处理速度和文件大小做了权衡吧。反正我是觉得大部分绘画里的图案是不适合用矢量图格式的，越接近写实和细节风格的越困难。你可以想象一下把一张照片用矢量格式来表示，反正我觉得会够呛的，说不定即使真的把所有细节都表示出来的话，渲染速度和文件体积可能比直接用位图还要大
很不错的博客，各种崇拜~
对于一般的个人兴趣行为，大多是估不准时间花费的（或者说不愿意去估）
但是对于工作上的事情，无论是项目规划还是写代码，一般都能估出实际耗时的，浮动最多在10%左右；一方面是参考经验值估算，另一方面是估好后就得努力按这个时间点来实现。。。