Restrukturyzacja zespołu produktowego Braze

Najważniejszą siłą napędową każdego produktu programowego jest grupa ludzi, którzy go tworzą — oraz ich wzajemne relacje. Dlatego ważne jest, aby zorganizować zespoły w sposób, który pozwoli im na uzyskanie jak największej dźwigni i wpływu.

W Braze intensywnie zastanawialiśmy się nad tym, jak projektowana jest nasza organizacja produktowa i inżynierska, i chcemy podzielić się naszymi wnioskami z poważnej reorganizacji działu, która pomogła nam znacznie ulepszyć sposób ustalania priorytetów funkcji, rozwijania wiedzy zespołu i bardziej efektywnego tworzenia naszego produktu.

Wczesna struktura: dopasowanie produktu/rynku i nie tylko

Znalezienie dopasowania produktu do rynku — i wykorzystanie go do rozwoju firmy — to tygiel, przez który muszą przejść wszystkie startupy. Na tym etapie rozwoju startupu szybkość eksperymentowania i umiejętność szybkiego wykorzystywania szans mają kluczowe znaczenie. W tym celu nasza oryginalna struktura zespołu produktowego wyglądała tak:

Ta struktura, która podzieliła nasz zespół w oparciu o specjalności funkcjonalne, sprawdziła się z kilku powodów.

Po pierwsze, pozwoliło nam to skutecznie radzić sobie z transformacyjnymi zmianami produktów na drodze do dopasowania produktu do rynku — eksperci mogli posiadać ogromne połacie naszej bazy kodu i korzystać z języków, frameworków i decyzji projektowych, z którymi byli najwygodniejsi. Napędzane ogromnymi ilościami kofeiny „drużyny” projektowe typu „armia-of-one” regularnie podejmowały ogromne przedsięwzięcia. Obejmowały one zbudowanie naszego publicznego interfejsu API skierowanego do klienta i przebudowę całej naszej infrastruktury do wysyłania wiadomości, często pełniąc rolę jedynego inżyniera, menedżera produktu i projektanta. Tego typu ekstremalne środki byłyby szaleństwem w dużej firmie, ale są konieczne i prawie rutynowe na wczesnym etapie rozwoju.

Dodatkowo ta struktura pomogła nam osiągnąć głębokie mistrzostwo w niektórych obszarach technicznych przy zaledwie 10-15-osobowym zespole. Wiele elementów naszych podstawowych produktów — np. warstwa model-widok-kontroler naszego interfejsu, interfejsy API i kod do wysyłania wiadomości o wysokiej przepustowości — zostało w pełni zrozumianych przez zaledwie kilka osób.

Wtedy było to proste i wszystko, czego potrzebowaliśmy. Kiedy szybkość jest najważniejsza, organizowanie w oparciu o proste wytyczne pomogło zmniejszyć obciążenie poznawcze i pozwoliło nam skupić uwagę tam, gdzie może to przynieść najwięcej dobrego.

Późniejsza struktura: wzrost i skalowanie

Jednak gdy nasz zespół przekroczył 30 lub 40 lat, struktura ta zaczęła się rozpadać. Ostatecznie zidentyfikowaliśmy reorganizację naszego zespołu produktowego jako rozwiązanie niektórych z naszych największych wyzwań. Wkładaliśmy niezrównoważone wysiłki, żonglując zestawami umiejętności i harmonogramami, aby tworzyć zespoły do ​​projektów strategicznych. Spędzaliśmy również nadmierną ilość czasu na ustalaniu priorytetów i często musieliśmy ustalać na siłę wszystkie priorytety produktów w całej firmie, ponieważ nasza struktura zespołu oparta na technologii nie odpowiadała bezpośrednio najważniejszym potrzebom produktu. I wreszcie, mieliśmy niewiele okazji dla członków zespołu, aby zdobyć głębokie doświadczenie z konkretnymi przypadkami użycia klientów.

Ostatecznie przeszliśmy na organizację zorganizowaną wokół zespołów wielofunkcyjnych Agile, podobną do modelu Squad/Tribe spopularyzowanego przez Spotify. Nasza nowa struktura organizacyjna wygląda tak:

Większość naszego zespołu pracuje w ramach „pionów produktowych”, odpowiadających kluczowemu obszarowi naszego produktu lub działalności. Na przykład:

• Nasz zespół ds. poczty e-mail i przedsiębiorstw obsługuje pocztę e-mail od góry do dołu, a także niektóre obszary produktów, takie jak zarządzanie uprawnieniami, które mają kluczowe znaczenie dla wielu naszych największych klientów.
• Nasz zespół Messaging & Automation posiada kilka obszarów produktów związanych z segmentacją użytkowników, przesyłaniem wiadomości i naszym flagowym produktem do orkiestracji, Canvas.

W ramach danej pionu oczekujemy, że ustalanie priorytetów będzie (stosunkowo) proste, ponieważ każdy z pionów odpowiada określonemu zestawowi potrzeb klientów. Niektóre zespoły, takie jak Visual Design, DevOps i nasze grupy inżynierii infrastruktury obejmują całą platformę, budując spójność w kluczowych obszarach.

Oddziaływania

