Wymiana doświadczeń: 6 sposobów, w jakie inżynierowie i menedżerowie produktu mogą sobie pomagać

Zapomnij o wszystkim, co słyszałeś na temat rywalizacji między inżynierami a menedżerami produktu – to paradygmat, który musi odejść w zapomnienie. Dzisiejszy świat technologii zmienia się zbyt szybko, a jedyną drogą naprzód jest współpraca oparta na wzajemnym dawaniu i braniu. Ten artykuł odkrywa sześć sposobów, dzięki którym inżynierowie i PMowie mogą unikać zderzeń i pozostać skoncentrowani na misji.

1. PMowie: Dzielcie się szerszą perspektywą; Inżynierowie: Dzielcie się ograniczeniami technicznymi

Oddaj: PMowie mogą pomóc inżynierom, dostarczając jasne zrozumienie celów biznesowych i potrzeb klientów stojących za projektem. To pomaga inżynierom zrozumieć, dlaczego dana funkcja lub termin jest ważny. Wczesne dzielenie się kontekstem pozwala inżynierom dostosować swoją pracę do szerszych celów.

Weź: Inżynierowie, w zamian, powinni otwarcie komunikować ograniczenia techniczne i złożoności związane z projektem. Jeśli pozornie mała funkcja będzie wymagała dużych zmian w backendzie, wyjaśnienie tego na wstępie pomaga PMom podejmować lepsze decyzje dotyczące priorytetów i harmonogramów.

Przykład: PM tłumaczy, że funkcja jest kluczowa do zdobycia ważnego klienta lub sprostania konkurencyjnym zagrożeniom, co pomaga inżynierom ustawić ją jako priorytet. Podobnie, gdy inżynier dzieli się, że funkcja będzie wymagała dodatkowego czasu z powodu problemów ze skalowalnością, PM może dostosować oczekiwania.

Zasób

Dla PM-ów: "Product Management in Practice" autorstwa Matta LeMay – Kompleksowy przewodnik po rozumieniu i komunikowaniu celów produktu.

Where the World Designs Electronics

Break down silos and enhance collaboration across all aspects of electronics development

Find Out More

Dla Inżynierów: "The Pragmatic Programmer" autorstwa Andrew Hunta i Davida Thomasa – Książka podkreślająca znaczenie komunikacji i podejmowania decyzji technicznych w procesie rozwoju.

2. PM-owie: Unikajcie mikrozarządzania; Inżynierowie: Angażujcie się w proces ideacji

Podaruj: Menedżerowie produktu powinni oprzeć się pokusie kontrolowania każdego szczegółu wykonania produktu. Zaufajcie inżynierom w kwestiach technicznych i dajcie im przestrzeń do rozwiązywania problemów na własną rękę. Zbyt szczegółowe zarządzanie może stłumić kreatywność i prowadzić do zniechęcenia.

Weź: Inżynierowie powinni przejąć inicjatywę w procesie ideacji. Nie czekajcie, aż zostaniecie poproszeni – oferujcie sugestie i pomysły na ulepszenie produktu. Wielu inżynierów posiada cenne spostrzeżenia, które mogą poprawić funkcjonalność, wydajność lub projekt produktu. Bycie proaktywnym pokazuje, że jesteście zainteresowani sukcesem produktu nie tylko od strony kodowania.

Przykład: PM określa cele biznesowe i prosi o wkład zamiast mówić inżynierom, jak mają zaimplementować funkcję. Tymczasem inżynierowie proaktywnie oferują rozwiązania techniczne i przyczyniają się do sesji burzy mózgów.

Zasób

Design Better, Together

Experience flexible controls for team management and project visibility.

Explore Solutions

Dla PM-ów: "Empowered" autorstwa Marty'ego Cagana i Chrisa Jonesa – Ta książka bada, jak upoważnić zespoły do przejmowania odpowiedzialności za realizację produktu.

Dla inżynierów: "Creative Confidence" autorstwa Toma Kelleya i Davida Kelleya – Świetne źródło dla inżynierów, którzy chcą kreatywnie przyczyniać się do idei produktu.

3. PM-owie: Hojnie przyznawajcie uznanie; Inżynierowie: Publicznie wspierajcie decyzje dotyczące produktu

