To, że w skład zespołu projektowego IT powinni wchodzić programiści – chyba wie każdy 😉 Wraz z rośnięciem potrzeb, projektu i rozwojem firmy przychodzi jednak moment, kiedy programiści nie powinni samodzielnie panować nad każdym aspektem działania projektu IT/rozwoju produktu. W czasach, gdy każdy jest agile i pracuje w scrumie, osoby nowe w świecie zarządzania zespołami IT zderzają się z wieloma pojęciami określającymi członków zespołu/projektu IT, które na początek mogą wydawać się przytłaczające i niezrozumiałe.

Dziś chciałabym się skupić na rolach w zespole IT – i wyjaśnić, na czym one polegają, w prosty i zrozumiały sposób, oraz kiedy faktycznie jest dobry moment, żeby rozbudować swój zespół projektowy o nowych członków zespołu w nowych rolach.

Najpopularniejsze role w zespole IT – lista z wyjaśnieniem

Skupiam się na rolach, z którymi zapewne spotkasz się najczęściej. Można oczywiście wymienić równiez specjalistów ds. chmury, baz danych, cyberbezpieczeństwa… jednak są to role nie stricte projektowe, i zazwyczaj obecne w dużych zespołach.

1. Project Manager

Project Manager (kierownik lub menedżer projektu) o osoba odpowiedzialna za planowanie, realizację i nadzór nad projektem od początku do końca. Jego głównym zadaniem jest zapewnienie, że prace postępują zgodnie z harmonogramem, budżetem i zakresem, a zespół ma wszystko, czego potrzebuje do osiągnięcia celu i dowiezienia projektu. Osoba ta ściąga z programistów obowiązek organizacji swoich zadań i kontaktu z klientem oraz pilnowania terminów.

2. Product Owner

Product Owner to ktoś, kto wie, czego użytkownicy i klienci oczekują od produktu/projektu. Reprezentuje ich interesy i dba o to, by zespół pracował nad tymi funkcjonalnościami, które są najważniejsze. To osoba, która decyduje, co będzie priorytetem w projekcie. W mniejszych zespołach rola PO i PM będzie się często ze sobą łączyć.

3. Tester (QA)

Tester, czyli QA (Quality Assurance) – jego rola to sprawdzanie, czy produkt działa poprawnie i spełnia wszystkie wymagania. Wykrywa błędy i problemy, zanim produkt trafi do użytkowników, co pomaga uniknąć problemów po wdrożeniu.

4. Analityk Biznesowy (Business Analyst)

Analityk Biznesowy to osoba, która zajmuje się analizą potrzeb biznesowych firmy i przekształcaniem ich w konkretne wymagania dla zespołu/projektu IT. Pomaga w zrozumieniu, jakie funkcje powinien posiadać produkt, by spełniał oczekiwania klientów i biznesu. W mniejszych zespołach rola ta łączy się często z rolą PO/PM.

5. DevOps

DevOps to rola, która łączy kompetencje programistów (Dev) z działem operacyjnym (Ops). DevOps dba o to, by oprogramowanie było łatwo i szybko wdrażane, a także monitorowane po wdrożeniu. Jest odpowiedzialny za automatyzację procesów i utrzymanie stabilności systemów. W mniejszych zespołach rola ta łączy się często z rolą Architekta czy Tech Lead’a.

6. UX/UI Designer

UX/UI Designer to osoba odpowiedzialna za to, jak produkt wygląda i jak się go używa. UX (User Experience) skupia się na tym, by korzystanie z produktu było łatwe i przyjemne, natomiast UI (User Interface) zajmuje się projektowaniem estetycznego i intuicyjnego interfejsu. Dostarcza makiety, które programiści przekładają na kod.

7. Tech Lead

Tech Lead to lider techniczny zespołu. Jego rola polega na kierowaniu zespołem programistów, podejmowaniu decyzji technicznych i dbaniu o wysoką jakość kodu. To osoba, która łączy umiejętności programistyczne z umiejętnościami zarządzania ludźmi. Może on również wspierać zespół PM/PO w kontakcie z klientem od strony technologicznej i dobieraniu odpowiednich rozwiązań.

Kiedy i jak rozbudowywać zespół projektowy IT o nowych członków zespołu? – zdroworozsądkowo

