Plánování a stanovení priority

Zjistěte, jak identifikovat cíle pro vaše úsilí o přípravu platformy na základě modelu schopností platformy, projít si běžné scénáře a najít způsoby měření úspěchu. Změřte úspěch tím, že změříte cíle na obchodní cíle.

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

Nejprve vyhodnoťte, kde je vaše organizace dnes, pomocí modelu schopností platformového inženýrství. Pomocí modelu můžete namapovat, kde je vaše organizace v šesti základních možnostech přípravy platforem: investice, přijetí, zásady správného řízení, zřizování a správa, rozhraní a měření a zpětná vazba. Všechny organizace jsou pokročilejší v některých možnostech než v jiných. Jakmile budete vědět, kde vaše organizace dnes stojí, můžete si vybrat, které možnosti chcete rozšířit. Další informace najdete v tématu Posouzení aktuálních postupů a nastavení budoucích cílů.

V průběhu času můžete průběžně plánovat a aktualizovat technické cíle platformy. Mít jasno v tom, co chcete získat z investic do vaší cesty platformového inženýrství, může významně přispět k budování organizační podpory.

Jako vedoucí technické platformy to jednou uvedl: "Nedělám něco pro inženýrství platforem, dokud z něj něco nemám." – Peter, vedoucí technické platformy, nadnárodní technická společnost

Při představách cílů je můžete vymezit na obchodní cíle související s technickým úsilím vaší platformy, a ne na specifika konkrétního vývojového týmu. Mezi běžné technické cíle platformy vysoké úrovně patří:

• Zvyšte kvalitu aplikace a omezte chyby a problémy během vydávání.
• Vylepšete zabezpečení a snižte počet incidentů zabezpečení nebo detekovaných běžných zranitelností a expozic (CVE), jakmile bude v produkčním prostředí.
• Snížit 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.
• Zrychlete čas pro dosažení hodnoty pro firmu tím, že snížíte složitost, režii a budete propagovat sdílení kódu prostřednictvím vnitřních postupů zdroje.
• Snižte náklady na vývoj nebo provoz, minimalizujte duplikaci a vylepšete automatizaci.

Výběr vašeho nejvyššího cíle je kritický, protože váš cíl řídí, jak si myslíte o stanovení priority.

Ještě lepší je odsouhlasení cílů a klíčových výsledků (OKR) s vedením a interními partnery pomáhá 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ší OKRs jsou ty, které můžete nastavit na základě konkrétního měřítka, které odstraňují subjektivitu.

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

Po identifikaci cílů zvolte klíčové scénáře, které vám pomůžou řídit váš backlog a plán. Podívejte se například na následující scénáře a související úlohy, které se mají provést.

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

• Vysvětlení a použití osvědčených postupů a zásad organizace
• Vytvoření nového úložiště
• Nástroje pro provisioning
• Zřízení společné infrastruktury
• Udělení přístupu členům týmu
• Zaveďte CI/CD potrubí
• Zřízení vývojové infrastruktury
• Počáteční nasazení pro otestování "pipes"

Scénář: Přidání nebo odebrání nového člena do 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ýraznění člena týmu v aplikacích
• Vytvoření prostředí sandboxu aplikace
• Vytvořte a nejprve zkontrolujte pull request.

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

• Vysvětlení 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

• Vysvětlení 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 k dispozici) 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 nebo služeb
• Posouzení, jestli splňuje potřeby
• Spojte se s vlastním týmem pro všechny dotazy
• Zavést do aplikace

Scénář: Reakce na provozní incident

• Oznámení o problému
• Posouzení, jestli kód aplikace nebo infrastruktura související (nebo obojí)
• Vytvoření prostředí sandboxu, které zrcadlí prod (pokud se liší)
• Provádění změn, testování, vydání mimo pásmo

Scénář: Rychlá náprava incidentu zabezpečení

• Oznámení o problému
• Posouzení rozsahu problémů (které systémy)
• Vysvětlení toho, jestli jsou zákazníci přímo ovlivněni
• Vytvoření prostředí sandboxu, které zrcadlí prod (pokud se liší)
• Provádění změn, testování, vydání mimo pásmo
• Komunikace s kýmkoli ovlivněným

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

• Vysvětlení využití nástrojů
• Upozorňovat uživatele na vyřazení
• (Volitelné) Koordinace migrace uživatelů do nového nástroje

