Napomknąłem ostatnio o portalu, w którym przygotowywanie zamkniętej wersji beta zmierza ku wyraźnemu końcowi - mowa o Feedybacky, a więc serwisie mającym ułatwić obsługę zgłoszeń serwisowych w software house'ach osobom... No właśnie - którym? Tego dotyczy dzisiejszy wpis, w którym pokażemy sobie, w jaki sposób już dostępna wtyczka (w świeżutkiej, bo dzisiejszej wersji 2.0.1, o której wkrótce nieco więcej opowiem) oraz powstający portal pomagają organizować pracę nad projektem w IT w fazach po- lub miedzywdrożeniowych poszczególnym członkom zespołu.

Zacytujmy najpierw pierwsze dwa zdania opisujące system w materiałach promocyjnych:

Feedybacky jest systemem, który powstał z myślą o uproszczeniu pracy zespołów IT nad oprogramowaniem, szczególnie w fazie wdrożeń lub analizy potrzeb użytkowników. Jest to aplikacja, która ma pomóc zwłaszcza pracownikom help desku, testerom, kierownikom projektów, jak i samym programistom.

Jak widać, w tym cytacie mamy wymienione role, które mogą najbardziej skorzystać na wprowadzeniu Feedybacky'ego do projektu. Poniżej podajmy argumenty, które przemawiają za każdą z wymienionych osób, aby uzasadnić ich obecność w rzeczonym fragmencie.

Pracownik help desku (wsparcia)

Ta klasa użytkowników narzuca się naturalnie gdy myślimy o systemie, który służy do obsługi zgłoszeń serwisowych i przyjmowania sugestii. Należy pamiętać o tym, że oddanie oprogramowania użytkownikom do produkcyjnego wykorzystywania bynajmniej nie jest końcem pracy nad nim - wiele osób zapomina o etapie utrzymywania (ang. maintenance), czyli potencjalnie długim okresie, w którym klienci mogą mieć różnorakie kłopoty z obsługą aplikacji i siłą rzeczy będą się zgłaszali do firmy IT z prośbą o wskazówki lub podjęcie działania. To sprawia, że osoby zapewniające wsparcie, ich cierpliwość i chęć pomocy są na wagę złota, zatem powinniśmy zapewnić im jak najbardziej komfortowe warunki, co oznacza m.in. uproszczenie procedury zgłoszeniowej (o czym traktował przywołany już na początku artykuł).

Jednym z większych problemów pracowników wsparcia (i nie tylko, o czym nieco później) przy reagowaniu na zgłoszenia jest brak dostatecznych informacji o tym, w jakich warunkach użytkownik działał w momencie wystąpienia incydentu. W klasycznym scenariuszu oznacza to konieczność dopytywania zgłaszającego o różne informacje, co może owocować rosnącą niecierpliwością po obu stronach, a czasami rozwiązanie przychodzi dopiero po osobistym spotkaniu z klientem i zobaczeniu, jak on to robi. Co prawda, Feedybacky nie "czyści" całkowicie tego problemu, ale mocno go ogranicza poprzez przesyłanie informacji, o które często padają pytania help desku - przeglądarka, system, treść wyświetlających się komunikatów, znacznik czasowy itd. Potencjalnie zatem system skraca czas reakcji na zgłoszenie, co powinno satysfakcjonować zarówno klienta, jak i wykonawcę.

Druga sprawa to fakt, że zazwyczaj zgłoszeń serwisowych nie jest jedno w tym samym czasie ani nawet dwa - często zgłasza się wielu różnych użytkowników i dział ma do obsłużenia wiele sytuacji, co oznacza trudności w zarządzaniu i śledzeniu statusu wszystkich spraw "na wokandzie". W tym Feedybacky jak najbardziej pomaga - grupuje wszystkie zgłoszenia w jednym miejscu, pozwala nadawać im statusy, komentować i ułatwia kontakt z klientem. 

Programiści

Osoby pracujące w IT doskonale wiedzą, że nie wszystkie zgłoszenia mogą rozwiązać osoby ze wsparcia - czasem jest konieczność udania się do programistów. W tym przypadku jeszcze większe znaczenie ma dostępność jak największej puli informacji oraz skrócenie czasu działania, w który wlicza się nie tylko sama "twarda" praca, ale też komunikacja ze zgłaszającym i uzyskanie dostępu do danych. To developerzy zazwyczaj dopytują o zrzuty ekranu, czas, logi i inne parametry, które Feedybacky może dostarczyć. Stąd prosty wniosek, że również ta grupa pracowników może skorzystać na tym systemie.

