Planowanie i określanie priorytetów
Dowiedz się, jak identyfikować cele działań inżynieryjnych platformy, przeglądać typowe scenariusze i szukać sposobów mierzenia sukcesu. Zmierz sukces, określając cele biznesowe.
Identyfikowanie celów i kluczowych scenariuszy
Zamiast patrzeć na zgnilizną listę kontrolną możliwości lub funkcji, zacznij od zidentyfikowania celów działań inżynieryjnych platformy. Możesz stale planować i aktualizować cele w czasie. Jednak jasne, co chcesz uzyskać od inwestowania w podróż inżynieryjną platformy, może przejść długą drogę, pomagając w tworzeniu pomocy technicznej organizacji.
Jako lider inżynierii platformy kiedyś to ujął: "Nie robię czegoś dla inżynierii platformy, dopóki nie mam czegoś, co mogę z niego uzyskać"." – Peter, lider inżynierii platformy, Międzynarodowa firma technologiczna
Gdy myślisz o swoich celach, określ ich zakres na cele biznesowe związane z nakładem pracy inżynieryjnej platformy, a nie specyfiką konkretnego zespołu deweloperów. Typowe cele inżynieryjne platformy wysokiego poziomu obejmują:
- Zwiększ jakość aplikacji, zmniejsz liczbę usterek i problemy podczas wydawania.
- Zwiększ bezpieczeństwo, zmniejsz liczbę zdarzeń zabezpieczeń lub wykryto typowe luki w zabezpieczeniach i ekspozycje (CVE) raz w środowisku produkcyjnym.
- Zmniejszenie ryzyka poprzez lepszą zgodność z obszarami, takimi jak licencjonowanie, ułatwienia dostępu, prywatność lub regulacje rządowe.
- Przyspiesz wartość biznesową, zmniejszając złożoność, nakład pracy i promowanie udostępniania kodu dzięki wewnętrznym rozwiązaniom źródłowym .
- Zmniejsz koszty programowania lub operacji, zminimalizuj duplikację i zwiększ automatyzację.
Wybór najwyższego celu ma kluczowe znaczenie, ponieważ cel zależy od tego, jak myślisz o priorytetyzacji.
Jeszcze lepiej, uzgadnianie celów i kluczowych wyników (OKR) z liderem i partnerami wewnętrznymi prowadzi do ustanowienia mierzalnych celów dla bieżącej fazy inwestycji. (Inne podejścia do planowania mają podobne pojęcia, jeśli organizacja używa czegoś innego). Najlepsze żądania OKR to te, które można ustawić w oparciu o konkretną miarę, ponieważ usuwa podmiotowość.
Scenariusze i zadania do wykonania
Po zidentyfikowaniu celów wybierz kluczowe scenariusze, aby wyprowadzić listę prac i harmonogram działania. Zobacz na przykład te scenariusze i skojarzone zadania do wykonania.
Scenariusz: rozpoczynanie tworzenia nowej aplikacji
- Omówienie i stosowanie najlepszych rozwiązań i zasad organizacji
- Utwórz nowe repozytorium
- Aprowizuj narzędzia
- Aprowizuj wspólną infrastrukturę
- Przyznawanie członkom zespołu dostępu
- Ustanawianie potoków ciągłej integracji/ciągłego wdrażania
- Aprowizuj infrastrukturę deweloperów
- Wstępne wdrożenie w celu przetestowania "potoków"
Scenariusz: Dodawanie lub usuwanie nowego członka do istniejącego zespołu
- Aktualizowanie dostępu do narzędzi, usług
- Konfigurowanie maszyny dewelopera
- Zwiększenie członków zespołu w aplikacjach
- Tworzenie środowiska piaskownicy aplikacji
- Tworzenie i przeglądanie pierwszego żądania ściągnięcia
Scenariusz: Dodawanie lub aktualizowanie infrastruktury dla istniejącej aplikacji
- Omówienie najlepszych rozwiązań organizacji, dostępnych opcji
- Aktualizowanie/dodawanie infrastruktury jako artefaktów kodu
- Tworzenie środowiska piaskownicy aplikacji
- Weryfikowanie aktualizacji
- Wprowadzanie zmian w innych środowiskach
Scenariusz: Dodawanie lub aktualizowanie narzędzia dla istniejącego zespołu
- Omówienie najlepszych rozwiązań organizacji, dostępnych opcji
- Żądanie użycia nowego narzędzia
- Aktualizowanie dostępu członka zespołu do narzędzi
- (Jeśli ma to zastosowanie) Integrowanie narzędzia z klientami lub potokami ciągłej integracji/ciągłego wdrażania
Scenariusz: znajdowanie lub ponowne używanie istniejącego interfejsu API, zestawu SDK lub usługi
- Odnajdywanie dostępnych interfejsów API, zestawu SDK, usług
- Ocena, czy spełnia ona wymagania
- Nawiąż połączenie z zespołem własnym, aby uzyskać odpowiedzi na pytania
- Wdrażanie aplikacji
Scenariusz: Reagowanie na zdarzenie operacji
- Powiadomienie o problemie
- Ocena, czy kod aplikacji lub infrastruktura powiązana (lub oba)
- Tworzenie środowiska piaskownicy, które dubluje prod (jeśli jest inaczej)
- Wprowadzanie zmian, testowanie, wydawanie poza pasmem
Scenariusz: Szybkie korygowanie zdarzenia zabezpieczeń
- Powiadomienie o problemie
- Ocena zakresu problemów (które systemy)
- Dowiedz się, czy klienci mają bezpośredni wpływ
- Tworzenie środowiska piaskownicy, które dubluje prod (jeśli jest inaczej)
- Wprowadzanie zmian, testowanie, wydawanie poza pasmem
- Komunikowanie się z wszystkimi osobami, których dotyczy problem
Scenariusz: Przestarzałe narzędzie
- Omówienie użycia narzędzia
- Powiadamianie użytkowników o wycofaniu
- (Opcjonalnie) Koordynacja migracji użytkowników do nowego narzędzia
Scenariusz: wdrażanie nowego modelu aplikacji architektury
- Proponowana architektura pilotażowa
- Dostosowywanie na podstawie wyników pilotażowych
- Aktualizowanie dokumentacji najlepszych rozwiązań
- Tworzenie szablonów, aktualizowanie automatyzacji, zasad, ładu
Inspekcja zgodności aplikacji (RODO, ułatwienia dostępu, standardy infrastruktury)
- Omówienie bieżących reguł zgodności
- Sprawdzanie, czy aplikacja spełnia reguły
- Ustal termin poprawek dla odchyleń
- Wprowadzanie zmian, testowanie, wydawanie
Wiele scenariuszy ma zastosowanie do więcej niż jednej roli, dlatego należy zastanowić się nad metrykami, aby dowiedzieć się, jak wiele scenariuszy poprawisz.
Od problemów do pojęć
Następnie należy zapoznać się z największymi problemami, z którymi borykają się deweloperzy i inne role, wraz ze zidentyfikowanymi scenariuszami i zadaniami. Może to być kuszące, aby rozpocząć badanie nowych produktów, aby wypełnić postrzegane luki, ale jeśli te produkty nie rozwiążą poważnego problemu, prawdopodobnie nie zostaną przyjęte lub docenione.
Istnieje kilka podejść, które mogą pomóc w badaniu tego rodzaju. Jednym z nich jest struktura progresji hipotezy. Nawet jeśli nie używasz sformalizowanego procesu, takiego jak struktura progresji hipotez, należy przeprowadzić wywiad deweloperów o zadaniu, aby ograniczyć zakres dyskusji, a następnie zidentyfikować swoje największe problemy w realizacji swojej pracy. Gdy masz dobre poczucie tego, czym są te problemy, przejdź do tworzenia planów ich rozwiązania. Dzięki temu można tworzyć funkcje, których deweloperzy chcą używać.
Aby móc szybko powtórzyć ten proces, zidentyfikuj osobę, która może reprezentować głos klienta bezpośrednio w wewnętrznym zespole platformy deweloperów. Ta rola jest zwykle nazywana menedżerem produktu (nawet jeśli ma inny tytuł pracy), a wraz ze wzrostem ich wiedzy są w stanie dokładnie przewidzieć wyniki mniejszych decyzji i określić, kiedy trzeba wykonać więcej wywiadów. Zapewnia to elastyczność przy jednoczesnym zapewnieniu, że koncentrujesz się na dostarczaniu wartości klientom wewnętrznym.
Uwzględnianie początkowych inwestycji
Gdy masz zestaw zweryfikowanych problemów i pojęć, jesteś w dobrej sytuacji, aby zdecydować, gdzie zainwestować. Należy jednak wziąć pod uwagę inwestycje z góry i długoterminową konserwację wymaganą podczas oceny rozwiązań. Najniższe rozwiązanie nakładu pracy, które może rozwiązać problem, zwykle jest właściwym rozwiązaniem, od którego należy zacząć, ale często jest to praca konserwacyjna, która ostatecznie decyduje, czy inwestycja zakończyła się sukcesem.
Innymi słowy, nie twórz rozwiązań przeznaczonych na późniejsze etapy podróży, chyba że naprawdę musisz.
Po zidentyfikowaniu najcieńszej opłacalnej platformy (TVP) ( MVP dla twojej platformy) należy przeprowadzić pilotaż za pomocą zestawu zespołów programistycznych, które są skłonne do przekazywania opinii. Jeśli twoje rozwiązanie pilotażowe rozwiąże problemy, z którymi borykają się te zespoły, nie powinieneś mieć problemów ze znalezieniem kogoś zainteresowanego angażowaniem się.
Należy przechwycić niektóre kluczowe metryki podczas pilotowania nowej możliwości lub zmian, aby można było zmierzyć, czy koncepcja zakończyła się pomyślnie przed jego wdrożeniem.
Mierzenie powodzenia i potwierdzanie wartości
Mierzenie sukcesu jest ważną częścią myślenia produktu. Nawet małe sukcesy z skromnymi inwestycjami mogą położyć podwaliny pod większe inwestycje, aby budować.
Na przykład trudno jest zabezpieczyć finansowanie lub zakup w celu zapewnienia zgodności, ponieważ mogą być postrzegane jako podatek operacyjny dla zespołów programistycznych, które dostarczają wartość biznesową. Sposób myślenia produktu może zmienić to postrzeganie. Mając sposób myślenia o produkcie, starasz się zapewnić, że klienci dla wewnętrznej platformy deweloperów są zadowoleni i że cele biznesowe uczestników projektu są spełnione. Metryki umożliwiają korzystanie z faktów w celu udowodnienia, że dostarczasz wartość biznesową. Ustawienie reguł OKR może pomóc, szczególnie jeśli masz metryki, których możesz użyć, aby pomóc usunąć subiektywną stronniczą stronniczą. Nawet jeśli nie mierzysz niczego, co ma zastosowanie dzisiaj, możesz ustawić uczenie OKR, aby ustawić punkt odniesienia, który następnie uściślisz po tym punkcie odniesienia jest znany.
Poniżej przedstawiono przykłady dobrze znanych metryk, które można zmierzyć, aby określić, czy zespoły, z którymi pracujesz, otrzymują wartość z tego, co tworzysz. Zero w tych, które pomagają zmierzyć, czy ty, i twoi klienci zespołu deweloperów, osiągasz swoje cele. Na przykład poniżej przedstawiono zestaw metryk, które ułatwiają ocenę, czy platforma przyczynia się do efektywnej organizacji inżynieryjnej:
- Szybkość/czas do wartości biznesowej: mediana dni ukończenia pierwszego żądania ściągnięcia (dołączanie), mediana minut procesów kompilacji i testowania (na przykład: ciągła integracja), mediana czasu scalania żądania ściągnięcia.
- Jakość oprogramowania: Zdarzenia (problemy) utworzone miesięcznie na dewelopera (liczba znormalizowana do liczby deweloperów), średni czas korygowania (MTTR), średni czas badania i korygowania problemu z zabezpieczeniami.
- Łatwość użycia platformy: zadowolenie użytkowników netto (NSAT)
- Kwitnący ekosystem: Średni wynik dla każdego z następujących ankietowanych pytań: "Jestem uprawniony do wykonywania mojej najlepszej pracy", "większość dni jestem pobudzony przez pracę, którą robię", "praca, którą robię, ma znaczenie dla mnie."
Następnie możesz podzielić te metryki według organizacji, zespołu lub projektu. Aby rozpocząć pomiar niektórych punktów odniesienia, możesz jednak obserwować zmiany tych metryk w miarę ulepszania platformy.
Inne metryki, które Ty lub Sponsorzy mogą cię zainteresować pomiarami, to:
| Obszar | Przykładowe metryki |
|---|---|
| Wydajność dostarczania oprogramowania | DevOps Research and Assessment (DORA): Zmiana czasu realizacji, częstotliwość wdrażania, zmiana współczynnika awarii, czas przywracania usługi (MTTR) |
| Operacje | DORA (MTTR), średni czas między awarią (MTBF), średni czas potwierdzenia, dostępność klienta końcowego, opóźnienie, metryki przepływności, koszt dla zespołu, koszt wdrożenia |
| Metryki wdrażania możliwości platformy | Liczba zespołów lub deweloperów korzystających z narzędzia lub funkcji w czasie, procent repozytoriów przy użyciu platformy, najpopularniejszych szablonów, potoków itp. |
Zbieranie metryk wymaga czasu i nakładu pracy, dlatego ważne jest, aby skupić się na krytycznych metrykach dla zidentyfikowanych podstawowych celów — szczególnie tych, które zasilają usługi OKR. Produkty oparte na protokole OpenTelemetry , takie jak Application Insights , mogą pomóc. Niezależnie od tego, pamiętaj, aby mierzyć łatwość korzystania z platformy i regularnie badać, że masz kwitnący ekosystem. Te metryki są często pomijane w systemach wewnętrznych i są wiodącym wskaźnikiem, czy spełniasz szersze cele biznesowe, ponieważ zaangażowanie ma kluczowe znaczenie dla sukcesu. Pomaga również wiedzieć, czy nadszedł czas, aby kontynuować rozwój klientów, aby dowiedzieć się, gdzie przejść dalej.
Inne porady
Niezależnie od sposobu rozpoczęcia należy pamiętać, że należy zaplanować zmianę, zacząć od nowych aplikacji dla pilotów, skoncentrować się na ulepszaniu istniejących środowisk użytkownika, przyjąć zasadę najniższych uprawnień, zaplanować kontrolowane eksperymenty i zminimalizować dostosowywanie.
Plan zmiany
Docelowa platforma aplikacji będzie ewoluować wraz z upływem czasu i może nie być w stanie przeprowadzić migracji wszystkich istniejących inwestycji jednocześnie. Zastanów się, jak można obsługiwać więcej niż jedną zmianę w czasie i zaplanować zmianę.
Weryfikowanie pomysłów przy użyciu nowszych aplikacji
Zacznij od nowych aplikacji o rozsądnym rozmiarze podczas pilotowania nowej platformy lub możliwości platformy. Umożliwi to również zarządzanie platformą jako produktem. Nieśmiały od ponownego tworzenia projektów, aby rozpocząć od czasu nauki, a duże istniejące aplikacje często mają unikatowe potrzeby, które są odkrywane tylko podczas ponownego tworzenia platformy. Z tego powodu sprzężenie sukcesu z tymi typami wysiłków może spowodować niezgodność oczekiwań lub problemy z późnym złamaniem. Począwszy od czegoś nowszego, możesz mieć pewność, że kierunek zapewnia wartość. Zmniejsza to ryzyko walki z tymi większymi wysiłkami. Mówiąc inaczej, jeśli jesteś przekonany, że ludzie mogą zacząć od prawej i pozostać w prawo, to staje się łatwiejsze do prowadzenia właściwej kampanii z tym, czego uczysz się z doświadczenia. Jeśli takie podejście nie jest możliwe, należy wykonać staranną analizę, ustawić oczekiwania i przyrostowo wykonać kroki, zamiast próbować zmieniać wszystko jednocześnie.
Skoncentruj się na istniejących centrach grawitacji dla środowisk użytkowników przed utworzeniem nowych
Deweloperzy są bardziej skłonni do wdrażania i trzymania się nowych funkcji, gdy są one udostępniane w czymś, co już lubią i używają. Podczas oceniania koncepcji dostarczania nowych możliwości należy zbadać opcje, które rozszerzają istniejące "centra grawitacji". Na przykład edytory/środowiska IDE (Visual Studio, VS Code), pakiety DevOps (GitHub, Azure DevOps), istniejące interfejsy wiersza polecenia lub istniejący portal wewnętrzny mogą być bardziej skuteczne niż zupełnie nowy portal lub inny środowisko użytkownika. Zobacz środowiska użytkownika, aby dowiedzieć się więcej.
Przyjmij zasadę najniższych uprawnień
Załóżmy, że deweloperzy mają ograniczony dostęp do systemów podrzędnych, takich jak infrastruktura aprowizacji. Będziesz potrzebować kontrolowanego sposobu włączenia tego dostępu na potrzeby samoobsługowych środowisk.
Planowanie kontrolowanego eksperymentowania
Poeksperymentuj przed wprowadzeniem poważnych lub ryzykownych zmian. Nie wszystko musi być w pełni zautomatyzowane do uruchomienia. Automatycznie wyzwalany ręczny przepływ pracy może być doskonałym sposobem na pilotaż pomysłów.
Minimalizowanie dostosowywania platformy aplikacji
Unikaj niestandardowych możliwości tworzenia platformy aplikacji, które mogą być zaćmione przez możliwości dostawców oprogramowania w czasie. Na przykład hosting środowiska uruchomieniowego, siatki usług, systemy tożsamości itd. Jeśli znajdziesz pilną potrzebę w obszarze, którego podejrzewasz, może to być podobne, planowanie wielu opcji implementacji, biorąc pod uwagę długoterminową konserwację, prawdopodobnie spowoduje przełączenie się w czasie.