Czy budować własny zespół programistyczny?

Grzegorz Papaj, 4 października 2019

Czy budować własny zespół programistyczny?

W epoce informatyzacji praktycznie nie ma poważnego biznesu, który by w większym lub mniejszym stopniu nie bazował na rozwiązaniach programistycznych. Oczywiście wiele firm korzysta z dostępnych na rynku gotowych produktów, niemniej jednak wraz ze wzrostem i specjalizacją biznesu pojawia się często potrzeba stworzenia oprogramowania dedykowanego (więcej o tym można przeczytać w artykule Aplikacje na zamówienie – 10 powodów za). System dedykowany można zamówić u dostawcy lub zbudować własnym zespołem programistycznym (jeśli się taki posiada).

Zespół programistyczny

Budować własny zespół programistów czy zatrudnić firmę?

Kiedy zapadła już decyzja o zbudowaniu oprogramowania dedykowanego, firma staje przed wyborem: zaangażować zewnętrzną firmę albo zatrudnić programistę/programistów.

Tworzenie działu programistycznego – wady i zalety

Każde z tych podejść ma swoje wady i zalety. W pierwszym przypadku do wyboru mamy kilka modeli współpracy (więcej o nich można poczytać w tekście Modele współpracy z firmą programistyczną). Tutaj skupimy się na tym drugim wariancie – na budowaniu zespołu programistycznego.

Zrozumienie potrzeb

Zbudowanie własnego działu programistycznego może przynieść firmie wiele korzyści. Najbardziej oczywistą jest dobre zrozumienie potrzeb. Nikt lepiej nie zrozumie wymagań i oczekiwań firmy i poszczególnych pracowników niż członek zespołu. Pracując na miejscu, posiadając obszerną wiedzę o funkcjonowaniu firmy i wiedzący kogo o co należy zapytać, własny programista może świetnym wykonawcą dedykowanego oprogramowania.

Z drugiej strony jednak bywa, że własny zespół ma nieco zniekształconą perspektywę. Na podejmowane przez niego decyzje projektowe może wpływać rutyna i przywiązanie do utartych w firmie procedur. Częstą sytuacją jest również przywiązanie do technologii, które członkowie zespołu znają i darzą sympatią, podczas gdy nie są to rozwiązania optymalne dla danego problemu. Nie bez powodu w korporacjach (a na Zachodzie również w firmach średniej wielkości) często zatrudniani są zewnętrzni konsultanci, którzy z dystansu oceniają jakość i sensowność stosowanych rozwiązań.

Koszty

Dodatkowym argumentem za własnym zespołem programistycznym są zazwyczaj koszty zatrudnienia. Jeśli przyjąć, że zarówno my jak i firma programistyczna, zatrudniamy pracownika za identyczną rynkową stawkę, to oczywiste jest, że dostawca musi doliczyć do stawki godzinowej programisty również swoją marżę. Zatem koszt godziny pracy własnego programisty będzie zdecydowanie niższy.

Niemniej jednak dostawca bierze na siebie mniej oczywiste koszty, zwykle pomijane w porównaniach. Chodzi o obciążenia związane z samym procesem rekrutacji, zapewnieniem ciągłości (np. zastępstw w przypadku chorób) czy administracji. Choć koszty te mogą być trudne do oszacowania, warto o nich pamiętać w ogólnym rozrachunku.

Ryzyka

Niestety zatrudnienie programisty wiąże się z szeregiem ryzyk. Największym jest zatrudnienie programisty o nieodpowiednich kwalifikacjach. Ryzyko jest szczególnie duże w przypadku pierwszego specjalisty IT w firmie – nie mając zaufanej osoby o wysokich kompetencjach technicznych niezwykle trudno jest zweryfikować umiejętności programisty. Zresztą nawet mając wsparcie w postaci doświadczonego kodera nadal łatwo popełnić na tym polu błędy (wkrótce napiszemy o tym w osobnym artykule).

Jako że większość firm przystępuje do budowy działu programistycznego od zatrudnienia jednego pracownika, ryzyko to znacznie się potęguje. Ponadto w jednoosobowych działach programistycznych pojawiają się dodatkowe czynniki ryzyka, które niejednokrotnie obserwowaliśmy u naszych klientów:

  • niedostateczne kompetencje do prowadzenia dużych projektów – programista, który sprawdza się przy małych zadaniach niekoniecznie musi być w stanie okiełznać duży system;
  • brak ciągłości prac – w przypadku dłuższej niedostępności programisty (np. na skutek choroby) rozwój projektu jest wstrzymywany;
  • przywiązanie do nieoptymalnych technologii – programista stosuje te rozwiązania, które zna i lubi, nie zawsze przy tym dbając o poszerzanie swojej wiedzy w obszarze nowych technologi;
  • eksperymentowanie – wykorzystywanie firmowego projektu do nauki nowej dla programisty technologii (nierzadko są to dość „egzotyczne” technologie, dla których brakuje specjalistów na rynku pracy);
  • brak kontroli – w zasadzie nikt w firmie nie wie, co robi programista i czy robi to właściwie;
  • skupienie całej wiedzy projektowej w jednej osobie, co bywa problematyczne, gdy programista odejdzie z firmy.

