Zarządzanie projektami oparte na kartach – sprawdzam nowe narzędzie Codecks

Z czym kojarzy Ci się zarządzanie projektem?

Pewnie z nudą, z pilnowaniem zadań, estymacji, sprawdzaniem, czy coś nie utknęło na dłużej w jakimś statusie. Dla mnie jest to zawsze forma interesującej magii. Z tych początkowo niepowiązanych linii, powoli wyłania się całość. Mniej lub bardziej udana. Wymagająca dopracowania, dalszych szlifów. W końcu po to iterujemy projekt, aby żył, rozwijał się, a czasem zmieniał swój kierunek. Pewnie myślisz, że do opieki nad projektem używa się też nudnych narzędzi? Nie. Nie zawsze. Chociaż przyznaję, że niektórzy wciąż trzymają się Excelowego arkusza.

Codecks – zarządzenie oparte na kartach

Nie twierdzę, że jest zły, że to jakaś kompletnie pomylona metoda. Po prostu z mojego doświadczenia wynika, że wraz z rozwojem projektu, trzeba włożyć trochę siły w ulepszenie czytelności. I trudno udostępnia się taki arkusz innym osobom, które również działają w projekcie i opiekują się mniejszymi zespołami. Wtedy dobrze pomóc sobie i sięgnąć po jakiś program. Tylko co wybrać? Na rynku jest ich mnóstwo, spotkałem się z używaniem Jiry, Redmine’a, ClickUp oraz Notiona. Widziałem też projekty na HackNPlan. Wszystkie narzędzia mają swoje plusy i minusy. Ale czy któreś jest dedykowane gamdevowi? Tak, to ostatnie. HackNPlan, ale ma to do siebie, że się je kocha albo nienawidzi.

Dlatego wciąż szukam interesujących rozwiązań. I tak trafiłem na Codecks. Narzędzie od podstaw stworzone dla gamedevu, przez osoby pracujące w tej branży. Odpowiadają za nie ludzie z Maschinen Mensch, studia, które stworzyło dwie części „Curious Expedition”.

Codecks polega na tym, że sprowadza tworzenie gry do formy zabawy. Zadania prezentowane są w formie kart, którym można przypisać tagi, osobę odpowiedzialną, status, priorytet, a także powiązać je z innymi. Potem układa się je w talie, które odpowiadają poszczególnym działom lub elementom gry. Stamtąd zadnia trafiają na rękę do zespołu lub konkretnej osoby. Tworzy to swoistą kolejkę, pozwalająca na określenie czym trzeba się zająć i w jakiej kolejności. Codecks pozwala także na mierzenie czasu spędzonego na danym zadaniu, ale nie pozwala ustawiać estymacji. W tym przypadku twórcy narzędzia zdecydowali się na ciekawy zabieg i wprowadzili kategorię effort (wysiłek). Pozwala to na sprawdzanie, ile energii potrzeba na realizacje poszczególnych zadań i jak przekłada się ona na czas spędzony na pracę. To jest interesujące podejście, trochę rezonuje mi z książką „NoEstimates: How To Measure Project Progress Without Estimating” Vasco Duarte. Myślę, że korzystanie z wymiaru effort jest w stanie przynieść dużo dobrego w pracy nad grą.

Każdy zespół dysponuje ograniczoną ilością energii, która też podlega różnych zmianom. Ktoś zachoruje, pójdzie na urlop, będzie miał gorszy tydzień. Nie zawsze widać to w tradycyjnych estymacjach czasowych. Sądzę, że effort wykorzystany w Codecks można przekuć w solidny wskaźnik określający prędkość realizacji zadań.

To jest dobry trop do oceny kondycji projektu oraz osób zaangażowanych w jego tworzenie. Bo w końcu to ludzie pracują nad grą, takie tytuły jak „Against the Strom” nie powstają same z siebie. Stoją za nimi zespoły. Właśnie za taką uosobienie pracy lubię Codecks. Budowanie talii wymaga interakcji pomiędzy ludźmi, codziennych (a przynajmniej cotygodniowych!) rozmów na temat priorytetów, które mają też wymiar zabawy. Talię można przecież tasować, a jakaś kartę odrzucić. To dokładnie to samo, co stwierdzenie, żeby dane zadanie cofnąć do backloga, ale trochę inaczej ubrane. I właśnie to przebranie może sprawić, że praca nad grą stanie się bardziej atrakcyjna.

Ludzie po prostu muszą chcieć korzystać z takich narzędzi i nie mogą ich traktować jako formy zbędnej biurokracji. Codecks dobrze koncentruje uwagę na najważniejszych rzeczach, ale nie jest całkowicie pozbawione wad. Pomimo mnóstwa pożytecznych integracji, nie widzę sposobu na to, aby mogło się stać formą samodokumentującego się systemu.

Mam na myśli niezłą synergię jaką można wypracować łącząc zadania z Jiry z dokumentacją w Confluence. Tego Codecks nie ma. Jedyną drogą to stworzenia takiego powiązania, jest połączenie repozytorium opartym na Obsidiania i wiązanie identyfikatorów zadań (kart) z poszczególnymi commitami. Co niekoniecznie może być czytelne dla całego zespołu i budzi także moje wątpliwości w kwestii skalowania się Codecks. O ile widzę tutaj duży potencjał dla niezależnych twórców, to mam obawy co do płynności w działaniu tego narzędzia przy zespołach liczących więcej, niż 15 – 20 osób. Nie wiem, czy wtedy Codecks byłby w stanie znacząco usprawnić proces produkcyjny i czy wtedy nie lepiej oprzeć się na Notion lub Jirze.