HTML

Magunkról

The blog of the Budapest based Digital Natives covers the topics such as technological challenges we meet in our work, also our solutions and developments related mostly to Ruby on Rails and e. g. JavaScript. You can read about project management methodologies, which drive our workflow, such as agile or scrum. We don’t forget to report about our work and free-time related events and activities.

Facebook

Címkék

2011 (1) 2012 (4) 2013 (5) 2014 (2) agency (1) agile (1) agilis (13) android (1) angel (2) anita (2) API (1) árazás (2) artisjus (1) balaton (1) bécs (1) becs (1) becslés (1) befektető (7) befekteto (1) bemutatkozás (1) berlin (1) beszédfelismerés (2) beszédtechnológia (1) bitbucket (1) blog (1) borkóstoló (1) budapest.rb (1) célok (1) client (4) cloud (1) code hulk (1) coding (1) coin (1) concept (2) conference (1) continuous integration (1) cross browser (1) cross platform (2) csapat (4) csapatépítés (1) csocsó (1) David (1) ddb (1) deployment (3) design (2) dev (5) dev meeting (2) digital (1) diktálás (1) dojo (1) ebook (1) education (1) elemzés (3) elmélet (1) English (1) english (9) értékelés (1) értékesítés (3) extreme programming (1) fejlesztő (3) feliratozás (1) Friday (1) frontend (2) game (3) game of thrones (1) gerzson (2) hackfwd (2) heroku (1) hirdetés (1) hosting (1) icatapult (2) idcee (4) idea (1) implementation (2) inkubáció (9) ios (1) javascript (1) jenkins (1) jogdíj (1) jruby (1) kaizen (1) kalandpark (1) kanban (3) képzés (2) kijev (1) kipuedu (1) kirándulás (1) kocákzati tőkealap (1) kommunikáció (1) lean (2) LinkedIn (1) Logidok (1) mahasz (1) marketing (1) meetup (9) mindroom (2) Mitnick (1) mixgar (14) mobil (4) moving (1) mvp (2) MVP (1) nabaztag (1) natives (1) olasz (1) open source (1) people search (1) piknik (1) planning (1) playertise (3) prága (1) presentation (1) product owner (1) product roadmap (1) project (1) prototípus (1) prototype (1) rabbit (1) rails (15) ruby (14) rupy (1) scrum (9) search API (1) series (2) sharewood (1) siker (2) social (1) sorozat (1) spaceship (1) speedinvest (1) startup (6) startup week (1) String (1) szerződés (1) szolgáltatás (2) taxi (3) taxitrust (3) taxtrust (1) techshow (2) testing (2) teszt (1) titanium (1) toborzás (2) tőke (2) toptal (1) trónok harca (1) tumblr (1) ügyfél (1) UI (1) UML (1) UX (2) üzletiangyal (1) vagrant (1) varga anita (1) verseny (2) videó (1) videóarchívum (1) vienna (1) világhírnév (8) virtualbox (1) vm (1) vodka (1) web (8) wired (2) workflow (2) xp (3) XP (1) Címkefelhő

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?

Címkék: xp web szolgáltatás értékesítés fejlesztő rails ruby toborzás scrum agilis

3 komment

A bejegyzés trackback címe:

https://digitalnatives.blog.hu/api/trackback/id/tr152479355

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

akocsis · http://akocsis.blog.hu 2010.11.30. 14:27:06

Ha jól értem:
- 4 fejlesztőt kell fizetni
- Az idő egy része betanítással fog elmenni
- A kártyák továbbra is a fejlesztő cég kezében maradnak

Ezek szerint ez a három közül a legrosszabb megoldás?

Az egyik banknál láttam ilyen megoldást, nagyon félrement.

Egyébként pedig úgy érzem, hogy itt a gombhoz keressük a kabátot, nem a kabáthoz a gombot.
Eleve azt kellene tudni, hogy a kkv profiljába beletartozik-e a szoftverfejlesztés, mi szerepel az üzleti tervükben.
Ha szoftvert akarnak fejleszteni, akkor 1-es opció, ha nem akarnak vele foglalkozni akkor 2-es.
Ha pedig a tulaj nem tudja eldönteni a kérdést, akkor érdemes lenne újra átgondolni az életét.

kristof.bardos 2010.12.01. 12:46:50

@akocsis: Egy olyan induló vállalkozásról beszélünk, ami egy szolgáltatásötletre (üzleti modellre) épül, elsősorban üzleti tudása van az alapítóknak és nincs idejük magukat szoftverfejlesztő céggé alakítani. Hosszú távon viszont cél, hogyha sikeres a szolgáltatásuk, akkor házon belül tudják megoldani a fejlesztést. A kártyák a fejlesztők kezében vannak, akik az alapítók alkalmazásában állnak - de ez így van mindenhol a világon.

akocsis · http://akocsis.blog.hu 2010.12.01. 16:14:49

A szolgáltatásnak nem kell feltétlenül házon belül lennie, de ha az alapítók célja hosszú távon ez, akkor egyértelmű mit kell tenniük. A kérdés meg lett válaszolva.

A kártyák tekintetében: igaz, hogy a fejlesztők kezében vannak kártyák, de ezen a felsorolt módszerek közül egyik sem segít.