Planuje i organizuje pracę zespołu w celu wykonania przydzielonych zadań

Dlaczego tak

W strukturze zespołu projektowego kierownik projektu odpowiada za planowanie, podział pracy, monitorowanie postępu i komunikację z klientem — pozostali członkowie odpowiadają za swoje specjalizacje. Tester rzeczywiście zna całą aplikację, ale jego rolą jest weryfikacja jakości, a nie zarządzanie. Projektant UX bada potrzeby użytkowników, lecz nie przydziela zadań zespołowi.

Dlaczego tak

Kryterium akceptacji opisuje obserwowalny wynik, który da się jednoznacznie sprawdzić testem: albo potwierdzenie się wyświetla i wiadomość dociera, albo nie. Określenia „ładnie”, „nowocześnie” czy „możliwie dobrze” każdy rozumie inaczej, więc nie pozwalają rozstrzygnąć, czy zadanie zostało wykonane. Tempo pracy programisty w ogóle nie opisuje wyniku zadania.

Dlaczego tak

Ciężkie urządzenia przenosi się zespołowo lub sprzętem pomocniczym, aby ograniczyć ryzyko urazów kręgosłupa, a najcięższe elementy montuje się w dolnej części szafy — obniża to środek ciężkości i ryzyko przewrócenia szafy. Montaż wysoko wymaga podnoszenia ciężaru nad poziom barków. Praca przy włączonym zasilaniu zwiększa ryzyko porażenia i zwarcia.

Dlaczego tak

Podstawiając do wzoru: (2 + 4 · 4 + 12) / 6 = (2 + 16 + 12) / 6 = 30 / 6 = 5 dni. Wynik 6 dni to zwykła średnia trzech oszacowań (18 / 3), która przecenia wpływ wartości skrajnych. Wynik 4 to samo oszacowanie najbardziej prawdopodobne — metoda PERT koryguje je o ryzyko, dlatego oczekiwany czas jest dłuższy.

Dlaczego tak

Skuteczna komunikacja w zespole jest konkretna i kierowana do właściwych osób: co blokuje pracę, kto może pomóc i jaki jest termin, a kanał projektu pozostawia ślad widoczny dla kierownika. Czekanie do cotygodniowego spotkania marnuje kilka dni pracy. Ogólna skarga do całej firmy nie wskazuje adresata ani konkretnej potrzeby.

Dlaczego tak

Prawidłowa współpraca przy przeglądzie kodu polega na rzeczowej, konkretnej uwadze skierowanej do autora — w miejscu, gdzie zespół ją widzi — z propozycją rozwiązania; autor poprawia kod i przy okazji się uczy. Przepisanie kodu po cichu odbiera mu tę możliwość i wprowadza zmiany bez jego wiedzy. Zatwierdzenie zmian z błędem przenosi go do produkcji, a angażowanie kierownika w zwykłą uwagę techniczną psuje zaufanie w zespole.