Klient mówi, że potrzebuje strony. To brzmi jak konkretne zamówienie, ale nim nie jest. Nie wiadomo jeszcze, po co ta strona ma istnieć, komu ma pomagać, co ma zmienić w przedsiębiorstwie ani po czym poznamy, że spełniła swoje zadanie. „Chcę stronę” jest początkiem rozmowy, a nie specyfikacją wykonawczą.

Klient nie musi być specjalistą od tworzenia stron. Zna swoją działalność, klientów i problemy, ale nie musi znać zależności między treścią, użytecznością, dostępnością, wydajnością, SEO, infrastrukturą i późniejszym utrzymaniem. Nie powinien też udawać, że zna. Zadaniem wykonawcy nie jest bezrefleksyjne zamienienie każdego życzenia w kod. Zadaniem jest zrozumienie celu biznesowego, przetłumaczenie go na wymagania i wyjaśnienie klientowi konsekwencji dostępnych decyzji.

Dlatego wywiad przed stworzeniem strony nie jest formalnością sprzedażową. Jest pierwszą częścią projektowania.

Klient opisuje rozwiązanie, ale trzeba odkryć problem

Wielokrotnie obserwowałem tę samą zasadę: klient nie wie jeszcze dokładnie, czego chce. Czasem ma tylko ogólne wyobrażenie. Czasem pokazuje stronę konkurencji i prosi o podobny element. Innym razem przedstawia bardzo konkretne wymaganie, które okazuje się antywzorcem — rozwiązaniem popularnym albo znajomym, ale niesłużącym jego rzeczywistemu celowi.

Nie jest to wada klienta. Nikt nie siedzi w głowie drugiego człowieka. Dopóki oczekiwania nie zostaną wyartykułowane, nie można ich uczciwie spełnić. Nawet wypowiedziane oczekiwanie nadal trzeba powiązać z pytaniem: „co ma dzięki temu osiągnąć użytkownik albo przedsiębiorstwo?”. Dojrzałe metody projektowania usług również rozdzielają potrzebę od zaproponowanego rozwiązania i zalecają najpierw poznanie pełnego kontekstu użytkownika (GOV.UK, „Learning about users and their needs”).

Klient może powiedzieć, że potrzebuje bloga. Sam blog jest jednak tylko mechanizmem publikowania treści. Nie tworzy automatycznie eksperckości marki, ruchu ani sprzedaży. Potrzebuje wartościowych materiałów, systematycznej pracy i dotarcia do odbiorców. Google wprost zaznacza, że nawet spełnienie technicznych wymagań i dobrych praktyk nie gwarantuje indeksowania ani wyświetlania strony w wynikach wyszukiwania (Google Search Essentials). Zaleca jednocześnie tworzenie przydatnych treści dla ludzi oraz aktywne informowanie właściwych społeczności o stronie (Google, „Creating helpful, reliable, people-first content”).

Blog ma sens wtedy, gdy pomaga potencjalnemu klientowi lepiej zrozumieć problem, ocenić kompetencje przedsiębiorstwa i podjąć bardziej jakościową decyzję zakupową. Jeśli firma nie zamierza tworzyć treści ani ich promować, trzeba powiedzieć to przed wyceną, nie kilka miesięcy po uruchomieniu pustej sekcji „Aktualności”.

Jedna rozmowa nie wystarczy, bo strona ma wiele warstw

Wywiad dzielę na kilka obszarów. Najpierw trzeba poznać ogólne potrzeby i ustalić rodzaj realizacji: czy potrzebna jest prosta strona, serwis osobisty, strona firmowa, sklep, czy może problem prowadzi w stronę bardziej złożonej aplikacji. Równolegle trzeba rozpoznać przestrzeń cyfrową klienta: domenę, hosting, bazę danych, pocztę, certyfikat SSL, CDN oraz istniejące systemy, z którymi rozwiązanie ma współpracować.

