Glass building

Dlaczego software-house ma sens?

Software-house to typ firmy, która nie prowadzi własnego realnego biznesu, jak produkcja, handel czy usługi „dla ludności”, a zamiast tego dostarcza usługi tworzenia i utrzymania oprogramowania dla innych firm. Od kilkunastu lat pracuję w takiej firmie (e-point S.A.) i obserwuję jak działają zespoły programistyczne i jak dostarczają wartość dla klientów. Celem niniejszego artykułu jest przedstawienie dwóch perspektyw: dla klientów (firm) oraz dla pracowników software-house’u, czyli najczęściej programistów. Nie twierdzę że każdy software-house, ani że firma w której pracuję tak idealnie działa, to jest to pożądany stan docelowy :-).

Wprowadzenie do tworzenia oprogramowania

W klasycznym modelu zwykła firma, na przykład wydawnictwo, potrzebująca wytworzenia dedykowanego oprogramowania (tzn. nie takiego „z pudełka” jak MS Office, gotowy system klasy ERP, itp.) mogłaby zatrudnić sobie programistów, opowiedzieć im co jest do zrobienia, dać czas na napisanie kodu i w efekcie cieszyć się działającą aplikacją, ponosząc minimalne koszty dodatkowe. Jest to bardzo optymistyczny scenariusz, który ma szansę zaistnieć tylko dla małych i dobrze sprecyzowanych projektów, jak na przykład wykonanie niedużej strony internetowej. Dlaczego jest bardzo duże ryzyko, że takie podejście nie zadziała dla dużego projektu? Oto kilka powodów:

  • dobrych programistów jest bardzo trudno znaleźć na rynku,
  • osobom bez doświadczenia jest bardzo trudno odróżnić dobrych programistów od słabych „skoczków” (osoby często zmieniające prace),
  • firmie bez „kultury pracy IT” trudno jest stworzyć atrakcyjne warunki do pracy dla programistów, więc w efekcie przekonać ich czymkolwiek innym niż wynagrodzenie,
  • wytworzenie i uruchomienie dobrego oprogramowania często wymaga szerszych kompetencji niż tylko programowanie, np. umiejętności projektowania UX (interfejsu użytkownika), projektowania modelu bazy danych i dalszych optymalizacji zapytań, tworzenia kodu interfejsu użytkownika (najczęściej w języku JavaScript oraz CSS), testowania – więc wymagałoby to zatrudnienia kolejnych osób, często potrzebnych nie w całym okresie projektu lub nie na cały etat,
  • tworzenie oprogramowania powinno być poprzedzone analizą i spisaniem wymagań i zaplanowaniem etapów prac, a w trakcie trwania projektu postępy powinny być monitorowane, więc to również może wymagać zatrudnienia kolejnych osób,
  • rozpoczęcie projektu wymaga podjęcia szeregu ważnych decyzji dotyczących stosu technologicznego (narzędzi, bibliotek, dodatkowego oprogramowania), z których wycofanie się jest trudne i czasochłonne – osoba z niewielkim doświadczeniem może wybrać po najmniejszej linii oporu nieoptymalny stos używany w poprzednim miejscu pracy lub przeciwnie, zaryzykować coś bardzo eksperymentalnego i niegotowego, co potem nie będzie działać lub będzie trudne do dalszego rozwoju,
  • w przypadku napotkania problemów samotny programista nie ma się kogo poradzić, więc stosuje rozwiązania ze stackoverflow, często na oślep i w sposób nieadekwatny do konkretnego przypadku,
  • oprogramowanie po uruchomieniu powinno mieć naprawiane na bieżąco błędy, być „pielęgnowane” i dalej rozwijane, tak aby użytkownicy mogli z niego na bieżąco korzystać i oczekiwać nowych funkcji wymaganych przez biznes, a często programiści nie lubią tego typu zadań „utrzymaniowych”,
  • programiści lubią znać strategię firmy i projektu przy którym pracują i mieć wizję dalszych prac w kontekście swojego indywidualnego rozwoju – brak planów lub wyzwań ponad „rozwiązywanie bieżących problemów” powoduje że zaczynają szukać takich wyzwań poza projektem, więc jeżeli jest to jedyny projekt IT w firmie, to szukają na zewnątrz,
  • programiści lubią się uczyć i rozwijać, najchętniej od lepszych od siebie – jeżeli w firmie jest ich mało, to trudno jest im kogoś takiego znaleźć na miejscu, nie ma też nikogo kto odbywałby z nimi spotkania okresowe, stawiał cele rozwojowe i pomagał im w ich osiąganiu.

