Správa závislostí: Kompletný sprievodca pre projekty a produkty

Informatec Digital » Zdroje » Správa závislostí: Kompletný sprievodca pre projekty a produkty

Riadenie závislostí je jedným z tých problémov, s ktorými sa každý denne stretáva, ale len málo organizácií sa mu systematicky venuje. Keď nie je kontrolovaný, vznikajú oneskorenia, zdanlivo nevysvetliteľné prekážky, konajú sa núdzové stretnutia na „uhasenie požiarov“ a v konečnom dôsledku projekty buď meškajú, alebo vôbec neprídu.

Naopak, keď sú závislosti identifikované, vizualizované a efektívne riadené, tímy pracujú autonómnejšie , termíny prestávajú byť hazardom a spolupráca medzi oddeleniami sa stáva oveľa plynulejším. V tomto článku sa podrobne pozrieme na to, aké sú závislosti v projektoch a digitálnych produktoch, aké existujú rôzne typy a ako ich v praxi riadiť pomocou agilných prístupov, frameworkov ako Kanban a nástrojov ako Jira alebo softvér na riadenie projektov.

Čo rozumieme pod pojmom závislosť v projektovom a produktovom manažmente?

V kontexte projektov a vývoja produktov je závislosť nevyhnutný vzťah medzi dvoma prvkami práce: úlohou, tímom, technickou zložkou alebo dokonca externým dodávateľom. Aby niečo mohlo začať, napredovať alebo skončiť, musí sa najprv stať niečo iné.

Z veľmi praktického hľadiska môže byť závislosť buď funkčnou požiadavkou (napríklad nákupný košík na webovej stránke), alebo čisto technickou požiadavkou (mať pripravené API, prístup k prostrediu alebo nasadenie vydania). Aj keď „akter“, ktorý spotrebúva výsledok, nie je osoba, ale iná služba, stále to označujeme ako závislosť.

V projektovom riadení sa úloha často označuje ako závislá, keď je jej vykonanie podmienené dokončením, začiatkom alebo postupom inej úlohy. Ak „úloha B“ potrebuje, aby „úloha A“ dosiahla určitý bod, aby mohla pokračovať, potom ide o závislosť.

Závislosti nie sú len nepríjemnosťou: predstavujú skutočné riziká . Zvyšujú pravdepodobnosť oneskorení, prekročenia nákladov a dokonca aj zrušenia iniciatívy ešte predtým, ako sa dostane do produkcie. Každá závislosť je štandardne rizikom s určitou pravdepodobnosťou a dopadom, ktoré by sa malo riadiť, nie ignorovať.

Typy závislostí: kompletný prehľad

Pre efektívne riadenie závislostí je potrebné ich najprv klasifikovať a pomenovať . Literatúra o projektovom riadení a prax v oblasti produktov zvyčajne rozlišujú niekoľko osí: podľa ich povahy (logická, založená na zdrojoch, externá, preferenčná), podľa vzťahu medzi úlohami a podľa rozsahu organizácie.

Oddelenia podľa ich charakteru

Logické alebo kauzálne závislosti sú tie, ktoré nasledujú po nevyhnutnej postupnosti krokov . Nemôžete namaľovať stenu, ak ste ju najprv nepostavili; nemôžete otestovať funkciu, ak nebola najprv vyvinutá. Sú najintuitívnejšie.

Závislosti na zdrojoch vznikajú, keď viacero úloh alebo projektov súťaží o ten istý obmedzený zdroj : kľúčovú osobu, jedného dizajnéra, jeden back-end tím, testovací stroj atď. Pokrok práce nie je určený ani tak logickým poradím, ako skôr skutočnou dostupnosťou týchto zdrojov.

Preferované závislosti sú tie, ktoré vyplývajú z interných postupov alebo osvedčených postupov , ale nie sú nevyhnutne potrebné na dokončenie výstupu. Napríklad dodatočná redakčná kontrola alebo dodatočný krok kontroly kvality, ktorý sa tím rozhodne ponechať, pretože znižuje chyby, aj keď by projekt mohol byť formálne „uzavretý“ aj bez neho.

Externé závislosti vznikajú, keď je tím viazaný na faktory, ktoré nemôže ovplyvniť : dodávateľ, ktorý musí dodať materiál, právne oddelenie, ktoré musí schváliť zmluvu, počasie, ktoré ovplyvňuje projekt, alebo platobná brána tretej strany, ktorá musí certifikovať svoju službu.