Cztery ostatnie punkty prowadzą często do sytuacji, które opisaliśmy w artykule Systemy informatyczne – nietypowe kłopoty.

Elastyczność

Elastyczność jest jednym z najważniejszych elementów decydujących o udanym bądź nieudanym wdrożeniu oprogramowania dedykowanego w firmie. Zazwyczaj praca własnym zespołem pozwala na osiągnięcie wysokiej elastyczności – w końcu to szef lub zarząd samodzielnie decydują, w jakim kierunku mają iść prace programistyczne. Nie są przy tym związani żadną umową, którą by trzeba renegocjować aby zmienić zakres prac lub nawet porzucić projekt. Warto jednak w tym momencie wspomnieć, że również w przypadku dostawców usług programistycznych możliwa jest równie elastyczna współpraca (o czym więcej napisaliśmy w artykule Modele współpracy z firmą programistyczną).

Z drugiej strony jednak zatrudnienie zespołu jest zobowiązaniem długoterminowym. Zwolnienie pracownika firmy nigdy nie jest ani łatwe ani przyjemne. Zdecydowanie łatwiej wypowiedzieć umowę dostawcy niż pracownikowi, często mocno zżytemu z innymi członkami zespołu. Dlatego więc, jeśli nie mamy w planach stałego rozwoju oprogramowania w firmie, prawdopodobnie lepiej pomyśleć o podwykonawcy.

Kolejnym aspektem elastyczności jest dobór właściwej technologii do projektu. Jak już to wcześniej opisaliśmy, zespół programistyczny ma tendencje do preferowania technologii, które zna, a które nie zawsze są najlepsze w danej sytuacji.

Zaangażowanie

Jeśli jednak zdecydujemy już się na budowę własnego zespołu programistycznego, warto wiedzieć, że zbudowanie dobrego zespołu (dotyczy to w równym stopniu także obszarów innych niż programowanie) wymaga czasu i zaangażowania. Dobór i weryfikacja umiejętności kandydatów na stanowiska programistyczne, doszkalanie ich (zarówno technologiczne jak i w temacie funkcjonowania przedsiębiorstwa), zarządzanie nimi i rozwiązywanie bieżących problemów wymagają sporego nakładu prac.

Jeśli zespół jest jedno- lub dwuosobowy, często pracuje bezpośrednio „pod zarządem”. Jeśli jednak jest większy, niezbędna staje się osoba zaufanego kierownika, który zdejmie z zarządu część administracyjną, pozwalając skupić się na celach strategicznych działu programistycznego. Niestety znalezienie dobrego kierownika programistów jest jeszcze trudniejsze niż znalezienie dobrego programisty.

Najważniejsze cechy kierownika zespołów programistycznych opisaliśmy w artykule Trzy filary dobrego kierownika projektów informatycznych.

Podsumowanie

Rozważając budowę działu programistycznego w swojej firmie możesz oczekiwać, że

  • potrzeby Twojej firmy będą dobrze rozumiane,
  • bezpośrednie koszty zatrudnienia będą mniejsze,
  • zarządzanie projektem może być bardziej elastyczne.

Jednocześnie musisz się liczyć tym, że:

  • istnieje szereg ryzyk związanych z zatrudnieniem niekompetentnych ludzi,
  • będziesz miał mniejszą elastycznością w doborze technologii,
  • zbudowanie zespołu wymaga czasu i wiąże się z kosztami (rekrutacyjnymi i administracyjnymi),
  • zatrudnianie pracowników stanowi zwykle większe zobowiązanie niż praca z zewnętrznym dostawcą,
  • w którymś momencie możesz potrzebować kierownika.

Zatem czy warto budować własny zespół programistyczny? Oczywiście w dużym stopniu zależy to od sytuacji firmy, planowanego wdrożenia oraz przewidywanych kierunków rozwoju. Nie ma zatem jednej prostej odpowiedzi dla każdego.

Niemniej jednak nawet podejmując decyzję o tworzeniu własnego zespołu zwykle warto pierwszy projekt programistyczny zrealizować za pomocą dostawcy, zdobywając od niego cenne informacje na temat prowadzenia projektów IT i zarządzania programistami.

Można również spróbować podejścia „hybrydowego”, zaczynając od zatrudnienia własnego kierownika, który będzie nadzorował i kierował pracami zewnętrznego zespołu. Jeśli mamy sprawdzonego kandydata na to stanowisko, może to być dobre rozwiązanie na początek. W końcu nawet wyspecjalizowane firmy programistyczne czasem posiłkują się dostawcami.

I na koniec, jeśli oceniamy, że nasze potrzeby zaspokoi jeden programista, ze względów organizacyjnych zazwyczaj lepiej jest lepiej pomyśleć o zewnętrznym dostawcy.