Od niemal całego życia zajmuję się marketingiem. Zanim zacząłem promować kanały YouTube w One2, zarządzałem działem obsługi klienta w agencji PROMO. Innowacje zawsze mnie przyciągały, więc spotkanie z metodologią Scrum było dla mnie kwestią czasu.
Moja droga do zarządzania projektami
W agencji reklamowej stałem się liderem działu składającego się z menedżerów kont. Nie mieliśmy systemu zarządzania projektami. Nie zdążaliśmy na czas z realizacją naszych zobowiązań kontraktowych ani nie wykonaliśmy pracy w dobrej jakości. W ten sposób stałem się osobą rozwiązującą problemy, aby zająć się negatywnymi opiniami klientów. To była droga bez wyjścia: nie zapobiegając problemowi, zajmowałem się jego następstwami.
Zacząłem szukać zestawu narzędzi, które mogłyby pomóc w tej sytuacji. W tamtym czasie nie miałem pojęcia o Agile ani Scrum, nie mówiąc już o sposobach stosowania metodologii Scrum w zespołach nie-IT.
Stałem się osobą rozwiązującą problemy, aby zająć się negatywnymi opiniami klientów.
Jak wybraliśmy metodologię zarządzania projektami
Na początku przyjrzeliśmy się Kanbanowi. Jest on szczególnie dobry do rozwiązywania problemów związanych z przepływem, takich jak poprawki błędów czy przetwarzanie zgłoszeń w centrum obsługi. Ale aby wprowadzić Kanban, potrzebujesz wysoko zmotywowanego i dobrze zorganizowanego zespołu. To nie dotyczyło naszego przypadku.
Rozważaliśmy też Waterfall. Jest on dobry dla zespołów IT, ponieważ wyraźna sekwencja etapów wymaga mniej kodu i jest na wzrost. Ten sam projekt w Scrum wyglądałby zupełnie inaczej:
działająca rzecz —> dostosowanie —> optymalizacja
Wiarygodność Waterfall ukrywa jego wadę – wysoki ryzyko zakłócenia terminów. Firmy chcą uzyskać wyniki jak najszybciej, a nie czekać całego roku, aby przekonać się, że wybrana strategia nie działa. Scrum też nie jest wolny od tego „problemu”.
Jakie narzędzia Scrum będą odpowiednie dla agencji marketingowej
Scrum oferuje wiele narzędzi do zwiększenia motywacji:
- Tablice Scrum. Tablice Scrum pokazują statusy zadań i mogą prowadzić do punktów problemowych (np. za dużo zadań jest w etapie dyskusji z klientami). Umożliwiliśmy naszym klientom dostęp do tablic scrumowych, aby mogli śledzić statusy zadań. To znacznie odciążyło naszych menedżerów kont.
- cotygodniowe standupy. Wszyscy członkowie zespołu kolejno przedstawiają wyniki ostatniego dnia, składają obietnice na bieżący dzień i dzielą się problemami. Dzięki takim codziennym standupom można zrozumieć, co dzieje się w firmie i znaleźć sposób na uczynienie pracy bardziej efektywną.
- planowanie. Czyni proces pracy przejrzystym dla menedżera i dla klienta. Zapraszaliśmy konkretnych klientów i wspólnie decydowaliśmy, jakie zadania ustalić na następujące sprintry.
- retrospektywa. Możemy zrozumieć błędy, które popełniliśmy i sposoby ich naprawy (np. jak zwiększyć liczbę jednoczesnych zadań w toku bez uszczerbku dla jakości).
- prezentacja produktu. Prezentuje postępy zespołu dokonane w czasie sprintu. Każdy członek zespołu pokazuje swoją część produktu. Prezentacja produktu umożliwia szybkie wprowadzenie zmian, poprawę produktu i nie marnowanie czasu na wcześniejsze prezentacje gotowego produktu.
Moja praca wcześniej polegała głównie na analizowaniu negatywnych opinii klientów. Po wprowadzeniu Scrum, zaczęliśmy pytać klientów o opinie, aby zrozumieć, czy nasz kierunek działania jest właściwy. Udoskonaliliśmy wskaźnik obsługi konsumenckiej (NPS).
Jakie są wady Scrum dla zespołów nie-IT?
Scrum ma trzy główne wady:
- Procesy biznesowe stają się droższe. Wprowadziliśmy stanowisko właściciela produktu, ponieważ żaden członek zespołu nie mógł poradzić sobie z tak ważną rolą. Taki specjalista jest kosztowny. Ani właściciel produktu, ani mistrz Scrum nie tworzą wartości bezpośrednio; są poza zespołem, a w zasadzie należą do kategorii wydatków ogólnych.
- Nie ma wygodnej usługi zarządzania projektami w Scrum dla zespołów nie-IT. Wcześniej korzystaliśmy z Jiry, ale jej dostosowanie często wymaga zaangażowania specjalisty.
- Terminologia IT w Scrum nie jest dostosowana do firm nie-IT. Dla firm IT istnieją szczegółowe wytyczne określające sposoby działania Scrum. Wyjaśniają terminologię: przyrost to działający produkt, prezentacja to pokazywanie sposobów działania produktu. W naszym przypadku nie było jasne, jak pisanie treści wpływa na działanie produktu. A co to jest przyrost w SEO? Jeśli napisaliśmy tekst i opublikowaliśmy go na stronie – czy to jest działający produkt? Zajęło nam ponad trzy miesiące dostosowanie terminologii IT do naszych potrzeb.
Jak nie udało nam się wprowadzić Scrum
Zaczęliśmy wprowadzać Scrum od zgrupowania. I od razu popełniliśmy dwa błędy.
Błąd nr 1. Zaczęliśmy łączyć specjalistów ds. reklamy kontekstowej i SEO w jednym zespole. Logika jest następująca: wszyscy generują ruch na strony klientów i zwiększają sprzedaż, co oznacza, że mogą razem pracować. Zespół jest zjednoczony wokół jednego klienta.
Jak rozwiązaliśmy problem: po pewnym czasie podzieliliśmy specjalistów według wartości i produktów. Niektórzy klienci otrzymali jednocześnie kilku menedżerów kont i zespoły.
Co zrozumieliśmy: zespół powinien być zjednoczony wokół celu biznesowego. Taki zespół jest samowystarczalny i potrafi samodzielnie tworzyć wartość dla klienta.
Błąd nr 2. Nie zdefiniowaliśmy od razu, kto ma być mistrzem Scrum i właścicielem produktu.
Jak rozwiązaliśmy problem: uzupełniliśmy istniejące stanowisko księgowego grupy o funkcję mistrza Scrum. Wcześniej odpowiadał on za wydajność zespołu i nieprzerwaną dostawę wartości do klienta. Zatrudniliśmy osobną osobę jako właściciela produktu.
Często spotykam się z dwoma błędami w firmach, które także wprowadzają Scrum:
- zespoły są łączone wokół jednej funkcji. Dział jest po prostu przemianowywany na zespół. Problem polega na tym, że jeśli klient potrzebuje strony internetowej, zespół powinien mieć programistę, projektanta i menedżera. Żaden dział marketingu składający się z menedżerów marki nie stworzy strony internetowej.
- Firmy boją się zniszczyć istniejącą strukturę. Następujący przykład był rzeczywisty. Jeden menedżer konta obsługiwał kilka projektów, z których każdy był wspierany przez różnych specjalistów SEO. Projekty były dystrybuowane w zależności od obciążenia specjalistów SEO. Załóżmy, że specjalista otrzymał 10 projektów do pracy o różnym priorytecie. Priorytety ustalają menedżerowie projektów, a ta firma miała ich kilku. W najlepszym przypadku specjalista SEO wykonał najłatwiejsze zadanie, w najgorszym — zadanie menedżera konta, który najwięcej krzyczał.
Zjednoczenie w „właściwe” zespoły to bolesny proces.
Dlaczego potrzebujemy mistrza Scrum?
Toyota ma interesujący przypadek, który ilustruje rolę mistrza Scrum. W fabryce niektórzy pracownicy zostali przydzieleni do wspierania inżyniera mechanika w optymalizacji pracy. Inżynier mechanik otrzymywał wynagrodzenie godzinowe, które było na tyle wysokie, że konieczne było zwiększenie wydajności i obniżenie kosztów. Zauważono, że inżynier mechanik szukał odpowiedniego klucza – wówczas przydzielono mu pomocnika, który dostarczał klucze. Idea miała jeszcze bardziej uprościć proces: na podłodze malowano szablony narzędzi, a pomocnik układał je rano przed rozpoczęciem pracy.
Tak więc dobry mistrz Scrum zapewnia 80% sukcesu w wprowadzeniu Scrum. Jeśli brakuje ci osoby, która mogłaby objeć tę rolę, znajdź kogoś, kto jest zainteresowany dalszą pracą w tej dziedzinie. W ostateczności, poszukaj mistrza Scrum w firmach IT.
Mistrz Scrum ma następujące nieoczywiste funkcje:
- Czucie, gdzie zespół nie radzi sobie, gdzie można przyspieszyć, a gdzie lepiej zwolnić. To jak tarcza przeciwko presji terminów i chaosu.
- Odpowiedzialność za poczucie bezpieczeństwa zespołu. Obejmuje to ochronę przed klientem, który chce „zrobić wszystko na wczoraj”. Na przykład, natknęliśmy się na taki problem: menedżerowie kont przygotowywali raporty dla klientów przez długi czas. Na wskazanie mistrza Scrum, uruchomiliśmy automatyczne raporty generowane w czasie rzeczywistym. Teraz klient nie musi czekać na koniec miesiąca, aby zrozumieć, jak radzimy sobie. Wszystkie strony są zadowolone.
- Podnoszenie poziomu zespołu w korzystaniu ze Scrum poprzez dobrowolny wybór.
- Komunikacja jeden na jeden z każdym członkiem zespołu. O problemach i kłopotach pracownika. W ten sposób młodsze specjalisty szybciej osiągną średni poziom, a średni będą awansować na starszych. Rotacja personelu zmniejszy się.
Dlaczego potrzebujemy właściciela produktu?
Nie zrozumieliśmy od razu, kto ma zostać właścicielem produktu i za co będzie odpowiadał. Doszliśmy do wniosku, że właściciel produktu to specjalista techniczny, który ma dobrą wiedzę na temat produktu i potrafi opracować strategie kontekstowe i SEO, przekazując je klientowi. Innymi słowy, jest to strateg, który mówi, co należy zrobić.
Co robi nasz właściciel produktu?
- tworzy backlogi;
- usuwa i ustala priorytety zadań;
- dostosowuje strategie na podstawie danych uzyskanych od zespołu;
- ponosi odpowiedzialność przed klientami za wynik.
Jak wdrożyliśmy Scrum w firmie nie-IT
Specjaliści pracowali oddzielnie: copywriterzy i redaktorzy, specjaliści do spraw linkowania i analitycy SEO. Wprowadzając Scrum, połączyliśmy ich ze sobą. Każdy zespół ma również menedżera konta, który przynosi wartość klientom.
Zespoły były formowane dla każdego z trzech obszarów SEO:
- zarządzanie masą linków
- tworzenie treści
- przeróbka stron internetowych.
Praca była podzielona na sprintry, które stanowiły podstawę miesięcznego planowania. Podczas planowania staraliśmy się zminimalizować ryzyko braku osiągnięcia wyniku na końcu miesiąca.
Eksperymentujemy z czasem trwania sprintów. Kiedy zaczynaliśmy wprowadzać Scrum, sprintry trwały tydzień. Tygodniowy sprint pozwala na szybkie uruchomienie procesu i zrozumienie, gdzie popełniasz błędy, nauczenie pracowników i zrozumienie, jak wszystko działa.
Kluczowa rada dotycząca czasu trwania sprintów Scrum w marketingu: wybierz termin, który wystarcza, aby stworzyć użyteczną rzecz.
Sprintry wyglądają następująco:
planowanie —> standupy —> prezentacja —> retrospektywa.
Przekierowaliśmy część zespołów do sprintów dwutygodniowych. Pamiętaj, że im dłuższy sprint, tym większe ryzyko, że nie dotrzymasz terminów.
W naszej pracy korzystamy z następujących narzędzi:
- planowanie pokerowe. Technika ta umożliwia ocenę złożoności i zakresu zadań, które będą musiały zostać rozwiązane w trakcie tworzenia produktu. Wszyscy członkowie zespołu są zaangażowani w planowanie pokerowe. Korzystając z kart, oceniają zadania i podejmują decyzje zbiorowe;
- analogiczny do programowania w parach oparty na ekstremalnym programowaniu. Kilka osób pracuje nad zadaniem w tym samym miejscu pracy. To demonstracyjny przykład zasady – „Dwie głowy są lepsze niż jedna”. Używamy tego w krytycznych momentach;
- cykle HADI. Są to algorytmy do sprawdzania kontrowersyjnych hipotez, które pomagają zyskać zaufanie klientów. Więcej o cyklach HADI przeczytasz poniżej.
Co to są cykle HADI i jak je wykorzystać?
Co to jest? Cykl HADI to algorytm do sprawdzania hipotezy, który wygląda następująco:
hipoteza —> weryfikacja —> wynik —> wnioski.
Cykle HADI przypominają pętlę Lean Startup:
budować —> mierzyć —> uczyć się
Jak to działa?
Generujesz hipotezy, których wykonalność budzi wątpliwości. Jeśli zadanie jest zrozumiałe i potrzebne, nie ma sensu przetwarzać go w cyklu HADI. Po sprawdzeniu hipotezy określasz, czy się udała, i w jakim stopniu efektywności. Jeśli tak, uruchamiasz ją w sprincie, jeśli nie, po prostu ją odrzucasz.
Jak to wygląda?
Na przykład, istnieje hipoteza: „Jeśli zrealizuję linkowanie wewnętrzne na produktach, przyniesie to potrojenie wzrostu ruchu”. Sprawdzaj hipotezę na jednym produkcie, ustawiając linki ręcznie wewnątrz strony. Jeśli hipoteza się uda, wydajesz zadanie programistom: „Zapewnij linkowanie wewnętrzne na całej stronie”.
Jakie są zalety cykli HADI?
Możliwe, że klient uważa, że twoje nowe rozwiązanie nie będzie dobrze działać. W odpowiedzi pokazujesz rzeczywisty przykład oparty na jednym elemencie.
Dokumentuj swoje hipotezy, nawet jeśli się nie powiodły. W następnym sprincie możesz przetestować inną. Dodatkowo upewnij się, że twoje eksperymenty nie powodują konfliktu interesów (na przykład, aby hipotezy dotyczące tej samej strony internetowej nie były testowane jednocześnie). W przeciwnym razie nie będzie jasne, która hipoteza odniosła sukces.
7 wskazówek, jak wprowadzić Scrum, jeśli nie jesteś firmą IT
- Rozpocznij od szkoleń. Czytaj literaturę specjalistyczną, uczestnicz w szkoleniach.
- Określ, kto jest twoim interesariuszem (stroną zainteresowaną). A następnie pracuj, aby dostarczyć wartość klientowi i interesariuszowi.
- Sprintry powinny pozostać niezmienione. Nie bój się zmieniać reszty rzeczy.
- Nie kieruj całego zespołu do Scrum, tylko dlatego że „to jest fajne”. Na przykład, nasi copywriterzy pracują w Kanban, ponieważ teksty nie mają priorytetów – muszą być po prostu zrobione jak najszybciej.
- Określ optymalny rozmiar swojego zespołu. Z mojego doświadczenia wynika, że w firmach nie-IT wynosi on pięć-siedem osób.
- Organizuj oddzieloną przestrzeń roboczą dla każdego zespołu. Jeśli masz biuro typu open space, dodaj offline’owe tablice Scrum.
- Przejmij inicjatywę w wdrażaniu Scrum. Jeśli kierownictwo nie wie, jaki jest cel nowej metodologii, nic nie zostanie zrobione.