Jedna osoba czy zespół? Jak dobrać minimalny skład projektu na podstawie kompetencji, zależności i ryzyka

Badania nie wspierają prostej zasady typu „mniejszy zespół zawsze jest lepszy” albo „większy zespół zawsze wykona więcej”.

Meta-analiza opublikowana w 2023 roku, obejmująca 208 niezależnych wyników i 21 435 zespołów, wykazała w ujęciu ogólnym praktycznie zerowy związek między wielkością zespołu a wykonaniem zadania, ale jednocześnie bardzo dużą zmienność zależną od kontekstu. Autorzy wskazują, że znaczenie wielkości zespołu zmienia się między innymi wraz ze złożonością zadania i wymaganiami koordynacyjnymi. [4]

Eksperyment na złożonym zadaniu mapowania kryzysowego również pokazał jednocześnie korzyści i koszty większych zespołów: wraz z wielkością rosła współpraca, ale zmieniało się też zaangażowanie poszczególnych osób. W tym konkretnym eksperymencie największe zespoły osiągnęły lepszy wynik niż równoważna liczba osób pracujących niezależnie. Nie jest to jednak uniwersalny przepis na każdy rodzaj pracy. [5]

Wniosek jest prosty: liczba osób powinna wynikać z charakteru pracy, a nie z jednej magicznej wartości.

Scrum Guide z 2020 roku opisuje zespół Scrum jako mały, przekrojowy i samodzielnie organizujący swoją pracę. Wskazuje również, że taki zespół ma zwykle 10 lub mniej osób. [3]

To ważna wskazówka w kontekście Scrum, ale nie uniwersalne prawo dotyczące wszystkich projektów, usług, branż i modeli współpracy.

Projekt budowlany, kampania marketingowa, audyt bezpieczeństwa, system finansowy i niewielka strona internetowa mają zupełnie inne potrzeby. Nie należy przenosić jednej liczby bezpośrednio między tymi sytuacjami.

Brytyjski Service Standard wymaga, aby zespoły usług cyfrowych były wielodyscyplinarne i miały dostęp do odpowiedniego zakresu umiejętności. Jednocześnie wskazuje, że skład powinien zależeć od tego, co zespół ma osiągnąć na danym etapie. [1]

Osobne wytyczne GOV.UK podkreślają, że wielkość zespołu i potrzebne role zmieniają się w kolejnych fazach budowy usługi. [2]

To prowadzi do praktycznej zasady:

najpierw rozpisz pracę i odpowiedzialność, potem dobierz kompetencje, a dopiero na końcu zamień je na konkretne osoby.

Nie da się dobrać zespołu do niejasnego zakresu.

Zapisz co najmniej:

• jaki rezultat ma powstać,
• co znajduje się w zakresie,
• co jest poza zakresem,
• jakie są najważniejsze wymagania jakościowe,
• jakie ograniczenia czasowe i budżetowe istnieją,
• kto będzie odbierał rezultat,
• czy zespół ma tylko dostarczyć rozwiązanie, czy również je utrzymywać.

Projekt „zbudować aplikację” i projekt „zaprojektować, zbudować, zabezpieczyć, wdrożyć i utrzymywać aplikację przez rok” wymagają zupełnie innego pokrycia pracy.

Zamiast natychmiast wpisywać stanowiska, wypisz rodzaje pracy, które rzeczywiście muszą zostać wykonane.

Dla usługi cyfrowej mogą to być przykładowo:

• poznanie potrzeb użytkowników,
• projektowanie rozwiązania,
• wykonanie warstwy widocznej dla użytkownika,
• wykonanie logiki i integracji po stronie serwera,
• testowanie,
• bezpieczeństwo,
• dostępność,
• wdrożenie i utrzymanie,
• koordynacja zakresu i decyzji.

W innym rodzaju projektu lista będzie zupełnie inna.

GOV.UK wskazuje, że zespół budujący i utrzymujący usługę powinien posiadać szeroki zestaw umiejętności obejmujący między innymi badanie potrzeb, projektowanie, budowę, testowanie, bezpieczeństwo, wdrażanie i utrzymanie. [2]

Nie każda kompetencja musi oznaczać pełnoetatową osobę w zespole.

Dla każdego obszaru określ:

Stała - potrzebna regularnie i bezpośrednio wpływa na codzienne decyzje.
Okresowa - potrzebna w konkretnych etapach lub punktach kontrolnych.
Dostępna z zewnątrz - może być zapewniona przez inną osobę lub zespół, jeżeli czas reakcji i odpowiedzialność są wystarczająco jasno ustalone.

