Czy „Zespół chirurgiczny” Freda Brooksa skutecznie radzi sobie z czynnikiem autobusowym?

Mój zespół 4 doświadczonych programistów pracuje nad dużą, modułową aplikacją Windows (około 200 KLoC). Skoncentrowałem się na podstawowej bazie kodu od początku projektu (3 lata temu) i stopniowo przeszedłem na pół-wiodącą pozycję programistyczną, chociaż nie jestem kierownikiem zespołu.

Nasza obecna iteracja to odświeżanie interfejsu użytkownika o wysokim priorytecie, wymagane przez kierownictwo wyższego szczebla, obejmujące około 15 zmian w podstawowej bazie kodu. Pytany przez zarządcę, to szacuje się, że każdy z 15 zmian zajmie mniej niż cztery godziny dla mnie, aby zakończyć , łącznie mniej niż 7 dni roboczych. Następnie zgłosiłem się na ochotnika do wykonania pracy. Zamiast tego menedżer postanowił równomiernie podzielić wszystkie 15 zadań na wszystkich czterech programistów.

W ciągu trzech dni od rozpoczęcia pracy zaobserwowałem dwie rzeczy:

1. Pozostali niedoświadczeni członkowie zespołu wykonali około 1 lub mniej każdego zadania.

2. Prawo Brook'a w akcji: spędziłem około połowy czasu, udzielając pomocy (próbując wyszkolić ich w zakresie używania komponentów). W rezultacie sam ukończyłem tylko 2 zadania, zamiast oczekiwanych 5 lub 6.

Zwróciłem się do mojego przełożonego z obawą, że się spóźniliśmy i ponownie zasugerowałem, że wykonam pozostałe zadania. Moja prośba została uprzejmie odrzucona, a podane powody równego podziału obciążenia były dwojakie:

1. Ogranicz czynnik ciężarówki / autobusu - teraz zwiększaj umiejętności innych programistów, aby w przyszłości każda praca mogła zostać powierzona każdemu, nie tylko mnie.
2. Aby wyeliminować „wąskie gardło” (mnie) i szybciej wykonać pracę.

Dla jasności nie mam problemów z: a) inwestowaniem czasu na naukę, b) ludźmi dotykającymi mojego kodu, lub c) bezpieczeństwem pracy. W rzeczywistości regularnie sugeruję liderowi zespołu, aby szkolił innych programistów w zakresie niektórych aspektów podstawowej bazy kodu, aby zmniejszyć ryzyko.

W tej iteracji mamy również duży zbiór naprawionych błędów o wysokim priorytecie, więc wydaje się, że można by poczynić większy postęp, gdyby obciążenie zostało rozdzielone.

W Mythical-Man-Month Brooks sugeruje „ zespół chirurgiczny ”, w którym każdy zespół składa się z lead + sub-lead (menadżer i ja) oraz kilka drobnych ról. Wydaje mi się, że naturalnie należymy do tej organizacji, ale mój menedżer działa przeciwko temu. Wydaje mi się, że czynnik magistrali został już zajęty (menedżer jest dobrze zaznajomiony z podstawowym kodem) i że wąskie gardło tak naprawdę nie istnieje (angażowanie większej liczby programistów nie przyspieszy pracy). Myślę, że pod tym względem zespół chirurgiczny jest dobrą rzeczą.

Takie są moje odczucia, ale nie jestem doświadczonym menedżerem ani nie mieliśmy do czynienia z czynnikiem autobusowym (pukanie do drewna). Czy Brooks miał rację? Czy pracowałeś w „zespole chirurgicznym”, w którym pojawił się czynnik autobusowy? Czy istnieją lepsze techniki zarządzania dystrybucją wiedzy specjalistycznej?

Podobne pytania:

• Jak zwiększyć współczynnik autobusu i jednocześnie specjalizować się?
• /software/103718/always-keeping-2-people-expert-on-any-one-chunk-of-code

W rzeczywistości argumentowałbym, że postępujesz zgodnie z modelem „zespołu chirurgicznego”. Szczęściarz!

Częścią tego modelu jest to, że niżsi członkowie zespołu pełnią rolę asystenta. Gdy zespół nie wykonuje operacji serca, można poruszać się wolniej i dać im szansę na ćwiczenie niektórych umiejętności lub przeszkolenie w zakresie odpowiedzialności.

Zadaniem chirurga jest zbadanie zespołu i zarządzanie nim poprzez wyszukiwanie słabych punktów i rozwiązywanie ich, a także bycie najlepszym programistą. Nie możesz tego zrobić bez chirurga (menedżera biznesowego), ponieważ nie rozumieją wymaganych umiejętności, jak praktykant mistrzowski.

Tak więc menedżer wykorzystuje tę okazję do pracy nad jednym z innych swoich celów. Jeśli w trakcie jego trwania w zespole ujawni się jakaś wada, może sobie z tym poradzić, zanim stanie się problemem. Powiedzmy, zatrudniając innego programistę.

