Gyakori probléma, hogy egy új webes szolgáltatás ötletét nem tudják maguk az ötletgazdák megvalósítani. Kérdés, hogy hogyan lehet ebben az esetben a fejlesztést megoldani? Alapvetően két lehetőség közül választhatunk: saját csapatot építünk, vagy megbízunk egy külsős céget (esetleg be is lehet vonni tulajdonrész fejében fejlesztőket, de ez egy ponton túl már nem gazdaságos).

A posztban összefoglalom az ezekhez kapcsolódó legfontosabb előnyöket és hátrányokat, majd egy harmadik megoldási javaslatot is bemutatok a kettő előnyeinek ötvözésére. Egy olyan projektet feltételeztem, amiben legalább egy, de inkább több fejlesztőnek folyamatosan akad munka és van fedezet a megvalósításra, tehát ezt is adottságnak vettem.

1. Az alapítók saját fejlesztői csapatot építenek

Előnyök:

• Házon belül lesz a kód és a tudás
• A továbbfejlesztések gyorsan megvalósíthatóak
• A hosszú távú költségek alacsonyak lesznek

 Hátrányok:

• Saját csapat építése hónapokba telik
• Az infrastruktúra kialakítása magas költséggel jár
• Az erőforrás nem jól skálázható: nem biztos, hogy mindig 100%-osan ki lehet terhelni az embereket és az sem, hogy mindent meg lehet oldani házon belül
• Fejlesztői kompetencia hiány miatt nem (feltétlenül) tudnak jó programozókat találni

 2. Megbíznak egy külső fejlesztő céget, hogy fejlessze le a szolgáltatást.

Előnyök:

• A munka azonnal megkezdődhet, nincs szükség csapatépítésre
• A rövid távú költségek alacsonyak, hiszen nem kell irodát bérelni és eszközöket vásárolni
• A fejlesztői kompetencia biztosítva van, akár tanácsadás jelleggel is
• Jól skálázható az erőforrás 

 Hátrányok

• A hosszú távú költségek magasak
• A kód és a fejlesztői tudás házon kívül van, ez nagy kockázatot jelent

3. Kombináljuk ezt a kettőt!

Egy olyan megoldási modellt kezdtünk el kidolgozni, amiben érvényesül a legtöbb előny és a legtöbb hátrányt (részben vagy egészben) ki tudjuk szórni. A modell lényege a következő:

A szolgáltatást külsős cég kezdi el fejleszteni, viszont ezzel párhuzamosan elkezd a fejlesztő cég új embereket keresni a megbízója számára, akiket felvehet és betaníthat a munka hosszú távú elvégzésére. 

Egy példán keresztül bemutatva:

Adott egy scope, amit 2 fejlesztő 4 hónap alatt tud megvalósítani (eközben persze több élesítés is lehet). A tervek szerint 2 embert folyamatosan ki tud terhelni a szolgáltatás fejlesztése, tehát ennyit akar a megbízó felvenni. Elkezdődik a projekt, és a felvételiztetés: elkezdjük írni a kódot, majd elkezdenek jönni az új emberek is. Tegyük fel, hogy sikerül az első hónap végére találni két embert, hála a folyamatos felvételiztetésnek és az isteni szerencsének :)

A két új ember nem fog tudni azonnal produktívan fejleszteni, meg kell ismerkedniük a Rubyval, a módszertanunkkal (Scrum és XP), az addig megírt kóddal és persze magával a projekttel. A módszertanbeli váltás egy hosszabb folyamat, hiszen a hagyományos munkamódszerhez képest teljesen más szemléletet várunk el a fejlesztőtől, ennek az elsajátítása nem megy egyik napról a másikra: az elvi megértése sem kis feladat, a gyakorlatba való átültetése pedig heteket (hónapokat, éveket) vesz igénybe intenzív alkalmazás és tanulás mellett.

Más szemszögből megvizsgálva a kérdést a projekten már dolgozó fejlesztőknek folyamatos betanítást kell végezniük, ami legjobb esetben is megfelezi az ő produktivitásukat. A második (az új emberek számára az első) hónap tehát inkább a betanulásról, mint a produktív fejlesztésről szól. A következő hónapban elkezd javulni a produktivitás, az utolsó hónapra pedig annyira bele kell jönniük az új embereknek a munkába, hogy önállóan tudjanak dolgozni és behozzák a lemaradást, így egyidejűleg már négy fejlesztő tud dolgozni együtt.

Nézzük meg az előbbi bontás szerint az előnyöket:

• A munka azonnal megindulhat, hiszen a külsős cégnek vannak saját fejlesztői
• A költségeket hosszú távon optimálisan lehet tartani, hiszen csak a saját csapat költségével kell számolni.
• A betanítás nem jelent plusz költséget a fejlesztő cég irányába, hiszen továbbra is 2 embert adunk a projektre
• A rövid távú költségeket csökkenti, hogy a betanítás során rendelkezésre bocsátjuk az eszközeinket: iroda, számítógép, szoftverek, csocsó...
• Az alapítók fejlesztői kompetencia hiányából fakadó kockázata minimális lesz, hiszen a felvett fejlesztők az alapítók alkalmazottai lesznek
• A toborzást és a csapatépítés szakmai részét a fejlesztő cég vállalja, tehát csak a szakmailag megfelelő embereket mutatja be a későbbi munkaadónak
• Utoljára, de nem utolsósorban: a megbízó egy olyan fejlesztői gárdát kap, ahol Rubyban, Scrum és XP szerint dolgoznak, azaz a munkamódszereket és a céges kultúrát is "exportáljuk", ami megfizethetetlen hozzáadott értéket jelent.

 Hátrányok:

• Kiszámíthatatlan, hogy mikor találni jó embert
• Az emberek toborzása költséget és plusz feladatokat jelent a fejlesztő cég számára, amit be kell tudnia építeni az életébe - folyamatos növekedés kezelése

Ezt a modellt egyébként két külföldi cég ihlette, az egyik a Cyrus Innovation, külön köszönet Paul Blairnek a beszélgetésekért és a startupFlyernek, hogy összehoztak minket. Leegyszerűsítve ők úgy fejlesztenek, hogy munka közben adják át a módszertanbeli tudásukat a projekt során a többi fejlesztőnek (szintén XP és Scrum).

A másik a Toughtbot kickstart nevű szolgáltatása, ami nagyon hasonlít üzleti szinten ahhoz, amit fentebb leírtam: eszközöket és fejlesztői kompetenciát biztosítanak induló szolgáltatásoknak.

Ti hogy látjátok ezt a kérdést, mivel lehet életképsebbé tenni ezt a szolgáltatást, mik lehetnek a további előnyei és buktatói?