Czy marketing może pracować jak zespół programistów?

W styczniu 1986 roku na łamach „Harvard Business Review” ukazał się artykuł pod tytułem The New Product Development Game. Jego autorzy, Ikujiro Nonaka i Hirotaka Takeuchi, zaproponowali nowe podejście do pracy nad złożonymi procesami. Czy ten rodzaj podejścia może być z powodzeniem stosowany w marketingu?

W lutym 2001 roku w amerykańskim Snowbird siedemnaście osób związanych z IT sformowało i podpisało tak zwany Manifest Agile (pełna nazwa: Manifest Zwinnego Wytwarzania Oprogramowania). Zwinne oprogramowanie było alternatywą dla kaskadowego modelu pracy, który okazywał się coraz mniej efektywny. Scrum to jedna ze zwinnych metodyk. Od tamtej pory ten sposób tworzenia oprogramowania stawał się coraz bardziej popularny na świecie.

Czym jest Scrum?

Scrum to iteracyjna (wielokrotnie powtarzalna) i przyrostowa metodyka zarządzania procesami. Najczęściej spotyka się ją w zespołach IT zaangażowanych w produkcję oprogramowania.

Czas pracy podzielony jest na mniejsze iteracje (zwane sprintami). To pierwsza z zalet Scruma – mniejszymi, operacyjnymi zadaniami łatwiej się zarządza. Szybciej też można korygować ewentualne nieścisłości w założeniach.

Po pierwsze: interakcje

Wszystkie metodyki zwinne charakteryzują się tym, że cenią ludzi i interakcje ponad procesy i narzędzia, działające oprogramowanie ponad obszerną dokumentację, współpracę z klientem ponad formalne ustalenia oraz reagowanie na zmiany ponad podążanie za planem.

Moim zdaniem cztery powyższe filary mogą być, po drobnym przystosowaniu, podstawą działania w komunikacji i marketingu. Mogłyby wtedy brzmieć:

Ceni się bardziej:

• ludzi i interakcje zachodzące między nimi niż procesy i narzędzia,

• działające rozwiązania niż obszerną dokumentację projektową,

• dwustronną współpracę z grupami docelowymi niż formalne ustalenia,

• sprawne reagowanie na zmiany niż ścisłe trzymanie się planu marketingowego.

Role, wydarzenia i elementy

Autorzy i osoby pracujące w tej metodyce twierdzą – dość przewrotnie – że Scrum jest łatwy do zrozumienia, ale trudny do opanowania i wdrożenia. Postaram się nakreślić jego główne założenia i role występujące w jego zakresie. Oto główne cechy charakterystyczne.

• Cały czas pracy dzieli się na powtarzalne okresy. Nazywa się je sprintami. Najczęściej spotykamy się z dwutygodniowymi sprintami. Okres ten wydaje się optymalny czasowo do zarządzania w marketingu i działach komunikacji. Nie jest za krótki, by można było zająć się trochę bardziej złożonymi zadaniami, ale jest na tyle niedługi, że da się sprawnie reagować na częste zmiany rynkowe.

• Zbieranie wszystkich niezbędnych do realizacji zadań na początku każdego sprintu. Równocześnie estymuje się czas zakładany do ich realizacji. Jeśli jedna osoba stwierdzi, że potrzebuje 10 godzin, a druga – 2 godzin na realizację, to mamy od razu możliwość omówienia zadania. Czasami jedna z tych osób źle zrozumie zakres zadania, więc jest okazja do jego weryfikacji, a czasami ktoś zna sposób na bardziej efektywną pracę. Transparentność Scruma zapewnia więc zwiększanie się know‑how całego zespołu i to praktycznie w każdym jego momencie.

• Po każdym sprincie następuje retrospektywa. Podczas niej identyfikuje się pozytywne i negatywne aspekty pracy w poprzednim sprincie oraz dobre praktyki. Taka analiza pozwoli lepiej zaplanować kolejne działania oraz wyeliminować przeszkody, których nie byliśmy wcześniej świadomi. Według twórców Scruma retrospektywa powinna trwać do trzech godzin. Przy dziewięciu osobach (taka jest najwyższa optymalna liczba osób w zespole) wydaje się to czas wystarczający na ten element.

• Główne role w Scrumie związanym z IT stanowi zespół deweloperski, czyli najczęściej zespół programistów; właściciel produktu, czyli osoba z zespołu, ale reprezentująca interesy klienta; oraz Scrum Master – osoba odpowiedzialna za usuwanie przeszkód (zewnętrznych i wewnętrznych) uniemożliwiających pracę nad konkretnym zadaniem. Po przeniesieniu założeń na zespoły marketingu i komunikacji oczywistym będzie fakt, jaką rolę przyjmie zespół marketingu. Ale kto powinien „grać” dwie pozostałe role? Wydaje się, że może robić to osoba odpowiedzialna za cały dział, choć twórcy Scruma nie zalecają łączenia tych funkcji. Moim zdaniem w zespołach nie‑IT jest to dopuszczalne i nawet bardziej efektywne. Można także przyjąć, że właścicielem produktu będzie osoba z poziomu zarządu firmy.

• W założeniach metodyki występuje jeszcze codzienny Scrum (ang. daily Scrum). Wydaje się jednak, że charakterystyka działań marketingowych nie determinuje konieczności codziennego spotykania się. Jeśli został przyjęty dwutygodniowy okres w sprintach, jednogodzinne spotkanie w połowie tego okresu również jest wystarczające.

#Scrum nie tylko dla #IT – wykorzystaj go w marketingu!

Tweetnij

Scrum w marketingu

