Jak naprawdę działają projekty IT/developerskie? 10 punktów, które warto znać.

Rynek usług informatycznych/technologicznych to dla większości osób wciąż zamknięta księga i pilnie skrywana tajemnica.

Mimo, że Polska jest znana z wychowywania talentów kontraktowanych przez zarówno USA i Europę Zachodnią i mimo, że wciąż kojarzona jest jako jeden z “liderów” tzw. outsourcingu technologicznego, mam wrażenie, że wciąż mało osób zdaje sobie sprawę jak ten rynek rzeczywiście działa i funkcjonuje.

Z jednej strony taki stan rzeczy jest korzystny dla samych firm zatrudniających i pośredniczących - im mniejsza wiedza kandydata na temat tego co dzieje się za zamkniętymi drzwiami, tym większa swoboda w dyktowaniu warunków zatrudnienia. Z drugiej strony prawdą jest również to, że nie wszyscy muszą rozumieć wszystko co się w tej branży dzieje i jest to wiedza “bardziej specjalistyczna”, dla tych, którzy rzeczywiście tym tematem się interesują.

1. Outsourcing vs. internal development

Aby zrozumieć sedno projektów developerskich, należy rozumieć czym różni się tzw. development wewnętrzny od outsourcingu i kontraktingu - to często również podział, który jest widoczny w rolach i pozycjach na które zatrudniają firmy.

Development wewnętrzny to proces budowy oprogramowania na własny użytek i sprzedaż. Firm które posiadają swój produkt, który okazał się komercyjnym sukcesem i posiadają swój własny zespół developerski jest stosunkowo mało. To tzw. “perełki”, którym udało się nie tylko wytworzyć własną technologię, ale również z powodzeniem uruchomić i zmonetynować ją na rynku.

Aby to się udało firma musi stworzyć jakościowe rozwiązanie technologiczne, sfinansować jego stworzenie/development, a następnie zdobyć wielu klientów gotowych płacić za swoje rozwiązanie mniejsze lub większe kwoty. 

Dlatego również takich firm jak i pozycji w zespołach z takimi produktami jest niezwykle mało - większość osób chce pracować właśnie w tych firmach, które swoje produkty posiadają i dlatego walka o te pozycje jest właśnie największa.

Outsourcing to z kolei proces dostarczania usług klientom, którzy takich usług potrzebują - takie usługi są po prostu fakturowane i rozliczane.

Powodów do korzystania z takich usług przez firmy/klientów może być wiele, ale najczęściej są to:

• Brak wiedzy nt. budowania technologii lub zespołów technologicznych
• Chęć skorzystania z usług przez ograniczony czas - zamiast budowania swojego zespołu długoterminowego
• Przyspieszenie procesu rozpoczęcia projektu

Korzystanie z usług IT to bardzo często wybór podobny do tego podejmowanego odnośnie mieszkania/nieruchomości - wynajem vs. kredyt. Możesz budować i inwestować w technologię, zespół i wiedzę, które w pewnym sensie kiedyś staną się Twoją “własnością”, jeśli jednak potrzebujesz tego jedynie przez krótszy okres, lepszym rozwiązaniem może się okazać “wynajem” takich kompetencji.

Podsumowując jeśli o projekcie myślimy “długoterminowo”, to budowa własnego zespołu technologicznego będzie zawsze opcją bardziej opłacalną - wiedza i zasoby zostają wtedy w firmie i to firma posiada 100 procentową kontrolę kosztów takiego projektu. Jeśli jednak potrzebujemy doraźnego wsparcia, lepszą opcją może się rzeczywiście okazać wynajem zasobów od kogoś innego.

2. Koszta i rozliczenia - opłacalność

Mimo rewolucji w świecie AI, projekty developerskie wciąż kosztują i to sporo. Stawki czołowych specjalistów wcale nie zmalały, a Ci, którzy zaadaptowali się do zmian technologicznych w sztucznej inteligencji stali się na rynku IT jeszcze mocniej cenieni.

Kontraktując jednak usługi IT, warto mieć na uwadze model rozliczeń który jest na rynku powszechnym standardem. Usługi IT na rynku polskim wyceniane są zazwyczaj “projektowo”, czyli w zależności od wykonywanego zakresu projektu - za dostarczone rozwiązanie. Jest to jednak model, który nie jest odpowiedni do specyfiki projektów IT, ponieważ charakteryzują się one zmieniającymi się okolicznościami, wytycznymi lub mniejszymi/większymi opóźnieniami.

