Zarządzanie zadaniami w jakimkolwiek projekcie IT jest chlebem powszednim i dlatego niektórym wydaje się, że jest proste. Ot, przydzielamy każdemu jakieś wymaganie, czasami nawet jedno jest realizowane przez parę osób i czekając na efekt, kontrolujemy postęp prac. Sytuacja komplikuje się, gdy zadań jest zbyt dużo lub po prostu planujemy sprint. Wówczas zadawane jest pytanie, które słyszał pewnie już każdy kierownik projektu, a mianowicie "co mam robić jako pierwsze?". Inaczej mówiąc, powstaje potrzeba przydzielenia priorytetów.

O tym, jak priorytety są ważne, przekonujemy się nie tylko pracując nad oprogramowaniem dla naszych klientów, ale także podczas rozmów dotyczących systemu Feedybacky. Dość częstą wątpliwością osób, które potem stają się użytkownikami naszej aplikacji, jest sposób sortowania zgłoszeń i wskazywania tych, które zasługują na szczególną uwagę lub powinny być realizowane w pierwszej kolejności. Dzisiaj właśnie na przykładzie Feedybacky'ego opowiem, w jaki sposób można zarządzać kolejnością wykonywania zadań.

Kto ustala priorytety?

Priorytety zadań zawsze powinien ustalać klient i jest to zrozumiałe ze względu na to, że ma on wiedzę biznesową, wizję swojego oprogramowania i wie, co jest w nim potrzebne w pierwszej kolejności. Natomiast, jak się pewnie spodziewacie, sprawa nie jest tak prosta, jak się wydaje.

Analitycy w software housie są osobami, którzy mają za zadanie poznać oczekiwania klienta, przeanalizować je i później pełnić rolę kogoś w rodzaju "proxy klienta". Oznacza to, że są dla zespołu IT człowiekiem na wyciągnięcie ręki, który ma wiedzę o tym, na czym może najbardziej zależeć zleceniodawcy pod kątem biznesowym. Tym samym odciążają go, a jednocześnie zapewniają programistom szybką informację. W mniejszych zespołach analityk nie jest osobną osobą - wówczas tę rolę przejmuje np. szef firmy, kierownik projektu lub główny programista.

Trzeba też wziąć pod uwagę specyfikację pracy zgodną z metodyką zwinną, w której w każdym sprincie powinno się dostarczać klientowi pewną wartość biznesową, czyli fragment oprogramowania, który pozwoli czerpać coraz to większe korzyści z całego przedsięwzięcia. Tutaj rola priorytetów jest bardzo ważna i dlatego zakres sprintu powinien być ustalany z klientem i konfontować jego oczekiwania z tym, ile czasu jest dostępne w danym etapie. Więcej pisaliśmy o tym w jednym z naszych poprzednich artykułów.

W przypadku etapu utrzymania, w którym dochodzą zgłoszenia np. od rzeczywistych użytkowników, rola klienta jest jeszcze większa - to on, będąc na pierwszej linii frontu, ma świadomość, z jakimi problemami najczęściej stykają się jego odbiorcy i co - zgodnie z zasadą Pareta - powinno być zrobione w pierwszej kolejności, aby zaspokoić większą część potrzeb. Oczywiście, sytuacja staje się prostsza w momencie, kiedy zgłoszeń nie ma dużo, bufor czasowy jest duży lub po prostu wszystko jest równie ważne. Tym niemniej, w dziale wsparcia jasne wskazania od klienta dotyczące kolejności wykonywania zgłoszeń sa na wagę złota.

Jak radzi sobie z tym Feedybacky?

FyBy jak najbardziej obsługuje priorytetyzowanie i to na czterech poziomach, które zostały opisane poniżej. Co więcej, wybieranie ich jest dość proste - wystarczy wejść w szczegóły danego zgłoszenia i zwyczajnie ustawić inną opcję (w prawym górnym rogu ekranu, pod przyciskiem "Aktualizuj"). Nie ma potrzeby zapisywania niczego ani wykonywania dodatkowych działań - tworząc i korzystając z Feedybacky'ego rozumiemy, że zmiana priorytetu może wymagać szybkiej reakcji i z tego powodu wybór opcji na liście rozwijanej od razu jest zapisywany w systemie.

A poziomy są następujące:

• wysoki - zgłoszenia o najwyższym priorytecie, które powinny być wykonywane w pierwszej kolejności i z tego powodu znajdują się na górze listy zgłoszeń. Ustawienie tego poziomu może wygenerować powiadomienie mailowe do wszystkich uczestników projektu, o ile mają ustawione otrzymywanie takich wiadomości.
• średni - domyślny priorytet zgłoszeń, które trafiają do systemu z wtyczki, FEF-a lub innymi drogami.
• niski - drobne poprawki estetyczne, które są ważne (tzn. trzeba je wykonać), jednak przegrywają w starciu z innymi zgłoszeniami. Realizowane są zwykle w ostatniej kolejności.
• nieistotny - ...lub prawie ostatniej, ponieważ mamy jeszcze poziom dla zgłoszeń, które są bardziej pytaniami lub pomysłami na przyszłość, ew. propozycjami, jednak bez większej szansy na wdrożenie. Jest to stopień, który może służyć np. do zapisywania koncepcji do rozważenia na później.