Mając na uwadze powyższe, profesjonalne rozpoczęcie projektu bez istniejących zasobów IT powinno rozpocząć się od stworzenia całego działu IT (!), z dyrektorem, kierownikiem, różnymi specjalistami i menadżerami koordynującymi ich prace, procedurami, polityką HR, itd. A to już jest bardzo dalekie do początkowego pomysłu „zatrudnijmy programistę”…

Oczywiście, można jeszcze rozważyć zatrudnienie bohatera typu „wszystko w jednym”, który nawet będąc kosztownym, właściwie poprowadzi projekt i uruchomi system. W takim wypadku problem najczęściej zaczyna się później, bo taka osoba niechętnie pracuje przy dalszym utrzymaniu systemu albo, widząc że stała się niezastępowalna z punktu widzenia działania systemu, systematycznie zwiększa swoje oczekiwania – najczęściej finansowe – wobec pracodawcy.

Hipotetyczny freelancer pracujący w przestrzeni co-workingowej | CC0 Public Domain | https://pxhere.com/pl/photo/915107
Hipotetyczny freelancer pracujący w przestrzeni co-workingowej | CC0 Public Domain

Skrajnymi przypadkami z którymi się spotkałem gdy firmy próbowały prowadzić samodzielnie projekty nowymi własnymi programistami, były sytuacje gdy wszyscy programiści odeszli, aplikacja częściowo nie działa, nikt nie wiedział jak działa ta sprawna część, jak wprowadzać zmiany, ani nawet zbudować i zainstalować zmienioną wersję (!). Analiza takich przypadków pokazuje, że pierwszymi powodami problemów są najczęściej małe doświadczenie i chybione początkowe decyzje. Później występuje brak dobrej komunikacji zespołu technicznego z interesariuszami biznesowymi i w szczególności brak przyzwolenia (i czasu) na refaktorowanie starego kodu, a w efekcie zniechęcenie i odejście programistów.

Z perspektywy klienta: dlaczego współpraca z software-house ma sens?

Software-house z definicji ma mieć szerokie doświadczenie w tworzeniu oprogramowanie i dysponować „zadbanymi” pracownikami o różnych kompetencjach. W związku z tym szereg problemów opisanych wyżej nie powinien wystąpić lub być niewidoczny dla samego klienta.

Prezentacja dla klienta,  CC0 Public Domain, https://pxhere.com/pl/photo/1452903
Hipotetyczna prezentacja dla klienta (CC0 Public Domain)

Przed przejściem do szczegółów warto jeszcze wspomnieć że współpraca z zleceniodawcy (klienta) z podwykonawcą (software-housem) może być realizowana w jednym z dwóch modeli: opłaty za projekt lub opłaty za wynajęcie zespołu – porównanie tych modeli to dłuższy temat na osobny artykuł…