Závislosti úloh: klasické časové vzťahy

Pri plánovaní sa závislosti úloh zvyčajne modelujú pomocou štyroch základných vzťahov, ktoré uvidíte v harmonogramoch alebo Ganttovom diagrame:

Vo vzťahu Dokončenie-začiatok (FS) nemôže následná úloha začať , kým sa nedokončí predchádzajúca úloha. Toto je najbežnejší vzťah a ten, ktorý štandardne používa väčšina nástrojov.

Vo vzťahu typu „dokončenie-dokončenie“ (FF) nemôže nasledujúca úloha dokončiť svoju prácu, kým sa nedokončí aj predchádzajúca úloha . Toto sa často stáva, keď je úloha v skutočnosti súčtom niekoľkých vzájomne závislých podúloh.

V prípade funkcie Start-to-Start (SS) musia byť obe úlohy aktivované paralelne . Nasledujúca úloha nemôže začať pred svojou predchodkyňou, aj keď potom pokračujú vlastným tempom.

Vzťah medzi začiatkom a koncom (SF), menej častý, ale stále existujúci, znamená, že úlohu A nemožno považovať za dokončenú , kým sa nezačne úloha B. Typickým príkladom je zmena zmeny v zákazníckom servise: jedna osoba nemôže odísť, kým nepríde ďalšia.

Interné, externé a medzitímové závislosti

Okrem ich povahy je dôležité rozlišovať medzi vnútornými závislosťami v rámci projektu (medzi úlohami alebo zdrojmi, ktoré tím sám kontroluje) a vonkajšími závislosťami, ktoré závisia od tretích strán.

V stredných a veľkých organizáciách sú závislosti medzi tímami čoraz dôležitejšie: keď sa viacero tímov, oddelení alebo dodávateľov musí koordinovať, aby dosiahli spoločný výsledok. Patria sem závislosti medzi produktovými tímami, medzi tímami a medzifunkčnými tímami (HR, obstarávanie, právne oddelenie) a medzi technickými tímami, ako sú back-end, front-end, mobilné a prevádzkové tímy.

Proaktívny vs. reaktívny manažment závislostí

Spôsob, akým organizácia rieši závislosti, vytvára rozdiel medzi kultúrou „hasenia požiarov“ a oveľa zdravším prostredím. Môžeme hovoriť o dvoch základných stratégiách : proaktívnej a reaktívnej.

Reaktívne riadenie zahŕňa reakciu na závislosť iba vtedy, keď dôjde k jej narušeniu : keď chýba povolenie, prístup, komponent alebo API a tím sa zasekol. Toto je typická situácia neustálych prestojov, preplánovania za chodu a porušených záväzkov.

Proaktívne riadenie na druhej strane zahŕňa venovanie úsilia od samého začiatku identifikácii a plánovaniu závislostí . Potreby sa predvídajú, kapacita sa rezervuje, záväzky medzi tímami sa objasňujú a riziká sa identifikujú skôr, ako sa stanú problémami.

Hoci vždy bude existovať reaktívna zložka (nedá sa predvídať všetko), zdravá stratégia riadenia závislostí musí mať silnú proaktívnu zložku : analýzu, stanovovanie priorít, prípravu alternatívnych scenárov a stanovenie opakujúcich sa udalostí na kontrolu stavu týchto závislostí.

Vizualizácia závislostí: od Kanbanu k maticiam v Jire

Prvým vážnym krokom v riadení závislostí je ich zviditeľnenie pre všetkých . Čo nie je vidieť, nie je riadené; je to pretrpené. Tu prichádzajú na rad praktiky Kanban, programové tabule a rôzne vizualizácie.

V systéme Kanban je jednou zo základných praktík vizualizácia práce . To zahŕňa jasné označenie toho, ktoré úlohy závisia od iných, ako aj tých, ktoré blokujú ostatné tímy. Jasné označenie položiek „čakajúcich na závislosti“ pomáha predchádzať prekvapeniam.

V nástrojoch ako Jira je veľmi praktickým prístupom využitie poľa prepojenia problémov na prepojenie úloh, ktoré sa navzájom blokujú . Môžete použiť vzťahy „bloky“ alebo „závisí od“, čím rozlišujete medzi silnými závislosťami (ktoré bránia spusteniu závislej úlohy) a slabšími (umožňujú paralelný postup počas riešenia druhej úlohy).

