Wyobraź sobie sytuację.
Od miesięcy budujesz produkt. Technologia została wybrana, integracja działa, zbliża się termin oddania.
I wtedy ktoś znajduje lepsze rozwiązanie. Szybsze. Nowsze. Być może dokładniejsze.
Co robisz?
W jednym z moich projektów dokładnie taki problem pojawił się przy budowie systemu OCR do dokumentacji medycznej — w ramach projektu IKZMED, o którym piszę szerzej w osobnym artykule.
Do zakończenia pozostawał około miesiąc. I właśnie wtedy pojawił się pomysł zmiany jednego z kluczowych elementów rozwiązania.
Technicznie pomysł miał sens
IKZ OCR powstawał jako moduł pozwalający automatycznie przetwarzać dokumentację medyczną. Dokument trafiał do systemu, OCR odczytywał jego zawartość, a kolejne elementy rozwiązania pozwalały przygotować dane do dalszego wykorzystania.
W trakcie prac pojawiło się alternatywne rozwiązanie OCR, które pod pewnymi względami wyglądało lepiej od wykorzystywanego przez nas silnika.
Naturalna reakcja techniczna brzmi: skoro znaleźliśmy coś lepszego, zmieńmy to.
Tylko że produkt technologiczny nie istnieje w próżni.
Technologia ma koszt zmiany
Wymiana jednego komponentu bardzo rzadko oznacza wyłącznie stary_ocr → nowy_ocr.
- Zmieniają się wyniki.
- Może zmienić się format danych.
- Trzeba ponownie przetestować pipeline.
- Mogą pojawić się nowe przypadki brzegowe.
- Elementy współpracujące z dotychczasowym rozwiązaniem wymagają ponownej weryfikacji.
- Dokumentacja może wymagać aktualizacji.
A każda z tych rzeczy zabiera czas. Gdy do deadline'u pozostaje pół roku, można podjąć takie ryzyko. Kiedy zostaje około miesiąca i przygotowujesz produkt do oddania, równanie wygląda zupełnie inaczej.
„Lepsze" nie oznacza „lepsze teraz"
To jedna z trudniejszych rzeczy w prowadzeniu projektu technologicznego.
Można znaleźć rozwiązanie obiektywnie lepsze technicznie i jednocześnie podjąć prawidłową decyzję, nie wdrażając go.
Dlaczego? Bo decyzja musi uwzględniać nie tylko jakość technologii. Uwzględnia również: czas, ryzyko, koszt zmiany i cel produktu.
W naszym przypadku priorytet był jasny: doprowadzić działające rozwiązanie do końca. Projekt był już na etapie przygotowania do finalnej prezentacji w ramach programu akceleracyjnego. Fundamentalna zmiana jednego z jego elementów na tym etapie mogła przynieść poprawę. Mogła też spowodować, że zamiast trochę lepszego OCR będziemy mieli niedokończony produkt.
Freeze też jest decyzją technologiczną
W branży technologicznej dużo mówi się o podejmowaniu decyzji dotyczących nowych technologii. Znacznie mniej o umiejętności powiedzenia:
Feature freeze czy technology freeze nie oznacza, że produkt jest idealny. Oznacza, że na danym etapie stabilność stała się ważniejsza od dalszej optymalizacji.
W IKZ OCR właśnie tego potrzebowaliśmy. Zamiast przebudowywania fundamentów skupiliśmy się na elementach potrzebnych do ukończenia rozwiązania. Dokończyłem brakujące części produktu, powstał frontend umożliwiający jego obsługę i przygotowaliśmy całość do prezentacji.
Deadline zmienia sposób podejmowania decyzji
Na początku projektu możemy eksperymentować. Możemy sprawdzić trzy biblioteki, dwa modele i kilka różnych architektur. Im bliżej produkcji, tym koszt eksperymentu rośnie.
Dlatego pytanie: „Czy istnieje lepsza technologia?" jest niewystarczające.
Dużo bardziej interesuje mnie:
Jeżeli odpowiedź brzmi „nie wiem", a do premiery został miesiąc, zwykle mamy już część odpowiedzi.
Dowieziony produkt wygrywa z idealnym produktem na localhost
IKZ OCR został ukończony i przygotowany do finału programu akceleracyjnego. Projekt pojechałem następnie zaprezentować i obronić podczas Carpathian Startup Fest.
Oczywiście później można wymienić silnik OCR. Można poprawić modele. Można przebudować pipeline. Można stworzyć kolejną wersję produktu.
Ale żeby móc rozwijać wersję 2.0, najpierw trzeba dowieźć 1.0.
I właśnie dlatego jedną z ważniejszych kompetencji technologicznych nie jest znajomość wszystkich nowych narzędzi. Jest nią wiedza, kiedy przestać je zmieniać.