GOV.UK wprost dopuszcza model, w którym specjalistyczna wiedza jest dostępna dla zespołu, nawet jeżeli jej właściciel nie jest stałym członkiem zespołu. [1]

To często pozwala uniknąć sztucznego zwiększania zespołu bez utraty ważnej kompetencji.

Dwie osoby mogą mieć wszystkie potrzebne umiejętności, a mimo to projekt może być źle obsadzony, jeżeli cała praca układa się w jeden wąski łańcuch zależności.

Sprawdź:

• które zadania mogą powstawać równolegle,
• które muszą czekać na inne,
• kto podejmuje decyzje blokujące dalszą pracę,
• od jakich zewnętrznych zespołów lub dostawców zależy projekt,
• gdzie brak jednej osoby zatrzyma kilka obszarów jednocześnie.

GOV.UK wymienia zarządzanie zależnościami od innych zespołów jako jedną z kompetencji wymaganych przy budowie usług cyfrowych. [2]

Jeżeli pracuje więcej niż jeden zespół, pojawia się dodatkowa potrzeba koordynowania planów i postępu między zespołami. [8]

Niektórych kompetencji nie widać na liście funkcji produktu, ale ich brak może być kosztowny.

W zależności od projektu mogą dotyczyć między innymi:

• bezpieczeństwa,
• ochrony danych,
• dostępności,
• wymagań prawnych lub branżowych,
• niezawodności,
• migracji danych,
• integracji z krytycznymi systemami,
• technologii, której zespół wcześniej nie używał.

GOV.UK zaleca dostęp do specjalistycznej wiedzy, gdy projekt jej potrzebuje, a skład zespołu powinien odzwierciedlać również najbardziej ryzykowne założenia konkretnego etapu. [1]

Nie oznacza to automatycznie osobnego stanowiska dla każdego ryzyka. Oznacza natomiast, że ktoś kompetentny musi mieć określoną odpowiedzialność i realną możliwość wpływu na decyzje.

Jedna osoba może znać projektowanie, programowanie, testowanie i wdrażanie. To nie znaczy, że może wykonywać wszystkie te rodzaje pracy jednocześnie w dowolnym terminie.

PMI w materiałach dotyczących planowania zasobów wskazuje na znaczenie dopasowania umiejętności, dostępności, kosztu i doświadczenia do potrzeb projektu. [7]

Dlatego dla każdej osoby sprawdź:

• ile czasu rzeczywiście może poświęcić,
• które zadania konkurują o jej uwagę,
• czy wymagane działania mogą być wykonywane równolegle,
• czy termin zakłada nierealistyczne przełączanie między wieloma rodzajami pracy,
• czy po uruchomieniu rozwiązania nadal ktoś musi je obsługiwać.

Pokrycie kompetencji bez pokrycia czasu nie jest pełnym pokryciem projektu.

Minimalny skład powinien również uwzględniać ciągłość.

Zapytaj:

• co stanie się, gdy kluczowa osoba będzie niedostępna,
• czy tylko jedna osoba rozumie krytyczny element rozwiązania,
• czy decyzje i wiedza są udokumentowane,
• czy ktoś inny potrafi przejąć najważniejsze zadania,
• czy projekt może bezpiecznie zatrzymać się na czas nieobecności.

Nie każdy mały projekt potrzebuje pełnej zastępowalności. W projekcie krótkim i niskiego ryzyka zaakceptowanie takiego ryzyka może być świadomą decyzją.

W projekcie krytycznym ta sama zależność od jednej osoby może być nieakceptowalna.

Projekt nie potrzebuje osobnej osoby dla każdej nazwy roli.

Jeżeli jedna osoba naprawdę posiada wymagane kompetencje, ma wystarczającą przepustowość i nie tworzy niedopuszczalnego ryzyka, może odpowiedzialnie pokrywać kilka obszarów.

Przykładowo w niewielkim projekcie jedna osoba może łączyć projektowanie interfejsu z jego wykonaniem. W innym projekcie jedna osoba może łączyć analizę biznesową z prowadzeniem zakresu.

Nie należy jednak łączyć ról tylko dlatego, że „ktoś musi to zrobić”. Połączenie ma sens dopiero wtedy, gdy ta osoba potrafi wykonać obie odpowiedzialności na wymaganym poziomie i ma na nie czas.

Jedna osoba może być racjonalnym składem, gdy jednocześnie:

• zakres jest niewielki i dobrze zdefiniowany,
• potrzebne kompetencje rzeczywiście mieszczą się w jej możliwościach,
• zadania nie wymagają dużej równoległości,
• zależności zewnętrzne są ograniczone,
• ryzyko jest akceptowalne,
• termin odpowiada rzeczywistej przepustowości,
• brak zastępstwa jest świadomie zaakceptowany.

