Na początku był chaos – czyli jak zarządziłam swoją pracą jako content writerka

Kiedyś dołączyłam do nowego projektu jako copywriterka. Zakres obowiązków był jasny i konkretny. W dodatku każdy typ zadania rządził się uniwersalymi prawami – przyswoić brief, stworzyć treść, mieć ją zweryfikowaną przez osobę zlecającą i done. Proste, prawda?

Nic bardziej mylnego. Już po miesiącu czułam, że tonę i nie ogarniam chaosu, który mnie otacza. Zadania spływały do mnie ze wszystkich stron – w mailach, na Slacku i na tablicy bez jasnego zakresu czy deadline’u.

Mój kalendarz przypominał pole minowe, a lista rzeczy do zrobienia nie miała końca. Najgorsze było to uczucie, że niby cały czas jestem zajęta, ale wieczorem nie potrafię powiedzieć, co właściwie udało mi się skończyć.

Postanowiłam, że trzeba coś zmienić. Miałam to szczęście, że w procesie wspierał mnie zespół Agile. I chociaż koncentrowaliśmy się na mojej pisarskiej specjalizacji, wiele z praktyk, które opiszę, jest bardzo uniwersalnych.

Kanban nie tylko dla developerów

W pierwszej kolejności chciałam wprowadzić prostą zasadę – wszystkie zadania powinny być mi zlecane w jednym miejscu.

Tak się złożyło, że mój zespół niedawno zaczął pracować w Jirze w metodzie Kanban. Gdy pierwszy raz o niej usłyszałam, wyobraziłam sobie skomplikowany system dla programistów. Okazało się, że to po prostu wizualizacja w formie tablicy tego, co i tak już robiłam, tylko bardziej świadoma.

Niestety nie oznacza to, że moja pierwsza tablica w Jirze działała tak, jak powinna.

Podział na kolumny wyglądał mniej więcej tak:

• To Do (Do zrobienia) – tu lądowało wszystko
• In progress (W trakcie) – regularnie miałam tu 5+ tasków
• Done (Zrobione) – to była najwolniej wypełniająca się kolumna…

Statusy, które mają znaczenie

Dopiero gdy przystąpiłam do sprzątania tego bałaganu, zrozumiałam, dlaczego czuję wypalenie. Statusów było za mało i nie do końca odpowiadały rzeczywistosci. Poza tym, na moją tablicę mogły trafić jakiekolwiek zadania bez żadnej weryfikacji z mojej strony.

Oto najważniejsze zasady, które z pomocą specjalistow Agile wprowadziłam do swojej tablicy w kwestii statusów:

• Stworzyłam Backlog, gdzie w pierwszej kolejności lądują wszystkie zlecane mi zadania (więcej o Backlogu w dalszej części wpisu).
• Dodałam kolumnę „Verifiction” (Weryfikacja). Dzięki temu taski „zimują”, gdy ktoś inny podejmuje akcję, a ja mogę przystąpić do kolejnych zadań. Co więcej, dodałam limit 7-dniowej weryfikacji. Jeśli ktoś nie zrobi jej w terminie, zamykam task.
• Ustawiłam limity w „To Do” i „In Progress”. Teraz mogę tam mieć maksymalnie 3 zadania. Jeśli chcę dodać czwarte, najpierw muszę coś przesunąć do „Verification” albo „Done”. To wymagająca, ale konieczna zasada, aby efektywnie zarządzać swoim skupieniem.
• Dodałam funkcję „flagowania” zadań. Oznacza to mniej więcej tyle, że z jakichś przyczyn task jest wstrzymany, ale nie anulowany. Dzięki takiemu oznaczeniu nie rozpraszam się, przeglądając tablicę albo Backlog w ciągu dnia.

Dodatkowa rada: Taski często „utykają” na etapie weryfikacji. Dzięki wizualizacji tego statusu na tablicy, łatwiej mi przypominać się osobom sprawdzającym. Ponadto, jeśli nie chcesz wprowadzać rygorystycznego limitu czasu na weryfikację, możesz generować raporty z życia tasków. Dzięki temu wykażesz, że zadanie po Twojej stronie było zrobione terminowo, ale nie masz wpływu na to, że task utknął w weryfikacji.

Backlog i checklisty do zadań

Dotąd Backlog był dla mnie strasznym miejscem, na które wolałam nie patrzeć, żeby nie pochłonęła mnie otchłań.

Zmieniło się to, gdy zaczęłam traktować go po prostu jako moją własną poczekalnię, gdzie sama decyduję, kiedy wpuścić do siebie (na tablicę) kolejnego „pacjenta”.

Krótko mówiąc, dopóki taski nie spełnią konkretnych warunków, nie trafiają na główną tablicę. Kluczem okazały się checklisty Definition of Ready – proste pytania, które są załączone automatycznie jako check boxy w tasku. 

