Dług technologiczny w panelu firmowym. Kolejna zmiana rozliczenia trwa miesiąc
Autor:
Paweł Matusiak
·
Panel B2B i CRM często „działają”, a firma i tak czeka tygodniami na nową regułę rozliczenia albo inny status zlecenia. Dług technologiczny to odroczony koszt tej zmiany: skopiowana logika, trzy źródła tego samego dokumentu, osoba, która pamięta, gdzie nie klikać. Świadoma pożyczka na sezon ma sens. Brak listy skrótów i właściciela sprawia, że odsetki wchodzą w marżę.
Panel serwisu, CRM sprzedaży albo ewidencja zleceń od zewnątrz wyglądają podobnie. Ktoś się loguje, wpisuje klienta, zamyka dokument. Firma mówi, że system działa.
Działa, dopóki proces się nie rusza. Inna umowa z siecią sklepów, inny cykl fakturowania, inny status wizyty — i biuro słyszy, że zmiana nie jest mała. Ekran, który miał przyjąć nową regułę w tydzień, stoi miesiąc. Cena, status i eksport do księgowości zostały kiedyś zrobione na skróty, w kilku miejscach naraz.
Dług technologiczny w rozwijanym oprogramowaniu to odroczony koszt takiej zmiany. Firma pożycza czas przed sezonem albo przed startem umowy. Pożyczka jest racjonalna, gdy ktoś spisze, co odłożono, i wróci do tego po szczycie. Bez rejestru skrótów i bez osoby, która za listę odpowiada, odsetki wchodzą w marżę: dłuższe wdrożenie nowej reguły, więcej poprawek na fakturze, więcej ludzi, którzy obchodzą panel arkuszem.
W małej i średniej firmie przy rozwijanym panelu da się utrzymać prostą zasadę. Pożyczać czas świadomie. Spłacać według kosztu najbliższej zmiany biznesowej. Lista brzydkich miejsc z przeglądu kodu bez tej miary nic nie mówi o tym, czy ekipa wyjedzie jutro z poprawnym zleceniem.
Skąd w rozwijanym panelu bierze się dług
Dług nie pojawia się w dniu, w którym ktoś wypowiada to słowo na spotkaniu. Pojawia się wcześniej, przy konkretnej decyzji. Umowa ma wejść od pierwszego. Sezon nie poczeka. Właściciel chce raport na rano. Programista albo firma wdrażająca robi skrót. Reguła ceny trafia do jednego ekranu, a nie do wspólnego miejsca, z którego korzystają oferta, zlecenie i faktura. Status wizyty zapisuje się w kalendarzu, bo karta zlecenia jest za wolna. Magazyn części zostaje w polu komentarza, na razie.
Każdy z tych skrótów jest zrozumiały w dniu, w którym powstaje. Kłopot zaczyna się, gdy nikt nie zapisuje, że to skrót. Po roku w panelu siedzi kilka takich decyzji. Nikt nie pamięta, która tabela jest prawdziwa. Kolejna zmiana musi objechać wszystkie miejsca, w których logikę skopiowano. Czasem któreś miejsce zostaje pominięte. Sprzedawca widzi wtedy inną kwotę niż księgowość.
Źródła są zwykle prozaiczne.
- Kopiowanie logiki zamiast jednego miejsca, z którego korzystają oferta, zlecenie i faktura.
- Pole tekstowe tam, gdzie powinien być słownik: status, typ umowy, jednostka rozliczenia.
- Eksport do programu księgowego, który działa, dopóki nikt nie doda kolumny.
- Brak automatycznego sprawdzenia przy regule, od której zależy kwota na fakturze.
- Ekran zrobiony na jeden kwartał przez kogoś, kto potem nie wraca do projektu.
Taki inwentarz nie ocenia programisty. Zapisuje, gdzie firma pożyczyła czas. Bez inwentarza pożyczka nie ma raty. Ma tylko odsetki, które widać dopiero przy następnej umowie.
Część długu wchodzi z zewnątrz. Biblioteka do PDF, której nikt nie aktualizuje. Framework bez bieżących poprawek. Paczka porzucona przez autora. Kto w firmie wie, co siedzi w panelu, to osobna rozmowa o open source w oprogramowaniu dla firm. Tu chodzi o coś bliższego codziennej pracy: o logikę procesu, którą ktoś z pośpiechu zostawił w pół drogi.
Przykład: serwis klimatyzacji i skróty, które zostały po sezonie
Wyobraźmy sobie firmę serwisową od klimatyzacji i wentylacji. Kilkanaście ekip, magazyn części przy hali, stałe umowy przeglądów na obiektach handlowych i biurowych. Przykład, nie historia klienta GESOFT. Aplikacja dla serwisu terenowego powstała, gdy lista w arkuszu przestała wystarczać, a porządek w obiegu od zgłoszenia do faktury nie nadążył za kolejnymi ekranami.
Dyspozytor musiał widzieć, który obiekt ma przegląd w tym miesiącu. Technik w terenie — co było ostatnio na dachu. Biuro — czy wizyta poszła na fakturę. Lista klientów w arkuszu tego już nie ogarniała.
Przez kolejne sezony ktoś dokładał ekrany. Kalendarz ekip, bo telefon nie ogarniał zjazdów. Pole na części zużyte przy wizycie, na szybko jako komentarz. Osobny eksport do księgowości. Raport dla właściciela schodzi do arkusza, bo z panelu nie da się wyciągnąć marży z obiektu. Portal dla klienta obiecano przy jednej umowie sieciowej i zostawiono w połowie: logowanie jest, status zlecenia — nie.
Kłopot zaczyna się przy umowie z siecią sklepów. Sieć chce rozliczenie miesięczne od obiektu, a nie od każdej wizyty. Właściciel serwisu umowę podpisuje. Biuro ma wystawić jedną fakturę za kilkanaście lokalizacji, z załącznikiem, ile było przeglądów i ile awarii. Programista mówi, że najpierw trzeba rozplątać status zlecenia. Dziś ten sam status siedzi w karcie, w kalendarzu i w eksporcie. Kwota na fakturze bierze się z jeszcze innego miejsca niż cennik na ofercie. Komentarz z częściami nikt nie zsumuje do pozycji magazynowej.
Zmiana, która w rozmowie z siecią brzmiała jak inny cykl fakturowania, w panelu rozjeżdża się na trzy tabele i dwa eksporty. Biuro przez kolejne tygodnie składa fakturę ręcznie. Technik na obiekcie nie wie, czy awaria weszła w ryczałt, czy pójdzie osobno. Klient z sieci dzwoni po status i słyszy inną odpowiedź niż ta z maila dyspozytora.
W tej historii wystarczy jedno miejsce na status zlecenia i jedna reguła rozliczenia, z której korzystają karta, kalendarz i faktura. Magazyn części jako pozycje z ilością, nie jako zdanie w komentarzu. Reszta panelu może poczekać. Sieć nie czeka.
Koszt kolejnej zmiany, nie koszt porządku w kodzie
Rozmowa o długu często zaczyna się od godzin programisty. Ile zajmie posprzątanie. Ile będzie kosztować przepisanie modułu. To są realne kwoty, ale nie są pierwszą stratą, którą czuje firma.
Pierwsza strata to koszt zmiany, której firma już potrzebuje. Umowa z siecią jest podpisana. Cykl fakturowania ma ruszyć od przyszłego miesiąca. Biuro i tak wystawi dokumenty. Albo panel to ogarnie, albo ktoś złoży je z kalendarza, komentarzy i arkusza. Godziny tej osoby nie wchodzą w wycenę „porządku”. Wchodzą w marżę kontraktu.
Druga strata to błąd, który wychodzi u klienta. Faktura z inną kwotą niż oferta. Przegląd oznaczony jako zrobiony w kalendarzu, a w karcie obiektu — jako zaległy. Reklamacja, korekta, telefon od zarządcy obiektu. W serwisie klimatyzacji taki telefon pada w upał, gdy ekipy i tak są rozjechane. Biuro gasi pożar dokumentu zamiast obsłużyć kolejną awarię.
Trzecia strata to tempo. Każda kolejna nietypowa umowa trwa dłużej niż poprzednia, bo skrótów przybywa. Właściciel zaczyna odmawiać kontraktów, które panel „nie ogarnie”. Albo je przyjmuje i dokłada ręcznej pracy. Obie decyzje są kosztowne. Żadna nie wynika z tego, że kod jest brzydki. Wynikają z tego, że zmiana procesu nie ma jednego miejsca, w którym da się ją zapisać.
Kolejność spłaty bierze się z biznesu: która zmiana jest teraz najdroższa, gdy stoi. W przykładzie — rozliczenie od obiektu. Tam idzie pierwsza praca. Raport właściciela w arkuszu może poczekać, jeśli arkusz obsługuje jedna osoba i nikt nie trzyma drugiej, „prawdziwszej” kopii. Ekran, którego nikt nie otwiera, nie wchodzi na początek listy tylko dlatego, że programista chciałby go przepisać.
Sama wycena godzin też bywa myląca, gdy porównuje się ją z kosztem nowej aplikacji. Przepisanie całego panelu wygląda jak czysta karta. W wycenie giną wtedy miesiące, w których firma uczy nowy system tego, co stary już wie: które obiekty mają dwa rozdzielacze, która umowa ma wyjątek na weekend, kto u klienta odbiera protokół. Ten koszt wychodzi po starcie, nie w ofercie.
Ekipy, biuro i ludzie, którzy obchodzą ekran
Dług widać najpierw w zachowaniu ludzi, nie w repozytorium. Technik nie dopisuje części w panelu, bo pole komentarza gubi się po zapisie. Wysyła zdjęcie tabliczki i listę zużytego materiału komunikatorem. Dyspozytor rano przepisuje to do karty, albo nie przepisuje, jeśli dzień stoi awariami.
W biurze ktoś trzyma własny arkusz. Statusy z panelu są w nim „dla spokoju” poprawiane. Przed fakturą ta osoba zgadza kalendarz z kartą i z mailem od ekipy. Gdy wyjedzie na urlop, fakturowanie czeka. Nikt inny nie wie, które pole jest ozdobą, a które liczy się do kwoty.
W serwisie z przykładu taką osobą bywa dyspozytor z wieloletnim stażem. Pamięta, że na jednym ekranie nie wolno zmieniać daty, bo zepsuje eksport. Pamięta, który status wpisywać, gdy wizyta była, ale protokół przyjdzie później. Ta wiedza operacyjna jest majątkiem firmy. Siedzi w jednej głowie, bo panel nie ma miejsca, w którym dałoby się ją zapisać jako regułę.
Obchodzenie systemu jest racjonalne. Ludzie chcą skończyć dzień. Problem zaczyna się, gdy obchodzenie staje się procesem. Wtedy nowy pracownik uczy się arkusza i komunikatora, nie panelu. Wdrożenie trwa. Błędy wracają. Właściciel kupuje kolejne szkolenie z programu, którego ekipa i tak nie używa w całości.
Tu pomaga konkret, nie hasło o „lepszym UX”. Status zlecenia widoczny na telefonie technika, zanim wyjedzie. Lista części do odhaczenia przy wizycie, z ilością, która schodzi ze stanu w magazynie przy hali. Dyspozytor nie przepisuje komunikatora rano. Nowy pracownik widzi ten sam ekran co stały. Osoba, która „wie, gdzie nie klikać”, może wreszcie iść na urlop bez zatrzymywania faktur.
Jeśli ekip jest kilka, a zlecenia spisuje jedna osoba w zeszycie, panel w telefonie nic nie da. Skrót w kodzie też nie jest wtedy pierwszym problemem. Pierwszy problem to wspólna lista wizyt. Dług technologiczny zaczyna być tematem, gdy lista już jest w programie, a ludzie i tak z niej uciekają.
Magazyn części, faktura i trzy wersje tego samego zlecenia
W serwisie klimatyzacji część bywa w trzech miejscach naraz. Na półce przy hali. W skrzynce w aucie. W komentarzu pod wizytą, jeśli technik zdążył wpisać. Stan na ekranie jest wtedy ozdobą. Zakup idzie „na oko”, bo nikt nie ufa liczbie w panelu. Brakuje filtra albo czynnika w piątek po południu, gdy obiekt handlowy nie poczeka do poniedziałku.
To samo zlecenie ma trzy twarze. Karta mówi, że wizyta zamknięta. Kalendarz — że ekipa jeszcze na obiekcie. Eksport do księgowości wziął kwotę z cennika standardowego, nie z ryczałtu w umowie. Jedno źródło prawdy o zleceniu nie istnieje. Istnieją trzy dokumenty, które ktoś w biurze próbuje pogodzić przed wystawieniem faktury.
Skutek jest podwójny. Magazyn zamawia za dużo „żeby było”, albo za mało i ekipa wraca. Faktura wychodzi późno albo z korektą. W umowie ryczałtowej z siecią spóźniona faktura psuje rozliczenie miesiąca. W awarii płatnej osobno klient dostaje dokument, którego nie rozpoznaje, bo na obiekcie słyszał inną kwotę.
Skrót, który to złożył, był prosty. Ktoś nie chciał robić słownika części i ruchu między halą a autem, bo sezon klimatyzacyjny już się rozpędzał. Komentarz „wystarczy na ten miesiąc”. Po dwóch sezonach komentarz jest jedynym śladem tego, co zeszło z półki. Inwentaryzacja przy hali rozjeżdża się z panelem i nikt nie umie powiedzieć, która liczba kłamie.
Tu nie pomaga kolejny raport. Pomaga decyzja, że zlecenie ma jeden status i jedną listę pozycji. Część schodzi ze stanu w aucie albo przy hali w chwili, gdy technik ją odhacza, nie wieczorem z pamięci. Faktura bierze te same pozycje i tę samą regułę umowy. Kalendarz pokazuje ten sam status co karta. Eksport do księgowości nie przelicza kwoty od zera.
Jeśli części jest kilkanaście indeksów i wydaje je jedna osoba z półki, arkusz nadal może wystarczyć. Warunek: nikt nie prowadzi drugiego stanu w telefonie. Gdy ekip jest kilkanaście i część jeździ w autach, komentarz pod wizytą przestaje być magazynem. Wtedy ruch części w panelu jest spłatą długu, nie ozdobą.
Kiedy pożyczka na sezon ma sens
Nie każdy skrót jest błędem. Serwis klimatyzacji w szczycie ma pełne grafiki i awarie, które nie poczekają na porządną tabelę. Firma, która w czerwcu zatrzyma panel na trzy tygodnie refaktoryzacji, straci kontrakty, których dług nie był wart. Świadoma pożyczka polega na tym, że ktoś nazywa skrót skrótem i stawia datę powrotu.
Warunki takiej pożyczki da się spisać bez metodyki z korporacyjnej tablicy.
- Skrót ma właściciela w firmie: osobę, która wie, że pole komentarza zastępuje magazyn, i powie to przy następnej zmianie.
- Skrót ma wpis w rejestrze: co odłożono, dlaczego, jaki proces przez to jest kruchy.
- Skrót ma termin przeglądu po szczycie, nie hasło „kiedy będzie czas”.
- Skrót nie wchodzi w regułę, od której zależy kwota na fakturze, chyba że biuro świadomie zgadza się składać dokumenty ręcznie do wskazanej daty.
Bez tych czterech punktów pożyczka zamienia się w stały stan panelu. Sezon się kończy. Kalendarz pustoszeje. Nikt nie otwiera listy, bo listy nie ma. W następnym szczycie dokładany jest kolejny skrót. Po kilku latach panel nadal „działa”, a każda nietypowa umowa wraca do ręcznego składania.
Rejestr nie musi być osobnym programem. Wystarczy wspólna lista w miejscu, w którym i tak planuje się prace przy panelu: ticket, dokument, karta projektu. Ważne, żeby żyła obok zleceń rozwojowych, a nie w głowie jednej osoby. Właściciel serwisu nie musi czytać kodu. Ma prawo wiedzieć, że rozliczenie od obiektu stoi na skopiowanej cenie i że kolejna sieć powtórzy ten sam zator.
Bywa i tak, że skrót zostaje na stałe, bo proces się nie powtórzy. Ekran na jedną akcję marketingową. Import z arkusza przy przejęciu kilku umów. Wtedy spłata nie ma sensu. Sens ma skasowanie ekranu po akcji, żeby nikt nie wziął go za obowiązującą drogę. Dług nieopłacony i niewyłączony zostaje pułapką dla nowego pracownika, który uzna komentarz za magazyn.
Przepisać panel od zera. Kontrargument i granice
Mocny kontrargument brzmi prosto. Stary panel jest do niczego. Taniej i bezpieczniej jest przepisać od zera albo kupić gotowy program dla serwisu i przenieść klientów. Stare skróty zostają za sobą. Zostaje nowy program, czysta struktura i umowa z dostawcą.
W części firm ten argument jest słuszny. Framework nie dostaje poprawek. Nikt w zespole nie rozumie, jak liczy się faktura. Testów nie ma. Osoba, która pamiętała wyjątki, odeszła. Każda zmiana psuje coś po drugiej stronie ekranu. Wtedy ewolucja jest pozorem. Firma łata dziury i udaje, że to modernizacja.
Nawet wtedy całe przepisanie rzadko jest najtańszą drogą. W starym panelu siedzi wiedza o procesie, której nikt nie spisał: wyjątek weekendowy, drugi rozdzielacz na obiekcie, inny odbiorca protokołu. Nowy system startuje „czyściej” i przez pierwsze miesiące uczy się tego od nowa, na żywych fakturach. Gotowy program dla serwisu bywa rozsądny, gdy wizyta, część i faktura są standardowe. Gdy sieć chce ryczałt od obiektu, a inny klient — od urządzenia, gotowiec często kończy się znowu komentarzem i arkuszem obok.
Stąd ograniczone przepisanie: jeden moduł, który blokuje najdroższą zmianę, z jawną granicą. W przykładzie — rozliczenie i status zlecenia, nie kalendarz urlopów i nie raport właściciela. Stary ekran działa, dopóki nowy nie liczy tej samej faktury na zestawie starych umów. Dopiero wtedy ruch się przerzuca. Reszta panelu zostaje.
Granice proponowanego podejścia trzeba powiedzieć wprost. Rejestr skrótów nie naprawi porzuconego frameworka. Nie przywróci osoby, która odeszła. Nie sprawi, że mały zespół utrzyma dwa panele naraz przez rok. Ewolucja działa, gdy da się wskazać miejsce, z którego oferta, zlecenie i faktura biorą regułę — albo gdy da się takie miejsce zbudować obok, bez gaszenia reszty. Nie działa, gdy panel jest kolażem ekranów z kolejnych zleceń i nikt nie umie powiedzieć, która tabela jest prawdziwa.
Bywa też tak, że dług jest polityczny, nie techniczny. Właściciel nie chce ruszać ekranu, bo „działa”. Dyspozytor nie chce wspólnego statusu, bo własny arkusz daje mu kontrolę. Programista nie chce rejestru, bo wtedy widać, co odłożono. Żadna architektura tego nie spłaci. Najpierw trzeba nazwać, kto traci na ręcznym składaniu faktury. Potem dopiero wybierać ewolucję, moduł albo gotowy program.
Arkusz, gotowy program albo ewolucja istniejącego panelu
Kilka ekip, jeden cennik, jedna osoba w biurze — arkusz utrzyma grafik i fakturę, jeśli nikt nie prowadzi drugiej kopii w telefonie. Standardowa wizyta, standardowa część, standardowa faktura — gotowy program często spina się taniej niż własny kod, nawet gdy ten kod dałoby się posprzątać.
Własny panel ma uzasadnienie, gdy proces jest nietypowy. Ryczałt od obiektu obok stawki od awarii. Część w aucie i przy hali. Protokół, który klient sieciowy chce w swoim wzorze. Wtedy spłata długu i ewolucja istniejącego systemu są zwykle tańsze niż nowy start. Nowy start ma sens, gdy starego nie da się już bezpiecznie ruszyć.
GESOFT w takich zleceniach najpierw rozpisuje obieg: kto zamyka zlecenie, skąd bierze się kwota na fakturze, co się dzieje, gdy część zeszła z auta, a nie z hali. Dopiero z tego widać, czy wystarczy porządek w istniejącym panelu. W tym samym zleceniu da się zrobić inwentaryzację długu: spisać skróty, wskazać, która zmiana biznesowa jest przez nie zablokowana, i zaplanować spłatę albo ograniczone przepisanie modułu.
Czasem wystarczy integracja z programem księgowym i jedno miejsce na status. Czasem trzeba zastąpić komentarz magazynem pozycji i zostawić resztę ekranów. Czasem po rozpisaniu obiegu widać, że arkusz nadal wystarczy, jeśli fakturę składa jedna osoba, a nie kilkanaście ekip. Ta rozmowa jest tańsza niż ogłoszenie, że „system trzeba przepisać, bo jest dług”.
Z argumentów zostaje prosta kolejność. Dług technologiczny w rozwijanym oprogramowaniu zaciąga się świadomie i spłaca od najdroższej zmiany procesu. Serwis z przykładu nie potrzebuje ideologii czystego kodu. Potrzebuje listy skrótów, jednego statusu zlecenia i osoby, która po sezonie otworzy tę listę znowu. Bez listy panel nadal „działa”. Umowa z siecią i tak schodzi do arkusza.
Najczęściej zadawane pytania
- Czy każdy skrót w panelu to dług technologiczny?
- Nie. Skrót z właścicielem, wpisem i datą przeglądu to pożyczka. Długem staje się wtedy, gdy nikt nie pamięta, że to skrót, a kolejna zmiana procesu musi objeżdżać kilka miejsc naraz. Ekran na jedną akcję, który po akcji zostaje wyłączony, nie musi być spłacany.
- Kiedy lepiej przepisać moduł, niż łatać istniejący ekran?
- Gdy nikt nie rozumie, jak liczy się faktura, gdy każda zmiana psuje inny ekran, albo gdy warstwa nie dostaje już poprawek. Nawet wtedy zwykle taniej jest przepisać jeden moduł z jawną granicą — status i rozliczenie, nie cały panel — i porównać nową fakturę ze starymi umowami, zanim ruch pójdzie na nowy ekran.
- Czy arkusz kalkulacyjny jest długiem?
- Sam z siebie nie. Staje się problemem, gdy jest drugą, „prawdziwszą” kopią tego, co siedzi w panelu, i gdy faktura zależy od osoby, która ten arkusz zgadza. Kilka ekip i jeden cennik w arkuszu u jednej osoby mogą być tańsze niż własna aplikacja.
Powiązana usługa:
Dedykowane oprogramowanie dla firm
Opisz projekt