Zatrudnianie od razu wszystkich wyżej wymienionych osób to mało strategiczne rozwiązanie. Dlatego chciałabym zdroworozsądkowo przybliżyć Ci, kiedy faktycznie powinieneś zatrudniać osoby do nowych ról i dlaczego może Ci to dać wymierne korzyści dla projektu.

Kiedy zatrudnić członków zespołu, którzy będą zarządzali projektem (PO/PM/BA)?

Czyli kiedy przyszedł moment, aby do Twojego zespołu dołączył Project Manager, Product Owner czy Analityk – specjalista w obszarze zarządzania projektem, badania oczekiwań i przekładania ich na taski dla programistów,.

Po czym ocenić, że to dobry moment, żeby programiści nie zarządzali samodzielnie projektem od A do Z?

1. Zadania przestały być wykonywane terminowo.

2. Zadania po wykonaniu nie spełniają wymogów biznesowych.

3. Masz problem z obustronnym zrozumieniem po stronie biznesu i zespołu programistów.

4. Programiści zwracają uwagę, że nie mają czasu na wykonywanie zadań.

5. Zadania wracają często do poprawek.

6. Twój projekt „płynie” bez większej organizacji, kolejności i kontroli, czy idziecie w dobrym kierunku.

Niektóre z tych punktów mogłyby się wydawać sugestią, że po prostu potrzebujesz kolejnego programisty do zespołu. Jednak jeżeli powyższa lista wpisuje się w Twoje problemy – to dobry moment, żeby ktoś zdjął z programistów obowiązek analizy biznesowej i organizowania zadań oraz zarządzania projektem.

W pierwszej kolejności powinieneś rozważyć wdrożenie do Twojego zespołu roli Project Managera, który połączy rolę Product Ownera i Analityka. Obłożenie obowiązkami na tym etapie nie jest prawdopodobnie na tyle duże, żeby rozbijać tę rolę na 3 różne, dlatego proponuję do tego zacząć. Kandydaci doświadczeni w zarządzaniu projektami IT mają zazwyczaj bardzo szerokie kompetencje i radzą sobie z zadaniami z tych 3 obszarów.

Jakie korzyści da Ci zatrudnienie osoby, która zarządza projektem?

1. Zadania zespołu będą analizowane z perspektywy nie tylko technologicznej, ale też biznesowej.

2. Programiści będą w stanie skupić się w pełni na zadaniach programistycznych, więc będą wykonywane czasowo.

3. Będziesz miał większą kontrolę nad tym, w jakim kierunku zmierza praca zespołu i czy efekty spełniają Twoje oczekiwania.

4. Większa efektywność = lepsza rentowność pracy zespołu projektowego IT.

5. Wdrożenie konkretnej metodyki działania i „cykliczności” do pracy zespołu.

Zastanawiasz się, czy w Twoim zespole projektowym jest potrzebna osoba, która będzie nim zarządzała? Możemy Ci pomóc przeanalizować Twoją sytuację i dobrać najlepsze rozwiązanie lub wesprzeć Cię w niepełnym wymiarze godzin w organizowaniu pracy zespołu. Skontaktuj się z nami, żeby porozmawiać o Twoich wyzwaniach związanych z IT w firmie.

Kiedy zatrudnić Testera w projekcie?

Po czym ocenić, że to dobry moment, żeby zatrudnić Testera do projektu?

1. Zadania wracają nagminnie do poprawek.

2. Błędy są wykrywane na ostatnich etapach.

3. Programiści zgłaszają, że mają za mało czasu na programowanie.

Tester w zespole to przede wszystkim krok w stronę rozwiązań, które są wdrażane na produkcję bez konieczności poprawek, a błędy są wykrywane na wczesnym etapie i łatwe do naprawy.

Jakie korzyści da Ci zatrudnienie Testera w projekcie?

1. Błędy będą wykrywane na wczesnym etapie.

2. Rozwiązania tworzone przez zespół projektowy będą działały bez błędów.

3. Programiści zyskują czas, którzy poświęcali na „testowanie sobie samemu”.

4. Testy są przeprowadzane przez osobę trzecią = dostrzegane są błędy, które samemu po sobie łatwo pominąć.

Kiedy zatrudnić UX/UI Designera w projekcie?

Po czym ocenić, że to dobry moment, żeby zatrudnić UX/UI Designera do projektu?

