Jak aktualizować aplikację zbudowaną z AI, nie psując jej osobom, które już z niej korzystają

Pierwszą wersję Twojej aplikacji łatwo było zmieniać. Jeśli coś się zepsuło, jedyną osobą, która to zauważyła, byłeś Ty. Potem prawdziwi ludzie zaczęli z niej korzystać — i teraz każda zmiana wydaje się jak operacja na przytomnym pacjencie. Nauczenie się, jak aktualizować aplikację zbudowaną z AI, nie psując jej, to przede wszystkim kwestia rutyny, a ta rutyna jest mniejsza, niż myślisz.

Pewna właścicielka biznesu korepetycyjnego, którą znamy, nauczyła się tego boleśnie. Jej aplikacja do planowania działała gładko od miesięcy, więc pewnego wieczoru poprosiła swojego kreatora z AI o małe usprawnienie: zmień nazwę „Sesja” na „Lekcja” wszędzie, bo tego słowa faktycznie używali jej korepetytorzy. Kreator chętnie zmienił nazwę — w tym, jak się okazało, w miejscu, gdzie przechowywane były istniejące rezerwacje. Następnego ranka troje korepetytorów otworzyło swoje kalendarze i znalazło je puste. Dane nie zniknęły, ale aplikacja nie mogła ich już znaleźć, a ona spędziła stresujący dzień na przywracaniu połączenia.

W tej zmianie nie było niczego nierozsądnego. Po prostu nie miała jeszcze rutyny na to, jak aktualizować aplikację zbudowaną z AI, gdy ma już użytkowników. Ten wpis jest tą rutyną — cztery nawyki, które zajmują może piętnaście dodatkowych minut na zmianę i zapobiegają większości katastrof.

Dlaczego aktualizacje wydają się inne, gdy masz użytkowników

Trzy rzeczy zmieniają się w chwili, gdy ktoś inny polega na Twojej aplikacji:

Są w niej teraz dane. Zmiany, które były nieszkodliwe na pustej aplikacji — zmiana nazw, przebudowa formularzy — mogą rozłączyć lub pomieszać informacje, które ludzie już wprowadzili.
Ludzie mają nawyki. Twoi użytkownicy nauczyli się, gdzie są przyciski. Nawet usprawnienie jest zakłóceniem, jeśli przesuwa coś, czego używają codziennie.
Nie wybierasz momentu wystąpienia problemów. Kiedy aplikacja była tylko Twoja, zepsuty wieczór nie miał znaczenia. Teraz zepsuty wtorkowy poranek to troje korepetytorów z pustymi kalendarzami.

Nic z tego nie znaczy, że masz przestać ulepszać swoją aplikację. Aplikacje, które przestają się zmieniać, umierają powoli, zamiast nagle. Znaczy to, że zmiany potrzebują odrobiny ceremonii.

Nawyk 1: Zrób kopię zapasową, zanim czegokolwiek dotkniesz

To ten nienegocjowalny. Przed jakąkolwiek zmianą większą niż poprawienie literówki upewnij się, że masz aktualną kopię zapasową danych aplikacji — i wiesz, jak ją przywrócić.

Jeśli już skonfigurowałeś automatyczne kopie zapasowe, ten nawyk kurczy się do jednego pytania do kreatora z AI: „Kiedy była ostatnia kopia zapasowa i jak bym ją przywrócił?” Jeśli odpowiedź jest pewna i świeża, działaj. Jeśli jeszcze nie skonfigurowałeś kopii zapasowych, zrób to przed następną aktualizacją — napisaliśmy pełny przewodnik po tworzeniu kopii zapasowej aplikacji zbudowanej z AI, i to najlepiej spędzona godzina nad Twoim produktem w tym miesiącu.

Historia z aplikacją korepetytorską powyżej miała szczęśliwe zakończenie właśnie dlatego, że jej platforma trzymała kopie zapasowe. Inaczej stresujący dzień byłby dniem katastrofalnym.

Nawyk 2: Zapytaj „co to może zepsuć?”, zanim powiesz tak

Oto pytanie, którego większość twórców nigdy nie pomyśli zadać, a robi więcej roboty niż pozostałe trzy nawyki razem wzięte. Po opisaniu zmiany kreatorowi z AI, a przed jej zatwierdzeniem, dodaj jedną linijkę:

„Zanim wprowadzisz tę zmianę — jakie istniejące funkcje lub dane może ona dotknąć?”

To działa, bo AI zwykle widzi połączenia, których Ty nie widzisz. Właścicielka aplikacji korepetytorskiej nie mogła wiedzieć, że „Sesja” była też nazwą miejsca, gdzie mieszkały rezerwacje. Kreator wiedział — tylko nigdy nie zapytała. Kiedy potem odbudowała swoją rutynę, to jedno pytanie stało się krokiem, który wyłapywał problemy: zasygnalizowało, że zmiana jej formularza cenowego dotknie dwie stare faktury i że dodanie wymaganego pola zablokuje istniejących klientów, którzy zarejestrowali się bez niego.

