Przez kilka pierwszych lat swojego istnienia w PSI, JIRA była używana prawie wyłącznie jako tzw. "issue tracker". Oznaczało to, że niemal wszystkie zadania, które trafiały do systemu były zgłoszeniami dotyczącymi wsparcia klientów. Wywołało to pewną dwoistość w przydziale pracy - zadania od klientów trafiały do JIRA, natomiast regularne prace projektowe (a także inne zadania np. prace wewnętrzne, zakupy itd.) znajdowały się w bardzo różnych miejscach.  W tym samym czasie zaczęliśmy realizować coraz bardziej skomplikowane projekty wymagające precyzyjnego podziału pracy i dokładniejszego śledzenia kosztów i pojawiających się problemow. Jako, że posiadaliśmy już system do komercyjnego zarządzania projektami, prace programistyczno / konsultanckie były po prostu raportowane na pozycje kosztowe takie jak "Programowanie", "Testy" itd. Wprowadzało to trudności w planowaniu prac, ocenie ryzyka przyszłych przedsięwzięć, a także prostym stwierdzeniu, czym się aktualnie zajmujemy.

W międzyczasie Atlassian znacząco rozwinął swój produkt - nawet w stopce na każdej stronie zamiast "Issue Tracker" pojawiło się "Project Management". Nowe funkcjonalności, takie jak wyszukiwanie za pomocą języka JQL, tablice Agile, czy tworzenie własnych widoków (tzw. Dashboards) spowodowały, że zaczęliśmy się zastanawiać nad rozszerzeniem zakresu jej użycia w PSI. W ten sposób rozpoczął się proces, który trwa do dzisiaj.

Najpierw narzędzie, czy najpierw procesy?

To było pierwsze pytanie, które padło, gdy ogłoszono plan kompleksowego wdrożenia JIRA w PSI Polska, a następnie w całej Grupie PSI. Jest to pytanie, które pada w każdej większej organizacji próbującej "wyciągnąć się za włosy z bagna". Narzędzie bez opisanego procesu wprowadza często tylko dodatkową złożoność, nikomu nie pomagając. Niestety, nawet najlepiej opisany proces może być jednak zupełnie martwy, jeśli jego wykonanie wymaga od użytkowniczek i użytkowników wielu czasochłonnych czynności. Dlatego też, godząc się z ryzykiem odrzucenia narzędzia, bądź jego niepoprawnej konfiguracji, podjęliśmy decyzję o jego wdrożeniu, a następnie optymalizacji pod kątem faktycznych procesów naszej organizacji. Aby zmniejszyć to ryzyko, zaczęliśmy od kilku najprostszych procesów, stopniowo dochodząc do tych najbardziej skomplikowanych i wymagających największych zmian.

Where do I start, where do I begin, czyli kolejność działania

Zarządzanie wewnętrznymi systemami PSI Polska

Mając już wszystkich użytkowników "na platformie", a także przygotowując się do wdrożenia kolejnych procesów, chcieliśmy, aby samo ich wdrożenie, a także niezbędne modyfikacje JIRA oraz innych systemów były maksymalnie transparentne dla wszystkich. Oprócz tego zależało nam na współudziale całej firmy w tym procesie. Dlatego też, kolejnym krokiem było stworzenie projektów JIRA obrazujących rozwój naszych wewnętrznych systemów oraz użycie tablic Agile w celu prostej wizualizacji postępów prac nad konkretnymi funkcjonalnościami. Dzięki temu pracownicy uzyskali wgląd (i wpływ) na zmiany w firmie. Drugim efektem było wdrożenie zarządzania zorientowanego na produkt dla wszystkich naszych wewnętrznych systemów - było to doskonałe ćwiczenie przed kolejnym krokiem.

Zarządzanie produktami dla Grupy PSI

