Nowa funkcja dla wybranej grupy użytkowników: jak zaplanować stopniowe udostępnienie

Zespół przygotował nowy widok zleceń. Zamiast pokazywać go wszystkim w poniedziałek rano, chce zaprosić niewielką grupę pracowników i sprawdzić, czy potrafią przekazać sprawę kolejnej osobie. Nowa wersja jest już w aplikacji, ale dostęp do niej ma tylko wybrana grupa. Sam przełącznik nie wystarczy: trzeba jeszcze wiedzieć, kto ją włączył, co obserwować i jak wrócić do pracy po wyłączeniu.

Stopniowe udostępnienie funkcji pozwala zaplanować naukę na ograniczonym zakresie. Wymaga jasnej definicji grupy, warunków zakończenia próby oraz odpowiedzialności za reakcję. Nie zastępuje testów ani kontroli uprawnień do danych.

Jeżeli planujesz wdrożenie funkcji, wyślij brief z opisem użytkowników, zadania i obszaru, który ma się zmienić. Wystarczy fikcyjna sprawa, bez haseł i danych klientów.

Zacznij od zadania grupy pilotażowej

Wyobraźmy sobie firmę usługową korzystającą z panelu zleceń. Zespół przygotował widok przekazania sprawy, w którym osoba kończąca etap wskazuje następcę oraz otwarte pytania. W próbie ma uczestniczyć kilka osób z różnych ról. To przykład projektowy, nie opis rzeczywistego wdrożenia.

Przed włączeniem widoku zapiszcie, jaką decyzję chcecie podjąć. Czy pracownik potrafi znaleźć otwartą sprawę, rozpoznać jej stan i przekazać ją bez dodatkowego telefonu? Czy następna osoba widzi kontekst potrzebny do pracy? Wynik powinien dotyczyć konkretnych czynności, a nie ogólnego pytania, czy nowy ekran się podoba.

W grupie warto uwzględnić osoby pracujące w różnych sytuacjach, na przykład przy biurku i na urządzeniu mobilnym. Dobór zależy od użytkowników aplikacji, nie od łatwości zebrania chętnych. Ustalcie także, kto może udzielić informacji zwrotnej oraz w jakim kanale zgłosić problem wymagający szybkiej reakcji.

Przygotowanie zadań opisujemy w artykule o teście prototypu z pracownikami. Udostępnienie działającej funkcji wymaga dodatkowo ustalenia skutków dla rzeczywistych danych oraz drogi powrotu, jeśli próba ujawni problem.

Uczestnikom wyjaśnijcie zakres próby oraz sposób zgłaszania problemów. Nie trzeba obiecywać, że wszystkie sugestie trafią do produktu. Lepiej wskazać, kto zbiera uwagi, jak będą oceniane oraz kiedy zespół podejmie następną decyzję. Jeśli funkcja zmienia sposób pracy innych osób, poinformujcie również je, nawet gdy same nie korzystają z nowego widoku.

Rozdziel publikację kodu i włączenie funkcji

Funkcja może zostać wdrożona w kodzie, a następnie udostępniona wybranym osobom za pomocą reguły konfiguracyjnej nazywanej flagą funkcji. Aplikacja sprawdza tę regułę i wybiera zachowanie przewidziane dla danego kontekstu. Konkretny sposób działania zależy od użytej technologii i miejsca, w którym wykonywana jest ocena.

Zapiszcie, czego dotyczy flaga. Czy włącza nowy widok, możliwość zapisu, czy cały proces wraz z integracją? Jeśli widoczny jest tylko przycisk, a zaplecze wykonuje nową operację dla wszystkich, granica próby została źle opisana. Każdy etap musi mieć uzgodniony zakres oraz sposób sprawdzenia.

Flaga nie jest samodzielnym mechanizmem autoryzacji. Osoba, która trafi do grupy pilotażowej, nadal musi mieć odpowiednie uprawnienia do spraw i operacji. Ukrycie widoku przed pozostałymi użytkownikami nie zastępuje kontroli dostępu w systemie. W artykule o rolach i uprawnieniach opisujemy, jak powiązać zakres danych z zadaniem.

Warto ustalić właściciela flagi, datę przeglądu i powód jej istnienia. Po zakończeniu próby ktoś powinien zdecydować, czy funkcja staje się standardowa, czy pozostaje wyłączona oraz kiedy można usunąć niepotrzebną konfigurację. Stary przełącznik bez właściciela utrudnia zrozumienie, która ścieżka faktycznie działa.

Nazwa flagi powinna pozwalać odróżnić próbę od stałego ustawienia konta. W dokumentacji zapiszcie, które części aplikacji ją sprawdzają oraz jakie zachowanie odpowiada każdej wartości. Jeżeli integracja z zewnętrznym systemem działa osobno, sprawdźcie, czy również respektuje ustalony zakres. W przeciwnym razie wyłączenie ekranu może pozostawić aktywny proces w tle.

