Jak zarząd może nadzorować technologię bez wchodzenia w kod?
Inwestor pyta, co firma dostała za kilka milionów wydanych na IT. W odpowiedzi widzi listę wdrożonych funkcji, ale nie dowiaduje się, które z nich zwiększyły przychód, obniżyły koszty albo ograniczyły ryzyko. Tymczasem kolejne funkcje są coraz droższe, a zarząd słyszy, że na dokończenie zaplanowanego zakresu prac potrzeba jeszcze jednego kwartału.
Próba wejścia w szczegóły techniczne zwykle nie rozwiązuje tego problemu. Bez kontekstu nawet szczegółowy dashboard może wyglądać dobrze, podczas gdy zespół pracuje nad rzeczami drugorzędnymi. Żeby odzyskać kontrolę, nie musisz zaglądać do repozytorium. Potrzebujesz wspólnych priorytetów, trzech konkretnych pytań zadawanych regularnie i jasnej granicy między decyzjami technicznymi a biznesowymi.
W skrócie
|
Nie myl listy funkcji z kontrolą nad budżetem IT
Lista wykonanych zadań pokazuje aktywność zespołu. Nie pokazuje natomiast, czy firma dobrze inwestuje pieniądze. Zarząd powinien znać efekty pracy IT i związane z nią ryzyka, nawet jeśli nie rozumie ani jednej linijki kodu.
To normalne, że CEO lub CFO nie potrafi ocenić architektury systemu. Od tego są CTO, Tech Leadzi i seniorzy. Problem zaczyna się wtedy, gdy nikt nie przekłada ich decyzji na język zarządu. W takiej sytuacji zagłębianie się w szczegóły techniczne daje tylko więcej informacji. Nie zwiększa kontroli.
IT i biznes mogą skupiać się na różnych celach
Zespół techniczny może wzorowo pilnować wskaźnika, który przestał być ważny dla firmy. Dzieje się tak zwłaszcza wtedy, gdy priorytety zmieniają się szybciej niż sposób pracy.
Wyobraź sobie aplikację, której wydajność zespół poprawiał przez pół roku. Opóźnienia w końcu przestały przeszkadzać użytkownikom. Deweloperzy nadal jednak optymalizują czas odpowiedzi, bo przez wiele miesięcy właśnie z tego byli rozliczani. Tymczasem zarząd planuje pozyskać dziesięć razy więcej klientów i potrzebuje wiedzieć, czy system ich obsłuży.
Obie strony chcą, żeby produkt działał dobrze. Problem w tym, że każda koncentruje się na innym celu.
Podobny rozjazd pojawia się po zmianie celu strategicznego firmy. Wczoraj liczył się szybki wzrost i czas wejścia na rynek. Dzisiaj planowana runda finansowania nie doszła do skutku, więc trzeba oszczędzać. Albo firma osiągnęła rentowność i zamiast kolejnych eksperymentów potrzebuje stabilnej obsługi obecnych klientów. Jeśli zarząd nie nazwie tej zmiany, zespół będzie nadal pracował według starych priorytetów.
Wrzutki pogłębiają ten problem. Naprawa błędów zabiera czas przeznaczony na rozwój, więc zespół zaczyna poświęcać mniej czasu na dbanie o jakość. To prowadzi do kolejnych błędów. Pilne prośby biznesu działają podobnie. Jeśli zespół regularnie przyjmuje je poza ustalonymi priorytetami, szybko stają się normą. Po kilku miesiącach wszyscy są zajęci, liczba funkcji rośnie, a najważniejsze problemy klientów nadal czekają na rozwiązanie.
Najpierw powiedz, co jest ważne na obecnym etapie
Kierunek biznesowy wyznacza zarząd. IT odpowiada za jakość wykonania w ramach tego kierunku. Nie można rozliczać IT z tego, że biznes nie określił sensownego celu.
Dlatego zacznij od prostych ustaleń:
- Jaki zakres kosztów jest akceptowalny?
- Jak często firma chce wdrażać zmiany?
- Jaki kompromis wybieracie między szybkością, kosztem i jakością, skoro zwykle nie da się maksymalizować wszystkich trzech naraz?
Potrzebna jest też osoba odpowiedzialna za priorytety, najczęściej Product Manager lub Product Owner. Ktoś musi odróżniać ważną zmianę od głośnej prośby i pilnować, co wypada z planu, gdy wpada coś nowego. Zespół techniczny powinien przy tym regularnie zbierać feedback od klientów (a nie raz na kilka miesięcy).
Nie próbuj zastępować zarządzania priorytetami kontrolą aktywności. Liczenie ruchów myszką, godzin przy komputerze albo zużytych tokenów szybko nauczy ludzi optymalizować wskaźnik zamiast wyniku.
Zadaj IT trzy pytania, które dadzą zarządowi potrzebne dane
Dobry nadzór nie wymaga dwudziestu wskaźników. Wystarczy kilka odpowiedzi, ale trzeba je odczytywać w kontekście planów firmy. Nawet popularne metryki DORA, takie jak częstotliwość wdrożeń czy odsetek wdrożeń powodujących problemy, niewiele znaczą bez trendu i kontekstu.
Te same liczby mogą przecież oznaczać zarówno szybki wzrost pod kontrolą, jak i sytuację, w której zespół tę kontrolę traci. Dlatego rozmowę warto oprzeć na trzech poniższych pytaniach.
Czy to, co robimy, ma wartość?
Najpierw sprawdź, czy praca zespołu prowadzi do oczekiwanego efektu biznesowego. Nie pytaj wyłącznie, ile zadań zakończono. Zapytaj, jaki problem rozwiązały.
Sprawdź, czy to, czego pilnuje zespół, pokrywa się z tym, co tworzy wartość dla firmy: zwiększa przychód, obniża koszty albo ogranicza ryzyko. Jeśli najważniejsza jest rejestracja nowych klientów, ktoś powinien monitorować całą tę ścieżkę. Wysoka dostępność strony głównej nie pomoże, gdy formularz rejestracji po cichu odrzuca część zgłoszeń.
Sprawdź też, jak czas całego zespołu rozkłada się między ustalone priorytety, błędy i pilne prośby. Sam podział czasu jeszcze o niczym nie przesądza. Nagły wzrost udziału wrzutek jest jednak dobrym powodem, by zapytać o przyczynę. Być może jakość spada. Być może biznes regularnie omija ustalone priorytety. To dwie różne sytuacje i każda wymaga innej reakcji: poprawy jakości albo uporządkowania sposobu ustalania priorytetów.
Headroom, tempo i stabilność bez repozytorium
Drugie pytanie brzmi: czy technologia pozwoli zrealizować plany firmy na najbliższe miesiące? Trzeba to przełożyć na konkretny scenariusz: obsługę nowych klientów, szybsze wdrażanie zmian albo stabilną obsługę obecnych klientów.
Jeśli sprzedaż planuje pozyskać pięciu dużych klientów, IT powinno przełożyć ten plan na spodziewany wzrost obciążenia i dać znać, czy obecny system go obsłuży oraz jak wpłynie to na koszty infrastruktury. Różnicę między obecnym obciążeniem a granicą, przy której system zacznie mieć problemy, nazywa się headroomem. Nie potrzebujesz liczby z laboratoryjną dokładnością. Potrzebujesz pewności, że handlowcy nie sprzedadzą czegoś, czego produkt nie będzie w stanie obsłużyć bez czterech miesięcy przebudowy.
Zapytaj również, czy zespół może dziś bezpiecznie wdrożyć zmianę na produkcję. Jak często to robi? Ile wdrożeń powoduje problemy? Czy z miesiąca na miesiąc wyniki są lepsze czy gorsze?
Stabilność ma wymiar finansowy. Liczą się nie tylko dostępność i liczba incydentów, lecz także reklamacje, kary za niedotrzymanie gwarantowanego poziomu usług (SLA) oraz czas obsługi klientów dotkniętych awarią. Ważne jest też źródło informacji. Jeśli o awarii pierwszy informuje klient, straty rosną, zanim zespół w ogóle zacznie usuwać awarię. Warto więc sprawdzić, czy zespół potrafi wykrywać problemy, zanim zgłoszą je użytkownicy.
Dług techniczny też trzeba opisać językiem biznesu. „Mamy słabe testy” niewiele mówi zarządowi. „Przez braki w testach każda zmiana trwa dwa razy dłużej” daje już podstawę do porównania kosztu naprawy z kosztami, które generuje jej dalsze odkładanie.
Spadające morale zespołu może być wczesnym sygnałem ostrzegawczym. Inżynierowie zwykle wcześniej widzą, że system traci stabilność albo że każda zmiana wymaga coraz więcej wysiłku. To sygnał do rozmowy, nie wskaźnik dla HR.
Sprawdź, na co idą pieniądze, zanim dopłacisz
Trzecie pytanie łączy wydatek z rezultatem: ile wydajemy, na co dokładnie i co otrzymujemy w zamian?
Raport z dotychczasowych kosztów nie wystarczy. Zarząd potrzebuje także aktualnej prognozy, ile będzie kosztować osiągnięcie najbliższego celu biznesowego. Gdy pojawia się nowe wymaganie, powinien zobaczyć jego wpływ na budżet, termin i pozostałe priorytety. Jeśli nowe wymaganie nie mieści się w obecnym planie i dostępnych zasobach, trzeba zmienić co najmniej jedno: zakres, kolejność priorytetów, termin albo budżet.
Załóżmy, że ważny klient prosi o nowy sposób raportowania. Zespół może zająć się tym od razu, ale wtedy opóźni integrację potrzebną trzem innym klientom. Decyzja nie brzmi więc: „czy budujemy nowy system raportowania?”. Brzmi: „czy warto przesunąć daną integrację o miesiąc, aby zadowolić tego klienta?”. Dopiero tak opisany wybór należy do zarządu.
Ustal progi dla dodatkowych kosztów, opóźnień i zmian zakresu. Po ich przekroczeniu zespół musi wrócić z tematem do zarządu. Rozmowa ma się odbyć przed rozpoczęciem dodatkowej pracy, a nie po wystawieniu faktury. Dzięki temu CFO może wybrać: dopłacić, ograniczyć zakres, przesunąć termin albo zatrzymać inwestycję.
Te trzy pytania nie zastąpią pełnego nadzoru nad projektem. Pozwolą jednak wychwycić moment, w którym technologia przestanie wspierać plan firmy.
Wymagaj analizy wariantów przy decyzjach, których cofnięcie będzie kosztowne
Zarząd nie powinien zatwierdzać wyboru bibliotek ani każdej decyzji architektonicznej. Powinien włączyć się wtedy, gdy rozważane rozwiązanie wymaga dużego budżetu, wiąże się z dużym ryzykiem albo trudno je później cofnąć.
Do tej grupy należą duże migracje, przebudowa istotnej części systemu, zmiana dostawcy lub wybór między chmurą a własną infrastrukturą. Podobnie jest z kluczowymi integracjami, wielkością zespołu i wyborem nietypowej technologii, która utrudni później rekrutację.
Także vendor lock-in, czyli uzależnienie od jednego dostawcy, wymaga decyzji biznesowej. Czasem warto wdrożyć rozwiązanie szybciej i zaakceptować, że zmiana dostawcy w przyszłości będzie trudniejsza. Innym razem wyższy koszt na początku daje firmie więcej swobody później. IT powinno opisać te konsekwencje. Zarząd powinien zdecydować, jakie ryzyko akceptuje.
Jak przygotować analizę, która pozwoli zarządowi podjąć decyzję
Dobra rekomendacja może mieć formę krótkiej analizy wariantów. Zespół przedstawia opcje A i B, ich zalety i wady, a następnie wskazuje preferowany kierunek.
Każdy wariant powinien odpowiadać na te same pytania:
- ile potrwa,
- ile będzie kosztował,
- co firma zyska,
- jakie ryzyka tworzy i jak prawdopodobne są najważniejsze z nich,
- jak duże straty mogą spowodować te ryzyka, jeśli wystąpią,
- jak trudno będzie później wycofać się z tej decyzji.
Potrzebna jest również rekomendacja Tech Leada lub CTO wraz z uzasadnieniem uwzględniającym obecny etap rozwoju firmy.
Wtedy zarząd może zaakceptować rekomendację, wybrać drugi wariant albo poprosić o połączenie ważnych elementów obu opcji. Dostaje materiał, na podstawie którego może podjąć decyzję, zamiast wykładu o stacku technologicznym.
Taka komunikacja jest jednym z najważniejszych zadań CTO lub doświadczonego Tech Leada. Nie oznacza to jednak, że firma od razu musi zatrudniać kogoś specjalnie do tej roli. Najpierw warto sprawdzić, czy ktoś w obecnym zespole może wziąć odpowiedzialność za komunikację między technologią a biznesem.
Zacznij od diagnozy produktu, zanim sięgniesz po zewnętrzne wsparcie
Gdy odpowiedzi na trzy powyższe pytania są niejasne, poproś własny zespół o diagnozę opartą na dowodach, a dopiero później rozważ wsparcie z zewnątrz.
Możesz przekazać zespołowi naszą checklistę zdrowia produktu i poprosić, żeby opisał wynik w kategoriach ryzyka. Ta checklista pomaga ocenić między innymi kierunek produktu, sposób badania potrzeb, delivery, jakość, współpracę z interesariuszami oraz odpowiedzialność za wynik.
Jeśli diagnoza pokaże poważne problemy albo nikt nie będzie potrafił wyjaśnić, jakie koszty i ryzyka z nich wynikają oraz jakie decyzje trzeba na tej podstawie podjąć, warto porozmawiać z naszym CEO lub CTO. W ciągu 30 minut pomożemy ci zweryfikować twoją ocenę sytuacji i skonfrontować ją z doświadczeniem osoby, która łączy perspektywę technologiczną z biznesową. Bez czytania kodu i bez zakładania z góry, że potrzebujesz dużego projektu naprawczego.
Podsumowanie
Nie musisz rozumieć kodu, żeby nadzorować technologię. Musisz wiedzieć, czy zespół tworzy wartość, czy system pozwoli zrealizować plany firmy i za co płacisz. Przy decyzjach drogich lub trudnych do cofnięcia potrzebujesz wariantów, liczb i rekomendacji.
Najdrożej robi się wtedy, gdy problem wychodzi na jaw dopiero po fakcie, bo wtedy pole manewru jest już znacznie mniejsze. Dlatego regularnie wracaj do trzech pytań: czy praca zespołu generuje wartość, czy technologia pozwoli zrealizować plany firmy i czy wydatki odpowiadają osiąganym efektom.