Dlatego standard zachodni to rozliczenie na podstawie czasu poświęconego na realizację usługi, na podstawie tzw. Manday (“dniówek”) lub ryczałtowych stawek miesięcznych. Ten model staje się również coraz bardziej popularny w Polsce wraz ze zwiększającą się świadomością polskich przedsiębiorców i klientów i zrozumieniem specyfiki projektów technologicznych.

3. Tzw. “to nas nie dotyczy” - HR i rotacja projektowa

Realizując projekty IT z zewnętrzną firmą (czyli nie rekrutując zespołu wewnętrznego) klienci bardzo często myślą, że daje im to tzw. “Spokój” - nie muszą się martwić o kwestie związane z HR lub o rotację projektową.

Teoretycznie jest to prawda i w przypadku współpracy outsourcingowej ciężar “zatrudnienia” specjalistów leży po stronie dostawcy usług. W praktyce jednak nie jest to do końca prawda - to jak dostawca zarządza HR lub warunki zatrudnienia specjalistów przekładają się finalnie również na specyfikę projektu po stronie klienta, a sytuacje krytyczne, takie jak choroby/zwolnienia dotyczą przecież również finalnego klienta.

W praktyce zatem oczekiwania klienta w tym obszarze często przewyższają realia, “to nas nie dotyczy” nie ma odzwierciedlenia w rzeczywistości, a zarządzanie i HR staje się tak samo istotne w przypadku współpracy z dostawcą jak przy budowaniu własnego zespołu technicznego.

4. Rekrutacja - rozbieżność firm i kandydatów

Jest jeden proces, który bardzo często decyduje o powodzeniu całego przedsięwzięcia - jest nim rekrutacja. Firmy IT jak i klienci tych firm prowadzą swoje własne rekrutacje na stanowiska do swoich zespołów.

Rekrutacja ma zawsze swoje 2 strony - są to tzw. Strona miękka/HR i strona techniczna, oparta na wiedzy merytorycznej.

Najczęstszym błędem podczas procesów rekrutacyjnych jest zbyt duże skupienie na jednej z tych stron i obszarów. Bardzo często firmy technologiczne decydują się zatrudniać kandydatów mocnych technicznie, jednocześnie nie zwracając uwagi na dopasowanie kulturowe i organizacyjne. Po pewnym czasie okazuje się jednak, że dana osoba nie jest dopasowana do firmy i mimo bogatej wiedzy technicznej nie odnajduje się we współpracy z innymi osobami z zespołu.

Firmy, które prowadzą rekrutację najlepiej, potrafią zbalansować oba obszary i potwierdzają umiejętności kandydata zarówno od strony miękkiej jak i technicznej - w takim samym, nie mniejszym lub większym stopniu.

Idealny kandydat lub pracownik nie istnieje, jednak połączenie weryfikacji miękkiej, motywacji, dopasowania do kultury organizacyjnej z wiedzą techniczną to często przepis na finalny sukces rekrutacji i tzw. “Perfect Match”.

5. Jakość w procesie software development

Kluczowym elementem procesu software development jest jego jakość. Elementów quality assurance takich jak testowanie, refinements, metodologia agile jest mnóstwo, jednak to na co warto zwrócić uwagę, to, że tak jak w większości segmentów usług i produktów jakość jest bardzo mocno powiązana z ceną.

Nie da się zatrudnić dobrego i jakościowego specjalisty po niskiej stawce, tak samo jak nie da się kupić dobrego auta za niewielkie pieniądze. Podobnie sprawa ma się w przypadku korzystania z usług firm IT - nie da się płacić niewielkich kwot za usługi i oczekiwać jakościowej usługi.

Jakość jest bardzo często rezultatem ceny płaconej za daną usługę, w szczególności w branży opartej o zasoby ludzkie, a nie o konkretny produkt lub skalowalne oprogramowanie.

6. Project management i business analysis - kluczowe role nietechniczne

Wydawałoby się, że kluczowe role w projektach IT pełnią osoby techniczne, developerzy implementujący określone rozwiązania. Jest to kolejny mit powielany przez kolejne lata przez środowisko, który często jest powielany również przez same firmy IT.

Oczywiście osoby techniczne pełnią role szalenie istotne - bo bez nich rozwiązania nigdy nie zostałyby zaimplementowane, jednak to role konsultantów, architektów i koordynatorów są często tymi, które dbają o całość projektu, jego harmonogram jak również jego pozytywne przyjęcie przez użytkowników.

