Bartosz Obermüller

Każda firma musi czasem podejmować strategiczne decyzje dotyczące swoich działań, kierunków rozwoju, podziału ról, struktury zespołu i wielu innych. Taka sytuacja dotyczy też naszej firmy – na bieżąco weryfikujemy sytuację, w jakiej znajduje się nasz zespół, realizowane projekty, relacje z klientami i oczywiście finanse.

Nasza firma to niewielki softwarehose, czyli firma tworząca oprogramowanie – głównie dedykowane rozwiązania tworzone na zamówienie klientów. Staramy się, by programy, które projektujemy i wykonujemy, spełniały oczekiwania klienta od strony funkcjonalności, były bezpieczne, ale też nowoczesne – zarówno od strony wizualnej, jak i technologicznej. 

Wykorzystywanie najnowszych technologii to z jednej strony duże ułatwienie dla nas jako twórców, bo rozwój technologii przynosi wiele usprawnień dla zespołów programistycznych. Z drugiej strony jest to wynik oczekiwań programistów, którzy oczekują umożliwienia im ciągłego rozwoju i pracy stale w najnowszym środowisku.

Mamy jednak w naszej ofercie takie programy, które zbudowaliśmy kilka lat temu jako własne produkty i oferujemy je naszym klientom jako gotowe rozwiązania lub baza do dalszej rozbudowy i adaptacji. Są to aplikacje wielokrotnie wdrożone w firmach naszych klientów, sprawdzone, gruntownie przetestowane i bardzo dobrze oceniane. Jednak, co pewien czas pojawiają się ze strony klientów prośby o wprowadzenie zmian lub rozbudowę używanych przez nich programów. I tu pojawia się kłopot, ponieważ programy te, jak już wspomniałem, zbudowane są kilka lat temu i wykorzystana została w nich technologia, która nowoczesna była w momencie ich budowy. Dziś już taka nie jest. 

To, oczywiście, nie przekreśla tych programów i nadal mogą być wykorzystywane z powodzeniem przez ich użytkowników. Powoduje natomiast problem z ich aktualizacją i rozwojem, bo większość programistów niechętnie zabiera się do pisania “starodawnego” kodu.

Stanęliśmy przed poważnym dylematem: Co zrobić? Jak sobie poradzić z taką sytuacją? 

Co mówi o podobnych sytuacjach teoria prowadzenia projektów informatycznych? 

Jedna z teorii sugeruje, by stare kawałki kodu pozostawiać nietknięte, a dopisywać nowe fragmenty w nowoczesnych technologiach i komunikować ze sobą stare z nowymi przez protokoły komunikacyjne (tzw. api). Stopniowo, dzięki takim zabiegom, stary kod zostanie wyparty przez nowy i całość będzie zbudowana w nowoczesnej technologii. Powoduje to jednak duży chaos w projekcie, a poza tym w perspektywie czasu te nowe fragmenty też w końcu staną się stare i sytuacja się powtórzy.

Inna teoria mówi o tym, że najlepiej jest przepisać cały stary system na nową technologię. Dzięki temu klient otrzyma system o dotychczasowych funkcjonalnościach, a użyta technologia będzie łatwa do rozwoju, bo atrakcyjna dla programistów. Wiąże się to jednak z olbrzymimi kosztami (rosnącymi wykładniczo wraz ze stopniem skomplikowania projektu). Zwykle klient nie jest w stanie ponieść tak dużych kosztów, szczególnie, gdy jego oczekiwania dotyczą drobnych zmian w istniejącym oprogramowaniu. Ponadto efekt końcowy jest niepewny – zarówno od strony ilości błędów, jakie pojawią się w nowym oprogramowaniu (potencjalna ilość błędów także rośnie wraz ze wzrostem stopnia skomplikowania programu), jak i ochoty do korzystania z nowego systemu przez klienta. Bo oczywistym jest, że wraz ze zmianą technologii będziemy chcieli wprowadzić pewne drobne zabiegi odświeżenia interface’u systemu – a to zwykle jest kłopotliwe dla klientów, którzy nie lubią zmian.

Doskonałym przykładem jest historia firmy InsERT, producenta programu Subiekt, który został sprzedany w ilości ponad 700 tysięcy licencji. Niekwestionowany lider polskiego rynku. Kilka lat temu firma ta postanowiła wprowadzić na rynek nową wersję swojego programu – nazwała go NEXO. Program miał zastąpić rodzinę starszych programów oznaczonych “GT”, do której należy program Subiekt GT. Niestety, pomimo tego, że nowy program jest nowoczesny, wykorzystuje najnowsze technologie, nowe trendy wizualne, to zaledwie niewielki procent klientów Subiekta zdecydowała się na przejście na nowy program. Subiekt GT ma się nadal doskonale i nic nie wskazuje na to, by firmy gremialnie zdecydowały się z niego rezygnować.

W mojej karierze większość programistów, których poznałem, oczekiwało zmienności projektów, stałego rozwoju i zawsze najnowszych technologii. Często popartych szkoleniami. Spotkałem jednak kilku takich, którzy cenili sobie fakt, że są dobrzy w tym, co robią. Nie chcieli się rozwijać, zmieniać technologii, ani uczyć się nowości – wystarczyło właściwie zdefiniować im zadania, wskazać brzegowe założenia, a oni, ze znanych sobie “klocków”, byli w stanie zbudować bardzo skuteczne i efektywne programy.

Podjęliśmy więc decyzję o tym, że chcemy poszukać takich właśnie pracowników na rynku i zdecydowaliśmy się rozpocząć proces rekrutacji. Pozyskanie takich programistów pozwoli nam utrzymać obecny kod istniejącego oprogramowania w dotychczasowej postaci i rozwijać go sukcesywnie ku uciesze zarówno klientów, jak i samych programistów. 

Stworzyliśmy i opublikowaliśmy ogłoszenie następującej treści:

Efekt końcowy naszego procesu rekrutacji będzie stanowił okazję do stworzenia kolejnego wpisu. Już dziś zapraszam Cię do śledzenia konsekwencji naszych decyzji.

Udostępnij ten artykuł