Hogyan lehet 30 nap alatt bevezetni egy dedikált fejlesztői csapatot?

Bevezető

A legtöbb kiszervezési szerződés nem az első évben, hanem már az első hónapban kudarcot vall. A mérnökök képzettek, a díjazás pedig méltányos, de a csapat hetekig hozzáférés, kontextus és egyértelmű prioritások nélkül dolgozik. Mire a munka megkezdődik, az ügyfél már elvesztette a bizalmát a modell iránt.

Egy dedikált fejlesztői csapat 30 napon belül elérheti a teljes termelékenységet, ha az ügyfél felkészül rá. A szolgáltató intézi a toborzást és a foglalkoztatást, de csak az ügyfél tudja elmagyarázni a terméket, a kódbázist és az üzleti célokat. A beillesztés közös projekt, és a tudásátadás nagy részét az ügyfél oldala végzi.

Az első nap előtt: mire kell felkészülni

A kezdés előtti hét dönti el, milyen gyorsan halad a csapat. Azok a fejlesztők, akik három napig várnak a kódtárhoz való hozzáférésre, elveszítik a lendületüket, és ez a késedelem meghatározza az egész együttműködés hangulatát.

A felkészülés néhány órányi munkát igényel az ügyféltől. Ennek nagy része adminisztratív jellegű, és egy személy is elvégezheti az egész listát.

• Hozzáférés és fiókok. Hozzon létre fiókokat a kódtárhoz, a feladatkövetőhöz, a felhőkonzolhoz és a kommunikációs csatornákhoz. Tesztelje az egyes bejelentkezéseket a kezdési dátum előtt.
• Műszaki dokumentáció. Gyűjtse össze egy helyen az architektúra-diagramokat, az API-leírásokat és a beállítási útmutatókat. Az elavult dokumentumok is elfogadhatók, ha valaki megjelöli, mi változott.
• Kapcsolattartó. Jelöljön ki egy személyt az ügyfél oldalán, aki egy munkanapon belül válaszol a kérdésekre. Ez a személy általában a technikai vezető vagy a termékfelelős.
• Kezdeti feladatlista. Készítsen elő 10–15 alacsony és közepes összetettségű feladatot. A csapatnak olyan munkára van szüksége, amely segít megismerni a kódbázist anélkül, hogy kockázatot jelentene a termelésre.

1. hét: Hozzáférés, háttérismeretek és első feladatok

Az első hét az orientációról szól. A csapat megismeri, mit csinál a termék, kik használják, és hogyan van felépítve a kód.

A héten elvárható eredmény szándékosan csekély. A cél egy működőképes környezet és az első összevonott módosítás, nem pedig egy új funkció kiadása.

1–2. nap: A környezet beállítása

Az első napon az ügyfél szervez egy induló megbeszélést. A termékfelelős elmagyarázza az üzleti modellt, a főbb felhasználói csoportokat és a jelenlegi prioritásokat. A technikai vezető áttekinti az architektúrát és a telepítési folyamatot.

A megbeszélés után a fejlesztők beállítják a helyi környezetet és futtatják az alkalmazást. A legtöbb beállítási probléma itt merül fel, ezért az ügyfél kapcsolattartójának elérhetőnek kell lennie a gyors válaszadás érdekében.

3–5. nap: Első kis feladatok

Minden mérnök egy vagy két feladatot vállal a kezdeti backlogból. A hibajavítások, a kisebb felhasználói felületi változtatások és a tesztelési lefedettség ebben a szakaszban jól működnek. Ezek során valódi kóddal dolgoznak, de a kockázat alacsony.

Minden feladat végigmegy a kódfelülvizsgálat, a tesztelés és a telepítés teljes ciklusán. Ez megmutatja a csapatnak, hogyan működik az ügyfél, és korán feltárja a folyamat hiányosságait.

2. hét: Folyamatok és kommunikációs ritmus

A második héten a csapat az egyéni feladatokról áttér a csapat rutinjaira. Az ügyfél és a szolgáltató megegyeznek abban, hogyan tervezik, vitatják meg és jelentik a munkát.

A távoli csapatoknak több struktúrára van szükségük, mint az egy helyen dolgozóknak. Az időzónák és a kulturális különbségek megnehezítik az informális kommunikációt, ezért a ritmusnak egyértelműnek kell lennie.