Zalety współpracy z firmą typu software-house z punktu widzenia klienta nie dysponującego wystarczającymi własnymi kompetencjami IT:

  • pomysł na tworzenie oprogramowania będzie wstępnie zweryfikowany,
  • jeżeli okaże się to możliwe, to zostaną zaproponowane gotowe rozwiązania lub szkielety przyspieszające otrzymanie działającego rozwiązania,
  • jeżeli okaże się to konieczne, to w ramach pierwszego etapu pomysł zostanie poddany analizie, spisaniu konkretnych wymagań, przygotowaniu projektów np. architektury czy interfejsu użytkownika, przedstawiona zostanie propozycja harmonogramu,
  • jeżeli okaże się to potrzebne, to przed rozpoczęciem właściwego projektu możliwe jest przygotowanie działającego prototypu fragmentu aplikacji (tzw. PoC – Proof of Concept) i przedstawienie go do testów docelowym użytkownikom aby potwierdzić wartość wymyślonej funkcjonalności,
  • wybrany będzie najlepszy stos technologiczny dostosowany do specyfikacji dokładnie tego projektu – umożliwiający jego najszybszą realizacje, a potem łatwy dalszy rozwój,
  • do pracy przystąpią zespoły złożone z doświadczonych pracowników, dodatkowo wspierane przez osoby zdobywające doświadczenie – kierowane do realizacji koniecznych ale mniej wymagających zadań,
  • do zespołu mogą dołączać dodatkowi specjaliści do wybranych etapów i w niepełnym wymiarze czasu pracy, zgodnie z bieżącym zapotrzebowaniem – dzięki temu że w pozostałym czasie pracują przy innych projektach w ramach software-house’u, to nie trzeba ich każdorazowo zatrudniać i zwalniać lub opłacać gdy bezproduktywnie czekają,
  • dalsze prace powdrożeniowe są prowadzone w dedykowanych zespołach, a procedury rotacji pracowników pomiędzy projektami zapobiegają „zanudzeniu” przy mniej atrakcyjnych zadaniach,
  • zakończenie lub tymczasowe zatrzymanie prac przy projekcie dla pracujących przy nim programistów nie jest powodem do szukania nowego pracodawcy, wyzwania czekają przy innych projektach w ramach software-house’u,
  • odejście programistów z projektu, np. ze względu na chęć nauki innych technologii, jest przeprowadzane w sposób kontrolowany, poprzedzony wdrożeniem nowej osoby na zastępstwo, a odchodząca osoba może nadal świadczyć doraźne konsultacje dla pozostałych członków zespołu,
  • software-house opracowuje dokumentacje i procedury umożliwiające rozwiązanie kontraktu i przeniesienie wiedzy do innego wykonawcy – w ten sposób klient ma wolność wyboru i utrzymania przewidywalnych kosztów,
  • w modelu gdy klient zleca projekt o określonym zakresie w określonym czasie i kwocie, to podwykonawca ponosi ryzyko realizacji w zadanym terminie, więc formalnie nie może wystąpić sytuacja gdy dzień przed zakończeniem projektu wewnętrzni pracownicy rozkładają ręce i proszą przesunięcie terminu ukończenia prac,
  • brak „społecznego ryzyka” utrzymywania we własnej organizacji grupy pracowników zarabiających średnio więcej niż inni,
  • brak konieczności zarządzania specyficzną grupą pracowników wymagających innego traktowania i możliwość skupienia się na własnym biznesie.

Czy współpraca z zewnętrznym podwykonawcą jest dla klienta rozwiązaniem doskonałym? Niestety – jak wszystko – nie jest wolna od wad. Najważniejsze z nich to:

  • wyższa cena za usługi podwykonawcy niż koszt zatrudnienia własnego pracownika, gdyż musi ona obejmować dodatkowe koszty zarządzania, rekrutacji, biura, sprzętu i narzędzi, udziału w szkoleniach i konferencjach podnoszących kwalifikacje, ryzyko projektu (w modelu z opłaty za projekt), itp.,
  • brak głębokiej wiedzy domenowej i technicznej z branży klienta – pracownicy software-house’u znają się dobrze na programowaniu ale niekoniecznie na specyfice każdego rynku lub rozwiązania, więc rozpoczęcie projektu wymaga szybkiego uzupełnienia tej wiedzy i bliskiej współpracy z ekspertami domenowymi po stronie klienta,
  • brak możliwości tzw. mikro-zarządzania przez pracowników klienta pracami poszczególnych osób przy poszczególnych zadaniach, bo zespół najczęściej pracuje w innej siedzibie i jest zarządzany wewnętrznie – raportowanie postępów odbywa się poprzez oficjalne raporty lub spotkania statusowe.

Z perspektywy pracownika: dlaczego praca dla software-house ma sens?

W tej części artykułu chciałbym odpowiedzieć na pytanie, dlaczego programista lub inny pracownik techniczny powinien zatrudnić się w firmie software-house, a nie bezpośrednio u klienta, np. we wspomnianym wydawnictwie.

