我认识一个小软件公司亚太区的技术总监，是一个在亚洲的欧洲人，聪明绝顶，不是CTO胜似CTO，他对公司产品的精通程度，以及对软件技术的掌握和钻研远远超出了常人的水平。他能够利用产品的开放接口，通过预留给客户的二次开发功能，做出比产品出厂功能还要棒的新功能；很多员工说，他做的二次开发的功能比公司研发人员做出来的一次开发后的产品还要棒。还要吸引客户。整个亚太区很多国家解决不了的技术问题都会找到他，他也往往不会让同事们失望，工作没日没夜的，一般都能够利用各种产品技巧和软件技巧解决问题；他自己通过二次开发写出来的一些功能甚至传播到了世界各地的同事们中间，很多其他区域和国家的同事都用他写出来的东西来赢得客户的青睐。
　　这样的员工真的是从上到下，从老板到员工每一个人都会喜欢的角色，整个公司都非常器重、甚至是依赖这个技术总监。
　　这样能干的一个人，你能想到他对公司有什么潜在的危险影响么?
　　直到有一天我和这个公司的一个工程师聊天，他给我讲了这样一个故事。
　　有一次这个工程师和几个人的技术团队一起去一个重要客户那里做一个项目，在项目过程中，客户对一个产品功能非常不满，并且给他们看了其竞争对手的实现方法。这个工程师和其他团队成员都非常触动，因为平时并不是有很多机会接触到竞争对手产品的，看了才知道原来在这方面自己已经被远远的甩在后边了。
　　回来之后，整个团队都认为应该让公司总部的产品决策者知道这个情况，在相关方面必须做出改进，吸取竞争对手的长处，了解客户的喜好倾向，夺回市场。在和公司总部以及相关领导层沟通的时候，和所有公司的天性一样，产品经理在竞争对手的产品和自己的产品之间首先捍卫自己的产品优势，相对轻视客户一线现场的反馈情况——当然这个实验室和一线的协调问题是另一个话题了；在这个工程师积极上下沟通的时候，亚太区技术总监站了出来，他的立场是公司不应该改变这个产品现状，应该保持产品的灵活性，能用二次开发实现的就不用实验室去改原产品，至于客户的需求，他可以自己通过二次开发做出一个和竞争对手产品非常相似的功能。
　　事情后续的进展就很平淡了，技术总监日夜兼程，用他独一无二的、公司内基本没有第二个人掌握的软件技巧，做出了客户的需求；总部的产品经理当然也就没有再去理会这个产品改进的建议和讨论。
　　在此后，这个工程师在其他客户处还遇到过很多次对同样功能的相似需求，这些需求都是可以通过竞争对手产品的内置功能轻易实现的，但是他们却不能完全照搬他们的技术总监给之前的客户开发出来的东西，所以他们还是得在现场付出很大的人力来通过二次开发实现。
　　我询问这个工程师，当时那个技术总监为什么反对把该功能做到产品中去而坚持保持产品原有发展思路，将该客户需求通过他的英雄式的二次开发来实现呢?
　　这个工程师没有告诉我一个明确的答案，也许产品原有的开发思路有它的合理性，也许技术总监非常enjoy这种通过一个个人英雄主义的方式解决问题的状态，而他表态以后，很多他下边的工程技术人员也不好再继续反驳了。但是事实是，他和他的团队成员从此一直为了和竞争对手在该功能上对抗，打得很累很艰难。
　　而且，似乎公司里并没有人意识到这一点，他们总是觉得客户有需求?我们的英雄能解决么?如果需求很紧急，赶快去找我们的英雄!却没有人再次把从根本上解决问题的建议提上日程。
　　故事总是这样，听故事的人听的明明白白，但是故事里的人就不那么明白了。从这个故事我们能总结出一些什么理性的结论呢?
　　英雄往往是用一种“非流程化”、“非常规化”的方式解决问题，一个公司的健康运营，说到底应该依靠一个健康的流程和责任划分，而不能仅仅依靠英雄的非常规的解决问题方式。大多数把目光盯在“目标”和“结果”上的经理们。特别是一些注重业务结果而非公司运营的经理们，他们往往在解决了问题之后忽视了一个正规的流程建设。因为往往虽然问题解决了，但是我们并没有去想一想“问题是不是应该这么被解决?”，“这种解决方式是不是在将来有可复制性?”