Rozširovanie vývojového tímu o externých inžinierov bez straty kvality kódu

Úvod

Kľúčové body

1. Využite externých inžinierov, ak je váš plán príliš nabitý pre váš hlavný tím.
2. Predtým, ako sa pripoja, stanovte jednoduché pravidlá kvality a základný postup dodávok.
3. Začleňte externých vývojárov pomocou jasného kontrolného zoznamu a jedného kontaktného partnera.
4. Používajte jeden spoločný súbor pravidiel, recenzií a metrík pre všetkých inžinierov.
5. Spoliehajte sa na krátke písomné aktualizácie, aby ste udržali rastúci zmiešaný tím v súlade.

Prečo by ste mali svoj vývojový tím rozšíriť o externých inžinierov?

Váš vývojový tím by ste mali rozšíriť o externých inžinierov, ak máte plný plán a vaši zamestnanci nestíhajú pracovať zdravým tempom. Hlavný dôvod je jednoduchý: externí inžinieri by mali zvýšiť rýchlosť a zručnosti bez zníženia kvality. Ak vám pomáhajú dodávať stabilnú prácu, ktorú je možné bezpečne udržiavať, má toto riešenie zmysel. Ak však pridávajú len stres a náhodné zmeny, nie je to správny čas.

Mnohí vedúci pracovníci v produktových spoločnostiach pociťujú rovnaký tlak. Nedokončená práca sa hromadí, termíny sa posúvajú a nábor kvalitných inžinierov vo vašom meste trvá dlho. V tom momente začnete uvažovať o rozšírení tímu inžinierov s pomocou zvonku. Môžete sa pozrieť na externý vývojársky tím v inej oblasti alebo na menšiu skupinu bližšie k vášmu časovému pásmu. Skutočnou otázkou nie je, či môžete priviesť externú pomoc, ale kedy bude podporovať váš plán, namiesto toho, aby zakrývala hlbšie problémy.

Jedným z dôvodov, prečo pozvať externých inžinierov, je prístup k zručnostiam, ktoré momentálne vo vašej spoločnosti nemáte. Možno potrebujete krátkodobú podporu v oblastiach, ako sú dáta, mobilné aplikácie alebo nové cloudové nastavenia. Možno nechcete budovať úplne nový tím pre každú novú tému. V takom prípade vám rozšírenie tímu softvérových vývojárov môže poskytnúť flexibilnú podporu pre vašu kľúčovú skupinu. Základné znalosti a smerovanie si ponecháte vo svojej spoločnosti a externú pomoc využijete na jasné a zamerané úlohy. V každodennom živote to vyzerá skôr ako pridanie jedného pokojného odborníka do zaneprázdneného tímu než ako vytvorenie druhej spoločnosti.

Existuje aj veľmi základný časový a nákladový uhol pohľadu. Najímanie silných ľudí na vlastnú päsť môže trvať mnoho týždňov alebo dokonca mesiacov a počas tej doby sa vaše resty nezastavia. Tu môžete vidieť jasné výhody rozšírenia IT personálu. Môžete si na určitý čas a v určitom rozsahu prizvať ďalších ľudí, zatiaľ čo budete premýšľať o dlhodobom prijímaní zamestnancov. Pre niektoré tímy táto možnosť vyrovnáva špičky v dopyte namiesto toho, aby nútila k veľkému nárastu počtu zamestnancov. Takéto nastavenie vám umožňuje otestovať, čo dodatočná kapacita prinesie vášmu produktu, skôr ako natrvalo zmeníte celú svoju štruktúru.

