Obserwacja: "Od siebie wymaga się inaczej, niż za odpłatną usługę."
Podczas użytkowania aplikacji BPM kluczowi użytkownicy odkrywają, że coś można zrobić lepiej lub łatwiej. To coś traktowane jest jako wada aplikacji. Zatem zgłaszane jest jako usterka gwarancyjna.
Z takich zgłoszeń robi się lista, którą jeżeli policzymy według instancji procesów, rozrasta się do kilkudziesięciu prostych zagadnień.
Do tego część z tych zagadnień dotyka core aplikacji, czyli długu technologicznego jaki zaciągnęliśmy (wykonawcy lub platformy).
Tylko kto ma za nią zapłacić?
Za tym wszystkim kryje się mechanizm psychologicznego sumowania.
Użytkownik, podczas zgłaszania problemów, każde zagadnienie widzi oddzielnie, co więcej widzi tylko warstwę prezentacji, a nawet widzi wyłącznie to biznesowo mu źle działa (np. w kolumnie Cel wyjazdu wyświetla się miejscowość, do której jedzie delegowana osoba w procesie obsługi delegacji).
Biznesowo jest to oczywisty błąd i nie ma znaczenia, że w trakcie opracowywania prototypu i testów nie wyszło, że w polu cel ma się pojawiać opis wydarzenia na które jest wystawiona delegacja.
Jest to oczywisty błąd bo konsultant powinien to wiedzieć, skoro mu się płaci za jego usługę.
A konsultant godzi się na to, bo przecież zamianę jednej zmiennej można zrobić przy okazji.
W ten sposób powstaje zbiór małych zadań, który przy wyliczaniu pracochłonności jest sumowany.
Niestety funkcja suma nie oddaje istoty rzeczy. Bo za każdym małym zagadnieniem stoi dług technologiczny, do którego nie wypada nam się przyznać.
Wszędzie tam gdzie jest choć mały element subiektywności suma całości nie jest równa sumie części.
W efekcie za brakującą resztę nie ma kto zapłacić.
Rozwiązanie hipotetyczne:
1. Zbieramy małe zgłoszenia i naprawiamy je
2. Wdrożenie nowej paczki zawsze jest odpłatnym wydarzeniem i zawiera:
a. Przygotowanie listy zmian
b. Przygotowanie skryptów instalacyjnych
c. Przepracowanie testów automatycznych dla ścieżek głównych
d. Przeprowadzenie testów ręcznych dla ścieżek alternatywnych
e. Wdrożenie nowej wersji
f. Migrację procesów
Wydarzenie takie, powinno zawsze kosztować tyle samo i powinno być nie zależne od ilości zmian.
Tylko, czy jeżeli wprowadzimy taką procedurę BPM nadal będzie elastyczny?
Brak komentarzy:
Prześlij komentarz