Kaip per 30 dienų įdarbinti specializuotą programavimo komandą

Įvadas

Dauguma užsakomųjų paslaugų sutarčių žlunga jau per pirmąjį mėnesį, o ne per pirmuosius metus. Inžinieriai yra kvalifikuoti, o kaina – sąžininga, tačiau komanda savaites praleidžia neturėdama prieigos, konteksto ar aiškių prioritetų. Kol darbas pagaliau prasideda, klientas jau yra praradęs pasitikėjimą šiuo modeliu.

Specializuota programavimo komanda gali pasiekti visą našumą per 30 dienų, jei klientas tam pasirengia. Tiekėjas rūpinasi darbuotojų paieška ir įdarbinimu, tačiau tik klientas gali paaiškinti, kas yra produktas, kodų bazė ir verslo tikslai. Įvedimas į darbą yra bendras projektas, o didžiąją dalį žinių perdavimo atlieka kliento pusė.

Prieš pirmąją dieną: ką reikia paruošti

Savaitė prieš pradžios datą lemia, kaip greitai komanda dirbs. Inžinieriai, kurie tris dienas laukia prieigos prie kodų saugyklos, praranda pagreitį, o šis vėlavimas nustato visos bendradarbiavimo eigos toną.

Pasirengimas užima keletą valandų kliento darbo. Didžioji dalis yra administracinio pobūdžio, ir visą sąrašą gali tvarkyti vienas asmuo.

• Prieiga ir paskyros. Sukurkite paskyras kodų saugyklai, užduočių sekimo sistemai, debesų konsolės ir komunikacijos kanalams. Prieš pradžios datą išbandykite kiekvieną prisijungimą.
• Techninė dokumentacija. Surinkite architektūros diagramas, API aprašymus ir nustatymo vadovus vienoje vietoje. Pasenę dokumentai yra priimtini, jei kas nors pažymi, kas pasikeitė.
• Kontaktinis asmuo. Paskykite vieną asmenį kliento pusėje, kuris atsakytų į klausimus per vieną darbo dieną. Paprastai tai yra technikos vadovas arba produkto savininkas.
• Pradinis užduočių sąrašas. Paruoškite 10–15 mažo ir vidutinio sudėtingumo užduočių. Komandai reikia darbo, kuris padėtų susipažinti su kodų baze nekeliant rizikos gamybai.

1 savaitė: prieiga, kontekstas ir pirmosios užduotys

Pirmoji savaitė skirta orientacijai. Komanda sužino, ką daro produktas, kas jį naudoja ir kaip organizuotas kodas.

Šios savaitės rezultatas sąmoningai yra nedidelis. Tikslas – sukurti darbo aplinką ir atlikti pirmąjį sujungtą pakeitimą, o ne išleisti naują funkciją.

1–2 dienos: Aplinkos parengimas

Pirmą dieną klientas surengia pradinį pokalbį. Produkto savininkas paaiškina verslo modelį, pagrindines vartotojų grupes ir dabartinius prioritetus. Techninis vadovas apžvelgia architektūrą ir diegimo procesą.

Po pokalbio inžinieriai sukonfigūruoja vietines aplinkas ir paleidžia programą. Dauguma konfigūracijos problemų iškyla būtent čia, todėl kliento kontaktinis asmuo turėtų būti pasiekiamas, kad galėtų greitai atsakyti į klausimus.

3–5 dienos: pirmosios nedidelės užduotys

Kiekvienas inžinierius imasi vienos ar dviejų užduočių iš pradinio užduočių sąrašo. Šiame etape gerai tinka klaidų taisymai, nedideli vartotojo sąsajos pakeitimai ir testavimo aprėptis. Jie dirba su tikru kodu, tačiau rizika yra nedidelė.

Kiekviena užduotis praeina visą kodų peržiūros, testavimo ir diegimo ciklą. Tai parodo komandai, kaip dirba klientas, ir leidžia anksti nustatyti proceso trūkumus.

2 savaitė: procesai ir bendravimo ritmas

Antrąją savaitę komanda pereina nuo individualių užduočių prie komandinių veiklos procedūrų. Klientas ir tiekėjas susitaria, kaip planuoti, aptarti ir atsiskaityti už darbą.

Išsibarsčiusioms komandoms reikia daugiau struktūros nei dirbančioms vienoje vietoje. Laiko juostos ir kultūriniai skirtumai apsunkina neformalų bendravimą, todėl bendravimo ritmas turi būti aiškiai apibrėžtas.

