Plánování a stanovení priorit
Zjistěte, jak identifikovat cíle pro vaše úsilí o přípravu platformy, projít si běžné scénáře a hledat způsoby měření úspěšnosti. Změřte úspěch tím, že změříte cíle na obchodní cíle.
Identifikace cílů a klíčových scénářů
Místo toho, abyste se podívali na kontrolní seznam možností nebo funkcí, začněte tím, že identifikujete cíle vašeho úsilí o přípravu platformy. Cíle můžete průběžně plánovat a aktualizovat v průběhu času. Mějte ale přehled o tom, co chcete získat z investic do vaší cesty přípravy platformy, může jít dlouhou cestou, která pomáhá vytvářet organizační podporu.
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í inženýrských platforem, nadnárodní technická společnost
Když uvažujete o svých cílech, nastavte jejich rozsah na obchodní cíle související s technickým úsilím 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, snižte chyby a problémy během vydávání.
- Zlepšení zabezpečení, snížení počtu incidentů zabezpečení nebo zjištění běžných ohrožení zabezpečení a ohrožení (CVE) jednou 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.
- Zrychlíte hodnotu od času do firmy tím, že snížíte složitost, režii a propaguje sdílení kódu prostřednictvím postupů vnitřního 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 vést k vytvoření měřitelných cílů 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í míry, protože odstraňuje 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 vyvést backlog a plán. Podívejte se například na tyto 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ě
- Zřizování nástrojů
- 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 otestování kanálů
Scénář: Přidání nebo odebrání nového člena do existujícího týmu
- Aktualizace přístupu k nástrojům, 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ření a kontrola první žádosti o přijetí změn
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 a služeb
- Posouzení, jestli splňuje potřeby
- Spojte se s vlastním týmem pro všechny dotazy
- Přijetí pro aplikaci
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ů na nový nástroj
Scénář: Zavedení nového modelu aplikace architektury
- 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, 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, proto byste měli uvažovat o metrikách, jak budete rozumět tomu, jak se vaše scénáře zlepšují.
Problémy až po koncepty
Dále se snažte 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 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 tento druh vyšetřování. Jedním z nich je architektura pro vývoj hypotéz. 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, abyste se zaměřili na poskytování hodnoty interním zákazníkům.
Proveďte případ počátečních investic.
Jakmile máte sadu ověřených problémů a konceptů, máte dobrou pozici, abyste se rozhodli, 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ý, který začíná, ale často se jedná o práci na údržbě, která nakonec rozhodne, zda je vaše investice ú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) ( MVP pro vaši platformu), nasaďte ji 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í toho, jak jste úspěšní, 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í tak, abyste nastavili směrný plán, který pak zpřesníte po zjištění tohoto směrného plánu.
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. Nula na těch, které vám pomůžou měřit, jestli vy a vaši zákazníci vývojového týmu dosahuje 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 a doba na obchodní hodnotu: Medián dnů 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 sloučení žádosti o přijetí změn.
- 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 pro nápravu (MTTR) – střední doba pro zkoumání a nápravu problému se zabezpečením.
- Snadné použití platformy: Spokojenost uživatelů s čistým uživatelem (NSAT)
- Thriving ekosystém: Průměrné skóre pro každou z následujících průzkumu otázek: "Jsem oprávněn dělat svou nejlepší práci", "většina dnů, kdy jsem aktivovaná prací, kterou dělám", "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 měřit některé směrné plány, můžete se ale podívat, jak se tyto metriky mění při vylepšování platformy.
Mezi další metriky, které byste vy nebo vaši sponzory mohli chtít měřit, patří:
| Plocha | 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) |
| 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ř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 , vám můžou pomoct. Bez ohledu na to, nezapomeňte měřit snadnou platformu a průzkum, že máte ekosystém, který pravidelně prospívá. 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. Získáte tak také zkušenosti se správou platformy jako produktu. Nechejte se znovu vytvářet projekty, abyste začali, protože se učíte, jak jste zvyklí, a velké existující aplikace často mají jedinečné potřeby, které jsou odhaleny pouze během samotného úsilí o opětovné platformy. Z tohoto důvodu může spojení úspěchu s těmito typy úsilí vést k neočekávaných neshodám nebo pozdním problémům způsobujícím přerušení. Když začnete s něčím novějším, můžete mít jistotu ve směru, jakým hodnotu poskytuje. To snižuje riziko řešení těchto větších snah. 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ý, budete chtít provést pečlivou analýzu, nastavit očekávání a postupně krokovat místo toho, abyste se snažili změnit všechno 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ů za účelem 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 uživatelských prostředích .
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é můžou být zatměny funkcemi, 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, že v oblasti, kterou máte podezření, může být taková, naplánujte několik možností implementace s ohledem na dlouhodobou údržbu, což pravděpodobně způsobí, že budete v průběhu času přecházet.