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

10

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:

Kevin McCormick
źródło
1
Rozważ szkolenie w zakresie komunikowania swoich umiejętności zespołowi.

Odpowiedzi:

5

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ć.

Spencer Rathbun
źródło
Dziękuję za odpowiedź. Już teraz to doświadczenie zdecydowanie ujawnia dwie słabości naszego zespołu: 1) nasza podstawowa baza kodu jest zbyt duża i wymaga większej modularyzacji, oraz 2) gdy robimy więcej modularyzacji, inni programiści muszą przejąć inicjatywę nowych komponentów, zamiast mnie. Większy problem, który niekoniecznie jest częścią mojego pierwotnego pytania, polega na tym, że mam o wiele większą wiedzę na temat kodu niż kierownik (który jest „oficjalnym” chirurgiem), więc nie deleguje skutecznie, jak mógłby imo .
Kevin McCormick
@KevinMcCormick - Wygląda na to, że powinieneś pozwolić swojemu kierownikowi martwić się o te rzeczy. Dostosuj swoje prognozy, aby teraz obejmowały pomoc członkom zespołu w ich zadaniach. Masz na to uzasadnienie.
Ramhound
@Ramhound, zdecydowanie prawda, a ja nawet już rozmawiałem o tym z kierownikiem, a on zgodził się na to w przyszłości. Trochę nierównowagi umiejętności, których nie był świadomy, i zaoferował pomoc. Wie, że projekt w dużej mierze opiera się na mnie, nad którym oboje pracujemy nad rozwiązaniem.
Kevin McCormick,
7

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ć.

Karl Bielefeldt
źródło
Dziękuję za odpowiedź! Mogę zdecydowanie powiedzieć, że „faza 2” to prawdziwy strach, biorąc pod uwagę, że mamy innego pracownika z innego projektu, który jest bardzo widocznym wąskim gardłem i spowodował poważne problemy w przeszłości. Nie jestem pewien, czy nasz projekt ma takie same problemy, więc domyślam się, że dzieje się tutaj trochę szarpnięcia kolana. Niezależnie od tego, traktuję to jako okazję do podzielenia się wiedzą i może ujawnię pewne słabości w dokumentacji, modułowości kodu itp. I tak, jest to niezwykle frustrujące! Przyjemnie jest słyszeć kogoś, kto czuje to samo.
Kevin McCormick
6

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.

Matthew Flynn
źródło
Dzięki za odpowiedź, zdecydowanie zgadzam się, że jedna osoba wykonująca całą pracę wiąże się z dużym ryzykiem i że kierownik jest tego świadomy. W tym przypadku jednak nie wykonuję całej pracy. Inni członkowie zespołu są bardzo produktywni podczas pracy nad innymi zadaniami, takimi jak naprawianie błędów i praca nad podskładnikami - a nie podstawową architekturą systemu. Byłoby to trochę podobne do sugerowania komuś z zespołu Windows Media Player w MS, aby wprowadził zmiany w jądrze systemu Windows.
Kevin McCormick,
@KevinMcCormick - Co zrobić, jeśli Media Player jest dodawany do jądra systemu Windows, ważna wymówka, aby to zrobić. Wygląda na to, że nie chcesz, aby członkowie zespołu zapoznali się z architekturą systemu podstawowego i nie widzę powodu, aby to zrobić, pomogłoby to tylko na dłuższą metę.
Ramhound
@Ramhound, tak, oczywiście, że w takim przypadku to na pewno prawda. Chcę , aby inni wzięli na własność rzeczy, które napisałem, wprowadzili zmiany i zrozumieli je (regularnie prowadzę szkolenia i dokumentację). Po prostu nie sądzę, że podejście „wszyscy pracują nad wszystkim w tym samym stopniu” jest skuteczne w porównaniu z pewnym poziomem przypisania roli, ponieważ wszyscy mamy różne umiejętności i wiedzę.
Kevin McCormick,
3

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.


źródło
Dziękuję za odpowiedź! Chciałbym móc je wszystkie zaakceptować. Ograniczenie czasowe jest w tym przypadku bardzo realne, ale jak powiedzieli inni, nigdy nie jest dobry czas na dokonywanie tego rodzaju inwestycji czasowych. Z przyjemnością dowiemy się, jak rozwiązałeś swoją sytuację.
Kevin McCormick,
3
+1 Niektórzy bossowie mogą być idiotami, ale wiele razy twój szef ma szerszą perspektywę i musisz mu zaufać.
Phil
@Phil - Szczerze mówiąc, w tym przypadku szef może mieć dobrą perspektywę. Niech martwi się o oś czasu, martw się spóźnieniem, mimo wszystko dostarczył szacunek. W najgorszym przypadku zdarza się czas crunchu, a ty sam dokończ wszystko.
Ramhound