西西河

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

共:💬161 🌺656
分页树展主题 · 全看首页 上页
/ 11
下页 末页
      • 家园 呵呵,德国银好象很喜欢搞现场模拟的

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

      • 家园 德国佬的东西吧,哎...

        我们公司用一种测试设备,性能极佳,但操作极恶心。我有一天被它恶心吐了,就问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比较熟呀?先谢过先。。。

分页树展主题 · 全看首页 上页
/ 11
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河