Nie wszystkie firmy związane z oprogramowaniem korzystają ze zwinnych metodyk. Jak więc przekonać te w ogóle niezwiązane z IT? Oto, moim zdaniem, najciekawsze zalety Scruma w działach marketingu i komunikacji.

• Szybszy proces wdrożenia nowego pracownika do zespołu oraz sprawniejsze poznanie przez niego kluczowych przesłań firmy (ang. key messages). Dzieje się tak, ponieważ w Scrumie dużą rolę przykłada się do informacji zwrotnej podczas omawiania praktycznie każdego zadania. Zadaniem lidera jest więc wyjaśnienie kluczowych przesłań organizacji, tak by nowy pracownik mógł realizować zadania w ich zakresie.

• Sprawniejsze zarządzanie priorytetami i „logistyką zadań”. We wspomnianej logistyce można spotkać trzy najczęstsze techniki: FIFO (pierwsze przyszło, pierwsze wyszło), LIFO (ostatnie przyszło, pierwsze wyszło), FEFO (pierwsze traci ważność, pierwsze wyszło). W marketingu najczęściej wykorzystywana jest technika FIFO, lecz całkowite poleganie na niej mogłoby przysporzyć wielu problemów podczas zapalnych sytuacji, np. brak szybkiej reakcji na sytuację kryzysową, bo wydarzyła się jako ostatnia. Zarządzanie priorytetami jest bardziej elastyczne i transparentne.

Największe wyzwania w przeniesieniu metodyki Scrum do działów nie‑IT

Najtrudniejszym etapem działania Scruma w działach niezwiązanych z IT wydaje się być sama jego implementacja. Oprócz wdrożenia wyszczególniłem cztery wyzwania.

• Obłożenie działu marketingu różnymi zadaniami (w zależności od firmy mniej lub bardziej związanymi ze wspieraniem sprzedaży, tworzeniem wizerunku, działaniami dotyczącymi media relations, budowaniem i realizacją strategii komunikacyjnej, zagadnieniami związanymi z employer brandingiem i dziesiątkami podobnych) sprawia, że zawsze jest więcej rzeczy „do zrobienia” niż możliwych zasobów do wykorzystania. W zasadzie wszystkie rzeczy są „na już”, więc powinny mieć wysoki priorytet. Wtedy jednak zarządzanie priorytetami nie będzie miało sensu. Proponuję stworzenie trójstopniowego systemu priorytetów. Nazwać można je dowolnie: 1, 2, 3, A, B, C itd. Ja stosuję nazewnictwo backlog L, backlog M, backlog S. Jest to terminologia wprost przeniesiona ze Scruma. Nazwa nie ma tutaj kluczowego znaczenia – istotne jest zarządzanie priorytetami. Jeśli jakieś zadanie zostało przydzielone do backlogu L, oznacza to, że jak tylko będą wolne zasoby, to zostanie ono zrealizowane w pierwszej kolejności, a żadne zadanie z niższego backlogu nie może być rozpoczęte, dopóki istnieją jakiekolwiek zadania na wyższym backlogu.

• Standardowo w Scrumie pracują programiści, którzy nie wykonują dla klientów prac serwisowych. Oznacza to, że cokolwiek dzieje się z systemem, to zajmuje się tym zespół serwisowy. Zespół Scruma ma zarezerwowane własne zasoby i nie są one przydzielane do innych prac niż zadania określone w sprintach. Wydaje się, że zespoły marketingu nie mają takich możliwości. Istnieje mnóstwo sytuacji, w których pewne rzeczy od razu stają się bardzo pilne – wystarczy wspomnieć o wyżej wymienionych sytuacjach kryzysowych. Jeśli zespół jest na tyle duży, że potrafi wydzielić „zespół serwisowy”, to jest to duży luksus. Trudno oszacować, ile firm w Polsce mogłoby stworzyć taki dział. W pozostałych przypadkach rozwiązaniem jest obłożenie sprintu na około 80% możliwości. Wtedy, podczas nagłych przypadków, zespół byłby i tak w stanie dostarczyć zakładane efekty sprintu.

• Znajomość metodyki wśród współpracowników i przełożonych. Zdaję sobie sprawę, że kiedy powiemy osobie z innego działu i to w firmie niezwiązanej z IT, że „umieściliśmy zadanie na backlogu L i prawdopodobnie zajmiemy się tym już w następnym sprincie”, może nas nie zrozumieć. Kluczem wydaje się być tutaj edukacja oraz systematyczne pokazywanie wyników prac, które w mojej opinii są dużo lepsze niż w innych systemach pracy.

• Wpływ czynników zewnętrznych. Nawet najlepsze planowanie i estymacje czasowe nie są w stanie przewidzieć czynników zewnętrznych. W działach IT pracujących w Scrumie zespół dysponuje wszystkimi zasobami i kompetencjami pozwalającymi na dokończenie określonych/zdefiniowanych efektów w zakładanym czasie. Działania z innymi podmiotami (wewnętrznymi i zewnętrznymi) mogą skutecznie przesunąć wszystkie ustalone terminy. W tym momencie pomaga retrospektywa i odniesienie się do czasu niezbędnego na wykonanie podobnego zadania w przeszłości łącznie z czasem reakcji podmiotów zewnętrznych.

Podsumowanie

Zwinne podejście do tworzenia oprogramowania zyskuje na popularności w świecie IT. Sprawdza się szczególnie w projektach bardzo rozbudowanych, w których występuje dużo zmiennych. Przyglądając się zakresowi zadań działów marketingu i komunikacji, możemy dojść do wniosku, że charakterystyka pracy jest zbliżona – wysoka złożoność, dynamika zmian i konieczność stałego poszerzania wiedzy. Myślę, że dlatego warto spróbować Scruma.