Zespół inżynierów w portalu Compass miał problem. Nasze funkcje były technicznie dobre, ale czegoś brakowało — prawdziwej satysfakcji klientów. Sprawnie pisaliśmy kod, ale czy rozwiązywaliśmy właściwe problemy?
Pracując nad portalem Compass jako starszy menedżer ds. inżynierii w firmie Atlassian, całe lata zmagałem się z tym wyzwaniem. Mój zespół i ja jesteśmy odpowiedzialni za tworzenie narzędzi, które pomagają zespołom programistycznym zarządzać komponentami oprogramowania i zasobami na dużą skalę. Od razu zauważyłem schemat, z którym boryka się wiele organizacji inżynierskich: jesteśmy świetni w dostarczaniu funkcji, ale czasami nie udaje się nam dostarczyć wartości.
Widziałem na własne oczy, jak kultura inżynierska potrafi zadecydować o sukcesie lub porażce produktu. W firmie Atlassian nie tylko tworzymy narzędzia dla zespołów programistycznych — żyjemy tymi samymi wyzwaniami, z którymi codziennie borykają się nasi klienci. Daje nam to wyjątkowe spojrzenie na przekształcanie kultury inżynierskiej i dlatego tak zależy mi na dzieleniu się tym, czego się nauczyliśmy.
Brak łączności w tradycyjnej inżynierii
Porozmawiajmy o hipotetycznym zespole produktowym, którego historia może zabrzmieć znajomo.
Tina jest starszą programistką znaną ze swojej doskonałości technicznej. Chociaż jej kod był nienaganny, utknęła w dobrze znanym cyklu: otrzymanie wymagań, napisanie kodu i wdrożenie funkcji. „Pisałam kod w próżni”, przyznaje Tina. „Nie miałam pojęcia, czy to, co tworzyłam, rzeczywiście rozwiązywało prawdziwe problemy klientów”. Potrzebowała więcej kontekstu dotyczącego klienta, ale czuła się ograniczona skupianiem się na samym wdrożeniu.
Rita, projektantka produktu w zespole, miała własne problemy. Tygodniami tworzyła perfekcyjne projekty tylko po to, aby otrzymać kluczową informację zwrotną w trakcie rozwoju oprogramowania, która wymuszała poważne zmiany. „Gdy programiści wskazują na ograniczenia techniczne, często jest za późno, aby zachować pierwotną wizję projektu”, wyjaśnia. Rita potrzebowała lepszej integracji z procesem rozwoju oraz sposobu na wcześniejszą weryfikację projektów.
Jest też Paul, menedżer produktu, który próbuje utrzymać wszystko w ryzach. Poświęcał mnóstwo czasu na sporządzanie dokumentów zawierających szczegółowe wymagania, jednak po drodze zawsze coś ginęło. „To jak zabawa w głuchy telefon”, mówi Paul. „Gdy funkcje trafiają do klientów, są już czymś innym niż początkowo sobie wyobrażaliśmy”. Rozpaczliwie zabiegał o lepszą współpracę między zespołami inżynierskimi i projektowymi, ale tradycyjny proces przekazywania wciąż tworzył bariery.
Rick, menedżer programu, miał chyba najtrudniejszą rolę ze wszystkich. Nocami pracował nad koordynowaniem zależności między wieloma zespołami, jednocześnie szukając równowagi między szybkością dostawy a jakością. „Kiedy zespoły pracują w odosobnieniu, proste zmiany mogą powodować tygodniowe opóźnienia”, zauważa Rick. Potrzebował sposobu na pobudzenie lepszej współpracy między zespołami oraz poprawę widoczności.
Wszystko to nadzorowała Anna, liderka ds. inżynierii, która borykała się ze zmianą sposobu działania swoich zespołów. Chociaż ceniła doskonałość techniczną, wiedziała, że czegoś brakuje. „Mamy niesamowicie utalentowanych inżynierów”, zauważa, „ale nie dostarczamy konsekwentnie wartości, jakiej potrzebują nasi klienci”. Anna chciała zmienić kulturę zespołu, ale tradycyjny model rozwoju utrudniał zrównoważenie doskonałości technicznej i wartości dla klienta.
Doświadczenie tego zespołu odzwierciedla szerszy wzorzec w rozwoju oprogramowania. Tradycyjne podejście sekwencyjne, choć zorganizowane i przewidywalne, tworzy naturalne bariery między osobami opracowującymi produkt a jego użytkownikami.
Kultura: klucz do transformacji
„Kultura zjada strategię na śniadanie”. Chociaż cytat ten jest często przypisywany guru zarządzania Peterowi Druckerowi, zyskał na znaczeniu, gdy Mark Fields umieścił go na stałe w pokoju narad Forda w 2006 roku. To przesłanie nie tylko było chwytliwą frazą — zawierało fundamentalną prawdę, którą wielokrotnie dostrzegaliśmy w branży technologicznej: nawet najbardziej błyskotliwa strategia nie powiedzie się, jeśli będzie sprzeczna z kulturą organizacji.
Kiedy zdecydowaliśmy się zmienić naszą kulturę inżynierską w portalu Compass, odkryliśmy coś ważnego: sama doskonałość techniczna to za mało. Musieliśmy wypełnić lukę między naszymi inżynierami a klientami. Liczby to potwierdzają: firmy o ugruntowanej kulturze odnotowują czterokrotnie wyższy wzrost przychodów niż ich konkurenci.
Doskonale ilustruje to nasza transformacja w portalu Compass. Przeszliśmy od tradycyjnego procesu cyklu życia funkcji trwającego zwykle 6–8 tygodni do iteracyjnego procesu odkrywania, który znacznie przybliżył nam problemy klientów. Nie była to tylko zmiana procesu — było to fundamentalne przejście od nastawienia „wiedzieć wszystko” do „dowiedzieć się wszystkiego”, w którym każda funkcja stała się okazją do uczenia się od naszych klientów.
Ewolucja inżynierii produktu
Inżynieria oprogramowania tradycyjnie polegała na przekształcaniu wymagań w działający kod przez systematyczne projektowanie, rozwój i testowanie. Inżynierowie koncentrują się przede wszystkim na technicznym wykonaniu: napisaniu efektywnego kodu, utrzymaniu systemów i zapewnieniu jakości.
Inżynieria produktu stanowi jednak fundamentalną zmianę sposobu myślenia o tworzeniu oprogramowania. Chociaż zachowuje techniczną dyscyplinę inżynierii oprogramowania, dodaje kluczowy element: dogłębne zrozumienie klienta i ciągłe uczenie się. Inżynierowie produktu nie tylko piszą kod — oni uczestniczą w odkrywaniu i rozwiązywaniu problemów klientów, wykorzystywaniu wiedzy technicznej przy podejmowaniu decyzji dotyczących produktów oraz braniu odpowiedzialności za wyniki swojej pracy.
Tradycyjny model inżynierii oprogramowania
W tradycyjnym modelu rozwój oprogramowania ma charakter liniowy. Wymagania są przekazywane od działu zarządzania produktem przez dział projektowania do zespołów inżynierskich, które je wdrażają. Pomyśl o tym jak o sztafecie, w której każdy zespół przekazuje pałeczkę następnemu.
Stary przepływ pracy naszego zespołu odzwierciedlał to liniowe podejście:
- Tworzenie i zatwierdzanie dokumentów dotyczących wymagań ciągnęło się miesiącami.
- Architekci i projektanci pracowali w izolacji.
- Inżynierowie kodowali zgodnie z dokładnymi specyfikacjami.
- Testowanie i wdrażanie następowało na końcu.
- Opinie klientów były wielokrotnie filtrowane.
To podejście sprawdzało się, gdy wymagania pozostawały stabilne, a zmiany były kosztowne. Ale na dzisiejszych szybko rozwijających się rynkach potrzebowaliśmy czegoś bardziej adaptacyjnego i zorientowanego na klienta.
Ciągła pętla inżynierii produktu
Nasza transformacja koncentrowała się na zastąpieniu tego liniowego procesu ciągłą pętlą uczenia się. Zamiast traktować rozwój jako sztafetę, działamy teraz bardziej jak drużyna piłkarska — wszyscy poruszają się razem, dostosowują do zmieniających się warunków i pilnują celu dostarczania wartości dla klientów.
W tym nowym modelu:
- inżynierowie biorą udział w rozmowach z klientami i sesjach odkrywania;
- rozwój i projektowanie odbywają się wspólnie, przy szybkim prototypowaniu i testowaniu;
- decyzje techniczne są weryfikowane zgodnie z potrzebami klienta;
- wdrożenie staje się okazją do nauki, a nie tylko kamieniem milowym w dostawie;
- zespoły mierzą sukces za pośrednictwem wpływu na klienta, a nie tylko wskaźników technicznych.
Od wdrożenia do odpowiedzialności
Dla inżynierów takich jak Tina ta transformacja oznaczała ewolucję od czystego wdrożenia do wzięcia prawdziwej odpowiedzialności. Obecnie inżynierowie:
- biorą udział w definiowaniu problemów i badaniu rozwiązań;
- wnoszą techniczny punkt widzenia do dyskusji na wczesnym etapie;
- sprawdzają założenia bezpośrednio z klientami;
- biorą odpowiedzialność za ostateczny kształt funkcji wykraczający poza samą jakość kodu;
- śledzą wskaźniki biznesowe i wpływ na rynek.
Wyniki mówią same za siebie: organizacje przyjmujące ten model odnotowują krótszy czas wprowadzenia na rynek i wyższe wskaźniki przyjęcia funkcji niż te stosujące tradycyjne podejścia do inżynierii. Co być może jeszcze ważniejsze, dostrzegliśmy większe zaangażowanie zespołu, trafniejsze decyzje techniczne i większą zgodność naszych rozwiązań technicznych z potrzebami klientów.
Jak umożliwiliśmy naszą transformację
Przekształcenie sposobu pracy inżynierów wymagało nie tylko zmiany sposobu myślenia, ale także odpowiedniej podstawy. Dla naszego zespołu kluczowym elementem tej podstawy było narzędzie Jira Product Discovery, które naturalnie wprowadziło kontekst klienta do naszego codziennego przepływu pracy.
Pierwszym problemem, który musieliśmy rozwiązać, było udostępnienie wszystkim analiz klientów. Wcześniej opinie klientów i wymagania dotyczące produktów znajdowały się w dokumentach Confluence, wątkach Slack i zgłoszeniach Jiry. Narzędzie Jira Product Discovery wprowadziło cały ten kontekst bezpośrednio do naszego przepływu pracy programistycznej. Inżynierowie mogli wreszcie zobaczyć rozmowy z klientami, sesje informacji zwrotnej i wzorce użytkowania obok prac programistycznych, dzięki czemu potrzeby klientów stały się namacalne i bliskie, a nie abstrakcyjne i odległe.
Ta dostępność zasadniczo zmieniła sposób współpracy naszych zespołów. Po utworzeniu nowych projektów projektantka taka jak Rita mogła powiązać je bezpośrednio z problemami klienta, które były widoczne i zrozumiałe dla inżynierów. Gdy Paul ustalał priorytety dla funkcji, mógł łatwo połączyć wpływ na klienta ze złożonością techniczną, co prowadziło do bardziej świadomych decyzji. Co najważniejsze, nasi inżynierowie mogli wreszcie zobaczyć pełny obraz — nie tylko to, co tworzyliśmy, ale też dlaczego miało to znaczenie dla naszych klientów i jak mogło wpłynąć na ich pracę.
W przypadku zespołów rozważających podobną transformację należy pamiętać, że nie chodzi o wybór między doskonałością techniczną a koncentracją na kliencie. Chodzi o połączenie tych dwóch elementów w celu tworzenia produktów, które klienci naprawdę będą uwielbiać. Kiedy inżynierowie dogłębnie rozumieją potrzeby klientów, podejmują lepsze decyzje techniczne, projektują bardziej przemyślane rozwiązania i dostrzegają większy sens swojej pracy, ponieważ widzą jej bezpośredni wpływ.
Chcesz dowiedzieć się więcej o tym, jak dokonaliśmy tej transformacji? Obejrzyj nasze webinarium: Magia inżynierii produktu: zamiana problemów klientów w uwielbiane funkcje, podczas którego szczegółowo omówię naszą podróż oraz podzielę się praktycznymi strategiami i rytuałami, które możesz wdrożyć w swoim zespole.