Nasza reorganizacja znacznie zmniejszyła zależności między zespołami. Wcześniej borykaliśmy się z podobnym do Sudoku problemem planowania odpowiedniej równowagi między specjalistycznymi zestawami umiejętności (inżynieria, projektowanie, zarządzanie produktem itp.) w danym projekcie w określonym czasie. Dostosowano również zachęty krótkoterminowe — przed przejściem zespoły często polegały na kontrahentach, którzy dążyli do niezwiązanych ze sobą celów. Dzięki naszej nowej strukturze zespoły produktowe są niezależne, mają znacznie większą kontrolę nad terminami i są w pełni dostosowane do celów, zwiększając produktywność i morale.

Nowy projekt organizacji poprawił również ustalanie priorytetów. Na przykład nasz zespół ds. poczty e-mail i przedsiębiorstw może być zmuszony do podjęcia decyzji między modernizacją naszej infrastruktury poczty e-mail, utworzeniem podstawowej funkcji poczty e-mail lub naprawą problemu z użytecznością w przedsiębiorstwie — jest to prosta i łatwo mierzalna decyzja, ponieważ wszystkie trzy dotyczą w podobny sposób potrzeb naszych klientów .

Zespół borykający się ze zbyt wieloma potrzebami o wysokim priorytecie jest również wskaźnikiem, że ich obszar produktowy potrzebuje więcej zasobów. Pozwala nam to na przekształcenie trudnych problemów związanych z ustalaniem priorytetów w potrzeby kadrowe, które wciąż są trudne, ale koncepcyjnie proste do rozwiązania.

Wreszcie, skupienie większości zespołów na konkretnym obszarze produktowym pozwoliło poszczególnym osobom na zbudowanie głębokiej wiedzy i wysoce produktywnych relacji roboczych z biegiem czasu. Początkowo, w ciągu pierwszych kilku lat budowania, jednostki mogły trzymać w głowach zasadniczo cały produkt i bazę kodu, ale gdy dorastaliśmy, stało się to niemożliwe. Problemy z produktem są fraktalne: za każdym razem, gdy przyjrzysz się bliżej, znajdziesz więcej niuansów i głębi. W rezultacie spędzanie wielu godzin w określonym obszarze produktu lub bazy kodu i dogłębne zrozumienie jego potrzeb biznesowych jest jednym z najlepszych sposobów na osiągnięcie prawdziwych przełomów produktowych. Ponadto tworzenie skoncentrowanych, długoterminowych zespołów buduje poczucie własności i relacji, a także pozwala na budowanie niewypowiedzianych relacji roboczych między spójnym zestawem współpracowników.

Oczywiście żaden system nie jest doskonały. Koncentrując się na filarach zorientowanych na produkt, zwiększyliśmy potencjał zespołów do optymalizacji pod kątem lokalnych potrzeb kosztem holistycznych priorytetów. Na przykład można skoncentrować się na zlokalizowanym długu technologicznym („ten kontroler jest niewygodny”) zamiast na problemach globalnych („zmiana naszego frameworka front-endowego zwiększyłaby ogólną prędkość prac inżynieryjnych”). W oczekiwaniu na tę potrzebę podjęliśmy kroki w celu ustanowienia wspomnianych powyżej zespołów przekrojowych i wykorzystaliśmy dedykowane komitety do innych szerokich projektów – na przykład komitet do zbudowania całościowego systemu produktowego/projektowego z komponentów front-end i wzorców projektowych .

Nasza nowa struktura zapewnia również wyższą energię aktywacji dla holistycznych, transformacyjnych zmian produktów. Niektóre obszary naszego produktu, takie jak interfejsy API zaplecza, są wspólną własnością kilku zespołów. Próg wprowadzania rozległych zmian w szerokich, przekrojowych obszarach naszej bazy kodu jest wyższy, więc ten rodzaj struktury działa najlepiej, gdy szkielet Twojego produktu jest już w dużej mierze uformowany.

Na wynos

Ogólnie rzecz biorąc, jesteśmy zadowoleni z naszej przeprojektowanej struktury organizacyjnej produktu: rozwiązaliśmy lub znacznie poprawiliśmy nasze wyzwania związane z zależnościami zespołów, ustalaniem priorytetów i budowaniem długoterminowej wiedzy o produktach, a także mamy pomocny plan działania dotyczący skalowania. W szczególności dowiedzieliśmy się, że:

• Usunięcie zależności i dostosowanie zachęt prowadzi do ogromnego przyrostu wydajności.
• Priorytetyzacja jabłek na jabłka jest zarówno prostsza, jak i skuteczniejsza.
• Głęboka wiedza na temat konkretnego klienta lub potrzeby biznesowej prowadzi do lepszych wyników produktu.
• Praca z tymi samymi członkami zespołu przez dłuższy czas ma kluczowe znaczenie dla budowania doskonałych relacji roboczych.

Poleciłbym tę strukturę każdemu zespołowi, który ma pewne kluczowe cechy: organizację międzyfunkcyjną, w której eksperci funkcjonalni, tacy jak menedżerowie produktu, projektanci i inżynierowie, są równymi interesariuszami; ponad około 15–20 osób w połączonym zespole ds. rozwoju produktu; i, co najważniejsze, silne dopasowanie produktu do rynku. A jeśli taka struktura zespołu brzmi dla Ciebie atrakcyjnie, zatrudniamy!