反反复复

什么叫做协调工作？

如果所有步骤都可以清晰切割，且先后清楚，那么大的任务可以切割成小的任务，每步设置好接口，指标，人手，然后各做各的，最后连接起来，大事情就做成了。

事实上当然没有这么理想。不说切割的难度、接口的复杂，人会偷懒。光是一点：任务是经常会出问题的，出了错，需要全局的调整。有时任务是不清楚的。要根据这一步的结果，决定下一步的对策。

抽象点说，从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理论存在一定的一般性：在许多任务中，你总能提取出一些局部，它是需要“反反复复”的。投入专门团队，加快反应速度，加快上下游速度，都是可用的加速方法。