Przyśpieszaj uruchamianie, zamiast tylko dostarczać
Celem dostarczania produktów jest to by ostatecznie wyszła z tego określona wartość:
Dla klienta – rozwiązane problemy
Dla biznesu - więcej $😃
Jednak szybsze dostarczanie rozwiązania != szybsze dostarczanie wartości. Powód? Nie wystarczy tylko dostarczyć – trzeba jeszcze uruchomić. A przykłady z życia pokazują, jak odmienne to są procesy.
W ramach rozszerzenia tego artykułu przygotowałem dla Ciebie tablicę Miro. Może być przez Ciebie traktowana jako wstęp do dyskusji o tym, co wymagane jest by uruchomić daną usługę. Będziemy się do niej odnosić dalej, ale jeśli przyszedłeś tylko po to podsumowanie, to link znajdziesz tutaj:
https://miro.com/app/board/uXjVLF0JQGE=/
Dostarczenie to dopiero początek
W wielu zespołach panuje przekonanie, że najważniejsze to napisać kod i wrzucić go na produkcję. Zapominają jednak, że samo wdrożenie nie generuje jeszcze żadnych przychodów.
Skupianie się jedynie na rozwiązaniu prowadzi do typowych problemów operacyjnych:
Kod jest gotowy, ale czekamy tydzień na tłumaczenia.
Nikt nie wie, jak skonfigurować nową funkcję na produkcji.
Brakuje kluczy do systemu zewnętrznego, bo nikt o nie nie zapytał.
Uruchamiamy testowo i nie wiemy, jak zweryfikować, czy działa, jak powinno.
Support nie wie, jak wprowadzić klienta w nowe rozwiązanie.
Każdy z tych problemów znacząco opóźnia moment, w którym rozwiązanie zacznie faktycznie działać (i zarabiać)
Szersza perspektywa
Aby dostarczać realną wartość, musimy zacząć od zmiany podejścia do procesu uruchamiania. Sam development to tylko jeden z etapów na drodze do sukcesu. Po nim następuje jeszcze uruchomienie ze wszystkimi dodatkowymi działaniami.
W newsletterze "Value-Stream Mapping" opisywałem, jak wykorzystać tę technikę by zidentyfikować wszystkie etapy procesu:
Przygotowanie środowiska i konfiguracji
Development i weryfikacja jakości
Zgody i certyfikaty zewnętrzne
Tłumaczenia i treści do publikacji
Testy na produkcji z małą grupą klientów
Szkolenia dla supportu i dokumentacja
Właściwe uruchomienie na podstawie metryk
Dopiero obserwując cały ten proces, dostrzeżemy prawdziwe koszty pracy. Development to z reguły tylko jego ułamek. Pozostałe działania, takie jak konfiguracja, testy czy szkolenia, nierzadko zajmują nawet więcej czasu i zasobów. Dopiero uwzględniając te wszystkie aspekty, jesteśmy w stanie realnie oszacować czas potrzebny do uruchomienia danej funkcji.
Warto też zauważyć, że etapy te nie zawsze następują po sobie sekwencyjnie. Wiele rzeczy możemy wykonywać równolegle - na przykład tłumaczenia mogą powstawać w trakcie developmentu. Dzięki takiemu podejściu skracamy całkowity czas dostarczenia wartości.
Co warto brać pod uwagę od początku
Aby uniknąć przykrych niespodzianek podczas uruchamiania, warto na starcie przeprowadzić dokładną analizę wymagań. Przygotowałem dla Was tablicę Miro, którą możecie wykorzystać do przeprowadzenia takich warsztatów z zespołem. Poniżej znajdziesz szybką ściągawkę - kluczowe obszary wraz z pytaniami, które warto sobie zadać.
Konfiguracja i parametryzacja
Jakie flagi feature'owe będą potrzebne?
Które parametry muszą być konfigurowalne per środowisko?
Jak będziemy zarządzać konfiguracją dla różnych rynków?
Kto ma mieć dostęp do zmiany konfiguracji?
Wymagane zgody i certyfikaty
Jakie zgody regulacyjne są wymagane?
Ile czasu potrzebujemy na uzyskanie certyfikatów?
Kto w organizacji może nam pomóc w procesie certyfikacji?
Jakie dokumenty musimy przygotować?
Systemy zewnętrzne
Jak uzyskać dostęp do środowisk testowych i produkcyjnych?
Jakie są limity API i koszty wykorzystania?
Jak przeprowadzić testy integracyjne?
Jak monitorować działanie integracji?
Tłumaczenia i treści
Jakie treści marketingowe musimy stworzyć?
Jakie treści aplikacyjne wymagają tłumaczenia?
Które rynki obsługujemy w pierwszej kolejności?
Kto tworzy i zatwierdza tłumaczenia?
Czy potrzebujemy nowych assetów graficznych na dany rynek?
Analityka biznesowa
Jakie metryki biznesowe mierzymy?
Gdzie w kodzie musimy wysyłać dodatkowe informacje?
Jakich dodatkowych raportów potrzebujemy?
Obserwowalność techniczna
Jakie metryki techniczne dodajemy?
Które procesy wymagają szczególnego monitoringu?
Jakie dodajemy dodatkowe logi ?
Jakie alerty konfigurujemy?
Obsługa klienta i procesy operacyjne
Jakich narzędzi potrzebuje support?
Jak przebiega proces szkoleń?
Gdzie dokumentujemy procesy operacyjne?
Jak obsługujemy zgłoszenia błędów?
Kto jest pierwszą linią wsparcia?
Komunikacja z klientem
Jakich szablonów wiadomości potrzebujemy?
Kiedy wysyłamy powiadomienia?
Kto odpowiada za treść komunikatów?
Testy i walidacja
Jak testujemy na produkcji?
Która grupa użytkowników testuje jako pierwsza?
Jakie są kryteria sukcesu testów? Kiedy mówimy, że nie startujemy?
Kiedy podejmujemy decyzję o pełnym rolloucie?
Czy dzięki temu szybciej dostarczamy wartość?
Można odpowiedzieć po matematycznemu, że:
To jest warunek konieczny, ale nie wystarczający, by szybciej dostarczać wartość
Ponieważ to, że coś szybciej uruchomimy, wcale nie oznacza, że dostarczyliśmy wartość 🤯
Ale o tym będzie już w kolejnym odcinku.
Twoja lista uruchamiania
Powyższy materiał jest w zamyśle podręcznym wstępem do dyskusji, który możesz wykorzystać w swoim obszarze biznesowym. Każdy produkt jest inny i ma inne kryteria uruchomienia. Ale trzeba o nich mówić publicznie, by zacząć je optymalizować.
Jest coś jeszcze, co sprawdzasz przy uruchomieniu? Daj znać w odpowiedzi / komentarzu 👇