Case study: Budowa zespołu IT na potrzeby realizacji projektu
Budowanie zespołu to nie układanka z pojedynczych gwiazd. Badania wielokrotnie pokazały, że średnie zespoły osiągają lepsze wyniki niż grupa indywidualnych talentów. Kluczowe jest dopasowanie kompetencji, odpowiednie zarządzanie odpowiedzialnościami i świadome tworzenie struktury współpracy. Przyjrzyjmy się temu na konkretnym przykładzie.
Na potrzeby tego artykułu skupię się na procesie powołania zespołu developerskiego, który ma zrealizować konkretny projekt: budowę systemu lojalnościowego. Zakładamy, że wszystkie wymagania są już idealnie dopracowane i kompletne, a nasz zespół nie będzie zajmował się ich tworzeniem, lecz realizacją w oparciu o przygotowaną dokumentację. Oczywiście jak to w projekcie zmiany mogą się zdarzać, ale załóżmy że nie wpływa to na zakres i czas realizacji projektu. W tej analizie skoncentruję się na kluczowych aspektach związanych z doborem kompetencji, podziałem ról i odpowiedzialności w zespole oraz identyfikowaniem potencjalnych ryzyk związanych z jego organizacją i dynamiką.
Projekt: Budowa systemu lojalnościowego
Zakres projektu
Chcemy stworzyć system lojalnościowy, który pozwoli użytkownikom gromadzić punkty i wymieniać je na zniżki. W jego skład wchodzą następujące funkcjonalności:
- zbieranie punktów za zakupy,
- saldo punktów,
- historia transakcji (zebrane i wydane punkty),
- termin ważności punktów,
- wymiana punktów na zniżki poprzez kupony,
- generowanie i zarządzanie kuponami (dodawanie, edycja, usuwanie, przeterminowanie),
- interfejs dla użytkownika,
- interfejs administracyjny,
- backend do obsługi logiki biznesowej,
- integracja z systemem ecommerce (zakupy, zwroty).
Tyle tytułem wstępu, mamy zakres i wymagania. Wiemy co trzeba zrobić i jakiego rodzaju funkcjonalności oczekuje od nas klient. Czas zabrać się za powoływanie zespołu.
Budujemy zespół
Specjalizacje i kompetencje
Zanim przystąpimy do pracy, kluczowe jest zbudowanie listy wszystkich niezbędnych kompetencji potrzebnych do zrealizowania celu. To fundament, który pozwoli upewnić się, że nasz zespół dysponuje odpowiednią wiedzą, doświadczeniem oraz zasobami, aby realizować projekt bez przeszkód i opóźnień. Jasne określenie ról i kompetencji na tym etapie to inwestycja w płynność pracy i minimalizację ryzyka.
Ważne! Brak którychkolwiek kompetencji na starcie może prowadzić do opóźnień w realizacji projektu, a w skrajnych przypadkach – do całkowitego braku możliwości jego ukończenia.
Lista niezbędnych ról:
- Product Owner - lider biznesowy.
- Tech Lead - lider techniczny.
- Scrum Master / Project Manager - koordynacja projektu.
- Frontend (np. React, Angular, Vue.js) - wytworzenie interfejsów użytkownika.
- Backend (np. Java, PHP, Node.js, Python) - wytworzenie aplikacji z logiką biznesową.
- UX / UI - projektowanie interfejsów.
- DevOps / Administrator systemowy - zarządzanie infrastrukturą (cloud, hosting).
- Architekt systemowy - projektowanie systemów.
- Analityk systemowo-biznesowy - analiza procesów i doprecyzowywanie wymagań.
- Testerzy QA - dbanie o jakość.
Powyższa lista to tylko najważniejsze role - czasem niektóre z nich łączy jedna osoba, w innym przypadku są rozbite na jeszcze drobniejsze odpowiedzialności - dużo zależy od wielkości firmy i kultury organizacyjnej.
Podział ról i odpowiedzialności
Aby projekt przebiegał sprawnie, konieczne jest przypisanie odpowiedzialności za obszary do konkretnych osób oraz zadbanie o to, aby osoba pełniąca daną rolę wiedziała, jakie są wobec niej oczekiwania. Jeśli ta praca zostanie dobrze wykonana, pomoże to uniknąć nieporozumień i zmniejszy ryzyko, że jakiś obszar projektu pozostanie bez opieki.
Ważne! Jeśli jakaś rola lub obszar pracy nie zostanie przypisany konkretnej osobie, istnieje duże ryzyko, że zostanie zaniedbany. W skrajnym przypadku może to doprowadzić do braku realizacji któregoś z wymagań lub jego wdrożenia w sposób niespójny i niezgodny ze sztuką.
Aby ułatwić sobie pracę, warto przejść przez wszystkie obszary odpowiedzialności. Dla ułatwienia poniżej znajduje się lista pytań – przy każdym pytaniu powinno widnieć nazwisko osoby odpowiedzialnej za dany obszar.
Pytania:
- Kto będzie liderem projektu?
- Kto podejmuje decyzje biznesowe?
- Kto komunikuje się z interesariuszami?
- Kto jest odpowiedzialny za spisywanie i aktualizację dokumentacji?
- Kto podzieli pracę na etapy?
- Kto zaplanuje harmonogram prac?
- Kto określi terminy realizacji w harmonogramie?
- Kto będzie dbał o wyceny i zweryfikuje ich poprawność?
- Kto będzie zmieniał harmonogram i dopasowywał go do realiów pracy?
- Kto spisze i określi ryzyka projektu?
- Kto będzie pilnował budżetu projektu?
- Kto rozpisze zadania i będzie nimi zarządzał podczas projektu?
- Kto zaprojektuje interfejsy użytkownika?
- Kto zaprojektuje rozwiązanie od strony technicznej?
- Kto będzie odpowiedzialny za spójność rozwiązań backendowych?
- Kto będzie odpowiedzialny za technologie frontendowe?
- Kto będzie odpowiedzialny za spięcie backendu i frontendu?
- Kto będzie odpowiedzialny za wydajność aplikacji?
- Kto zweryfikuje, czy wymagania biznesowe zostały prawidłowo zrozumiane i zaimplementowane?
- Kto zadba o standardy bezpieczeństwa?
- Kto przygotuje infrastrukturę serwerową?
- Kto napisze scenariusze testowe?
- Kto będzie testował?
- Kto podejmie ostateczną decyzję o wdrożeniu funkcjonalności na produkcję?
- Kto będzie monitorował aplikacje / funkcjonalność po wdrożeniu na produkcję?
- Kto podsumuje projekt i zadba o celebrację osiągnięc zespołu?
- Kto zarchiwizuje i rozliczy projekt?
Powyższa lista jest poglądowa i może się różnić w zależności od organizacji, metodologii pracy czy charakteru projektu. Jeśli wszystkie odpowiedzialności zostaną przypisane do konkretnych osób i zadbamy o ich zaangażowanie w realizację, może to znacząco zmniejszyć ryzyko niepowodzenia.
Dodatkowe ryzyka
Nawet najlepiej zaplanowany podział ról i odpowiedzialności nie gwarantuje pełnego bezpieczeństwa projektu. Istnieją ryzyka, które pojawiają się niezależnie od zespołu i warto je jak najwcześniej zidentyfikować. Część z nich wynika z czynników zewnętrznych – mogą mieć istotny wpływ na realizację, choć nie zawsze da się je całkowicie wyeliminować.
Podobnie jak przy podziale ról możemy zadać szereg pytań, które są w stanie ułatwić nam identyfikację ryzyk.
Pytania:
- Czy wymagania są zrozumiałe przez wszystkich członków zespołu?
- Jak duże jest ryzyko, że wymagania zmienią się w trakcie realizacji projektu?
- Czy mamy komplet niezbędnych kompetencji w zespole?
- Czy kompetencje zespołu nie są zbyt silny lub zbyt słabe?
- Czy osoby przypisane do ról mają odpowiednie kompetencje?
- Czy osoby mają wystarczająco dużo czasu, aby zaangażować się w projekt?
- Czy w zespole są osoby w konflikcie?
- Czy w zespole są osoby z zaplanowanymi nieobecnościami?
- Czy są w zespole osoby, przy których istnieje ryzyko nieplanowanych nieobecności?
- Czy projekt jest zależny od innych projektów?
- Czy istnieje ryzyko braku synchronizacji z innymi zależnymi obszarami?
- Czy znane są jakiekolwiek techniczne problemy, które mogą wpłynąć na terminową realizację?
- Czy projekt jest zależny od czynników zewnętrznych?
- Czy projekt został wystarczająco dobrze przeanalizowany przed rozpoczęciem?
- Czy projekt musi zostać ukończony w ściśle określonym terminie?
- Czy interesariusze są świadomi ryzyk projektowych?
Powyższa lista pytań obejmuje kluczowe obszary, które mogą wykoleić projekt i poważnie poturbować zespół. Zadbaj o to, aby odpowiedzi były szczere – tylko wtedy będzie można skutecznie zidentyfikować i ograniczyć ryzyka, zanim staną się realnym problemem.
Podsumowanie
Budowanie zespołu IT na potrzeby konkretnego projektu to nie tylko zebranie grupy specjalistów – to przemyślany proces, w którym kluczowe są kompetencje, jasny podział ról i odpowiedzialności oraz świadome zarządzanie ryzykiem.
W case study dotyczącym systemu lojalnościowego przeanalizowaliśmy, jak dobrać właściwych ludzi, na co zwrócić uwagę przy przypisywaniu odpowiedzialności oraz jakie pytania warto zadać, by zidentyfikować potencjalne zagrożenia. Odpowiednie przygotowanie na starcie pozwala uniknąć chaosu i zwiększa szanse na sprawną realizację projektu.
Zespół to nie tylko zbiór utalentowanych jednostek, ale precyzyjny mechanizm, który wymaga starannego przygotowania, aby działał sprawnie. Kluczowe jest wczesne rozpoznanie potencjalnych zagrożeń i ich eliminacja – bo gdy tryby zaczną się zacinać, może być już za późno na naprawę.
Opublikowane 11.03.2025
