Rozmowa z Mariuszem Wróblem, Team Leaderem w firmie Edge One Solutions
Kilkanaście lat temu, gdy znacznie wzrosło tempo rozwoju mechanizmów sztucznej inteligencji i uczenia maszynowego, zaczęły pojawiać się głosy, że zawód programisty być może nie będzie miał przyszłości – aplikacje miały pisać się same. Dlaczego prognozy te nie sprawdziły się?
W procesie tworzenia aplikacji człowiek jest niezastąpiony i nie sądzę, żeby zmieniło się to za naszego życia. Działania programistów polegają nie tylko na pisaniu kodu, ale także na rozwijaniu swojego wachlarza dodatkowych umiejętności i wiedzy, wśród których najważniejsze jest poznawanie biznesowych aspektów funkcjonowania danego przedsiębiorstwa, sposobu organizacji pracy, komunikacji pomiędzy poszczególnymi działami w firmie itd. Obecnie jedną z najpopularniejszych architektur aplikacyjnych są mikroserwisy – projekt dzielony jest na małe części, za stworzenie każdej z nich odpowiada grupa programistów, ale wszystkie te części muszą stanowić spójną całość. Dlatego ludzie muszą ze sobą rozmawiać, ustalać zakres prac i weryfikować efekty – nie wyobrażam sobie, żeby za to wszystko miały być odpowiedzialne maszyny.
Niemniej, powstały już przecież generatory kodu…
Tak, ale tylko w tych obszarach, w których wiele rzeczy jest powtarzalnych, przez co praca programistów stawała się odtwórcza, a nie twórcza. Najlepszym przykładem są generatory stron internetowych. Nadal potrzebny jest człowiek, który decyduje jak dana strona ma wyglądać, ale za „przetłumaczenie” jego wizji na język opisu stron dba już generator. Jeżeli są to w dużej mierze pasywne strony, a interakcja z użytkownikiem ograniczona jest co najwyżej do wdrożenia modułu komentarzy lub prostego sklepu internetowego, to nie ma problemu. Ten pojawia się natomiast, gdy konieczne jest zaimplementowanie skomplikowanej logiki biznesowej i spowodowanie, żeby aplikacja zachowywała się w bardzo konkretny sposób.
Czy alternatywą mogłyby być tu platformy no-code, których twórcy chwalą się zapewnianymi możliwościami dostosowania do potrzeb praktycznie każdego odbiorcy?
Tego typu platformy, wbrew obietnicom, mają wiele ograniczeń. Ich architektura dostosowana jest tylko pod konkretne potrzeby. Gdy aplikacje stworzone za pomocą tego typu narzędzi osiągną dużą skalę działania, zaczyna brakować im wydajności. Mogę posłużyć się przykładem: dla Allegro nasza firma tworzyła system obsługi programu Smart. Tego typu funkcji, jak też większości programów lojalnościowych, nie da się obsłużyć za pomocą gotowej platformy. To wszystko trzeba zaprogramować, uwzględniając w tym procesie indywidualne potrzeby związane z aspektami biznesowymi czy logistycznymi, jak też setki niuansów, których twórcy platform no-code po prostu nie przewidzieli. Bywa też, że konieczne jest stworzenie czegoś, czego nikt inny wcześniej nie zrobił. Przez kilkanaście lat swojej programistycznej kariery miałem kilka sytuacji, gdy trzeba było wymyślić coś, czego jeszcze nigdy na rynku nie było. Czasami trzeba było stworzyć zupełnie nowe funkcje, czasami zmodyfikować istniejące, na przykład dostępne w modelu open source.
Co obecnie jest największym wyzwaniem przy prowadzeniu projektów programistycznych?
Zdecydowanie skompletowanie mądrego i bardzo różnorodnego zespołu, który ma wszechstronną wiedzę, ale jednocześnie potrafi współpracować ze sobą i jest komunikatywny podczas rozmów z działami biznesowymi. Tu jest podobnie jak w sporcie – jeśli zbierzemy grupę gwiazd, to one będą się nieustannie kłócić, bo każdy będzie chciał strzelać bramki. A nam potrzeby jest zespół, który jest ze sobą zgrany, tworzy całość i gra do jednej bramki. Gdy w zespole będą sami senior developerzy, którzy mają już wyrobione nawyki, to ciężko będzie im dojść do porozumienia, a wytworzenie kodu potrwa dłużej, bo nie będą mogli znaleźć kompromisu. Równie ważne jest, aby strona biznesowa miała realistyczne wymagania i szanowała zdanie programistów, ze szczególnym naciskiem na prognozowany czas realizacji danego projektu.
Jakiego typu problemy w tym zakresie mogą wystąpić?
Podam hipotetyczny przykład nierealnego oczekiwania biznesowego. Firma w październiku zgłasza potrzebę wdrożenia na swojej platformie sklepu internetowego systemu kodów rabatowych, aby był dostępny jeszcze przed świętami. Tymczasem do realizacji tego zadania konieczne się zmodyfikowanie interfejsu API operatora płatności, na co on potrzebuje miesiąca. My z kolei na całą procedurę potrzebujemy kolejnych dwóch miesięcy, aby przeprowadzić odpowiednie testy, analizy, wdrożyć mechanizmy monitorowania poprawności działania danego systemu i zbierania opinii od użytkowników. To powoduje, że będziemy gotowi, ale dopiero na luty.
Co wówczas należy zrobić?
W takiej sytuacji trzeba wypracować kompromis i z czegoś zrezygnować, akceptując pewne ryzyko, albo tak zaplanować działania, aby rzeczy priorytetowe zostały wdrożone jeszcze przed świętami, zaś dodatkowe zrealizowane w następnej kolejności. Analiza ryzyka na tym etapie jest kluczowa. Może na przykład dostarczyć informacji, że pewien problem potencjalnie dotknie tylko promilowego odsetka użytkowników i manualna pomoc im, np. za pośrednictwem działu obsługi klienta, zajmie mniej czasu niż stworzenie idealnego rozwiązania. Co za tym idzie, bardziej opłaca się z biznesowego punktu widzenia. Równie ważne jest budowanie świadomości klienta, przed jak trudną sytuacją nas postawił.
Czy w warstwie technicznej również pojawiają się tak trudne wyzwania?
Od strony programistycznej praktycznie wszystko jest do zrealizowania, to jest tylko kwestia czasu. Natomiast bardzo dużym wyzwaniem jest zamodelowanie projektu, czyli przeniesienie wizji biznesowej na kod i zaimplementowanie go w już funkcjonującym dużym systemie. Trzeba mieć świadomość, że dotknie on warstw logistyki, płatności, integracji z innymi operatorami… Aby skutecznie wszystko ze sobą zintegrować, konieczne jest porozumienie się z zewnętrznymi dostawcami, przedyskutowanie sposobu implementacji po ich stronie, uzgodnienie wszystkich kontraktów itd. Następnie zaś projekt należy podzielić na mniejsze części i wykonać.
Można odnieść wrażenie, że przy realizacji tego typu projektów aspekty techniczne nie odgrywają większej roli, zarówno po stronie biznesowej, jak też programistycznej, ale kluczowe są tzw. umiejętności miękkie i predyspozycje do pracy w zespole…
Zgadza się. Oczywiście, umiejętności techniczne są ważne i konieczne jest ich posiadanie na pewnym poziomie. Ale jeśli tworzone oprogramowanie dotyczy głównie warstwy biznesowej, a nie jakiejś wąskiej specjalizacji, np. pisania skomplikowanych algorytmów czy tworzenia sterowników dla nowego sprzętu, to nasze zadania technicznie są relatywnie proste i bazują na łączeniu poszczególnych elementów ze sobą, ewentualnie uzupełnianiu ich o potrzebne funkcje. Opracowujemy mechanizmy, które muszą liczyć, analizować, wyświetlać treści w określony sposób, współpracować z systemami innych dostawców itd. Potrafimy to robić, bo robimy to od lat. Co więcej, korzystamy z frameworków, w których wiele z takich mechanizmów, jak na przykład sortowanie czy porównywanie obiektów, już zostało zaimplementowanych, wystarczy więc umiejętnie z nich korzystać. Najważniejsze więc staje się umiejętne przeniesienie struktury organizacyjnej projektu na strukturę aplikacji. Dzięki temu można podzielić system na małe części, przydzielić opiekę nad kodem poszczególnym zespołom i zapewnić ich skuteczną współpracę.
Jeśli poszukujesz zespołu programistów z wieloletnim doświadczeniem, skontaktuj się z nami!
