Specyfikacja – „owoc” wstępnego etapu współpracy
Asertywny konsultant – powodzenie na starcie
Wizja nabiera „realnych” kształtów
Koncepcja trafia do specyfikacji
Ważne, niefunkcjonalne dodatki
Jak definiujemy sukces współpracy?
Specyfikacja – harmonogram – wycena
Procedury to nie wszystko…
Specyfikacja – „owoc” wstępnego etapu współpracy
Proces przygotowywania specyfikacji rozpoczyna się już w trakcie pierwszego spotkania z klientem, w trakcie którego – w ramach tzw. briefu – przedstawiciele agencji poznają specyfikę działalności klienta, główne założenia projektowanej aplikacji oraz cele, jakie ma realizować. Jeśli presja czasu nie jest jedynym i najważniejszym priorytetem to możemy powstawanie specyfikacji potraktować jako proces. Stosujemy wtedy strategię, którą można określić jako „od analizy do syntezy”. Oznacza to dla nas możliwość szerokiego pozyskania od klienta wiedzy, a następnie wysyntetyzowanie jej do modelu pomocnego w zaplanowaniu działań.
W tym miejscu z pomocą przychodzą różne techniki, jedną z nich ich tworzenie mind-mapy. Pozwala ona na umieszczanie kolejnych komponentów, które złożą się później na poszczególne funkcjonalności wraz z relacjami między nimi. Pozwala to uniknąć pułapki liniowego myślenia, wykluczającego sieciowość zależności między składowymi oprogramowania. Dla obu stron to również dobry sposób na ułatwienie wspólnej pracy nad kreowaniem przestrzeni przyszłej aplikacji – znacznie przyjemniej uzupełnia się strukturę mind-mapy w porównaniu z tworzeniem opisu np. w dokumencie tekstowym. Często zdarza się, że klienci analizując strukturę planowanej aplikacji w opisie tekstowym znacznie większą uwagę poświęcają informacjom zawartym na jego początku oraz końcu, kosztem szczegółów zawartych wewnątrz długiego opisu. Wydłuża to proces dochodzenia do akceptowalnego modelu aplikacji.
Asertywny konsultant – powodzenie na starcie
Na tym etapie wyjątkowo istotny dla powodzenia całego procesu jest element… „miękki”. Relacja klient – usługodawca musi być budowana na zasadzie partnerskiej. Postawa agencji, zakładająca przyjęcie do wiadomości wszystkich oczekiwań klienta to pierwszy krok do dalszych kłopotów. Już w tym momencie dobry konsultant zobowiązany jest sygnalizować niewłaściwe założenia, jakie przyjmuje klient oraz wskazywać alternatywy. Obowiązkiem odpowiedzialnej agencji jest dopilnowanie, by opracowana wspólnie z klientem koncepcja realizowała oczekiwane przez niego cele (np. racjonalizację kosztów czy generowanie przychodów).
Wizja nabiera „realnych” kształtów
Kiedy obie strony osiągają etap spójnego wyobrażenia finalnego produktu można przystępować do tworzenia makiet funkcjonalnych. Możemy je podzielić na dwie grupy, które – dość potocznie – określamy jako low-fi oraz high-fi. Pierwsze przypominają proste czarno-białe szkice z kwadratami i prostokątami prezentującymi przyciski, pola oraz funkcje. Drugie prezentują szczegółowy wygląd aplikacji z propozycjami kolorystyki, grafik, treści czy poszczególnych interakcji. Makiety low-fi to często zarzewie – anegdotycznych już w naszej branży – nieporozumień, kiedy klienci mają problemy z przyzwyczajeniem się do myślenia oderwanego od kwestii estetycznych. To moment, kiedy zdarza nam się słyszeć reakcję „to moja aplikacja będzie taka brzydka?”
Koncepcja trafia do specyfikacji
Na bazie doświadczeń z opisanych powyżej etapów powstaje dokument, który określamy mianem specyfikacji. Najczęściej tworzony jest równolegle z nimi. Zazwyczaj dokument ten składa się z ogólnego opisu planowanej aplikacji, celów jakie ma realizować, a także zestawienia wymagań funkcjonalnych, jakie oddamy do dyspozycji użytkownikom. Co bardzo ważne, specyfikacja może być traktowana jako załącznik do umowy – określający dokładnie zakres obowiązków wykonawcy, ale może również stanowić jednocześnie dokument będący podstawą prac programistów.
W zależności od stosowanych procedur, twórcy aplikacji mogą uzupełniać standardowy zestaw dokumentów tworzących specyfikację dodatkowymi elementami, jak na przykład diagramy UML. Prezentują ona logikę przebiegu procesów w aplikacji, w sposób przyjazny i zrozumiały dla osób, które nie są wtajemniczone w kwestie programistyczne.
Ważne, niefunkcjonalne dodatki
Wszystkim powyższym materiałom – określającym stronę funkcjonalną planowanej aplikacji – towarzyszy jeszcze sfera wymagań niefunkcjonalnych. To kwestie związane z całą sferą kompatybilności z poszczególnymi urządzeniami, systemami operacyjnymi czy przeglądarkami. Wymogi niefunkcjonalne obejmować mogą również np. maksymalny czas reakcji aplikacji, poziomu bezpieczeństwa haseł czy rodzaju szyfrowania.
Jak definiujemy sukces współpracy?
I na koniec, warto również pamiętać, by nasza specyfikacja jasno określała kryterium powodzenia projektu. Nie zawsze bowiem oddanie aplikacji do użytkowania musi kończyć proces jej tworzenia. Często mamy do czynienia z projektami, które co do swej zasady zakładają ciągły rozwój i mają wpisane w specyfikacji takie cechy jak otwartość na rozwój, doskonalenie procesów czy funkcjonalności oraz rozbudowaną sferę analityczną.
Specyfikacja – harmonogram – wycena
Przygotowana w ten sposób specyfikacja powinna być odpowiednią bazą do harmonogramowania prac, określania kwestii wykorzystania optymalnych zasobów – ludzkich oraz technologicznych – a także, „last but not least” kalkulacji kosztów.
Procedury to nie wszystko…
To – zgodne z zasadami, metodologią i doświadczeniem agencyjnym – podejście, nie będzie jednak wnosić zbyt wiele wartości dodanej jeśli umknie nam jeden, niezmiernie ważny aspekt. O sukcesie takich projektów często decyduje otwartość obu stron, elastyczność oraz świadomość realiów po stronie agencji. Specyfikacje mogą być zamknięte w setkach stron dokumentacji, mogą również stanowić syntetyczne, „zgrabne” opracowanie. Doświadczeni konsultanci wiedzą, że specyfikacja powinna mieć adekwatną formułę i wymiar do skali projektu oraz oczekiwań klienta. Unikajcie takich, którzy za wszelką cenę, nawet cenę sprawnie prowadzonej analizy, zarzucą Was wszystkim, czego dowiedzieli się na odbytych szkoleniach.