Môžete si tiež vybrať rôzne modely, ako sa títo ľudia pripoja k vášmu svetu. V modeli rozšírenia personálu pridáte do svojho tímu externých inžinierov a vaši vedúci každý deň riadia ich prácu. V rámci nearshore vývojového tímu ľudia pracujú v podobnom časovom pásme a môžu sa pripojiť k vašim hovorom a chatom v bežných pracovných hodinách. Mnohé spoločnosti spolupracujú so skúseným partnerom v oblasti vývoja softvéru, ktorý už vie, ako robiť nearshore vývoj softvéru a spolupracovať s internými tímami. Čím sú kultúra, časové pásmo a nástroje podobnejšie, tým je ľahšie dosiahnuť, aby sa mnohí ľudia cítili ako jeden tím, aj keď sa zmluvy líšia. Táto spoločná základňa je to, čo robí externú prácu prirodzenou namiesto krehkou.

Ako pripravíte svoj kód a procesy pred pridaním externého vývojárskeho tímu?

Na externý vývojársky tím sa pripravíte stanovením jasnej a jednoduchej základne pre to, ako vytvárajte a dodávate svoj produkt. Pred príchodom nových ľudí potrebujete spoločné pravidlá, základné nástroje a viditeľný spôsob práce. Bez tejto základne závisí každá zmena od osobného štýlu a pamäti a noví ľudia nemajú ako uhádnuť správnu cestu. S touto základňou sa aj noví ľudia môžu pohybovať v bezpečnom a stabilnom rytme.

Tento základ si môžete predstaviť ako kvalitné bezpečnostné zábradlie pre kód. Toto zábradlie predstavuje jednoduché kontroly, ktorými musí prejsť každá zmena, bez ohľadu na to, kto ju napísal. Môžu sa týkať toho, ako veci pomenúvate, ako formátujete súbory a čo znamená „hotovo“ pre každú malú časť práce. Keď zábradlie zostáva rovnaké pre všetkých, váš produkt pôsobí stabilne aj napriek tomu, že tím rastie a mení sa. Vďaka tomu je ľahšie dôverovať celému toku, nielen ľuďom, ktorých už poznáte.

Potrebujete tiež základný proces nepretržitej integrácie a dodávky. Tento dlhý výraz opisuje jednoduchú myšlienku. Zakaždým, keď niekto zmení kód, systém vykoná kontroly a pomôže presunúť túto zmenu k používateľom v malých, bezpečných krokoch. Tento proces môže fungovať na bežných platformách a môže bežať pri každom odoslaní do vášho hlavného úložiska kódu. Funkčný proces premení mnoho malých úprav na čistú líniu pokroku namiesto hromady veľkých, desivých vydaní. Noví ľudia sa môžu túto cestu naučiť raz a potom ju nasledovať bez ďalších dohadov.

Testy sú kľúčovou súčasťou tejto cesty. Automatizované testovanie v CI/CD znamená, že vaše testy bežia samostatne zakaždým, keď niekto zdieľa nový kód. Môžete začať s jednoduchými kontrolami, ktoré pokrývajú najpoužívanejšie cesty vo vašom produkte. Postupom času môžete pridať ďalšie testy, keď zistíte, kde sa chyby objavujú najčastejšie. Aj malá sada stabilných testov vám poskytuje väčšiu bezpečnosť ako obrovský zoznam manuálnych kontrol, ktoré nikto nestihne vykonať včas. Tento prístup udržuje veci reálne a podporuje interných aj externých inžinierov.

Pomáha tiež pozrieť sa na staršie časti vášho systému, skôr ako požiadate iných, aby sa ich dotkli. Tu prichádza do hry základné riadenie technického dlhu. Technický dlh je spôsob, ako opísať kód, ktorý funguje, ale je ťažké ho zmeniť bez rizika. Môžete označiť zóny, ktoré sú bezpečné pre nových ľudí, a zóny, ktoré stále vyžadujú starostlivosť vašich najskúsenejších zamestnancov. Keď viete, kde sa nachádzajú rizikové časti, môžete externý vývojový tím najskôr nasmerovať do bezpečnejších oblastí. Tým chránite svoj produkt a chránite nových ľudí pred skrytými pascami.

