Planowanie i określanie priorytetów

Dowiedz się, jak identyfikować cele działań inżynieryjnych platformy na podstawie modelu możliwości inżynierii platformy, przeglądać typowe scenariusze i szukać sposobów mierzenia sukcesu. Zdefiniuj sukces, dostosowując swoje cele do celów biznesowych.

Identyfikowanie celów i kluczowych scenariuszy

Aby rozpocząć, najpierw oceń, gdzie twoja organizacja znajduje się dzisiaj, korzystając z modelu możliwości inżynierii platformy. Użyj modelu, aby ocenić, gdzie twoja organizacja znajduje się w kontekście sześciu kluczowych zdolności inżynieryjnych platform: inwestycji, wdrażania, zarządzania, aprowizacji, interfejsów oraz pomiarów i sprzężenia zwrotnego. Wszystkie organizacje są bardziej zaawansowane w niektórych możliwościach niż w innych. Gdy już wiesz, gdzie stoi twoja organizacja, możesz wybrać możliwości, które chcesz rozwijać. Aby dowiedzieć się więcej, zobacz Ocena bieżących praktyk i określanie przyszłych celów.

Możesz stale planować i aktualizować cele inżynieryjne platformy w czasie. Jasne określenie tego, co chcesz uzyskać dzięki inwestycjom w proces inżynierii platformy, może znacznie pomóc w uzyskaniu wsparcia organizacyjnego.

Jak to kiedyś ujął lider inżynierii platformy: "Nie robię nic dla inżynierii platformy, dopóki nie mam z tego korzyści". — Peter, lider inżynierii platformy, międzynarodowa firma technologiczna

Jeśli 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 oraz zmniejsz liczbę usterek i problemów podczas wydawania.
• Zwiększ bezpieczeństwo i zmniejsz liczbę incydentów związanych z bezpieczeństwem, oraz wykrytych typowych luk w zabezpieczeniach i ekspozycji (CVE), w środowisku produkcyjnym.
• Zmniejszenie ryzyka poprzez lepszą zgodność z obszarami, takimi jak licencjonowanie, ułatwienia dostępu, prywatność lub regulacje rządowe.
• Przyspiesz osiąganie wartości biznesowej, zmniejszając złożoność, nakład pracy oraz promując udostępnianie kodu dzięki praktykom inner source.
• 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 liderami i partnerami wewnętrznymi pomaga ustalić mierzalne cele dla bieżącej fazy inwestycji. (Inne podejścia do planowania mają podobne pojęcia, jeśli Twoja organizacja używa czegoś innego). Najlepsze OKR-y to te, które można ustawić w oparciu o konkretną miarę, ponieważ eliminuje subiektywność.

Scenariusze i zadania do wykonania

Po zidentyfikowaniu celów wybierz kluczowe scenariusze, aby wyprowadzić listę prac i harmonogram działania. Zobacz na przykład następujące scenariusze i skojarzone zadania do wykonania.

Scenariusz: rozpoczynanie tworzenia nowej aplikacji

• Omówienie i stosowanie najlepszych rozwiązań i zasad organizacji
• Tworzenie nowego repozytorium
• Aprowizuj narzędzia
• Zapewnij wspólną infrastrukturę
• Przyznawanie członkom zespołu dostępu
• Ustanawianie potoków ciągłej integracji/ciągłego wdrażania
• Zapewnienie infrastruktury do rozwoju oprogramowania
• 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 i usług
• Konfigurowanie maszyny deweloperskiej
• Zwiększenie poziomu członka zespołu w aplikacjach
• Tworzenie środowiska piaskownicy aplikacji
• Tworzenie i przeglądanie najpierw żądania ściągnięcia

Scenariusz: Dodawanie lub aktualizowanie infrastruktury dla istniejącej aplikacji

• Omówienie najlepszych rozwiązań organizacji, dostępnych opcji
• Aktualizowanie lub dodawanie infrastruktury jako artefaktów kodu
• Tworzenie środowiska sandbox 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) Integracja narzędzia do klientów lub z pipeline'ami CI/CD

Scenariusz: znajdowanie lub ponowne używanie istniejącego interfejsu API, zestawu SDK lub usługi

• Odnajdywanie dostępnych interfejsów API, zestawu SDK lub usług
• Ocena, czy spełnia ona wymagania
• Nawiąż połączenie z zespołem własnym, aby uzyskać odpowiedzi na pytania
• Przyjęcie do zastosowania

Scenariusz: Reagowanie na zdarzenie operacji

• Powiadomienie o problemie
• Określ, czy problem dotyczy kodu aplikacji, infrastruktury, czy obu.
• Twórz środowisko piaskownicy, które odzwierciedla środowisko produkcyjne (jeśli się różni)
• 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: Wycofanie narzędzia

• Omówienie użycia narzędzia
• Powiadamianie użytkowników o wycofaniu
• (Opcjonalnie) Koordynowanie migracji użytkowników do nowego narzędzia

Scenariusz: wdrażanie nowego modelu architektury aplikacji