Przykładem może być mały materiał informacyjny, prosta analiza, jednorazowa konsultacja albo niewielkie wdrożenie w znanym środowisku.

To nadal zależy od konkretnego zakresu. Sama etykieta „mały projekt” niczego nie rozstrzyga.

Zespół staje się bardziej uzasadniony, gdy pojawia się kilka z tych warunków:

• potrzebne kompetencje są zbyt szerokie dla jednej osoby,
• wiele prac musi odbywać się równolegle,
• termin jest krótszy niż realna sekwencyjna realizacja,
• projekt ma wiele zależności i interfejsów,
• ryzyko wymaga niezależnej wiedzy specjalistycznej,
• rozwiązanie trzeba jednocześnie budować i utrzymywać,
• jedna osoba stałaby się krytycznym punktem całego projektu,
• odpowiedzialność obejmuje kilka odmiennych dziedzin.

W takich warunkach dokładanie kompetencji jest ważniejsze niż dokładanie samych osób.

Dodanie osób zwiększa dostępny kapitał wiedzy i potencjalną przepustowość, ale może również zwiększyć liczbę zależności, przekazań pracy i potrzebę uzgadniania decyzji.

Badanie projektów programistycznych opublikowane w Journal of Systems and Software wykazało, że zależności między wielkością zespołu, produktywnością, wysiłkiem i czasem są złożone i nie zawsze potwierdzają intuicyjne oczekiwania. [6]

Meta-analiza dotycząca wielkości zespołów również pokazuje, że wynik zależy od kontekstu zadania i kosztów procesu zespołowego. [4]

Dlatego pytanie nie brzmi „ile osób możemy dodać?”, tylko „czy kolejna osoba usuwa realne ograniczenie projektu bardziej, niż zwiększa koszt koordynacji?”

Nie każda ważna kompetencja musi być obecna codziennie.

Stała obecność ma większy sens, gdy dana osoba regularnie podejmuje decyzje, jej praca ma wiele zależności z innymi obszarami albo potrzebna jest szybka reakcja.

Wsparcie okresowe może wystarczyć, gdy kompetencja jest potrzebna w konkretnych punktach, na przykład do przeglądu, konsultacji, oceny ryzyka lub specjalistycznego odbioru.

Warunek jest jeden: dostępność nie może być pozorna. Musi być wiadomo:

• kto odpowiada,
• kiedy jest dostępny,
• jaki ma czas reakcji,
• jakie decyzje może podejmować,
• co dzieje się, gdy wykryje problem.

Dostęp do specjalisty bez ustalonej odpowiedzialności może wyglądać dobrze na schemacie, ale nie musi działać w rzeczywistym projekcie.

Załóżmy, że celem jest uruchomienie internetowego systemu rezerwacji.

Wariant A: prosty prototyp do sprawdzenia pomysłu
Zakres jest ograniczony, nie ma płatności ani danych szczególnie wrażliwych, a celem jest sprawdzenie procesu z małą grupą użytkowników. Jedna wszechstronna osoba może potencjalnie pokryć projektowanie i wykonanie, z okresową konsultacją w razie potrzeby.

Wariant B: publiczna usługa z kontami, płatnościami i integracjami
Pojawia się więcej specjalizacji, testów, ryzyka, zależności i prac możliwych do prowadzenia równolegle. Zespół kilku osób staje się znacznie bardziej uzasadniony.

Wariant C: usługa działająca stale i wymagająca szybkiej obsługi problemów
Do budowy dochodzi utrzymanie, obserwowanie działania, reagowanie na awarie i ciągłość wiedzy. Skład potrzebny do uruchomienia może nie być wystarczającym składem do trwałej eksploatacji.

To ten sam ogólny rodzaj produktu, ale inny zakres, ryzyko i model działania tworzą inne potrzeby zespołowe.

1. Zaczynasz od gotowej listy stanowisk zamiast od pracy do wykonania.

2. Zakładasz, że każda rola wymaga osobnej osoby.

3. Patrzysz wyłącznie na kompetencje i ignorujesz dostępny czas.

4. Dodajesz osoby, ale nie usuwasz zależności i wąskich gardeł.

5. Pomijasz kompetencje wynikające z ryzyka, bo nie tworzą widocznej funkcji produktu.

6. Uzależniasz kilka krytycznych obszarów od jednej osoby bez świadomej decyzji o ryzyku.

7. Traktujesz skład z początku projektu jako niezmienny aż do końca.