Przyznawaj: Jedną z częstych skarg inżynierów jest to, że PM-owie przywłaszczają sobie zasługi za sukces projektu, ponieważ to oni często prezentują go kierownictwu. PM-owie mogą budować zaufanie, dzieląc się uznaniem z zespołem inżynieryjnym i dając inżynierom możliwość prezentowania ich pracy.

Wspieraj: Inżynierowie, w zamian, mogą wspierać decyzje PM-ów podczas prezentacji dla innych zespołów lub interesariuszy. Nawet jeśli nie zgadzasz się z niektórymi aspektami, publiczne popieranie decyzji dotyczących produktu pokazuje jedność i sprzyja kulturze współpracy.

Przykład: Po udanym wprowadzeniu produktu na rynek, PM zaprasza inżynierów do prezentacji osiągnięć technicznych. Inżynierowie, w zamian, publicznie wspierają decyzje PM-ów dotyczące produktu na spotkaniach z interesariuszami.

Zasób

Dla PM-ów: "Radical Candor" autorstwa Kim Scott – Książka, która dostarcza wglądów w budowanie silnych relacji i przyznawanie zasług tam, gdzie się należą.

Dla inżynierów: "Crucial Conversations" autorstwa Al Switzlera, Josepha Grenny'ego i Rona McMillana – Naucz się, jak prowadzić efektywne, wspierające rozmowy z kolegami i kierownictwem.

4. PMowie: Bądźcie otwarci na dyskusje o długu technicznym; Inżynierowie: Bądźcie realistyczni co do harmonogramów

Podaruj: PMowie mogą pomóc inżynierom, będąc otwartymi na rozmowy o długu technicznym i konserwacji. Kuszące jest priorytetyzowanie nowych funkcji, ale zaniedbanie technicznej podstawy może prowadzić do większych problemów. Pozwolenie na czas na niezbędne refaktoryzacje kodu lub ulepszenia infrastruktury demonstruje zrozumienie dla długoterminowego zdrowia produktu.

Weź: Inżynierowie również powinni być realistyczni, jeśli chodzi o to, ile czasu rzeczy zajmą. Jeśli podajesz zbyt konserwatywne szacunki, PMowie mogą czuć się pod presją, aby naciskać na harmonogramy. Dostarczanie dokładnych harmonogramów i wczesne komunikowanie opóźnień pomaga PMom efektywnie planować.

Przykład: Inżynierowie komunikują ryzyko związane z długiem technicznym, a PMowie pozwalają na czas na refaktoryzację, podczas gdy inżynierowie dostarczają realistyczne szacunki czasu, aby zarządzać oczekiwaniami.

Zasób

Dla PMów: "Technical Debt 101" autorstwa ThoughtWorks – Świetne wprowadzenie do zrozumienia długu technicznego i sposobów jego zarządzania.

Dla inżynierów: "Projekt Feniks" autorstwa Gene'a Kima, Kevina Behra i George'a Spafforda – Powieść ilustrująca wpływ równoważenia długu technicznego i priorytetów biznesowych.

5. PMowie: Włączajcie inżynierów w otrzymywanie informacji zwrotnych od klientów; Inżynierowie: Szanujcie priorytety biznesowe

Podaj: PMowie mogą pomagać inżynierom, dzieląc się bezpośrednio informacjami zwrotnymi od klientów. Inżynierowie często czują się bardziej związani z produktem, gdy słyszą, jak klienci go używają, z jakimi problemami się mierzą i które funkcje uwielbiają.

Weź: Inżynierowie, z kolei, powinni szanować priorytety biznesowe, które PMowie starają się zrównoważyć. Chociaż uruchomienie funkcji, która nie jest doskonała, może być frustrujące, czasami może to być kluczowe dla utrzymania konkurencyjności.

Przykład: PM zaprasza inżynierów do udziału w sesjach zbierania informacji zwrotnych od klientów, a inżynierowie rozumieją znaczenie pewnych uruchomień funkcji, nawet gdy czują, że niektóre aspekty wymagają dalszego dopracowania.

Zasób:

Dla PMów: "Lean Product Playbook" autorstwa Dana Olsena – Praktyczny przewodnik do zrozumienia informacji zwrotnych od klientów i przekładania ich na działania strategii rozwoju produktu.

Dla inżynierów: "Mit o miesiącu człowieka" autorstwa Fredericka P. Brooksa – Ta klasyczna książka porusza wyzwania związane z harmonogramami rozwoju oprogramowania i oczekiwaniami biznesowymi.