Kilkumiesięczne doświadczenie z zarządzania wewnętrznymi systemami PSI jako produktami za pomocą JIRA dało nam spory zastrzyk wiedzy, którą postanowiliśmy produktywnie wykorzystać wychodząc szerokim frontem do całej Grupy PSI. Jednym z produktów wykorzystywanych przez całą Grupę PSI będącym w gestii polskiego oddziału jest PSI Java Framework, czyli platforma programistyczna, na której bazują wszystkie nasze produkty wdrażane przez jednostki Grupy na całym świecie. Wiosną 2015 roku zaprezentowaliśmy rozwiązanie o nazwie PJF Backlog, które było pierwszym w historii Grupy całościowym podejściem do rozwoju produktu za pomocą JIRA. Od tej chwili, każde wymagania zgłoszone do platformy musiało się tam znaleźć. Szczegóły rozwiązania znajdziecie w notatce poświęconej PJF Backlog. Zysków z tego wdrożenia było bardzo wiele, natomiast w kontekście niniejszego artykułu najważniejsze było rozpropagowanie rozwiązania w całej Grupie PSI. Dzięki PJF Backlog pracownicy z całego świata mogli się na żywo przekonać, że zarządzanie produktem za pomocą JIRA jest możliwe (i całkiem proste).

Zarządzanie testami

Mniej więcej w tym samym czasie w Grupie PSI pojawiła się inicjatywa wdrożenia nowoczesnego narzędzia do zarządzania procesem testowania systemów PSI i ich możliwego połączenia z wymaganiami (kto nie wypełniał Requirements Traceability Matrix, nie zna życia!). Powstał dość szczegółowy katalog wymagań dla tego systemu i kiedy nadszedł moment wyboru systemu je spełniającego, okazało się, że JIRA w odpowiedniej konfiguracji jest w stanie je spełnić. Rozpoczęliśmy więc projekt o nazwie PSIrmtm (PSI Requirements and Test Management), którego celem było dostosowanie JIRA do zarządzania procesem testowania, a także przechowywania katalogów testów dla naszych produktów w standardowej konfiguracji. Okazało się to skomplikowanym przedsięwzięciem, dość jednak powiedzieć, że obecnie najwięksi klienci PSI przeprowadzają testy wspólnie z nami w JIRA, a specyfikacje testów w Excelu odeszły na zasłużoną emeryturę. Jako, że JIRA niemalże od początku swojego istnienia w PSI była już znana naszym klientom, dzięki wdrożeniu tego procesu oni także przekonali się, że można za jej pomocą osiągnąć o wiele więcej niż tylko proste zgłaszanie błędów do poprawy w ramach wsparcia.

Zarządzanie zadaniami w projektach klienckich

Po 2 latach automatyzacji kolejnych procesów oraz przekonywania klientów i użytkowników zarówno z Polski, jak i innych krajów mieliśmy już odpowiednią wiedzę i pozycję, aby wrócić do naszego oryginalnego celu. Od lata 2015 roku zaczęliśmy konsekwentnie dodawać wszystkie zadania projektowe, zarówno te "merytoryczne", czyli np. utworzenie nowego widoku w naszym systemie, czy też "organizacyjne" jak spotkania projektowe do JIRA. Wymagało to kompleksowego przeszkolenia wszystkich pracowników firmy, a także przygotowania własnej, zorientowanej na potrzeby PSI dokumentacji. Ponadto, pojawił się tu ważny aspekt zmiany sposobu myślenia o pracach projektowych - z orientacji na pozycje kosztowe na podział na niewielkie, dające się opisać zadania. Oczywiście nie obyło się bez problemów - dobranie odpowiedniej struktury zadań, czy grafu stanów (workflow), a także zbioru widocznych pól zajęło nam bardzo wiele czasu, a obiekty te optymalizujemy do dzisiaj. Dzięki przejrzystemu zarządzaniu JIRA jako produktem (patrz wyżej), a także wielu godzinach poświęconych na wsparcie i odpowiadanie na pytania, udało się jednak uzyskać zbiór konfiguracji uwzględnia-jący różne wielkości projektów, typy produktów i rodzaje współpracy z naszymi klientami. Obecnie, jedną z pierwszych aktywności realizowanych w projekcie jest szkolenie z JIRA dla pracowników klienta.

Logowanie czasu pracy

