什么叫做协调工作?
如果所有步骤都可以清晰切割,且先后清楚,那么大的任务可以切割成小的任务,每步设置好接口,指标,人手,然后各做各的,最后连接起来,大事情就做成了。
事实上当然没有这么理想。不说切割的难度、接口的复杂,人会偷懒。光是一点:任务是经常会出问题的,出了错,需要全局的调整。有时任务是不清楚的。要根据这一步的结果,决定下一步的对策。
抽象点说,从A走到F,不是ABCDEF的顺序,而是ABCBCBCBCBCDEF。 有些步骤,反反复复,既要debug,又要兼顾效果。反反复复处,效率可高可低,需要有人管。管是为了降低成本。具体说是降低沟通的成本,以及加快流程的进度。
以前有人问我老板,哪本书最好啊?老板说,这个问题错了。你以为,学习是线性的过程?先学X,再学Y,再学Z?不是的。学X你发现没学过Y很吃力,学Y你又发现X的某些定理是基础。怎么办?没关系,先看X,再看Y。当然先看Y也行。看不懂再看一遍。因为最终你不会只看一遍X或者一遍Y,而是每样都看很多遍。哪一样先,其实不太重要。
说到底,还是反反复复。
那怎么反复才快呢?
显然,要缩短BC的周期。
聚焦。像医生做手术,用布将无关的部分盖起来。ABCDEF,首先要知道BC是反复的地方。这本身就需要判断。然后,可能需要制定目标。因为A是起点,F是终点,都是清晰的东西。但要知道BC好不好,对不对,可能需要另一个指标验证中间步骤的得失。否则,每次做完C,都要往下走到DEF才能看到答案。有时可能很费事。如果往下走是不可避免的步骤,那就让DEF尽可能快可以实现。这成为了加快迭代的要点。有时需要A的配合,那么A加速也同理地重要。
由于迭代可能是多次的,所以每次的结果,必须可以复用到下一个版本之中。
然后是人员的投入。最好是BC分别有人负责,这样容易抽取其中的诀窍。这是分工的思维。但分工以后沟通要非常快速。最后一方有需求另一方马上响应。一天1次来回与5次来回,看上去差不多时间,但效率是5倍。
这些道理很简单,难是难在,你要在具体的任务中,抽象出ABCD来。甚至有时候这抽象不存在,你需要发明另一个理论(可能也是很简单的,也跟上述类似)。于是,如果你抄来一招ABCD,并拘泥于其中,未必有利。但以上ABCD理论存在一定的一般性:在许多任务中,你总能提取出一些局部,它是需要“反反复复”的。投入专门团队,加快反应速度,加快上下游速度,都是可用的加速方法。
留言