Na blogu opisywaliśmy już koncepcję umowy serwisowej, gdzie przytaczaliśmy jej zalety oraz sytuacje, w jakich jest stosowana. Dla osób, które nie czytały poprzedniego tekstu na ten temat, a chciałyby mieć pełną wiedzę przed przystąpieniem do dalszej lektury niniejszego artykułu, chciałem najpierw krótko przypomnieć, czym jest taka "serwisówka".

A jest to rodzaj usługi świadczonej przez (między innymi) firmy IT, w której klient wykupuje abonament na określoną liczbę godzin na opiekę nad danym oprogramowaniem. Jest to dobre rozwiązanie, gdy utrzymujemy daną aplikację, dbamy o jej rozwój, poprawki i szukamy wykonawcy, który zapewni nam spokojną głowę przez dłuższy czas, podczas którego będziemy planować kolejne funkcje. W takim wypadku software house oferuje konkretny pakiet czasu na np. miesiąc, który zleceniodawca ma do dyspozycji na konsultacje, tworzenie nowych funkcji, korekty czy modyfikacje. W dodatku, ta usługa jest zwykle tańsza, gdy przeliczy się koszt za roboczogodzinę. Istnieje też możliwość przenoszenia niewykorzystanych godzin, a przynajmniej my, w Wilda Software, tak robimy.

Wiemy zatem, czym jest umowa serwisowa, więc możemy przejść do zarządzania nią. Wiele firm wykorzystuje do tego współdzielony arkusz kalkulacyjny, np. na Google Drive, w którym są odpowiednie rubryki i zarówno klient, jak i wykonawca mogą zobaczyć, jakie zadania zostały wycenione i czekają na decyzję, które są w trakcie, a także ile godzin pozostało do wykorzystania w danym okresie. Niestety, taka forma, mimo że wygodna, ma parę wad. Po pierwsze, wymaga sumiennego prowadzenia takiego pliku, co leży w interesie obu stron, ale może być dublowaniem pracy, gdyż zadania w zespole IT najczęściej są składowane w innym narzędziu. Po drugie, w zależności od klienta, bywa, że zgłoszenie następiło inną drogą, opis zmiany jest dostępny gdzieś indziej, a przesłana wycena jeszcze w innym miejscu - taka sytuacja sprawia, że utrzymywanie arkusza jest jeszcze trudniejsze. Po trzecie, nie ukrywajmy, że programiści, mimo że sumiennie pracują, nie zawsze mają łatwy dostęp do materiałów, a sami czasem zalegają z informacjami o wycenie bądź poświęconym czasie, przez co kierownik (odpowiedzialny za arkusz) musi mieć na to dodatkowe oko. Oczywiście, to wszystko jest szukaniem dziury w całym, ale nie da się ukryć, że widać, iż przydałoby się narzędzie, które ułatwi zarządzanie realizacją umowy serwisowej. Pierwotnie narzędzie do zarządzania zadaniami, z którego korzysta zespół IT, nie zawsze jest ku temu odpowiednie.

Na szczęście, mamy jeszcze Feedybacky'ego i jego nową funkcjonalność, która może ułatwić życie wielu software house'om.

Definiowanie i typy umów serwisowych w Feedybacky

W omawianym systemie pojawiła się możliwość definiowania i śledzenia umów serwisowych na podstawie zgłoszeń dodawanych do systemu. Do tego ostatniego jeszcze dzisiaj wrócimy, natomiast chciałbym omówić w tym tekście, w jaki sposób za pomocą naszego narzędzia można obsługiwać "serwisówki".

Wszystko zaczyna się na ekranie konfiguracji swojego projektu (lub dodawania nowego), gdzie pojawiła się nowa sekcja "Umowa serwisowa":

Standardowo tryb umowy nie jest wybrany (w pierszym polu jest "Brak") i wypełnienie kolejnych kontrolek nie jest wymagane. Jednak mamy także dwie opcje, które właczają nam funkcje do serwisowania i wpływają na metodę śledzenia godzin. Ich nazwy mogą wydawać się Wam znajome i rzeczywiście - te terminy omawialiśmy już w artykule o sposobach rozliczeń.