Poslednou časťou základu je jednoduchá bezpečnosť a prístup. Bezpečný životný cyklus vývoja softvéru znie ťažko, ale spočíva na jasných krokoch. Ľuďom poskytnete len prístup, ktorý potrebujú, chránite skutočné údaje používateľov a s tajnými kľúčmi zaobchádzate opatrne. Zapíšete si tiež, čo robiť, keď sa niečo pokazí, aj keď ide o malý problém. Keď je bezpečnosť súčasťou bežnej práce, externí inžinieri sa môžu zapojiť do vášho procesu bez toho, aby vyvolávali nové obavy. Vaše právne a bezpečnostné tímy tiež vidia, že tento rast je výsledkom plánu, nie rýchleho riešenia.

Ako vyzerá bezpečný plán zapracovania externých vývojárov?

Bezpečný plán zapracovania externých vývojárov im poskytuje kontext, nástroje a jasné prvé kroky bez toho, aby ich hnal do hlbokej vody. Mal by pôsobiť ako vedená cesta, kde každý deň má jednoduchý a reálny účel. Keď je plán jasný, noví ľudia môžu priniesť pridanú hodnotu za týždne, nie mesiace, a váš vlastný tím sa necítia vyčerpaní neustálymi otázkami.

Začlenenie externých vývojárov začína spoločným pohľadom na to, čo sa musia najskôr naučiť. Patrí sem váš produkt, vaši používatelia a váš bežný spôsob práce. Kontrolný zoznam pre vývojárov môže obsahovať všetky tieto položky na jednom mieste. Môže byť v podobe jednoduchého dokumentu, ktorý môžu obe strany otvoriť a upravovať. Viditeľný kontrolný zoznam mení „Myslím, že sme im to už povedali“ na „vieme presne, čo je hotové a čo bude ďalej“. Táto malá zmena odstraňuje veľa tichého stresu pre všetkých.

Tu je jeden jednoduchý zoznam, ktorý často dobre funguje ako základ pre takýto kontrolný zoznam:

1. Prístup k kódu, sledovaniu práce a hlavným chatovacím miestnostiam.
2. Kroky na spustenie produktu na notebooku alebo testovacom serveri.
3. Stručný sprievodca pre používateľov, hlavné toky a kľúčové obchodné pravidlá.
4. Mená osôb, ktoré môžete kontaktovať s otázkami o produkte, kóde a nástrojoch.
5. Dve alebo tri malé, jasné úlohy pripravené na prvú skutočnú zmenu.

Pomôže aj určenie jasnej kontaktnej osoby. Technický vedúci alebo senior inžinier môže počas prvých týždňov fungovať ako onboarding buddy. Táto osoba môže skontrolovať všetky počiatočné zmeny, odpovedať na otázky a vysvetliť, prečo minulé rozhodnutia vyzerajú tak, ako vyzerajú. Krátke denné kontroly, aj keby to bolo len päť minút v chate, môžu udržať veci na správnej ceste. Kľudný sprievodca a stabilné kontaktné body prispievajú k bezpečnému zapracovaniu viac ako veľká reč v prvý deň. Postupom času môžete pre vývojárske tímy presunúť viac aktualizácií do asynchrónnej komunikácie, napríklad krátke písomné poznámky.

Z toho, čo som videl, je najväčším rizikom počas zapracovania tichá zmätenosť. Noví ľudia sa boja, že sa pýtajú príliš veľa, a starí členovia tímu dúfajú, že veci sa „vyriešia“ samy od seba. Jasný plán na zapracovanie externých vývojárov a jediný vlastník tohto plánu menia túto situáciu. Keď je za tento proces zodpovedná jedna osoba, môžete spozorovať vzorce, opraviť slabé miesta a urobiť každé ďalšie zapracovanie hladšie. Za pár mesiacov sa tento plán stane opakovaným aktívom namiesto nového boja zakaždým, keď pridáte niekoho nového.

Ako udržiavať kvalitu kódu v zmiešanom vývojárskom tíme, keď riadite externých vývojárov?