Kiedy udało się umieścić cały zakres pracy projektowej (i nie tylko) w JIRA, szybko okazało się, że system zawiera tylko połowę prawdy. Patrząc na JIRA byliśmy w stanie oszacować merytoryczny postęp prac, lecz niestety był on w tym momencie zupełnie oderwany od postępu kosztowego. Prowadziło to do sytuacji, gdy pracownicy musieli ręcznie wpisywać nazwy zadań z JIRA w naszym systemie do komercyjnego zarządzania projektami i podawać tam liczbę godzin spędzonych nad nimi. W kontekście szybkiego wzrostu liczby zadań stało się to nieznośnym i wrażliwym na błędy obowiązkiem, który nie spotkał się z zadowoleniem zespołów. Postanowiliśmy, że dla tego przypadku musimy przygotować rozwiązanie idealnie skrojone pod nasze potrzeby. Niewiele myśląc, zasiedliśmy do klawiatur i stworzyliśmy własne rozszerzenie do JIRA, które automatycznie przenosi godziny zalogowane na konkretne zadanie w JIRA do odpowiadającej mu pozycji kosztowej, po drodze poddając wpisy drobiazgowej walidacji (pamiętajmy, że są to godziny płatne przez naszych klientów, a także istotne w kontekście Prawa Pracy). Po wdrożeniu tego rozwiązania, programistka lub konsultant musi jedynie zalogować godziny w JIRA, a cała "maszyneria administracyjna" działa w tle i nie wymaga żadnej interakcji. W międzyczasie rozbudowaliśmy nasz system do komercyjnego zarządzania projektami tak, aby możliwe było wystawianie faktur na podstawie wpisów użytkowników - dzięki temu jesteśmy gotowi wystawiać faktury za nawet najbardziej skomplikowane projekty już pierwszego dnia roboczego następnego miesiąca.

Zakupy "biurowe" i marketing

Po przejściu tak wielkiego kroku, kolejne wydawały się już "wisienkami na torcie". Jednego dnia po prostu padło pytanie: "dlaczego bilety lotnicze dalej zamawiamy mailem?". W sumie nikt już nie pamiętał dlaczego - postanowiliśmy zatem to od razu zmienić. Okazało się przy tym, że tak prosta funkcjonalność JIRA jak przypisanie zadania innej osobie chroni nas przed często sporymi kosztami; jeśli na przykład zamówienie biletu lotniczego zostało wysłane mailem do asystentki, która była akurat chora, a osoba zamawiająca nie wiedziała o tym, kilkudniowe opóźnienie powodowało konieczność zakupu biletu po znacznie wyższej cenie. Podobnie miała się rzecz dla materiałów marketingowych - projekty ulotek czy artykułów takich, jak ten krążyły po serwerach plików i skrzynkach mailowych bez prostej informacji jaki jest ich status i kto jest za nie odpowiedzialny. Takie sytuacje są już historią. Teraz wszystkie projekty marketingowe są realizowane z wykorzystaniem JIRA, która pomaga w podziale zadań oraz wymianie informacji.

HR - rekrutacja i on/off-boarding

Ostatnim obszarem naszej firmy nieobjętym JIRA był dział HR. W tym przypadku wynikało to częściowo z nieznajomości narzędzia, a częściowo z istnienia wcześniej innych rozwiązań (np. systemu do zarządzania kandydatami). W pokonaniu tej bariery pomogły nam (o dziwo!) wymagania formalnoprawne, to jest wejście w życie RODO oraz wdrożenie w Grupie PSI Systemu Zarządzania Bezpieczeństwem Informacji (ISMS). Wejście w życie RODO wymusiło wdrożenie jednej, niepodzielnej i dobrze chronionej bazy kandydatek i kandydatów z regulowanym dostępem. JIRA, dzięki rozbudowanemu systemowi uprawnień, a także konfigurowalnemu zestawowi pól umożliwiła przechowywanie danych w jednym miejscu zgodnie z wymaganiami nowego Rozporządzenia. Wdrożenie ISMS spowodowało natomiast konieczność bardziej rygorystycznego zarządzania dostępami pracowników do zasobów PSI. Nie poprzestając jednak tylko na aspektach związanych z bezpieczeństwem, zbudowaliśmy specjalną konfigurację JIRA, która umożliwia śledzenie przyjścia, odejścia, czy zmiany działu przez pracownika. Lista niezbędnych aktywności do wykonania przy tych wydarzeniach jest generowana automatycznie i przypisywana odpowiednim osobom (HR, IT, Księgowość, Sekretariat itd.). Dzięki temu, możemy być pewni, że każdy nowy pracownik otrzyma wszelkie informacje i kody dostępowe niezbędne do swojej pracy, a przy odejściu zostaną one odebrane lub zablokowane w sposób nie pozostawiający żadnych wątpliwości.

