Programování

Budování modelu dodavatelského řetězce softwaru

Standardní zobrazení hodnotového proudu vývoje softwaru začíná kódováním a končí kódem ve výrobě. Často vidíte vývojové diagramy, které začínají „obchodem“ a končí „zákazníkem“. Toto zobrazení však přesně neodráží složitost dodávky softwaru v podnikovém měřítku.

Pokud se vrátíte o krok zpět, uvidíte mnohem více aktivit při dodávání softwaru zákazníkům, ale současné přístupy ke správě těchto aktivit jsou zakořeněny v rámci poskytování služeb, nikoli v produkčních modelech. Jako takové nespojují všechny činnosti, které jsou zapojeny, jako jediný end-to-end systém.

Model používaný v jiných výrobních odvětvích je model dodavatelského řetězce a jeho uplatněním v dodávce softwaru můžete rozšířit své chápání „systému“ dodávajícího software nad rámec devops a poskytnout vám nový pohled na to, jak jej optimalizovat.

Co je to dodavatelský řetězec?

Dodavatelský řetězec začíná myšlenkou, že můžete koordinovat všechny výrobní a neproduktivní činnosti jako jeden systém. Řízení dodavatelského řetězce je často mylně chápáno jako jednoduše „řízení dodavatelů“, i když ve skutečnosti jde pouze o jeden aspekt řízení dodavatelského řetězce (i když kritický).

Všechny podniky v oblasti produktů a služeb mají dodavatelský řetězec a příslušné činnosti a jejich relativní význam pro systém dodavatelského řetězce se budou lišit. Hlavní myšlenkou však je, že při koordinaci těchto aktivit jako jediného systému získáte hodnotu větší než součet částí a efektivně dodáte tuto hodnotu zúčastněným stranám.

Následující činnosti jsou jen několika důležitými aspekty všech dodavatelských řetězců, ale u softwaru jsou prováděny jedinečně:

Plánování

V tradičním dodavatelském řetězci zahrnují plánovací činnosti koordinaci aktiv a optimalizaci toku procesů za účelem vyvážení nabídky materiálů s poptávkou po produktech. V dodavatelském řetězci softwaru zahrnuje tato koordinace zajištění vývoje správného kódu pro funkce produktu, které jsou nejvíce potřebné. Ve velkém měřítku, se stovkami aplikací a tisíci vývojářů softwaru, se jedná o monumentální úsilí.

Rozsah plánovacích aktivit je často minimalizován existujícími devops modely. Je tedy poněkud ironické, že velké podniky, které nejvíce potřebují devop, se musí potýkat s právními, regulačními, smluvními a zákaznickými povinnostmi, díky nimž je plánování zdlouhavé a složité. Přístup k plánování dodavatelského řetězce zahrnuje optimalizaci rozhraní mezi mnoha různými plánovacími rolemi a disciplínami a klíčovým faktorem úspěchu je schopnost je efektivně integrovat.

Na jedné straně jsou agilní metodiky, které řídí vývoj v podniku, často formovány uvnitř vodopádových procesů. Jen málo podniků může uniknout cyklům fiskálního plánování a agilní procesy mohou obsahovat abstrakce, které jsou v rozporu s těmito cykly; například sprinty nemusí odpovídat hranicím fiskálních čtvrtí. Nedostatek komunikace a propojení mezi vývojovými procesy využívajícími agilní a neproduktivní aktivity využívající vodopád může vést k plýtvání a neefektivnosti v celém podnikání.

Na druhé straně plánování podnikových produktů vždy zahrnovalo rozsáhlé systémy správy požadavků a sledovatelnosti, a u softwarových produktů se to nijak neliší. Správa požadavků je obzvláště důležitá ve vysoce regulovaných odvětvích, jako je zdravotnictví, kde může být vyvinut software pro zdravotnické prostředky, který může pro uživatele znamenat život nebo smrt. Správa požadavků zahrnuje specializované nástroje a metodiky a schopnost sledovat věrnost a kvalitu jejich implementace v průběhu životního cyklu vývoje může být pro podnikové softwarové produkty klíčová.

Získávání

V tradičním dodavatelském řetězci zahrnuje získávání komponent řízení vztahů s dodavateli a vývoj strategií nákupu dílů a materiálů. Software také do značné míry závisí na zdrojových komponentách - podle nedávného výzkumu společnosti Sonatype nyní open source tvoří většinu softwarových produktů: až 80 až 90 procent kódu v moderních aplikacích pochází z komponent open source. A tyto komponenty vytvářejí jedinečné výzvy pro správu.