Bez osób, które wiedzą jak wydać projekt do grupy docelowej, wypromować go, jak koordynować prace związane z rozwojem projektu tech lub jak budżetować projekty, żadna technologia nie miałaby prawdopodobnie prawa długoterminowo istnieć. Podobnie jak projekty nigdy nie powstałyby bez osób stricte technicznych. Takie projekty są praktycznie zawsze wynikiem/dziełem prac całego zespołu zarówno technicznych jak i biznesowych, a nie jedynie developerów.

7. UX i UI, czyli wygląd

Zanim zacznie się development praktycznie zawsze należy zaprojektować to co użytkownik zobaczy na ekranie.

Mimo, że praktycznie każdy przyzna, że wygląd danego rozwiązania robi różnice, w projektach technologicznych planowanie wizualne okazuje się nie być standardem.

Wiele firm lub klientów decyduje się na wyeliminowanie tego etapu/elementu i skupienie się tylko na podstawowych aspektach. To błąd, który potem bardzo ciężko naprawić, a poświęcenie odpowiedniej ilości czasu i zasobów praktycznie zawsze przekłada się na pozytywne wyniki.

8. Skomplikowane umowy - intellectual property

Na rynku IT przyjęło się, że umowy na takie usługi są złożone, skomplikowane i niezrozumiałe dla przeciętnego Kowalskiego. Co do zasady, jest to prawda, lecz dostawcy wychodząc naprzeciw potrzebom rynku, mocno uprościli podejście do klienta i w dzisiejszych czasach, można już liczyć na sensowne i zrozumiałe warunki umowne.

Pewien poziom złożoności jest jednak wciąż obecny - powodem jest głównie chęć zabezpieczenia swojego interesu przez obie strony, zarówno klientów jak i dostawców - takie jak terminy wypowiedzenia, sytuacje krytyczne (niedziałająca infrastruktura), czas odpowiedzi lub SLA (serwisowanie poprojektowe).

Warto jednak zauważyć, że są w umowach punkty szalenie istotne dla powodzenia takich projektów - takim punktem jest m. in. przekazanie praw do własności intelektualnej. Ten aspekt musi być pokryty w odpowiednim stopniu aby zapewnić klientowi otrzymanie praw do zamawianych prac po realizacji projektu, a jego brak często prowadzi do konieczności pisania kolejnych umów lub konfliktów na linii dostawca klient.

9. Komercjalizacja, rozwój i skalowanie to kluczowe elementy sukcesu

Rozpoczynając projekt IT, często nie myśli się o jego komercjalizacji oraz dynamicznym wzroście i rozwoju, czyli tzw. skalowaniu. Jeśli produkt realizujemy jedynie dla wąskiej i ograniczonej grupy użytkowników, nie powinno być to problemem, jednak często jest to błąd prowadzący do ograniczonego wzrostu projektu.

Warto od samego początku pamiętać o możliwościach rozwoju technologii do szerszej grupy użytkowników i jego dynamicznym wzroście. Nazywa się to dostosowanie infrastruktury do jej późniejszego skalowania.

Elementami istotnymi z perspektywy skalowania technologii są m.in. infrastruktura serwerowa, mikroserwisy, relacyjność baz danych lub dostęp API.

Często produkty realizuje się również bez konkretnego planu na jego komercjalizacje i wydanie do grupy potencjalnych klientów. Ten aspekt dotyczy najczęściej początkujących przedsięwzięć, które nie zdają sobie sprawę, że nie da się samemu finansować technologii w nieskończoność. 

Aspekt komercjalizacji technologii to jednak kompletnie osobny temat o którym można by napisać osobny materiał. Warto jednak pamiętać o tym, że na rynku pozostają i finansują się tylko te produkty które mają swoje grono realnie płacących klientów.

10. Krótkoterminowe oczekiwania vs. długoterminowość projektu

Realizując projekty tech, często myślimy o krótkoterminowych korzyściach i o tym co wydarzy się za tydzień, miesiąc, dwa.

Warto jednak mieć na uwadze, że projekty tech ciągną się latami i często realne efekty prac nad technologią mogą być widoczne dopiero po kilku latach, zakładając postęp każdego tygodnia, poprzez odpowiednie planowanie i wykonywanie sprintów.

Projekty technologiczne to jednak zdecydowanie nie miejsca dla projektów krótkich i szybkich, większość projektów rozwija się miesiącami i latami i pracując w tej branży warto mieć odpowiedni poziom cierpliwości.

Podsumowując to jedynie niektóre z elementów istotnych dla projektów technologicznych. O szczegółach takich projektów dowiecie się z innych materiałów oraz z opisów realizowanych przez nas projektów tech.