Plánování a stanovení priority

Zjistěte, jak identifikovat cíle pro vytváření platforem, projít si běžné scénáře a hledat způsoby, jak měřit úspěch. Úspěch můžete měřit tak, že své cíle odměříte na obchodní cíle.

Identifikace cílů a klíčových scénářů

Jak kdysi řekl vedoucí inženýrství platforem: "Nedělám něco pro inženýrství platforem, dokud nemám něco, co z toho můžu získat." – Peter, vedoucí pro inženýrství platforem, nadnárodní tech společnost

Místo toho, abyste se dívali na další kontrolní seznam funkcí nebo funkcí, začněte tím, že identifikujete cíle svého úsilí o vytváření platforem. Cíle můžete průběžně plánovat a aktualizovat v průběhu času. Když ale budete mít jasno v tom, co chcete získat díky investici do přípravy platforem, může vám pomoct s budováním podpory organizace.

Když přemýšlíte o svých cílech, využívejte je na obchodní cíle související s úsilím o vytváření platforem, nikoli na specifika konkrétního vývojového týmu. Tady jsou například některé běžné obecné cíle přípravy platforem:

• Zvyšte kvalitu aplikace, snižte počet chyb a problémů během vydávání.
• Vylepšete zabezpečení, snižte počet incidentů zabezpečení nebo jednou v produkčním prostředí detekujte KVV .
• Snižte riziko díky lepšímu dodržování předpisů v oblastech, jako jsou licencování, přístupnost, ochrana osobních údajů nebo vládní regulace.
• Urychlete čas-to-business hodnotu tím, že snížíte složitost, režii a podpoříte sdílení kódu prostřednictvím vnitřních zdrojových postupů.
• Snižte náklady na vývoj nebo provoz, minimalizujte duplicity a vylepšete automatizaci.

I když všechny tyto cíle můžou být dlouhodobými cíli, výběr vašeho nejvyššího cíle je kritický, protože to určuje způsob, jakým přemýšlíte o stanovení priorit.

Ještě lepší je, když se s vedením a interními partnery dohodnete na cílech a klíčových výsledcích (OKRs), můžete stanovit měřitelné cíle pro aktuální fázi vašich investic. (Jiné přístupy k plánování mají podobné koncepty, pokud vaše organizace používá něco jiného.) Nejlepší OKR jsou ty, které můžete nastavit na základě konkrétní míry, protože odstraňuje subjektivitu.

Scénáře a úlohy, které se mají provést

Jakmile určíte své cíle, identifikujte klíčové scénáře, které použijete k dosažení backlogu a plánu. Podívejte se například na tyto scénáře a úlohy, které se mají provést.

Scénář: Zahájení vytváření nové aplikace

• Principy a uplatňování osvědčených postupů a zásad organizace
• Vytvoření nového úložiště
• Nástroje pro zřizování
• Zřízení společné infrastruktury
• Udělení přístupu členům týmu
• Vytvoření kanálů CI/CD
• Zřízení vývojové infrastruktury
• Počáteční nasazení pro testování "kanálů"

Scénář: Přidání nebo odebrání nového člena existujícího týmu

• Aktualizace přístupu k nástrojům a službám
• Nastavení vývojářského počítače
• Zvýšení náplně členů týmu u aplikací
• Vytvoření prostředí sandboxu aplikace
• Vytvoření a kontrola první žádosti o přijetí změn

Scénář: Přidání nebo aktualizace infrastruktury pro existující aplikaci

• Principy osvědčených postupů organizace a dostupných možností
• Aktualizace nebo přidání infrastruktury jako artefaktů kódu
• Vytvoření prostředí sandboxu aplikace
• Ověření aktualizací
• Zavedení změn v jiných prostředích

Scénář: Přidání nebo aktualizace nástroje pro existující tým

• Principy osvědčených postupů organizace a dostupných možností
• Žádost o použití nového nástroje
• Aktualizace přístupu členů týmu k nástrojům
• (Pokud je to možné) Integrace nástroje do klientů nebo kanálů CI/CD

Scénář: Vyhledání nebo opakované použití existujícího rozhraní API, sady SDK nebo služby