Dobierz grupę i regułę

Grupa może być określona przez listę kont, rolę albo inną cechę dostępną w aplikacji. Ustalcie, skąd pochodzi ta informacja i jak zachowuje się reguła po zmianie zespołu przez pracownika. Jeśli udział ma wynikać z jawnego zaproszenia, grupa wszystkich osób z określonego działu może być zbyt szeroka.

Przed próbą sprawdźcie konto uczestnika, osobę spoza grupy oraz użytkownika, którego dane nie są kompletne. Widok i uprawnienia powinny odpowiadać ustaleniom. Jeśli system dzieli użytkowników według losowej reguły, zweryfikujcie w dokumentacji, jak zapewnia powtarzalny przydział i co dzieje się po zmianie identyfikatora.

Nie zakładajcie, że każda osoba w grupie korzysta z funkcji w ten sam sposób. Pracownik, który przekazuje sprawę, wykonuje inne zadanie niż osoba ją przejmująca. Przed rozszerzeniem próby sprawdźcie obie strony procesu. W artykule o przejściu od wskaźnika do sprawy pokazujemy, dlaczego wynik powinien prowadzić do właściwego kontekstu pracy.

Jeśli funkcja wymaga udziału kilku osób, warto uzgodnić, jak wspólnie pracują użytkownicy z dostępem i bez niego. Nowy ekran nie powinien tworzyć sprawy, której nie da się otworzyć w dotychczasowej ścieżce, chyba że taki zakres został świadomie zaplanowany i sprawdzony. Kompatybilność obu dróg jest częścią próby.

Przy pracy między oddziałami wyjaśnijcie też, czy grupa obejmuje osoby, organizacje czy konkretne sprawy. Jeśli użytkownik przenosi zgłoszenie do innej jednostki, nowy właściciel może nie należeć do pilotażu. Zespół powinien przetestować tę sytuację i zapewnić możliwość dalszej pracy. Uzgodniona reguła powinna być zrozumiała również dla obsługi, która otrzyma pytanie o brak widoku.

Zaplanuj brak konfiguracji i wyłączenie

Przed uruchomieniem ustalcie, co aplikacja ma zrobić, gdy nie może odczytać konfiguracji flagi. Odpowiedź zależy od narzędzia, sposobu przechowywania ustawień i rodzaju błędu. Dla przykładu dokumentacja LaunchDarkly opisuje wartość zastępczą podawaną podczas oceny flagi. Nie należy zakładać, że wszystkie biblioteki i wszystkie sytuacje awarii działają identycznie.

Wybierzcie zachowanie bezpieczne dla konkretnego procesu i sprawdźcie je w testach. Jeżeli nowy widok zależy od usługi, która jest niedostępna, użytkownik powinien otrzymać jasną informację albo móc przejść do uzgodnionej ścieżki. Należy sprawdzić, czy aplikacja korzysta z ostatnio znanej konfiguracji, czy z wartości zastępczej, zamiast wnioskować o tym z samej nazwy flagi.

Wyłączenie dostępu nie cofa automatycznie danych zapisanych podczas próby. Jeżeli uczestnik rozpoczął przekazanie sprawy w nowym widoku, zespół musi wiedzieć, gdzie znajduje się zapis i czy można go dokończyć w dotychczasowej ścieżce. W artykule o wdrażaniu zmian i powrocie omawiamy planowanie reakcji po wykryciu problemu.

Zapiszcie, kto ma prawo wyłączyć flagę, jak powiadamia osoby odpowiedzialne i jak sprawdza wynik. Sama zmiana ustawienia w panelu nie musi być natychmiast widoczna w każdej sesji lub usłudze. Zachowanie należy sprawdzić dla rzeczywistej konfiguracji i zachować sposób rozpoznania użytkowników, którzy nadal korzystają z wcześniejszego stanu.

W planie wyłączenia uwzględnijcie wiadomości i działania uruchomione przed zmianą ustawienia. Funkcja mogła wysłać powiadomienie albo przekazać zadanie do kolejki. Zespół powinien wiedzieć, jak sprawdzić ich stan i kto wyjaśni opóźnione wykonanie. Przełącznik nie odwołuje automatycznie każdej operacji rozpoczętej wcześniej. Decyzja zależy od projektu aplikacji oraz możliwości integracji.

Właściciel próby powinien też sprawdzić, jak odbiorcy dowiedzą się o zatrzymaniu funkcji. Komunikat może wskazać drogę do wcześniejszego widoku i osobę kontaktową, jeśli zadanie zostało rozpoczęte. Nie obiecujcie zachowania zmian, dopóki zapis nie został potwierdzony przez aplikację.

