Mityczny Mityczny Człowiek-Miesiąc

Jako lider produktu w firmie technologicznej jestem bezdenną potrzebą. Moim zadaniem jako Chief Product Officer w Mailchimp jest wprowadzenie na rynek produktu, który wygra w bardzo konkurencyjnej przestrzeni. Aspiracje Mailchimp są wysokie i aby je zrealizować, musimy dostarczyć na rynek znaczną ilość produktu. Często dla wielu w firmie wydaje się, że robimy za dużo. Zawsze jesteśmy na skraju odpadania kół.

A kiedy robisz za dużo i zdecydujesz się zrobić więcej niż to, nieuchronnie zaczniesz słyszeć wzmiankę o Mitycznym Człowieku Miesiące . To jak jedna z tych kulek łagodzących stres, gdzie po ściśnięciu jednego końca wyskakuje Mityczny Miesiąc Człowieka na drugim końcu.

Wydana przez Fredericka Brooksa w 1975 roku (pamiętasz rok 1975, prawda? Kiedy tworzenie oprogramowania w 100% przypominało tworzenie oprogramowania w 2020 roku?), ta książka jest dość popularna wśród inżynierów oprogramowania. Konkretnie, w całej książce jest jeden punkt, który jest sławny (nie jestem przekonany, że ludzie czytają cokolwiek poza tym punktem, jeśli w ogóle czytali książkę):

„...dodanie większej liczby mężczyzn wydłuża, a nie skraca harmonogram.”

Łatwa naprawa. Od teraz będę tylko zatrudniał kobiety do projektów (patrz Powrót Króla i walka z Witch King of Angmar).

Załóżmy jednak, że punktacja Brooksa jest aktualna niezależnie od identyfikacji płci inżynierów oprogramowania, o których mowa. Oto punkt: oprogramowanie jest trudne do zbudowania z wieloma złożonymi współzależnościami. I wszyscy muszą ze sobą współpracować, aby to zrobić.

Kiedy dodaję ludzi do zespołu, trzeba ich wprowadzić i wszczepić w projekt. Ktoś musi wykroić dla nich odpowiednią pracę. Zespół musi się komunikować, aby upewnić się, że wszystko działa razem, a każda dodatkowa osoba zwiększa geometrycznie złożoność komunikacji. W pewnym momencie dodawanie ludzi staje się obciążeniem dla projektu, a nie korzyścią.

Oto wykres z książki ilustrujący ten punkt:

To jest absolutnie słuszne. Dlatego tak często słyszę to w pracy. Wyczerpani indywidualni współpracownicy i wyczerpani liderzy wyrzucą to z siebie — nie możemy jechać szybciej, nie możemy zrobić więcej, przestań zatrudniać, przeczytaj Mityczny człowiek-miesiąc i rozpacz! Jedynym rozwiązaniem jest najwyraźniej zatrzymanie rozwoju i zabicie niektórych projektów.

Kiedy jako CPO mówię: „zrobimy to!” często odpowiedź brzmi: „OK, więc co zamierzamy zabić?” Mityczny człowiek-miesiąc zamienia rozwój produktu w grę o sumie zerowej. Jeśli chcemy jednej rzeczy, musimy powstrzymać inną. To jest prawdziwy mit, a ja nazywam bzdury.

I dochodząc do patologicznie błędnie zinterpretowanego (dojdziemy do tego) wniosku, książka najwyraźniej mówi, że najszybsza firma technologiczna to taka, która zatrudnia wszystkie cztery osoby — najwyraźniej czterech mężczyzn . Coś więcej tylko spowalnia to wszystko. Ktoś powinien wysłać kopie książki do Amazon, Apple i Google, aby mogli naprawić swoje ewidentnie rozdęte organizacje.

Jedyny problem związany z tym podejściem polega na tym, że w przestrzeni, w której konkurencja rośnie, iteruje i realizuje — jedynie hamując rozwój organizacji — edytowanie i koncentracja nakładu pracy na dopasowanie może być receptą na wymarcie. Będziesz bardziej zdrowy na umyśle i mniej zestresowany — aż do utraty pracy.

A jako właścicielka zarządzania produktem w mojej firmie, nie przepadam za potrzebą spowolnienia i skupienia. Musimy bezwzględnie ustalać priorytety! Bez wątpienia. Ale prowadzenie produktu to ćwiczenie w sprzeczności. Muszę nadać priorytet temu, co mam, jednocześnie planując, aby zrobić więcej. Ale co mam zrobić w obliczu Mitycznego Miesiąca Człowieka ?

