// portal usług online dla obywateli i firm

Specyfikacja techniczna portalu usług online: co zwykle pomijają zamawiający

Specyfikacja techniczna portalu usług online to jedno z najczęstszych zamówień IT składanych przez urzędy i duże firmy świadczące usługi na rzecz ludności lub biznesu. Logika jest prosta: obywatel lub firma składa wniosek przez konto użytkownika, system kieruje go do właściwego urzędu lub działu, a status można śledzić online bez wizyt i telefonów.

Zamawiającym najczęściej jest urząd lub organizacja, która sama świadczy usługę, ale nie ma etatowego zespołu IT zdolnego zaprojektować architekturę o takiej skali. Specyfikację techniczną pisze wtedy ktoś z pracowników na wzór już istniejących portali — i nieuchronnie przenosi do dokumentu nazwy usług, ale nie ich wewnętrzną logikę.

Portal to nie strona z formularzem kontaktowym, lecz system oparty na logowaniu przez państwowe usługi identyfikacji, wymianie danych z innymi urzędami i odporności w okresach szczytowego obciążenia. Jeśli te rzeczy nie zostaną opisane w specyfikacji na etapie zamówienia, trzeba będzie je dopowiadać na etapie developmentu — a to zmienia już terminy, koszt i odpowiedzialność stron.

Co zwykle pomija się w specyfikacji

Usługi wymienione z nazwy, bez ścieżki wniosku

Czym to grozi. Wykonawca nie wie, ile kroków przechodzi wniosek, kto go rozpatruje i kiedy status powinien się zmieniać. Przy odbiorze zamawiający oczekuje jednego procesu, deweloper zrealizował inny — spór schodzi do przeróbki logiki, a nie drobnej poprawki.

Jak napisać to dobrze. Dla każdej usługi — osobna mapa procesu: kto składa wniosek, jakie dokumenty załącza, przez jakie etapy przechodzi wniosek, kto i na którym kroku go przetwarza, jakie statusy widzi wnioskodawca.

Brak opisu logowania do konta użytkownika

Czym to grozi. Jeśli sposób logowania nie jest ustalony, wykonawca zakłada jeden wariant (np. prostą rejestrację przez telefon), a przy odbiorze okazuje się, że wymagane było logowanie przez OneID lub z podpisem elektronicznym. To nie poprawka interfejsu, a inna architektura uwierzytelniania i inne terminy.

Jak napisać to dobrze. W sekcji logowania wprost wskazać: które sposoby autoryzacji są obowiązkowe (OneID, podpis elektroniczny, numer telefonu z potwierdzeniem), dla jakich kategorii użytkowników — obywateli, firm, jakie dane system otrzymuje przy logowaniu i skąd.

Integracje nazwane, ale nieopisane

Czym to grozi. Zwrot „integracja z systemem urzędu X” nic nie mówi o formacie wymiany danych, protokole, częstotliwości zapytań ani o tym, kto ma otworzyć dostęp do środowiska testowego. Wykonawca dowiaduje się tego w trakcie developmentu, gdy terminy są już uzgodnione, i czeka na odpowiedź od strony trzeciej, na którą nie ma wpływu.

Jak napisać to dobrze. Dla każdej integracji — osobny blok: z jakim systemem, jaki protokół i format wymiany, jakie dane przekazywane są w obie strony, kto zapewnia dostęp do obwodu testowego i w jakich terminach, kto odpowiada za utrzymanie integracji po uruchomieniu.

Brak wymagań dotyczących przechowywania danych osobowych

Czym to grozi. Portal pracuje na wnioskach zawierających dane paszportowe, adresy, często dane o firmach. Bez wymagań co do przechowywania i ochrony tych danych wykonawca wybiera architekturę sam, a przy odbiorze albo kontroli regulatora okazuje się, że nie odpowiada ona oczekiwaniom zamawiającego.

Jak napisać to dobrze. Osobna sekcja z wymaganiami co do miejsca przechowywania danych, poziomu dostępu, rejestrowania działań na danych osobowych oraz terminów ich przechowywania lub usuwania.

Nie oszacowano obciążenia w dniach szczytowych

Czym to grozi. Usługi mają sezonowość — dni, w których wniosków składa się wielokrotnie więcej niż zwykle. Jeśli obciążenie nie zostało uwzględnione w specyfikacji, system liczony jest na dzień przeciętny, a w szczyt wnioski zawisają albo nie są przyjmowane — i widać to u użytkowników, nie tylko na testach wewnętrznych.

Jak napisać to dobrze. Wskazać oczekiwaną liczbę wniosków w dniu zwykłym i szczytowym, wymagany czas odpowiedzi systemu przy takim obciążeniu oraz warunki testów obciążeniowych przed odbiorem.

Brak opisu, co uznaje się za system gotowy i odebrany

Czym to grozi. Bez kryteriów odbioru zamawiający i wykonawca rozmijają się w rozumieniu gotowości: jedna strona uważa za portal działający formularz składania wniosku, druga — pełny cykl ze statusami, integracjami i raportowaniem. Spór pojawia się na etapie finalnym, gdy zmiana czegokolwiek jest kosztowna dla obu stron.

Jak napisać to dobrze. Spisać konkretne kryteria odbioru dla każdej usługi i integracji, a także scenariusze testowe, które muszą zostać przeprowadzone przed podpisaniem protokołu odbioru.

Co daje dobra specyfikacja

Zamawiającemu specyfikacja z opisanymi ścieżkami, logowaniem i integracjami daje porównywalne oferty od wykonawców i przewidywalny odbiór bez przeróbek na własny koszt.

Wykonawcy taka specyfikacja pozwala ocenić realny zakres prac i terminy, zamiast wliczać ryzyka w cenę „na wszelki wypadek”.

Jasne wymagania co do przechowywania danych i obciążenia zdejmują z obu stron konieczność sporu o to po fakcie, gdy portal już działa.

Opracowanie takiej specyfikacji to osobny etap przed zamówieniem i warto go wykonać przed ogłoszeniem przetargu, a nie równolegle z nim.

Cena i czas realizacji

Specyfikacja techniczna: od $400, 1-4 tygodnie; cena zależy od złożoności systemu, architektury, stosu technologicznego i integracji. Realizacja w podwykonawstwie: wycena według zakresu kontraktu, przed złożeniem oferty.

Specyfikacja do przetargu lub podwykonawstwo: szczegóły →

Nie podajemy zamawiających ani przetargów: analizujemy typową specyfikację, a nie czyjeś zamówienie.

Przygotowujesz zamówienie albo już wygrałeś przetarg?

Omów przetarg