• Czy deadline jest realistyczny i jasny? (Nie akceptuję „ASAP” – to nie jest precyzyjny deadline!)
• Czy mam wszystkie materiały/dostępy? (Oszczędzę Wam czasu – nie działa zasada pt. „Zaczynaj teraz, resztę wyślemy później”)
• Czy cel i odbiorca są określeni? („Artykuł o Dockerze” to za mało – dla kogo? Juniorów? Seniorów?)
• Czy format i miejsce publikacji są jasne? (Inaczej pisze się post na bloga, inaczej dokumentację techniczną)
• Czy wiem, kogo zapytać, gdy utknę? (Wyznaczony kontakt w tasku to mój must-have)

Co jeszcze przyda się content writerom:

1. „Czy tekst ma szablon/styl marki?” – Oszczędza mi to godziny przerabiania gotowego tekstu.
2. „Czy są przykłady podobnych realizacji?” – Wolę od razu wiedzieć, jaki tone of voice preferują.

Warto dodać, że wiele z tych pytań znajdzie odpowiedź w dobrze napisanym briefie do zadania. Ale o tym można napisać zupełnie osobny artykuł 😊

Poranna rutyna

Gdy już miałam poukładany Backlog i przejrzystą tablicę z limitami, trzeba było jeszcze ten stan utrzymać. Wprowadziłam więc 15-minutowy rytuał przed rozpoczęciem pracy, który stosuję do dziś:

1. Przeglądam te taski, które są „zablokowane” – może coś jest za długo w weryfikacji albo jakiś task powinien dostać flagę?
2. Przeglądam Backlog:
   • Patrzę na te taski, które dopiero się pojawiły. Sprawdzam, co mogę odznaczyć w checkliście Definition of Ready, a czego mi brakuje. Następnie piszę w komentarzu, czego jeszcze potrzebuję od Zlecającego.
   • Wybieram maksymalnie 3 zadania na dziś. (Jeśli coś już jest w kolumnie „To Do”, muszę pilnować limitu).
3. Rozpoczynam pracę nad taskami, idąc „od prawej” – czyli w pierwszej kolejności popycham te zadania, które są bliżej finalizacji.

Jak można się domyślić, najtrudniejsze było nauczyć się mówić: „Nie, dziś nie wezmę tego zadania”. Ale gdy Project Managerzy zauważyli, że dzięki temu rzeczywiście kończę to, co zaczęłam – nastąpiła pełna współpraca. Ostatecznie wszystko szło do przodu o wiele szybciej!

Komunikacja z Project Managerem (i innymi zlecającymi)

Współpraca z Project Managerem to jeden z kluczowych elementów mojej pracy. Czasami może pojawić się pewien opór przed wprowadzaniem zmian w procesie. Warto wtedy dobrze formułować swoje argumenty.

1. Odnieść się do wspólnego celu: „Limit czasu na weryfikację nie jest po to, żeby było Ci trudniej – staram się nam pomóc dowieźć zadanie w terminie”.
2. Wyjaśnić korzyści: „Zmiana statusu i odpowiednie przypisanie osoby zajmuje tylko parę sekund, a diametralnie ułatwia mi zarządzanie wieloma taskami. Dzięki temu szybciej otrzymasz treść, której ode mnie oczekujesz”.
3. Zaproponować test: „Spróbujmy stosować tę praktykę przez dwa tygodnie – jeśli się nie sprawdzi, wrócimy do poprzedniego sposobu”.

Taka komunikacja nie tylko pomaga faktycznie coś zmienić, ale też buduje zaufanie. PM wie, że jestem zaangażowana w projekt i zależy mi na jakości. Chociaż zmiana zawsze napotyka pewien opór, warto podkreślać, że ostatecznie dzieje się po to, aby ułatwić pracę nam wszystkim.

Kilka słów podsumowania

Nie trzeba być ekspertem od metodyk zwinnych, by lepiej organizować swoją pracę w projekcie. Wystarczy kilka prostych kroków: wizualizacja zadań, codzienny przegląd Backlogu, świadoma komunikacja i gotowość do rozmowy o zmianach. Te praktyki nie tylko ułatwiają codzienność, ale też pozwalają odnaleźć rytm pracy – niezależnie od tego, czy jesteś content writerem, czy pełnisz inną rolę w zespole.

I najważniejsze na koniec… niestety, nie na wszystko mamy wpływ. Jednak czasem już nawet drobne poprawki w procesie i stopniowe wprowadzanie zasad asertywnej komunikacji to krok milowy, aby lepiej nam się pracowało.

Życzę nam wszystkim jak najwięcej jasno opisanych tasków, a jak najmniej oporu przed zmianą 😊