Egy szervezet számára vonzó lehetőségnek tűnik házon belülre hozni azt a fejlesztést, amelyet korábban külső partner végzett. A tudás közelebb kerül, a döntések gyorsabbá válhatnak, a cég pedig a beszállítói díj egy részét is megtakaríthatja.

Az elhatározás azonban önmagában még nem hoz létre fejlesztői csapatot.

Ha nem érkezik mellé új kapacitás, megfelelő környezet és világos felelősségi rendszer, ugyanazok az emberek kapnak még egy sapkát. A meglévő projektek, az üzemeltetés és a szakmai feladatok mellé megérkezik a fejlesztés is — gyakran úgy, hogy közben egyik korábbi feladat sem lesz kevesebb.

A beszállítói költség ilyenkor valóban csökkenhet. A munka viszont nem tűnik el, csak máshol jelenik meg.

Projektet veszünk át, vagy képességet építünk?

Ez az első kérdés, amelyet érdemes tisztázni.

Egy projekt átvétele meghatározott eredményről és határidőről szól. Egy belső fejlesztési képesség ennél jóval több: emberek, szerepek, eszközök, folyamatok, döntési jogok és későbbi működtetési felelősség együttese.

A különbség a projekt lezárása után válik igazán láthatóvá. Ki javítja a hibát? Ki követi a technológiai változásokat? Ki fejleszti tovább a megoldást? Ki őrzi az architekturális összhangot, amikor új igény érkezik?

Ha ezekre nincs előre kijelölt válasz, akkor nem képesség épült, csak egy újabb feladat került a szervezetbe.

szándék
  → kijelölt kapacitás
  → fejlesztési környezet
  → tiszta szerepek
  → fenntartható működés
  → belső képesség

A folyamat minden eleme számít. A kapacitást nem pótolja a lelkesedés, a felelősséget nem helyettesíti a technológiai tudás, a fejlesztési környezetet pedig nem teremti meg egy új projekt neve.

A kapacitást nem lehet ugyanarra az órára kétszer lefoglalni

A belső fejlesztés gyakran a szervezet legjobb szakembereire talál rá. Ők ismerik az üzleti területet, az adatokat, a jelenlegi rendszereket és a korábbi döntések okait. Logikus tehát, hogy rájuk épüljön az új működés.

Csakhogy ugyanezek az emberek általában már több projektben és több szerepben dolgoznak. Egy személy lehet egyszerre szakértő, architect, elemző, fejlesztő, tesztelő és informális koordinátor. Ez rövid ideig rugalmas működésnek látszik, tartósan azonban nem ad kiszámítható szállítási képességet.

A névleges létszám ezért kevés információt ad. A valódi kérdés az, hogy mennyi megszakításoktól védett, előre tervezhető idő áll rendelkezésre.

Ha egy új projekt kapacitását kizárólag a meglévő feladatok közötti résekből próbáljuk összerakni, a prioritások minden héten újratárgyalódnak. A projekt halad, de mindig csak addig, amíg egy üzemeltetési esemény, egy másik határidő vagy egy sürgősebb üzleti igény közbe nem lép.

A belső fejlesztéshez ezért nem feltétlenül teljesen új szervezet kell. Kijelölt idő és védett fókusz viszont igen.

Mire érdemes saját képességet építeni?

Nem szükséges minden lehetőségre igent mondani, de a választást nem is érdemes kizárólag a jelenlegi technológiai profilra szűkíteni. Ha egy szervezet csak azt vállalja el, amit már most is pontosan ugyanúgy tud, nem sok tere marad a fejlődésnek. Ha viszont minden elérhető projektre rámozdul, a tanulási költség, a párhuzamos szerepek és a működési kockázat könnyen szétterül a teljes csapaton.

A jobb választóvonal az, hogy az adott képesség hosszú távon része lesz-e a szervezet értékének.

Érdemes házon belül építeni azt, ami:

  • szorosan kapcsolódik a cég tartós szakmai irányához;
  • több projektben vagy termékben újra felhasználható;
  • a belső üzleti és technológiai tudásból valódi előnyt nyer;
  • a projekt után is folyamatos figyelmet és továbbfejlesztést igényel;
  • és amelyhez fenntartható szakmai mag alakítható ki.

Egy ritkán szükséges, erősen specializált vagy egyszeri feladatnál a külső partner továbbra is ésszerű választás lehet. A belső tudás és a partneri szaktudás nem egymás ellentétei. Jól elválasztott felelősségekkel ugyanazon szállítási modell részei lehetnek.

Öt kérdés még az ajánlat előtt