Scénář: Zavedení nového modelu architektury aplikace

• Navržená pilotní architektura
• Úprava na základě výsledků pilotního nasazení
• Dokumentace k aktualizaci osvědčených postupů
• Vytváření šablon, aktualizace automatizace, zásad a zásad 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
• Stanovení konečného termínu pro opravy odchylek
• Provádění změn, testování, vydání

Mnoho scénářů platí pro více než jednu roli. Zamyslete se nad metrikami, jak změříte zlepšení.

Problémy až po koncepty

Dále porozumíte 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 tak, aby vyplnily vnímané mezery, ale pokud tyto produkty nevyřeší hlavní bolestný bod, 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í, jako je architektura pro průběh hypotézy. I když nepoužíváte formalizovaný proces, jako je architektura pro progrese hypotéz, měli byste požádat vývojáře o práci, která se má provést, aby mohli určit rozsah diskuze, a pak identifikovat jejich největší problémy při plnění své práce. Jakmile budete mít dobrou představu o tom, co jsou tyto problémy, pokračujte v plánování jejich řešení. To pomáhá zajistit, abyste vytvořili funkce, které chtějí vývojáři používat.

Abyste mohli tento proces rychle zopakovat, identifikujte někoho, kdo může vyjádřit hlas zákazníka přímo ve vašem interním týmu vývojářské platformy. Tato role se obvykle nazývá produktový manažer (i když má jinou pracovní pozici) a s rostoucími znalostmi dokáže přesně předpovědět výsledky pro menší rozhodnutí a určit, kdy potřebujete udělat více pohovorů. Tím zajistíte flexibilitu a zároveň zajistíte, že se zaměříte na poskytování hodnoty interním zákazníkům.

Předložte argumenty pro své počáteční investice.

Jakmile máte sadu ověřených problémů a konceptů, jste v dobré pozici rozhodnout, kam investovat. Při vyhodnocování řešení však zvažte počáteční investice a dlouhodobou údržbu. Řešení s nejnižším úsilím, které může vyřešit problém, je ten správný pro začátek, ale často je to údržba, co nakonec rozhodne, zda se vaše investice ukáže jako úspěšná.

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

Jakmile identifikujete nejtenčí realizovatelnou platformu (TVP) (například minimální realizovatelný produkt pro vaši platformu), pilotujte ji se sadou vývojových týmů, které jsou ochotné poskytnout zpětnou vazbu. Pokud vaše pilotní řešení řeší problémy s těmito týmy, neměli byste mít potíže najít někoho, kdo se zajímá o zapojení.

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

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

Měření úspěchu je důležitou součástí produktového myšlení. I malé úspěchy s skromnými investicemi mohou položit základ pro větší investice, na kterých by bylo možné stavět.

Například může být obtížné zabezpečit finanční prostředky nebo nákupy za účelem dodržování předpisů, protože je lze vnímat jako provozní daň vývojovým týmům, které poskytují obchodní hodnotu. Produktová mysl může toto vnímání změnit. S ohledem na produkt se snažíte zajistit, aby zákazníci pro vaši interní vývojářskou platformu byli spokojení a že jsou splněny obchodní cíle zúčastněných stran. Metriky umožňují využít fakta k prokázání, že poskytujete obchodní hodnotu. Nastavení OKR může pomoct, zejména pokud máte metriky, které můžete použít k odstranění subjektivní předsudky. I když dnes neměříte nic použitelného, můžete nastavit OKR učení, abyste stanovili základní úroveň, kterou pak zpřesníte po jejím stanovení.

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

• Rychlost dosažení obchodní hodnoty: Medián dnů potřebných k dokončení prvního pull requestu (zaškolení), medián minut pro procesy sestavení a testování (například CI), medián času potřebného ke sloučení pull requestu.
• Kvalita softwaru: Incidenty (problémy) vytvořené za měsíc za vývoj (počet normalizovaných na počet vývojářů), střední doba obnovení (MTTR) – doba pro zkoumání a nápravu problému se zabezpečením.
• Snadné použití platformy: Čistá spokojenost uživatelů (NSAT)
• Thriving ekosystém: Průměrné skóre pro každou z následujících průzkumných otázek: "Jsem zmocněn/zmocněna dělat svou nejlepší práci", "většinu dnů mě práce, kterou dělám, nabíjí energií", "práce, kterou dělám, je pro mě smysluplná."