Za prvé, může být obtížné rozhodnout, jak určit kvalitu komponent, s mnoha faktory ovlivňujícími rozhodnutí, jako je spotřebnost, testování, dokumentace, komunita, podpora a trendy v technologii. Jasná strategie a přístup k výběru komponent je nezbytný.

Zadruhé, vzhledem k počtu bublin komponent s otevřeným zdrojovým kódem je výzvou i to, že vědí, co všechno jim umožňuje, aby je všechny efektivně spravoval. Produktoví manažeři a inženýři musí věnovat zvláštní pozornost problémům s licencí a bezpečnostním problémům. Stav vašich komponent open source se může každý den měnit, protože jsou objevovány nové chyby zabezpečení a správci mění své strategie duševního vlastnictví. A zákazníci chtějí přesně vědět, co dostávají - mnoho velkých podniků si nebude kupovat software bez kusovníku s popisem toho, co je v krabici. Správa všech těchto problémů s otevřeným zdrojovým kódem je klíčovým aspektem vývoje softwarových produktů.

Rozdělení

Získání softwaru do rukou zákazníků může zahrnovat komplexní síť partnerů všeho druhu: nasazení, distribuce, integrace, prodejce; dohody všeho druhu: OEM, licence, NDA, RFP; setkání všeho druhu: dema, PoC, prezentace; a ještě mnohem víc.

Tyto vztahy slouží jako vstupy, výstupy a dokonce i kroky v procesu dodávání softwaru. Stav kteréhokoli z těchto vztahů může přímo ovlivnit vývojové aktivity. Bez jejich důkladného řízení a propojení s prováděnou prací dochází k velmi hmatatelnému odpadu.

Představte si, že poskytnete epos pro vyhlídku, která se tiše stala ztracenou příležitostí, nebo nasadíte funkci pro partnera, který před měsícem zrušil jejich dohodu. K tomu dochází pravidelně, když je software dodáván nezávisle na hodnotovém toku podniku - když funkce dodávky softwaru není spojena s dodavatelským řetězcem.

Potrubí devops musí být úzce spojeno s partnerstvími, dohodami a cíli, pro které je práce prováděna. Kód lze vysledovat a propojit od příběhu k požadavku až k záznamu zákazníka ve vašem CRM, a to vše tím, že se s dodávkou softwaru zacházíte jako s dodavatelským řetězcem a pokračujete strategií integrace.

Představte si místo toho možnost zobrazit všechny probíhající činnosti prováděné pro konkrétní smlouvu nebo všechny funkce plánované pro nového zákazníka - to je výsledek správy softwarového dodavatelského řetězce - viditelnost a sledovatelnost v průběhu celého životního cyklu.

Nástroje

Zatímco vaše klasické výrobní nástroje mohou sestávat z vysekávacích strojů a pecí pro tepelné zpracování, softwarový dodavatelský řetězec zahrnuje třídu nástrojů (různě nazývaných nástroje ALM, nástroje životního cyklu nebo nástroje devops), které se používají ke správě různých fází dodávky softwaru .

Strategie pro správu těchto nástrojů se velmi liší od klasického přístupu, protože technické a intelektuální investice do nástrojů pro vývoj softwaru jsou obrovské a velmi působivé. Tento typ nástroje se také rychle vyvíjí a je velmi fragmentovaný - dnešní Jenkinsové budou Hudsonem z dávných dob. Organizaci je třeba umístit tak, aby měla odolný, ale modulární zásobník nástrojů, který poskytuje týmům to, co potřebují, při zachování flexibility přizpůsobení.

Řetězec nástrojů navíc nelze odpojit - je třeba předávat informace zpět nahoru a dolů napříč hodnotovým řetězcem, abyste získali znalosti tam, kde je to potřeba. Je důležité zkoumat tuto oblast také z integračního hlediska - jak můžete propojit aktivity v dané vrstvě s okolními a podporujícími aktivitami řízení dodavatelského řetězce?

Závěr

Obchod historicky oddělil správu technologií od linií podnikání generujících příjmy a zacházel s nimi jako se souborem podpůrných aktivit řízených hodnotami a cíli sladěnými s poskytováním služeb. Ve světě definovaném softwarem však tento obchodní model již nesedí.

Schopnost dodávat software se přesunula z klasicky definovaného prostoru podpory a přišla definovat všechny primární aktivity generující příjmy.

Proto musíte svůj model znovu promyslet jako produkční systém a přejít k jednomu, který zachycuje vztahy složitosti napříč aktivitami hodnotového proudu. Toto myšlení ztělesňuje dodavatelský řetězec a s vývojem výroby softwarových produktů tento model jistě uvidíme dospět.

$config[zx-auto] not found$config[zx-overlay] not found