zastępowanie aplikacji retool, którą przerosłeś. zastąpienie zbyt rozrośniętej aplikacji retool ma sens, gdy wewnętrzne narzędzie, w którym żyje twój zespół operacyjny, przestaje oszczędzać czas, a zaczyna go kosztować. sygnałem nie jest wiek aplikacji. jest nim tydzień, który inżynier spędza na rozplątywaniu zepsutego zapytania, którego nikt nie udokumentował, albo faktura za miejsca w licencji, która rośnie szybciej niż zespół, który z niej korzysta. zastąpienie oznacza posiadanie kodu, uwierzytelniania i śladu audytowego zamiast wynajmowania ich.
zespół miał aplikację retool. działały na niej wewnętrzne operacje: zwroty pieniędzy, zmiany na kontach, eskalacje ze wsparcia. z czasem zaczęła robić też trzy rzeczy, których na początku nie robiła. psuła się w sposób, który rozumiał tylko jeden inżynier. naliczała opłatę za miejsce w licencji nawet za osoby, które otwierały jeden ekran. a każda poprawka oznaczała edycję konfiguracji, której nikt nie chciał wziąć na siebie. aplikacja nie zawiodła. zespół ją przeró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 warto zastąpić aplikację retool własnym narzędziem wewnętrznym?
zastąp ją, gdy utrzymanie aplikacji retool pochłania więcej czasu inżynierów, niż oszczędza, gdy opłata za miejsce w licencji rośnie szybciej niż zespół, który z niej korzysta, albo gdy zmiany trafiają na produkcję bez śladu audytowego. te jeden czy dwa procesy, które ją przerosły, zbuduj od nowa jako własne narzędzie z uwierzytelnianiem, rolami i dziennikami. resztę zostaw, dopóki nie zacznie boleć.
#jak wyglądało to zastąpienie w praktyce?
zrobiliśmy to dla ~40-osobowego zespołu produktowego b2b saas. ich aplikacja retool urosła do kilkudziesięciu zapytań i konfiguracji uprawnień trzymanej razem ręcznie. nie odbudowaliśmy wszystkiego naraz. dostarczyliśmy własne wewnętrzne narzędzie operacyjne z trzema elementami wbudowanymi od pierwszego dnia, a nie doczepionymi później. zespół operacyjny w pełni przeszedł na nowe narzędzie w ciągu dwóch tygodni od przełączenia.
- 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
#dlaczego inżynierowie odzyskali dzień pracy tygodniowo?
aplikacja retool kosztowała zespół mniej więcej jeden dzień pracy inżyniera tygodniowo. ten czas szedł na zepsute zapytania, ręcznie obsługiwane prośby o dostęp i zmiany, które wymagały inżyniera, bo zespół operacyjny nie mógł wprowadzić ich bezpiecznie. własne narzędzie przeniosło tę pracę na zespół operacyjny. inżynierowie odzyskali około dnia tygodniowo. te jawne, udokumentowane wyniki publikujemy w dzienniku.
podmiot i liczby w tym tekście są zanonimizowane zgodnie z umową z klientem. odzyskany dzień tygodniowo i dwutygodniowe wdrożenie to liczby zgłoszone przez samego klienta, nie prognozy.
#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 uwierzytelnianiem, rolami i dziennikami audytowymi dostarczonymi jako część realizacji, a kod przekazujemy ci od pierwszego dnia.
we aren't
nie jesteśmy kolejną subskrypcją za miejsce w licencji, którą wynajmujesz w nieskończoność, ani niestandardową przebudową na dwa kwartały, która zamienia działającą aplikację na czystą kartkę.
różnicą, na której zespołowi zależało najbardziej, była własność. subskrypcja retool, którą porzucali, naliczała opłatę za miejsce i trzymała kod na cudzej platformie. narzędzie, które zbudowaliśmy, trafiło do nich jako repozytorium, którego są właścicielami od pierwszego dnia. bez opłat za miejsce w licencji. bez platformy, z której można zostać odciętym. tak dział platforms buduje wewnętrzne narzędzia operacyjne.
w tygodniu, w którym przestaliśmy łatać starą aplikację, odzyskałem moich inżynierów. o to właśnie chodziło.
jeśli twój zespół wciąż łata aplikację retool, której nikt nie chce wziąć na siebie, poprawką nie jest kolejna łatka. jest nią posiadanie narzędzia, uwierzytelniania i śladu audytowego. w ramach krótkiego zlecenia konsultingowego określamy, które procesy warto przenieść, a które zostawić bez zmian, po czym budujemy tylko tę część, która przerosła stare narzędzie. powiedz nam, co budujesz.