Co zaskakujące, odpowiedź na to pytanie pochodzi z tej samej książki Brooksa. Oto kolejny wykres w tym samym rozdziale:

Toczy się walka o skalowanie rozwoju produktów. Jeśli praca, którą próbujesz wykonać, można czysto partycjonować, dodaj ludzi! Jeśli twoja praca jest połączona, to w pewnym momencie dodawanie ludzi jest po prostu złe.

Jeśli ktoś mówi, że absolutnie muszę zabić projekt, aby rozpocząć kolejny, to po prostu tak nie jest. Jeśli te dwa projekty wymagają bardzo niewielkiej komunikacji i koordynacji, możemy odejść.

Właśnie dlatego dodanie rdzeni do procesora może do pewnego stopnia zwiększyć doświadczoną prędkość komputera lub telefonu — coś, o czym inżynierowie powinni wiedzieć wszystko. Jasne, dodanie rdzeni nie pomoże mi w wykonaniu złożonych obliczeń jednowątkowych. Ale może mi to pomóc w wykonaniu kilku niezależnych zadań.

Konflikt menedżera produktu między skalowaniem a bezwzględnym ustalaniem priorytetów może być zarządzany.

1. Bezwzględnie ustalasz priorytety w miejscach, które są jednowątkowe (powiedzmy zaległości dla zespołu produktowego).
2. Skalujesz, dodając więcej rdzeni do samodzielnej pracy.

Bardzo rzadko jednak w firmie jest coś w pełni niezależnego od wszystkiego. Jako absolutne minimum Twoja firma zamierza scentralizować funkcje wspierające (globalne IT, prawne, HR itp.), co prowadzi do wąskich gardeł.

Wszystko sprowadza się do zarządzania zależnościami

Zadaniem kierownika ds. produktu staje się wtedy nie tylko tworzenie strategii, ale także wykonywanie w sposób, który maksymalizuje wartość dla klienta i firmy, zapewniając przepustowość i maksymalnie zmniejszając ryzyko współzależności. „Jak najwięcej” jest tutaj kluczowe. W ten sposób możesz sprawić, że firma będzie wyglądać tak samo jak drugi wykres, a nie pierwszy. Współzależność jest chorobą nieuleczalną , ale jej objawy można leczyć wieloma sposobami leczenia.

Jednym z rozwiązań jest ustalenie strategicznego kierunku dla firmy, który minimalizuje lub ogranicza zależność poprzez starannie dobrany portfel inicjatyw. Zabawne jest to, że wielu ludzi to odrzuci. Załóżmy, że mam dwie opcje, jedną, w której mogę wykonać projekty A, B i C, które mają bardzo małą koordynację (powiedzmy, że wpływają na różne produkty), a drugą opcję z projektami D1, D2 i D3, które mają mnóstwo współzależności ( powiedzmy, że wszystkie mają wpływ na ten sam produkt). Często jest tak, że Mityczny Miesiąc Człowieka zostanie przywołany przeciwko pierwszemu planowi, a nie drugiemu. Bo na papierze wygląda to na więcej .

Rzeczywiście, jest mniej „skoncentrowany”. Ale w rzeczywistości jest to mniej trudne z perspektywy zależności, a zatem lepsze wyniki z dodatkowym personelem.

Pamiętaj, że nie mówię, aby wybrać dla firmy grupę prac, które nie są powiązane. Mailchimp w najbliższym czasie nie zbuduje kuchenki mikrofalowej. Wszystkie prace powinny zmierzać w tym samym długofalowym kierunku. Takie podejście może zwiększyć ryzyko doświadczenia klienta (które omówimy później), a także obciążenie funkcji globalnych, takich jak badania klientów. Miej na to oko.

Innym zabiegiem jest stworzenie procesu zarządzania produktem i programem, który w razie potrzeby ułatwia koordynację zależności i komunikację bez nadmiernego obciążania zespołów koordynacją, jeśli nie jest to wymagane . Czasami próbując zarządzać koordynacją, abyśmy mogli zrobić więcej , w końcu tworzymy tak uciążliwe procesy, że robimy mniej. Jest to równowaga między robieniem zbyt małej koordynacji, co powoduje, że kawałki nie współdziałają ze sobą, a robieniem zbyt dużej koordynacji, która powoduje, że kawałki nigdy nie zostaną zbudowane, ponieważ wszyscy jesteśmy w stójce przez wieczność.