Ak úloha, ktorá by mala vyriešiť závislosť, ešte neexistuje, môžete problém označiť špecifickou značkou, ktorá indikuje túto nevyriešenú potrebu. Táto značka vám potom umožní zoskupiť a zobraziť tieto nevyriešené závislosti v paneloch, plánoch, nevybavených úlohách alebo nástenkách.

S týmito informáciami je možné vytvoriť maticu závislostí, kde jeden rozmer predstavuje tímy alebo družstvá organizácie a druhý predstavuje časovú os. To ukazuje, kto je na kom závislý a kedy, čo uľahčuje alokáciu kapacít a vyjednávanie o prioritách.

Pred rozsiahlym prijatím práce na diaľku sa tieto matice často kreslili na fyzických tabuliach. Dnes umožňujú pluginy a moduly Jira, ako napríklad Advanced Roadmaps, BigPicture a Structure, vizuálne znázornenie týchto sietí závislostí v hybridných alebo plne vzdialených prostrediach.

Rezervačné kurzy a rezervačná tabuľa v Kanbane

Keď získate globálny prehľad o závislostiach na úrovni produktu alebo organizácie, môžete ísť o krok ďalej a aplikovať koncept rezervačných tried z metódy Kanban na priradenie rôznych úrovní služieb k riešeniu závislostí.

Trieda rezervácie sa používa na klasifikáciu práce podľa priority, naliehavosti alebo požadovaného času dodania. Na použitie tohto prístupu so závislosťami sa používa kalendár na pridelenie kapacitných úsekov vyhradených na ich riešenie, či už podľa dní, týždňov alebo iterácií (napríklad šprinty v Scrum tímoch).

Zvyčajne existujú tri hlavné typy rezerv. Po prvé, existujú garantované zdroje, ktoré majú kapacitu špeciálne rezervovanú na zabezpečenie toho, aby v prípade potreby boli k dispozícii v konkrétnom dátume. Tieto zvyčajne zodpovedajú nepredvídaným, ale kritickým úlohám.

Druhou možnosťou sú rezervované závislosti: ide o úlohy, ktoré už majú stanovený časový rámec na dokončenie. Často sa používajú pre silné závislosti, ktorých vyriešenie umožňuje inému tímu začať pracovať.

Nakoniec, závislosti v pohotovostnom režime patria do kategórie, kde sa budú riešiť iba v prípade dostatočnej kapacity . Zvyčajne ide o závislosti, ktorým sa možno dočasne vyhnúť, odložiť ich, kým sa nedosiahne pokrok v iných častiach práce.

Tento model sa veľmi podobá spôsobu, akým letecké spoločnosti spravujú svoje letenky: existujú veľmi drahé garantované miesta, štandardné rezervácie a letenky na čakacej listine, ktoré závisia od toho, či nedochádza k prekročeniu počtu miest. Miesto na čakacej listine môže dokonca časom zmeniť svoj status , a to z „na čakacej listine“ na „rezervované“ alebo „garantované“, keď sa blíži cieľový dátum a riziko sa zvyšuje.

Podujatia na preskúmanie závislostí a koordináciu tímov

Mať rezervačnú tabuľu alebo maticu závislostí nestačí, ak nie je integrovaná do pravidelných kontrolných rituálov . Je nevyhnutné mať v rámci aktuálneho pracovného postupu aspoň jednu udalosť, kde sa tieto závislosti preskúmajú a vykonajú sa úpravy.

Nemusí to byť nové stretnutie; môže byť integrované ako pevný bod do programu existujúcich stretnutí: napríklad na stretnutí plánovania iteracií, v plánovaní PI v štýle SAFe alebo na koordinačnom stretnutí medzi tímami.

Skutočne dôležité je, aby boli počas tejto kontroly prítomné všetky strany zapojené do vytvárania a riešenia závislostí . Bez tejto osobnej konverzácie (alebo konverzácie medzi obrazovkami) ľahko vznikajú falošné očakávania, jednostranné záväzky a sľuby, ktoré sa nedajú dodržať.

Dobré a zlé závislosti: synchrónne a asynchrónne

