If it's a core business function -- do it yourself, no matter what. --
Pick your core business competencies and goals, and do those in house. If you're a software company, writing excellent code is how you're going to succeed. Go ahead and outsource the company cafeteria and the CD-ROM duplication.
Tuurlijk het klinkt allemaal mooi: lage kosten en snel resultaat, wie wil dat nou niet?
De 5 grootste risico's die ik zie zijn:
- Diefstal van code
- Specificaties en kwaliteit van code
- Plannen
- Communicatie problemen
- Change management
Diefstal van code:
Op het moment dat je heel de applicatie uitbesteed aan een andere partij heb je de kans dat die partij er met jouw code vandoor gaat. Of anders met de concepten erachter. Dat hebben we gezien met Microsoft en IBm in de jaren 80. En kortgeleden nog met de rechtzaak tussen Heineken en Philips over de beertender\perfect draft. De enige manier om dit risico beheersbaar te houden: laat ze kleine afgebakentende onderdelen maken die opzichzelf weinig kunnen. Maar wat is dan de winst van outsourcen? Kun je die onderdelen dan niet beter als component inkopen?
Specificaties en kwaliteit van code:
Wanneer je code gaat uitbesteden zal de specificatie heel duidelijk en eenduidig moeten zijn. Beide partijen moeten weten wat er gemaakt wordt en hoe. Dit vraagt een flinke tijdsinvestering vooraf, zeker als je organisatie hier niet op ingericht is en specificaties vaak veranderen. Daarnaast zul je een manier moeten hebben om te testen of de geleverde code aan de specificaties voldoet.
Plannen:
In een project is een bepaald stuk code vaak afhankelijk van andere stukken code. Sommige zaken moeten nu eenmaal na elkaar en kunnen niet tegelijkertijd. Dit zul je goed moeten plannen. Maar de enige die weet hoe lang een feature precies duurt is de programmeur zelf. Wat de ene programmeur in 10 min, doet een ander 5 dagen over. Afhankelijk van ervaring en kennis. Mensen die zonder detail specificaties zeggen hoe lang iets duurt liegen.
Communicatie problemen:
Iedereen die met een multi-site ontwikkel team gewerkt heeft kent het probleem: communicatie! Ook al spreek je dezelfde taal als je niet fysiek in dezelfde kamer bent gaat het communiceren al lastiger dan iemand die naast je staat. Zeker als je moet overleggen over de details van hoe iets geimplemteerd moet worden. Laat staan als je een andere taal spreekt en zelfs in een andere tijdzone leeft. Je moet een goede Project Manager zijn om Multi-Site ontwikkeling goed te kunnen managen.
Change management:
Eind goed al goed, je hebt een stukje software ge-outsourced en het product is opgeleverd. Hoera. Alleen nu blijkt er een fout in te zitten in de aangeleverde code. En iedere programmeur weet hoe moeilijk het is om code van anderen te lezen. Dus mag je naar India bellen om uit te leggen wat er fout zit en dat ze het op moeten lossen, of nog leuker mensen zijn dol enthousiast maar willen 1 kleine wijziging..
Kortom: Outsourcen zal best lukken mits:
- Je heel goed kunt plannen
- Je een heel goede project manager hebt die alles in de hand heeft
- Je duidelijke specicificaties hebt
- Je heldere testprocedures hebt
En dan schat ik de kans op succes nog maar op 50%. En een groot deel van het geld wat je bespaard ben je kwijt aan die goede Project Manager, de communictie en controle. (Dat voortraject van specificaties en goed plannen moet je zoiezo doen natuurlijk ;) )
Kortom huur gewoon een aantal goede Programmeurs in, 2 goede programmeurs verzetten evenveel werk als 20 middelmatige, en maak het jezelf gemakkelijk.
The only exception to this rule, I suspect, is if your own people are more incompetent than everyone else, so whenever you try to do anything in house, it's botched up. Yes, there are plenty of places like this. If you're in one of them, I can't help you.
Geen opmerkingen:
Een reactie posten