爱吱声

标题: offshore的笨蛋们 [打印本页]
作者: 老兵帅客    时间: 2012-7-26 01:18
标题: offshore的笨蛋们
本帖最后由 老兵帅客 于 2012-7-25 12:20 编辑
2 J( h5 y/ {0 V, ~$ G. y" ~2 d; H5 c8 P' `3 K# i
刚刚解决了一个performance issue，事情是这样的，我们的一个项目所使用的一个web service是由我们公司印度分公司的员工，我们称之为offshore team，完成的，这个东西在测试服务器上工作没问题，但是发布到生产机以后遇到了严重的performance issue，因为客户的访问请求居然需要六到八分钟才能完成，届时客户界面那边早就time out了。客户要求offshore team解决这个问题，他们找了半天找不到原因，没办法这件事就交给我们来解决了。
; p9 _4 e. T6 o: Q- w; ~
. O) F4 z+ g/ |* y9 W我找来代码，发现里面居然没有任何log语句，因此你无法通过log信息来发现问题出在哪里，这程序是怎么写的和测试的？没辙，咱自己来给它加上所需要的log语句吧，然后安排重新发布到生产机上去。说到这里有人可能会问，你怎么不先在测试机上测试而直接上生产机了呢，回答是这程序在测试机上没问题，而在生产机上有问题，那唯一的可能就是数据量导致的问题，因此发布到测试机没用，还是直接上生产机吧。/ s% \6 E  `, ?" r0 U4 h, `" P
- L. M! @  H4 T. G3 D" U3 y& Y
发布到生产机上，安排客户进行测试，发现问题出在了JDBC语句上，这句话用字段值来搜索所需要的记录集合，数据库表里面对应字段类型是varchar2，而我们的offshore家伙们的对应JDBC PrepareStatement语句居然是setLong，这样每个记录都需要做一次数据类型的转换，这么干数据量小的时候没事，一旦大到了一定程度，这性能能不完蛋嘛。5 S$ O# C- E- Q1 i

8 R9 a1 L$ q$ j发现了问题，解决方案也就简单了，在java程序里面预先转换好数据类型，然后把setLong改成setString，再把程序重新发布到生产机上去再测试，这回好了，从原来的需要六到八分钟减少到不到一秒钟，完事了。5 f: L, c3 n. z

' d0 a3 ^4 T, J+ poffshore team这帮家伙水平也忒次了，居然不懂得要尽可能减少数据转换次数这个基本常识，从而导致了这次的性能问题。出了问题自己还没办法解决，只好求助加拿大这边的人来帮忙，这样的out sourcing有什么实际意义呢。
作者: 机器猫    时间: 2012-7-26 02:24
我现在也成天干给offshore team擦屁股的事。
作者: MacArthur    时间: 2012-7-26 02:49
OutSourcing唯一用处就是给那些愚蠢自大的Business Leader们一个机会，来显示显示他们也“懂得IT潮流”。。。# c' m' S2 n& v8 t% d' Y1 i+ y

* N, J8 L% Q" h5 @3 z5 n仅此而已。。。 " K* c9 d! L1 }/ m+ A, t) P* l- Q6 P