Zbierz sygnały, które pomagają podjąć decyzję

Ustalcie przed próbą, jakie zachowania i problemy chcecie obserwować. Przy widoku przekazania sprawy może to być poprawne wskazanie następnej osoby, odnalezienie otwartych pytań oraz liczba spraw wymagających ręcznego wyjaśnienia. Definicje powinny opisywać źródło danych i moment pomiaru. W artykule o definicjach wskaźników pokazujemy, dlaczego nazwa liczby nie wystarczy.

Nie traktujcie małej grupy jako automatycznego dowodu, że wynik utrzyma się w całej organizacji. Uczestnicy mogą mieć inną rolę lub lepiej znać system niż pozostali użytkownicy. Zapiszcie zakres obserwacji oraz sytuacje, których nie obejmowała. Decyzję o rozszerzeniu podejmuje właściciel procesu po obejrzeniu konkretnych wyników i uwag.

Kanał opinii powinien pozwalać opisać zadanie i miejsce problemu bez wysyłania haseł czy danych klientów. Jeśli użytkownik zgłasza błąd, osoba prowadząca próbę powinna potwierdzić przyjęcie i wskazać kolejny krok. Zgłoszenie nie znika tylko dlatego, że flaga została wyłączona.

Niektóre sygnały wymagają natychmiastowej reakcji, inne można omówić po zakończeniu próby. Ustalcie tę różnicę wcześniej. Przykładowo błędne przypisanie sprawy może wymagać zatrzymania funkcji i sprawdzenia danych, podczas gdy uwaga o nazwie przycisku może trafić do kolejnej wersji. Kryteria zależą od skutków w danym procesie.

Jeżeli próba obejmuje wskaźniki, zapiszcie także warunki ich interpretacji. Dłuższy czas wykonania zadania w pierwszym dniu może wynikać z poznawania ekranu, ale nie należy przyjmować tego wyjaśnienia bez rozmowy i obserwacji. Sprawdźcie, gdzie uczestnik szukał informacji i czy rozumiał komunikaty. Krótka notatka o konkretnej przeszkodzie często lepiej kieruje poprawką niż sama średnia liczba kliknięć.

Przeprowadź próbę pełnej ścieżki

W środowisku testowym sprawdźcie osobę w grupie, poza grupą i bez informacji potrzebnej do oceny reguły. Następnie wyłączcie konfigurację zgodnie z możliwościami narzędzia i zobaczcie, co dzieje się z otwartym formularzem. Dla każdego przypadku zapiszcie oczekiwany widok, stan danych oraz wynik dostępu do operacji.

W środowisku testowym integracji możecie prześledzić również zmianę reguły w trakcie pracy i sprawdzić powiązane usługi. Próba powinna obejmować stare i nowe zachowanie. Nie wystarczy kliknąć przełącznika w panelu, jeśli użytkownik nadal widzi poprzednią wersję przez aktywną sesję.

Poproście uczestnika o przekazanie przykładowej sprawy, a następną osobę o jej przejęcie. Nie podpowiadajcie drogi. Jeżeli obie osoby korzystają z różnych wersji interfejsu, sprawdźcie, czy widzą ten sam stan i czy rozumieją kolejny krok. Scenariusz oraz osobę potwierdzającą wynik zapiszcie w kryteriach odbioru aplikacji.

Przed rozszerzeniem grupy przejrzyjcie otwarte problemy, zapis decyzji i plan komunikacji. Osoby dołączające później powinny wiedzieć, co się zmieniło oraz gdzie zgłosić trudność. W oprogramowaniu na zamówienie tempo udostępnienia powinno wynikać z wyników próby i gotowości procesu, a nie wyłącznie z daty wpisanej w harmonogramie.

Przed rozpoczęciem testów przygotujcie fikcyjne konta o różnych uprawnieniach i danych wystarczających do wykonania zadania. Sprawdźcie także, czy osoba spoza pilotażu nie może uruchomić nowej operacji przez bezpośrednie wywołanie usługi. Jeżeli dostęp do danych powinien być ograniczony, mechanizm uprawnień musi działać niezależnie od tego, czy interfejs pokazuje przycisk.

Po zakończeniu próby wykonajcie przegląd ustawień. Właściciel powinien potwierdzić, czy flaga nadal jest potrzebna oraz jaka ścieżka pozostaje obowiązująca. Zmianę dokumentacji i usunięcie nieużywanego kodu należy zaplanować oraz sprawdzić osobno. Pozostawiona konfiguracja może mylić kolejny zespół, nawet gdy użytkownicy nie widzą już nowego ekranu.

Ustalcie termin tej decyzji i jej właściciela przed zakończeniem próby.