• Zjišťování dostupných rozhraní API, sady SDK a služeb
• Posouzení, zda splňuje potřeby
• Spojte se s vlastním týmem a v případě jakýchkoli dotazů
• Přijmout pro aplikaci

Scénář: Reakce na provozní incident

• Oznámení o problému
• Posouzení, jestli kód aplikace nebo infrastruktura souvisí (nebo obojí)
• Vytvoření prostředí sandboxu, které zrcadlí prostředí prod (pokud se liší)
• Provádění změn, testování, out-of-band vydané verze

Scénář: Rychlá náprava incidentu zabezpečení / Oznámení o běžných ohroženích zabezpečení a ohrožení zabezpečení (CVE)

• Oznámení o problému
• Posouzení šířky problémů (které systémy)
• Zjistit, jestli se to týká přímo zákazníků
• Vytvoření prostředí sandboxu, které zrcadlí prostředí prod (pokud se liší)
• Provádění změn, testování, out-of-band vydané verze
• Komunikace s kýmkoli, koho se to týká

Scénář: Vyřazení nástroje

• Principy použití nástrojů
• Upozorňovat uživatele na vyřazení
• (Volitelné) Koordinační migrace uživatelů na nový nástroj

Scénář: Definování nebo uvedení nového modelu aplikace / architektury

• Návrh architektury z pilotního nasazení
• Úprava na základě výsledků pilotního nasazení
• Aktualizace dokumentace k osvědčeným postupům
• Vytváření šablon, automatizace aktualizací, zásady, zásady správného řízení

Audit dodržování předpisů aplikací (GDPR, přístupnost, standardy infrastruktury)

• Vysvětlení aktuálních pravidel dodržování předpisů
• Ověření, že aplikace splňuje pravidla
• Stanovit konečný termín pro opravy odchylek
• Provádění změn, testování, vydání

Mnoho scénářů se vztahuje na více než jednu roli, takže se také budete chtít zamyslet nad metrikami, abyste pochopili, jak moc se vaše scénáře zlepší.

Od problémů k konceptům

Dále doporučujeme porozumět největším problémům, se kterými se vaši vývojáři a další role setkávají se scénáři a úlohami, které jste identifikovali. Může být lákavé začít zkoumat nové produkty, aby se vyplnily domnělé mezery, ale pokud tyto produkty nevyřeší hlavní problém, pravděpodobně nebudou přijaty nebo oceňovány.

Existuje několik přístupů, které vám můžou pomoct s tímto druhem šetření. Jedním z nich je rámec progrese hypotézy. I když nepoužíváte formalizovaný proces, jako je architektura progrese hypotéz, můžete získat mnoho z rozhovorů s vývojáři o práci, kterou je třeba udělat, aby se diskuse vymezila, a pak identifikovat jejich největší problémy při plnění jejich práce. Jakmile budete mít dobrý přehled o těchto problémech, můžete přejít k vytváření konceptů pro jejich řešení. Tím zajistíte, že budete vytvářet funkce, které chtějí vývojáři používat.

Abyste mohli tento proces rychle zopakovat, budete chtít identifikovat někoho, kdo může zastupovat hlas zákazníka přímo ve vašem interním týmu vývojářské platformy. Tato role se obvykle označuje jako produktový manažer (i když má jinou pracovní pozici), a s rostoucími znalostmi budou moct přesně předpovědět výsledky menších rozhodnutí a určit, kdy potřebujete udělat více pohovorů. Díky tomu si zachováte flexibilitu a zároveň zajistíte, že se soustředíte na poskytování hodnoty interním zákazníkům.

Využte případ pro vaše počáteční investice

Jakmile budete mít sadu ověřených problémů a konceptů, budete mít dobrou pozici k tomu, abyste mohli argumentovat investicemi. Mějte však na paměti úroveň počátečních investic a vyžaduje se dlouhodobá údržba. Řešení s nejnižším úsilím, které může problém vyřešit, je obvykle tím správným řešením, ale často je to právě údržba, která nakonec rozhoduje o tom, jestli je vaše investice úspěšná.

