Správa závislostí: Kompletní průvodce pro projekty a produkty

Informatec Digital » Zdroje » Správa závislostí: Kompletní průvodce pro projekty a produkty

Řízení závislostí je jedním z problémů, se kterými se každý denně potýká, ale jen málo organizací se jím systematicky zabývá. Pokud není pod kontrolou, vznikají zpoždění, zdánlivě nevysvětlitelné překážky, konají se mimořádné schůzky k „hašení požárů“ a nakonec se projekty buď zpozdí, nebo vůbec nedorazí.

Naopak, když jsou závislosti identifikovány, vizualizovány a efektivně spravovány, týmy pracují autonomněji , termíny přestávají být hazardem a spolupráce mezi odděleními se stává mnohem plynulejší. V tomto článku se podrobně podíváme na to, co jsou závislosti v projektech a digitálních produktech, jaké různé typy existují a jak je v praxi spravovat pomocí agilních přístupů, frameworků jako Kanban a nástrojů, jako je Jira nebo software pro projektový management.

Co rozumíme pod pojmem závislost v projektovém a produktovém řízení?

V kontextu projektů a vývoje produktů je závislost vztah nutnosti mezi dvěma prvky práce: úkolem, týmem, technickou součástí nebo dokonce externím dodavatelem. Aby něco mohlo začít, postupovat nebo skončit, musí se nejdříve stát něco jiného.

Z velmi praktického hlediska může být závislost buď funkčním požadavkem (například nákupní košík na webu), nebo čistě technickým požadavkem (připravené API, přístup k prostředí nebo nasazení verze). I když „aktorem“ konzumujícím výsledek není osoba, ale jiná služba, stále ji označujeme jako závislost.

V projektovém řízení se úkol často popisuje jako závislý, pokud je jeho provedení podmíněno dokončením, zahájením nebo postupem jiného úkolu. Pokud „úkol B“ potřebuje, aby „úkol A“ dosáhl určitého bodu, aby mohl pokračovat, pak se jedná o závislost.

Závislosti nejsou jen nepříjemné: představují skutečná rizika . Zvyšují pravděpodobnost zpoždění, překročení nákladů a dokonce i zrušení iniciativy ještě předtím, než se dostane do produkce. Každá závislost je standardně rizikem s určitou pravděpodobností a dopadem, které by mělo být řízeno, nikoli ignorováno.

Typy závislostí: kompletní přehled

Aby bylo možné závislosti efektivně spravovat, je nutné je nejprve klasifikovat a pojmenovat . Literatura o projektovém řízení a praxe v oblasti produktů obvykle rozlišují několik os: podle jejich povahy (logické, založené na zdrojích, externí, preferenční), podle vztahu mezi úkoly a podle organizačního rozsahu.

Závislosti podle jejich povahy

Logické nebo kauzální závislosti jsou ty, které následují nevyhnutelnou posloupnost kroků . Nemůžete natřít zeď, pokud jste ji nejdříve nepostavili; nemůžete otestovat funkci, pokud nebyla nejdříve vyvinuta. Jsou nejintuitivnější.

Závislosti na zdrojích vznikají, když více úkolů nebo projektů soupeří o stejný omezený zdroj : klíčovou osobu, jednoho designéra, jeden back-endový tým, testovací stroj atd. Postup práce není určen ani tak logickým pořadím, jako spíše skutečnou dostupností těchto zdrojů.

Preferované závislosti jsou ty, které vyplývají z interních postupů nebo osvědčených postupů , ale nejsou nezbytně nutné pro dokončení výstupu. Například dodatečná redakční kontrola nebo dodatečný krok kontroly kvality, který se tým rozhodne ponechat, protože snižuje chyby, i když by projekt mohl být formálně „uzavřen“ i bez něj.