9 g* z. C  F/ L. f
% u2 l) d5 G/ ^) f" s3 F6 Z) j9 p1 S, h, N3 S% v
作者: 老兵帅客    时间: 2012-7-26 03:01
MacArthur 发表于 2012-7-25 13:49 # J0 o% E0 i5 ^0 @  H
OutSourcing唯一用处就是给那些愚蠢自大的Business Leader们一个机会，来显示显示他们也“懂得IT潮流”。。 ...
, H7 q3 t$ t* ]! l4 P
他们的主要用处是在统计报表上面告诉高层，我们通过out sourcing节省了多少多少开支，现实中就算了。1 b; z+ Y: a% b9 }1 I9 k) m* y, K
- J0 `  A+ y- M. q7 [$ A4 T
我们的客户已经明确表示，在以后的项目中不再考虑offshore的人员了，原因就是他们的表现太差，仅靠本地人员来救驾，那还不如直接用本地人员算了。
作者: 老兵帅客    时间: 2012-7-26 03:02
机器猫 发表于 2012-7-25 13:24 % G# \% q2 \: F3 g  c: T- b0 J
我现在也成天干给offshore team擦屁股的事。
. P- i" ^5 g% `' ?7 I" W
嗯，同病相怜啊
作者: 明月回春    时间: 2012-7-26 08:53
其实软件这个行当不适合外包，尤其是offshore的那种。除去成本与能力之类原因，软件产品本身的质量控制没有直接的手段。因为他本身并不是有形有质的。你能对硬盘质检，但是检测硬盘中的软件代码质量，却要几乎从头到尾读一遍代码。这个成本很高，而且也依赖于检测人的自身水平。
6 B9 {, e9 h+ y2 H  C4 T& t: R! F目前的质量控制只是一种过程控制，而且注重形式。所以，有可能生产出来一堆华丽而规范的垃圾。。。
作者: 库布其    时间: 2012-7-26 09:14
成本上来说，offshore team 主打 + 本地人员擦屁股 < 本地人员全部搞定 就可以。7 d5 [/ Z$ Y0 B2 i2 Z
. i5 u8 D! J, U5 r4 ]5 e4 D
各种个案都有。我算是在中国的offshore team吧，有很好的工程师，也有差一些的工程师。总体来说比美国的差，但是搞个一年半年，抢美国工程师的饭碗没问题的。
作者: 老兵帅客    时间: 2012-7-26 10:02
明月回春 发表于 2012-7-25 19:53 8 u. z# O, N/ y) ?
其实软件这个行当不适合外包，尤其是offshore的那种。除去成本与能力之类原因，软件产品本身的质量控制没有 ...
- M8 P5 e/ R  f( z
说的很对，问题是我们的offshore team出来的东西连华丽都没有，就剩下垃圾了。3 x: z9 a1 o# C1 o+ r; g( ~3 `

3 w2 I: f6 |( x" x我们这个项目一共用了三个web service，原来打算都让那边的人来做，结果有一个半年做不出来，被我们这边的一个家伙一个礼拜搞定，还一个被我彻底重写了，就剩下现在这个貌似还行的，现在发现还是不灵啊。我今天收拾的这个有多复杂呢，实在是很简单，就是一个用JDBC写的sql select语句啊，连这都搞不定，算什么呢。
作者: 假如十八    时间: 2012-7-26 10:02
写过几次sql的半吊子路过。。。
作者: 老兵帅客    时间: 2012-7-26 10:04
库布其 发表于 2012-7-25 20:14 . p- z5 l( v. M, ]6 z$ {
成本上来说，offshore team 主打 + 本地人员擦屁股 < 本地人员全部搞定 就可以。
9 [. b2 [# R+ L* c: p4 B6 l2 ~- N' z$ p' b
各种个案都有。我算是在 ...
$ u" n# L# q, F6 o0 r
国内的软件工程师要比印度的强多了，但是问题在于两点，一个是时差问题，正好是背靠背，再一个就是语言问题，我们要求直接能电话谈工作，这个就很难了。
作者: 老兵帅客    时间: 2012-7-26 10:05
假如十八 发表于 2012-7-25 21:02
( L9 ^1 D0 r6 Z! j4 G% K( o写过几次sql的半吊子路过。。。
  k7 r( ~) K: f3 ~6 _% ^: l
数据库专家啊，崇拜。。。。。。
作者: 假如十八    时间: 2012-7-26 10:09
老兵帅客 发表于 2012-7-26 10:05 " z$ X8 F& g. g- r6 a
数据库专家啊，崇拜。。。。。。

6 C) u7 b3 ^; F/ E% c  Y4 e0 G% d7 f别逗了。。。我就会写个select。。。那种从sysobjects里面抽字段名玩来玩去的事儿我是不会干的~
作者: 四处张望    时间: 2012-7-26 10:25
假如十八 发表于 2012-7-26 10:09
, X' ^9 V$ J$ z& K( N" n. N别逗了。。。我就会写个select。。。那种从sysobjects里面抽字段名玩来玩去的事儿我是不会干的~ ...
1 \- i5 T9 @7 M$ ]3 e; y+ u
我做了十几年了，帮主说得sysobjects我都不知道是啥
作者: hotlemontea    时间: 2012-7-26 10:28
很多美国公司已经开始insource回来了吧
作者: 老兵帅客    时间: 2012-7-26 10:29
hotlemontea 发表于 2012-7-25 21:28
. |# D0 \# B" _8 Y6 H& c很多美国公司已经开始insource回来了吧

' v7 z$ Z; V9 ]- Y* A2 l美国不清楚，加拿大已经在往回收了。
作者: 草蜢    时间: 2012-7-26 12:21
Whatever happened to load test in Staging environment?
作者: 库布其    时间: 2012-7-26 12:58
老兵帅客 发表于 2012-7-26 10:04 8 v4 z$ K6 `' H6 _
国内的软件工程师要比印度的强多了，但是问题在于两点，一个是时差问题，正好是背靠背，再一个就是语言问 ...
1 X, W4 T% T& Q
时差有利有弊。& a# p+ t' N7 w& j
我就说个利吧。全球都有用户，出了事情总会有人第一时间接手开始搞，等这头该休息了，一个mail出去后面爬起来上班的继续搞。
; y& c; g9 K' X# t% g( P2 Z6 Y' s) }; |4 d; d' W8 {
语言在我们这里基本还可以，磕磕绊绊把问题搞清楚说明白，还是没问题的，基本没有只懂哑巴英语的人。。。其实哑巴英语的，赶鸭子上架几次，也就开口了。开口了，就不怕说不明白了，十几年的英语教育，还是有些作用的。
( ^8 g  t7 }9 H9 |, ~  a0 z& j# o( H" S. e) K1 K  f0 a$ z
最后的权衡，估计还是人力成本为大头。同样级别同样能力养一个美国工程师，大概在中国能养2-3个同样级别能力的。
作者: 晨池    时间: 2012-7-26 13:10
难道他们不做大量数据的测试吗？测试机上跑完了就完了，那测试也应该有Performance Testing，应该能检测到大量数据时候出问题的情况的呀，应该能预料到会有大量数据的情况下吧。这不能说Offshore team出问题。。。是Offshore testing team出问题
作者: 四处张望    时间: 2012-7-26 13:53
晨池 发表于 2012-7-26 13:10   ?7 r# K2 B  j+ U. m4 r0 I
难道他们不做大量数据的测试吗？测试机上跑完了就完了，那测试也应该有Performance Testing，应该能检测到 ...
( `6 Z, b6 E+ `
功能测试很可能做，性能测试吗，哇哈哈。
作者: 老兵帅客    时间: 2012-7-26 18:35
四处张望 发表于 2012-7-25 21:25
/ `5 P$ f) s# Y, W, q& R/ l$ z我做了十几年了，帮主说得sysobjects我都不知道是啥

; H  A4 r0 @3 J. H' O5 x俺也不知道
作者: 老兵帅客    时间: 2012-7-26 18:37
草蜢 发表于 2012-7-25 23:21 + \  D2 h% `! m: q  z3 W
Whatever happened to load test in Staging environment?
1 H/ R, t' ?/ I$ t) G! I* I
测试服务器最多只有三百万条记录，因此没事，但是到了生产机，那里有七千万条记录，就完蛋了。
作者: 老兵帅客    时间: 2012-7-26 18:40
库布其 发表于 2012-7-25 23:58
' @# g- i# {3 R7 C时差有利有弊。
( f$ n1 v9 }  P5 A% x. o. ]我就说个利吧。全球都有用户，出了事情总会有人第一时间接手开始搞，等这头该休息了，一 ...

. D* b# M! c6 x# {- Z1 ?$ g* s不是那么讲的，软件out sourcing做得最厉害的是北美，你和它背靠背了，时差就成为严重的问题。
6 L. G1 }' Q, [% ^5 L  m7 d. d# r) T% A; N  U+ R% _' G
语言问题更严重，我们这里的人来自各大洲，什么口音都有，我不相信国内的技术人能够普遍做到和这些人无困难电话沟通。
作者: mark    时间: 2012-7-26 18:45
明月回春 发表于 2012-7-26 08:53
3 I4 U8 _6 g2 b; Y- p其实软件这个行当不适合外包，尤其是offshore的那种。除去成本与能力之类原因，软件产品本身的质量控制没有 ...

/ k7 c& H( H2 `4 o0 Q! a这个倒不是，有些TEAM的水平还是很高的。一分钱一分货。上面例子的问题关键是所遇非人。
作者: 四处张望    时间: 2012-7-26 19:05
老兵帅客 发表于 2012-7-26 18:37 1 ]- x9 L% O- F. E
测试服务器最多只有三百万条记录，因此没事，但是到了生产机，那里有七千万条记录，就完蛋了。 ...
0 U  Q+ z& v9 b8 v5 J( |( Z: u& U2 y6 B- j
7千万就挺利害了，一般性能测试不会用那么大数据量。
作者: 晨池    时间: 2012-7-26 19:07
四处张望 发表于 2012-7-26 13:53 : u6 b5 b' h1 s8 e$ @
功能测试很可能做，性能测试吗，哇哈哈。

$ E, t8 @3 h5 _+ Q  W这样作为服务器上跑的程序，还是要跑性能测试吧，客户端的不跑也就算了，服务器端的程序不跑一下，多不放心啊。我还是选择认为他们做了性能测试但是不知道为啥，忘记了测这一个地方吧2 N; S+ s' o" k$ f
作者: 老兵帅客    时间: 2012-7-26 19:13
四处张望 发表于 2012-7-26 06:05
$ a/ Z& p' H: X; d% Y2 z7千万就挺利害了，一般性能测试不会用那么大数据量。
9 a4 z6 y) s  g0 W* ^; A$ c
是啊，所以出问题了呢。关键在于，数据库的那个字段是varchar2，程序里面为什么要用long呢，应该是string才对啊。
作者: 四处张望    时间: 2012-7-26 19:45
老兵帅客 发表于 2012-7-26 19:13 ( L9 C& x7 ]& h, V. I
是啊，所以出问题了呢。关键在于，数据库的那个字段是varchar2，程序里面为什么要用long呢，应该是string ...
  h7 ~" L% |9 t, r& T. }. \+ l: |: J5 F
其实我会猜他们原来是想用long类型，但是数据库设计那里或者搞错了，或者看错了。
作者: 四处张望    时间: 2012-7-26 19:48
晨池 发表于 2012-7-26 19:07
) ]1 H! D$ s% k6 n8 \3 T这样作为服务器上跑的程序，还是要跑性能测试吧，客户端的不跑也就算了，服务器端的程序不跑一下，多不放 ...

: Y1 ~: h6 m5 d2 b7 R; R主要问题是性能的问题并不是随便测测就能测出来的，老兵这个例子是上了7千万，我是很少见到哪里性能测试会拿这个折腾自己的。他们拿百万级别的数据测了性能，也算交货了。
作者: 晨池    时间: 2012-7-26 20:08
四处张望 发表于 2012-7-26 19:48
  J+ B- C: E+ S* l* w' u主要问题是性能的问题并不是随便测测就能测出来的，老兵这个例子是上了7千万，我是很少见到哪里性能测试 ...

; w* i: V  R6 _- ~1 I是啊，我也是后来才看到这个贴的，跑了三百万的确实也够意思了。这个里面也只能说良好的编程习惯太重要了
作者: 老兵帅客    时间: 2012-7-26 20:46
四处张望 发表于 2012-7-26 06:45 - Z, y3 ^  p9 }; P; F
其实我会猜他们原来是想用long类型，但是数据库设计那里或者搞错了，或者看错了。 ...
* e; i' E; i3 F$ N* w5 _6 u6 r$ z
这个我问过了，数据库那里一直就是varchar2，那就不应该在java这边使用long，因此这个错误纯属程序员做事不仔细，没考虑数据类型转换的成本。
作者: 老兵帅客    时间: 2012-7-26 20:47
四处张望 发表于 2012-7-26 06:48
/ P- t! C" c5 e- q4 X主要问题是性能的问题并不是随便测测就能测出来的，老兵这个例子是上了7千万，我是很少见到哪里性能测试 ...

- v! e3 D5 P8 B1 D我觉得这个问题其实是code review那边出了问题，否则不应该看不出来数据类型不匹配的问题来的。
作者: 老兵帅客    时间: 2012-7-26 20:48
晨池 发表于 2012-7-26 07:08 8 Q6 m; K0 e; ]7 ]
是啊，我也是后来才看到这个贴的，跑了三百万的确实也够意思了。这个里面也只能说良好的编程习惯太重要了 ...
5 H0 I  `8 b! N$ l  k& L- K
对，规范的编程习惯很重要的。
作者: 四处张望    时间: 2012-7-27 10:57
老兵帅客 发表于 2012-7-26 20:47
8 s7 V6 K) l6 F9 M/ V, Z4 H" @" ^- }我觉得这个问题其实是code review那边出了问题，否则不应该看不出来数据类型不匹配的问题来的。 ...

: Q) e$ V6 O6 c+ \( E6 X0 }这里出问题我倒觉得不算太奇怪，问题是为何找不出问题.
作者: 老兵帅客    时间: 2012-7-27 11:10
四处张望 发表于 2012-7-26 21:57 + y% X9 Z' P1 k! z
这里出问题我倒觉得不算太奇怪，问题是为何找不出问题.

* f! v  w, [+ T( R不奇怪，连做个如此简单的web service都如此吃力，哪里还有能力做深层次分析。
作者: 空气精灵    时间: 2012-7-27 11:51
老兵帅客 发表于 2012-7-26 18:40
/ t2 y  c/ s: [- B. N9 t; `不是那么讲的，软件out sourcing做得最厉害的是北美，你和它背靠背了，时差就成为严重的问题。
7 [& s$ e: n" j" u7 @- l/ V3 H/ e! {% q1 t% V) p9 \( H7 S) z- H1 [
语言问题 ...
5 p) f( X% ~& w7 m6 i, }6 u
国内这样的人是有的，只是人家就不做outsourcing了。
作者: 空气精灵    时间: 2012-7-27 11:52
老兵帅客 发表于 2012-7-26 19:13 $ ~9 E) c# p. F  u# t% D
是啊，所以出问题了呢。关键在于，数据库的那个字段是varchar2，程序里面为什么要用long呢，应该是string ...
6 @6 g) D/ i9 Z) ^/ L
这个实在不可思议，程序里的数据类型参照DB里的设，这是非常非常非常基本的啊。除非是曾有人改过数据库结构。
作者: 四处张望    时间: 2012-7-27 12:03
空气精灵 发表于 2012-7-27 11:52
; v# x( g0 f+ H( u9 h' k  ]) H这个实在不可思议，程序里的数据类型参照DB里的设，这是非常非常非常基本的啊。除非是曾有人改过数据库结 ...

