Kiedy wycofać własne rozszerzenie SaaS

Syntalith może pomóc ocenić dalszy zakres własnego oprogramowania: co można przenieść do produktu, co uprościć, a co nadal wymaga opieki. Punktem wyjścia jest praca wykonywana przez rozszerzenie i ludzie korzystający z wyniku. Takie porównanie może prowadzić do wycofania części kodu zamiast jego dalszego rozwijania.

Nowa funkcja obejmuje część dawnej potrzeby

Załóżmy, że firma zleciła aplikację powiadamiającą o zmianach w rejestrze. Z czasem rozszerzono ją o przypomnienie kierownikowi, jeśli wskazana osoba nie podjęła sprawy. Teraz obecne narzędzie oferuje własne powiadomienia. Administrator widzi możliwość uproszczenia obsługi, ale kierownik nadal potrzebuje informacji o sprawach pozostawionych bez reakcji.

Najpierw trzeba ustalić, które zachowania rzeczywiście są używane. Być może zwykłe powiadomienia wystarczą, ponieważ zespół zmienił sposób pracy. Być może potrzebne przypomnienie można skonfigurować w produkcie. Można też pozostawić tylko ten fragment rozszerzenia, który nadal rozwiązuje konkretny problem. Podstawą wyboru powinny być potrzeby widoczne w obecnej pracy.

Dla przykładu Microsoft Lists i SharePoint pozwalają tworzyć reguły powiadamiania o zmianach na liście lub w bibliotece. Konfiguracja wymaga odpowiednich uprawnień i podlega opisanym ograniczeniom. Taka funkcja może pokryć część własnego rozszerzenia; jej przydatność trzeba sprawdzić w używanym środowisku.

Porównaj cały dzień pracy odbiorcy

W przykładzie ważne jest, czy użytkownik otrzyma właściwą wiadomość, potrafi przejść do sprawy i wie, co ma zrobić. Kierownik powinien zobaczyć, jak będzie rozpoznawał brak reakcji po zmianie. Jeśli dotychczasowe rozszerzenie łączyło dane z kilku miejsc, porównanie musi objąć również te zależności.

Nowa funkcja może wymagać innego planu, ustawień lub sposobu przydzielania dostępu. Potwierdź te warunki z administratorem albo dostawcą. Zestaw je z pracą potrzebną do utrzymania własnego elementu: zmianami integracji, obsługą problemów i rozwojem. Dalsze utrzymywanie istniejącego kodu wymaga osobnego uzasadnienia.

Warto przyjrzeć się także wyjątkom dodawanym przez lata. Część może nadal być ważna, inne mogły pozostać po zakończonym projekcie lub zmianie zespołu. Właściciel procesu powinien wskazać, z których zachowań firma chce świadomie zrezygnować. To okazja do uproszczenia pracy, o ile skutki są zrozumiałe dla jej uczestników.

Wyłączenie dodatku też wymaga przygotowania

Otwarte sprawy mogą mieć zaplanowane działania w dotychczasowym rozszerzeniu. Trzeba uzgodnić, czy zostaną dokończone tam, czy przejęte przez nową funkcję. Przy przejściu ważne jest uniknięcie podwójnych wiadomości i rozpoznanie spraw, które nie trafiły do żadnego obiegu. Firma powinna wiedzieć, kto wyjaśnia takie przypadki.

Jeżeli rozszerzenie przechowuje własną historię, ustal, gdzie będzie dostępna po wyłączeniu. Kod i dokumentacja mogą pozostać w archiwum firmy, nawet jeśli aplikacja przestaje działać. Dostępy oraz połączenia należy uporządkować w uzgodnionym zakresie, z osobą odpowiedzialną za każde środowisko.

Po zmianie wsparcie może rozdzielić się inaczej: konfigurację przejmie administrator produktu, a wykonawca pozostanie odpowiedzialny za zachowaną integrację. Warto zapisać tę granicę i zasady eksportu danych. Dzięki temu użytkownik wie, gdzie zgłosić problem, a firma potrafi później zmienić opiekuna pozostałego kodu.

Porozmawiaj z Syntalith o rozszerzeniu, które dziś dubluje funkcję produktu. Możemy omówić, co nadal robi dla zespołu i jaki zakres oceny pozwoli zdecydować o uproszczeniu, pozostawieniu albo wycofaniu. Informacje o wycenie są w cenniku.