Czytelnicy zaglądający na ten blog od dłuższego czasu pamiętają pewnie, że dość często pisaliśmy o naszym autorskim systemie, Feedybacky, służącym do zarządzania zgłoszeniami serwisowymi i gwarancyjnymi, głównie w projektach programistycznych. Prawda jest taka, że od pewnego czasu rzeczywiście nie dawaliśmy znać, co się dzieje w tym obszarze - wpływ na to miały inne tematy komercyjne, a także fakt, że nie wszystkie zmiany są warte publicznego omawiania, gdyż mają bardziej znaczenie dla wewnętrznych struktur oprogramowania aniżeli funkcji dostępnych dla użytkowników. Nie zmienia to faktu, że czuliśmy się z tym trochę źle, zwłaszcza, że FyBy jak najbardziej jest wykorzystywany w praktyce i sprawdza się w przedsięwzięciach, w których został wdrożony.

Z tym większą przyjemnością wracamy dzisiaj do tematu i ponieważ w ostatnich miesiącach w projekcie działo się dość sporo, możemy to dzisiaj omówić i jednocześnie przedstawić aktualny status prac. Będziemy odnosić się przede wszystkim do samej aplikacji, dostępnej pod adresem Feedybacky.com i faktu, że system stał się potrzebny nie tylko przy obsłudze zgłoszeń, ale też całych projektów IT.

Skąd te zmiany?

Bardziej dociekliwi mogą zapytać "skąd pomysł na takie zmiany?", marudy zapytają "po co?", a malkontenci "dlaczego dopiero teraz?". Jeśli czytaliście o naszym stosie technologicznym, to być może pamiętacie, że do zarządzania samymi zadaniami stosujemy Redmine'a, a więc otwarte i samodzielnie instalowane oprogramowanie, które, co prawda, w ostatnich latach straciło nieco na znaczeniu, ale nadal jest rozwijane i personalnie pasuje nam bardziej niż np. Jira. Etapy i wymagania większości projektów rozpisane są właśnie tam, jednak w tych przedsięwzięciach, które są już po pierwszych wydaniach i użytkownicy w nich działają oraz zgłaszają uwagi, następuje pewien dualizm - zadania pojawiają się zarówno w Redminie, jak i Feedybacky. Co więcej, istnieje dodatkowa potrzeba przechowywania materiałów (w tym wycen) oraz zarządzania nimi. To czasem powoduje konieczność zaangażowania innych narzędzi, nawet tak podstawowych jak współdzielone arkusza kalkulacyjne. A żeby tego było mało, poszczególni klienci mają również swoje przyzwyczajenia i wymogi dotyczące przekazywania zakresu prac w danych momentach. To oznacza, że bywały projekty wykorzystujące nawet po pięć systemów to pozornie podobnych czynności.

Mówiąc wprost, zaczęło nas to męczyć i przeszkadzać w pracy.

