Rozšiřování vývojového týmu o externí inženýry bez ztráty kvality kódu

Úvod

Hlavní body

1. Využijte externí inženýry, když je váš plán příliš nabitý pro váš hlavní tým.
2. Než se připojí, nastavte jednoduchá pravidla kvality a základní postup dodávek.
3. Zapojte externí vývojáře pomocí jasného kontrolního seznamu a jednoho kontaktního partnera.
4. Pro všechny inženýry používejte jeden společný soubor pravidel, kontrol a metrik.
5. Spoléhejte se na krátké písemné aktualizace, abyste udrželi rostoucí smíšený tým v souladu.

Proč byste měli rozšířit svůj vývojový tým o externí inženýry?

Měli byste rozšířit svůj vývojový tým o externí inženýry, když máte plný plán a vaši vlastní lidé nestačí zdravým tempem držet krok. Hlavní bod je jednoduchý: externí inženýři by měli zvýšit rychlost a dovednosti, aniž by snížili vaši laťku kvality. Pokud vám pomáhají dodávat stabilní práci, kterou lze bezpečně udržovat, má takové řešení smysl. Pokud však přinášejí pouze stres a náhodné změny, není na to vhodná doba.

Mnoho vedoucích pracovníků v produktových společnostech pociťuje stejný tlak. Backlog roste, termíny se posouvají a najímání silných inženýrů ve vašem městě trvá dlouho. V tu chvíli začnete uvažovat o rozšíření inženýrského týmu s pomocí zvenčí. Můžete se podívat na outsourcovaný vývojový tým v jiné oblasti nebo na menší skupinu blíže vašemu časovému pásmu. Skutečnou otázkou není, zda můžete přivést externí pomoc, ale kdy podpoří váš plán, místo aby zakrývala hlubší problémy.

Jedním z důvodů, proč přizvat externí inženýry, je přístup k dovednostem, které momentálně ve firmě nemáte. Možná potřebujete krátkodobou podporu v oblastech, jako jsou data, mobilní aplikace nebo nové cloudové nastavení. Možná nechcete budovat zcela nový tým pro každé nové téma. V takovém případě vám rozšíření softwarového vývojového týmu může poskytnout flexibilní vrstvu podpory kolem vaší hlavní skupiny. Základní znalosti a směr udržíte uvnitř své společnosti a externí pomoc využijete pro jasné a zaměřené části práce. V každodenním životě to připomíná spíše přidání jednoho klidného odborníka do rušného týmu než vytvoření druhé společnosti.

Existuje také velmi základní časový a nákladový úhel pohledu. Najímání silných lidí na vlastní pěst může trvat mnoho týdnů nebo dokonce měsíců a během této doby se vaše nevyřízené úkoly nezastaví. Zde můžete vidět jasné výhody rozšíření personálu IT. Můžete si najmout další pracovníky na definovanou dobu a v definovaném rozsahu, zatímco budete přemýšlet o dlouhodobém najímání. Pro některé týmy tato možnost vyrovnává špičky v poptávce, místo aby nutila k velkému nárůstu fixního počtu zaměstnanců. Tento typ uspořádání vám umožňuje otestovat, co extra kapacita přináší vašemu produktu, než definitivně změníte celou strukturu.

Můžete si také vybrat různé modely, jak tito lidé vstoupí do vašeho světa. V modelu personálního posílení přidáte externí inženýry do svého vlastního týmu a vaši vedoucí budou každý den řídit jejich práci. V rámci nearshore vývojového týmu pracují lidé v podobném časovém pásmu a mohou se připojit k vašim hovorům a chatům v běžných hodinách. Mnoho společností spolupracuje se zkušeným partnerem v oblasti vývoje softwaru, který již ví, jak provádět nearshore vývoj softwaru a jak se začlenit do interních týmů. Čím blíže jsou si kultura, časové pásmo a nástroje, tím snazší je, aby se mnoho lidí cítilo jako jeden tým, i když se smlouvy liší. Tato společná základna je to, co způsobuje, že externí práce působí přirozeně, nikoli křehce.

Jak připravíte svůj kód a procesy před přidáním externího vývojového týmu?

Na externí vývojový tým se připravíte tím, že nastavíte jasný a jednoduchý základ pro to, jak svůj produkt vytváříte a dodáváte. Než přijdou noví lidé, potřebujete společná pravidla, základní nástroje a viditelný způsob práce. Bez tohoto základu závisí každá změna na osobním stylu a paměti a noví lidé nemají jak odhadnout správnou cestu. S tímto základem se i noví lidé mohou pohybovat v bezpečném a stabilním rytmu.