• Proponowana architektura pilotażowa
• Dostosowywanie na podstawie wyników pilotażowych
• Aktualizowanie dokumentacji najlepszych rozwiązań
• Tworzenie szablonów, aktualizowanie automatyzacji, zasad i ł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. Zastanów się nad metrykami dotyczącymi mierzenia poprawy.

Od problemów do pojęć

Następnie zapoznaj się z największymi problemami, z którymi borykają się deweloperzy i inne role, przy użyciu zidentyfikowanych scenariuszy i zadań. 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, takim jak 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 jest 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.

Uzasadnij swoje początkowe inwestycje

Gdy masz zestaw zweryfikowanych problemów i pojęć, jesteś w dobrej sytuacji, aby zdecydować, gdzie inwestować. 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 swojej najprostszej opłacalnej platformy (TVP) (takiej jak minimalny pożądany produkt dla platformy), przetestuj ją z zestawem zespołów programistycznych, które chcą przekazać opinię. 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, na których można budować.

Na przykład trudno jest zabezpieczyć finansowanie lub uzyskanie akceptacji dla działań związanych z zapewnieniem zgodności, ze względu na to, że są 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 OKRs może pomóc, zwłaszcza jeśli masz metryki, których możesz użyć, aby pomóc usunąć subiektywną stronniczość. Nawet jeśli nie mierzysz obecnie niczego, co ma zastosowanie, możesz ustawić OKR związany z nauką, aby stworzyć punkt odniesienia, który następnie uściślisz, gdy ten punkt odniesienia stanie się znany.

Poniżej przedstawiono przykłady dobrze znanych metryk, które można zmierzyć, aby określić, czy zespoły, z którymi pracujesz, uzyskują wartość z tego, co tworzysz. Skup się na tych, które pomagają zmierzyć, czy ty i klienci twojego zespołu deweloperów osiągacie 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 procesów pierwszego wniosku o przyciągnięcie kodu (dołączanie), mediana minut procesów kompilacji i testowania (na przykład: ciągła integracja), mediana czasu scalania wniosku o przyciągnięcie kodu.
• Jakość oprogramowania: zdarzenia (problemy) utworzone miesięcznie na dewelopera (liczba znormalizowana do liczby deweloperów), średni czas odzyskiwania (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. Musisz zmierzyć niektóre punkty odniesienia, aby rozpocząć, ale możesz obserwować zmiany tych metryk w miarę ulepszania platformy.

Inne metryki, których pomiarem Ty lub Twoi sponsorzy mogą być zainteresowani, to:

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ą elementy OKR. Produkty oparte na protokole OpenTelemetry, takie jak Application Insights, mogą pomóc.

Pamiętaj, aby regularnie oceniać łatwość użytkowania platformy i upewniać się, że ekosystem rozwija się pomyślnie. 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ż określić, czy nadszedł czas na dalszy rozwój relacji z klientami, aby określić dalsze kroki.

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ż jeden wariant w czasie i zaplanować zmiany.

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. Zapewnia to również doświadczenie w zarządzaniu platformą jako produktem. Unikaj rozpoczynania projektów replatformingu, ponieważ uczysz się w miarę postępowania, a duże, istniejące aplikacje często mają unikalne potrzeby, które są ujawniane dopiero podczas samego procesu replatformingu. Z tego powodu wiązanie sukcesu z tego typu wysiłkami może prowadzić do niezgodności oczekiwań lub niespodziewanych problemów na późnym etapie. Zaczynając od czegoś nowszego, możesz zyskać pewność co do swojego kierunku i wartości, jaką to zapewnia. Zmniejsza to ryzyko podejmowania tych większych wysiłków. Innymi słowy, jeśli jesteś przekonany, że ludzie mogą zacząć dobrze i pozostać na właściwej drodze, to łatwiej jest poprowadzić kampanię doskonalenia, ucząc się na doświadczeniach. Jeśli takie podejście nie jest możliwe, chcesz przeprowadzić staranną analizę, ustawić oczekiwania i przyrostowo wykonać kroki, zamiast próbować zmienić wszystko naraz.

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. Aby dowiedzieć się więcej, zobacz Środowiska użytkownika.

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 do doświadczeń samoobsługowych.

Planowanie kontrolowanego eksperymentowania

Poeksperymentuj przed wprowadzeniem poważnych lub ryzykownych zmian. Nie wszystko musi być w pełni zautomatyzowane na początek. Automatycznie wyzwalany ręczny przepływ pracy może być doskonałym sposobem na pilotaż pomysłów.

Minimalizowanie dostosowywania platformy aplikacji

Unikaj tworzenia niestandardowych możliwości platformy aplikacji, które mogą być zaćmione przez możliwości udostępniane przez 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óry podejrzewasz, że może przypominać ten, zaplanuj wiele opcji wdrożenia, ponieważ długoterminowa konserwacja prawdopodobnie zmusi Cię do zmiany w czasie.

Treści powiązane

• Stosowanie systemów inżynierii oprogramowania