• Kasdienės trumpas susirinkimai. Surenkite trumpą pokalbį laiku, kuris sutampa abiejose laiko juostose. Penkiolika minučių pakanka padėties apžvalgai ir kliūčių aptarimui.
• Sprintų planavimas. Planuokite darbą vienos ar dviejų savaičių sprintais. Kliento produkto savininkas nustato prioritetus, o komanda įvertina reikalingas pastangas.
• Kodo peržiūros taisyklės. Susitarkite, kas ką peržiūri ir per kiek laiko. Jei peržiūra vėluoja daugiau nei vieną dieną, tai sulėtina visą komandą.
• Rašytinės naujienos. Paprašykite, kad bendrame kanale būtų skelbiama trumpa savaitės santrauka. Tai suteikia suinteresuotosioms šalims informaciją be papildomų susitikimų.
• Escalation path. Nustatykite, kas kiekvienoje pusėje sprendžia kliūtis. Tiekėjo klientų vadybininkas tvarko komandos klausimus, o kliento kontaktinis asmuo – klausimus, susijusius su produktu.

3–4 savaitės: Atsakomybė ir vertinimas

Per paskutines dvi savaites patikrinama, ar įvedimas į darbą pavyko. Komanda prisiima tikrą atsakomybę, o abi pusės vertina rezultatus pagal aiškius kriterijus.

Šis etapas taip pat parodo, kur procesą dar reikia patobulinti. Nedideles problemas lengviau išspręsti 25-ą dieną nei 90-ą dieną.

Tikros funkcijos perdavimas

Trečią savaitę komandai paskirkite vieną užbaigtą funkciją iš produkto plano. Ji turėtų reikalauti dizaino sprendimų, darbo su keliomis kodų bazės dalimis ir išleidimo į gamybą.

Kliento technikos vadovas peržiūri techninį požiūrį prieš pradedant kūrimą. Po to komanda pati atsako už darbą nuo sąmatos iki diegimo. Atidus priežiūra šiame etape prieštarauja tikslui.

Rodikliai, kuriuos reikia stebėti 30-ąją dieną

Mėnesio pabaigoje surenkite apžvalgos pokalbį su tiekėju. Palyginkite rezultatus su pirmąją savaitę nustatytais lūkesčiais ir, jei įmanoma, remkitės skaičiais.

• Pristatymo tempas. Palyginkite suplanuotus ir įvykdytus istorijos taškus per paskutinius du sprintus. Stabilus tempas yra svarbesnis nei greitas.
• Kodo kokybė. Patikrinkite, kokia dalis „pull“ prašymų praeina peržiūrą per pirmąjį arba antrąjį etapą. Dažnas perdarymas rodo konteksto spragas.
• Klausimų skaičius. Stebėkite, kaip dažnai inžinieriai prašo kliento pagalbos. Šis skaičius turėtų mažėti kiekvieną savaitę.
• Suinteresuotųjų šalių atsiliepimai. Paprašykite produkto savininko ir techninio vadovo pateikti trumpą įvertinimą. Jų nuomonė dažnai atskleidžia problemas, kurių rodikliai nepastebi.

Dažniausios įdarbinimo klaidos

Dauguma vėlavimų įdiegimo procese kyla dėl tų pačių kelių priežasčių. Įmonės jas kartoja, nes iš pradžių kiekviena iš jų atrodo nereikšminga.

• Vėluojanti prieiga. Paskyros, kurios gaunamos trečią dieną, komandai kainuoja tris dienas. Saugumo patvirtinimai dažnai užtrunka ilgiau nei tikėtasi, todėl juos reikia pradėti tvarkyti iš anksto.
• Produkto konteksto trūkumas. Inžinieriai, nesuprantantys vartotojų, priima techniškai teisingus, bet nenaudingus sprendimus. Viena valanda produkto paaiškinimo sutaupo savaičių darbo persvarstymui.
• Per daug kontaktinių asmenų. Kai nurodymus duoda penki žmonės, kyla prioritetų konfliktas. Vienas sprendimų priėmėjas užtikrina aiškią kryptį.
• Komandos traktavimas kaip išorės. Atskiri komunikacijos kanalai ir riboti susitikimai sukuria dviejų lygmenų struktūrą. Komandos, kurios įsilieja į kliento kasdienybę, integruojasi greičiau.

Paskutinės mintys

Trisdešimt dienų pakanka, kad specializuota komanda pasiektų visą produktyvumą. Rezultatas priklauso ne tiek nuo tiekėjo, kiek nuo to, kaip gerai klientas parengia prieigą, kontekstą ir aiškius prioritetus.

Laikykite įdarbinimą projektu, turinčiu atsakingus asmenis, terminus ir galutinę peržiūrą. Strukturizuotas pirmasis mėnuo sukuria pasitikėjimą, kurio reikia ilgalaikiam bendradarbiavimui.