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. Zmierz sukces, określając cele biznesowe.
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 do tworzenia wykresu, w którym twoja organizacja ma sześć podstawowych możliwości inżynieryjnych platformy — inwestycje, wdrażanie, ład, aprowizowanie i zarządzanie, interfejsy oraz pomiary i opinie. 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 , jak używać modelu.
Możesz stale planować i aktualizować cele inżynieryjne platformy w czasie. Jasne, co chcesz uzyskać od inwestowania w podróż inżynieryjną platformy, może przejść długą drogę, pomagając w tworzeniu wsparcia organizacyjnego.
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
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 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 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.
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.
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.
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.