看周星驰的《功夫》，印象最深便是火云邪神说过的一句话：
天下武功，唯快不破。
之后从高中开始，便开始受「互联网模式」的熏陶。
互联网模式很强调一点：快速迭代，小步快跑。
然而，只求「快」并不一定是好的。
「快」，不一定真的快
这阵子我重复开始感受这一点。这两年我一直听到一句话：DDL 是第一生产力。但我越来越觉得：DDL 是最糟糕的生产力。
这里并非否认 DDL 的作用，而是提醒要重视时间管理，避免被 DDL 赶着跑。
有时候项目进度压身的时候，我会下意识地做很多快速的判断和决定。
诚然，这些判断和决定都有着一定的思考和经验积累。然而，在很多时候，这种「快」会带来很多的「折腾」，甚至比原来更「慢」。
比如：为了赶在 DDL 前完成 xx 课程的作业，我在没有通读作业和课程的情况下，用 30 分钟作业的书写。尽管我依旧可以根据自己的经验把做作业写到 60 分，但是这距离我参加课程的目标就有了很大的偏差。
因此，我下次仍然需要抽出 2 个小时把上次的课程再读一次，然后再重新迭代一次作业。
原本只需要 1 次就可以完成的事情，我用了 2 次来完成。
单次来看，在第一次的时候我使用了 30 分钟就完成了作业，确实很快。但实际上，我最后总共花了 2 个半小时，还加上中间各种因为作业写不好内心的不舒服，这就称不上「快」了。
「慢」，有可能是真的快
中国有句古话，慢工出细活。
而在团队协作中，适时的「慢」不仅仅不会拉低整体进度，还尽量避免团队成员要帮你「擦屁股」的情况出现。
举个例子。
运营同事 A 向设计师 B 提交了一个设计需求。
设计需求：设计秒杀商品活动 banner
尺寸：首页轮播图
活动商品：后台搜索 xx 商品，即可找到
拟订完成时间：2017 年 12 月 12 号
当这个需求到达设计师 B 的时候，设计师首先要做如下几个事情：
-
确定首页轮播图的尺寸
-
上后台搜索 xx 商品，看到原价，然而没看到秒杀价格
-
跟运营再次确认秒杀价
-
开始制作 banner
乍一看，这是一个「快速」且「完整」的设计需求。
然而，从流程管理和效率而言，这并不是最合理。对于团队而言，在同一个模块产生了同样的动作和时间损耗。而这，便是资源的浪费。
换个角度而言，便是拖慢了整体的进度。
如果提交的设计需求是如下的：
设计需求：设计秒杀商品活动 banner
banner 尺寸：1080 x 864
banner 商品：xxx 商品（点击链接 xxx.com 即可）
banner 元素要求：xxxx
活动原价：xx 元
秒杀价格：xx 元
拟订完成时间：2017 年 12 月 12 号
尽管这样子需要耗费在「提设计需求」上的时间更多了，但实际上整体的进度更快，而对于运营本身的时间也有了极大节约。
为什么？因为避免了设计师在设计过程因为模糊需求产生的问题打断自己的工作进程。
流程管理与协作
在流程管理上，评判快与慢的思考纬度应该看的是整体流程的时间能否被节省，而不能够单看子节点。
最后的最后，时间管理真的很重要。
image
网友评论