Roadmapa platformy: od chaosu do flow

Zacznij od tarcia produktu

Każda roadmapa platformy, jaką recenzowałem, należy do jednego z dwóch gatunków. Pierwszy czyta się jak dokument produktowy: „skróć czas od merge'a do produkcji", „spraw, żeby sandbox zewnętrznego dostawcy przestał blokować QA", „zabij ręczne odnawianie certyfikatów, które spowodowało dwie awarie". Drugi czyta się jak lista życzeń infrastrukturalnych: „migracja na service mesh", „adopcja nowego API klastra", „ewaluacja build systemu następnej generacji".

Pierwszy gatunek zdobywa budżet i przychylność, bo zespoły produktowe widzą w nim własny ból. Drugi konkuruje z dostarczaniem produktu o zasoby, obiecując korzyści dostrzegalne tylko dla zespołu platformowego — i przegrywa tę konkurencję, najpierw powoli, potem nagle, przy najbliższym cyklu planowania.

Platforma istnieje po to, żeby wszyscy inni byli szybsi. Roadmapa, której nie da się wywieść z czyjegoś tarcia, to hobby z linią budżetową.

To nie znaczy, że praca infrastrukturalna jest nieuprawniona — migracja na mesh może być dokładnie tym, czego trzeba. To znaczy, że wpis w roadmapie musi być napisany w języku tarcia, które usuwa — bo to sformułowanie jest zarazem testem, czy cokolwiek usuwa.

Platforma jest produktem

Najbardziej użyteczna zmiana ramy dla zespołów platformowych: inżynierowie produktowi to Twoi użytkownicy — i mają alternatywy. Mogą budować cień własnych narzędzi, kopiować w nieskończoność tego jednego Jenkinsfile'a albo po cichu obchodzić Twoją złotą ścieżkę. Adopcja platformy jest w praktyce dobrowolna nawet tam, gdzie na papierze jest obowiązkowa — a traktowanie jej jako dobrowolnej produkuje lepsze platformy.

Potraktowanie ramy produktowej serio ma konkretne konsekwencje:

• Odkrywanie zamiast zakładania. Usiądź z zespołami produktowymi i obejrzyj deploy, incydent, onboarding. Tarcie, które obserwujesz, jest realne; tarcie, które pamiętasz z własnej ostatniej pracy produktowej, jest przeterminowane.
• Przyjmowanie zgłoszeń, które nie jest kolejką zguby. Zespoły produktowe potrzebują widocznej ścieżki od „to boli" do decyzji roadmapowej, z uczciwym tak, nie albo później — to cisza hoduje cień infrastruktury.
• Wygaszanie ze ścieżką migracji. Zabranie capability bez asystowanej ścieżki wyjścia to sposób, w jaki zespoły platformowe wydają lata zaufania w tydzień.

Mapuj capability platformy