Twierdzenie w Mitycznym Miesiącu Człowieka polega na tym, że gdy dodajesz ludzi do projektu oprogramowania, komunikacja musi wzrastać geometrycznie. Na przykład, jeśli masz 3 osoby w projekcie, to są 3 linie komunikacji. Ale jeśli masz 4, to jest 6 linii komunikacji. Jedna dodatkowa osoba w tym przypadku prowadzi do podwojenia komunikacji! Zabawa. (Jest to oczywiście nadmierne uproszczenie komunikacji w projektach rozwoju oprogramowania).

Różni ludzie pełnią różne role i dlatego otrzymują różne zakresy autonomii. Być może kierownik projektu musi komunikować się ze wszystkimi członkami zespołu. Ale czy inżynier pracujący nad API musi komunikować się z marketerem produktu? A może marketer może po prostu przejść przez menedżera produktu? Dobry proces i kadencja spotkań mogą wówczas wyeliminować niepotrzebną komunikację i spotkania. Chodzi o to, że formuła komunikacji Brooksa to górna granica koordynacji , a nie wyrok śmierci.

Wreszcie, użyj narzędzi, zasad i ram w połączeniu z niezależną pracą nad faktyczną współpracą w celu zwalczania objawów współzależności. Na przykład, jeśli mogę skoordynować kluczowe wskaźniki wydajności dwóch zespołów (KPI, tj. pomiary sukcesu), aby zachęcić do ruchu w mniej więcej tym samym kierunku, to ich niezależna praca będzie bardziej prawdopodobna ich kluczowe wskaźniki efektywności zachęcają do ruchu ortogonalnego. Nie zapewni to, że wszystko będzie idealnie do siebie pasować, tylko że praca, którą muszę wykonać, aby dopasować je do siebie w przyszłości, jest mniejsza niż mogłaby być w innym przypadku. Inne przykłady mogą obejmować stosowanie instrukcji „parzystych”, systemów projektowania i testów automatycznych.

Więc jest początek. Ale współzależności przybierają wiele form poza kodem. Podam przykład z Mailchimp.

Ryzyko związane z obsługą klienta: ukryty (ale akceptowalny?) koszt pracy zaporą ogniową

Ponieważ klientem Mailchimpa jest często właściciel małej firmy, który jest nowicjuszem w marketingu (a na całym świecie są miliony właścicieli małych firm, którzy przekształcili się w marketerów), musimy zapewnić płynne i natychmiast zrozumiałe doświadczenie od początku do końca . Nie możemy pozwolić sobie na luksus złożenia potwora chmur Frankensteina poprzez przejęcie w sposób, w jaki mogą to robić gracze korporacyjni. Nie możemy przerzucać słabo zintegrowanego oprogramowania z konsultantami i opiekunami klientów.

Jako produkt konsumencki (pomyśl o Instagramie, Nintendo Switchu lub Roombie) musimy nadawać się do użytku zaraz po wyjęciu z pudełka. W przypadku kompleksowej platformy marketingowej, która ma wspierać Twój biznes, to trudne! A to oznacza, że ​​każda rzecz, którą tworzy Mailchimp, musi być płynnie połączona z perspektywy doświadczenia.

Jednak doskonałe partycjonowanie projektów wprowadza ryzyko związane z doświadczeniem . Nie chodzi o to, że kodu nie da się napisać samodzielnie. Można to osiągnąć, ale nadal istnieje ryzyko, że produkty będą wyglądać tak, jakby zostały zbudowane przez różne zespoły, a to doświadczenie może być cholernie mylące dla użytkownika. Wpadamy w konflikt z prawem Conwaya — nasi klienci mogą stwierdzić, gdzie kończy się praca jednego zespołu, a zaczyna się praca drugiego zespołu.

Dlatego starasz się połączyć pracę wszystkich ze sobą — nie tylko na zapleczu, ale także na froncie. W erze ekosystemu, zdominowanej przez doskonałość CX od graczy takich jak Apple, stało się to niemal stawką w przestrzeni konsumenckiej. Ale to koszmar Mitycznego Człowieka-Miesiąca , choć tym razem nie z technicznego punktu widzenia. To z perspektywy projektowania usług. W miarę jak dodajemy więcej osób do całej tej kompleksowej pracy połączonej, wszystko zwalnia do wspólnego indeksowania.

