Role w panelu administracyjnym i odpowiedzialność za treści nie są opisane
Czym to grozi. W specyfikacji jest wykaz sekcji, ale nie powiedziano, kto i jak je wypełnia. Wykonawca zakłada jedno konto administratora i materiały demonstracyjne, a u zamawiającego aktualności prowadzi biuro prasowe, dokumenty wykłada prawnik, zgłoszenia obywateli ogląda osobny pracownik. Przy odbiorze okazuje się, że nie ma podziału uprawnień i każdy poprawia wszystko. Osobny spór dotyczy tego, kto tłumaczy i publikuje treści w trzech językach: wykonawca uznaje to za zadanie zamawiającego, zamawiający — za część odbioru serwisu.
Jak napisać to dobrze. Osobna sekcja z tabelą ról: administrator, redaktor aktualności, publikujący dokumenty, operator zgłoszeń — i co każdej roli jest dostępne. Tam samo — kto przygotowuje i wprowadza docelowe treści w każdym języku, w jakim zakresie wykonawca wypełnia serwis przed odbiorem i co zamawiający przekazuje jako gotowe teksty.
Brak wymagań dotyczących hostingu, kopii zapasowych i obciążenia
Czym to grozi. Specyfikacja opisuje serwis jako produkt, a nie jako działającą usługę. Nie powiedziano, na czyich zasobach jest umieszczony, kto płaci za hosting i domenę po odbiorze, jak często wykonywane są kopie zapasowe i jak długo są przechowywane. Rezultat: serwis odebrany, a po kilku miesiącach po awarii nie ma czego przywracać. Osobno pojawia się kwestia obciążenia — publikacja ważnego dokumentu daje napływ odwiedzających, a serwis obliczony na zwykły dzień się zawiesza.
Jak napisać to dobrze. Sekcja o eksploatacji: gdzie umieszczony jest serwis i na czyim koncie bilansowym, kto administruje serwerem po odbiorze, częstotliwość i okres przechowywania kopii zapasowych, procedura przywracania. Dodatkowo — oczekiwane obciążenie w szczycie i wymóg potwierdzenia go testem obciążeniowym przed podpisaniem protokołu.
Przeniesienie starych materiałów w ogóle nie jest wspomniane
Czym to grozi. Działający serwis organu publicznego ma zgromadzone archiwum: aktualności z lat pracy, uchwały, raporty, formularze. W specyfikacji nie ma o nich ani słowa — jakby serwis powstawał od zera. Wykonawca liczy cenę bez migracji, zamawiający jest pewny, że archiwum przeniesie się samo. Na końcowym etapie archiwum albo gubi się razem z odnośnikami, do których materiałów odwoływano się z zewnątrz, albo przenoszone jest w pośpiechu kosztem jakości pozostałych prac.
Jak napisać to dobrze. Sekcja o migracji: które sekcje starego serwisu są przenoszone, które archiwizowane, których świadomie nie przenosi się. Osobno — zachowanie adresów stron albo konfiguracja przekierowań na nowe adresy, żeby zewnętrzne odnośniki nadal działały. Zakres przenoszonego materiału wskazać w samej specyfikacji, a nie zostawiać do doprecyzowania.
Odbiór opisany „po wyglądzie zewnętrznym”
Czym to grozi. Sformułowanie w rodzaju „serwis powinien odpowiadać zatwierdzonemu projektowi graficznemu i działać prawidłowo” nie pozwala ani odebrać, ani odrzucić pracy. Komisja otwiera stronę główną, patrzy na nią i wyraża życzenia co do kolorów i rozmieszczenia bloków — na etapie, gdy zmieniać je jest już za późno. A funkcje, które są naprawdę krytyczne, nikt nie sprawdza: czy zgłoszenie obywatela dotarło do odpowiedzialnego pracownika, czy zachowało się formatowanie dokumentu przy wgrywaniu.
Jak napisać to dobrze. Załącznik ze scenariuszami odbioru: konkretne działania i oczekiwany rezultat. Redaktor publikuje aktualność w trzech językach — pojawia się we wszystkich wersjach. Obywatel wysyła zgłoszenie — trafia do rejestru i powiadomienie idzie do odpowiedzialnej osoby. Odwiedzający włącza wersję dla osób słabowidzących — ustawienie zachowuje się przy przejściu między stronami. Protokół podpisywany jest po przejściu scenariuszy.
Dostępność i szybkość na telefonie nie są określone mierzalnie
Czym to grozi. Wersja dla osób słabowidzących w specyfikacji jest wskazana, ale sprowadzona do przycisku powiększenia czcionki i czarno-białego motywu. Rzeczywista dostępność — nawigacja z klawiatury, opisy tekstowe obrazów, działanie czytników ekranu — nie jest sprawdzana, a serwis formalnie spełnia wymóg, pozostając nieprzydatny dla tych, z myślą o których powstał. Szybkość na urządzeniu mobilnym zwykle nie jest wspomniana: serwis składany jest z ciężkimi zdjęciami i z telefonu w regionie ładuje się długo.
Jak napisać to dobrze. Wskazać standard dostępności, pod kątem zgodności z którym sprawdzany jest serwis, i sposób sprawdzenia. Dla szybkości — mierzalny próg czasu ładowania kluczowych stron na połączeniu mobilnym, narzędzie pomiaru i warunek, że wyniki pomiarów są załączane do protokołu odbioru.
Nie powiedziano, komu przekazywane są kody źródłowe i dostępy
Czym to grozi. Specyfikacja kończy się uruchomieniem serwisu. Co zamawiający otrzymuje poza działającym adresem — nie opisano. W rezultacie kod źródłowy pozostaje u wykonawcy, domena zarejestrowana jest na jego pracownika, dostęp do serwera wydawany jest na telefon. Kolejny przetarg na rozwój zamienia się w problem: nowy wykonawca nie może rozpocząć pracy, a zamawiający musi wracać do poprzedniego wykonawcy nie z powodu jakości, a z braku wyjścia.
Jak napisać to dobrze. Sekcja o przekazywanych rezultatach: kod źródłowy z historią zmian, prawa do użytkowania i rozwoju, konta domeny i hostingu zarejestrowane na organizację, instrukcja administratora i podręcznik redaktora w języku pracy pracowników. Przekazanie potwierdzane jest protokołem i wchodzi w warunki ostatecznej płatności.
Wymagania napisane tak, że porównanie ofert jest niemożliwe
Czym to grozi. Gdy serwis opisany jest ogólnymi słowami, każdy wykonawca liczy swój zakres prac. Jedna oferta obejmuje przeniesienie archiwum, konfigurację serwera i szkolenie pracowników, inna — tylko skład stron według listy. Ceny różnią się wielokrotnie i porównywanie ich jest bezsensowne. Zamawiający wybiera tańszą ofertę, a potem dowiaduje się o wszystkim, czego w niej nie było. Część wykonawców w ogóle nie zgłasza się, nie rozumiejąc granic pracy.
Jak napisać to dobrze. Wynieść do specyfikacji wszystko, co wpływa na koszt: zakres przenoszonych materiałów, liczbę wersji językowych treści i kto je przygotowuje, zakres szkolenia, okres wsparcia po uruchomieniu i co w niego wchodzi. Im konkretniejsze granice, tym bliżej siebie są oferty i tym sensowniejsza konkurencja.