Jeszcze innym zastosowaniem Feedybacky'ego dla programistów może być tworzenie swoistej listy TODO - często zdarza się, że pracując nad daną funkcją skupiamy się na ogólnej mechanice działania, zostawiając szczegóły i szczególne przypadki na później. Problem w tym, że w przypadku uświadomienia sobie takiego "szczegółu" trzeba go sobie gdzieś zapisać lub pamiętać, co nieco wytrąca z równowagi. Korzystając z wtyczki można to zrobić szybko i czym prędzej wrócić do właściwej pracy nawet bez zmiany karty w przeglądarce, a jednocześnie mieć pewność, że potem będziemy w stanie odtworzyć detale do skorygowania.

Kierownicy projektu i szefowie firm (CEO)

O ile dział wsparcia we współpracy z programistami mają bezpośredni kontakt i rozwiązują problemy oraz sugestie klientów, o tyle ci ostatni w sytuacjach "biznesowych" (często kryzysowych) kontaktują się zwykle z kierownikami projektu czy wręcz szefami firm, którzy "spinają" projekty od strony formalnej i organizacyjnej. Takie osoby nawet, jeśli nie uczestniczą czynnie w procesie dostosowania systemu, to muszą mieć podgląd na to, co się dzieje na linii wsparcie-klient i móc szybko zorientować się w sytuacji, co jest trudne, gdy firma nie ma przygotowanego do tego środowiska lub wszystkie informacje są wymieniane mailem, komunikatorem czy - nie daj Boże - telefonem. Także tutaj Feedybacky może pomóc, umożliwiając raportowanie i wyświetlenie statystyk przepływu zgłoszeń w danym projekcie i to bez zbędnego niepokojenia działu wsparcia oraz programistów.

Testerzy

We wcześniejszych akapitach dywagowaliśmy o sytuacjach, w których aplikacja webowa została już uruchomiona w trybie produkcyjnym i zgłoszenia pochodzą od docelowycjh użytkowników. Natomiast Feedybacky został też stworzony na potrzeby testowych wersji systemu, w których klienci najwięcej "klikają" na różnych etapach projektu i zgodnie z duchem metodyk zwinnych mogą zgłaszać potrzebę zmian czy zaznaczać kwestie, które potem zostaną rozwinięte. Ale nie tylko klienci - także wewnętrzni testerzy software house'u (podobnie jak każda osoba weryfikująca system przed oddaniem go klientowi) mogą w ten sposób zgłaszać znalezione niedoskonałości programistom, śledząc przy tym informacje o już rozwiązanych sprawach.

Podaliśmy powody korzystania z FyBy dla wszystkich klas użytkowników wymienionych w przytoczonym na początku cytacie. Ale są jeszcze dwie dodatkowe grupy osób, które potencjalnie mogą skorzystać na tym systemie. Są to:

Klienci

Snując rozważania o projektach IT i wykonawcach nie można zapominać o tym, że "klient nasz pan" i także jemu zależy na udogodnieniach i śledzeniu statusu realizacji zgłoszonych spraw. W wielu przypadkach brak jasnej informacji dotyczącej postępu prac jest dla zleceniodawców projektu bardzo niepokojący, gdyż nie pozwala zaplanować ewentualnych działań marketingowych lub szerzej zakrojonych testów. Dlatego Feedybacky umożliwia działanie osobom po obu stronach, podgląd tego, co aktualnie się dzieje i dyskusję.

Biuro firmy/Dział sprzedaży

Na koniec dość niespodziewana chyba w tym artykule rola, ale jak najbardziej uzasadniona. Zauważmy, że Feedybacky'ego możemy wykorzystać nie tylko jako miejsce do zgłaszania sugestii i problemów na stronie, ale też jako zwyczajny formularz kontaktowy, za pomocą którego kontaktować się z nami będą potencjalni klienci. Jest to ciekawa opcja, gdyż pozwala zaoszczędzić na podstronie, może być dostosowana do estetyki aplikacji, a także nie wymaga programowania samej mechaniki formularza - wystarczy odpowiednio skonfigurowana wtyczka i projekt w portalu, co jest dość łatwe w realizacji.

Jak widać, Feedybacky potencjalnie może ułatwić pracę (i życie) wielu osobom - magazynuje zgłoszenia w jednym miejscu, pozwala nimi zarządzać, przeglądać statusy, raporty i skraca komunikację pomiędzy wykonawcą a klientem. To wszystko może wpłynąć na relację z klientem, wydajność pracy zespołu i - idąc dalej - jakość oprogramowania, gdyż łatwo i szybko dostępne miejsce do zgłaszania poprawek i propozycji pozwala zgłaszać ich więcej i wręcz zachęca do zadbania o każdy szczegół aplikacji webowej.

A może Wy widzicie jeszcze inne zastosowania Feedybacky'ego lub chcielibyście zapytać, w jaki inny sposób system może Wam pomóc?

Pozdrawiam - Jakub Rojek