早年，我在大公司工作的时候，极厌恶繁琐的文档要求。当年开发戏称：一天写代码，就要再搭配两天写文档。流程对于效率的阻碍已经到了忍无可忍的地步，但无奈势单力薄，只有继续再忍。

待到羽翼丰满，新工作只考虑小公司，对于高效率的工作环境心生向往，知道大公司能给你很多你想要的东西，但这项恰恰除外。

如愿进入创业公司 ，我去的时候规模不大，创立不足三月，没有规范，没有限制，只要把任何搞定，想怎么来就怎么来。那段时间的确是成绩斐然，大半年时间做的项目比我过去两年还要多。

但好景不长，公司高层产生矛盾，IT部经理转投他人，带走了超过一半的骨干力量。然后，IT部副经理扶正，无奈行业当时正处于蓬勃发展期，新开公司多，机会也多，再加上内部的一系列调整。四个月之后，被扶正的IT部经理也转投他人，又一次带走了剩余的骨干力量。

经过这两轮残酷的人员轮换，原有的老员工所剩无几，工作交接时就发现文档过于简略，导致新接手的员工完全不知道该问什么样的问题。等老员工一撤，马上坠入地狱，开始不断的安排人员进行反向解析、试错, 期间的过程惨不忍睹。

这时候才开始切身体会到大公司的习惯性思维：文档化+人员备份，可以降低多大的风险。

终于，开始清楚的看到一个小公司如何变成一个大公司的过程，期间的人员调整、制度演进、在效率与风险之间的不断进化，让我对于大公司的这么一些东西有了更深入的了解，才开始明白：

他们之所以不遗余力的推广这些看似高成本、低效率的东西，那都是因为之前交过学费、吃过亏的。

现在，周报、文档、员工的分权备份，一样都不能少，我依旧会觉得麻烦与厌恶，还是会不时的提出反对意见，要求更多的效率以及更简便的流程，但现在比起才从大公司出来那一阵，却已然不同了。

很多事情都是类似，产品经理要求可以把一些具体的需求放在高度抽象的战略思维框架中，同时又可以从这种战略思维框架中把事情拆分成一系列可执行的工作。这种具体-->抽象-->具体的过程产生的结果有可能与直接把需求抛给执行层是一样的，但并不代表他没有价直值。这样的思考与推演，提升了策略选择的完备性与确定性，让我们明白，我们到底为什么做这样的事情。