核心瓶颈

决定木桶能盛多少水的是最短的那一根木片
                                                                 －－木桶原理
不管一个瓶子有多么大，出口决定了它倒出水量的多少。这个出口就是传说中的“瓶颈”。如果把瓶子比作团队，出口流出的水的速度是团队生产率的话。那么什么是瓶颈呢？我先卖个关子

2个月之前，有幸加入了“郎咸平中文网”群，进而很幸运的接触到了郎教授在娄底的讲座。在讲座上，郎教授讲了一个很生动的例子－－“中餐馆厨师”。在这个例子中，他用“厨师”比作企业的人才。企业就像“中餐馆”。这个模型中，很明显中餐馆成也“厨师”败也“厨师”。为了留住厨师企业就会给他大量超过他应得的报酬，而且还会感慨这么好的厨师太少了。

人才太少了，这就是企业的思维，那么怎么办？要多招人才进来才行，以丰厚的报酬作为诱饵，吸引更多人才进来，不然企业怎么发展啊是不是。这就是我们的现状，从这个现状中我们反过来想，可以发现，公司的瓶颈就是人才。

那么真正的人才在公司是什么地位呢？核心。对开发人员来讲，也就是核心开发人员或者项目经理等。那么我们是不是可以大胆假设一下：对公司来说，核心就是瓶颈呢？公司生产效率上不去，恰恰是由干得很好的核心开发人员和项目经理造成的呢？

这种想法有点离经叛道了，因为我们知道，在部门中，核心的力量是人所共知的，他们技术过硬、思维敏捷、业务熟练、有大局观，工作效率往往是最高的，怎么会是瓶颈呢？如果说是瓶颈也是由于这样的人才太少的缘故。

是因为太少吗？当我也是一个核心的时候，我也是这么想的，要是可用的人才多一点就好了。但当我来到一个新的公司，不再是核心的时候，站在旁边去看，发现了一些新的东西。

为什么说核心就是瓶颈，因为往往一个核心拥有的知识和一个非核心其知识量的差距是很大的。（注：是核心知识不是核心技术，核心知识指业务的重点、设计思路、系统的结构、用户需求等等需要权衡的一些点或者经验）但以量而计，我们大部分的工作是由非核心工作人员完成的。可核心往往喜欢扎堆，喜欢跟核心人员交流，导致核心知识总是以很慢的速度扩散到每个人。面对这对矛盾，往往很难解决。当然核心人员首先是人，是人就更爱和熟悉的人交流，强制他们不扎堆也是不符合人性的。显然在软件工程中，人们意识到这种瓶颈从而注意到文档的重要性，但是写文档的时间占耗是相当恐怖的。因而文档往往又变成了新的瓶颈。属于挖一个坑填另一个坑，到最后谁能保证文档就比代码好读呢？大多数情况下，文档不过是提供了一个全局的视图罢了。这就是另一个话题了，暂不展开。

另外，本身核心从客观上讲已经不可能不是瓶颈了，我们的企业或者团队又总会在上面再盖个盖子。不过企业得坏话还是少说的好，这里就不说了，大家自己体会去吧：）

那么有没有一种办法可以缓解这种瓶颈效应呢？有，那种办法叫做“结对”。是敏捷开发的一种实践。详细的说明推荐看一下《敏捷软件开发：原则、模式与实践》。