Wewnętrzny zespół vs. outsourcing – co się bardziej opłaca na różnych etapach rozwoju projektu?

Decyzja, co robić in-house, a co podzlecać, jest jednym z kluczowych problemów przy tworzeniu projektu aplikacji mobilnej. Moim zdaniem wybór powinien być uzależniony przede wszystkim od momentu życia produktu. Jedynym przypadkiem, w którym od początku można ograniczyć rolę software house’u do audytów i wsparcia w tworzeniu/wdrażaniu nietypowych elementów projektu, jest sytuacja, kiedy zespół tworzący firmę od początku posiada wszystkie niezbędne kompetencje techniczne.

Etap początkowy

Na samym początku jest często pomysł i brak wiedzy, jak go zrealizować. Tutaj rola software house’u może być zbawienna dla projektu. Do największych zalet SH można zaliczyć:

Czas i koszt – rekrutacja zespołu, wdrożenie go w projekt, dopasowanie ludzi do kultury organizacyjnej itd. to duży wydatek (o wiele większy niż koszt stworzenia przez podwykonawcę) i do tego dodatkowe tygodnie na samym początku, żeby stworzyć dobrze działający zespół. Przy małych projektach i tak potrzeba kilku różnych specjalistów, którzy nie są wymagani na pełen czy nawet pół etatu. Software house zapewnia rozwiązanie tych problemów. To dalej jest przedsięwzięcie za dziesiątki tysięcy, ale to wciąż bardziej opłacalne niż tworzenie działu IT od zera.

Elastyczność – niezależnie, czy podwykonawca rozlicza się w systemie Time & Material, czy Fixed Price, ma się o wiele większą elastyczność niż z własnym zespołem, któremu zawsze trzeba płacić pensję. Software house może zawsze poczekać z jakimś etapem, inaczej się rozliczyć, coś potraktować priorytetowo itd. Możliwości elastycznego zarządzania budżetem są zazwyczaj większe niż z własnym zespołem. Kilka miesięcy bez pracy to kilka miesięcy bez kosztów, a zawsze czeka gotowy zespół, żeby wziąć projekt, gdy tylko będzie trzeba.

Należy popatrzeć tutaj na potencjalne zagrożenia outsourcingu:

Solidność podwykonawcy – przy software housie nie ma się tak dokładnego spojrzenia na to, co się dzieje, jak przy własnym zespole. Wybranie odpowiedzialnego i terminowego partnera jest kluczowym zadaniem przy outsourcingu. Firma, z którą pracujemy, będzie często nam towarzyszyła przez lata, dlatego dobrze dwa razy przemyśleć, czy na pewno ta nam pasuje i czy możemy jej zaufać. Warto tutaj patrzeć nie tylko na umiejętności techniczne, ale też na to, jak nam się pracuje z daną firmą. Ważne jest, żeby się ostatecznie choć trochę lubić, bo to kompletnie zmienia komfort tworzenia produktu.

Brak pełnego know-how projektu – jest to pewne ryzyko, które trzeba podjąć, decydując się na software house. Tracimy część wiedzy, jak to zostało zrobione, a wdrożenie nowych osób w taki projekt będzie trudniejsze niż w projekty prowadzone od początku wewnątrz firmy.

Trudniejsze pivoty – jeżeli trzeba coś szybko zmienić i jest to absolutnie kluczowe dla przetrwania projektu, to wtedy może wyjść pazerność podwykonawcy. Na rynku zdarzały się sytuacje, że projekt musiał szybko coś zmienić, a firma podnosiła wtedy swoją stawkę. Problem ten sprowadza się przede wszystkim do solidności podwykonawcy. Moim zdaniem jest to działanie szkodliwe dla całej branży.

Etap dojrzewania projektu

Po roku czy dwóch, osiągnięciu rentowności, rozbudowaniu projektu, następuje okres, kiedy warto się stopniowo uniezależniać od software house’u. Część zadań staje się coraz bardziej przewidywalna. Jeżeli co miesiąc programista w software housie poświęca około 120–160 godzin na dany projekt, to racjonalną decyzją jest przejęcie jego obowiązków przez programistę in-house.

Pierwszą zaletą jest niższy koszt (software house musi sobie doliczyć marżę, żeby istnieć), a drugą – większa kontrola nad projektem (własny pracownik jest zawsze pod ręką). Rola software house’u z każdym zatrudnionym pracownikiem maleje. Natomiast jest to dalej istotny partner we wprowadzaniu dużych zmian – wtedy współpracuje z zespołem wewnętrznym. Jeżeli projekt był przy firmie od początku, to często zna produkt lepiej od wewnętrznego zespołu IT, który został zrekrutowany dopiero potem.

Przez długi czas zostaje wiele ról, które lepiej zostawić podwykonawcy. Zatrudnienie kolejnych osób jest nieopłacalne, a zmuszanie programistów o danej specjalizacji, żeby znali się 5 godzin w miesiącu na czymś innym, jest dość ryzykowne. Tutaj należy wymienić część zadań QA, DevOps, UI/UX.

Dojrzały projekt

W końcu następuje moment, kiedy większość kluczowych ról jest obsadzona przez dedykowanego pracownika. To jest moment, kiedy software house przestaje być firmą od „robienia rzeczy”, a zostaje bardziej partnerem od doradztwa. Dalej warto zlecać audyty bezpieczeństwa czy audyty UX poza firmą (żeby nie być sędzią we własnej sprawie). Warto wykorzystać spojrzenie z zewnątrz i prowadzić spotkania wewnętrznego zespołu z firmą, która projekt prowadziła od początku. Mając dwa punkty widzenia, trudniej jest poświęcić duże środki na nieracjonalną hipotezę.

Dochodzi tutaj możliwość rozpoczęcia wszystkiego od początku, czyli stworzenia kolejnej linii biznesowej wewnątrz firmy. Wtedy niezbędne jest powiększenie zespołu. Zamiast rekrutować na parę miesięcy, często lepiej wrócić do sprawdzonego podwykonawcy. Różnica polega przede wszystkim na tym, że w takiej opcji od początku w projekcie uczestniczy zespół in-house – dzięki temu straty know-how projektu są zminimalizowane.

Software House nie jest ani najlepszą opcją, ani złem wcielonym. To po prostu kontrahent, którego usługi można wykorzystać do wzrostu biznesu. Wiedząc jak to zrobić, współpraca może być wybitnie korzystna.