K externím závislostem dochází, když je tým vázán na faktory, které nemůže ovlivnit : dodavatel, který musí dodat materiál, právní oddělení, které musí schválit smlouvu, počasí, které ovlivňuje projekt, nebo platební brána třetí strany, která musí certifikovat svou službu.

Závislosti úkolů: klasické časové vztahy

Na úrovni plánování se závislosti úkolů obvykle modelují pomocí čtyř základních vztahů, které uvidíte v harmonogramech nebo Ganttových diagramech:

Ve vztahu Dokončit-zahájit (FS) nemůže následná úloha začít, dokud není dokončena předchozí úloha. Toto je nejběžnější vztah a ten, který většina nástrojů používá standardně.

Ve vztahu typu „dokončit-dokončit“ (FF) nemůže další úkol dokončit svou práci, dokud není dokončen i předchozí úkol . K tomu často dochází, když je úkol ve skutečnosti součtem několika vzájemně závislých dílčích úkolů.

V případě metody Start-to-Start (SS) musí být obě úlohy aktivovány paralelně . Následná úloha nemůže začít dříve než její předchůdce, i když pak budou pokračovat vlastním tempem.

Vztah mezi začátkem a koncem (SF), méně častý, ale stále existující, znamená, že úkol A nelze považovat za dokončený, dokud nezačne úkol B. Typickým příkladem je změna směny v zákaznickém servisu: jedna osoba nemůže odejít, dokud nepřijde další.

Interní, externí a mezitýmové závislosti

Kromě jejich povahy je důležité rozlišovat mezi interními závislostmi v rámci projektu (mezi úkoly nebo zdroji, které tým sám ovládá) a externími závislostmi, které závisí na třetích stranách.

Ve středních a velkých organizacích se závislosti mezi týmy stávají stále důležitějšími: když se více týmů, oddělení nebo dodavatelů musí koordinovat, aby dosáhlo společného výsledku. To zahrnuje závislosti mezi produktovými týmy, mezi týmy a mezifunkčními týmy (HR, nákup, právní oddělení) a mezi technickými týmy, jako je back-end, front-end, mobilní a provozní.

Proaktivní vs. reaktivní správa závislostí

Způsob, jakým organizace řeší závislosti, tvoří rozdíl mezi kulturou „hašení požárů“ a mnohem zdravějším prostředím. Můžeme hovořit o dvou základních strategiích : proaktivní a reaktivní.

Reaktivní správa zahrnuje reakci na závislost pouze v případě jejího narušení : když chybí oprávnění, přístup, komponenta nebo API a tým se zasekne. Toto je typická situace neustálých výpadků, přeplánování za chodu a porušených závazků.

Proaktivní řízení na druhou stranu zahrnuje věnování úsilí od samého začátku identifikaci a plánování závislostí . Potřeby jsou předvídány, kapacita je rezervována, závazky mezi týmy jsou vyjasněny a rizika jsou identifikována dříve, než se stanou problémy.

I když vždy bude existovat reaktivní složka (nelze předvídat všechno), zdravá strategie řízení závislostí musí mít silnou proaktivní složku : analýzu, stanovování priorit, přípravu alternativních scénářů a stanovení opakujících se událostí pro kontrolu stavu těchto závislostí.

Vizualizace závislostí: od Kanbanu k maticím v Jiře

Prvním vážným krokem ke správě závislostí je jejich zviditelnění pro všechny . Co není vidět, není spravováno; je to přetrváváno. Zde přicházejí na řadu Kanbanové postupy, programové nástěnky a různé vizualizace.

V systému Kanban je jednou ze základních praxí vizualizace práce . To zahrnuje jasné určení, které úkoly závisí na ostatních a které blokují ostatní týmy. Jasné označení položek, které „čekají na závislosti“, pomáhá předcházet překvapením.

V nástrojích, jako je Jira, je velmi praktickým přístupem využití pole propojení problémů k propojení úloh, které se navzájem blokují . Můžete použít vztahy „bloky“ nebo „závisí na“, které rozlišují mezi silnými závislostmi (brání spuštění závislé úlohy) a slabšími (umožňují paralelní postup, zatímco se řeší druhá).