% u: f5 z& c4 r3 H我真见过不管的，因为功能上的确可以跑。
作者: 我是人间惆怅客    时间: 2012-7-27 14:32
老兵帅客 发表于 2012-7-26 18:35
+ u+ M1 n4 k5 d/ }2 k俺也不知道
( ~" t7 Q" i8 V. L4 ~' @, B6 P
sysobjects 是 sql server 里的系统表，记录的是 用户表、视图等对象的定义数据。
作者: 老兵帅客    时间: 2012-7-27 16:25
空气精灵 发表于 2012-7-26 22:52
! A" v# _' l2 |0 p: i这个实在不可思议，程序里的数据类型参照DB里的设，这是非常非常非常基本的啊。除非是曾有人改过数据库结 ...
& x$ k, K  V- }
数据库没改过，神奇吧。
作者: 老兵帅客    时间: 2012-7-27 16:25
我是人间惆怅客 发表于 2012-7-27 01:32
. h( r. U6 B6 ]8 Y6 T) Nsysobjects 是 sql server 里的系统表，记录的是 用户表、视图等对象的定义数据。 ...

2 l; W( M. @8 \- k* f, H俺们这里不用sql server，用oracle
作者: 老兵帅客    时间: 2012-7-27 16:25
四处张望 发表于 2012-7-26 23:03
7 ]4 H- M) p1 |9 r# S; e4 o. w我真见过不管的，因为功能上的确可以跑。

  N- d# X$ J2 [8 T是可以跑，就是性能会成问题。
