„W tym roku dowieźliśmy więcej funkcji niż w zeszłym. Przychodów z tego nie widziałem”. Tak odpowiedział Head of Product, kiedy Tomáš, VP of Engineering, obiecał zarządowi trzy razy większą przepustowość. Business case dla platform engineering, czyli uzasadnienie biznesowe dla zespołu platformowego, to prośba, która przetrwa taką odpowiedź: oddaj mi jeden kwartał roadmapy, a w ciągu trzech kolejnych pokażę zwrot, w pieniądzach.
Tomáš (to nie jego prawdziwe imię) kieruje inżynierią w firmie B2B SaaS. Jego zespoły platformowe spędzają 60% czasu na utrzymaniu produkcji, 2% na otwieraniu swoich komponentów dla innych zespołów i 38% na budowaniu funkcji. Zespoły produktowe bez nich nie ruszą, więc każda inicjatywa obejmująca kilka zespołów czeka w czyjejś kolejce.
Jego prezentacja była dobra. Zależności narysowane jak spaghetti, autonomiczne zespoły, cel 3x. Każda liczba w niej była procentem.
Brakowało jednego slajdu i powiedziałem mu to wprost. W całej prezentacji nie było ani jednego dolara. Raport Stripe „The Developer Coefficient” pokazał, że programiści spędzają 17,3 godziny z 41,1-godzinnego tygodnia na utrzymaniu, złym kodzie i długu technologicznym (technical debt). Twój zarząd już płaci ten rachunek, więc pokaż mu fakturę.
Zarząd finansuje datę zwrotu
Zapytaj ChatGPT, jak zdobyć finansowanie na zespół platformowy, a powie Ci, żeby „przestać sprzedawać to jako usprawnienie inżynierii i zacząć sprzedawać jako inwestycję biznesową”. Słusznie, tylko że to za mało. Inwestycja bez daty to życzenie.
Więc podaj datę. „Daj mi połowę Q1. Odzyskasz ją do końca roku, a od tego momentu jedziemy szybciej”. Nie żebrzesz o czas na platformę. Jesteś VP, który sprzedaje inwestycję.
Procent zaprasza do targowania się o procent. Data zwrotu, czyli okres zwrotu (payback period) przełożony na kalendarz, zaprasza do decyzji, a decyzja należy do ludzi przy stole. Właśnie tam chcesz ją mieć.
Rachunek jest wystarczająco duży, żeby to udźwignąć. Dyrektorzy IT (CIO) w badaniu McKinsey przyznali, że od 10 do 20% budżetu technologicznego przeznaczonego na nowe produkty idzie na spłatę długu technologicznego.
Tomáš miał szczęście. Jego CEO w weekend przed wyjazdowym spotkaniem zarządu przeżył własny moment „pociąg odjeżdża bez nas” i był gotów rozbić roadmapę. Ale mandatu nie dostaje się po godzinie rozmowy, a slajd ze zwrotem to ten, z którym wracasz raz za razem. W Mews i w firmach, którym doradzam od tamtej pory, widziałem, że ta walka trwa od pół roku do roku, zanim ludzie zrozumieją: nie sprzedajesz wolniejszej roadmapy, tylko przyspieszasz firmę.
Zanim poprosisz o czas, zmierz, dokąd on idzie
Nie sprzedasz daty zwrotu, jeśli o dzisiejszym stanie tylko zgadujesz. Pierwszy slajd pokazuje, dokąd idzie czas teraz, a liczby muszą pochodzić od zespołów, nie od Ciebie.
Pięć koszyków: planowane i nieplanowane
Podziel czas każdego zespołu na pracę nad roadmapą, inwestycję w platformę, reaktywną pracę na produkcji (incydenty, dyżury, hotfixy), eskalacje od klientów i pomoc innym zespołom. Pierwsze dwa koszyki są planowane, trzy ostatnie w większości nie. Udział pracy nieplanowanej to Twoja liczba na nagłówek: pokazuje, ile miejsca na roadmapę Twoje zespoły naprawdę mają.
Bez timesheetów
Każdy Team Lead rozpisuje czas swojego zespołu w osobodniach na pięć koszyków. Piętnaście minut, dokładność ±10% wystarczy. Przez dwa tygodnie rób to jako pilotaż, potem przejdź na kroczące sześć tygodni, bo jeden duży incydent potrafi kompletnie wypaczyć dwa tygodnie.
Zapisz, kto zlecił
Przy każdym koszyku zapisz, który dział zlecił tę pracę. Wtedy moce przerobowe stają się budżetem, który rozdzielasz: „Twój dział ma w tym kwartale 400 osobodni, sam decydujesz, co w nie wejdzie”. Nowa prośba staje się wymianą, a spór o priorytety przechodzi do ludzi, którzy za te priorytety odpowiadają.
Zamień dni na pieniądze
Liczba osobodni razy pełny koszt dnia pracy. To liczba, którą czyta CFO. Jeśli wycena decyzji inżynierskiej dla zarządu to dla Ciebie nowość, mniejszą wersję tego rachunku opisałem w tekście o tym, jak rozmawiać z zarządem.
Tak wyglądał pomiar i cel Tomáša. To liczby jednej prawdziwej firmy, zanonimizowane. Cel dla zespołów produktowych jest celem, nie pomiarem.
| Typ zespołu | Praca | Dziś | Cel |
|---|---|---|---|
| Zespoły platformowe | Utrzymanie produkcji | 60% | 30% |
| Zespoły platformowe | Otwieranie komponentów dla innych zespołów | 2% | 50% |
| Zespoły platformowe | Funkcje dla klientów | 38% | 20% |
| Zespoły produktowe | Utrzymanie produkcji | 35% | 10% |
| Zespoły produktowe | Zmiany w platformie (przez kontrybucję) | 3% | 10% |
| Zespoły produktowe | Funkcje dla klientów | 62% | 80% |
Spójrz na ostatni wiersz. Zespoły produktowe już dziś spędzają 62% czasu na funkcjach.
Hamuje je 35%, które spędzają z głową odwróconą w stronę produkcji, i kolejka, w której stoją do platformy. Więcej czasu na funkcje to efekt uboczny usunięcia tych dwóch rzeczy. Jeśli przed zbudowaniem tego slajdu chcesz spojrzenia z zewnątrz na to, dokąd idzie czas Twoich zespołów, do tego służy audyt produktywności zespołów inżynierskich.
Punkt odniesienia spoza jednej firmy: zasada Marty’ego Cagana z SVPG daje inżynierii 20% mocy przerobowych na starcie, a więcej, gdy system jest w złym stanie.
Zespół platformowy buduje funkcje na końcu
Kolejność priorytetów Tomáša dla zespołów platformowych: najpierw produkcja, potem otwieranie komponentów, funkcje na końcu. 30% na produkcję to pożądany udział, nie limit: kiedy produkcja płonie, produkcja wygrywa.
Dlaczego funkcje na końcu? Dziesięć autonomicznych zespołów, które potrzebują tych samych pięciu osób ze wspólnego rdzenia, to nie dziesięć równoległych strumieni pracy. Przez kilka tygodni jadą szybko, a potem znowu czekają na code review, odpowiedzi i zależności.
Kolejka tylko się przesunęła. Badania DORA nazywają to „downstream disorder”: zyski z szybszego pisania kodu zjadają wąskie gardła w testach, przeglądach bezpieczeństwa i dalej.
Zamknij 10%, otwórz 90%
Mały zestaw komponentów zostaje w całości w rękach właściciela: uwierzytelnianie, autoryzacja, prywatność, czyli miejsca, w których chcesz być ostrożny. W planie Tomáša to około 10% zmian. Pozostałe 90% staje się „własnym, ale otwartym”: właściciel rozdziela zależności, dokumentuje, spisuje intencje i ograniczenia, dodaje testy i buduje bezpieczne ścieżki, żeby każdy zespół mógł kontrybuować bez psucia rdzenia.
Kontrybucja działa w obie strony
Zespoły produktowe zmieniają platformę, kiedy tego potrzebują. Zespoły platformowe zmieniają kod produktowy, kiedy wymaga tego produkcja, na przykład, gdy coś pada albo nie wyrabia wydajnościowo. Obie strony muszą się pogodzić z tym, że w ich kodzie grzebie ktoś inny. Po latach silnej własności każdy komponent w firmie Tomáša obrósł biurokracją, a on chce się pozbyć 90% tych procedur.
Nie buduj do szuflady
Żadnej funkcji platformy „bo może się przyda za trzy lata”. Buduj to, czego zespół potrzebuje teraz. Platforma idzie tam, dokąd idą zespoły produktowe, a nie wybiega przed nie.
Mierz platformę tym, jak szybko biegną inni
Zespoły platformowe ocenia się po tym, o ile szybciej dowożą zespoły produktowe, a nie po tym, co same zbudowały. Tak w praktyce wygląda zespół platformowy w ujęciu Team Topologies: wewnętrzny produkt, który istnieje po to, żeby przyspieszać zespoły stream-aligned, czyli te, które dowożą zmiany prosto do klienta. Jeśli chcesz zrozumieć samą rolę, opisałem ją w tekście o roli platform engineera.
Głos przeciwny zasługuje na uczciwe wysłuchanie. Raport DORA 2024 pokazał 6% wzrostu produktywności zespołu przy dedykowanym zespole platformowym i 8% spadku przepustowości wśród tych, którzy z platformy korzystają. Źle zrobiona platforma Cię spowalnia i właśnie dlatego mierzysz ją szybkością innych zespołów, a najpierw udowadniasz ją na jednym zadaniu.
Zamień procenty na pieniądze: slajd jeden za trzy
To slajd, którego Tomáš nie miał. Składają się na niego trzy liczby.
Ile kosztuje ten kwartał
Liczba osobodni zdjętych z roadmapy razy pełny koszt dnia pracy. To Twoja inwestycja, w pieniądzach.
Kiedy to wraca
Część roadmapy, którą tracisz w kwartale inwestycji, zestawiona z tym, co odzyskujesz potem, kwartał po kwartale, aż narastające saldo wyjdzie na plus. Licz się z tym, że przez mniej więcej dwa miesiące zespoły zwolnią albo prawie staną, bo będą wdrażać nowe narzędzia i nowy sposób pracy. Napisz to wprost na slajdzie: zwalniamy, żeby potem przyspieszyć.
Nie zgaduj przyspieszenia. Weź je z pilotażu (o nim w następnej sekcji): to, co pokaże zadanie referencyjne przy pierwszym odczycie, jest Twoją liczbą na Q2, i nie ekstrapolujesz dalej, niż pilotaż udowodnił.
Ile to jest warte
Twój CPO powinien wiedzieć, ile przychodu generujecie co kwartał i ile z tego przypada na nowe funkcje. To Twoja cena za kwartał roadmapy. Wpisz wynik na slajd jako hipotezę, ale liczbę wpisz. Wtedy ludzie przestają debatować, czy w ogóle się na to zgodzić.
Tak wygląda kształt tego rachunku, na liczbach wymyślonych na potrzeby tego tekstu (przykład, a nie dane Tomáša). Wynik liczę w „dzisiejszych kwartałach”, gdzie 1,0 to kwartał taki jak obecny, a nowe funkcje przynoszą 3 mln USD przychodu na kwartał.
| Kwartał | Dowieziona roadmapa | Narastające saldo | Dodatkowy przychód względem dziś, jeśli adopcja się utrzyma |
|---|---|---|---|
| Q1, inwestycja | 0,5 | −0,5 | −1,5 mln USD |
| Q2 | 1,2 | −0,3 | +0,6 mln USD |
| Q3 | 1,4 | +0,1, punkt zwrotu | +1,2 mln USD |
| Q4 | 1,6 | +0,7 | +1,8 mln USD |
Jeden kwartał oddajesz, trzy potrzebujesz, żeby go odzyskać: pod koniec Q4 jesteś 0,7 kwartału do przodu, czyli około 2,1 mln USD. Jeśli w drugim roku utrzymasz tempo z Q4, każdy kwartał daje 0,6 kwartału dodatkowego wyniku, około 7,2 mln USD rocznie.
Przeczytaj jeszcze raz nagłówek ostatniej kolumny. „Jeśli adopcja się utrzyma” to zarzut Head of Product, wpisany na Twój własny slajd. I to dlatego istnieje następna sekcja.
Prace nad niezawodnością i bezpieczeństwem też dostają liczbę przychodową. ValueSum Jade’a Rubicka ocenia dowiezioną pozycję tak, że 100 punktów oznacza dodanie 100% ARR w ciągu roku, pomnożone przez prawdopodobieństwo sukcesu. Jego przykład z niezawodnością, krok po kroku:
| Krok | Wynik |
|---|---|
| Jedna trzecia klientów może odejść przez tę niestabilność | 33 |
| To raczej duzi klienci, więc w praktyce chodzi o około 45% przychodu | 45 |
| Realne ryzyko odejścia na klienta to około 20%: 45 × 20% | 9 |
| Szkody wizerunkowe podwajają wynik: 9 × 2 | 18 |
Rubick daje Ci też argument za stałym udziałem platformy zamiast walki o każdy projekt osobno: „pewien procent każdej organizacji inżynierskiej powinien zajmować się rzeczami, które z czasem czynią organizację bardziej efektywną”, bo taka praca „zwykle dostaje za mało”, jeśli optymalizujesz wyłącznie pod dowiezioną wartość.
„Dowieźliśmy więcej, a przychody stoją” to słuszny zarzut
Head of Product miał rację. To, że przyspieszymy maszynę, nie znaczy, że w tym tempie będziemy dowozić właściwe rzeczy. Raport Pendo o adopcji funkcji pokazał, że 80% funkcji w przeciętnym produkcie software’owym jest używanych rzadko albo wcale.
Business case potrzebuje więc drugiego właściciela. Opowiedziałem Tomášowi, jak robiliśmy to w Mews, gdzie jako VP of Engineering rozwinąłem inżynierię z 8 do 80 zespołów. Mój KPI, ten, z którego byłem znany: co kwartał dowoziłem co najmniej 80% roadmapy. Gdybym nie dowiózł, mogli mnie zwolnić.
Mierzyłem to jako wkład w roadmapę: jaki procent czasu moich zespołów idzie na roadmapę, a jaki poza nią. Dwa zespoły pracujące poza roadmapą, z jakiegokolwiek powodu, stawiały pod znakiem zapytania cały kwartał. Swoich liderów uczyłem zasady, według której sam żyłem: jeśli nie dowieziesz mi roadmapy, ja też mam problem.
Mój odpowiednik po stronie produktu miał inny KPI. „Dzięki, Marianie, że zbudowałeś mi szybką maszynę. Ale to ja muszę do niej coś wrzucać”. Jego zadaniem było karmić moją roadmapę rzeczami, które mają znaczenie, mierzonymi adopcją produktu. Celowo ustawiliśmy to tak, żebyśmy byli parą bliźniaków.
Szybsza maszyna sama niczego nie sprzeda. Ktoś musi odpowiadać za to, co do niej wpada.
Każda inicjatywa była przypisana do kwartału i miała w Jira własne pole z oceną adopcji. Przyznaję, ocenialiśmy ręcznie, żadnej automatycznej metryki nie było:
| Ocena | Co oznacza | Liczy się do 65%? |
|---|---|---|
| Bardzo wysoka | Zarabia dla nas dużo pieniędzy | Tak |
| Wysoka | Zgodnie z oczekiwaniami | Tak |
| Neutralna | Zarabia tyle, ile kosztowała: ludzie, licencje, infrastruktura | Nie |
| Katastrofa | Nie zarabia na swój koszt | Nie |
| Do oceny | Za wcześnie na ocenę, dozwolone najwyżej przez jeden kwartał | Nie |
Wyczucie czasu to część dobrej decyzji produktowej, więc nic nie zostaje bez oceny dłużej niż kwartał.
Ja miałem 80% dowiezionej roadmapy. Lider produktu obok mnie miał 65% adopcji produktu, czyli ocen wysokich albo bardzo wysokich. Czekanie się nie liczy, bo czekanie nie generuje pieniędzy.
I szczerze mówiąc, krzyczeliśmy na siebie. „Trzymam dla Ciebie szybką roadmapę, a Ty wrzucasz do niej śmieci? Potem moi ludzie są niezadowoleni i ktoś odchodzi”.
Czasem mówiłem, że coś nie ma miejsca na roadmapie. Czasem on chciał oznaczyć coś jako sukces, a ja mówiłem, że to raczej nie jest sukces. Ale wtedy masz już sensowne dyskusje, o wartości.
Rubick dochodzi do tego samego miejsca z drugiej strony. Zaleca ponowną ocenę każdej funkcji trzy albo sześć miesięcy po dowiezieniu i zachowanie obu ocen, przewidywanej i wstecznej. Dwie kolejne zasady z tej pracy skopiowałbym od razu: wartość oceniają liderzy produktu albo działów, nie inżynieria, a oceny nie używa się do oceniania ludzi ani zespołów.
Tomášowi nie udało się jeszcze uzgodnić KPI adopcji na samej górze, więc jego wersja bliźniaków działa poziom niżej: każdy autonomiczny obszar dostaje Product Managera i Engineering Managera, którzy razem odpowiadają za jeden wynik biznesowy. Taka para powinna istnieć na każdym poziomie: zespół, dyrektor, VP, CTO i CPO. Jeśli jako Engineering Director ustawiasz to poniżej poziomu VP, Twój odpowiednik po stronie produktu jest Twoim bliźniakiem.
Udowodnij to na jednym zadaniu, zanim poprosisz o całą organizację
Tomáš sam napisał małą zmianę w kodzie, pierwszą od dwóch lat. Powinna zająć trzy godziny. Code review, pipeline’y i brak informacji o tym, jak zmiana uderzy w klientów, zrobiły z niej dzień pracy, a bramki wdrożeniowe rozciągnęły samo wdrożenie do tygodnia.
To zadanie stało się punktem odniesienia, czyli benchmarkiem:
| Zadanie referencyjne | Dziś | Koniec pilotażu | Docelowo |
|---|---|---|---|
| Development | 1 dzień | ~4 godziny | 2 godziny |
| Wdrożenie | 1 tydzień | kilka dni | 2 godziny |
Na pilotaż wyznaczył jeden cel. Do pierwszego odczytu 60% punktów tarcia na ścieżce tego zadania ma się poprawić. Każdy z nich jest mały: godzina tu, pół godziny tam, piętnaście minut gdzie indziej.
Jeśli Twoje zespoły pracują z agentami AI, lista punktów tarcia obejmuje też to, czego agent nie potrafi: zauważyć wolnego endpointu, zanim zauważy go klient, znać historii produktu, uruchomić instancji deweloperskiej, obserwować wdrożenia.
Na pilotaż wybierz spokojny zespół
Tomáš zaczął od zespołu z lekką roadmapą, żeby pilotaż nie zabił planu. Punkt odniesienia jest Ci potrzebny wcześniej niż transformacja.
Pożycz mu SWAT od narzędzi
Mała grupa od narzędzi buduje to, czego zespół pilotażowy nie zbuduje sam: feature flagi, szybsze pipeline’y, cokolwiek wyjdzie z listy punktów tarcia. Po pilotażu SWAT staje się zwykłym zespołem z większą liczbą ludzi.
Przytnij obszary do liderów, których masz
Tomáš skrócił listę kandydatów na obszary dla autonomicznych zespołów z 18 do 5. Każdy obszar potrzebuje mocnego lidera po stronie inżynierii i mocnego lidera po stronie produktu, a Tomáš ma pięć takich par. Obecni liderzy biorą mniej obszarów, za to szerszych, bez nowej warstwy zarządzania.
Business case w sześciu slajdach: przykład i co bym dodał
Z taką prezentacją chciałbym, żeby Tomáš wszedł na salę. Każdy slajd odpowiada na jedno pytanie, które zarząd i tak zada.
| Slajd | Na jakie pytanie odpowiada | Co na nim jest |
|---|---|---|
| 1. Ile kosztuje dziś | Na co idą nasze pieniądze na inżynierię? | Podział mocy przerobowych, udział pracy nieplanowanej, w pieniądzach, według zlecającego działu |
| 2. Dlaczego jesteśmy wolni | Dlaczego więcej ludzi nas nie przyspiesza? | Wspólne komponenty, na które czeka każdy zespół |
| 3. Kontrakt | Na co zespoły będą poświęcać czas zamiast tego? | Docelowy podział dla każdego typu zespołu, zasada 90/10, raport co sprint |
| 4. Wymiana | Z czego rezygnujemy i kiedy to wraca? | Koszt kwartału, narastające saldo, przychód, jeśli adopcja się utrzyma |
| 5. Papierek lakmusowy | Skąd będziemy wiedzieć, zanim postawimy na to całą organizację? | Zadanie referencyjne, zespół pilotażowy, data pierwszego odczytu |
| 6. Kto odpowiada za wynik | Kto sprawi, że szybsza maszyna zacznie zarabiać? | KPI dowożenia, KPI adopcji, imienni właściciele, skala ocen |
Konspekt, arkusz mocy przerobowych i arkusz zwrotu spakowałem do darmowego zestawu: pobierz zestaw z szablonem business case dla platformy (zip, 16 KB: Markdown, Word i trzy arkusze CSV, na razie po angielsku, bez podawania e-maila).
Przynieś propozycję, nie samą fotografię stanu. Sam stan zachęca do pytania „czemu tyle na wsparcie?”, a potem decyduje ktoś inny. Niech dane zbierają Twoi dyrektorzy. Twoje zadanie to je zinterpretować i zaproponować jedną zmianę.
Co sprint raportuj kontrakt względem rzeczywistości. Co kwartał moje 100% było podzielone na trzy uzgodnione pudełka, produkt, technologię i całą resztę, i sprawdzałem je w każdym sprincie. Kiedy rozjazd rośnie, właściwa decyzja bywa paradoksalna: zatrzymaj prace techniczne na dwa sprinty i rób produkt, żeby wrócić do równowagi.
A najtrudniejsze przychodzi po „tak”. Nie wszyscy się przestawią, bo albo nie biorą na siebie odpowiedzialności, albo nie potrafią pracować w parze i mają za duże ego. Kilka z tych osób będzie musiało odejść.
Tomáš wyszedł ze zgodą na start pilotażu. Pierwszy odczyt jeszcze przed nim, więc liczb z jego zadania referencyjnego nie mogę Ci jeszcze pokazać. Kiedy się pojawią, dopiszę je tutaj. Co powie Twój zarząd, kiedy poprosisz o jeden kwartał i obiecasz trzy z powrotem? Jeśli chcesz zbudować ten slajd razem ze mną, zanim go pokażesz, do tego służy mój mentoring dla CTO.