Pokud úkol, který by měl závislost vyřešit, dosud neexistuje, můžete problém označit konkrétní značkou, která tuto nevyřešenou potřebu označuje. Tato značka vám pak umožní seskupit a zobrazit tyto nevyřešené závislosti v panelech, plánech, backlogech nebo nástěnkách.

S těmito informacemi je možné vytvořit matici závislostí, kde jedna dimenze představuje týmy nebo jednotky organizace a druhá představuje časovou osu. To ukazuje, kdo je na kom závislý a kdy, což usnadňuje alokaci kapacit a vyjednávání priorit.

Před širokým přijetím práce na dálku se tyto matice často kreslily na fyzické tabule. Dnes pluginy a moduly Jira, jako jsou Advanced Roadmaps, BigPicture a Structure, umožňují vizuální reprezentaci těchto sítí závislostí v hybridním nebo plně vzdáleném prostředí.

Rezervační kurzy a rezervační tabule v Kanbanu

Jakmile máte globální přehled o závislostech na úrovni produktu nebo organizace, můžete jít ještě o krok dále a aplikovat koncept tříd rezervací z metody Kanban k přiřazení různých úrovní služeb k řešení závislostí.

Třída rezervace se používá ke klasifikaci práce podle priority, naléhavosti nebo požadovaného času dodání. Pro použití tohoto přístupu se závislostmi se používá kalendář k alokaci kapacitních slotů vyhrazených pro jejich řešení, ať už po dnech, týdnech nebo iteracích (například sprinty ve Scrum týmech).

Obvykle existují tři hlavní typy rezerv. Zaprvé existují garantované zdroje, které mají kapacitu speciálně rezervovanou tak, aby v případě potřeby byly k dispozici k určitému datu. Ty obvykle odpovídají nepředvídaným, ale kritickým úkolům.

Druhou možností jsou rezervované závislosti: jedná se o úkoly, které již mají stanovený časový rámec pro dokončení. Často se používají pro silné závislosti, jejichž vyřešení umožňuje jinému týmu zahájit práci.

Konečně, pohotovostní závislosti spadají do kategorie, kde budou řešeny pouze tehdy, je-li k dispozici dostatečná kapacita . Obvykle se jedná o závislosti, kterým se lze dočasně vyhnout, odložit je, zatímco se pracuje na jiných částech práce.

Tento model se velmi podobá způsobu, jakým letecké společnosti spravují své letenky: existují velmi drahá garantovaná sedadla, standardní rezervace a letenky na čekací listině, které závisí na tom, zda nedojde k nadměrnému počtu rezervací. Stav místa na čekací listině se může v průběhu času dokonce změnit , a to z „na čekací listině“ na „rezervované“ nebo „garantované“, jak se blíží cílové datum a riziko se zvyšuje.

Akce pro kontrolu závislostí a koordinaci týmů

Mít rezervační tabuli nebo matici závislostí nestačí, pokud není integrována do pravidelných kontrolních rituálů . Je zásadní mít v rámci aktuálního pracovního postupu alespoň jednu událost, kde se tyto závislosti zkontrolují a provedou se úpravy.

Nemusí se jednat o novou schůzku; lze ji integrovat jako pevný bod do programu stávajících schůzek: například do schůzky plánování iterací, do plánování PI ve stylu SAFe nebo do koordinační schůzky mezi týmy.

Opravdu důležité je, aby se této kontroly zúčastnily všechny strany zapojené do vytváření a řešení závislostí . Bez této osobní konverzace (nebo konverzace mezi obrazovkami) snadno vznikají falešná očekávání, jednostranné závazky a sliby, které nelze dodržet.

Dobré a špatné závislosti: synchronní a asynchronní