作者: 我是人间惆怅客    时间: 2012-7-27 23:24
老兵帅客 发表于 2012-7-27 16:25 : @) q" K4 ^& y0 O- G# ~) i
俺们这里不用sql server，用oracle
: _( `3 ]' ^2 }. b
hah ，俺们只会 sql server。
作者: 坚持到底    时间: 2012-7-28 21:57
这个有点太没有技术含量了。
作者: nimenkanne    时间: 2012-8-10 09:12
offsource不能多用，其实应该把费时费人工 但是不核心的东西offsource
; |$ U+ d5 G3 J8 d全部都offsource估计是不行
作者: profer    时间: 2012-8-10 13:55
本帖最后由 profer 于 2012-8-10 13:57 编辑
" N% V7 Q3 b3 O! i9 J' V) [9 n2 l" \" |7 C  k8 |+ C5 {- G" p& E) K
读书还是刷盘子？假如有两个机会，一个是外包做数据库应用30w,一个是去淘宝做数据库调优15w，你会选哪个？以前一个同事选择了后者，三年后到某银行拿100w了。3 f7 J& [2 p2 d0 n5 b* ]
现在猎头打电话，要是外包的岗，我都是直接要求翻三倍。有个孩子要求两倍，上个月刚去报到了。
3 f# U6 C% ?& p2 f, ?, G5 j古语说：家财万贯不如一计压身。多给几毛钱把一些粗笨的体力活转移到劳动成本低廉国家的路子注定是行不通的，最多成为年轻人进入这个行业的跳板，人有自强之心，特别是像这中国这种处处要争第一的国家。
作者: 老兵帅客    时间: 2012-8-10 18:07
nimenkanne 发表于 2012-8-9 20:12
: y1 g- M* z7 s$ _offsource不能多用，其实应该把费时费人工 但是不核心的东西offsource
2 E) F: `; a$ d7 v% J: q* n全部都offsource估计是不行 ...
( \; w8 u, d+ i7 O  t( K) F
这里的关键是outsourcing的工钱给多少，很多忒克扣了，能招来的人水平不可能好；可是如果给好了的话，那还有利可图嘛，这是个矛盾。
作者: 老兵帅客    时间: 2012-8-10 18:09
profer 发表于 2012-8-10 00:55   J6 G- H2 Y$ K, W. |$ z
读书还是刷盘子？假如有两个机会，一个是外包做数据库应用30w,一个是去淘宝做数据库调优15w，你会选哪个？ ...

! m# {3 ?. Z# d; f' t9 ^8 s中国的软件outsourcing实际上很少的，主要是语言不行，就剩下coding这段，那机会就很少了。
作者: 小木    时间: 2012-8-12 02:28
咦，为啥程序里只用得到long然后数据库里非要是varchar?: F" W8 T" X  S7 d7 P# A# p
我觉得数据库设计一开始就错掉了啊。。。。
作者: 老兵帅客    时间: 2012-8-12 03:25
小木 发表于 2012-8-11 13:28 : U2 q4 ], J2 v, ~$ ]
咦，为啥程序里只用得到long然后数据库里非要是varchar?
: D, E5 _% {4 m! f' _) Z我觉得数据库设计一开始就错掉了啊。。。。 ...
/ X* `2 X0 ?. s9 Z' I6 g
数据库没错，错的是程序，这才出的问题。
作者: nimenkanne    时间: 2012-8-12 16:10
老兵帅客 发表于 2012-8-10 18:07 ' h5 e: ~& |& \3 a/ z
这里的关键是outsourcing的工钱给多少，很多忒克扣了，能招来的人水平不可能好；可是如果给好了的话，那 ...

, b# }& L6 C6 X9 u% C6 J0 D% F  C* [
您说的很对
, J2 R" L8 C* z& |  D8 }+ C% Y4 f从管理成本角度说，我觉得大约是50%的工资比较好。
- X: H+ w9 O% `* {& T用数据说：比如美国工程师1年是40~60万人民币吧，那中国的给到20~40万基本可以满足需求了。; _3 I5 p! p$ `( m
20~40万，即使是在北上广，也是可以招到很不错的工程师了。, \$ p' t+ ~( F3 v4 K
4 ~. z/ m$ `- @$ M" X7 D3 y
至于有利可图：50%的成本+ 节省的管理成本，裁员的人力成本等等  还是有利可图的
$ \9 b0 Z+ [1 V
作者: 老兵帅客    时间: 2012-8-12 23:18
nimenkanne 发表于 2012-8-12 03:10 % z9 w' m, F6 ~7 x. u( h; S) Q9 V
您说的很对+ P" o2 L7 T; C5 N7 B0 J, K0 Z
从管理成本角度说，我觉得大约是50%的工资比较好。, |5 }' S: G# |# Z$ s% E/ }
用数据说：比如美国工程师1年是40~60万人 ...
" [0 U9 y; ?4 s7 b
想什么好事呢，你只计算工资成本，却不计算通讯和语言成本，要知道后面那两个加起来有时候不比工资成本低多少。举个例子，我们这里经常要和客户直接谈东西，于是outlook上约个时间，找个会议室直接开会，散会就可以干活了。如果这件事要和国内的人合作，先不说语言上的问题，国内和北美是背靠背，因此除非国内用北美时间上下班，否则只能够用电子邮件，一个来回走一天，国内的人工成本立刻就上去了，原本便宜一半也就变成和这边一样的成本，甚至更高，那还图个什么？
+ q. N, h* x( B; Y4 N! {9 z# D0 s% \1 ]" r! m9 e/ C  t+ ]
事实上，应用软件开发里面，能够整个打包不需要中间再和客户接触的情况很少，很多时候是和客户一起干活，也就是一边商量一边干，有关文档经常在变。这就是为什么国内很多这类企业都做日本、韩国的生意，原因是没有时差问题，时差成本下来了，否则没戏。
/ o9 j( n: W. o2 E$ ^% S0 R
1 D2 `) N  D7 x0 V$ j' g* B不要说和中国，中国国内的技术人员很多语言根本达不到这边的要求，也就是直接电话讨论问题，因为口音问题和电话线路的噪音问题，就是印度那边英语普遍比较好，时差问题也比较小的情况，时差所造成的成本上升也是很严重的问题。
- @4 @$ w* w7 P# [+ I
! G, g  X, [) R6 h5 P) e" v& i你所说的情况，只在一种情况下成立，那就是比较专业的技术性程序，不需要和客户有很多的接触，直接打包拿走。可是这种情况往往涉及专利问题，以国内的无法无天，法律经常成为闹剧的局面，怎么解决？
作者: nimenkanne    时间: 2012-8-13 06:23
老兵帅客 发表于 2012-8-12 23:18 ; O: H2 r  Q$ F$ @% N# O1 ]- T
想什么好事呢，你只计算工资成本，却不计算通讯和语言成本，要知道后面那两个加起来有时候不比工资成本低 ...
1 v4 N6 \/ `3 ~& V" o" p! z1 G
就我知道的中国的不少外企，就是offshore模式。通讯模式也可以解决，乙方加班呗。晚上8~10点加班，所有讨论在这个时段进行。6 d+ F: x1 \" |( g( w6 U
至于您说的外语问题，有。不过年薪给到了20~35万，外语一般还是可以交流的。或者管事的负责做交流。哪怕是一个团队找一个外语好的懂点技术的专门做接口人呢？这点成本和节省下来的成本比，是有限的
8 B0 Z* R1 ]2 p! G% ^8 R- {- Y
/ k4 p6 d" {- E5 \. M  p另外我想说：印度人的外语确实很好，不过他们的习惯是有的没的说一大堆，也许已经是增加了沟通成本。
  B" @; J5 Y6 J- j1 E7 g& V
+ P% y: f9 J' [0 p% w您在关注开发的同时，忽略了一个小问题：软件不是只有新feature的开发的。还包括很多的维护/测试工作。这一些offshore就非常合适了。
作者: 我爱莫扎特    时间: 2012-8-13 06:54
你们这个算小CASE啦。RBS把核心数据库外包给印度做，一个小伙子按错一个键，整个大银行瘫痪了两周多呢！
作者: 老兵帅客    时间: 2012-8-13 07:09
我爱莫扎特 发表于 2012-8-12 17:54
2 }2 L: n. b* J) d' M. c, ?* |你们这个算小CASE啦。RBS把核心数据库外包给印度做，一个小伙子按错一个键，整个大银行瘫痪了两周多呢！ ...

, e. U" z5 K& k所以北美在往回收呢，就是因为看到了这些成本问题
作者: 老兵帅客    时间: 2012-8-13 07:19
nimenkanne 发表于 2012-8-12 17:23
* @* G7 Q( X! L' a8 z+ u就我知道的中国的不少外企，就是offshore模式。通讯模式也可以解决，乙方加班呗。晚上8~10点加班，所有讨 ...

0 ~- s  u; f3 T! J1 F; i2 W
# ^, a6 N" l$ y9 _; Q+ G: h时差问题的唯一解决办法就是国内夜里上班，用北美的工作时间，否则没戏。" f; n9 m1 ~' G' D

* h1 l, u$ d4 F我理解你所说的晚上八到十点加班，那个只能是两边的技术团队开会，跟客户没戏，人家才没兴趣跟你凑时间呢。人家出钱的，想什么时候就是什么时候，怎么都是有理。我们在这边的，见了客户永远都会变成yes man，围着客户转的，哪里敢要求客户如何如何。
4 F1 P+ Y6 r9 }9 S: |' E, ]$ e4 d. I5 ?: h( w" m0 j
语言问题在于，技术好的一般英语都不太好，倒过来也一样，原因就是时间投入的分配。管事的负责作交流是不可能的，因为开会的时候要直接人对人谈话，还有很多的业务和技术讨论，你要加进去多少语言好的呢，他们懂得业务和技术嘛，那样成本也就上去喽。其实这也就是为什么做软件外包印度比中国强，不是印度技术多好，而是时差和语言问题比较好办一些。  \% a- J. I! x0 y; v3 t

* k0 }; d" l6 e0 y- _) `6 ~" \别处不清楚，我这里测试QA一类是绝不外包的，因此唯一合适的就剩下technical support了。
作者: nimenkanne    时间: 2012-8-13 19:15
老兵帅客 发表于 2012-8-13 07:19
+ _& N) ^# H8 ~% @  F) B时差问题的唯一解决办法就是国内夜里上班，用北美的工作时间，否则没戏。
, ]8 ^+ \# y# r3 P% t8 v
% L4 G. Q3 ]# G: x  G我理解你所说的晚上八到十点加 ...