Tyto metriky pak můžete rozdělit podle organizace, týmu nebo projektu. Nejdříve musíte změřit některé základní hodnoty, ale pak můžete sledovat, jak se tyto metriky mění při vylepšování vaší platformy.

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

Area	Ukázkové metriky
Výkon doručování softwaru	DevOps Research and Assessment (DORA): Změna doby předstihu, frekvence nasazení, míra selhání změn, doba obnovení služby (MTTR)
Operations	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řechodu na možnosti platformy	Počet týmů nebo vývojářů, kteří používají nástroj nebo funkci v průběhu času, procento úložišť využívajících platformu, nejoblíbenější šablony, kanály atd.

Shromažďování metrik vyžaduje čas a úsilí, takže je důležité se zaměřit na kritické metriky pro klíčové cíle, které jste identifikovali, zejména ty, které podporují vaše okrs. Produkty založené na OpenTelemetry, jako je Application Insights, můžou pomoct.

Ujistěte se, že měříte snadnost použití platformy a pravidelně ověřujete, že máte prosperující ekosystém. Tyto metriky se u interních systémů často zmeškávají a představují hlavní ukazatel toho, jestli splňujete širší obchodní cíle, protože zapojení je pro úspěch velmi důležité. Také vám pomůže zjistit, jestli je čas provést další vývoj zákazníků, abyste pochopili, kde pokračovat.

Další tipy

Bez ohledu na to, jak začnete, mějte na paměti, že byste měli naplánovat změnu, začít s novými aplikacemi pro pilotní nasazení, zaměřit se na vylepšení stávajících uživatelských prostředí, přijmout zásadu nejnižších oprávnění, naplánovat řízené experimentování a minimalizovat přizpůsobení.

Plánování změn

Vaše cílová aplikační platforma se bude v průběhu času vyvíjet a možná nebudete moct migrovat všechny vaše stávající investice najednou. Zamyslete se nad tím, jak můžete v průběhu času podporovat více variant a naplánovat změnu.

Ověřování nápadů s novějšími aplikacemi

Začněte s novými aplikacemi přiměřené velikosti při pilotním nasazení nové platformy nebo možností platformy. Díky tomu můžete také spravovat platformu jako produkt. Vyhýbejte se zahajování projektů na změnu platformy, protože se postupně učíte, a existující velké aplikace často mají jedinečné potřeby, které jsou odhaleny pouze během samotné změny platformy. Z tohoto důvodu může spojení úspěchu s těmito typy úsilí vést k nesouladům v očekáváních nebo problémům, které se objeví pozdě. Když začnete s něčím novějším, můžete mít jistotu ve svém směru a cítit hodnotu, kterou poskytuje. To snižuje riziko zahájení těchto větších projektů. Pokud jste si jistí, že lidé můžou začít správně a zůstat v pořádku, bude jednodušší řídit správnou kampaň tím, co se naučíte ze zkušeností. Pokud tento přístup není možný, chcete provést pečlivou analýzu, nastavit očekávání a přistupovat postupně, namísto snahy změnit vše najednou.

Než začnete vytvářet nové, zaměřte se na stávající centra závažnosti uživatelského prostředí.

Vývojáři budou s větší pravděpodobností přijímat nové funkce a držet se nových funkcí, když se objeví v něčem, co už rádi 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í centra závažnosti. Například editory a integrované vývojové prostředí (Visual Studio, VS Code), sady DevOps (GitHub, Azure DevOps), existující rozhraní CLI nebo existující interní portál můžou být efektivnější než úplně nový portál nebo jiný uživatelský systém. Další informace najdete v tématu Uživatelské 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, například ke 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 velký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 pilotní nápady pilotovat.

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

Vyhněte se vlastním možnostem vytváření aplikační platformy, které by mohly být zatměny možnostmi, které dodavatelé softwaru vydávají v průběhu času. Například hostování modulu runtime, sítě služeb, systémy identit atd. Pokud zjistíte naléhavou potřebu v oblasti, o které máte podezření, že by mohla být touto povahou, naplánujte několik možností implementace s ohledem na dlouhodobou údržbu, což pravděpodobně způsobí, že budete postupem času přecházet na jiné řešení.

Související obsah

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