Môže to znieť neintuitívne, ale nie všetky závislosti sú zlé. Niektoré závislosti podporujú zdravú spoluprácu , zatiaľ čo iné vytvárajú izolácie a neustále trenie. Užitočným spôsobom, ako ich rozlišovať, je hovoriť o synchrónnych a asynchrónnych závislostiach.

Asynchrónne závislosti sú tie, v ktorých tímy nepracujú súčasne alebo v rovnakej rytmike. Príkladmi problematických asynchrónnych závislostí sú Scrum tím, ktorý má v úmysle integrovať do svojho aktuálneho Sprintu vývoj, ktorý bude iný tím robiť v ďalšom Sprinte, alebo urgentná žiadosť o prístup k zdroju, ktorý závisí od tretieho, preťaženého tímu.

Synchrónne závislosti na druhej strane vznikajú, keď sa práca vykonáva v rovnakom časovom rámci . Napríklad niekoľko tímov zdieľa vývojové a testovacie prostredie alebo spoločnú softvérovú knižnicu otvorenú pre príspevky od akéhokoľvek vývojára v spoločnosti.

Tieto typy závislostí povzbudzujú ľudí k aktívnej spolupráci a zdieľaniu kontextu . Bez nich by bolo pre každý tím jednoduchšie izolovať sa vo svojom vlastnom sile. A silá okrem obmedzenia celkovej perspektívy majú tendenciu narúšať empatiu medzi oddeleniami a komplikovať rozhodovanie na organizačnej úrovni.

Dlhodobá stratégia by sa mala zamerať na minimalizáciu asynchrónnych závislostí a posilnenie synchrónnych závislostí, pričom by sa mali uprednostňovať tímy s väčšou komplexnou autonómiou a otvorenejšími postupmi spolupráce.

Navrhovanie organizácií a tímov na zníženie závislostí

Organizačná štruktúra priamo ovplyvňuje počet a typ závislostí. S rastom produktu a množením tímov sa objavuje viac trenia, prekrývania a úzkych miest . Problémy sa zvyčajne začínajú objavovať už s dvoma tímami a s každým novým vytvoreným tímom sa zintenzívňujú.

Vo vertikálne integrovaných, produktovo orientovaných organizáciách je cieľom zvyčajne vytvoriť multidisciplinárne tímy, ktoré sú čo najautonómnejšie , čo je veľmi v súlade s topológiou „stream-line teams“ opísanou v časti Team topologies. Tieto tímy sú zodpovedné za obchodnú doménu alebo subdoménu od začiatku do konca.

Aj pri autonómnych tímoch sú stále potrebné mechanizmy zosúladenia , aby sa zabezpečila konzistencia produktov a zabránilo sa narušeniu tímovej spolupráce: okrem iných mechanizmov sú potrebné globálne arbitrážne inštancie plánovacích plánov, spoločné plánovacie podujatia inšpirované plánovaním PI, programové rady, ktoré vizualizujú závislosti, zdieľané dizajnové systémy a komunity praxe.

V praxi mnoho spoločností končí s hybridnými modelmi, kde nie všetky zručnosti možno nájsť v každom tíme . Vznikajú medzifunkčné tímy, ktoré pokrývajú produktový dizajn, dáta, QA, mobilné technológie, back-end alebo prevádzku a slúžia viacerým produktovým tímom, čo prináša ďalšie závislosti, ktoré je potrebné efektívne riadiť.

Oddelenia s medzifunkčnými tímami: HR, nákup, právne…

Okrem technických oblastí sa mnoho tímov spolieha na medzifunkčné firemné tímy, ako sú ľudské zdroje, obstarávanie alebo právne oddelenie. Tieto závislosti sa často prejavujú ako kľúčové nábory, budovanie kapacít prostredníctvom externých dodávateľov, riadenie rozpočtu alebo právne kontroly.

Keď tím potrebuje podpísať alebo posilniť svoju zostavu a nekontroluje tento tok , je ovplyvnený čas uvedenia hráčov na trh a trpí predvídateľnosť. Na zmiernenie týchto situácií je možné aktivovať niekoľko pák.

Jednou z možností je delegovať určité činnosti, ktoré tradične riadilo oddelenie ľudských zdrojov alebo nákupu , na tímy (napríklad časť výberového procesu alebo operačný vzťah s dodávateľmi) s jasnou správou, ale s menšou byrokraciou.

