Co tydzień pojawia się nowa firma obiecująca dostarczyć aplikację w połowie czasu i za połowę ceny. Drobny druk jest niemal zawsze taki sam: sporej części tego oprogramowania nie napisał człowiek, wygenerowała je sztuczna inteligencja.
Postanowiliśmy tego nie robić. Nie z braku zaufania do technologii — korzystamy z niej na co dzień w innych zadaniach — ale ze względu na to, co dzieje się z projektem, gdy nikt w zespole nie rozumie do końca tego, co zostało dostarczone.
Problemem nie jest pierwsza wersja
Automatycznie wygenerowana aplikacja zwykle działa dobrze pierwszego dnia. Problem pojawia się trzy miesiące później, gdy trzeba coś zmienić.
Wtedy padają pytania, które decydują o tym, czy projekt idzie do przodu, czy zamienia się w studnię bez dna: dlaczego zostało to zrobione właśnie tak? co się stanie, jeśli to ruszę? czy to można usunąć? Jeśli osoba, która dostarczyła oprogramowanie, nie potrafi odpowiedzieć, każda zmiana staje się loterią.
Wywodzimy się z systemów, w których awaria nie jest drobną niedogodnością. Álvaro utrzymywał oprogramowanie do zarządzania ruchem lotniczym, Adrián — usługi monitorujące infrastrukturę gazową. W takich środowiskach uczysz się jednej bardzo konkretnej rzeczy: kod czyta się o wiele częściej, niż się go pisze. Optymalizowanie szybkości pisania kosztem czytelności to zły interes.
Co naprawdę się dla nas liczy
Kiedy mówimy, że piszemy kod ręcznie, nie chodzi nam o romantyczne rzemiosło. Chodzi o trzy bardzo praktyczne rzeczy:
- Ktoś odpowiada. Jeśli coś przestaje działać, jest osoba, która wie, dlaczego zostało napisane w ten sposób, i potrafi to naprawić w kilka godzin, a nie tygodni.
- Aplikacja nie rozrasta się sama. Generowany kod ma tendencję do powielania się. Powielony kod oznacza, że każdą zmianę trzeba wprowadzić w pięciu miejscach, a prędzej czy później ktoś o jednym zapomni.
- Decyzje o Twoich danych zapadają z rozwagą. To, gdzie przechowywana jest dana osobowa, jak długo i kto ma do niej dostęp, nie jest decyzją techniczną, tylko prawną. U nas weryfikuje ją Jhonathan, który jest prawnikiem.
Czy to oznacza, że jesteśmy wolniejsi?
Na początku czasem tak. W skali całego projektu — prawie nigdy.
To, co oszczędzasz na generowaniu kodu, wydajesz później na poprawianie dziwnych zachowań, na tłumaczenie po raz dziesiąty, jak coś działa, albo na przepisywanie całego fragmentu, bo nikt nie chce go już dotykać. Wolimy rozłożyć ten wysiłek od początku i dojść do końca bez niespodzianek.
Pomaga też to, że nie przyjmujemy wszystkiego, co do nas trafia. Jeśli projekt nie mieści się w dostępnym terminie lub budżecie, mówimy o tym przed startem, zamiast odkrywać to w połowie drogi.
Jak to sprawdzić, porównując dostawców
Nie trzeba być technikiem, żeby odróżnić jedno podejście od drugiego. Wystarczą trzy pytania na pierwszym spotkaniu:
- Kto dokładnie będzie pisał moją aplikację i czy ta osoba będzie dostępna za rok?
- Jeśli za pół roku będę potrzebować zmiany, ile czasu zajmie Wam ocena jej wpływu?
- Kto sprawdza, jak przetwarzane są dane osobowe moich pracowników lub klientów?
Odpowiedzi na te trzy pytania mówią o jakości tego, co otrzymasz, więcej niż jakakolwiek prezentacja handlowa.
Jeśli chcesz zobaczyć, jak stosujemy to w praktyce, zajrzyj do OnTempo, naszej aplikacji do ewidencji czasu pracy i zarządzania zespołem, albo po prostu napisz do nas.
Czy ten tekst był przydatny?
Jeśli chcesz się czymś podzielić albo masz pytanie o swoją sytuację, napisz do nas.