7 R* A) K7 |( O# K7 B& S我知道您说的意思了  p9 B' f) [, X: \2 F
如果是直接面对客户的，那没戏。8 B" }. B/ d& d( y! u/ ^# |
但是一般大公司都有专门做需求的，那是本地的。然后需求明确后 就可以找offshore了$ }8 `; I+ h& ]6 Q( Q
大公司由于层级复杂，每个职务都有明确的专人负责。所以可以沿用offshore的模式。7 e9 B% W& F$ i1 H
5 i3 H. ]' `& Z' ~: Q
但是据我观察，大公司的做法不是完全包给其他的公司，而是自己独资在中国开设研发基地。说白了，目的就是外包。但是这样操作起来风险小一点。
作者: 老兵帅客    时间: 2012-8-13 20:45
本帖最后由 老兵帅客 于 2012-8-13 11:43 编辑 2 q' e6 A! W3 C* G
nimenkanne 发表于 2012-8-13 06:15
" R; k) o5 _* k, j我知道您说的意思了4 x8 |( E- o3 Y8 u( j* @+ I
如果是直接面对客户的，那没戏。) F3 s7 d1 T1 z) G" N% ]1 I
但是一般大公司都有专门做需求的，那是本地的。然后 ...
3 G+ W) \+ K( Y6 }6 m" }