Hipotetyczne stanowisko pracy programisty | CC0 Public Domain | https://pxhere.com/pl/photo/563656
Hipotetyczne stanowisko pracy programisty | CC0 Public Domain

Cechy pracy w software-house które wielokrotnie przedstawiałem, np. w czasie spotkań rekrutacyjnych i okresowych:

  • praca w środowisku zapewniającym wysoką kulturę IT, możliwość wymiany wiedzy, inspirujące rozmowy w kuchni, kontakt niemal wyłącznie z osobami zainteresowanymi tworzeniem oprogramowania,
  • możliwość rozwoju i nauki programowania od osób lepszych od siebie (np. przez procedury przeglądu kodu i programowania w parach) oraz dzielenia się własną wiedzą z innymi osobami zainteresowanymi rozwojem,
  • możliwość pracy przy bardzo różnych projektach w różnych branżach (ja np. ostatnio sporo nauczyłem się o branży motoryzacyjnej…),
  • szybkie i komfortowe wejście do nowego projektu i/lub zespołu dzięki zunifikowanym procedurom i dokumentacji (tzw. „Up and running within 2h” i „Commit on the first day” posługując się nazewnictwem nofluffjobs.com),
  • dobrze zorganizowane prowadzenie projektu: podzielone i dobrze określone zadania, ustalone priorytety, separacja od chaotycznych decyzji biznesowych,
  • możliwość zmian projektów (zespołu, technologii i/lub branży) bez konieczności zmiany pracy i kolegów/koleżanek,
  • możliwość korzystania z najlepszego sprzętu, technologii i narzędzi – rolą CTO (ang. Chief Technology Officer) i kierowników technicznych jest śledzenie bieżących trendów i sugerowanie (lub forsowanie…) ich do realizowanych projektów,
  • mimo udziału w różnych projektach dla różnych klientów praca z jednego własnego biura, w dobrych warunkach i ze znajomymi pracownikami – to cecha wyróżniająca w stosunku do firm body-leasingowych, które „rzucają” pracownikami po siedzibach różnych klientów w różnych lokalizacjach,
  • możliwość udziału w szkoleniach wewnętrznych, wewnętrznych hackathonach, korzystanie z biblioteki książek, itp.

Żeby nie było zbyt pięknie, to są też pewne wady pracy w tego typu firmach:

  • mniejsze prawdopodobieństwo pracy w najbardziej zaawansowanych projektach wymagających bardzo głębokiej wiedzy technicznej i biznesowej (np. program budowy rakiet kosmicznych…),
  • mniejsze prawdopodobieństwo pracy w projektach wymagających wysokiej poufności danych, jak systemy bankowe czy główne systemy firm finansowych,
  • procedury zarządzania wiedzą i dążenie do wysokiej efektywności niemal uniemożliwia „okopanie się na ciepłej posadzie”, gdzie niewielkim wysiłkiem można otrzymywać wysokie wynagrodzenie – to trochę sarkazm ale słyszałem o różnych przypadkach…

Podsumowanie

Odpowiadając sobie na tytułowe pytanie, sądzę że tak, software-house’y mają sens. Z punktu widzenia klienta jest to możliwość zamówienia i sprawnego otrzymania działającego oprogramowania wysokiej jakości, bez konieczności budowania i utrzymania całych struktur IT. Z kolei z perspektywy pracowników jest to możliwość pracy w najlepszym środowisku z podobnymi do siebie ludźmi, nad ciekawymi projektami i z możliwościami ciągłego rozwoju.

Mimo że poniższe cechy starałem się przedstawić możliwie obiektywnie i abstrahując od swojego miejsca pracy, to oczywiście zapraszam do współpracy z e-point, zarówno potencjalnych klientów jak i przyszłych pracowników :-).

Sytuacja win-win | CC0 Public Domain | https://pxhere.com/pl/photo/1433619
Sytuacja win-win | CC0 Public Domain

O autorze

Marek Berkan Marek Berkan: programista, entuzjasta tworzenia oprogramowania, zarządzania zespołami technicznymi. Prywatnie motocyklista, kolarz MTB, biegacz, żeglarz, rekreacyjny wspinacz, zamiłowany turysta. Witryny: , , .

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *