Zastąpienie aplikacji retool, z której się wyrosło. Ilustracyjny przykład praktyczny, nie wynik klienta: zespół i liczby to założenia. Zastąpienie rozrośniętej aplikacji retool warto rozważyć, gdy wewnętrzne narzędzie, w którym żyje twój zespół ops, przestaje oszczędzać czas, a zaczyna go kosztować. Sygnałem jest tydzień, który inżynier spędza na rozplątywaniu zepsutego, nieudokumentowanego zapytania, albo rachunek za licencje rosnący szybciej niż zespół, który z nich korzysta. Zastąpienie oznacza posiadanie kodu, uwierzytelniania i śladu audytowego zamiast ich wynajmowania.
Załóżmy, że zespół ma aplikację retool, która obsługuje jego wewnętrzne operacje: zwroty, zmiany kont, eskalacje supportu. Robi też trzy rzeczy, których z początku nie robiła. Psuje się w sposób, który rozumie tylko jeden inżynier. Nalicza opłaty za ludzi, którzy otwierają jeden ekran. A każda poprawka oznacza edycję konfiguracji, której nikt nie chce być właścicielem. Aplikacja nie zawiodła. Zespół z niej wyrósł.
#Skąd wiem, że nadszedł czas, żeby odejść od retoola?
Nie ma liczby użytkowników, która by o tym decydowała. Obserwujemy cztery sygnały. Ile godzin pracy inżynierów tygodniowo pochłania utrzymanie aplikacji przy życiu. Ile płatnych miejsc w licencji należy do osób, które czytają jeden widok. Ile zmian trafia na produkcję bez śladu audytowego, któremu ktokolwiek ufa. I ile czasu zajmuje nowej osobie w zespole operacyjnym, zanim przestanie prosić inżyniera o wprowadzenie zmiany za nią. Gdy trzy z tych czterech sygnałów idą w złą stronę, to narzędzie jest wąskim gardłem, nie zespół.
Kiedy zastąpić aplikację retool własnym narzędziem wewnętrznym?
Zastąp ją, gdy utrzymanie aplikacji retool kosztuje więcej czasu inżynierów, niż oszczędza, gdy koszty licencji rosną szybciej niż zespół, który z niej korzysta, albo gdy zmiany wchodzą bez wiarygodnego śladu audytowego. Odbuduj ten jeden lub dwa procesy, które ją przerosły, jako własne narzędzie z uwierzytelnianiem, rolami i dziennikami. Resztę zostaw, aż zaboli.
#Jak wygląda zastąpienie?
Weź jako założenie zespół produktowy B2B SAAS liczący około 40 osób. Jego aplikacja retool urosła do dziesiątek zapytań i uprawnień trzymanych razem ręcznie. Projekt nie odbudowuje wszystkiego naraz. To własne wewnętrzne narzędzie ops z trzema rzeczami wbudowanymi od początku, a nie dodanymi później, a zespół ops przechodzi proces po procesie.
- Logowanie, dzięki czemu dostęp jest przyznawany i odbierany w jednym miejscu (uwierzytelnianie)
- Dostęp oparty na rolach, dzięki czemu pracownik supportu i administrator widzą różne ekrany (rbac)
- Dziennik audytowy, który zapisuje, kto co zmienił i kiedy
#Skąd wraca czas inżynierów?
Taka aplikacja retool kosztuje czas inżynierów co tydzień. Idzie on na zepsute zapytania, ręcznie obsługiwane prośby o dostęp i zmiany, które wymagają inżyniera, bo zespół ops nie może ich bezpiecznie zrobić. Własne narzędzie przenosi tę pracę na zespół ops. Liczba do zmierzenia to godziny inżynierów tygodniowo na narzędziu ops, przed i po. Te przykłady praktyczne opisujemy w dzienniku.
to przykład praktyczny. Zespół i każda liczba to założenia, nie wynik klienta. Nie opisujemy tu żadnego prawdziwego zlecenia.
#Czy to nie jest po prostu większa wersja uzależnienia od dostawcy?
We are
Określamy zakres procesów, które przerosły retoola, i odbudowujemy je jako wewnętrzne narzędzie, którego jesteś właścicielem, z wbudowanym uwierzytelnianiem, rolami i dziennikami audytowymi, a kod należy do ciebie od początku.
We aren't
Nie jesteśmy kolejną platformą, którą wynajmujesz w nieskończoność, ani pełną niestandardową przebudową, która zamienia działającą aplikację na czystą kartkę.
Różnicą, na której takiemu zespołowi zależy najbardziej, jest własność. Platforma hostowana trzyma kod po stronie kogoś innego. Narzędzie zbudowane w ten sposób trafia do ciebie jako repozytorium, którego jesteś właścicielem od początku, bez platformy, z której można zostać odciętym. Tak nasza praca we wdrożeniach AI podchodzi do wewnętrznych narzędzi ops.
Test: w tygodniu, w którym przestajesz łatać starą aplikację, odzyskujesz swoich inżynierów. O to właśnie chodzi.
Jeśli twój zespół wciąż łata aplikację retool, której nikt nie chce być właścicielem, rozwiązaniem nie jest kolejna łata. To posiadanie narzędzia, uwierzytelniania i śladu audytowego. Które procesy warto przenieść, a które zostawić, ustalamy w ramach doradztwa AI, a potem budujemy tylko tę część, która przerosła stare narzędzie. powiedz nam, co budujesz.