1. Masz duże i ciągłe potrzeby pod kątem projektowania stron, aplikacji i interfejsów na potrzeby wewnętrzne lub zewnętrzne.

2. Dla rozwiązań programowanych przez zespół IT ważna jest warstwa wizualna.

3. Docelowi użytkownicy rozwiązań tworzonych przez IT skarżą się na warstwę wizualną.

Podkreślam, że potrzeby pod kątem projektowania wizualnego muszą być duże i ciągłe. Wiele firm do późnego etapu rozwoju decyduje się na współprace z UX/UI Designerami w niepełnym wymiarze godzin, i w wielu wypadkach się to sprawdza. Niemniej, jeżeli przede wszystkim 1. punkt dotyczy Twojej firmy, warto rozważyć zatrudnienie osoby od UX/UI.

Jakie korzyści da Ci zatrudnienie UX/UI Designera do projektu?

1. Rozwiązania tworzone przez zespół IT będą nie tylko dobre na warstwie logicznej, ale też wizualnej.

Kiedy zatrudnić Tech Leada do projektu?

Po czym ocenić, że to dobry moment, żeby zatrudnić Tech Lead’a do projektu?

1. Zadania po wykonaniu nie spełniają wymogów biznesowych.

2. Masz problem z obustronnym zrozumieniem po stronie biznesu i zespołu programistów.

3. Twój projekt „płynie” bez większej organizacji, kolejności i kontroli, czy idziecie w dobrym kierunku.

4. Twoi programiści zgłaszają dużą złożoność projektu i potrzebę konsultacji z kimś bardziej doświadczonym.

5. Brakuje Ci know-how technologicznego, które łączyłoby wiele obszarów.

6. Proces wdrożeń na produkcję dzieje się bez większej organizacji i wiąże się ze stresem.

Korzyści nieco pokrywają się z tymi związanymi z zatrudnieniem PM/PO/BA, jednak w przypadku Tech Lead’a bierzemy pod uwagę głębsze rozumienie technologiczne i wsparcie od tej strony klienta docelowego, jak i zespołu. Specjalista w roli Tech Lead’a nie rozpisuje zadań i nie organizuje pracy zespołu, ale oferuje wielopłaszczyznową wiedzę techniczną, dzięki temu usprawnia procesy wytwarzania oprogramowania, wdrażania na produkcję, doradza w jakim kierunku iść pod kątem programistycznym, żeby rozwiązania były skalowalne czy identyfikuje i zarządza długiem technologicznym.

Rola Tech Lead’a w mniejszych zespołach będzie łączyć rolę Architekta, DevOpsa i Team Leadera, dlatego potrzeba w niej osoby zarówno technicznej, ale też dobrej pod kątem komunikacyjnym i pod kątem umiejętności zarządzania.

Jakie korzyści da Ci zatrudnienie osoby, która zarządza projektem od strony technologicznej?

1. Zadania będą analizowane z perspektywy nie tylko technologicznej, ale też biznesowej.

2. Programiści będą mieli wsparcie w osobie, która ma wielopłaszczyznową wiedzę technologiczną.

3. Dług technologiczny, proces wdrożeń czy skalowalność rozwiązań będą lepiej zarządzane.

4. Wielopłaszczyznowe know-how na temat technologii.

5. Kierunek, w którym idzie IT w Twojej firmie, będzie optymalny i biznesowo, i technologiczne.

Chciałbym rozbudować zespół, ale nie potrzebuję specjalistów full-time – co zrobić?

Wdrożenie wszystkich tych osób do zespołu wymaga dobrze opracowanej strategii, oceny pod kątem biznesowo-technologicznym i, rzecz jasna, kosztów. Jeżeli widzisz wyżej wymienione potrzeby, ale nie jesteś pewien, czy osoba w tej roli będzie miała obłożenie w pełnym wymiarze godzin lub nie chcesz początkowo inwestować w nowe role w zespole full-time, możesz rozważyć współpracę w niepełnym wymiarze godzin.

Możemy pomóc Ci przeanalizować Twoją sytuację i dobrać odpowiednie rozwiązanie. Jeżeli rozważasz rozbudowę zespołu IT i potrzebujesz wsparcia – możesz się z nami skontaktować za pomocą poniższego formularza, a my odezwiemy się do Ciebie, aby umówić spotkanie z osobą, która przeanalizuje Twoją sytuację pod kątem biznesowym i IT.