Může to znít neintuitivně, ale ne všechny závislosti jsou špatné. Některé závislosti podporují zdravou spolupráci , zatímco jiné vytvářejí oddělení a neustálé tření. Užitečným způsobem, jak je rozlišovat, je hovořit o synchronních a asynchronních závislostech.

Asynchronní závislosti jsou ty, ve kterých týmy nepracují současně nebo v určitém rytmu. Příkladem problematických asynchronních závislostí je Scrum tým, který má v úmyslu integrovat do svého aktuálního sprintu vývoj, který bude jiný tým provádět v příštím sprintu, nebo urgentní požadavek na přístup k prostředku, který závisí na třetím, přetíženém týmu.

Synchronní závislosti na druhou stranu vznikají, když práce probíhá ve stejném časovém rámci . Například několik týmů sdílí vývojové a testovací prostředí nebo společnou softwarovou knihovnu otevřenou příspěvkům od jakéhokoli vývojáře ve společnosti.

Tyto typy závislostí povzbuzují lidi k aktivní spolupráci a sdílení kontextu . Bez nich by se každý tým snáze izoloval ve svém vlastním silu. A sila kromě omezení celkové perspektivy mají tendenci narušovat empatii mezi odděleními a komplikovat rozhodování na organizační úrovni.

Dlouhodobá strategie by se měla zaměřit na minimalizaci asynchronních závislostí a posílení synchronních závislostí, s upřednostňováním týmů s větší komplexní autonomií a otevřenějšími postupy spolupráce.

Návrh organizací a týmů pro snížení závislostí

Organizační struktura přímo ovlivňuje počet a typ závislostí. S růstem produktu a množením týmů se objevuje větší tření, překrývání a úzká hrdla . Problémy se obvykle začínají objevovat již u dvou týmů a s každým nově vytvořeným týmem se zhoršují.

Ve vertikálně integrovaných, produktově orientovaných organizacích je cílem obvykle vytvořit multidisciplinární týmy, které jsou co nejvíce autonomní , což je velmi podobné topologii „streamově orientovaných týmů“ popsané v části Týmové topologie. Tyto týmy jsou zodpovědné za obchodní doménu nebo subdoménu od začátku do konce.

I s autonomními týmy jsou stále potřebné mechanismy pro zajištění konzistence produktů a zabránění narušení týmové spolupráce: mimo jiné instance arbitráže globálních plánů, společné plánovací akce inspirované plánováním PI, programové desky, které vizualizují závislosti, sdílené designové systémy a komunity praxe.

V praxi mnoho společností končí s hybridními modely, kde ne všechny dovednosti lze nalézt v každém týmu . Vznikají mezioborové týmy, které pokrývají produktový design, data, QA, mobilní technologie, back-end nebo provoz a slouží více produktovým týmům, což zavádí další závislosti, které je třeba efektivně řídit.

Oddělení s mezioborovými týmy: HR, nákup, právní oddělení…

Kromě technických oblastí se mnoho týmů spoléhá na mezioborové firemní týmy, jako jsou personální oddělení, nákupní oddělení nebo právní oddělení. Tato závislost se často projevuje jako nábor klíčových pracovníků, budování kapacit prostřednictvím externích dodavatelů, správa rozpočtu nebo právní kontroly.

Když tým potřebuje podepsat nebo posílit svou soupisku a nekontroluje tento tok hráčů , je ovlivněna doba uvedení hráčů na trh a trpí předvídatelnost. K zmírnění těchto situací lze aktivovat několik pák.

Jednou z možností je delegovat určité činnosti tradičně řízené personálním oddělením nebo nákupem na týmy (například část výběrového procesu nebo provozní vztahy s dodavateli) s jasnou správou, ale menší byrokracií.

Dalším způsobem je vyjednat rozpočty na služby tak, aby každé družstvo mělo v rámci dohodnutých limitů autonomní prostor pro rozhodování o tom, které profily nebo služby a kdy najme.