Elementy roadmapy w kształcie projektów („migracja Terraform Q3") ukrywają swój cel. Zamiast tego grupuję pracę platformy w capability — deploy, obserwowalność, security, integracje, testowanie, recovery — bo capability ma użytkownika i obietnicę, co czyni widocznym zarówno postęp, jak i braki.

Capability: deploy
Użytkownik: inżynier produktowy
Obietnica: zmiana na produkcji poniżej 30 minut, rollback poniżej 5
Stan obecny: mediana 55 min, rollback ręczny i nieprzećwiczony
Adopcja: szablon usługi, dokumentacja, jedna zmigrowana usługa, office hours

Capability: obserwowalność
Użytkownik: inżynier na dyżurze
Obietnica: dashboard wpływu dowolnej usługi w 2 kliknięcia
Stan obecny: 60% usług na standardowym układzie dashboardu
Adopcja: moduł dashboard-as-code wpięty w szablon

Dwie właściwości czynią tę mapę użyteczniejszą niż lista projektów. Obietnica to poziom usługi, z którego zespoły produktowe mogą Cię rozliczać — a na takim zaufaniu odnawia się budżety. Linia stanu obecnego trzyma roadmapę w uczciwości: luka między obietnicą a stanem to właśnie roadmapa, widoczna dla wszystkich.

Układaj według wpływu na flow

Z zmapowanymi capability kolejność przestaje być polityką, a staje się arytmetyką. Pytanie dla każdego kandydata: ile powtarzalnego czekania, ryzykownej pracy ręcznej albo obciążenia supportem to usuwa — razy ile zespołów w to uderza i jak często?

Element oszczędzający każdemu zespołowi godzinę tygodniowo wygrywa z niszową optymalizacją nawet wtedy, gdy niszowa jest technicznie ciekawsza — a zwykle to właśnie ona jest ciekawsza, dlatego arytmetyka ma znaczenie. Dwie kategorie zasługują na stały priorytet poza kolejką: ryzykowne ręczne kroki na ścieżce krytycznej (to incydenty z odpalonym timerem) oraz wszystko, co generuje powtarzalne tickety wsparcia (każdy ticket to platforma oblewająca samoobsługę podwójnie — raz dla użytkownika, raz dla inżyniera, który odpowiada).

Adopcja jest wynikiem

Pułapka platformowa, którą widzę najczęściej: capability wychodzi, element roadmapy się zamyka, a pół roku później używają go trzy zespoły, podczas gdy dziewięć dalej robi po staremu. Według każdego standardu produktowego ta funkcja poległa — ale roadmapy platform rzadko to przyznają, bo definicją ukończenia było „wypuszczone".

Ja definiuję platformowe „done" inaczej: capability jest ukończona, gdy drugi zespół używa jej bez rozmowy z zespołem platformowym. Ta definicja wymusza mało efektowną pracę, która naprawdę napędza adopcję:

• Szablon albo moduł, który czyni właściwą drogę najkrótszą drogą.
• Dokumentacja pisana pod realny przypadek użycia, przetestowana na kimś, kto tej rzeczy nie budował.
• Jedna usługa produkcyjna zmigrowana przez sam zespół platformowy — implementacja referencyjna i test empatii w jednym ruchu.
• Jawne okno migracji z pomocą, a nie mail o deprecjacji z terminem.

Uczciwy pomiar flow

Metryki wynikowe platformy to metryki dostarczania: lead time zmian, częstotliwość wdrożeń, wskaźnik nieudanych zmian, czas przywrócenia. Jeśli platforma działa, te wskaźniki ruszają się u zespołów produktowych — mierzenie własnej prędkości zespołu platformowego mierzy głównie to, jak bardzo jest zajęty, a to nie to samo co użyteczny.

Obok wyników w stylu DORA śledzę dwa sygnały specyficzne dla platformy. Krzywe adopcji per capability — płaska krzywa to najwcześniejszy uczciwy feedback, że coś z capability jest nie tak, na długo zanim ktokolwiek złoży skargę. Oraz taksonomię ticketów wsparcia — rozkład tego, o co ludzie proszą, to rankingowa lista miejsc, gdzie samoobsługa zawodzi: aktualizowana ciągle i wolna od błędu ankiet.

Jak roadmapy platform upadają

• Przebudowa z wieży z kości słoniowej. Osiemnaście miesięcy budowania idealnej platformy v2, podczas gdy zespoły produktowe żyją z problemami v1. Gdy v2 ląduje, jej założenia są przeterminowane, a użytkownicy wrodzy. Zamiast tego wypuszczaj capability po capability, do istniejącego flow.
• Nakaz bez przewagi. Wymuszanie adopcji polityką, zanim capability będzie faktycznie lepsza od tego, co zespoły robią dziś. Zgodność następuje; zaufanie nie; kolejna capability startuje pod wiatr.
• Roadmapa pod CV. Wybory technologiczne napędzane tym, czego zespół platformowy chce się nauczyć. Czasem zbieżne z potrzebami użytkowników — ale tylko przypadkiem. Mapa capability obnaża to szybko, co jest kolejnym argumentem za mapą.
• Wszystko dla wszystkich. Platforma przyjmująca każdą prośbę zbiega do drugiej, gorszej wersji indywidualnego setupu każdego zespołu. Zdrowa roadmapa mówi „nie" albo „później" — widocznie i z powodami.

Podsumowanie

• Każdy wpis roadmapy pisz w języku tarcia produktowego, które usuwa — to sformułowanie jest zarazem testem.
• Traktuj inżynierów produktowych jak użytkowników z alternatywami; adopcja jest w praktyce dobrowolna.
• Grupuj pracę w capability z użytkownikiem, obietnicą i linią stanu obecnego — luka to roadmapa.
• Kolejność z arytmetyki flow: zasięg razy częstość razy usunięte tarcie, z ręcznym ryzykiem i generatorami ticketów poza kolejką.
• Done znaczy: drugi zespół zaadoptował bez pomocy — szablony, przetestowane doki i zmigrowana usługa referencyjna to prawdziwa praca.
• Mierz metryki dostarczania zespołów produktowych i krzywe adopcji, nie zajętość zespołu platformy.