主题：【原创】电讯英雄传 - 二号大牛与G先生(1) -- 山而王

当年国内某项目国际招标，国内方并没有要求搭建现场模拟环境，但是德国人志在必得，自己掏钱在国内招了一彪人马，搭建了一个很漂亮的模拟环境，银子可是没有少花，我们同事看了回来说德国人的东东就是不错，性能好，那做工没的说，可是那价格也是没得商量，呵呵，结果输给东洋人了。为什么？都是台面下的事情，东西说的过去就行了，东洋人还是了解国内的办事规则。后来再类似的投标德国同志就再不来了。

我们公司用一种测试设备，性能极佳，但操作极恶心。我有一天被它恶心吐了，就问apps说你们这$%^@Q%#机器是怎么编的操作软件啊？那哥们不好意思地告诉我，硬件是在硅谷做的，软件是包给了一个德国公司。从此，德意志的软件工业给我留下了深刻的印象。

后来我给他们举了个比喻，你们给我们的机器堪称卡迪拉克，但你们的软件迫使我们倒着开！

确实不简单

其实倒不一定是二牛比公司里的那些高工水平要高到哪里去，关键的几个问题是：

1。高工虽然理论基础扎实，经验丰富。但是往往在闭门造车，并不彻底了解他们所需要解决的问题。

　　文中提到公司的需求文件不对头，很可能是有很多特殊原因的：这些文件不一定真是高工写的（很多时候高工出主意，执笔的可能是个新人，甚至说不定是个Technical Writer而已，根本不是Engineer）。把想法从大脑里影射到书面文件上本身就会丢失一些信息，比如说写文件的人为了简洁，常常假设读文件的人对讨论的话题已经有基本认识，否则写起来的时间太长，管理层也不干。但是读文件的人却不一定有直观的背景知识。就象文中所说的，写软件的人并不熟悉硬件-往往没看过硬件的有关文档，可能是找不到或者没有时间看。所以实际写那些文档的人已经在进行软件解决方案设计（Solution Design），可是做方案设计的人真地有资格设计软件吗？

　　再加上读文件的理解问题。。。这个问题也是软件外包过程中最大的问题之一。

2。高工们比较容易有思维定式（Thinking　in　silos）。由于各种各样的原因，包括政治因素，他们经常是只见树叶不见森林。特别是Lab Engineer和Field Engineer的出发点不一样。上面谈到了写文档的问题，有很多时候其实麻烦不是在写文档的人身上。如果几个高工意见不一，管理层又下了压力，写文档的Business Analyst或Technical Analyst就不得不Herd Cats，很多时候偷懒就把棘手的问题“扫到地毯下藏起来”（Sweep it under the rug）。这样的隐患必然在写软件或者用软件的过程中体现出来。

3。ATT在德国面临的问题应该似乎有管理上的问题。首先公司必须有软硬件都懂的解决方案设计师-Solution Architect。一般情况下这种设计师级别比较高，比较贵，难以长期在一个客户那里解决具体问题。所以碰到欧洲客户那样叫真的主，应该组成一个on site团组，现场了解问题，即使不能解决，至少应该明白问题出在哪里。德国的那些博士看来都不怎么了解系统的设计实施，他们应该一早就提出要求让总部派懂行的人去。。。可能是Pride的问题.

不过二牛身上最大的闪光点在于没有知难而退，这种精神是成功的必要条件。碰到复杂问题的时候分析了解问题要有耐心和解决问题的决心　-　跟打仗一样，狭路相逢勇者胜。另一方面，领导层没有放弃对项目的支持也是一个重要因素。很多时候，SOLUTION　ARCHITECT的一个重要任务就是告诉领导层，这个问题是否值得解决，还是干脆放弃。。。文中没有写这个项目的管理和决策过程，如果写出来应该是挺有意思的，应该可以做软件工程和项目管理的案例。

你知道哪个牛人对KGDB比较熟呀？先谢过先。。。