Ile tak naprawdę zarabiasz na programiście: prawda o marży w outstaffingu

«Byłem pewien, że zarabiam 40% na każdym developerze. Kiedy pierwszy raz rozbiliśmy to na osoby, wyszło 11%. Różnica? Bench, którego po prostu nigdy nie traktowałem jak kosztu.»

To słowa właściciela 14-osobowego studia outstaffingowego. Ta historia brzmi znajomo dla prawie każdego, kto wynajmuje zespół na godziny: stawka dla klienta minus pensja developera wygląda jak zysk. W rzeczywistości między tymi dwiema liczbami chowa się połowa firmy — i dopóki nie rozbijesz kosztów na osoby, zarządzasz przychodem, a nie marżą.

Dlaczego „stawka minus pensja” kłamie

Weźmy typowego developera mid-level. Klientowi wystawiasz $35 za godzinę, a developer kosztuje cię około $3,000 miesięcznie po podatkach. W głowie właściciela to $35 kontra mniej więcej $20 — marża blisko 43%. Wygląda świetnie i właśnie na tej liczbie wiele osób opiera decyzje: czy zatrudniać kolejnych ludzi, dać rabat albo podnieść pensję.

Problem w tym, że developer nie dowozi 160 płatnych godzin miesięcznie. Między projektami siedzi na benchu. Onboarding nowego klienta zjada tydzień, zanim człowiek wejdzie w cudzy kod i procesy. Do tego spotkania, code review, nauka, chorobowe, urlopy. Realne wykorzystanie — czyli udział godzin, za które klient faktycznie płaci — nawet w zdrowych studiach rzadko przekracza 75%. A każdy niepłatny procent finansujesz z własnej kieszeni.

Rozbijmy to na jedną osobę

Policzmy uczciwie, na tych samych liczbach.

43% na papierze zamieniło się w 12% w prawdziwym życiu. I to wciąż dobry scenariusz. Wystarczy, że wykorzystanie spadnie do 60% przez jeden pusty miesiąc, a ten sam developer zaczyna generować stratę — choć pensję wypłacasz tak samo.

Policzmy cały rok

Miesięczny wynik potrafi mylić, bo bench nie rozkłada się równo. Weźmy tego samego developera mid-level w skali roku. Przez dziesięć miesięcy pracuje na 80%, przez jeden miesiąc na 40% (projekt się skończył, następny jeszcze nie ruszył), a łącznie tydzień schodzi na chorobowe i naukę. W ciągu roku klient zapłacił za około 1,250 godzin zamiast teoretycznych 1,920. Przychód: około $43,750. Pensja z podatkami: $36,000. Koszty ogólne na osobę: $8,400. Roczny zysk z developera: około −$650. Ten sam developer, który „daje 43% marży”, zakończył rok lekko pod kreską — tylko przez jeden pusty miesiąc i kilka niebillowalnych tygodni rozsmarowanych po roku.

«Benchu nie widać na żadnej fakturze, więc nikt go nie zauważa. A zjada więcej niż jakikolwiek rabat dla klienta.»

Trzy koszty, które wszyscy zaniżają

Po pierwsze: bench. Czas między projektami opłacasz ty, nie klient. Jeden pusty tydzień w miesiącu to minus 25% przychodu na osobę przy tej samej pensji. W 14-osobowym studiu nawet średni bench na poziomie 10% działa tak, jakbyś utrzymywał półtorej osoby, które nic nie przynoszą.

Po drugie: niebillowalne godziny w projekcie. Daily, synchronizacje z klientem, review, research, poprawki po zmianie wymagań. Klient płaci za 6 godzin, a zajętych jest 8. Te dwie godziny dziennie też są twoim kosztem — tylko niewidocznym.

Po trzecie: koszty zarządzania. Na każdych pięciu–sześciu developerów potrzebny jest project manager, a rekrutacja albo zastąpienie człowieka kosztuje mniej więcej miesiąc jego pensji, plus miesiące, zanim nowa osoba osiągnie pełną wydajność. Te pieniądze nie są przypięte do jednej konkretnej faktury, więc łatwo je przeoczyć — dopóki nie policzysz zysku na osobę po kosztach ogólnych.

Jak to wygląda w praktyce

Problem słychać w typowych zdaniach w studiu. „Mamy dużo projektów, ale mało zysku”. „Urośliśmy do 20 osób, a właściciel zarabia jak przy 12”. „Klient odpadł — damy radę, wrzucimy tę osobę na projekt wewnętrzny” (czyli na pełny bench na twój koszt). „Dajmy temu klientowi 10% rabatu, jest duży” — podczas gdy marża na tym koncie i tak wynosiła już 12%, a rabat zamienia je w stratę.

To wszystko są objawy jednego: studio liczy różnicę między stawką a pensją i nigdy nie liczy zysku na osobę po benchu i kosztach ogólnych. Przychód jest duży, a właściciel zastanawia się, gdzie znika zysk.

Jak zobaczyć marżę na każdym developerze

Żeby tym zarządzać, musisz widzieć przychody i koszty per osoba albo per projekt, a nie w jednym worku. W Finmap tworzysz projekty i kierunki, księgujesz przychody od klientów oraz bezpośredni koszt osoby, która wykonuje pracę — i widzisz marżę brutto na każdym inżynierze oraz w całym studiu. Bench przestaje być niewidzialny: pusty miesiąc od razu pojawia się w raporcie, a nie pół roku później jako mgliste „jakoś spadł nam zysk”. Widzisz też, który klient daje normalną marżę, a który tylko zajmuje ludzi prawie za darmo.

Powiązane — czym rachunkowość zarządcza różni się od księgowości w IT oraz jak mierzyć wykorzystanie zespołu.

Co z tym zrobić

• Ustal docelowe wykorzystanie i sprawdzaj je co tydzień, nie raz na kwartał. Pusty tydzień złapany na czas można jeszcze domknąć sprzedażą.
• Wlicz bench w cenę: stawka musi pokrywać nie tylko godziny pracy, ale też nieuniknione puste przebiegi. Jeśli docelowe wykorzystanie to 75%, stawkę budujesz od tego poziomu, nie od 100%.
• Mierz zysk na osobę po kosztach ogólnych, a nie samą różnicę brutto między stawką a pensją. Tylko ta pierwsza liczba mówi prawdę.
• Patrz na marżę według klientów: duży klient z rabatem często przynosi mniej niż mały klient na pełnej stawce.
• Planuj zastępstwa i rekrutacje na podstawie obłożenia, a nie „na wszelki wypadek”. Każda osoba „pod wzrost” bez projektu to czysty bench na twój koszt.

Outstaffing wydaje się prostym biznesem, dopóki nie zaczniesz liczyć per osoba. Kiedy to zrobisz, od razu widać, kto naprawdę zarabia, kto siedzi na benchu i którędy marża wycieka przez niebillowalne godziny. A wtedy decyzje o zatrudnieniu, rabatach czy nowym projekcie podejmujesz na liczbach, nie na poczuciu, że „jest dużo ludzi, więc chyba jest dobrze”.

Pieniądze nie znikają. Po prostu ich nie widzisz.

Wypróbuj Finmap za darmo przez 14 dni i zobacz marżę na każdym developerze i projekcie już w tym miesiącu — bez ręcznego sklejania arkuszy.