Egy lehetőség értékelését nem az árazással érdemes kezdeni. Először azt kell megvizsgálni, hogy a szervezet valóban képes-e vállalni a teljes életciklust.

1. Illeszkedik a választott szakmai irányhoz?

Az új projekt építi a később is használható tudást, vagy egyetlen szállítás kedvéért hoz létre külön világot?

2. Van név szerint kijelölt kapacitása?

Nem az a kérdés, hogy kik értenek hozzá, hanem az, hogy kik és mennyi időben fognak rajta dolgozni. A rendelkezésre állásnak a többi projekttel együtt is hihetőnek kell maradnia.

3. Megvan a fejlesztés működési tere?

Forráskód-kezelés, fejlesztői és tesztkörnyezet, automatizált build, kiadási folyamat, jogosultságok, monitorozás és hibakezelés nélkül a fejlesztés minden lépése egyedi szervezést kíván. A környezet nem technikai kényelmi elem, hanem a kiszámítható munka alapja.

4. A teljes költséget árazzuk?

Az implementáció csak egy része a vállalásnak. A tanulás, a tervezés, a tesztelés, a koordináció, a dokumentáció, az üzemeltetési átadás és a későbbi támogatás ugyanúgy kapacitást használ.

5. Tudjuk, mi történik az átadás után?

Egy belső fejlesztésnél nincs valódi „falon átdobás”. A létrehozott megoldás életciklusa a szervezeten belül folytatódik. Már az induláskor láthatónak kell lennie, ki lesz a szakmai és működési gazdája.

Ha ezek közül több kérdésre sincs még válasz, attól a lehetőség nem válik rosszá. A vállalás formáját kell hozzáigazítani a valós helyzethez: szűkebb scope-pal, közös partneri szállítással, előkészítő szakasszal vagy egy későbbi indulással.

Mitől lehet magasabb az ár?

Egy specializált fejlesztőcég kész csapattal, kialakult eszközökkel és bejáratott folyamattal érkezik. Egy frissen épülő belső képességnek ugyanezt az alapot még létre kell hoznia. Ha ez a tanulási és felépítési költség egyetlen projekt árában jelenik meg, az ajánlat könnyen magasabb lesz.

Ez önmagában nem teszi indokolatlanná.

A belső szállítás többletértéke lehet a szervezeti kontextus mély ismerete, az architektúrába való szoros illeszkedés, a gyorsabb döntési út és az, hogy a megszerzett tudás a következő projektben is megmarad. Ilyenkor az ügyfél nem egyszerűen fejlesztési órákat kap, hanem tartósan használható összefüggést és felelősséget.

Ha azonban ugyanazt az eredményt kínáljuk hosszabb átfutással és nagyobb bizonytalansággal, a magasabb árat a belső építkezésünk finanszírozásával magyarázzuk. Ez nem ügyfélérték. Ilyenkor érdemesebb partnert bevonni, szűkíteni a vállalást, vagy nem elindulni az adott lehetőségen.

Egy működőképes kezdés

A belső fejlesztési képességet célszerű egy jól körülhatárolt projekten felépíteni. Olyanon, amely közel áll a meglévő szakmai maghoz, de már megköveteli az új működés fontos elemeit.

Az induláshoz néhány egyszerű döntés többet érhet egy nagy átalakítási programnál:

  • legyen egy név szerint kijelölt, kis létszámú magcsapat;
  • a tagjai kapjanak előre rögzített, védett kapacitást;
  • egyszerre kevés fejlesztési feladat fusson;
  • készüljön el a minimálisan szükséges fejlesztői és tesztkörnyezet;
  • legyen világos, mely szerepek maradnak belül, és hol kapcsolódik partner;
  • az első projekt végén ne csak a terméket, hanem a létrejött képességet is értékeljük.

Az első szállítás így kettős eredményt ad. Elkészül egy használható megoldás, és közben létrejön egy olyan működési alap, amelyre a következő projekt már kisebb felépítési költséggel támaszkodhat.

A lényeg

A fejlesztés házon belülre hozása jó stratégiai döntés lehet. Közelebb hozhatja egymáshoz az üzleti tudást, az architektúrát és a megvalósítást, miközben a létrejövő tudás a szervezetben marad.

Ehhez azonban a megtakarítás egy részét képességgé kell alakítani: idővé, eszközzé, fókuszszá és tiszta felelősséggé.

Nem attól lesz valami belső képesség, hogy belső emberek csinálják. Attól lesz az, hogy a szervezet időt, teret, eszközt és felelősséget is rendel hozzá.