6. PMowie: Ustalajcie Jasne, Osiągalne Cele; Inżynierowie: Bądźcie Zorientowani na Rozwiązania

Podaj: Jedną z najcenniejszych rzeczy, jakie PM może zrobić dla inżynierów, jest ustalenie jasnych i osiągalnych celów. Niejasne wymagania lub ciągle zmieniające się priorytety mogą powodować frustrację. Definiując, jak wygląda sukces i trzymając się tych parametrów, PMowie mogą pomóc inżynierom skupić się i pracować efektywnie.

Weź: Inżynierowie powinni podchodzić do problemów z nastawieniem na rozwiązania. Zamiast wymieniać powody, dla których coś nie może zostać zrobione, proponuj alternatywy lub obejścia. Bycie konstruktywnym pomaga PMowi i zespołowi iść do przodu bez utknięcia na technicznych przeszkodach.

Przykład: PM dostarcza jasne metryki sukcesu dla projektu, podczas gdy inżynierowie oferują praktyczne rozwiązania, gdy pojawiają się techniczne ograniczenia.

Zasób

Dla PMów: "Mierz to, co ma znaczenie" autorstwa Johna Doerra – Dowiedz się, jak ustalać jasne cele i mierzalne kluczowe wyniki (OKR), które są zgodne z wysiłkami twojego zespołu.

Dla inżynierów: "Projektowanie aplikacji intensywnie wykorzystujących dane" autorstwa Martina Kleppmanna – Zasób techniczny, który pomaga inżynierom myśleć o budowaniu skalowalnych, niezawodnych systemów, równoważąc wymagania produktu.

Przykład z życia wzięty: 5-stopniowy algorytm Elona Muska do redukcji biurokracji wewnętrznej

Elon Musk jest dobrze znany ze swojego śmiałego stylu zarządzania w Tesla i SpaceX. W swoich dążeniach do przecięcia wewnętrznej biurokracji, Musk opracował pięciostopniowy algorytm, szczegółowo opisany w jego ostatniej biografii autorstwa Waltera Isaacsona, który dostarcza praktycznego schematu dla usprawnienia procesów.

1. Kwestionuj każde wymaganie: Musk radzi kwestionować każde wymaganie, nawet jeśli pochodzi od "inteligentnej osoby". Przypisz imię do każdego wymagania i ciągle pytaj, czy jest ono konieczne. Jeśli nie, wyeliminuj je.
2. Usuń każdą część procesu, którą możesz: Musk podkreśla, że prostota jest kluczem. Usuń niepotrzebne kroki—idź dalej, niż myślisz, że powinieneś. Jeśli nie musisz dodać przynajmniej 10% z powrotem, nie usunąłeś wystarczająco.
3. Uprość i optymalizuj: Dopiero po wyeliminowaniu niepotrzebnych kroków powinieneś uprościć i zoptymalizować to, co pozostało. Unikaj błędu usprawniania procesów, które nie powinny w ogóle istnieć.
4. Przyspiesz czas cyklu: Gdy proces zostanie usprawniony, skup się na jego przyspieszeniu. Musk ostrzega przed marnowaniem czasu na przyspieszanie części procesów, które są zbędne lub niepotrzebne.
5. Automatyzuj na końcu: Ostatnim krokiem Muska jest automatyzacja, ale tylko po dokładnym zbadaniu, usunięciu i uproszczeniu procesu. Zbyt wczesna automatyzacja może prowadzić do niepotrzebnej złożoności.

Metoda Muska może być potężnym przykładem, jak PMowie i inżynierowie mogą współpracować, aby kwestionować nieefektywności, usprawniać przepływy pracy i optymalizować produktywność. Poprzez ciągłe kwestionowanie założeń i upraszczanie procesów, zespoły rozwijające produkty mogą znacząco zmniejszyć wewnętrzne przeszkody i zwiększyć współpracę.

Mniej stresu, więcej pasji

Jak mądrze powiedział Simon Sinek, "Ciężka praca nad czymś, na czym nam nie zależy, nazywa się stresem; ciężka praca nad czymś, co kochamy, nazywa się pasją." To samo dotyczy relacji między inżynierami a PMami. Kiedy pracują razem z wzajemnym szacunkiem i pasją, dzieją się wielkie rzeczy. Niech ten duch dawania i brania napędza kolejne wielkie wydanie produktu Twojego zespołu.