Ďalším spôsobom je vyjednávať rozpočty na služby tak, aby každé družstvo malo autonómnu rozhodovaciu rezervu o tom, ktoré profily alebo služby si najme a kedy, v rámci dohodnutých limitov.

Je tiež možné využiť občasnú integráciu odborníkov z oblasti ľudských zdrojov, nákupu alebo právneho oddelenia do tímov na urýchlenie kritických rozhodnutí , najmä v časoch silného rastu alebo relevantných strategických zmien.

Typické technické závislosti: back-end, prevádzka a mobilné zariadenia

Na technickejšej úrovni existujú tri obzvlášť bežné zdroje závislostí: samostatné back-endové tímy , izolované operačné (Ops) tímy a nezávislé mobilné tímy.

Keď centralizovaný back-endový tím obsluhuje viacero front-endových tímov, vytvára to ťažko spravovateľný vzťah medzi klientom a dodávateľom . Back-endový tím musí vytvárať API pre všetkých, vyvažovať externé priority, ktoré nekontroluje, a odolávať tlaku. Produktové tímy zároveň zažívajú oneskorenia a frustráciu z toho, že nevedia, kedy budú potrebné funkcie pripravené.

Ako paliatívne opatrenia možno dočasne integrovať back-endových vývojárov do tímov , definovať jasné zmluvy o rozhraní medzi back-endom a front-endom alebo vyvinúť architektúry mikroslužieb, kde každý tím zodpovedá za svoje vlastné služby, pričom sa akceptuje, že sa objavia nové závislosti, ale oveľa lepšie zvládnuteľné.

V prípade operačných tímov sa závislosť zvyčajne sústreďuje na prostredie a správu nasadenia . Tímy dokončia svoj vývoj, ale potrebujú operácie na nasadenie do každého prostredia. Ak sú operácie preťažené, vydania sa hromadia, ich priority sú neprehľadné a zvyšuje sa riziko oneskoreného alebo uponáhľaného dodania.

Na zlepšenie v tejto oblasti je možné implementovať vizuálnu správu toku dodávok typu Kanban, do backlogu tímov je možné integrovať používateľské príbehy špecifické pre požiadavky operácií a ponúknuť „továrne na softvér ako službu“, ktoré automatizujú veľkú časť procesu.

Napriek tomu skutočne významný skok nastáva, keď sa prijme zrelá kultúra DevOps , kde vývoj a prevádzka úzko spolupracujú, testovanie a nasadzovanie sú automatizované a tímy majú možnosť bezpečne preniesť svoje zmeny do produkčného prostredia.

Niečo podobné sa deje aj s nezávislými mobilnými tímami: ich vysoko špecifické zručnosti (iOS, Android, mobilný dizajn, pravidlá platformy) vedú mnoho organizácií k tomu, aby ich zoskupili do jedného tímu, ktorý nakoniec obsluhuje viacero tímov. To vytvára fronty, zložité stanovovanie priorít a úzke miesta, keď všetky tímy súčasne žiadajú o mobilné zmeny.

Jednou z možných stratégií je udržiavať tieto mobilné tímy s logikou prieskumného tímu , ktorá sprevádza družstvá, vzory označovania, opakovane použiteľné komponenty a osvedčené postupy, a rozpustiť túto jednotku, keď sa rozsah mobilnej funkcie vyrovná webovej verzii.

Správa softvérových závislostí: knižnice, frameworky a bezpečnosť

Okrem organizácie sa vo vývoji softvéru slovo závislosť zvyčajne vzťahuje na externé knižnice, frameworky a komponenty , ktoré vaša aplikácia potrebuje na fungovanie. Hovoríme tu o správcoch závislostí, ako sú Maven, Gradle, npm alebo Composer.

Zlá správa týchto závislostí môže viesť ku konfliktom verzií , problémom s integráciou, ťažkostiam s dlhodobou údržbou alebo bezpečnostným zraniteľnostiam. Preto je také dôležité používať nástroje, ktoré automatizujú sťahovanie, riešenie verzií a kontrolované aktualizácie.

Je vhodné udržiavať závislosti primerane aktuálne a hľadať rovnováhu medzi bezpečnosťou a stabilitou. Obsesívne aktualizácie môžu spôsobiť neočakávané chyby, ale zriedkavé aktualizácie spôsobujú, že projekt je zraniteľný voči známym zraniteľnostiam alebo škodlivým verziám na npm.

