Co robi inżynier pracujący bezpośrednio w procesie oraz kiedy jest potrzebny

Inżynier pracujący bezpośrednio w firmie klienta to inżynier oprogramowania, który działa w ramach procesów klienta, a nie tylko nad zaległymi zadaniami. Pracuje razem z osobami, które będą korzystać z narzędzia, dowiaduje się, w jaki sposób faktycznie wykonywane są prace, tworzy pierwszą wersję na podstawie rzeczywistych danych i pozostaje do momentu, aż narzędzie zostanie wdrożone w codziennej działalności. Nazwa ta pochodzi od firm sprzedających złożone oprogramowanie dużym organizacjom, gdzie produkt funkcjonuje tylko wtedy, gdy zostanie zintegrowany z systemami i praktykami klienta.

Taki sposób pracy nadaje się również dla małych i średnich firm, być może nawet lepiej. Mała firma rzadko posiada wewnętrzny zespół IT, który potrafi przekształcić niejasną ideę („Czy sztuczna inteligencja może odczytać nasze certyfikaty dostawców?”) w specyfikację. Potrzebuje osoby, która potrafi przeprowadzić badania, napisać kod i przejąć odpowiedzialność za wynik.

Co faktycznie obejmuje ta rola

Większość pracy odbywa się przed i po napisaniu kodu. Typowe zlecenie przechodzi przez cztery fazy:

• Odkrywanie. Rozmowy z osobami wykonywającymi pracę, przegląd rzeczywistych dokumentów, arkuszy kalkulacyjnych i systemów oraz pisemny opis obecnego procesu wraz z jego wyjątkami. Wyjątki są najważniejsze, ponieważ to właśnie tam automatyzacja zawodzi.
• Prototyp. Narzędzie działające na próbkach rzeczywistych danych w ciągu kilku dni, a nie tylko zestaw slajdów. Jest to wersja wstępna, ale ludzie mogą nią korzystać i wskazać, co jest nie tak.
• Produkcja. Kontrola dostępu, obsługa błędów, rejestracja działań, monitorowanie, kopie zapasowe, etap weryfikacji, w którym osoba zatwierdza niepewne wyniki, oraz zestaw testowy pokazujący, czy narzędzie nadal funkcjonuje po każdej zmianie.

Przekazanie i wsparcie. Dokumentacja, krótkie szkolenie dla zespołu oraz ustalony sposób zgłaszania problemów i proszenia o zmiany.

W czym różni się od klasycznego projektu

W projekcie o ustalonej zakresie klient określa wymagania, dostawca je realizuje, a obie strony kłócą się co do ich znaczenia. To działa, gdy problem jest dobrze zrozumiały, np. przy nowej stronie internetowej lub znanej integracji.

Automatyzację opartą na sztucznej inteligencji rzadko jest możliwe dobrze zrozumieć na początku. Nikt nie wie, ile faktur ma nietypową strukturę, jak często dostawca wysyła skan zamiast pliku PDF, ani jakie zasady stosuje księgowy bez ich zapisania. Inżynier, który pracuje bezpośrednio nad projektem, dowiaduje się tego poprzez pracę z materiałem, dzięki czemu zakres projektu kształtuje się na podstawie faktów, a nie domysłów.

Różni się to również od zwiększania liczby pracowników. Programista wspomagający otrzymuje zlecenia od kierownika zespołu. Inżynier pracujący na miejscu powinien decydować, co należy stworzyć, sprzeciwiać się, gdy jakaś idea nie przynosi rezultatów, oraz oceniać, czy uzyskany efekt jest skuteczny.

Kiedy mała firma potrzebuje takiej pomocy

Ten model ma sens, gdy zachodzą następujące warunki:

• powtarzalny proces pochłania godziny co tydzień: czytanie dokumentów, kopiowanie danych między systemami, sprawdzanie terminów, odpowiadanie na te same pytania;
• dane znajdują się w wielu miejscach: w systemach ERP lub 1C, plikach Excel, załącznikach e-maili, folderach udostępnionych, zeskanowanych dokumentach papierowych;
• ktoś już próbował chatbota lub prototypu ChatGPT i działa on dobrze w demonstracji, ale nie w rzeczywistych przypadkach;
• nie ma wewnętrznego programisty, który zna zarówno specyfikę biznesu, jak i technologię.

Brakuje sensu, gdy proces zmienia się co miesiąc, gdy nie ma nikogo po twojej stronie, kto mógłby poświęcić kilka godzin tygodniowo na odpowiadanie na pytania, lub gdy gotowe narzędzie już wykonywało to zadanie. W takim przypadku lepiej kupić takie narzędzie.

Co można oczekiwać w pierwszych dwóch tygodniach

Nasze współprace rozpoczynamy od dwutygodniowego okresu o ustalonej cenie. Pod koniec tego czasu powinieneś mieć trzy rzeczy: pisemny opis procesu wraz z wyjątkami znalezionymi w rzeczywistych danych, prototyp działający na próbce twoich dokumentów lub zapisów, oraz szczere oszacowanie czasu potrzebnego na pełną implementację, w tym wskazanie tego, co w ogóle nie powinno być zautomatyzowane.

Po tym decydujesz, czy kontynuować współpracę. Pełna realizacja zwykle trwa od dwóch do sześciu tygodni, w zależności od liczby zaangażowanych systemów oraz stopnia potrzeby ponownej weryfikacji wyników.

Pytania, które należy zadać przed zatrudnieniem kogoś

• Czy inżynier będzie pracował z naszymi rzeczywistymi danymi od pierwszego tygodnia i w jaki sposób kontrolowany jest dostęp?
• Skąd mamy wiedzieć, że narzędzie jest poprawne? Prosimy o zestaw testowy i odpowiednie metryki, a nie obietnice. Nasze notatki na temat ocen i przeglądu przez ludzi opisują, jak to wygląda w praktyce.
• Gdzie działają modele i czy jakiekolwiek z naszych danych opuszczają naszą infrastrukturę? Informacje na temat plików poufnych znajdują się pod adresem lokalnego AI do plików poufnych.
• Co się dzieje po przekazaniu: kto to naprawia, gdy dostawca zmienia format faktury?

Jeśli odpowiedzi będą niejasne, projekt również będzie taki. Jeśli chcesz omówić konkretny proces, nasza strona forward-deployed engineering opisuje, w jaki sposób realizujemy takie zlecenia, a ty możesz do nas odpisać za pośrednictwem formularza kontaktowego.