Zbuduj wyjście, zanim pierwszy klient o nie zapyta

Tylny panel matowego czarnego komputera w kształcie sześcianu z pustymi portami i jednym kablem z zielonym wtykiem wychodzącym poza kadr

Młoda firma programistyczna zdobywa klienta, o którego zabiegała od roku. Dział zakupów przysyła ankietę, a jedna z jej części pyta, jak klient mógłby odejść: co by dostał, w jakim formacie, jak szybko i z jaką pomocą. Zespół patrzy na to, co istnieje. Na dwóch ekranach jest pobieranie CSV. Ustawienia klientów są zapisane jako zserializowane obiekty, które rozumie tylko aplikacja. Pliki leżą w zasobniku pod losowymi nazwami. Każdy proces odwołuje się do wewnętrznych identyfikatorów dostawcy. Uczciwa odpowiedź brzmi: „zbudowalibyśmy coś, gdybyście poprosili”, i zespół spędza kolejny miesiąc na budowaniu tego zamiast funkcji, które ta umowa miała sfinansować.

Prawdziwa przyczyna

Nikt nie projektuje produktu tak, żeby w pierwszym roku trudno było od niego odejść. Trudno staje się przez zwykłe skróty: zapisywanie tego, co najłatwiej, wewnętrzne identyfikatory wszędzie, konfiguracja trzymana tam, gdzie akurat zapisuje ją ekran, który ją edytuje. Każdy skrót jest rozsądny. Razem rozrzucają stan klienta po miejscach, do których żaden eksport nie był projektowany.

Dokładanie wyjścia po fakcie oznacza znalezienie każdego z tych miejsc i uzgodnienie formatu dla każdego z nich — na działającym systemie, z klientami w środku. Zaprojektowanie go od początku oznacza podjęcie tych samych decyzji raz, póki system jest na tyle mały, że mieści się w jednej głowie.

Gdzie chowa się stan klienta

W konfiguracji. Procesy, reguły, uprawnienia i szablony często znaczą dla klienta więcej niż rekordy, bo zapisują, jak działa organizacja. To też część, która najrzadziej daje się wyeksportować.

W identyfikatorach. Jeśli każde odwołanie używa identyfikatorów dostawcy, eksport jest zbiorem łamigłówek. Stabilne klucze, które coś znaczą, albo przynajmniej udokumentowane mapowanie sprawiają, że dane nadają się do użycia gdzie indziej.

W plikach bez kontekstu. Załączniki trzymane osobno od rekordów, do których należą, pod nazwami nic nieznaczącymi poza aplikacją.

W historii. Ślady audytowe, wersje i powody zmian, trzymane w osobnej tabeli, w usłudze logów albo nigdzie.

W stanie pochodnym. Oceny, klasyfikacje i wszystko, co policzono z danych klienta, w tym wyniki funkcji AI. Jeśli klient na tym polega, potrzebuje albo wyniku, albo sposobu, żeby policzyć go ponownie.

W integracjach. Połączenia z innymi systemami, skonfigurowane przez klienta i przechowywane przez dostawcę, które po drugiej stronie trzeba odtwarzać ręcznie.

Co robić zamiast tego

Zrób z eksportu funkcję produktu, nie zgłoszenie do wsparcia. Jedna akcja dająca wszystko, co klient stworzył, w udokumentowanych otwartych formatach, bez pytania kogokolwiek o zgodę.

Używaj eksportu we własnej pracy. Dane testowe, środowiska przedprodukcyjne i dema budowane z wyeksportowanych danych. Format, od którego zależy zespół, pozostaje kompletny; ten używany tylko przy wyjściu gnije.

Traktuj konfigurację jak dane. Reguły i procesy zapisuj w ustrukturyzowanej, wersjonowanej formie, którą da się wyeksportować i zaimportować, a nie jako stan schowany za ekranem ustawień.

Opublikuj schemat. Znaczenie pól, dopuszczalne wartości, powiązania. Jeśli kompetentna obca osoba nie potrafi wczytać eksportu do bazy danych i go zrozumieć, eksport nie jest skończony.

Daj ścieżkę samodzielnego hostingu, nawet jeśli skorzysta z niej niewielu. Produkt, który może działać na infrastrukturze klienta, jest zmuszony trzymać swój stan jawnie, a to utrzymuje w uczciwości każde inne wyjście.

Wpisz wyjście do standardowej umowy. Format, termin, pomoc i potwierdzenie usunięcia danych. Obietnicę łatwiej dotrzymać, gdy produkt już robi to, co obiecuje.

To pierwsze rzeczy, na które patrzymy we wszystkim, co budujemy albo wspieramy — nie dla zgodności z przepisami, tylko dlatego, że firma, od której klient mógłby odejść, musi go stale zdobywać na nowo, a ta presja zwykle daje lepsze produkty. Strona kupującego w tej samej sprawie jest w tekście eksport, którego nikt nie odtworzył, nie jest wyjściem.

Test do zrobienia dziś

Załóż nowe konto we własnym produkcie i używaj go przez godzinę tak, jak robiłby to prawdziwy klient: dodaj rekordy, zmień ustawienia, wgraj pliki, podłącz inne narzędzie. Potem wyeksportuj wszystko, na co produkt pozwala, i spróbuj odbudować to konto w pustej instancji, korzystając wyłącznie z eksportu i publicznej dokumentacji.

Zapisz każdy krok, który wymagał zapytania do bazy, wewnętrznego narzędzia albo pamięci programisty. Ta lista to wyjście, którego Twoi klienci jeszcze nie mają — a dziś jest najtańszy moment, żeby je zbudować.