Je také možné využít občasné integrace odborníků z oblasti lidských zdrojů, nákupu nebo právního oddělení do týmů k urychlení kritických rozhodnutí , zejména v době silného růstu nebo relevantních strategických změn.

Typické technické závislosti: back-end, provoz a mobilní zařízení

Na technické úrovni existují tři obzvláště běžné zdroje závislostí: samostatné back-endové týmy , izolované operační (Ops) týmy a nezávislé mobilní týmy.

Když centralizovaný back-endový tým obsluhuje více front-endových týmů, vytváří to obtížně spravovatelný vztah mezi klientem a dodavatelem . Back-endový tým musí vytvářet API pro všechny, vyvažovat externí priority, které nekontroluje, a odolávat tlaku. Produktové týmy zároveň zažívají zpoždění a frustraci z toho, že nevědí, kdy budou potřebné funkce připraveny.

Jako paliativní opatření lze dočasně integrovat back-end vývojáře do týmů , definovat jasné smlouvy o rozhraní mezi back-endem a front-endem nebo vyvinout architektury mikroslužeb, kde je každý tým zodpovědný za své vlastní služby, s akceptováním, že se objeví nové závislosti, ale mnohem lépe zvládnutelné.

V případě operačních týmů se závislost obvykle soustředí na prostředí a správu nasazení . Týmy dokončují svůj vývoj, ale potřebují operační týmy k nasazení do každého prostředí. Pokud je operační tým přetížený, vydané verze se hromadí, jejich priority jsou neprůhledné a zvyšuje se riziko pozdního nebo uspěchaného dodání.

Pro zlepšení v této oblasti lze implementovat vizuální správu toku dodávek typu Kanban, uživatelské příběhy specifické pro operační požadavky lze integrovat do backlogu týmů a lze nabídnout „továrny softwaru jako služby“, které automatizují velkou část procesu.

I tak ale skutečně významný skok nastává, když je přijata zralá kultura DevOps , kde vývoj a provoz úzce spolupracují, testování a nasazení jsou automatizované a týmy mají možnost bezpečně přenést své změny do produkčního prostředí.

Něco podobného se děje s nezávislými mobilními týmy: jejich vysoce specifické dovednosti (iOS, Android, mobilní design, pokyny pro platformu) vedou mnoho organizací k tomu, že je seskupují do jednoho týmu, který nakonec obsluhuje více družstev. To vytváří fronty, složité prioritizace a úzká hrdla, když všechny týmy požadují mobilní změny současně.

Jednou z možných strategií je udržovat tyto mobilní týmy s logikou průzkumného týmu , která doprovází jednotky, vzory značení, opakovaně použitelné komponenty a osvědčené postupy, a tuto jednotku rozpustit, jakmile se rozsah mobilních funkcí vyrovná webové verzi.

Správa softwarových závislostí: knihovny, frameworky a zabezpečení

Kromě organizace se ve vývoji softwaru slovo závislost obvykle vztahuje na externí knihovny, frameworky a komponenty , které vaše aplikace potřebuje k fungování. Zde mluvíme o správcích závislostí, jako jsou Maven, Gradle, npm nebo Composer.

Špatná správa těchto závislostí může vést ke konfliktům verzí , problémům s integrací, dlouhodobým obtížím s údržbou nebo bezpečnostním zranitelnostem. Proto je tak důležité používat nástroje, které automatizují stahování, rozlišení verzí a řízené aktualizace.

Je vhodné udržovat závislosti přiměřeně aktuální a zároveň najít rovnováhu mezi bezpečností a stabilitou. Obsesivní aktualizace mohou způsobit neočekávané chyby, ale nepravidelné aktualizace činí projekt zranitelným vůči známým zranitelnostem nebo škodlivým verzím na npm.

