Po 30 wywiadach z praktykami projektów ekstremalnych zaczęła zapełniać mi się lista narzędzi, które są stosowane w takich projektach. I często słyszę o wielu z nich po raz pierwszy. Inne, mimo, że znane, natomiast są wykorzystywane w nietypowy sposób.
Poniżej zamieszczam listę narzędzi wspierających zarządzanie projektami bardzo zmiennymi i ryzykownymi, który stosują przedstawiciele uczelni, startupów, agencji reklamowych, korporacji, czy zespołów studenckich.
Przy okazji mam roboczy tytuł nowej książki Bardziej niż Agile. Co sądzicie?
Narzędzia podzieliłem na kilka grup:
Wizualizacja zadań
- Active Collab
- Trello
- Jira
- Excel
- Asana
- Kanban Board
- MS Project
W tej grupie dominują tablice zadań. Czasem, gdy projekt jest nadzorowany, bo instytucja finansująca projekt chce kontrolować budżet, w stylu kaskadowym pojawia się Gantt albo WBS, ale na to wskazywało bardzo niewielu rozmówców.
Bardzo często jednak w ogóle nie było listy zadań, a członkowie zespołu werbalnie omawiali swoje bieżące prace. Takiemu podejściu sprzyja to, że zespoły w ekstremalnych projektach są bardzo małe, zwykle od 2 do 6 osób.
Repozytorium dokumentacji
- Azure devops
- Github
- Google Drive
- Jupyter
- Google Colab
- Notion
- Nuclino
- Lab Archive
Tutaj z ciekawostek pojawiają się trochę bardziej inteligentne notatniki oferujące dostęp w chmurze. Przykładem takim jest Google Collab, który pozwala na wplatania kawałków kodu w treść dokumentacji i płynne uruchamianie go. Wspaniała sprawa przy projektach eksploracyjnych z obszaru oprogramowania. Podobne funkcje oferuje Jupyter , czyli wspólne tworzenie kodu i jego dokumentowanie.
Praca kreatywna
- Figma
- Xmind
- Jamboard
- Miro
Ostatnio na rynku pojawiło się wiele narzędzi działających na tej zasadzie, że na wspólną tablicę wchodzi wielu ludzi i równolegle tworzą na niej notatki, wstawiają obrazki, dyskutują, rysują itd. Zamiast tablicy może to być pająk przedstawiający mapę myśli. Ciekawe jest wykorzystanie przez agencję reklamową Figmy, narzędzia do makiet ekranów, w roli komunikatora z klientem. Za pomocą Figmy uzgadniane są wymagania i zatwierdzane są kolejne wersje powstającego dzieła.
Notion jest dla mnie dużą niespodzianką. Zgrabny notatnik z lista dyskusyjną, kalendarzem, tablicą zadań i paroma innymi funkcjami.
Komunikacja w zespole lub z klientem
- Discord
- Teams
- Slack
- Facebook Messenger
Wiele zespołów pracując zdalnie, ale i, moje zaskoczenie, stacjonarnie stosuje narzędzia do rozmawiania synchronicznego.
Czego nadal mi brakuje
Gromadzenie wiedzy wciąż jest obszarem, który słabo działa. Szczególnie przekazywanie wiedzy między projektami lub między ludźmi, którzy dotąd ze sobą nie współpracowali i nie mieli szansy porozmawiać. Jeżeli wiedzę da się ustrukturalizować, to częściowo tą lukę wypełniał mi arkusz kalkulacyjny. W innej firmie ten obszar jest obsługiwany przez publiczny dysk z raportami statusu z projektów. Jednak to ciągle za mało. Dzielenie się wiedzą i jej akumulacja jest krytyczna w każdej innowacyjnej organizacji, a nie działa to efektywnie. Kilka lat temu pojawiła się kategoria rozwiązań nazywany Electronic Notebook, inspirowanych Wikipedią, ale to ciągle nie zaspokaja wszystkich potrzeb. Szczególnie brakuje mi pokazania ustrukturalizowania wiedzy i niewiedzy przez pokazanie drzewa hipotez i luk wiedzy.
Przejście miedzy zakresem ustrukturalizowanym a zwinnym. Parokrotnie w projektach ekstremalnych pojawia się potrzeba przejścia z filozofii kaskadowej na zwinną. Na wejściu jest budżet lub uporządkowane procesy, a na wyjściu eksploracja nowego terenu. Z perspektywy zarządzania zakresem narzędzia informatyczne albo oferują coś w rodzaju backlogu lub listy ticketów, albo WBS, do którego dopina się harmonogram i budżet. W drugą stronę czasem projekt zaczyna się zwinnie, ale w trakcie kolejnych miesięcy stabilizuje się i strukturalizuje i można przejść do bardziej kaskadowego zarządzania. Nie znajduję narzędzia, które łączyłoby te dwa światy.
Planowanie i kontrola czasu w ultrazwinnym środowisku. Niemal regułą jest, że sprinty w ekstremalnych projektach mają zmienną długość trwania. Jeden może trwać trzy godziny, a drugi dwa tygodnie. Techniki kontroli w agile opierają się na pomiarze tempa przepływu zadań i porównywaniu tego tempa w różnych sprintach. Jeżeli każdy sprint trwa tyle samo, to możemy porównać, jak dużo udało się zrobić w poprzednim, a jak dużo w bieżącym. I na tej podstawie wyciągamy wnioski. Jednak w ekstremalnych projektach szacowanie czasu jest obarczone olbrzymim błędem a sprintów nie da się porównać. Jak w takiej sytuacji kontrolować produktywność? Brakuje i metod i narzędzi, które to wspierałyby.