Produktový tím rastie, vývoj sa spomaľuje: čo vyriešiť skôr, než prijmete ďalších ľudí
Vývojárov pribudlo, no zmena čaká na rovnakého schvaľovateľa. Nový tím potrebuje API od pôvodného a oba čakajú na spoločné testovacie prostredie. Firma má viac rozpracovaných úloh, ale zákazník vidí výsledok neskôr. Rast produktového tímu potrebuje upraviť tok práce, rozhodovanie a zodpovednosť za celý výsledok.
Rozširovanie tímu má riešiť konkrétnu chýbajúcu schopnosť alebo kapacitu. Ak je príčinou pomalé rozhodovanie, ďalší človek v rovnakej rade problém nezmení. Najprv potrebujete vidieť, kde práca vzniká, kde čaká a čo bráni jej bezpečnému používaniu.
Modelovým príkladom je slovenská firma, ktorá rozvíja klientsky portál, internú administráciu a prepojenie na ERP. Časť dodáva vlastný tím, časť externý partner. Odporúčania pomáhajú riadiť takýto rast bez sľubu univerzálnej veľkosti tímu alebo presného násobku výkonu.
01Rozlíšte nedostatok kapacity od čakania a opráv
Vyberte niekoľko nedávnych zmien a sledujte ich od rozhodnutia po použitie. Kedy bol problém pochopený? Kedy sa začalo pracovať? Koľko času strávil výsledok v schvaľovaní, testoch alebo čakaní na iný tím? Záznam nemá hľadať vinníka, ale opakovanú prekážku.
Pri jednom type úloh môže chýbať človek s potrebnou znalosťou. Inde tím prerába zadanie po neskorom vyjadrení obchodu. Ďalšia zmena je hotová, no bez prístupu do skúšobného prostredia sa nedá preveriť. Každá situácia potrebuje iný zásah.
- Kapacita: pripravená práca čaká na dostupnú schopnosť, ktorú tím opakovane nemá.
- Rozhodovanie: chýba priorita, podklad alebo osoba oprávnená uzavrieť spornú otázku.
- Závislosť: výsledok sa bez iného tímu alebo spoločnej služby nedá dokončiť.
- Opravy: práca sa vracia pre nejasné prevzatie, neskoré testy alebo zmenu účelu.
Nábor má zodpovedať zistenej potrebe. Pri opakovaných chybách vo fakturačnom postupe môže pomôcť znalosť agendy alebo lepší test. Pri chýbajúcej vývojovej schopnosti potrebujete človeka alebo dodávateľa. Všeobecná požiadavka pridajte kapacitu tieto možnosti nerozlišuje.
02Zjednoťte cieľ a pomenujte, kto rozhoduje o poradí
Klientsky portál, administrácia a integrácia môžu mať spoločný obchodný výsledok. Napríklad zákazník vybaví zmenu objednávky bez telefonátu. Ak však každý tím optimalizuje vlastný zoznam funkcií, potrebné časti sa nemusia stretnúť včas.
Určite, kto rozhoduje o poradí práce a kto poskytuje podklady. Obchod, prevádzka a podpora majú prispieť svojou znalosťou. Nemajú však každý deň zadávať nové priority rovnakým ľuďom mimo dohodnutého postupu. Nezhodu treba vedieť uzavrieť bez ďalšieho nekonečného kola schvaľovania.
Ak používate Scrum, Scrum Guide pri viacerých tímoch na rovnakom produkte opisuje spoločný Product Goal, Product Backlog a Product Owner. Toto je konkrétne pravidlo Scrumu. Nemá sa zamieňať s tvrdením, že každý rastúci tím musí používať tento rámec.
Odlišujte plán výsledkov od nezmeniteľného zoznamu termínov. Pri dôležitom termíne označte potrebný rozsah, neistoty a závislosti. Nová požiadavka má mať dôsledok pre existujúci plán. Ak sa k nemu len pridáva ďalšia práca, firma si vytvára záväzky bez zodpovedajúcej kapacity.
K dôležitému rozhodnutiu zapíšte dôvod, podklady a dôsledok pre plán. Nový člen tímu tak nemusí spätne zisťovať, prečo sa určitá cesta zamietla. Spoločný záznam tiež obmedzí opakované porady o už uzavretej otázke. Osobné rozhovory sú užitočné, ale podstatný výsledok má zostať dostupný aj ďalším ľuďom.
03Rozdeľte zodpovednosť tak, aby tím dokázal dokončiť výsledok
Tím potrebuje vedieť, pre koho pracuje, akú časť produktu spravuje a ako jeho zmena prejde do prevádzky. Rozdelenie len podľa technológie môže vytvoriť časté odovzdávanie medzi návrhom, rozhraním a serverom. Posudzujte konkrétne závislosti skôr, než zmeníte organizačnú schému.
| Situácia | Vhodný zásah na preverenie | Riziko nevhodného zásahu |
|---|---|---|
| Každá funkcia putuje cez niekoľko úzkych skupín | Zostaviť tím so schopnosťami dokončiť ucelený pracovný postup | Nový tím iba pridá ďalšie odovzdávanie a čakanie. |
| Viaceré tímy opakovane riešia rovnakú infraštruktúru | Poskytnúť použiteľnú spoločnú službu s jasnou podporou | Platformový tím sa stane povinným schvaľovateľom každej zmeny. |
| Nový tím nevie bezpečne pracovať s konkrétnou technológiou | Dočasne odovzdať znalosť a overiť samostatné používanie | Pomoc zostane trvalým úzkym miestom bez prenosu schopnosti. |
| Kritická špecializovaná časť vyžaduje osobitnú znalosť | Dohodnúť rozhranie, zodpovednosť a spôsob požiadaviek | Každá zmena čaká na jediného človeka bez náhrady. |
Team Topologies rozlišuje spoluprácu, poskytovanie služby a dočasnú pomoc. Pri raste si preto dohodnite, ktorý vzťah potrebujete a dokedy. Spoločná služba má byť použiteľná podľa pravidiel; dočasná spolupráca má mať výsledok, po ktorom sa bežná práca zjednoduší.
Samostatnosť neznamená absenciu spoločných pravidiel. Firma stále potrebuje bezpečnosť, prevádzku a kompatibilitu. Tím však má poznať hranice svojich rozhodnutí a dostupnú pomoc. Pri náhrade člena musí dokumentácia a prevzatie umožniť pokračovať bez čakania na pôvodného autora.
04Závislosti riešte cez rozhrania, prostredia a spoločné prevzatie
Modelový nový tím upravuje objednávku v portáli. Potrebuje cenové pravidlá z ERP a stav spracovania z administrácie. Dohodnite, kto spravuje API, aké údaje prenáša a ako sa oznámi jeho zmena. Hotové tlačidlo bez fungujúceho celého postupu nie je dokončený výsledok.
Pripravte verzie rozhrania, skúšobné dáta a dostupné prostredie. Potvrďte správanie pri chybe a zodpovednosť za opravu. Ak každý test potrebuje ručne vytvorené údaje od rovnakého človeka, pri raste tímu sa čakanie predĺži. Vhodná samostatná skúška môže čakanie obmedziť.
Zjednoťte význam dokončenej práce. V Scrume je relevantná Definition of Done spoločná pre tímy na rovnakom produkte. V inom postupe tiež potrebujete dohodnúť kvalitu, bezpečnosť, testy a pripravenosť na prevádzku. Neprenechávajte integráciu a nevybavené chyby neurčitej budúcej fáze.
Mikroslužby nie sú automatickou odpoveďou na rast tímu. Rozdelenie aplikácie môže zmeniť prevádzku, sledovanie chýb a závislosti. Preverte, či konkrétna hranica pomôže samostatnému dodávaniu a či máte schopnosť ďalšie časti spravovať. Organizačný problém sa nemá iba presťahovať do siete.
05Obmedzte rozpracovanú prácu a zväčšujte dokončený výsledok
Kanban Guide opisuje riadenie rozpracovanej práce a sledovanie jej toku. Pre firmu to znamená pomenovať začiatok, koniec a pravidlá postupu. Rozpracované je aj to, čo čaká na test alebo schválenie, nielen kód práve otvorený vývojárom.
Dohodnite, koľko práce možno naraz začať a čo sa stane pri prekážke. Keď je kapacita plná, pomôžte dokončiť existujúcu úlohu. Ďalšia začatá funkcia nemusí skrátiť čas do výsledku, ak sa hromadí pred rovnakými testami.
Rozdeľujte zmeny na menšie použiteľné časti. Modelový portál môže najprv umožniť zmenu kontaktu, potom adresy a neskôr komplikovanejšiu úpravu objednávky. Každá časť má mať svoj účel a podmienky prevzatia. Rozdrobenie podľa technických vrstiev bez použiteľného výsledku môže čakanie len zakryť.
Pri urgentnej práci určite, čo sa odloží a kto zmenu schválil. Zaznamenajte jej dôvod. Ak je každá požiadavka urgentná, tím nevie plánovať a nevidí skutočné priority. Prevádzkové incidenty potrebujú postup, ktorý nezruší prehľad ostatnej práce.
06Merajte dodávanie aj kvalitu, nie aktivitu jednotlivca
Počet odpracovaných hodín a uzavretých položiek neukazuje, či zákazník dokončí svoju úlohu. Určite aj produktový výsledok, napríklad použitie nového postupu a opakované problémy podpory. Meranie má viesť k rozhodnutiu, nie iba zaplniť ďalšiu nástenku.
Aktuálne metriky DORA zahŕňajú čas od zmeny v správe verzií po nasadenie, frekvenciu nasadenia, čas obnovy po zlyhanom nasadení, podiel zlyhaných zmien a podiel nasadení vyvolaných opravou incidentu. Obnova po zlyhanom nasadení nie je všeobecný čas riešenia všetkých incidentov.
Sledujte konkrétnu aplikáciu alebo službu v čase. Neporovnávajte mechanicky dva tímy s inými produktmi ani jednotlivcov podľa počtu zmien. Spolu s výsledkom skúmajte čakanie, vek rozpracovanej úlohy a opakované opravy. Pri zlepšení rýchlosti skontrolujte aj dopad na kvalitu a prevádzku.
Začnite dostupnými údajmi a jasnou definíciou. Drahé nové meracie riešenie nemusí byť prvý krok. Ak tím nevie povedať, kde zmena čaká a kto ju dokončí, potrebujete najprv ujasniť tok práce. Presnejšia hodnota bez následného opatrenia nepomôže.
07Rast overte na jednej zmene spôsobu práce
- Zmapujte skutočný tok. Nedávne zmeny, čakanie, opravy a chýbajúce schopnosti.
- Dohodnite cieľ a zodpovednosť. Priorita, hranice tímov, spoločné pravidlá a rozhodovacie právomoci.
- Odstráňte konkrétnu prekážku. Potrebná schopnosť, použiteľné rozhranie, prostredie alebo obmedzenie rozpracovanosti.
- Overte výsledok pred ďalším rastom. Čas do použitia, kvalita, prevádzka a schopnosť tímu pokračovať samostatne.
Pri prijatí ľudí pripravte čas na ich zapracovanie. Určite sprievodcu, dostupné podklady a prvú primeranú úlohu. Existujúci tím bude časť kapacity venovať odovzdaniu znalostí. Krátkodobý pokles dodávania preto automaticky neznamená, že nový človek nepomáha.
Zmenu vyhodnoťte na porovnateľných úlohách a s vysvetlením kontextu. Ak prekážka zostala, ďalší nábor neoznačujte bez dôkazu za riešenie. Upravená zodpovednosť alebo jednoduchší spoločný postup môže byť ďalším krokom. Rast je úspešný, keď firma dokončuje potrebné výsledky udržateľne.
Pri plánovaní zahrňte podporu, správu a odstraňovanie chýb. Tím, ktorý rieši živú prevádzku, nemá celú kapacitu na nové funkcie. Pomenujte túto prácu a sledujte jej dôvody. Inak môže rozšírenie tímu iba dočasne zakryť problém, ktorý mu stále vracia nedokončené alebo nespoľahlivé zmeny.
08Časté otázky
Kedy má zmysel prijať ďalšieho vývojára?
Keď viete pomenovať pripravenú prácu a chýbajúcu schopnosť či kapacitu. Najprv odlíšte čakanie na rozhodnutia, závislosti a opakované opravy. Nový človek nevyrieši automaticky rovnaké úzke miesto.
Aká je správna veľkosť produktového tímu?
Závisí od produktu, práce a potrebných schopností. Konkrétny rámec môže mať vlastné odporúčanie, no firma má posúdiť komunikáciu a schopnosť dokončiť výsledok. Univerzálne číslo pre každý tím nie je vhodným základom.
Majú mať všetky tímy rovnaký zoznam úloh?
Potrebujú spoločné porozumenie cieľu a prioritám tam, kde pracujú na rovnakom výsledku. V Scrume má rovnaký produkt spoločný Product Backlog. Iný postup sa môže organizovať odlišne, ale nesmie skryť závislosti.
Potrebujeme pri raste platformový tím?
Najprv doložte opakovanú potrebu spoločnej služby. Má tímom pomôcť pracovať samostatne, nie schvaľovať každý krok. Pre menšiu firmu môže stačiť jednoduché spravované riešenie s jasným kontaktom.
Prečo neporovnávať výkon podľa bodov alebo počtu úloh?
Rôzne tímy majú odlišný rozsah a spôsob odhadu. Počet položiek môže rásť len rozdelením práce. Sledujte použiteľný výsledok, tok zmien a kvalitu konkrétnej aplikácie v čase.
Ako zapojiť externého dodávateľa bez ďalšieho čakania?
Dohodnite hranice, rozhrania, prístupy, prevzatie a rozhodovanie. Pripravte dostupné skúšobné prostredie a dokumentáciu. Preverte, či sa jeho časť dá začleniť a prevádzkovať bez neustálej účasti pôvodného autora.