A weboldal használatával elfogadja az Adatkezelési Tájékoztatóban foglaltakat, amely tartalmazza süti szabályzatot is.
A fejlesztők lecserélése mindig egy nehéz döntés, de a Broduction végig segít a folyamatban, legyen az Web, Applikáció vagy AR/VR fejlesztés. A leváltott fél lehet freelancer vagy egy szoftverház csapata is, a lépések ugyanazok.
Röviden az új beszállítónak hozzá kell férni mindenhez, ami az adott szoftver fejlesztésével kapcsolatos és törekedni rá, hogy a korábbi fél akarva akaratlanul de semmit se tartson vissza. Átadja a forráskódot, dokumentációkat és egyéb rendszerekhez való hozzáférést mindezt megfelelő -admin- jogosultsággal.
Egyszerűen hangzik de a lentebb található checklist-ünkkel az is lesz. Átnézzük mik az első lépések melyekkel a felmerülő nehézségek kezelhetőek. Egy megfelelő audit folyamattal mely főként felmerülő biztonsági és használhatósági hibák felderítését szolgálják, az új csapat akár már 1-2 héten belül új funkciókat szállíthat. Nézzük hogyan lehetséges.
A gördülékeny váltás érdekében fontos, hogy az érkező csapat megértse a termék vízióját, legfontosabb céljait (KPIs). Tisztában kell lenniük a projekt technológiai hátterével, függőségeivel. Mely fejlesztési tételek készültek el, mik vannak éppen fejlesztés alatt és mikkel kell majd foglalkozni közvetlenül az átvétel után?
Általában a korábbi fejlesztők tudnak ebben segíteni, hogy a lehető legpontosabb leírást lehessen az új csapat számára bocsátani a megfelelő dokumentációkkal. Például, ha egy mobil applikációról beszélünk a következő információkra lesz szükség, hogy kiderüljön a kiszemelt csapat tudja e vállalni a megbízást.
Miután megvannak a szükséges információk a projekt technológiai hátteréről, a felkeresett új beszállítók már érdemben tudnak rá reagálni. Ideális esetben egy megfelelő titoktartási nyilatkozat aláírását követően. Ezután hozzáférést kaphatnak a szükséges anyagokhoz, erőforrásokhoz, hogy megbecsülhessék pontosan mennyi időre lesz szükségük míg átveszik és auditálják a terméket.
Ha vízesésmodellben dolgozott a korábbi csapat akkor valahol lennie kell egy részletes szoftver specifikációnak, mely segíti az átvételt. Ha pedig agilis megközelítéssel dolgoztak, akkor úgynevezett product backlog item-ekkel, user story-kkal kell rendelkezniük, melyek részletesen kifejtenek egy-egy leprogramozott feladatot.
Egyértelműen ez a legfontosabb és remélhetőleg megfelelően karbantartott és dokumentált anyagról beszélünk. A legjobb ha a kód dokumentációja és a használt harmadikféltől származó fejlesztői csomagok információ is elérhetőek.
Nem a világvége, ha csak a forráskód menthető a régi fejlesztőktől, a szükséges információk kinyerhetőek a kódból, de nem túl ideális és eltarthat egy ideig.
A beszállítócsere egyszerűbb lehet, ha a termék fő funkcionalitása le van fedve automatikus (integration, controller or unit) tesztekkel. Ezenfelül, ha működő funkcionális és UI tesztek is vannak az nagyszerű, mivel így ellenőrizhetőek és könnyen megérthetőek az üzleti értéket hordozó folyamatok.
Szükség lesz minden fájlra, hasznos adatra, ami a projekttel kapcsolatos. Ezek -a teljesség igénye nélkül- lehetnek: design fájlok, prototípusok, mockup-ok, 2D/3D modellek, audió, videó vagy animációs anyagok, stb...
A kód verziókezelő és feladat menedzselő rendszeréhez való hozzáférés elérhetősége biztosítja, hogy minden fontos információ eljut a megfelelő helyre. Egyéb hozzáférések, az adott terméktől függhetnek, az új beszállító biztosan jelzi mikre lehet még szükség.
Ez lehet a leggyorsabb és a leglassabb lépés is mind közül. Sajnos a meglévő beszállító nem mindig kötelezhető az akadálytalan váltás elősegítésére.
Nézzük, mik a leggyakoribb problémák és mit érdemes tudni róluk:
Annak érdekében, hogy minél simábban véget érjen a folyamat, fontos hogy a termék gazdája nyugodt mediátorként működjön a felek között. Az előző fejlesztők további pénzügyi igényei adott esetben jogosak is lehetnek, a legfontosabb, hogy mindenki a ténylegesen megkötött szerződés alapján járjon el. Elképzelhető, hogy az érkező csapat is segíthet a véleményével, egy kifejezetten szakami kérdéskör kapcsán kialakult vitás helyzetben.
Alapvetően mindig az ügyfél a termék egyetlen tulajdonosa tulajdonjogi szempontból és ez vonatkozik a használt külső rendszerekre, fiókokra is. Értesítve a korábbi ügynökséget, ők át tudják adni ezen hozzáféréseknek a pontos listáját. Átvéve az irányítást ezek felett, érdemes meggyőződni annak teljességéről (admin jogosultság), majd megválni azon személyektől a fiókokban akik már nem dolgoznak a terméken.
Mielőtt az új fejlesztők neki ugranának az új funkciók kódolásának fontos, hogy alaposan átnézzék a jelenlegi kódbázist és előálljanak egy feladat listával. Mely a legégetőbb változtatási igényeket tartalmazzák, persze csak ha van ilyen.
A mi fókuszunk általában biztonsági, stabilitási és skálázási problémák körül forog és ellenőrizzük milyen külső függőségeket lenne érdemes frissíteni melyek gyorsan végrehajthatóak vagy kifejezetten nélkülözhetetlenek. Érdemes még a termék hosting szolgáltatásának és annak megfelelő beállítását is ellenőrizni, biztosítva annak a stabilitását és a felhasználók adatainak a biztonságát is az átvétel alatt.
Az új csapat segíthet kiválasztani egy előnyösebb feladat menedzsment szoftvert és javaslatokat tesz a termék lehetséges fejlesztési irányaival kapcsolatban. Miután vége az auditnak, annak kimenete azonnali fejlesztésre alkalmas, megfelelően specifikált fejlesztési tételek (product backlog item), melyek prioritása az üzleti célok mentén lett meghatározva. Ennek eredményeképpen szinte azonnal lehetséges a munka megkezdése.
Nálunk, minden más fejlesztőktől érkezett ügyfelet tapasztalt termék menedzserek és szoftver architect-ek segítenek a lehető legzökkenőmentesebb váltás érdekében.
Broduction
Új fejlesztő csapatot keres megváltozott igényei miatt? 2016 óta foglalkozunk termékfejlesztéssel a Broduction-nél. Bátran kereshet minket, ha kérdése lenne egy lehetséges váltással kapcsolatban! Mi segítünk!
Keressen most