Kvalitu kódu v zmiešanom vývojárskom tíme udržiavate pomocou rovnakých jednoduchých pravidiel, kontrol a čísel pre všetkých. Vaše štandardy musia platiť pre všetkých inžinierov, ak chcete, aby produkt pôsobil ako jeden čistý a bezpečný systém. Keď rozdelíte pravidlá podľa typu zmluvy, rozdelíte aj dôveru a jasnosť vo vašom tíme.

Zmiešaný vývojový tím je skupina, v ktorej interní a externí inžinieri pracujú na rovnakom produkte. Môžu sedieť na rôznych miestach, ale zdieľajú jeden backlog a jeden úložný priestor kódu. Táto kombinácia môže byť veľmi silná, pretože spája hlboké znalosti v danej oblasti s novými pohľadmi. Môže byť však aj krehká, ak každá skupina sleduje svoje vlastné zvyky. Bez jasného vedenia sa táto kombinácia mení na skupiny kódu, ktoré sa od seba líšia a medzi ktorými je ťažké sa pohybovať. To je moment, kedy kvalita a rýchlosť začínajú klesať.

V tomto prípade pomáhajú osvedčené postupy jednoduchého preskúmania kódu. Každá zmena by mala prejsť revíziou aspoň jednej ďalšej osoby, bez ohľadu na to, kto ju urobil. Revízie by sa mali zameriavať na zrozumiteľnosť, bezpečnosť a kompatibilitu so zvyškom systému, nielen na štýl. Môžete to podporiť pomocou jednoduchých nástrojov, ktoré skenujú kód a hľadajú bežné problémy. Tieto rutiny udržujú kvalitu kódu externých vývojárov v súlade so zvyškom vášho tímu pokojným a opakovaným spôsobom. Ľudia sa učia jeden od druhého a budujú spoločný pohľad na to, čo je „dobré“.

Môžete tiež sledovať malú sadu metrík tímu vývojárov softvéru. Tie môžu ukázať, ako dlho trvá dokončenie práce, koľko problémov sa dostane k používateľom a ako často dodávate. Nepotrebujete desiatky čísel. Potrebujete len niekoľko, ktoré môžete ľahko prečítať a diskutovať o nich. Keď tieto metriky zostávajú stabilné alebo sa zlepšujú, zatiaľ čo riadite externých vývojárov a rozširujete tím, viete, že vaše nastavenie podporuje kvalitu. Ak sa zhoršia, máte včasný signál na prehodnotenie pravidiel, rozsahu alebo kombinácie úloh.

Komunikačné vzorce sú rovnako dôležité ako pravidlá a čísla. Mnohé zmiešané vývojárske tímy sa tiež považujú za distribuované agilné tímy, pretože ľudia pracujú z viacerých miest alebo časových pásiem. Potrebujú asynchrónnu komunikáciu pre vývojárske tímy, aby pokrok nezávisel od dlhých hovorov. Veľmi pomáhajú krátke písomné aktualizácie, jasné poznámky k úlohám a jednoduché značky stavu. Dobré písomné aktualizácie uľahčujú všetkým inžinierom zapojiť sa, sledovať a vylepšovať produkt v priebehu času. Živé rozhovory sú stále dôležité, ale už nie sú jediným miestom, kde sa prijímajú rozhodnutia.

Spôsob, akým zapájate ľudí zvonku, tiež ovplyvňuje kvalitu. Ak s nimi zaobchádzate ako s oddeleným prúdom s nejasnými cieľmi, nebudú mať pocit plnej zodpovednosti za produkt. Ak ich pridáte do existujúcich tímov pod jedným súborom pravidiel, môžu konať ako ktorýkoľvek iný člen tímu. Niektoré spoločnosti na to používajú nastavenie rozšírenia tímu, kde kombinujú interných a externých ľudí pod jedným vedením. Spoločné ciele, spoločné nástroje a spoločné recenzie prispievajú k kvalite kódu v softvérovom vývoji viac ako akýkoľvek prísny kontrolný dokument. V priebehu času môžete upravovať zloženie ľudí a prácu, ale spoločný rámec zostáva rovnaký.