GOV.UK wprost wskazuje, że wielkość i role zespołu zmieniają się w kolejnych fazach rozwoju usługi. [2]

To rozsądna zasada również poza usługami publicznymi:

• na początku możesz potrzebować więcej badań i doprecyzowania problemu,
• podczas wykonania rośnie udział kompetencji wykonawczych i testowych,
• przed uruchomieniem mogą wzrosnąć potrzeby związane z bezpieczeństwem, jakością i przygotowaniem operacyjnym,
• po uruchomieniu zmienia się proporcja między rozwojem a utrzymaniem.

Minimalny skład jest właściwością etapu i zakresu, nie stałą liczbą przypisaną do projektu raz na zawsze.

Dla każdego ważnego obszaru zapisz pięć rzeczy:

Obszar pracy - co musi zostać wykonane?
Kompetencja - jaka wiedza i umiejętność są potrzebne?
Odpowiedzialność - kto podejmuje decyzję i odpowiada za rezultat?
Dostępność - czy kompetencja jest stała, okresowa czy zewnętrzna?
Ryzyko braku - co stanie się, jeśli tej kompetencji zabraknie albo osoba będzie niedostępna?

Następnie dopiero przypisz konkretne osoby.

Jeżeli jedna osoba pokrywa kilka wierszy, sprawdź jej czas i zależności. Jeżeli jeden wiersz wymaga kilku osób, sprawdź, czy powodem jest przepustowość, niezależna kontrola czy równoległość pracy.

1. Czy wszystkie obowiązkowe obszary pracy mają właściciela?
2. Czy każda krytyczna odpowiedzialność ma osobę z odpowiednią kompetencją?
3. Czy ktoś pełni kilka ról i ma na nie realnie wystarczająco czasu?
4. Czy projekt zakłada prace równoległe, których obecny skład nie jest w stanie prowadzić?
5. Czy znamy najważniejsze zależności z innymi osobami, zespołami i dostawcami?
6. Czy istotne ryzyka mają dostęp do właściwej wiedzy specjalistycznej?
7. Czy jedna nieobecność może zatrzymać cały projekt?
8. Czy skład wystarczy nie tylko do wykonania, ale też do uruchomienia i utrzymania, jeżeli jest to częścią zakresu?
9. Czy wiadomo, które kompetencje mogą być dostępne okresowo zamiast stale?
10. Czy mamy momenty, w których ponownie ocenimy skład po zmianie zakresu lub etapu?

Dobieranie zespołu nie powinno zaczynać się od pytania:

„ile osób zwykle potrzeba do takiego projektu?”

Lepsza kolejność to:

rezultat -> praca -> kompetencje -> zależności -> ryzyko -> przepustowość -> osoby.

Jeżeli po przejściu tej sekwencji jedna osoba rzeczywiście pokrywa całość, jedna osoba może być właściwym wyborem.

Jeżeli brakuje kompetencji, czasu, niezależnej kontroli, ciągłości albo możliwości prowadzenia pracy równolegle, potrzebujesz kolejnych osób lub pewnego dostępu do specjalistów.

Celem nie jest najmniejszy zespół. Celem jest najmniejszy skład, który realistycznie potrafi dostarczyć wymagany rezultat na wymaganym poziomie ryzyka i jakości.

[1] GOV.UK Service Standard - Have a multidisciplinary team
Przejdź do źródła

[2] GOV.UK Service Manual - Set up a service team at each phase
Przejdź do źródła

[3] The Scrum Guide, 2020 - Scrum Team
Przejdź do źródła

[4] Bernerth, Beus, Helmuth, Boyd - The more the merrier or too many cooks spoil the pot? A meta-analytic examination of team size and team effectiveness, Journal of Organizational Behavior, 2023
Przejdź do źródła

[5] Mao, Mason, Suri, Watts - An Experimental Study of Team Size and Performance on a Complex Task, PLOS ONE, 2016
Przejdź do źródła

[6] Rodríguez, Sicilia, García, Harrison - Empirical findings on team size and productivity in software development, Journal of Systems and Software, 2012
Przejdź do źródła

[7] Project Management Institute - Solving The Resource Puzzle
Przejdź do źródła

[8] GOV.UK Service Manual - Running more than one service team
Przejdź do źródła

Nota metodologiczna: część źródeł dotyczy usług cyfrowych, część zespołów Scrum, część zarządzania projektami, a część badań nad zespołami i tworzeniem oprogramowania. W artykule wykorzystujemy je wyłącznie w zakresie, który wspierają. Siedmiokrokowy sposób doboru minimalnego składu jest redakcyjną syntezą tych zasad, a nie formalnym standardem żadnej z wymienionych organizacji.