Secure Client Portal Sprint: co obejmuje usługa

Co to jest

Sprint to skoncentrowana implementacja uzgodnionych procesów portalu lub systemu webowego. Może obejmować wskazane role użytkowników, granice uwierzytelniania i dostępu, przyjmowanie zgłoszeń od klientów, formularze, pliki, widoki statusu, wybrane procesy w pulpitach oraz materiały przekazania potrzebne do obsługi dostarczonych funkcji. Przed rozpoczęciem prac strony potwierdzają, co użytkownicy mogą robić, które integracje lub ścieżki danych są wymagane, jaka administracja jest uwzględniona, jakie prace backendowe są dozwolone, jak będą prowadzone testy i jakie wsparcie jest dostępne po przekazaniu. Usługa koncentruje się na potwierdzonych procesach. Złożone marketplace'y, infrastruktura finansowa klasy bankowej lub regulowana, pełne programy SaaS na zamówienie, nieograniczone panele administracyjne, ciągłe zarządzane operacje, SOC/MDR i reagowanie na incydenty pozostają poza ofertą.

Dla kogo

Ten sprint jest odpowiedni dla zespołów, które:

• Potrzebują, aby klienci lub partnerzy przesyłali informacje, wgrywali pliki, sprawdzali status lub korzystali z jasno ograniczonego procesu operacyjnego
• Chcą, aby decyzje dotyczące ról i dostępu zostały jednoznacznie określone przed rozpoczęciem budowy portalu lub systemu webowego
• Potrzebują określonej alternatywy dla rozproszonych formularzy, plików, skrzynek pocztowych i ręcznych aktualizacji statusu
• Chcą realizacji i przekazania w stałym zakresie

Co pomaga wyjaśnić

Sprint pomaga wyjaśnić:

• Którzy użytkownicy, role, granice uwierzytelniania, kroki przyjmowania zgłoszeń, formularze, pliki, widoki statusu i procesy w pulpitach są objęte zakresem
• Które integracje, funkcje administracyjne, zmiany backendowe, decyzje dotyczące danych i obowiązki klienta wymagają potwierdzenia
• Jak dostarczone procesy zostaną przetestowane, przekazane i objęte wsparciem w ustalonej granicy
• Co celowo odłożono, ponieważ należy do późniejszej fazy, innego dostawcy lub odrębnego zakresu

Co jest zawarte

• Pisemne potwierdzenie ról użytkowników, granic dostępu, procesów, integracji, zakresu realizacji, testów i przekazania
• Implementacja uzgodnionych procesów przyjmowania zgłoszeń, formularzy, plików, statusów, ról i pulpitów
• Notatki implementacyjne istotne dla bezpieczeństwa dotyczące wybranych decyzji związanych z uwierzytelnianiem i kontrolą dostępu
• Testy uzgodnionych procesów w dostępnym środowisku realizacyjnym
• Dokumentacja przekazania dotycząca dostarczonych funkcji, znanych ograniczeń, odpowiedzialności i kolejnych kroków operacyjnych
• Ograniczone wyjaśnienia po dostarczeniu dotyczące dostarczonych elementów w zakresie

Co nie jest uwzględnione

• Pełna platforma SaaS na zamówienie, szeroka realizacja agencyjna, złożony marketplace ani nieograniczony rozwój paneli administracyjnych
• Systemy klasy bankowej, regulowana infrastruktura finansowa ani obietnica zgodności z wymogami regulacyjnymi
• Nieuzgodnione funkcje, integracje, prace backendowe, migracje, programy danych ani bieżące zarządzane operacje
• SOC, MDR, ciągły monitoring, reagowanie na incydenty ani obietnica bezpieczeństwa na poziomie platformy
• Nieograniczone poprawki, nieograniczone wsparcie ani obietnica nieprzerwanego działania

Kiedy to wybrać

Ten sprint warto wybrać, gdy firma ma konkretny proces portalu lub systemu webowego, który można opisać przed rozpoczęciem realizacji. Dobrze sprawdza się przy procesie przyjmowania zgłoszeń, dostępie klientów zależnym od ról, wymianie dokumentów, widoczności statusu lub ograniczonej potrzebie pulpitu. W przypadku niezdefiniowanej platformy produktowej, regulowanego systemu finansowego, złożonego marketplace'u lub szerokiego programu prac administracyjnych lepszym punktem wyjścia jest odrębne discovery i zakres. Gdy role, integracje, dane lub priorytety funkcji są wciąż niepewne, lepszym pierwszym krokiem może być discovery lub blueprint produktu. Sprint przynosi najwięcej korzyści, gdy klient może wyznaczyć właścicieli procesów, podejmować decyzje dotyczące dostępu i treści, przekazać wymagane informacje o integracjach i zaakceptować udokumentowaną granicę realizacji.

Nasze podejście

Zaczynamy od procesu operacyjnego, a nie od listy ekranów. Brief wskazuje użytkowników, role, warunki dostępu, formularze, pliki, statusy, potrzeby pulpitów, integracje, ograniczenia backendu, podejście do testów i oczekiwania dotyczące przekazania. Następnie implementujemy potwierdzony proces, jawnie pokazując decyzje dotyczące zakresu. Prośba o nową funkcję administracyjną, integrację ze stroną trzecią lub szerszą zmianę backendu jest otwarcie oceniana jako kwestia zakresu. Testujemy uzgodnione przepływy i zapisujemy obserwacje dla potwierdzonego środowiska. Przy przekazaniu zespół otrzymuje praktyczną dokumentację dostarczonych elementów oraz jasną listę pozycji wyłączonych lub odłożonych. Bieżące operacje, nowe funkcje, operacje bezpieczeństwa i reagowanie na incydenty pozostają odrębnymi obowiązkami. Przekazanie wskazuje też, które decyzje dotyczące konfiguracji, treści, dostępu lub dostawców klient musi utrzymywać po dostarczeniu. Portal może być użyteczny od razu, a mimo to wymagać późniejszych usprawnień lub prac weryfikacyjnych; żadne z nich nie jest po cichu włączone do pierwotnego sprintu.

Często zadawane pytania

Artykuły pokrewne