Fixed price w tym wypadku to klasyczne obliczanie sumy wycen, czyli jednego z pól, które jest dostępne do uzupełnienia przy okazji aktualizowania zgłoszenia. To, co jest istotne, to fakt, że w tym przypadku Feedybacky bierze pod uwagę wyłącznie zgłoszenia, których status należy do grupy "zrealizowane" lub "zakończone" (i uwzględniania jest data pierwszego ustawienia takiego statusu). Najczęściej jest bowiem tak, że praca jest rozliczana w okresie, w którym udało się ją wykonać i oddać klientowi choćby do testów. Dodatkowo, tryb realizacji zgłoszenia musi być ustawiony na "umowa serwisowa".

Time and materials z kolei, jak pamiętamy z tekstu, bierze pod uwagę faktycznie przepracowany czas nad zadaniem (kolejne pole dostępne podczas aktualizacji zgłoszenia) i w tym momencie nie ma znaczenia ani wycena, ani status zgłoszenia. Jest więc możliwe, że jeśli dane zadanie będzie realizowane przez dwa okresy rozliczeniowe (dwa miesiące), to część zostanie zaliczona na poczet pierwszego okresu, a reszta - drugiego. Także tutaj wymagane jest, aby zgłoszenie miało ustawiony tryb realizacji na "umowa serwisowa".

Niezależnie od wybranego trybu, włączenie umowy serwisowej pociąga za sobą również konieczność wprowadzenia:

• miesiąca, w którym umowa się rozpoczyna - jest to pole potrzebne przede wszystkim do obliczania godzin przeniesionych z jednego okresu rozliczeniowego na drugi, o ile będzie to pożądane.
• maksymalnej liczby godzin - czyli miesięcznego pakietu czasu, który obowiązuje dla danej umowy serwisowej.
• czy godziny będą przenoszone - tak, jak wspominaliśmy w poprzednim tekście o kontraktach, godziny niewykorzystane w jednym okresie mogą być dostępne do użycia w bezpośrednio następującym po nim drugim miesiącu. Feedybacky umożliwia włączenie tego.

Uzupełnianie i śledzenie danych

Tak, jak wspomniałem wyżej, przy okazji aktualizowania zgłoszeń mamy do wyboru kilka pól dotyczących trybu wykonywania zlecenia. Są one dostępne także w momencie, kiedy umowa serwisowa nie jest aktywna - dzięki temu Feedybacky może służyć do śledzenia czasu spędzonego nad projektem. Jednak usługa abonamentowa daje kolejne możliwości.

Przy zgłoszeniach mamy informację o tym, ile wynosiła wycena oraz jaka jest suma realnie przepracowanego czasu (wszystko w godzinach, jednak nie ma problemu, aby umówić się na zapisywanie w ten sposób minut). To, co jest istotne, to fakt, że co innego widzi kierownik, a co innego klient - na powyższych zrzutach ekranu widać perspektywę użytkownika o tej pierwszej roli. Musimy pamiętać, że klient zobaczy zazwyczaj tylko wynikową wycenę, jednak z małym wyjątkiem - jeżeli wybrany został tryb "time and materials", zamiast wyceny widoczna będzie wartość faktycznie przepracowana. Zobaczy zatem to, co faktycznie jest dla niego interesujące, natomiast kierownicy mogą traktować oba pola jako wewnętrzną kontrolę tego, jak bardzo rzeczywisty czas odbiega od szacowanego.

Warto zauważyć, że o ile wycena jest jedna dla zgłoszenia, o tyle przepracowany czas jest sumowany wraz z każdym komentarzem. Dzięki temu, realizując zadanie fragmentami, możemy też zapisywać poszczególne "sesje", które Feedybacky automatycznie dodaje do siebie. Możliwe jest także korygowanie czasu w ten sposób, poprzez wpisywanie wartości ujemnych, a w przypadku usunięcia komentarza - suma zostanie zrewidowana.