Tuto základnu si můžete představit jako kvalitní ochranné zábradlí pro kód. Tato zábradlí jsou jednoduché kontroly, kterými musí projít každá změna, bez ohledu na to, kdo ji napsal. Mohou zahrnovat způsob pojmenování věcí, formátování souborů a význam pojmu „hotovo“ pro jakoukoli malou část práce. Když zábradlí zůstávají pro všechny stejná, váš produkt působí stabilně, i když se tým rozrůstá a mění. Díky tomu je snazší důvěřovat celému toku, nejen lidem, které již znáte.

Potřebujete také základní kontinuální integraci a dodávací pipeline. Tato dlouhá fráze popisuje jednoduchou myšlenku. Pokaždé, když někdo změní kód, systém provede kontroly a pomůže tuto změnu přenést k uživatelům v malých, bezpečných krocích. Tento proces může fungovat na běžných platformách a může být spuštěn při každém odeslání do vašeho hlavního úložiště kódu. Funkční proces promění mnoho malých úprav v čistou linii pokroku namísto hromady velkých, děsivých vydání. Noví lidé se mohou tuto cestu naučit jednou a pak ji následovat bez zbytečného hádání.

Testy jsou klíčovou součástí této cesty. Automatizované testování v CI/CD znamená, že vaše testy se spouštějí samy pokaždé, když někdo sdílí nový kód. Můžete začít s jednoduchými kontrolami, které pokrývají nejpoužívanější cesty ve vašem produktu. Postupem času můžete přidávat další testy, jakmile zjistíte, kde se chyby obvykle objevují. I malá sada stabilních testů vám poskytne větší bezpečnost než obrovský seznam ručních kontrol, které nikdo nestihne provést včas. Tento přístup udržuje věci v reálném stavu a podporuje interní i externí inženýry.

Pomáhá také podívat se na starší části vašeho systému, než požádáte ostatní, aby se jich dotkli. Zde přichází na řadu základní správa technického dluhu. Technický dluh je způsob, jak popsat kód, který funguje, ale je obtížné jej změnit bez rizika. Můžete označit oblasti, které jsou bezpečné pro nové lidi, a oblasti, které stále vyžadují péči vašich nejzkušenějších zaměstnanců. Když víte, kde se nacházejí rizikové části, můžete externí vývojový tým nejprve nasměrovat do bezpečnějších oblastí. Tím chráníte svůj produkt a chráníte nové lidi před skrytými nástrahami.

Poslední částí základu je jednoduchá bezpečnost a přístup. Bezpečný životní cyklus vývoje softwaru zní složitě, ale spočívá na jasných krocích. Lidem poskytujete pouze přístup, který potřebují, chráníte skutečná uživatelská data a s tajnými klíči zacházíte opatrně. Také si zapisujete, co dělat, když se něco pokazí, i když jde o malý problém. Když je bezpečnost součástí běžné práce, externí inženýři se mohou zapojit do vašeho procesu, aniž by vyvolávali nové obavy. Vaše právní a bezpečnostní týmy také vidí, že tento růst je v souladu s plánem, a nejde o rychlé řešení.

Jak vypadá bezpečný plán zapracování externích vývojářů?

Bezpečný plán zapracování externích vývojářů jim poskytuje kontext, nástroje a jasné první kroky, aniž by je vrhá do hluboké vody. Měl by působit jako vedená cesta, kde každý den má jednoduchý a reálný účel. Když je plán jasný, noví lidé mohou přinést přidanou hodnotu během týdnů, nikoli měsíců, a váš vlastní tým se necítí vyčerpaný neustálými dotazy.

Začlenění externích vývojářů začíná společným pohledem na to, co se musí nejprve naučit. To zahrnuje váš produkt, vaše uživatele a váš běžný způsob práce. Kontrolní seznam pro zapracování vývojářů může všechny tyto položky obsahovat na jednom místě. Může být uložen v jednoduchém dokumentu, který mohou obě strany otevřít a upravit. Viditelný kontrolní seznam mění „Myslím, že jsme jim to už řekli“ na „Víme přesně, co je hotové a co je další na řadě“. Tato malá změna odstraní spoustu tichého stresu pro všechny.

Zde je jeden jednoduchý seznam, který často dobře funguje jako základ pro takový kontrolní seznam:

1. Přístup ke kódu, sledování práce a hlavním chatovacím místnostem.
2. Kroky pro spuštění produktu na notebooku nebo testovacím serveru.
3. Krátký průvodce pro uživatele, hlavní toky a klíčová obchodní pravidla.
4. Jména osob, na které se můžete obrátit s dotazy ohledně produktu, kódu a nástrojů.
5. Dvě nebo tři malé, jasné úkoly připravené pro první skutečnou změnu.