Kolejne warstwy dotyczą funkcjonalności, wyglądu, treści, kosztów i harmonogramu. Każda odpowiada na inne pytanie. Funkcjonalność opisuje, co użytkownik i administrator mają móc zrobić. Wygląd łączy interfejs, doświadczenie użytkownika i charakter marki. Treść obejmuje teksty, zdjęcia, grafiki, filmy, audio, tłumaczenia oraz odpowiedzialność za ich przygotowanie. Budżet i harmonogram pokazują, co można wykonać teraz, co trzeba ograniczyć, a co warto świadomie przenieść do kolejnego etapu.

Pojęcie „najwyższych standardów” również trzeba rozbić na konkretne wymagania. W3C rozwija wiele standardów sieciowych, a WCAG określa testowalne kryteria dostępności na poziomach A, AA i AAA (W3C, „Accessibility Standards Overview”; W3C, „WCAG 2 Overview”). Pole „zgodne z W3C” nie wystarczy. Specyfikacja powinna wskazać, który standard stosujemy, jaki poziom zgodności przyjmujemy i w jaki sposób go sprawdzimy. Podobnie trzeba potraktować responsywność, wydajność, bezpieczeństwo, kopie zapasowe, prywatność i kryteria odbioru.

Klient może nie pomyśleć, że formularz kontaktowy pociąga za sobą obowiązki dotyczące danych, komunikaty po wysłaniu, obsługę błędów i właściwe odnośniki w stopce. Nie powinien odkrywać tych zależności dopiero po wdrożeniu. Rolą procesu jest połączenie rzeczy, które klient wypowiedział, z elementami wynikającymi z konstrukcji rozwiązania oraz uzgodnionego standardu.

Po każdej warstwie musi powstać decyzja, nie tylko notatka

Rozmowa bez podsumowania szybko zamienia się w zbiór różnych wspomnień. Klient pamięta jedno, wykonawca drugie, a agent AI może dostać jeszcze trzecią interpretację. Dlatego po każdym obszarze powinien powstać krótki dokument: opis ustaleń, założenia, decyzje otwarte oraz konsekwencje dla kosztu i pozostałych części projektu.

Klient otrzymuje ten dokument, wnosi uwagi i zatwierdza, że rozumie oczekiwany rezultat. Nie chodzi o podsunięcie mu regulaminu do kliknięcia. Akceptacja ma potwierdzać wspólne rozumienie: co zostanie wykonane, czego nie będzie w tym etapie, jakie materiały ma dostarczyć klient i po czym obie strony rozpoznają poprawny wynik.

Wczesna walidacja nie usuwa wszystkich błędów, ale pozwala odkrywać je wtedy, gdy zmiana jest jeszcze stosunkowo tania. Podręcznik inżynierii systemów NASA zaleca walidowanie oczekiwań i wymagań możliwie wcześnie oraz iteracyjnie, ponieważ późne wykrycie niewłaściwego rozwiązania prowadzi do rozległych przeróbek (NASA, „Systems Engineering Handbook”). Strona małej firmy nie jest statkiem kosmicznym, ale mechanizm błędu pozostaje znajomy: im później odkrywamy, że budowaliśmy nie to, czego potrzeba, tym więcej pracy trzeba wyrzucić albo wykonać ponownie.

Zatwierdzone warstwy składają się w specyfikację wykonawczą. Ta sama specyfikacja służy wycenie pracy, czasu i kosztu, a potem staje się kontekstem dla ludzi lub agentów realizujących projekt. Zamiast ogólnego polecenia „zrób stronę”, wykonawca otrzymuje uzgodnione cele, funkcje, treści, wygląd, ograniczenia, standardy i kryteria akceptacji.

Najwięcej pracy bywa w tym, co wygląda jak kilka kliknięć

Budżet jest trudnym etapem, ponieważ klient widzi głównie efekt końcowy. Może założyć, że strona powstaje z gotowych bloków i kilku kliknięć. Tymczasem nawet nagłówek w pierwszej sekcji strony wymaga decyzji. Ma wzbudzić zaufanie, zaciekawić właściwego odbiorcę, wyjaśnić wartość oferty i pasować do całej kompozycji. Zdanie „jesteśmy wspaniali” da się wpisać w minutę, ale zwykle nie daje odbiorcy powodu, żeby czytał dalej.