Je také dobrým zvykem minimalizovat počet závislostí: před přidáním nové knihovny je vhodné se zeptat, zda skutečně přináší přidanou hodnotu , nebo zda se jedná o něco, co by se dalo řešit jednodušeji. Každá přidaná závislost znamená větší plochu pro údržbu, potenciální konflikty a v mnoha případech i dopad na výkon.

To vše by mělo být doprovázeno jasnou dokumentací o tom, které závislosti se používají, s jakými verzemi a k ​​jakému účelu, a také důkladným automatizovaným testováním, které ověří, zda aktualizace nenaruší stávající funkčnost. Nástroje pro analýzu zabezpečení také pomáhají odhalovat známé zranitelnosti v přidaných závislostech.

Praktické tipy pro správu závislostí v projektech

V každodenním řízení projektů existuje řada postupů, které výrazně usnadňují udržování závislostí pod kontrolou . Několik nástrojů (Asana, Wrike, Jira atd.) se shoduje na doporučování určitých přístupů.

Zaprvé je zásadní organizovat úkoly v robustním nástroji pro řízení projektů , který umožňuje modelovat závislosti úkolů, vizualizovat časové osy a rychle zjistit, co je blokováno a proč. Tím se snižuje riziko přehlédnutí důležitých souvislostí.

Velmi užitečná je také jasná vizualizace závislostí pomocí Ganttových diagramů, plánů nebo Kanbanových tabulí . Sledování pořadí provádění a bodů blokování pomáhá týmu lépe pochopit, proč určité úkoly přicházejí před nimi nebo po nich a jak ovlivňují jejich kolegy.

Dalším kritickým aspektem je sledování potenciálních rizik souvisejících se závislostmi. V počátečních fázích projektového plánu je vhodné prodiskutovat specifická rizika závislostí : přetížení klíčových pracovníků, externí dodavatelé, čekající povolení nebo nevyřízená obchodní rozhodnutí.

A konečně, otevřená komunikace mezi zúčastněnými stranami je zásadní. Komunikace nikdy není nadbytečná při řešení závislostí: pokud někdo ví, že se zpozdí s úkolem, na kterém závisí ostatní, je nejlepší ho o tom co nejdříve informovat , aby všichni ostatní mohli upravit své plány a vyhnout se tvrdé negativní ovlivnění.

Dopad závislostí na úspěch projektu

Zvládnutí řízení závislostí má přímý dopad na úspěch projektu. Na jedné straně umožňuje komplexnější kontrolu a informovanější strategické plánování , protože projektový manažer vidí, jak všechny části do sebe zapadají, a definuje realistický pracovní příkaz.

Na druhou stranu to výrazně zlepšuje řízení času a prevenci zpoždění . Pochopením kritických sekvencí úkolů a jejich závislostí lze přesněji upravovat termíny, stanovovat priority skutečně kritických úkolů a okamžitě odhalovat důsledky přesunu úkolu.

Dobrá správa závislostí navíc pomáhá snižovat počet chyb a optimalizovat zdroje . Zabraňuje duplicitě úsilí, minimalizuje zbytečné přepracování a vytváří pořadí provádění, které omezuje prostor pro nákladné chyby.

To vše vede k větší flexibilitě a přizpůsobivosti: když jsou změny nevyhnutelné, jasná mapa závislostí vám umožňuje reorganizovat plán s menším utrpením , předvídat dopady a překonfigurovat priority s větším úsudkem.

Celkově se efektivní řízení závislostí mezi úkoly, týmy a technickými komponentami stává klíčovým faktorem úspěchu jak u jednorázových projektů, tak u průběžného vývoje komplexních digitálních produktů. Organizace, které upřednostňují autonomní týmy, jasnou vizualizaci, koordinační rituály a silnou technickou kulturu, snižují úzká hrdla, zkracují dobu uvedení produktů na trh a umožňují svým týmům pracovat s menším třením a větším zaměřením na poskytování skutečné hodnoty koncovému uživateli.