Czytaj odpowiedź jak pilot czytający raport pogodowy. „To kosmetyka, nic innego tego nie dotyka” — czyste niebo, lecimy. „To zmodyfikuje sposób przechowywania rezerwacji” — to Twój sygnał, żeby zwolnić, zrobić kolejną kopię zapasową i może poprosić o łagodniejszą wersję zmiany.

Nawyk 3: Zmieniaj jedną rzecz naraz i testuj ją jak nieznajomy

Pakowanie pięciu usprawnień w jedną dużą aktualizację wydaje się efektywne. Jest dokładnie odwrotnie: gdy coś się zepsuje, nie będziesz wiedzieć, które z pięciu to spowodowało, a cofnięcie zepsutego oznacza cofnięcie wszystkich pięciu.

Jedna zmiana, potem sprawdzenie. Sprawdzanie liczy się tak samo jak rozdzielanie:

Używaj drugiego konta, nie konta właściciela. Ty widzisz aplikację jako jej administrator; Twoi użytkownicy nie. Zaloguj się jako zwykły użytkownik — trzymaj na stałe konto testowe właśnie do tego — i przejdź przez ścieżkę, której dotyczyła Twoja zmiana. (Jeśli nigdy wcześniej nie testowałeś własnej aplikacji, oto jak to zrobić bez doświadczenia w QA.)
Sprawdź to, co zmieniłeś, oraz to, co jest obok. Jeśli zaktualizowałeś formularz rezerwacji, zrób rezerwację — a potem otwórz też starą rezerwację i upewnij się, że wciąż się wyświetla. Większość uszkodzeń po aktualizacjach pojawia się w starych danych, nie w nowych.
Zrób to teraz, nie jutro. Testuj od razu po zmianie, póki jest świeża i mała. Problem znaleziony pięć minut po aktualizacji jest oczywiście spowodowany aktualizacją. Problem znaleziony w piątek może być czymkolwiek.

Nawyk 4: Wybierz spokojny moment i znaj swoje cofanie

Dwa ostatnie kawałki wyczucia czasu, których używają profesjonaliści, a o których osoby nietechniczne rzadko słyszą:

Wypuszczaj, gdy Twoi użytkownicy są nieobecni. Pewnie znasz rytm swojej aplikacji — aplikacja korepetytorska była najbardziej obłożona w popołudnia dni roboczych, a niemal cicha w niedzielne wieczory. Niedzielny wieczór to czas na zmiany. Jeśli coś pójdzie nie tak, masz godziny na naprawę, zanim ktokolwiek się pojawi, zamiast minut.

Znaj swoje cofanie, zanim go potrzebujesz. Zapytaj kreatora z AI: „Jeśli ta zmiana spowoduje problemy, czy możesz ją cofnąć? Co by to wymagało?” Czasem odpowiedź to „jedno kliknięcie”. Czasem to „cofnięcie zmiany jest łatwe, ale dane utworzone po zmianie mogą nie pasować do starej wersji”. Chcesz usłyszeć tę odpowiedź, gdy jesteś spokojny, a nie gdy troje korepetytorów pisze do Ciebie.

A gdy zmiana jest widoczna dla użytkowników — przesunięty przycisk, zmieniona nazwa pola, nowy krok — powiedz im o tym. Jedna krótka wiadomość („Zauważysz, że Sesje nazywają się teraz Lekcje — te same rezerwacje, przyjaźniejsza nazwa”) zamienia mylącą niespodziankę w sygnał, że ktoś aktywnie dba o produkt, na którym polegają.

Wersja na piętnaście minut

Oto cała rutyna, na tyle mała, by zmieścić się na karteczce samoprzylepnej: kopia zapasowa aktualnego stanu → zapytaj, co może się zepsuć → jedna zmiana naraz → przetestuj jak nieznajomy, ze starymi danymi włącznie → ciche godziny → znaj swoje cofanie → powiedz użytkownikom.

Właściciele, którzy trzymają się czegoś takiego, nie aktualizują swoich aplikacji zbudowanych z AI rzadziej niż ci nieostrożni — aktualizują więcej, bo każda zmiana przestaje być hazardem. To prawdziwa nagroda: nie unikanie awarii, ale pozostawanie na tyle pewnym siebie, by dalej ulepszać rzecz, na której ludzie polegają.

Następnym razem, gdy będziesz mieć zamiar poprosić kreatora o zmianę, wypróbuj jednolinijkowe pytanie z Nawyku 2 i zobacz, co wyjdzie na wierzch. A jeśli to ten wpis, który wreszcie skłoni Cię do skonfigurowania kopii zapasowych — zacznij tutaj.