• Napi standup-megbeszélések. Tartson egy rövid telefonos megbeszélést olyan időpontban, amely mindkét időzónában elérhető. 15 perc elegendő az állapot és az akadályok áttekintéséhez.
• Sprinttervezés. Tervezzék meg a munkát egy- vagy kéthetes sprintekre. Az ügyfél termékfelelőse határozza meg a prioritásokat, a csapat pedig becsüli a munkával járó erőfeszítést.
• Kódfelülvizsgálati szabályok. Állapodjanak meg abban, ki mit és milyen gyorsan vizsgál felül. Az egy napnál hosszabb késedelem az egész csapat munkáját lassítja.
• Írásbeli frissítések. Kérjen rövid heti összefoglalót a közös csatornán. Ez az érdekelt felek számára átláthatóságot biztosít további megbeszélések nélkül.
• Escalation path. Határozzák meg, ki oldja meg az akadályokat mindkét oldalon. A szállító ügyfélmenedzsere kezeli a csapattal kapcsolatos problémákat, az ügyfél kapcsolattartója pedig a termékkel kapcsolatos kérdéseket.

3–4. hét: Felelősségvállalás és értékelés

Az utolsó két hét során kiderül, hogy a beilleszkedés sikeres volt-e. A csapat valódi felelősséget vállal, és mindkét fél egyértelmű kritériumok alapján értékeli az eredményeket.

Ez a szakasz azt is megmutatja, hol van még szükség a folyamat finomítására. A kisebb problémákat a 25. napon könnyebb kijavítani, mint a 90. napon.

Egy valódi funkció átadása

A harmadik héten rendeljen a csapatnak egy teljes funkciót a terméktervből. Ennek tervezési döntéseket kell igényelnie, a kódbázis több részén kell átívelnie, és termelésbe is be kell vezetni.

Az ügyfél technikai vezetője a fejlesztés megkezdése előtt áttekinti a technikai megközelítést. Ezt követően a csapat felel a munkáért a becsléstől a telepítésig. A szoros felügyelet ebben a szakaszban ellentétes a célokkal.

A 30. napon nyomon követendő mutatók

A hónap végén tartson áttekintő megbeszélést a szolgáltatóval. Hasonlítsa össze az eredményeket az első héten kitűzött elvárásokkal, és ahol lehetséges, használjon számadatokat.

• A szállítási ütem. Hasonlítsa össze a tervezett és a teljesített sztoripontokat az elmúlt két sprintben. A stabil ütem fontosabb, mint a gyors.
• Kódminőség. Ellenőrizze, hogy a pull requestek hány százaléka felel meg az első vagy a második körben. A gyakori átdolgozás a kontextusbeli hiányosságokra utal.
• Kérdések száma. Kövessük nyomon, milyen gyakran kérnek segítséget a fejlesztők az ügyféltől. Ennek a számnak hetente csökkennie kell.
• Az érdekelt felek visszajelzései. Kérjen rövid értékelést a termékfelelőstől és a műszaki vezetőtől. Véleményük gyakran olyan problémákat tár fel, amelyek kimaradnak a mutatókból.

Gyakori bevezetési hibák

A bevezetési késések többségének ugyanazok a kevés okai vannak. A cégek újra és újra elkövetik őket, mert eleinte mindegyik apróságnak tűnik.

• Késői hozzáférés. A harmadik napon érkező fiókok három napba kerülnek a csapatnak. A biztonsági jóváhagyások gyakran tovább tartanak a vártnál, ezért érdemes korán elkezdeni őket.
• A termék kontextusának hiánya. Azok a mérnökök, akik nem értik a felhasználókat, technikailag helyes, de haszontalan döntéseket hoznak. Egy óra termékmagyarázat heteknyi újramunkát takarít meg.
• Túl sok kapcsolattartó. Ha öt ember ad utasításokat, a prioritások ütköznek egymással. Egy döntéshozó biztosítja az irány egyértelműségét.
• A csapat külsőként való kezelése. A különálló csatornák és a korlátozott értekezletek kétrétegű struktúrát hoznak létre. Azok a csapatok, amelyek beilleszkednek az ügyfél rutinjába, gyorsabban integrálódnak.

Záró gondolatok

Harminc nap elegendő ahhoz, hogy egy elkötelezett csapat teljes termelékenységre tegyen szert. Az eredmény kevésbé függ a szolgáltatótól, inkább attól, hogy az ügyfél mennyire jól biztosítja a hozzáférést, a kontextust és a világos prioritásokat.

Kezelje a beillesztést úgy, mint egy projektet, amelynek felelősei, határidői és záróértékelése van. A strukturált első hónap megteremti azt a bizalmat, amelyre egy hosszú távú együttműködésnek szüksége van.