3 S' }& `8 w0 k4 G! \问题就在于需求总是在变，因此BA、SA的文档也总是要跟着变，经常会出现事情很急，于是技术人员先干着，相应的文档跟着更新的倒过来局面。4 e2 A0 J/ Q& y% P7 h. {
. T6 j0 h2 e) p  {' ]
至于你所说的大公司每个职务都有明确的专人负责，没错，但是哪里的人都是人，都有下级服从上级，为业务部门服务的需要，于是明确而稳定的流程经常成为具文，应急对付的事情层出不穷。! w$ M/ o' V% @" P) c

( |7 v9 y4 ]) A. Z* ^" X在中国设立研发基地的一般都是技术性公司，其它类型的还是外包居多。
作者: nimenkanne    时间: 2012-8-14 08:25
老兵帅客 发表于 2012-8-13 20:45
2 m& N* p% m$ R问题就在于需求总是在变，因此BA、SA的文档也总是要跟着变，经常会出现事情很急，于是技术人员先干着，相 ...

0 I0 G$ N. V/ X# S- o8 k: ]! h应急是有的。这在软件研发中是不可避免的
. Z- r* D3 G# J) g5 K, ]不过我看到很多的外包都是做的是原有功能的维护，需求的变化在这一点上影响不大。
$ L/ U, |( x) b% H) `
作者: 老兵帅客    时间: 2012-8-14 08:48
nimenkanne 发表于 2012-8-13 19:25 5 |# s' z. A" x& L
应急是有的。这在软件研发中是不可避免的
: d+ M6 m8 v5 A4 ]2 q不过我看到很多的外包都是做的是原有功能的维护，需求的变化在 ...
% ^! f6 G0 E( y. l1 E
这点倒是很对，不过这种外包也就拿不到多少钱了。
作者: nimenkanne    时间: 2012-8-14 08:53
老兵帅客 发表于 2012-8-14 08:48 6 ?4 ^7 {7 R$ J, \
这点倒是很对，不过这种外包也就拿不到多少钱了。
3 w( C+ R3 W% m0 U9 \7 k/ d* ^
大概是50%的原来国家的成本吧' u: [; Y2 m. O7 t. D' f
我在了2家公司都是这样
作者: castigliano    时间: 2012-8-16 16:18
听说微软中国不少中层是把外包公司当成灰色收入来源的。。。
作者: 老兵帅客    时间: 2012-8-16 18:18
castigliano 发表于 2012-8-16 03:18 - I  ?7 m+ D( ?: R: ^
听说微软中国不少中层是把外包公司当成灰色收入来源的。。。
+ {2 _9 A, ]! n& `& S1 }
这个就不了解了。



欢迎光临 爱吱声 (http://129.226.69.186/bbs/) Powered by Discuz! X3.2