Zespoły prawdziwie interdyscyplinarne. Jak świadomie je budować?
Ludzie – to na nich trzeba stawiać. No i na mocne, niezależne zespoły, wyposażone w najlepsze narzędzia! I rzeczywiście chcemy, aby tak było, ale… coś nam zgrzyta. Praca zdaje się iść wolno, a efekty nie powalają. Mamy dobrych specjalistów, pracujemy niby zwinnie, ale coś się nie zgadza. Bo w rzeczywistości nie chodzi jedynie o to, aby mieć dobrych specjalistów i najlepsze technologie. Ważne są jeszcze interakcje (i procesy), zachodzące między tymi ludźmi. A te wymagają bardzo świadomego budowania zespołów. Najlepiej prawdziwie interdyscyplinarnych.
Co to znaczy zespół prawdziwie interdyscyplinarny? I dlaczego jest to takie ważne?
To taki zespół, który rzeczywiście, a nie tylko pozornie, posiada wszystkie umiejętności, które potrzebne mu są do osiągania zadań. Przykładowo: jeśli potrzebny jest w zespole Product Designer, to taka rola znajdzie się w składzie tego zespołu. Ważne jest to, że będzie ona jego integralną częścią, a nie zewnętrznym dostawcą usługi, któremu zleca się zadania.
To holistyczne podejście do składu, procesów i interakcji, zachodzących między jego członkami, które sprawia, że zespół realizuje cele bez oczekiwania na kogoś z zewnątrz.
Złożone problemy ( np. rozwój produktów cyfrowych), dotykające wielu obszarów i zagadnień (np. SEO, UX, frontend, backend), wymagają takich zespołów właśnie. Interdyscyplinarność pozwala im działać niezależnie (od innych). Zespoły niezależne to zespoły szybsze (mniej czekania), w których członkowie czują większą odpowiedzialność za swój obszar i dzięki temu dostarczają lepsze rozwiązania. Przewagę konkurencyjną można zdobywać na kilka sposobów, a częstotliwość i czas dostarczania zmian mogą być jednym z nich. Między innymi dlatego warto zwrócić uwagę na to, czy nasz zespół jest prawdziwie interdyscyplinarny, a dzięki temu niezależny, czy tylko pozornie składa się z uzupełniających się ról. Mam wrażenie, że często liderom wydaje się, że pracują zwinne i zbudowali zespoły interdyscyplinarne, a w rzeczywistości nie tylko brakuje w zespole wybranych ról, ale w dodatku procesy i interakcje między nimi to skostniałe, powolne mechanizmy; przykładowy projektant pracuje dla kilku zespołów, z których każdy próbuje wyszarpać jak najwięcej jego czasu. Liderzy sądzę, że zapewnili odpowiednie „zasoby”, ale nie rozumieją, jak taki układ funkcjonuje w praktyce.
Jeden zespół będzie potrzebował w składzie tylko frontend dewelopera i backend deweloperów, ale jeszcze inny będzie działał w pełni swoich sił, gdy na jego pokładzie znajdą się dodatkowo Data Analyst i Product Designer. Dobry skład to będzie krok pierwszy. Kolejnym będzie zadbanie o to, aby mogli oni korzystać ze swoich umiejętności stale, na bieżąco. Korzyści opisywanego podejścia jest sporo, więc przejrzyjmy je pokrótce.
Wiele z firm podkreśla, że „teamwork to ważna rzecz”. Ciężko się z tym nie zgodzić. Ale jak to praktykować? Jak wzmocnić poczucie gry zespołowej? Stwórz zespół interdyscyplinarny właśnie. Pomyśl: teamwork może wtedy zaistnieć, gdy będzie do niego okazja i zespół interdyscyplinarny to jest taka okazja. Zespół, który musi działać w różnych układach osobowych na potrzeby zadań (raz Jacek z Kasią, kiedy indziej Kasia z Martą i Jackiem) i w którym specjaliści różnych dziedzin wymieniają się wspólnie wiedzą i praktykami, to doskonała baza dla zaistnienia pracy zespołowej. Z mojego doświadczenia wynika, że to w takich grupach jest najwięcej dynamiki i wielobarwnych interakcji, które nas jednoczą. Nie jest oczywiście tak, że to warunek konieczny, ale to na pewno sytuacja sprzyjająca grze zespołowej.
Gdy pozwolisz, aby spotkali się specjaliści z np. dwóch różnych dziedzin, którzy mają wspólne zadanie, może zdarzyć się magia. A na pewno zdarzy się sporo nauki. Może też innowacyjnych rozwiązań, kto wie? W zespołach interdyscyplinarnych, których skład nie zmienia się przez dłuższy czas, wiedza zaczyna bardzo swobodnie przepływać między specjalistami, wychodzą oni poza swój obszar, inspirują się nawzajem, wyjaśniając pewne zagadnienia. Nie bój się jednak, nic się nie rozmywa – nie jest tak, że każdy zaczyna być specjalistą „od wszystkiego, czyli od niczego”. Przykładowo: programiści lepiej zaczynają rozumieć zagadnienia user experience, a projektanci ograniczenia techniczne i tematykę responsywności. Dzięki temu pomysły są bardziej kreatywne, lepiej dopasowane do standardów, uwzględniają szerszą perspektywę.
Mało tego – okazuje się, że wielobarwność zespołu powoduje, że zmienia się styl komunikacji, bo dbamy o to, aby więcej osób nas rozumiało. Przez to stosujemy inne metody tłumaczenia pomysłów, sporo wizualizujemy, często upraszczamy, szukamy różnych perspektyw. Przykład: w pewnym zespole projektanci musieli zrozumieć zagadnienie związane z bardzo „backendowymi” rzeczami, aby zaprojektować nowy interfejs dla użytkowników. Ich pytania były tak fundamentalne, że zaczęliśmy odkrywać nieprzyjazne użytkownikom pierwotne założenia logiki działania pewnych funkcji. Stało się tak dlatego, że programiści PHP żyli z klątwą wiedzy (wiedzieli, jak poruszać się po serwisie od dłuższego czasu) i gdy musieli wyjść ze swojej wąskiej specjalizacji i wyjaśnić te zagadnienia innym członkom zespołu, okazało się, że nie wszystko jednak jest takie proste. Efekt współpracy? Przyjaźniejsza logika działania aplikacji.
Projektanci (i inni specjaliści) to deweloperzy
W praktyce zespoły prawdziwie interdyscyplinarne można poznać po kilku cechach czy aktywnościach. Przede wszystkim: każdy członek tego zespołu bierze udział, jako pełnoprawna jego część, we wszystkich wydarzeniach i spotkaniach, które uznawane są za zespołowe.
Czy w Twoim zespole projektanci UX biorą udział w retrospektywach i planowaniu sprintu? To tylko przykładowe pytanie, ale myślę, że pozwala zrozumieć, o co mi chodzi. Jeśli wytwarzasz produkty, które wymagają np. specjalisty UX, to najprawdopodobniej taki projektant powinien brać udział w tych wydarzeniach, jak każdy inny deweloper. Deweloper? Tak, deweloper! Projektanci w takim sensie też rozwijają (development) oprogramowanie. To samo dotyczy analityków danych, specjalistów SEO i innych dziedzin. Rozumiem, że formalnie tacy ludzie są zatrudnieni na stanowiskach odpowiadających ich specjalizacjom, ale w zespołach prawdziwie interdyscyplinarnych te formalne tytuły nie mają tego znaczenia, natomiast to, co robimy – ma. I tak w przypadku np. projektanta rozwija on produkty poprzez tworzenie makiet, widoków, opinie, testy z użytkownikami i tak dalej.
Kolejnym przejawem, który może nam podpowiedzieć, czy nasz zespół jest interdyscyplinarny, jest sposób przepływu komunikacji na codzień, na potrzeby pojedynczych zadań, historyjek czy funkcji (feature’ów). Jak daleko musi „sięgnąć” frontend developer, gdy potrzebuje opinii specjalisty UX/UI (Może jednak zmienimy ten element na inny niż w projekcie)? Czy komunikuje się przez Jirę, Trello lub inny system ticketów? Może przez Product Ownera lub Project Managera? Może musi czekać do jakiegoś „weekly”? Im więcej musisz włożyć wysiłku w uzyskanie odpowiedzi na jakieś pytanie, tym większa szansa, że go ostatecznie nie zadasz i być może stracicie szansę na lepsze rozwiązanie. W prawdziwie interdyscyplinarnym zespole kontakt specjalistów będzie bezpośredni i na bieżąco – tak, jak gdybyśmy siedzieli obok siebie w biurze i tak, jak robią inni deweloperzy między sobą. Nie przez pośredników lub przy jakichś dedykowanych do tego okazjach, ale od razu, gdy występuje taka potrzeba.
Miałem okazję pracować w różnych układach, ale to właśnie wtedy, gdy specjaliści różnych dziedzin byli blisko siebie, powstawały najlepsze produkty. Pozwalało to na szybkie zmiany nawet w trakcie developmentu. Z pewnym zespołem tworzyliśmy nowy cennik usług, stronę, na której można było zamówić wariant produktu. W trakcie pisania kodu nowej wersji cennika programiści wpadali na pomysły drobnych usprawnień do pierwotnego dizajnu. Mając możliwość bieżących konsultacji z projektantem UX/UI, zgłaszali je i część była od razu implementowana. Porównaliśmy efekt końcowy i pierwotne projekty – różnic było sporo, chociaż wiele z nich niewielkich rozmiarów. Za to wyniki biznesowe tego wdrożenia nas zachwyciły.
Bliska współpraca między np. projektantami i programistami, będzie wymagała także tego, aby specjaliści byli ze sobą zsynchronizowani w czasie – aby projekty powstawały w odpowiednim momencie, tuż przed rozpoczęciem kodowania. Pisząc prościej: projektant UX/UI będzie działał z delikatnym wyprzedzeniem programistów. Czasami będzie to sprint wcześniej, a czasem 2-3 dni przed rozpoczęciem programowania. W zależności od metod pracy możesz chcieć najpierw omówić pomysł z całym zespołem na sesji refinementu (daw. grooming, doskonalenie backlogu) zanim trafi on do sprintu. Zatem rytm, w jakim pracujecie (np. długość trwania sprintów), będzie wpływał na to, kiedy tacy specjaliści muszą być gotowi ze swoim materiałem i jak długo jeszcze będziecie o nich rozmawiali.
Aby skrócić czas między wytworzonym materiałem a rozpoczęciem kodowania danego pomysłu, można skorzystać z makiet, prototypów – często one są wystarczające i nie musisz mieć finalnego dizajnu przed rozpoczęciem kodowania, aby możliwe było jego omówienie lub nawet wytwarzanie. Dodatkowo możesz skrócić ten czas, gdy nie potrzebujesz tworzyć wielu nowych widoków, pełnych dizajnów, bo macie już dobrze wykorzystywany od dłuższego czasu style guide (lub inne zestawy zasad czy standardów) – w takiej sytuacji wystarczy rozmowa na ogólnym poziomie, ponieważ detale (np. odległości między przyciskami, kolory, rozmiary) są już znane.
Skupiłem się trochę na sytuacji, w której to programiści korzystają ze współpracy z np. projektantem. Jednak w prawdziwie interdyscyplinarnym zespole wymiana wiedzy i opinii działa we wszystkie strony. W praktyce oznacza to, że projektant, zanim skończy swoją pracę, może skorzystać ze wsparcia programistów, pozyskując opinie w zakresie możliwości technicznych czy generalnie zebrać feedback (A co myślisz o tym?) – w takich zespołach pętla zwrotna odbywa się bardzo często, na małych częściach. Dzięki temu unika się sytuacji, w których ktokolwiek, niezależnie od specjalizacji, tworzy duży materiał, a dopiero po opracowaniu go waliduje, czy to był w ogóle dobry kierunek.
Porównajmy tę sytuację z taką, w której najpierw zewnętrzny zespół projektantów tworzy przez wiele tygodni kompletny zestaw widoków. To dosyć częsty układ w niby zwinnych organizacjach. Nie róbmy tak! Jeśli nie możemy inaczej, bo organizacja jest skostniała i nie ma szans na reorganizację, to na poziomie zespołu spróbujmy zrobić coś, co zapewni częstą pętlę zwrotną od samego początku. Projekty mogą być już od pierwszych wersji widoków pokazywane programistom i szeroko konsultowane. Stwórzmy sobie chociaż namiastkę prawdziwie interdyscyplinarnego zespołu.
Nikt z nas nie lubi marnotrawstwa. Szczególnie, gdy marnujemy talenty naszych ludzi, np. poprzez nieoptymalną pracę. Nie twórzmy silosów kompetencyjnych, zewnętrznych zespołów, które ze sobą muszą się synchronizować, przekazywać sobie materiały i tym podobne. Zespoły prawdziwie interdyscyplinarne to sposób na uniknięcie niepotrzebnych przestojów w pracy, zwiększenie zaangażowania i dużo lepsze wyniki biznesowe na koniec.