Tak, jak wspomniano wyżej, priorytety są istotne także z punktu widzenia sortowania listy zgłoszeń - nie tylko te o wyższym priorytecie trafiają na samą górę, aby wszystkie osoby z zespołu IT od razu je widziały, ale także zyskują odrębne kolory ułatwiające identyfikację. Na poniższym zrzucie ekranu możecie zobaczyć listę z dwoma zgłoszeniami o wysokim priorytecie, dwoma ze średnim i po jednym z niskim oraz nieistotnym.

Zadania o wysokim priorytecie mogą być rozdystrybuowane po wielu projektach w systemie i w takim wypadku czasami powstaje problem znany jako "nie mam co w rąk włożyć", a kierownik projektu nie zawsze jest dostępny. Dodatkowo, warto wziąć pod uwagę także to, ile dane zgłoszenie czeka na obsłużenie lub - odwrotnie - czy dyskusja o nim jest tak szybka, że wręcz przypomina rozmowę z konsultantem na żywo. Dlatego Feedybacky oferuje również ekran kokpitu, na którym możemy zobaczyć aktualną sytuację w naszych projektach - ostatnio aktualizowane zgłoszenia, te czekające najdłużej na reakcję, a także wybrane najbardziej priorytetowe.

Aby ułatwić klientowi szybkie dokonanie wyboru, czy dane zgłoszenie ma być traktowane priorytetowo, wtyczka od wersji 2.2 umożliwia włączenie odpowiedniej listy rozwijanej z dwiema opcjami (pole "priorityField"). Dlaczego tylko dwiema? Umówmy się - dla klienta zawsze wszystko jest istotne, a kwestie nieistotne... nie istnieją :)

Jak widać, Feedybacky pozwala dość szybko zorientować się w priorytecie poszczególnych zgłoszeń, o ile zarządzanie nimi jest prawidłowe. A można sobie jeszcze ułatwić pracę poprzez inny mechanizm.

SLA oraz pożary

Termin SLA (ang. Service Level Agreement) jest terminem najczęściej wykorzystywanym w umowach obejmujących serwisowanie i w działach wsparcia (help desk). W ogólności wskazuje on maksymalny czas reakcji i odpowiedzi na zgłoszenia serwisowe o danym poziomie priorytetu. Jest to zobowiązanie firmy wykonawczej (np. z sektora IT), które pozwala klientowi mieć pewność, że reakcja będzie odpowiednio szybka. Oczywiście, wiąże się z przyjęciem na siebie odpowiedzialności, co ma swoje odwzierciedlenie w innych punktach umowy, jednak nas w tym tekście najbardziej będzie interesowało to, że SLA może ułatwiać wybór zgłoszeń do obsłużenia w danej chwili.

W systemie możemy definiować czas reakcji dla danego priorytetu na ekranie konfiguracji tego projektu - w tym celu kierownik powinien wybrać odpowiednią opcję na liście projektów lub zgłoszeń.

Co daje nam konfiguracja tych pozycji? Wówczas zbliżanie się lub przekroczenie czasu reakcji na zgłoszenie o danym priorytecie zostanie odwzierciedlone odpowiednimi ikonkami na liście zgłoszeń, ekranie szczegółów zlecenia oraz w kokpicie. Te dwie ikony to płomień (czas się zbliża) lub gaśnica (został przekroczony). Jest to żartobliwe nawiązanie do potocznego określenia, że w jakimś projekcie praca się pali lub wręcz pojawił się pożar, a więc potrzebna jest szybka reakcja na coś, co może wywołać zdenerwowanie klienta.

Warto zauważyć, że czas przekroczenia jest liczony nie tylko od momentu pojawienia się samego zgłoszenia, ale też ostatniej odpowiedzi drugiej strony. Oznacza bowiem czas reakcji - czasami, mimo wielu dodatkowych informacji, zespół IT potrzebuje innych, bardziej szczegółowych i dopiero po ich uzyskaniu może dalej "gasić pożar".

Możliwości rozwoju tej funkcjonalności są cały czas badane przez nas i bardzo możliwe, że będą rozwijane w przyszłości, aby nadążyć za sytuacjami, które mają miejsce w rzeczywistości.

Podsumowanie

Ustalanie jasnych dla wszystkich priorytetów jest istotne w każdym projekcie IT i dostępne praktycznie we wszystkich narzędziach do zarządzania zadaniami. Feedybacky nie jest tu wyjątkiem, a dodatkowo pozwala lepiej zarządzać zgłoszeniami wymagającymi szczególnej uwagi lub zbyt długo czekającymi na odpowiedź. Natomiast warto pamiętać, że niezależnie od używanej aplikacji, najważniejszym źródłem priorytetów jest klient, a w drugiej kolejności - jego "proxy" w postaci analityka w zespole IT.

Na koniec życzę Wam tego, aby żadne zgłoszenie w Waszych projektach nie weszło nigdy w fazę "pożar, pali się!".

Pozdrawiam i dziękuję - Jakub Rojek.