Pomáhá také jmenovat jasnou kontaktní osobu. Technický vedoucí nebo senior inženýr může během prvních týdnů fungovat jako onboardingový buddy. Tato osoba může zkontrolovat všechny počáteční změny, odpovědět na otázky a vysvětlit, proč minulá rozhodnutí vypadají tak, jak vypadají. Krátké denní kontroly, i když jen pětiminutové v chatu, mohou udržet věci na správné cestě. Klidný parťák a pravidelné kontaktní body přispívají k bezpečnému zapracování více než velká řeč první den. Postupem času můžete více aktualizací přesunout do asynchronní komunikace pro vývojové týmy, například krátké písemné poznámky.

Z mých zkušeností vyplývá, že největším rizikem během zapracování je tichá zmatenost. Noví lidé se bojí, že se ptají příliš, a starší členové týmu doufají, že se věci „vyřeší“ samy. Jasný plán pro zapracování externích vývojářů a jediný vlastník tohoto plánu tuto situaci mění. Když je za celý proces zodpovědná jedna osoba, můžete odhalit vzorce, opravit slabá místa a každé další zapracování tak proběhne hladčeji. Za několik měsíců se plán stane opakovatelným aktivem namísto nové výzvy pokaždé, když přijmete někoho nového.

Jak udržujete kvalitu kódu ve smíšeném vývojovém týmu, když řídíte externí vývojáře?

Kvalitu kódu ve smíšeném vývojovém týmu udržujete pomocí stejných jednoduchých pravidel, kontrol a čísel pro všechny. Vaše standardy musí platit pro všechny inženýry, pokud chcete, aby produkt působil jako jeden čistý a bezpečný systém. Jakmile rozdělíte pravidla podle typu smlouvy, rozdělíte také důvěru a jasnost ve svém týmu.

Smíšený vývojový tým je skupina, ve které interní a externí inženýři pracují na stejném produktu. Mohou sedět na různých místech, ale sdílejí jeden backlog a jeden úložiště kódu. Tato kombinace může být velmi silná, protože spojuje hluboké znalosti dané oblasti s novými pohledy. Může být také křehká, pokud každá skupina následuje své vlastní zvyky. Bez jasného vedení se tato kombinace promění v klastry kódu, které se liší a mezi nimiž je obtížné se pohybovat. To je okamžik, kdy kvalita a rychlost začínají upadat.

Zde pomáhají jednoduché osvědčené postupy pro revizi kódu. Každá změna by měla projít revizí alespoň jednou další osobou, bez ohledu na to, kdo ji provedl. Revize by se měly zaměřit na srozumitelnost, bezpečnost a soulad se zbytkem systému, nejen na styl. Můžete to podpořit jednoduchými nástroji, které skenují kód a hledají běžné problémy. Tyto rutiny udržují kvalitu kódu externích vývojářů v souladu se zbytkem vašeho týmu klidným a opakovatelným způsobem. Lidé se od sebe navzájem učí a budují společný smysl pro to, co je „dobré“.

Můžete také sledovat malou sadu metrik týmu pro vývoj softwaru. Ty mohou ukázat, jak dlouho trvá dokončení určité práce, kolik problémů se dostane k uživatelům a jak často dodáváte. Nepotřebujete desítky čísel. Stačí jen několik, které můžete snadno přečíst a prodiskutovat. Pokud tyto metriky zůstávají stabilní nebo se zlepšují, zatímco řídíte externí vývojáře a rozšiřujete tým, víte, že vaše nastavení podporuje kvalitu. Pokud se zhorší, máte včasný signál k přezkoumání svých pravidel, rozsahu nebo kombinace úkolů.

Komunikační vzorce jsou stejně důležité jako pravidla a čísla. Mnoho smíšených vývojových týmů se také považuje za distribuované agilní týmy, protože lidé pracují z několika míst nebo časových pásem. Potřebují asynchronní komunikaci pro vývojové týmy, aby pokrok nezávisel na dlouhých hovorech. Krátké písemné aktualizace, jasné poznámky k úkolům a jednoduché značky pro stav velmi pomáhají. Dobré písemné aktualizace usnadňují všem inženýrům připojit se, sledovat a vylepšovat produkt v průběhu času. Živé rozhovory jsou stále důležité, ale již nejsou jediným místem, kde se rozhoduje.

Způsob, jakým zapojujete externí osoby, také ovlivňuje kvalitu. Pokud s nimi zacházíte jako s odděleným proudem s nejasnými cíli, nebudou mít pocit plného vlastnictví produktu. Pokud je přidáte do stávajících týmů pod jedním souborem pravidel, mohou se chovat jako kterýkoli jiný člen týmu. Některé společnosti k tomu používají nastavení rozšíření týmu, kde kombinují interní a externí osoby pod jedním vedením. Společné cíle, společné nástroje a společné recenze přispívají ke kvalitě kódu ve vývoji softwaru více než jakékoli přísné kontrolní dokumenty. V průběhu času můžete upravovat složení lidí a práci, ale společný rámec zůstává stejný.