Poza trzecią poprawką, o której wspomniałem powyżej, używającą narzędzi i struktur zamiast over-watchy i bramek scenicznych, jest jeszcze jeden zawór zwalniający: dokonaj świadomych kompromisów w zakresie doświadczenia klienta . W szczególności, gdzie możemy swobodnie udostępniać doświadczenie, które jest oderwane od reszty (tj. to jest poniżej normy)? Akceptacja ryzyka i pójście naprzód to zadanie lidera produktu. Używasz więc pewnych kryteriów, aby to uporządkować (być może nie utrzymuje nowych obszarów aplikacji o małym natężeniu ruchu na tych samych standardach doświadczenia, co twoje „dojne krowy”) i podejmujesz decyzję (np. iteracja i nauka polerowania na sąsiednich innowacje). To oczywiście wykracza poza projektowanie.

Zawsze możesz ominąć prawo Brooksa, decydując się na zaporę ogniową, w tym wysiłki, które w idealnym świecie nie powinny być zaporą!

“

Zastrzeżę to, mówiąc, że oprogramowanie, które zbuduję, nikogo nie zabije. Nie zalecałbym tego podejścia, gdybym budował urządzenie medyczne. Ale w firmie zajmującej się oprogramowaniem marketingowym mogę celowo izolować zespoły, wiedząc, że zwiększyłem szanse na niekompatybilność jako kompromis w celu zwiększenia liczby personelu i szybszego poruszania się.

Z przykrością muszę przyznać, że Mityczny Miesiąc Człowieka jest rzeczywistością w mojej firmie i podejrzewam, że również w Twojej. Ale jest to łatwe do opanowania — oto sedno sprawy. Równoległość i łagodzenie zależności oferują nam wyjście, które ogranicza prawie mityczny status Mitycznego Człowieka-Miesiąca . Więc następnym razem, gdy w Twojej firmie pojawi się wyraźna dychotomia (skaluj, aby działać wolniej lub zrezygnować ze swoich aspiracji), pamiętaj, że jeśli jesteś sprytny w tym, jak układasz pracę, nadal możesz urosnąć.

Nie zapomnij o miękkiej stronie skalowania

Pamiętaj, że zarządzanie Mitycznym Człowiekiem Miesiącem nie powstrzyma inżynierów przed przywoływaniem go jak czarnej magii. Odwołują się do tej zasady nie tylko dlatego, że jest w tym trochę prawdy, ale dlatego, że skalowanie po prostu jest do bani (zawsze) z perspektywy emocjonalnej i poznawczej. Jeśli wydaje mi się, że płacą mi za pisanie kodu i rozwiązywanie problemów klientów, ostatnią rzeczą, jaką chcę zrobić, to zmienić swoją rutynę i dowiedzieć się, jak pracować z nowymi ludźmi i większym zespołem.

Skalując swoją firmę, pamiętaj, aby wczuć się w ból skalowania i zmiany. Zespół, który doda nawet jednego członka, staje się zupełnie nowym zespołem z perspektywy zaufania i kultury. Ludzie są zmęczeni tą zmianą. Oznacza to, że zarządzając i łagodząc Mityczny Miesiąc Człowieka , będziesz musiał zarządzać emocjami towarzyszącymi rozwojowi. To chyba najważniejsze zadanie ze wszystkich.

Silna wiara zespołu w Mityczny Człowiek-Miesiąc sama w sobie może urzeczywistnić jego wnioski. To w zasadzie odpowiednik wiary w latanie w Piotrusia Pana. Jeśli zespół uważa, że ​​skalowanie ich spowolni, a nie kupią zmiany, rzeczywiście zwolnią tempo.

Dlatego pracując nad zarządzaniem zależnościami i wprowadzając narzędzia ułatwiające skalowanie, upewnij się, że jasno komunikujesz, dlaczego stoją za praktykami. Zaangażuj ludzi w wybór pracy i procesów, które łagodzą problemy związane z miesięcznymi pracownikami, ponieważ kiedy są częścią zmiany i zmienia się ich perspektywa, nagle skalowanie staje się przynajmniej kulturowo możliwe.