Jinak řečeno, nevytvovávejte řešení, která cílí na pozdější fáze vaší cesty, pokud to opravdu nepotřebujete.

Jakmile identifikujete svou nejtenčí životaschopnou platformu (TVP) ( MVP pro vaši platformu), můžete ji pilotovat pomocí sady vývojových týmů, které jsou ochotné poskytnout zpětnou vazbu. Pokud vaše pilotní řešení řeší problémy, se kterými se tyto týmy potýkají, neměli byste mít problém najít někoho, kdo by se chtěl zapojit.

Při pilotním nasazení nové funkce nebo změn byste měli zaznamenat některé klíčové metriky, abyste mohli před jeho uvedením změřit, jestli byl koncept úspěšný.

Měření úspěšnosti a prokazování hodnoty

Bez ohledu na to, jestli provádíte svoji první investici nebo ne, je měření úspěšnosti důležitou součástí produktového myšlení. Pomůže vám nejen zjistit, jestli jste dosáhli svých cílů, ale i malé úspěchy se skromnými investicemi mohou vytvořit základ pro větší investice, na kterých můžete stavět.

Může být například obtížné zajistit financování nebo nákup v rámci úsilí o dodržování předpisů, protože mohou být vnímány jako provozní daň vývojovým týmům, které přinášejí obchodní hodnotu. Nastavení produktového myšlení může toto vnímání změnit. S ohledem na produkt se snažíte zajistit, aby zákazníci vaší interní vývojářské platformy byli spokojení a aby byly splněny obchodní cíle zúčastněných stran. Metriky vám umožňují pomocí faktů prokázat, že poskytujete obchodní hodnotu. Nastavení OKR může pomoct, zejména pokud máte metriky, které můžete použít k odstranění subjektivních předsudků. I když dnes nic neměříte, můžete nastavit výukovou OKR a nastavit směrný plán, který pak upřesníte, jakmile bude tento směrný plán známý.

Tady jsou příklady dobře známých metrik, které můžete měřit, abyste zjistili, jestli týmy, se kterými pracujete, získávají hodnotu z toho, co vytváříte. Žádné z nich, které vám pomůžou změřit, jestli vy a vaši zákazníci vývojového týmu dosahujete svých cílů. Například následující sada metrik vám pomůže vyhodnotit, jestli vaše platforma přispívá k efektivní technické organizaci:

• Rychlost/čas na obchodní hodnotu: Medián dnů do dokončení první žádosti o přijetí změn (onboarding), medián minut pro procesy sestavení a testování (například CI), medián času pro sloučení žádosti o přijetí změn.
• Kvalita softwaru: Incidenty (problémy) vytvořené za měsíc a vývoj (počet normalizovaných na počet vývojářů), střední doba potřebná k nápravě (MTTR) a střední doba potřebná k prošetření a nápravě problému se zabezpečením.
• Snadné použití platformy: Čistá spokojenost uživatelů (NSAT)
• Vzkvétající ekosystém: Průměrné skóre pro každou z následujících zkoumaných otázek: "Mám možnost odvést svou nejlepší práci", "většinu dní mě povzbudí moje práce", "práce, kterou dělám, je pro mě smysluplná."

Tyto metriky pak můžete rozdělit podle organizace, týmu nebo projektu. Abyste mohli začít, budete muset změřit některé směrné plány, ale při vylepšování platformy můžete watch, že se tyto metriky změní.

Mezi další metriky, které by vás nebo vaše sponzory mohlo zajímat měření, patří:

Oblasti	Ukázkové metriky
Výkon doručování softwaru	Výzkum a hodnocení DevOps (DORA): Doba potřebná ke změně, frekvence nasazení, změna míry selhání, doba obnovení služby (MTTR)
Operace	DORA (MTTR), střední doba mezi selháním (MTBF), průměrná doba potvrzení, dostupnost koncového zákazníka, latence, metriky propustnosti, náklady na tým, náklady na nasazení
Metriky přijetí funkcí platformy	Počet týmů nebo vývojářů, kteří nástroj nebo funkci v průběhu času používají, procento úložišť využívajících platformu, nejoblíbenější šablony, kanály atd.