Dobrým zvykom je minimalizovať počet závislostí: pred pridaním novej knižnice sa oplatí položiť si otázku, či skutočne prináša pridanú hodnotu , alebo či ide o niečo, čo by sa dalo riešiť jednoduchšie. Každá pridaná závislosť znamená viac údržbárskej plochy, potenciálne konflikty a v mnohých prípadoch aj vplyv na výkon.

Toto všetko by malo byť sprevádzané jasnou dokumentáciou o tom, ktoré závislosti sa používajú, s ktorými verziami a na aký účel, ako aj dôkladným automatizovaným testovaním na overenie, či aktualizácia nenaruší existujúcu funkcionalitu. Nástroje na analýzu zabezpečenia tiež pomáhajú odhaliť známe zraniteľnosti v pridaných závislostiach.

Praktické tipy na správu závislostí v projektoch

V každodennom riadení projektov existuje množstvo postupov, ktoré výrazne uľahčujú udržiavanie závislostí pod kontrolou . Niekoľko nástrojov (Asana, Wrike, Jira atď.) sa zhoduje na odporúčaní určitých prístupov.

Po prvé, je nevyhnutné organizovať úlohy v robustnom nástroji na riadenie projektov , ktorý vám umožňuje modelovať závislosti úloh, vizualizovať časové harmonogramy a rýchlo vidieť, čo je blokované a prečo. To znižuje riziko prehliadnutia dôležitých prepojení.

Veľmi užitočná je aj jasná vizualizácia závislostí pomocou Ganttovho diagramu, plánu alebo Kanban tabule . Zobrazenie poradia vykonávania a bodov blokovania pomáha tímu lepšie pochopiť, prečo určité úlohy prichádzajú pred nimi alebo po nich a ako ovplyvňujú ich kolegov.

Ďalším kritickým aspektom je monitorovanie potenciálnych rizík súvisiacich so závislosťami. V počiatočných fázach projektového plánu je vhodné brainstormingovať špecifické riziká závislostí : preťaženie kľúčového personálu, externí dodávatelia, čakajúce povolenia alebo nevyriešené obchodné rozhodnutia.

Napokon, otvorená komunikácia medzi zainteresovanými stranami je nevyhnutná. Komunikácia nikdy nie je zbytočná pri riešení závislostí: ak niekto vie, že sa oneskorí pri úlohe, na ktorej závisia ostatní, je najlepšie ho o tom čo najskôr informovať , aby si všetci ostatní mohli upraviť plány a vyhli sa tvrdému dopadu.

Vplyv závislostí na úspešnosť projektu

Zvládnutie riadenia závislostí má priamy vplyv na úspech projektu. Na jednej strane umožňuje komplexnejšiu kontrolu a informovanejšie strategické plánovanie , pretože projektový manažér vidí, ako všetky časti do seba zapadajú, a definuje realistický pracovný príkaz.

Na druhej strane to výrazne zlepšuje riadenie času a predchádzanie oneskoreniam . Pochopením kritických postupností úloh a závislostí je možné presnejšie upraviť termíny, stanoviť priority skutočne kritických úloh a okamžite odhaliť dôsledky presunutia úlohy.

Okrem toho, dobrá správa závislostí pomáha znižovať chyby a optimalizovať zdroje . Zabraňuje duplicite úsilia, minimalizuje zbytočné prepracovanie a vytvára poradie vykonávania, ktoré obmedzuje priestor pre nákladné chyby.

Toto všetko vedie k väčšej flexibilite a prispôsobivosti: keď sú zmeny nevyhnutné, jasná mapa závislostí vám umožňuje reorganizovať plán s menším utrpením , predvídať dopady a prekonfigurovať priority s väčším úsudkom.

Celkovo sa efektívne riadenie závislostí medzi úlohami, tímami a technickými komponentmi stáva kľúčovým faktorom úspechu v jednorazových projektoch aj v prebiehajúcom vývoji komplexných digitálnych produktov. Organizácie, ktoré uprednostňujú autonómne tímy, jasnú vizualizáciu, koordinačné rituály a silnú technickú kultúru, znižujú úzke miesta, zlepšujú čas uvedenia na trh a umožňujú svojim tímom pracovať s menším trením a väčším zameraním na poskytovanie skutočnej hodnoty koncovému používateľovi.