Problem zbyt wielu kategorii zgłoszeń
Problem ten występuje wówczas, gdy kategorii zgłoszeń jest zbyt wiele. Powyżej przedstawiłem sześć przykładowych kategorii –to co najmniej o 1/3 za wiele.
System zgłaszania staje się skomplikowany i trudny do ogarnięcia przez okazjonalnego użytkownika.
Problem zbyt małej liczby kategorii zgłoszeń
Ta trudność jest w pewnym sensie odwrotna do poprzedniej; jest też znacznie bardziej brzemienna w skutki. Załóżmy, że mamy tylko 3 kategorie: błąd blokujący (uniemożliwia pracę z systemem, więc ma bardzo krótki czas rozwiązania), błąd średni (pozwala na rozwiązanie mniej-więcej w ciągu 2 dni roboczych) oraz „propozycja rozwoju”. Załóżmy teraz, że pojawia się problem o charakterze biznesowym, który jest dość ważny i wymaga sporych prac programistycznych, a do tego przed implementacją wymaga uwzględnienia wielu oddziaływań, wypowiedzenia się wielu osób i wypracowania rozwiązania, a przy tym wpływa na inne elementy systemu. W jakiej kategorii powinien być zgłoszony? Kategorie błędów objętych rygorystycznym czasem rozwiązania nie są najlepszym wyborem (ani dla dostawcy usług, ani dla Klienta). Dostawca pracuje pod „mieczem Damoklesa” w postaci terminu, więc będzie dążył do jak najszybszego (być może powierzchownego) rozwiązania zgłoszenia. W ten sposób dostawca usług będzie miał palący problem, a Klient otrzyma gorsze (za to szybkie) rozwiązanie. Pewnym rozwiązaniem byłoby zgłoszenie typu „propozycja rozwoju”–ale wielu użytkowników postrzega ten status jako związany z dodatkowymi kosztami „za rozwój”. Usługodawcy i usługobiorcy–we wspólnym interesie–zazwyczaj jakoś obchodzą ten problem, zakładając zgłoszenia o średnim priorytecie i „obezwładniając” mechanizm JIRY (czy innego rozwiązania śledzenia zleceń) przy pomocy funkcji „zawieszania”. Jest to jednak nie tylko sprzeczne z ideą SLA, ale wręcz idzie po jej prąd; obchodzimy mechanizmy które są jej bogactwem. Właściwym rozwiązaniem byłoby chyba zróżnicowanie statusów zgłoszeń nie objętych ścisłym terminem realizacji –na takie, które są swobodną propozycją do rozważenia przy kolejnej wersji systemu i na takie, w których toczy się praca nad wypracowaniem bieżących rozwiązań.
Problemy wynikające z korzystania z mechanizmu zgłoszeń
Łańcuchowanie zgłoszeń, Istotnym problemem jest –skądinąd naturalna –skłonność użytkowników do „łańcuchowania” zgłoszeń. Zjawisko polega na tym, iż po rozwiązaniu jednego –zgłoszonego pod rygorem czasowym –problemu, użytkownik zauważa inny, mniej lub bardziej związany z poprzednim i dopisuje go w komentarzach poprzedniego zgłoszenia (zamiast dokonać nowego zgłoszenia). Różnica jest fundamentalna –bowiem nowe zgłoszenie oznacza nową pulę czasu na rozwiązanie, zaś dopisanie nowego problemu do starego zgłoszenia powoduje, iż rozwiązanie może nastąpić tylko w czasie, jaki pozostał z całkowitego limitu po rozwiązaniu poprzedniego zgłoszenia. Jest to sprzeczne z ideą SLA, jednak tendencja jest zrozumiała (nawet bez złych intencji Zgłaszającego). Po prostu objęcie zagadnienia rozrzuconego po różnych zgłoszeniach jest dość trudne, stąd skłonność do komasowania problemów w jednym zgłoszeniu. Z drugiej strony, przy odpowiednio długim łańcuchu w tym samym zgłoszeniu (w cyklu problem – rozwiązanie – nowy problem – rozwiązanie – następny problem itd.) przekroczenie limitu SLA staje się nieuchronne. Rozwiązaniem byłaby możliwość klastrowania zgłoszeń (tak by można je było przechowywać i przeglądać niejako w „folderach tematycznych”), ale niewiele systemów wsparcia SLA zapewnia podobną funkcjonalność. Pozostaje zaapelowanie do dyscypliny zakładania zgłoszeń lub korzystanie ze statusów zgłoszenia nieposiadających limitu czasowego.
Zgłaszanie propozycji rozwoju lub modyfikacji jako błędów podlegających SLA
Ten problem ma charakter pozatechniczny –nie bardzo też wyobrażam sobie techniczne środki jego mitygacji. Rozróżnienie pomiędzy błędem a postulatem modyfikacji jest zagadnieniem „miękkim” i każdorazowo musi być rozwiązane na drodze negocjacji.