Shromažďování metrik vyžaduje čas a úsilí, proto je důležité se zaměřit na kritické metriky pro klíčové cíle, které jste určili – zejména ty, které podporují vaše okrs. Produkty založené na OpenTelemetry, jako je Application Insights, vám můžou pomoct. Bez ohledu na to nezapomeňte změřit jednoduchost používání platformy a pravidelně zkontrolovat, že máte vzkvétající ekosystém. U interních systémů se tyto metriky často vynechávají a jsou hlavním ukazatelem toho, jestli splníte širší obchodní cíle, protože zapojení je pro úspěch klíčové. Pomůže vám také zjistit, jestli je čas provést další vývoj pro zákazníky, abyste pochopili, kam dál.

Další tipy

Bez ohledu na to, jak začnete, mějte na paměti následující pokyny.

Plánování změn

Vaše cílová aplikační platforma se bude časem vyvíjet a je možné, že nebudete moct migrovat všechny své stávající investice najednou. Pravděpodobně si budete chtít promyslet, jak můžete v průběhu času podporovat více než jednu variaci a naplánovat změnu.

Ověření nápadů pomocí novějších aplikací

Při pilotním nasazení nové platformy nebo funkcí platformy je obecně nejlepší začít s novými aplikacemi přiměřené velikosti. Získáte tak také zkušenosti se správou platformy jako produktu. Vyhýbejte se zahájení projektů re-platforming, protože se budete učit postupně a velké existující aplikace mají často jedinečné potřeby, které jsou odhaleny pouze během samotného úsilí o re-platforming. Z tohoto důvodu může spojení úspěchu s těmito typy úsilí vést k očekávané neshodě nebo pozdním problémům způsobujícím zásadní problémy. Když začnete s něčím novějším, můžete mít jistotu ve svůj směr hodnoty, kterou poskytuje. Tím se snižuje riziko, že se vypořádáte s tímto větším úsilím. Jinými slovy, pokud jste si jistí, že lidé můžou začít správně a zůstat v pořádku, pak bude jednodušší řídit kampaň get right s tím, co se naučíte ze zkušeností. Pokud tento přístup není možný, budete chtít provést pečlivou analýzu, nastavit očekávání a postupně se do toho pusťte, abyste se nepokoušli všechno změnit najednou.

Než začnete vytvářet nová, zaměřte se na stávající tíhou pro uživatelské prostředí.

Vývojáři s větší pravděpodobností osvojí nové funkce a zůstanou u nich, když se objeví v něčem, co se jim už líbí a používají. Při vyhodnocování konceptů pro poskytování nových funkcí nezapomeňte prozkoumat možnosti, které rozšiřují stávající "těžiště". Například editory/integrované vývojové prostředí (Visual Studio, VS Code), sady DevOps (GitHub, Azure DevOps), existující rozhraní příkazového řádu nebo existující interní portál můžou být efektivnější než zcela nový portál nebo jiné uživatelské prostředí. Další informace najdete v tématu o uživatelském prostředí .

Předpokládejme princip nejnižší úrovně oprávnění.

Předpokládejme, že vývojáři mají omezený přístup k podřízeným systémům, jako je zřizování infrastruktury. Budete potřebovat řízený způsob, jak tento přístup povolit pro samoobslužné prostředí.

Plánování řízeného experimentování

Experimentujte před zavedením hlavních nebo rizikových změn. Ne všechno musí být plně automatizované, aby bylo možné začít. Automaticky aktivovaný ruční pracovní postup může být skvělým způsobem, jak využít pilotní nápady.

Minimalizace přizpůsobení aplikační platformy

Snažte se vyhnout možnostem platformy vlastních aplikací, které by mohly být zastíněné možnostmi, které dodavatelé softwaru vydávají v průběhu času. Například hostování za běhu, sítě služeb, systémy identit atd. Pokud zjistíte naléhavou potřebu v oblasti, o které se domníváte, že je podobná, naplánujte několik možností implementace vzhledem k tomu, že dlouhodobá údržba pravděpodobně způsobí přechod v průběhu času.

Použití systémů softwarového inženýrství