I'm the law, czyli kto za tym stoi

Jak widać, kompleksowe wdrożenie JIRA w PSI Polska i Grupie PSI to wieloletni proces, który wymaga zmian na wielu płaszczyznach działania organizacji. Aby to było możliwe, odpowiedzialność za nie musi być w rękach osób, które mają zarówno wiedzę techniczną umożliwiającą zaprojektowanie efektywnego rozwiązania, ale także (a może przede wszystkim) szerokie kompetencje w zakresie procesów organizacji oraz "moc sprawczą" ewentualnej ich zmiany. Dlatego też w PSI Polska zdecydowaliśmy, że właścicielem produktu JIRA jest Zespół Zarządzania Jakością ze wsparciem Działu Projektów Wewnętrznych. Ma on za zadanie łączyć obie te kompetencje, a ponadto, jako, że odpowiada także za definiowanie procesów i procedur przedsiębiorstwa i ich zgodność z zasadami Grupy, normami międzynarodowymi i przepisami prawa, może bezpośrednio wpłynąć na sposób pracy w firmie. Oczywiście organizacja taka wymaga znaczącego poszerzenia wiedzy technicznej wśród członków zespołu, ale jest naszym zdaniem znacznie efektywniejsza od pozostawienia tej odpowiedzialności jedynie "technicznemu" administratorowi.

Nie zgubić się w liczbach, czyli JIRA jako system informacji biznesowej

Automatyzując kolejne procesy w JIRA staraliśmy się nie kierować wyłącznie metrykami, które dostarcza sam system. Dopiero po migracji danego procesu na JIRA i zebraniu pewnej ilości danych (np. przypadków testowych, wymagań produktowych, zadań Helpdesku IT) staraliśmy się dobrać techniki raportowania odpowiednie dla danego przypadku. Dlatego też do każdego z opisanych powyżej zakresów działalności naszej firmy stworzyliśmy specyficzny zestaw narzędzi, które pozwalają ocenić efektywność danego procesu oraz ewentualne problemy. Przykładowo, dla projektów korzystamy szeroko z raportów dostarczanych przez tablice Scrum takich jak Burndown Chart, czy Epic Report. Dla produktów oraz wsparcia lepiej sprawdzają się narzędzia powiązane z tablicami Kanban - odpowiednio Cumulative Flow Chart oraz Control Chart. Dla Działu HR wystarczy natomiast prosta subskrypcja na filtr, która pokazuje kandydatów, z którymi musimy skontaktować się w danym miesiącu.

Co dalej?

Wielka integracja. Obecnie, każda jednostka PSI posiada osobny serwer JIRA - kiedy ta konfiguracja powstawała, istotne było, aby każda jednostka mogła dowolnie kształtować procesy odpowiednio do swojego biznesu. Wyzwania globalizacji oraz częsta współpraca między jednostkami PSI w projektach, a także coraz częstsze życzenia klientów w zakresie integracji, powodują jednak, że konfiguracja ta staje się coraz trudniejsza w utrzymaniu. W związku z tym obecnie pracujemy nad koncepcją integracji różnych serwerów JIRA w Grupie PSI. Wyniki nie są jeszcze godne publikacji, ale pracy dla zespołu znajdzie się na pewno wiele.

Zarządzanie wiedzą. JIRA sprawdza się świetnie do opisu zadań wykonywanych przez zespoły. Niestety, przy ich coraz większej ilości często jest tak, że wiedza wykraczająca poza pojedyncze zadanie może "przeciekać nam przez palce". Z tego względu zdecydowaliśmy się na wdrożenie w całej Grupie PSI jednej platformy zarządzania wiedzą - Confluence, na której tego rodzaju informacje mogą być przechowywane i w prosty sposób przechowywane. Teraz, czeka nas integracja tego systemu z JIRA - testowe wdrożenie dla jednego serwera już pokazało potencjał tej integracji, także spodziewajcie się kolejnych artykułów wkrótce!