今天的工作我的感悟是，efficiency=difficulty/dependency^2.一个任务越难，负责人的单位工作效率就越低。然而，如果这个任务牵涉到的人多了起来，任务完成的依赖性就越来越高。这时候，效率会疯狂地下降。
在大型的公司内，尤其是我们组这样的合作项目组中，基本每次做产品都会和开放商撕一撕。我们有我们的期许，他们有他们的难处。然而每一个产品每一个功能的开发，都少不了两边的合作，这样，对于每一个产品，依赖性都异常地高。Startup之所以发展的快，fail fast,prototype fast就是因为他们的核心人员往往就是开发，自己琢磨一下就着手弄了。然而在尾大不掉的公司，冗余的流程很多，人员技能的缺陷（pm没有良好的代码技术，工程师没有好的产品品味），导致了每一个产品都慢上半拍，只有靠着招聘更多的人员来弥补开发速度和运营的质量，然而这样表面上提高了总的单位工作力，其实增加了总的依赖性。在我看来，增加人力对于依赖性的增长斜率是高于工作力的，所以每多一个人，看上去是提高了速度，其实最后在不改变内部工作分工和流程的情况下反而会有副作用。
举个例子，直播火起来之后，自然而然地，YY、斗鱼这些巨头应该想到移动端直播。但是出于不知名的原因，居然是不知名的映客抢了先机。瞬间之前平台直播的巨头们都开始追赶移动直播，开放手机直播信号接入，导流给户外、生活主题的主播，这些都已经慢了半步。难道这些公司里就没有人曾经想到如今移动互联网阶段的这一步棋吗？肯定不会。然而从应对措施来说，很明显可以看出，就是动作缓慢罢了。
再举个例子，当时火的要死的一个黑客单挑特斯拉、谷歌的小哥，就是一个人一个车库一台电脑一台车折腾出“民科”自动驾驶的雏形。谷歌和特斯拉不可不谓是行业巨头，尤其是谷歌依据自己得天独厚的地图和庞大的机器学习界智库资源，车子还在路上测试，这个小哥就已经带着记者遛了好几个弯了。可想而知，对于谷歌而言，这个项目的依赖性有多高：街景、地图测的数据支持，人工智能专家的技术，硬件开发团队，软件工程师也要融合各端。而小哥就举起扳手带上电脑就开始搞了。即便他个人的生产力明显低于大公司，但是他的依赖性基本为零，所以效率却可以放大很多倍。
或许，流程改革以及管理科学将会是互联网公司更上一层楼的核心步骤，也或许，若干年后我老老实实上一些课之后会回来笑斥幼稚的自己。这一定很有趣。