Slashdot Mirror
25 Years Old and an Offshore IT Manager
dcblogs writes "The Chinese outsourcing market, at $1.7 billion last year, is growing at 38% a year, according to research by the Everest Group. This is creating opportunities for Westerners who want to go to China, learn the language, and help these Chinese offshore companies reach overseas markets. There are job opportunities for people with management experience or who are young and willing to gamble. Here's the story of one 25-year-old who started learning Mandarin on his plane ride over to China, three years ago, and is now an international development manager for an IT offshoring firm."
look at Vista, it is one of the main highlights of this, it eats up RAM very quickly
Not this again. Vista does eat up RAM for application cache. This means it is effectively using the RAM you spent money on. Once the RAM is needed for more important things Vista will release whatever is required. Why have RAM if your OS doesn't use it?
At the end of the day you get what you pay for, cheap but cheerful
you pay cheap you get cheap
I have some experience myself working with offshore teams (Indian instead of Chinese) half of the team of which I'm a part is offshore. Also we have to deal with other technical teams on a regular basis which are also part onshore / part offshore (in a support capacity not programming) Our role is sort mini-project management (low paid work, which is a cross between project management and a call center, usually for the preparation of quotes for individual PC's / Servers etc, but we typically end up getting involved with things far above our station on a regular basis
Part of the problem can be the language barrier you see you'll usually get individuals with skills in communication (such as call center staff who need to have good English) or individuals with skills in a technical role (such as server Support) But it can be quite hard to find someone who has skills in both areas (technical and can speak English fairly well) this is quite rare. This puts added pressure on the onshore staff that are still remaining to compensate, especially when it comes down to someone who is speaking very fast in a heavy accent, trying to describe some technical problem about Active Directory in half English. This leaves the on-shore guys trying to do double the work they did originally with the missing staff (some of the on-shore staff have already left at our place simply because of the added pressure) The best you can do to get around this is to use something like MS Communicator, or some form of IM which at least cuts out the heavy accent
Another problem is that part of the mentality within these offshore areas is to do exactly what your told to do.
in some ways this is good, in others bad.
Somewhat similar to a machine type mentality, "we follow the process exactly as it's written with no room for flexibility"
you can of course tell them to do something different, but this again still takes time to act as interpreter from an onshore perspective
again this puts added pressure on the remaining onshore teams to compensate when something unexpected comes along which they can't deal with
The above point also leads in some cases to a lack of technical vetting, and experience with the way things such as email accounts are configured within the company. The onshore staff who usually know what they're doing can usually pick up on something when someone asks them to setup something that doesn't smell quite right but for offshore individuals this isn't always the case, who usually take the approach, do it anyway fix it later
One example of this was a test distribution list that was setup recently on the email system, with the number of people working within the company (we're talking above several thousand here, we have several companies tied into the same network via domains) you need to be careful about allowing these sorts of lists to feed into higher level lists that include everyone everywhere. (usually if you do have such a list, it's setup in such a way so that only certain individuals can send to it) Needles to say a new "test" distribution list was created by one of the offshore team, at which point some moronic project manager decided to send a "test" email which then went to everyone's mailbox at the same time This however was not the problem, the problem was when several users decided to hit "Reply-All" which of course sent the reply to all users everywhere and these replies where then replied to with messages such as "should I be on this list?" The end result was that the outlook servers ground to a complete and utter halt, with the sheer volume of crap flying around on the system
Meanwhile once the two onshore employees that had been replaced heard about this, they basically laughed they're asses off
One last final comment, another trick they do here over in the UK is to bring the offshore guys onshore, but then still pay them the going cheap r
Well, nobody has anything but anecdotes to provide.
However, I'm an IT researcher (I can't go into any detail) and have been analyzing the services of a few of the largest Managed Service Providers in the world in my field.
I can't say their names, but we have a lab environment and we're running tests on their products nd services and doing direct comparisons between their services and their claims.
One is considered the "premier" service in the US, the other is the "premier" service in Europe and one is based out of India and is considered the "premier" service in asia.
The Indian firm is actually the largest both by revenue and by number of customers using the service. We presumed that this would mean they have a solid understanding of what they do.
The results from Indian firm is horrible.
And by horrible, I mean laughably horrible.
They're sending us reports using a not-entirely-functional EVALUATION version of the commercial software which their US counterpart uses (developed by a US company). Presumably this would be a service they provide for thousands of customers... But they're using crippleware to send out definitive reports to customers and trying to pass it off as comprehensive. The fact is that they're likely not paying for the crippleware, since this particular crippleware is NOT LICENSED for commercial use.
In our examinations, their event detection is non-existent and the actual appliances they sent us to do the detection work just keep crashing.
They wanted someone to sit and babysit them at the datacenter all through the testing. Apparently this is a normal practice of theirs to do the "watch-notice-reboot" on a daily basis. They seemed shocked we were unwilling to park someone at the datacenter overnight to babysit the testing of supposedly "critical infrastructure gear".
In another of our results, we ran 50-some tests. A good score might be their giving 30-35 results, which is what we expected.
The US firm did well gave 32 results, the European firm did exceptionally well finding 39. The Indian firm discovered 4 of them (holy crap?!?!).
I was casually glancing over the logs of the servers (as a bored system admin in the test company might be doing) and noticed 3 of the events just from a cursory peek, so the fact that their software found only FOUR...
We actually showed them the results, showed them the tests and then let them reconfigure and try again... assuming it was a misconfiguration or some silly error.
The second time around they only discovered TWO of the events. (they did substantially worse, after seeing the cheat-sheet)
Woah.
On the other hand, the Indian firm's rates are on the order of 10-20 TIMES less expensive. You get what you pay for.
I'm sad to report that a massive number Asian (mostly Chinese and Indian) clients are using this service with apparently no idea how absolutely awful they are at it.
But how would they find out? While this company is allowed to advertise in China, their *actually effective* counterparts from the US and Europe are not.
Scary.
Sad.
Just an anecdote.
This isn't to cast a dispersion on outsourcing. Frankly, my opinion was pretty balanced before we ran into this testing scenario very recently... but it makes me go HMMMMMMM....
I have been involved in many outsourced IT projects in various roles from developer to project manager.
Many outsourced projects succeed quite well, but there are many which fail catastrophically. There are several reasons for why a project either fails or succeeds and the number one reason is the quality of management.
The problem arises because many firms are not equipped to deal with the challenges of managing a project outsourced to a vendor residing in another part of the world. They assume that an offshore project can be managed exactly the way a project done by an internal team is managed.
But this is far from true.
The way one approaches a offshore project must necessarily be different from the way one approaches work done internally. This applies to IT projects, manufacturing, consulting.. whatever.
Because many firms do not seem to understand that they need to adopt a different style for managing offshore work, they find that their offshore projects start to fail - and since they had success with their internal team before, they extrapolate this to mean that the outsourcing vendor is completely at fault for the projects failing - or perhaps it is because of the vendor's nationality and background.
Some rules for managing offshore work:
a) Be prepared to spend a lot more time managing the work. Your vendor does NOT know your business - you do. So it is necessary for you to micro-manage the work done by the vendor's team until they have an understanding of what you want done. In the initial stages of starting a project, this will involve traveling across to the vendor's office and sitting with them to establish the requirements, designing screens, helping in the design of the architecture, the database etc.
As the vendor gets more comfortable with your style of work, your requirements etc, they will be able to deliver work without too much involvement from you - and then you can step back and reduce your involvement.
b) Be prepared to review work often - at least once in every 3 to 5 days. This will involve doing code reviews, reviewing the database design, reviewing the progress of work on each module etc.
c) Establish rules for how releases are made - how often are *complete* releases issued, how are hot patches released, how is the QA handled for each of these. It is particularly important in the initial stages of the project to receive deliveries at least once in every 2 weeks or so - this allows you to take any corrective steps early steps early when the pressure on you is low rather than right at the end when project deadlines are right around the corner.
d) You need to decide internally as to how long you are willing to wait till ANY vendor is able to deliver to the standards that you expect. If despite a lot of work, the vendor is not showing any improvement, then you should consider changing your vendor.
e) Insist on receiving code for everything done at least once a week. Review *ALL* code initially. If you notice *ANYTHING* which is not exactly like you want it, insist on it being fixed ASAP. Do this a few times and your team will realize exactly what you need.
(a), (b), (c) and (d) implies is that you need an onshore Project Leader.
f) Do QA internally. Anything which is delivered from your vendor must run through a set of exhaustive QC rounds internally. So you need a QA team internally.
g) Setup tools which you can access and which the team can use for project management, QA and bug tracking, document management etc. Use these tools well and use them often.
If you make the mistake of assuming that your vendor understands your culture, working style, domain, team and expectations thoroughly right at the onset of a relationship with them, then you are in for a big disappointment.
To establish a good working relationship with a vendor, the company outsourcing the work must spend a lot of time to train the vendor.
If you aren't willing to go through this effort, then please do not consider outsourcing.
Not so easy with the points-based immigration system. Just being able to "do IT" won't get you the visa, unfortunately, and the Oz government is much stricter on foreign applicants now...
--- Nick, hard at work
But if you think about it that may be the correct behaviour for best performance. I agree Windows memory management is terrible, and often seems to do stupid things, but I think that the case for optimal performance is a little more complex than you mention.
An (horrific and oversimplified) example: I run a simulation with a very large dataset (in the order of hundreds of megabytes to gigabytes of data), but it's in the background/not all the data is required at once. In the meantime I open and close firefox a few times. Now in your ideal, as much of my simulation data would remain in memory as possible, and firefox would be left out of the cache. However that won't lead to the optimum performance since firefox will be reloaded from disk each time which will be slower. In fact assuming all my RAM is used up by the simulation data, then some of it will have to page out to load firefox. It makes more sense to keep the firefox object code in RAM even after it has closed since it will respond faster if it is used again, and the simulation data was paged out anyway because there was not enough RAM, so no matter what it will have to be reloaded. It is admittedly a gamble, but I can see the case for paging out data that is incredibly rarely used in favour of having more memory available for a performance enhancing cache. This same behaviour is used on Linux and no doubt other systems.
That said I do agree that Windows seems to cling too much to its application cache, if you have several applications consuming very large amounts of memory and CPU time it seems that Windows is incapable of distributing the resources well. I have used Solaris systems that have had 6 or 7 simulations, each with gigabytes of data running simultaneously on a four processor machine. I only noticed that there was this much load when I went to run a simulation myself and it was quite slow. The responsiveness of other applications and the user interface was barely affected, something which I'd attribute to an operating system that does the right thing with memory and processor allocation.