Zorganizowaliśmy serię wewnętrznych spotkań oraz warsztatów, podczas których członkowie zespołu (a zdecydowana większość korzysta z Feedybacky'ego) mogli wyrazić swoje zdanie i dostać pole do dyskusji na temat dalszych prac. Wiadomo bowiem było, że FyBy musi się rozwijać, jak zresztą prawie każde oprogramowanie. Pytanie jednak dotyczyło tego, które funkcje są najbardziej priorytetowe, biorąc pod uwagę aktualne potrzeby. A kto jest ich lepszym źródłem niż osoby, które korzystają z systemu najwięcej, czyli programiści oraz członkowie linii wsparcia? Oczywiście, także klienci, a więc użytkownicy aktywnie korzystający z Feedybacky'ego, którzy również zostali włączeni do dyskusji i dostarczyli bardzo ciekawych informacji.

Na tej bazie została przygotowana lista modyfikacji oraz nowych funkcji, a także wyznaczone priorytety, które mają przybliżyć nas do jednego - ograniczenia innych systemów na rzecz jednego, którym będzie FyBy. Nie oznacza to, że ten system może zastąpić wszystko, gdyż dobrze wiemy o tym, iż nie zawsze jest sens, a jedna aplikacja do wszystkiego jest do niczego. Tym niemniej, nawet nie będąc uczestnikiem wewnętrznych dysput, stosunkowo łatwo można zaproponować zmiany, które uczynią z Feedybacky'ego nie tylko system dla help desku, ale także do codziennej pracy. Niektóre zmiany są małe i stosunkowo szybkie do wprowadzenia, a inne wymagają miesięcy wytężonej pracy. Zaplanowaliśmy te modyfikacje i właśnie pierwszymi efektami chcielibyśmy się z Wami podzielić oraz wysłuchać Waszych uwag, a także... odkryć trochę kuchni. Nie każda zmiana jest ważna z punktu widzenia funkcjonalności - niektóre mają bardziej zademonstrować sposób myślenia i w ten sposób uczyć. A my lubimy uczyć.

Trzeci sposób dodawania zgłoszeń na FyBy

Zaczynamy od czegoś prostego i oczywistego, a co już jest w systemie od dłuższego czasu, aczkolwiek nie było wcześniej okazji o tym napisać. Do pewnego momentu Feedybacky oferował dwie drogi dodawania zgłoszeń: przez wtyczkę zamieszczoną w aplikacji klienta oraz wstrzykiwalny zewnętrzny formularz Feedybacky Embedded Form. W przypadku zagadnień helpdeskowych są to wystarczające metody, jednak czas pokazał, że trudno się obyć bez ścieżki, która wydaje się naturalna, a jednak jej brakowało - zwykły formularz w samym Feedybacky.

Jeśli system jest wykorzystywany jako centralne miejsce do zadań, to siłą rzeczy musi umożliwiać łatwe dodawanie tych zadań. Należy wziąć przy tym pod uwagę fakt, że czasem chcemy to zrobić bezpośrednio z poziomu jakiegoś projektu, a czasem jeszcze nie wiedząc, do czego chcemy dane zagadnienie przypisać. Sam formularz jest dosyć podobny do wcześniej wspomnianego FEFa (którego zresztą też czekają zmiany, choć bardziej techniczne) i umożliwia także natychmiastowe dodanie wyceny czy przypisanie kategorii (do których jeszcze dzisiaj dojdziemy).

Grupowa aktualizacja zmian

Zanim wynik danego sprintu czy po prostu zlecona praca zostaną oddane klientowi, musi przejść przez proces weryfikacyjny. Siłą rzeczy, nie musi, ale jest on wskazany, gdyż może ujawnić pewne niedoróbki, które powinny zostać poprawione zanim oprogramowanie znajdzie się w rękach prawdziwych użytkowników. Czasem tych zgłoszonych pozycji jest na tyle dużo, że nie traktuje się ich pojedynczo, tylko poprawia masowo i równie masowo się je aktualizuje.

I tutaj wyszła potęga dyskusji, gdyż część zespołu w ten sposób nie pracowała, w związku z czym nie doświadczała tego, z czym miała do czynienia druga grupa. A ona ekstremalnie irytowała się faktem, iż chcąc oznaczyć 10-20 zagadnień jako "gotowe do wdrożenia" i nie chcąc dodawać żadnego konkretnego komentarza, musiała klikać każde osobno. W związku z tym pojawił się później zrealizowany pomysł grupowej aktualizacji statusow.

Osoby korzystające z Feedybacky pewnie zauważyły checkboxy po lewej stronie na liście zgłoszeń - ich zaznaczenie oraz wybranie docelowego statusu natychmiast wprowadza zmianę dla wszystkich. Jak najbardziej współgra to z raportami oraz innymi mechanizmami pozwalającymi porządkować i monitorować zgłoszenia, a przy wdrożeniach, gdzie wiemy, co właśnie wprowadziliśmy na serwer, ta droga jest znacznie szybsza.

Zmiany na liście

Będąc już na samej liście zgłoszeń, przeszła ona transformację. Na razie małą, ale możemy zdradzić Wam, że w dalekiej perspektywie mamy w planach dużo większe modyfikacje.

Przede wszystkim wysłuchanie głosu użytkowników przyniosło jeden ciekawy wniosek - nikt (albo prawie nikt) nie korzysta z wykresu, który jest położony po prawej stronie. Mówiąc wprost, jest on dość nieużyteczny w obecnej formie i o ile bywają sytuacje, w których chcielibyśmy graficznie zobaczyć rozkład grup statusów, to nie jest to regularna aktywność. Diagram mógł wręcz mylić użytkownika, gdyż pierwotnie pod uwagę brał całą historię projektu. Jednocześnie, potrzebne były dodatkowe informacje w samej tabeli. W związku z tym:

• domyślnie wykres został ukryty, choć można go odkryć,
• przy zakrytym wykresie, na liście pojawia się kolumna z przypisanymi osobami (do czego jeszcze dzisiaj przejdziemy),
• wielkość fontu w nagłówkach została nieco zmniejszona, podobnie jak odstępy.

Ale to nie wszystko - z racji tego, że pojawiły się kategorie, a także nowe filtry (np. po komentarzach, właśnie kategoriach, przypisanych osobach), to kontrolki zostały przearanżowane według tego, co jest wykorzystywane najczęściej. Dodatkowo, zostały poprawione ikonki w filtrach i na liście. A żeby tego było mało, to mechanizm zapamiętywania filtrów działa dla każdego projektu z osobna. To powinno ułatwić poruszanie się po różnych przedsięwzięciach.

Kategorie

Jedną z częściej podnoszonych kwestii w Feedybacky jest brak hierarchii zgłoszeń, co ponownie wynika z helpdeskowego rodowodu, zgodnie z którym wpisy są wprowadzane spontanicznie i każde jest traktowane pojedynczo. To z kolei może być ograniczające w przypadku, kiedy przechowujemy informacje o zadaniach w jakimś kontekście, np. pojedynczego sprintu - w takim wypadku większość osób wyobraża sobie hierarchiczne zarządzanie zgłoszeniami. Jednak należy pamiętać, że taka funkcja jest dużo większym fragmentem do realizacji niż wielu podejrzewa, zwłaszcza jeśli weźmiemy pod uwagę interfejs, wyświetlanie czy uprawnienia. Nie oznacza to, iż FyBy takiej funkcji nie uzyska, gdyż z dużym prawdopodobieństwem w przyszłości znajdzie się ona w naszym systemie. Jednak Feedybacky zawierał już fundamenty do innego rozwiązania, które pozwala na łatwiejsze porządkowanie zadań, a dodatkowo jest znany osobom korzystającym częściej z Githuba. Mowa o tagach, zwanych też kategoriami czy etykietami.

Do zgłoszeń można przypisać dowolną liczbę kategorii, których struktura jest płaska - żadna nie jest ważniejsza i zależna od innej. Ich zastosowanie ma miejsce głównie podczas filtrowania na liście, gdzie można wybrać tagi, które muszą być zawarte przez wyświetlane zagadnienia. W ten sposób można zorganizować zgłoszenia w sprinty, etapy, ale także oznaczyć zadania obowiązkowe, opcjonalne, gwarancyjne, a także związane z poszczególnymi obszarami wewnątrz danych projektów. Tym samym osoby zajmujące się np. konkretnym wycinkiem aplikacji mogą łatwo przefiltrować zgłoszenia, którymi rzeczywiście będą zainteresowani. Co więcej, po znalezieniu jednego "reprezentanta" danej grupy istnieje możliwość szybkiego wyświetlenia (lub dodania) listy z pozycjami o podobnych właściwościach.

Kategorie są bardzo elastycznym mechanizmem, który można wykorzystać zależnie od naszych potrzeb i wyobraźni. Warto pamiętać, iż strona klienta również widzi tagi przypisane do zgłoszeń.

Przypisane osoby

To akurat nie jest nowa funkcja, gdyż przypisywanie wykonawców do zgłoszeń zostało wprowadzone już dawno temu, jednak od tego czasu nastąpiło wiele zmian.

Po pierwsze, wykonawcy przy zgłoszeniach są widoczni dla wszystkich. Początkowe założenia były inne, jednak w miarę upływu czasu dostrzegliśmy, iż przy dużych projektach skrócenie komunikacji (a Feedybacky w dużej mierze do tego służy) wpływa dobrze na postęp prac, a znajomość osób po drugiej stronie - pozytywnie na atmosferę. Jednocześnie nadal istnieje możliwość ustawienia aliasów, w związku z czym osoba zaangażowana w zagadnienie jest widoczna pod nic niemówiącym mianem.

Po drugie, także klient może przypisywać osoby do zgłoszenia po swojej stronie. Co ważne, kierownicy mogą ustawiać tylko kierowników, a klienci klientów, sprawiając, że system jest chroniony przed błędami wynikającymi z braku informacji o osobach po drugiej stronie. Ponownie - przy dużych projektach z zaangażowanymi użytkownikami u zleceniodawcy zazwyczaj każdy z nich odpowiada za koordynację innej części systemu, w związku z czym istnieje też potrzeba dostarczenia informacji na temat tego, kto może zaprezentować szczegóły.

Po trzecie, wspomniane już wyżej filtrowanie - przy dłuższych pracach zarówno wykonawcy, jak i klienci chcą zobaczyć, czym jeszcze muszą się zająć. Ale co więcej, kierownik projektu (czy Product Owner) również chciałby czasem zerknąć na to, jaki jest status zagadnień przypisanych do osoby X lub czy ta osoba ma jeszcze dużo pracy. To bardzo ułatwia poruszanie się po projekcie oraz śledzenie postępu.

Możliwość ukrywania zgłoszeń dla poszczególnej roli

Czasem jest tak, że wykonawcy nie chcą prezentować niektórych zgłoszeń klientowi, ale jednocześnie chcą je gdzieś umieścić dla reszty zespołu. Ma to miejsce zazwyczaj podczas etapu testów wewnętrznych, gdzie niekoniecznie wskazane jest informowanie zleceniodawcy o pewnych błędach, które na tym etapie zostały znalezione i zostaną skorygowane jeszcze przed oficjalną prezentacją. Także klienci czasem mogą chcieć zapisywać swoje pomysły i chwilowo udostępnić je wyłącznie osobom o wybranej roli.

Cóż, teraz jest to możliwe dla każdego zgłoszenia i ponownie - kierownicy mogą udostępniać zgłoszenia tylko innym kierownikom, a klienci klientom. Z doświadczenia to bardzo ułatwia komunikację przy poprawkach wewnętrznych, a jednocześnie ogranicza natłok wiadomości u osób, które i tak pewnych zgłoszeń nie zobaczą. Należy też wspomnieć, iż standardowo, przy braku określenia ról, zgłoszenie widzą wszyscy mający dostęp do projektu.

Statusy charakterystyczne dla projektu

Przy okazji rozmów z różnymi klientami o ich obsłudze Feedybacky'ego dostrzegliśmy, jak różny może być przepływ informacji. Nie zawsze procedura odpowiada statusom, które system domyślnie oferuje i nierzadko pewne statusy były nadmiarowe lub wykorzystywane niezgodne z przeznaczeniem. Przykładem może być obecność w procesie więcej niż jednego serwera testowego lub sam proces akceptacji klienta - do tej pory odbywało się to poprzez odpowiednią odpowiedź w komentarzu. Czas to zmienić.

Obecnie każdy projekt ma swoją listę statusów. Grupy są stałe (z nimi są skojarzone statystyki oraz zachowanie systemu w pewnych sytuacjach), jednak kierownicy projektu mogą dowolnie modyfikować same pozycje, które można ustawić dla zgłoszeń w danym przedsięwzięciu. Jedynie status "nowy" jest obowiązkowy ze względu na bycie "wejściem" dla nowych zgłoszeń.

W ten sposób można nie tylko utworzyć stany charakterystyczne dla danego typu współpracy z klientem, ale także zmienić nazwy istniejącym pozycjom.

Inne zmiany

Oczywiście, poza większymi funkcjami, w Feedybacky został wprowadzony szereg mniejszych zmian, które zwykle nie są na tyle interesujące, aby o nich osobno mówić. W szczególności są to drobne poprawki layoutu, okna modalne pozwalające potwierdzić pewne akcje czy zmienione teksty. W tym miejscu warto wspomnieć o:

• symbolu projektu, który jest nie tylko ciągiem znaków, ale posiada również przypisany hash, ułatwiający identyfikację projektu w systemie (a przy okazji wymuszający korzystanie z tego hasha we wtyczce),
• przypadkowe wyjście z częściowo uzupełnionego formularza aktualizacji zgłoszenia musi być potwierdzone przez użytkownika, co nie jest wielkim kosztem czasowym, gdy nastąpiło to świadomie, ale w niektórych przypadkach pozwala zapobiec utracie długo wpisywanych danych,
• usuwanie członków projektu było zdecydowanie zbyt łatwe i musiało zostać zabezpieczone oknem modalnym.

Co dalej?

Tempo przybywania pomysłów jest na pewno szybsze niż tempo ich realizacji, ale warto pamiętać, że nie zawsze każdy pomysł jest odpowiedni. Potwierdzi to każda osoba pracująca przy kreatywnych projektach, gdzie zbyt duże nagromadzenie różnych koncepcji nie zawsze gwarantuje spójność, a wręcz może wytworzyć chaos. Dlatego trzeba to kontrolować i nie każda idea, która pozornie wygląda na wspaniałą, jest rzeczywiście warta realizacji.

Dlatego warto wyznaczać sobie odgórne, bardziej dalekosiężne cele i takim jest np. w naszym przypadku postępująca rezygnacja z Redmine'a na rzecz Feedybacky'ego, co oznacza zagwarantowanie np. miejsca do przechowywania notatek czy lepsze raportowanie godzin. Ostatnie miesiące pokazały też, iż potrzebne są zmiany w zakresie zarządzania wycenami. W planach jest także przearanżowanie kokpitu, który w obecnej formie jest rzadko użyteczny. Z pewnością, gdy nastąpią zmiany z tym związane, doczekają się one artykułu na naszym blogu.

Tym niemniej, zapraszamy także do przetestowania obecnych zmian. Jeśli jesteście chętni do skorzystania z projektu Feedybacky (nadal w fazie beta), zachęcamy do kontaktu.

Pozdrawiam i dziękuję - Jakub Rojek.