Lub juniorzy mogą popełnić błąd. Jest to idealny moment, aby to zrobić, ponieważ ktoś patrzy przez ramię. Powiedział Oscar Wilde

Doświadczenie to po prostu nazwa, którą nazywamy naszymi błędami.

Jeśli te juniorzy nie mają okazję do popełniania błędów, wtedy nigdy nie poprawi. Nie tylko obrabuje Twój zespół doświadczonych przyszłych programistów, ale w pewnym sensie odbiera im szansę, którą powinni mieć.

Nasza firma działała tak, jak sugerujesz. Mieliśmy tylko dwie osoby, które rozumiały krytyczną część kodu. Ilekroć w tej części kodu pojawiało się zadanie, zamiast spędzać kilka tygodni na przyspieszaniu pracy innej osoby, zadanie to było przydzielane do nich, ponieważ mogliby je wykonać w ciągu kilku dni. Przez jakiś czas to działało całkiem dobrze.

Ostatecznie ich płyta stała się tak pełna, że ​​nawet jeśli uda im się ukończyć zadanie za 2 dni, przejście na szczyt listy zajęłoby tygodnie. Menedżerowie toczą zaciekłe bitwy słowne, nad którymi zadanie jest pilniejsze. Pilne zadania zależne byłyby niewykonane.

W końcu menedżerowie mieli dość czekania i zaczęli szkolić swoje własne zespoły. Tak, przez pewien czas było znacznie wolniej, ale teraz nasza przepustowość jest znacznie lepsza.

Możesz być teraz w pierwszej fazie, w której możesz poradzić sobie z pracą, ale nie możesz przewidzieć, kiedy przejdziesz do drugiej fazy. Oto wskazówka: zawsze dzieje się to w najbardziej niewygodnym możliwym czasie. Twój menadżer ma rację, by przyjąć cios, kiedy nadal masz trochę oddechu.

Tak, frustrujące jest obserwowanie, jak ktoś zmaga się z czymś, co możesz zrobić znacznie szybciej i łatwiej samemu. Spróbuj kiedyś wychować dwulatka. Robisz to, ponieważ pomaga to ulepszać cały zespół. Zadaniem Twojego menedżera jest martwienie się o harmonogram. Jeśli martwisz się o nierozwiązane błędy o wysokim priorytecie, rzuć sobie wyzwanie, aby zobaczyć, jak szybko możesz je naprawić.

Być może nie jesteś teraz wąskim gardłem, ale ostatecznie staniesz się, jeśli będziesz kontynuował całą pracę sam. Twój menedżer zdaje sobie sprawę, że na tyle ważne jest, abyś nauczył się delegować, aby ryzykować spóźnienie projektu - zaufaj mu. Gdy nauczysz się puszczać, juniorzy zaczną się uczyć i produkować znacznie więcej pod twoim przewodnictwem.

Stosujesz ograniczenie, które może nie być obecne lub mieć tak znaczący stopień, jak myślisz, że jest. W szczególności martwisz się czasem do zakończenia. Z drugiej strony, twój menedżer nie wydaje się zaniepokojony postrzeganymi ograniczeniami czasowymi.

Jeśli wyeliminujesz czas dostawy z pytania, szybko zaczniesz się zastanawiać, dlaczego zadajesz pytanie w pierwszej kolejności.

Nie oznacza to, że czas jest zawsze dostępny i stwierdziliście, że jest to żądanie o wysokim priorytecie od kierownictwa wyższego szczebla. Ale nie jesteś wtajemniczony we wszystkich rozmowach z szefem. Być może negocjował przez dłuższy czas, abyś spędził ten czas na szkoleniu innych członków zespołu.

I choć uważasz, że czynnik autobusu został już rozwiązany, twój szef może oczekiwać kolejnej prośby, która nie będzie łatwo pasować do 7 dni pracy jednego z jego gwiazdorskich twórców. O wiele bezpieczniej jest trenować zespół na mniejszej iteracji, gdzie obiektywna wielkość ryzyka jest znacznie mniejsza.

Byłem wcześniej krytycznym wąskim gardłem; i szczerze mówiąc, nie jest to przyjemne miejsce. W moim przypadku rozmawiałem z wiceprezesem ds. IT i opracowaliśmy plan trwałego rozwiązania problemu. Bolało, ale bolało o wiele mniej niż gdybym został przewieziony ciężarówką.

Łatwo jest wejść w sposób myślenia o wszystkim, co musi zostać wyeliminowane tak szybko, jak to możliwe. Dobry menedżer dostrzega rzadkie okazje, w których niewielkie opóźnienie (w przypadku szkolenia przekrojowego / edukacji) może później przynieść znaczne dywidendy.