Takich pozornie małych elementów są dziesiątki. Każdy może wpływać na inne części strony. Dlatego rzetelna wycena nie wynika z liczby podstron ani bloków. Wynika z pracy potrzebnej do osiągnięcia uzgodnionego rezultatu, uwzględnienia zależności oraz sprawdzenia, czy całość rzeczywiście działa.

Dobry wywiad nie ma sprawić, że w projekcie nigdy nic się nie zmieni. Ma sprawić, że zmiana będzie świadoma. Jeśli po rozpoczęciu realizacji klient chce dodać sklep do planowanego wcześniej bloga, nie jest to drobna poprawka. To nowy etap z własnymi funkcjami, płatnościami, zamówieniami, treściami, ryzykiem, kosztem i harmonogramem. Powinien przejść osobny wywiad, nawet jeśli korzysta z tej samej strony i tej samej relacji z klientem.

Sprzeciw wykonawcy może być częścią dobrej obsługi

Czasem wymaganie klienta jest sprzeczne z jego celem, budżetem albo dobrym standardem. Wykonawca nie powinien wtedy chować się za zdaniem „klient nasz pan” ani arbitralnie narzucać własnego gustu. Potrzebna jest rozmowa pokazująca obie strony decyzji: co klient zyska, z czego zrezygnuje, jakie ryzyko przyjmuje i jaka alternatywa lepiej realizuje jego cel.

To jest również edukacja. Klient nie musi znać branżowego języka, ale powinien rozumieć, za co płaci i dlaczego propozycja wygląda właśnie tak. Dopiero wtedy może świadomie zatwierdzić rozwiązanie albo przyjąć konsekwencje innego wyboru.

Nie każdą sprzeczność da się jednak rozwiązać. Wolę nie rozpocząć projektu niż wziąć pieniądze za stronę, o której z góry wiem, że nie będzie służyć klientowi. Krótkoterminowo oznacza to utratę zlecenia. Długoterminowo chroni obie strony przed rozczarowaniem, konfliktem i realizacją, której nie chciałbym pokazywać jako własnej pracy.

Jakość może wspierać zaufanie, rekomendacje i kolejne zlecenia, ale niczego automatycznie nie gwarantuje. Rynek, widoczność, oferta i późniejsza aktywność klienta nadal mają znaczenie. Właśnie dlatego nie chcę sprzedawać strony jako magicznej maszyny do pozyskiwania klientów. Mogę zaprojektować dobre narzędzie i uczciwie wyjaśnić, jak go używać. Nie mogę obiecać rezultatu niezależnego od całego przedsiębiorstwa.

Specyfikacja jest końcem wywiadu i początkiem odpowiedzialności

Rezultatem procesu nie jest plik z odpowiedziami klienta. Jest nim zaakceptowana instrukcja wykonawcza: połączenie celu biznesowego, potrzeb przyszłych użytkowników, wymagań klienta, wiedzy wykonawcy, standardów, budżetu, harmonogramu i kryteriów odbioru.

Na jej podstawie można rozpocząć zadania, raportować postęp, przeprowadzić testy, odebrać projekt, przeszkolić klienta oraz ustalić wsparcie, aktualizacje i kopie zapasowe. Bez niej realizacja opiera się na domysłach. Z nią nadal może być trudna, ale przynajmniej wiadomo, jaki problem rozwiązujemy i kto zaakceptował sposób dojścia do wyniku.

Klient ma otrzymać wszystko, o co świadomie poprosił, oraz elementy konieczne do tego, aby całość działała zgodnie z uzgodnionym standardem. Nie chodzi o dorzucanie funkcji, których nie potrzebuje. Chodzi o to, aby po zakończeniu nie odkrył, że kupił fragment systemu, podczas gdy nikt nie powiedział mu o pozostałych częściach.

Strona dla samego posiadania strony nie ma sensu. Sens ma narzędzie, którego cel, zakres i dalszy sposób użycia zostały wspólnie zrozumiane przed rozpoczęciem pracy.

Bibliografia

✦Buduję systemy dla większej autonomii.