设为首页收藏本站

爱吱声

 找回密码
 注册
搜索
楼主: 老兵帅客
打印 上一主题 下一主题

[信息技术] offshore的笨蛋们

[复制链接]
  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    41#
     楼主| 发表于 2012-7-27 16:25:57 | 只看该作者
    四处张望 发表于 2012-7-26 23:03
    2 q/ e/ d9 l2 z; D, g( e% w5 s# m- @/ W我真见过不管的,因为功能上的确可以跑。

    7 N# Y3 |) b! e9 c" X9 u是可以跑,就是性能会成问题。

    该用户从未签到

    42#
    发表于 2012-7-27 23:24:59 | 只看该作者
    老兵帅客 发表于 2012-7-27 16:25
    - L' s. Y/ e' N& @& N/ s: r' |俺们这里不用sql server,用oracle

    * h8 @/ A" x$ N5 N! [, ^hah ,俺们只会 sql server。
  • TA的每日心情
    擦汗
    2019-7-2 00:12
  • 签到天数: 809 天

    [LV.10]大乘

    43#
    发表于 2012-7-28 21:57:25 | 只看该作者
    这个有点太没有技术含量了。

    该用户从未签到

    44#
    发表于 2012-8-10 09:12:00 | 只看该作者
    offsource不能多用,其实应该把费时费人工 但是不核心的东西offsource
    : w" r3 Z& q# I( M- T3 e$ _5 P; J全部都offsource估计是不行
  • TA的每日心情
    奋斗
    2018-1-6 00:24
  • 签到天数: 1 天

    [LV.1]炼气

    45#
    发表于 2012-8-10 13:55:35 | 只看该作者
    本帖最后由 profer 于 2012-8-10 13:57 编辑 & }* C6 j  ]" J* k3 {* P6 E  @. {

    4 _, J7 u$ B. J, o, O- p读书还是刷盘子?假如有两个机会,一个是外包做数据库应用30w,一个是去淘宝做数据库调优15w,你会选哪个?以前一个同事选择了后者,三年后到某银行拿100w了。: r, V8 e/ z4 ]3 Q6 |
    现在猎头打电话,要是外包的岗,我都是直接要求翻三倍。有个孩子要求两倍,上个月刚去报到了。
    : y8 E  f! k% \古语说:家财万贯不如一计压身。多给几毛钱把一些粗笨的体力活转移到劳动成本低廉国家的路子注定是行不通的,最多成为年轻人进入这个行业的跳板,人有自强之心,特别是像这中国这种处处要争第一的国家。
  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    46#
     楼主| 发表于 2012-8-10 18:07:43 | 只看该作者
    nimenkanne 发表于 2012-8-9 20:12 ! P% C( H- [4 V7 W: _* D3 n
    offsource不能多用,其实应该把费时费人工 但是不核心的东西offsource
    4 \8 t: c- x' K0 A' p* T( n, ^, A3 m全部都offsource估计是不行 ...

    : U6 h/ @/ O" P6 V; M4 b) b这里的关键是outsourcing的工钱给多少,很多忒克扣了,能招来的人水平不可能好;可是如果给好了的话,那还有利可图嘛,这是个矛盾。
  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    47#
     楼主| 发表于 2012-8-10 18:09:11 | 只看该作者
    profer 发表于 2012-8-10 00:55 ( \& |: Z3 i+ `- l" Q0 ?5 o5 f! J
    读书还是刷盘子?假如有两个机会,一个是外包做数据库应用30w,一个是去淘宝做数据库调优15w,你会选哪个? ...
      \1 S8 M1 m" Z3 Q+ U& h1 ~- R
    中国的软件outsourcing实际上很少的,主要是语言不行,就剩下coding这段,那机会就很少了。

    该用户从未签到

    48#
    发表于 2012-8-12 02:28:18 | 只看该作者
    咦,为啥程序里只用得到long然后数据库里非要是varchar?6 ~3 x3 N' x. Z
    我觉得数据库设计一开始就错掉了啊。。。。
  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    49#
     楼主| 发表于 2012-8-12 03:25:04 | 只看该作者
    小木 发表于 2012-8-11 13:28   G( N0 D( N) x0 _; i3 v
    咦,为啥程序里只用得到long然后数据库里非要是varchar?; k9 ^2 {; E9 o& E
    我觉得数据库设计一开始就错掉了啊。。。。 ...

    2 F0 X# i( M" M- i5 [; t; m7 _数据库没错,错的是程序,这才出的问题。

    该用户从未签到

    50#
    发表于 2012-8-12 16:10:14 | 只看该作者
    老兵帅客 发表于 2012-8-10 18:07
    3 H4 s, y6 M) @( E2 E- V' [0 g) X这里的关键是outsourcing的工钱给多少,很多忒克扣了,能招来的人水平不可能好;可是如果给好了的话,那 ...
    1 ]/ H) i1 ~- h7 o; O9 |
    ' T# e/ y; Y+ D) @
    您说的很对- ?9 R& [9 q4 n; x
    从管理成本角度说,我觉得大约是50%的工资比较好。
    / e& i) u( j; B$ N用数据说:比如美国工程师1年是40~60万人民币吧,那中国的给到20~40万基本可以满足需求了。; u  _0 N, k1 ?' _! |* J
    20~40万,即使是在北上广,也是可以招到很不错的工程师了。% P0 x) J4 h+ T- V2 `) R6 H1 C
    1 Z- m9 F& P6 E- q$ j3 ]- w  Y. ?
    至于有利可图:50%的成本+ 节省的管理成本,裁员的人力成本等等  还是有利可图的, D# _9 R9 j- p  B6 x9 q  L- E' Z3 J
  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    51#
     楼主| 发表于 2012-8-12 23:18:21 | 只看该作者
    nimenkanne 发表于 2012-8-12 03:10
    ( C( M1 v2 p$ i您说的很对
    ! p8 k2 _0 t1 a; _7 T# W从管理成本角度说,我觉得大约是50%的工资比较好。5 p+ G( W3 K3 r+ P6 T- z+ L: C5 t) u  e
    用数据说:比如美国工程师1年是40~60万人 ...
    , |- Q" c$ g. X) e
    想什么好事呢,你只计算工资成本,却不计算通讯和语言成本,要知道后面那两个加起来有时候不比工资成本低多少。举个例子,我们这里经常要和客户直接谈东西,于是outlook上约个时间,找个会议室直接开会,散会就可以干活了。如果这件事要和国内的人合作,先不说语言上的问题,国内和北美是背靠背,因此除非国内用北美时间上下班,否则只能够用电子邮件,一个来回走一天,国内的人工成本立刻就上去了,原本便宜一半也就变成和这边一样的成本,甚至更高,那还图个什么?
    & I* t* Q! M' C, O2 _1 N* _: @0 p9 Q6 e% T
    事实上,应用软件开发里面,能够整个打包不需要中间再和客户接触的情况很少,很多时候是和客户一起干活,也就是一边商量一边干,有关文档经常在变。这就是为什么国内很多这类企业都做日本、韩国的生意,原因是没有时差问题,时差成本下来了,否则没戏。6 d% w: S# G3 b) o9 H2 G
    . C$ c8 ?% K9 N+ |" n/ F2 w
    不要说和中国,中国国内的技术人员很多语言根本达不到这边的要求,也就是直接电话讨论问题,因为口音问题和电话线路的噪音问题,就是印度那边英语普遍比较好,时差问题也比较小的情况,时差所造成的成本上升也是很严重的问题。* T1 ]# D: v: W& ~
    6 a9 b& q* H; \2 L3 N
    你所说的情况,只在一种情况下成立,那就是比较专业的技术性程序,不需要和客户有很多的接触,直接打包拿走。可是这种情况往往涉及专利问题,以国内的无法无天,法律经常成为闹剧的局面,怎么解决?

    该用户从未签到

    52#
    发表于 2012-8-13 06:23:36 | 只看该作者
    老兵帅客 发表于 2012-8-12 23:18
    6 h/ P4 ]5 G# l* ?* F% j想什么好事呢,你只计算工资成本,却不计算通讯和语言成本,要知道后面那两个加起来有时候不比工资成本低 ...

    0 F# R/ @2 q6 U1 I! g就我知道的中国的不少外企,就是offshore模式。通讯模式也可以解决,乙方加班呗。晚上8~10点加班,所有讨论在这个时段进行。. S* A0 A( c0 F/ [4 H& u# F
    至于您说的外语问题,有。不过年薪给到了20~35万,外语一般还是可以交流的。或者管事的负责做交流。哪怕是一个团队找一个外语好的懂点技术的专门做接口人呢?这点成本和节省下来的成本比,是有限的
    8 j: m$ z% @7 @5 O. G% u% f8 U6 m/ \+ M1 T& n
    另外我想说:印度人的外语确实很好,不过他们的习惯是有的没的说一大堆,也许已经是增加了沟通成本。
    0 Q1 F; l( D. A" |9 }% c! y% a" Q% ^4 X* @! u
    您在关注开发的同时,忽略了一个小问题:软件不是只有新feature的开发的。还包括很多的维护/测试工作。这一些offshore就非常合适了。

    该用户从未签到

    53#
    发表于 2012-8-13 06:54:13 | 只看该作者
    你们这个算小CASE啦。RBS把核心数据库外包给印度做,一个小伙子按错一个键,整个大银行瘫痪了两周多呢!
  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    54#
     楼主| 发表于 2012-8-13 07:09:15 | 只看该作者
    我爱莫扎特 发表于 2012-8-12 17:54
      \; T) E) l! R6 u你们这个算小CASE啦。RBS把核心数据库外包给印度做,一个小伙子按错一个键,整个大银行瘫痪了两周多呢! ...

    : M$ X9 a# V2 O6 Z- y& A所以北美在往回收呢,就是因为看到了这些成本问题
  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    55#
     楼主| 发表于 2012-8-13 07:19:20 | 只看该作者
    nimenkanne 发表于 2012-8-12 17:23
    ; v8 k( \2 f! K6 v0 ]就我知道的中国的不少外企,就是offshore模式。通讯模式也可以解决,乙方加班呗。晚上8~10点加班,所有讨 ...
    ! M2 }' {9 {6 z4 S" f5 R
    $ t, l2 K. I8 u! T/ g& y
    时差问题的唯一解决办法就是国内夜里上班,用北美的工作时间,否则没戏。! V6 ?, P( ?+ A" G4 L2 f

      r% h8 F9 X! F! p. x  g& d我理解你所说的晚上八到十点加班,那个只能是两边的技术团队开会,跟客户没戏,人家才没兴趣跟你凑时间呢。人家出钱的,想什么时候就是什么时候,怎么都是有理。我们在这边的,见了客户永远都会变成yes man,围着客户转的,哪里敢要求客户如何如何。, [* U9 k1 V; x

    2 r3 {- a1 ^, V: r0 j. d语言问题在于,技术好的一般英语都不太好,倒过来也一样,原因就是时间投入的分配。管事的负责作交流是不可能的,因为开会的时候要直接人对人谈话,还有很多的业务和技术讨论,你要加进去多少语言好的呢,他们懂得业务和技术嘛,那样成本也就上去喽。其实这也就是为什么做软件外包印度比中国强,不是印度技术多好,而是时差和语言问题比较好办一些。
    0 X' f; @4 U' L- z5 Q
    . Q  n: H/ ~7 X( y别处不清楚,我这里测试QA一类是绝不外包的,因此唯一合适的就剩下technical support了。

    该用户从未签到

    56#
    发表于 2012-8-13 19:15:25 | 只看该作者
    老兵帅客 发表于 2012-8-13 07:19
    8 |8 f; E! N- v; T1 q5 @时差问题的唯一解决办法就是国内夜里上班,用北美的工作时间,否则没戏。
    ; \* [5 o# B+ R3 L, k% f& S1 n* a: c
    我理解你所说的晚上八到十点加 ...
    6 R; L# j9 n' U( `
    我知道您说的意思了1 ^/ Z" m' _7 J  k
    如果是直接面对客户的,那没戏。
    & S+ v2 \+ X7 C% _2 C% p4 g但是一般大公司都有专门做需求的,那是本地的。然后需求明确后 就可以找offshore了# s9 q7 D5 H6 Q8 M2 W2 e( Z
    大公司由于层级复杂,每个职务都有明确的专人负责。所以可以沿用offshore的模式。
    4 L- j- I, M+ W" W; b; X) G, g5 H8 V& Z* G, }1 Z1 w2 C* I9 q
    但是据我观察,大公司的做法不是完全包给其他的公司,而是自己独资在中国开设研发基地。说白了,目的就是外包。但是这样操作起来风险小一点。
  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    57#
     楼主| 发表于 2012-8-13 20:45:38 | 只看该作者
    本帖最后由 老兵帅客 于 2012-8-13 11:43 编辑 3 h' W( j* I, W% a* X9 f
    nimenkanne 发表于 2012-8-13 06:15 ; M( m! W2 {$ G, J
    我知道您说的意思了8 r! ^. |: _. o. B3 l8 i
    如果是直接面对客户的,那没戏。
    % q4 p2 l/ \6 I" J' y; R1 u3 z2 s但是一般大公司都有专门做需求的,那是本地的。然后 ...

    ) P1 m2 q( \8 A) ~; p6 d# n( t. X8 Q( g
    问题就在于需求总是在变,因此BA、SA的文档也总是要跟着变,经常会出现事情很急,于是技术人员先干着,相应的文档跟着更新的倒过来局面。
    ; m7 F" |% S( J( ^6 @) K+ M' y5 [8 ^
    至于你所说的大公司每个职务都有明确的专人负责,没错,但是哪里的人都是人,都有下级服从上级,为业务部门服务的需要,于是明确而稳定的流程经常成为具文,应急对付的事情层出不穷。  X" e1 R7 T. ]. z9 s6 N' y
    ) K& C! H7 G, k7 _1 l0 K+ w3 @
    在中国设立研发基地的一般都是技术性公司,其它类型的还是外包居多。

    该用户从未签到

    58#
    发表于 2012-8-14 08:25:52 | 只看该作者
    老兵帅客 发表于 2012-8-13 20:45
    4 K, D/ p& o; V问题就在于需求总是在变,因此BA、SA的文档也总是要跟着变,经常会出现事情很急,于是技术人员先干着,相 ...

    $ K& H4 p7 B5 g9 i5 D: I应急是有的。这在软件研发中是不可避免的8 d) E" `0 I8 z2 d8 r5 Z) m
    不过我看到很多的外包都是做的是原有功能的维护,需求的变化在这一点上影响不大。/ b; O3 ?, O. g& r  q
  • TA的每日心情
    开心
    2023-1-5 00:48
  • 签到天数: 2591 天

    [LV.Master]无

    59#
     楼主| 发表于 2012-8-14 08:48:29 | 只看该作者
    nimenkanne 发表于 2012-8-13 19:25
    8 T4 ^# B* _$ w1 U0 H7 M+ B应急是有的。这在软件研发中是不可避免的
    ; C% I( d% o8 q" _* r' }) z/ M不过我看到很多的外包都是做的是原有功能的维护,需求的变化在 ...

      N! O8 m% `! v  q' `- t这点倒是很对,不过这种外包也就拿不到多少钱了。

    该用户从未签到

    60#
    发表于 2012-8-14 08:53:59 | 只看该作者
    老兵帅客 发表于 2012-8-14 08:48 2 X0 V4 U, |, l7 ]5 y/ t
    这点倒是很对,不过这种外包也就拿不到多少钱了。
    + d# r1 @. w8 V7 P( _/ `" p
    大概是50%的原来国家的成本吧
    ; n1 ^3 P" B7 E+ n我在了2家公司都是这样

    手机版|小黑屋|Archiver|网站错误报告|爱吱声   

    GMT+8, 2026-2-2 20:11 , Processed in 0.080229 second(s), 16 queries , Gzip On.

    Powered by Discuz! X3.2

    © 2001-2013 Comsenz Inc.

    快速回复 返回顶部 返回列表