Podobne sumy pojawiają się na ekranie raportowym, dostępnym dla kierowników - tam również (tym razem po włączeniu jednego z trybów serwisowych) pojawi się dodatkowa kolumna z konkretną wartością wyceny lub przepracowanego czasu. Będzie on również dostępny w wyeksportowanych plikach CSV i TXT.

Śledzenie postępu realizacji umowy serwisowej

Na kilku ekranach (kokpicie, liście zgłoszeń, szczegółach danego zgłoszenia oraz raportu) Feedybacky oferuje małą tabelkę, która umożliwia zorientowanie się, jak wygląda realizacja umowy serwisowej w bieżącym miesiącu. Spójrzmy na przykład.

W międzyczasie zgłoszenia na łączną wycenę 40 godzin zostały zrealizowane i teraz widać jak na dłoni, że w danym okresie rozliczeniowym z założonych 50 godzin zostało do dyspozycji 10. System niczego nie blokuje w przypadku przekroczenia tej liczby - jest to jedynie informacja dla kierowników i klientów, na ile mogą sobie jeszcze pozwolić w danym miesiącu bez dodatkowych opłat. Pod tym względem specyficzny jest kokpit, który pokazuje dane dotyczące wielu projektów naraz - jak wygląda tabelka w tamtym miejscu?

Na tym ekranie widzimy wszystkie umowy serwisowe, w które jesteśmy zaangażowani, a dodatkowo ich postęp. Możemy też zobaczyć niezgodność - dla pierwszego projektu do wykorzystania w jednym okresie jest 30 godzin, a tymczasem do dyspozycji mamy aż 46. Jak to możliwe? To właśnie efekt przeniesienia godzin - w poprzednim miesiącu klient nie wykorzystał 16 przysługujących mu jednostek, dzięki czemu zostały one przetransferowane na ten miesiąc, w efekcie czego mamy 30 + 16 = 46 godzin. Te wartości są obliczane na bieżąco.

Trzecia forma dodawania zgłoszeń

Na koniec możecie zadać słuszne pytanie o wcześniej wspominane dodawanie zgłoszeń wymagających serwisu. Feedybacky jest systemem głównie dla działów wsparcia (czyli tzw. help desków czy supportów) i choć jest stosowany także do normalnej pracy, to słyszeliśmy już, że przy "standardowych" zgłoszeniach (nie z aplikacji webowych poprzez wtyczkę), mechanizm umieszczania ich w systemie może być nieco niewygodny i przydałby się taki zwyczajny, dostępny bezpośrednio w portalu.

I taki się w Feedybacky pojawił. Został stworzony na bazie FEF-a (Feedybacky Embedded Form) {https://feedybacky.com/fef-guide}, jednak pomiędzy tymi formularzami jest kilka ważnych różnic. Po pierwsze, FEF ma osobny adres, do którego należy mieć link, natomiast nowy formularz jest dostępny bezpośrednio w portalu, w menu po kliknięciu na ikonę w lewym górnym rogu. Po drugie, FEF dotyczy konkretnego projektu, natomiast nowe rozwiązanie posiada listę rozwijaną do wyboru miejsca, gdzie zgłoszenie ma zostać ulokowane. I po trzecie - ponieważ nowa forma zgłaszania uwag jest osadzona bezpośrednio w portalu i z natury służy do wiadomości na wyższym poziomie ogólności, nie ma potrzeby i sensu uzupełniania wielu informacji, które są potrzebne przy diagnozowaniu konkretnych zgłoszeń przesyłanych z aplikacji.

Dodatkowo, ostatnio badamy możliwość wykorzystywania Feedybacky'ego do dyskusji o projekcie z podziałem na wiele wątków. Do takiego zastosowania nowy formularz jest jak znalazł.

Podsumowanie

Jak widać, umowa serwisowa w projekcie jest dobrą koncepcją, ale należy zadbać o odpowiednie narzędzie do jej obsługi. Feedybacky zapewnia kompleksowe, a jednocześnie proste funkcje pozwalające zarządzać takim konktraktem. Na pewno jest to ciekawa alternatywa dla współdzielonych arkuszy kalkulacyjnych i myślę, że może z powodzeniem być wykorzystywane już tu i teraz.

Pozdrawiam i dziękuję - Jakub Rojek.