Jak przygotować specyfikację projektu - serwisu internetowego lub aplikacji dedykowanej? [beta]

Dlaczego warto przygotowywać specyfikację?

Specyfikacja jest niezbędna do przeprowadzanie analizy i prawidłowej wyceny projektu. Statystycznie większość projektów informatycznych kończy się porażką. Część jest porzucana - nie jest kończona, część kończy się, jednak przekracza termin i/lub budżet. Dzieje się tak najczęściej ze wględu na to, że podczas analizy i wyceny nie jest znany pełen zakres projektu.

Istnieją projekty zwinne, w których szczegółowa specyfikacja jest znana jedynie na najbliższą iterację, a co do całego projektu określone są cele i ogólne wymagania. Jednak jest to inne podejścia, inna metodyka pracy. W szczególności nie są wtedy znane końcowe koszty projektu. Możemy je jedynie w niektórych sytuacjach, bardzo zgrubnie oszacować. Jeśli Twój projekt da się opisać, jego zakres jest znany - przygotuj specyfikację. Jeśli masz konkretny budżet i chcesz zrealizować konkretny zakres - przygotuj specyfikację. To pomoże wszystkim uczestnikom projektu. 

Dziś specyfikacja nie musi być już opasłymi tomami drukowanymi jak w czasach słusznie minionych. Preferowane są zwięzłe, lekkie, zwinne, ale precyzyjne i wyczerpujące dokumentacje w formie dokumentów online, które następnie uzupełniane są przez obie strony dialogu.

Elementy specyfikacji

Specyfikacja powinna:

• opisywać podstawowe cechy, założenia oraz cele projektu.
• zawierać (co najmniej) ogólny opis projektu, w tym zakres zadań, które będą w jego ramach realizowane.
• uwzględniać załączniki - dodatkowe dokumenty, które dają specyfikacji kontekst, uzupełniają ją. Mogą to być np. dokumenty tekstowe z treścią podstron i komunikatów, grafiki takie jak billboardy i ulotki, logo z księgą znaków. Jeśli materiały te nie istnieją jeszcze (a tak się najczęściej zdarza w nowych projektach. Powstają one zwykle w trakcie wdrożenia, które trwa 2-3-4 miesiące. Kluczowym dokumentem, który jest potrzebny do wyceny projektu są makiety. Istnieją umownie 3 rodzaje makiet względem stopnia skomplikowania i precyzyjności. Lo-fi, Hi-fi i pomiędzy nimi umowne mid-fi. Makieta lo-fi to szkic na karcie. Załącz więcej dokumentów i opisz je, a analityk wybierze te, które są potrzebne. 
• określać na jakich urządzeniach i jakich systemach aplikacja będzie przygotowywana. W przypadku aplikacji webowej (nie natywnej) jest to szeroka gama urządzeń, jednak potrzebne jest ich określenie. 
• listować systemy z którymi system ma być zintegrowany oraz opisywac sposób integracji i wymiany danych. Jakie dane mają być przekazywane? W którą stronę? Z jaką częstotliwością lub w jakiej sytuacji? Przykładowymi systemami, z którymi często integruje się systemy informatyczne są: system CRM, system ERP, system magazynowy, system marketing automaton.
• określać jak interfejs użytkownika współdziała z aplikacją (frontend z backendem). Warto opisać jakie są efekty wysyłki poszczególnych formularzy w serwisie i innych głównych akcji jak wyszukiwanie. W tym miejscu warto opisać źródło informacji (np. formularz rejestracji), rodzaj informacji (np. dane użytkownika - login, mail, imię, nazwisko) oraz efekt tego działania - dodanie konta do bazy lub wysyłka maila potwierdzającego rejestrację.
• (jeśli to możliwe) odnosić się do przykładów istniejących systemów. Np. menu jak w gmailu, listy artykułów różnorodne jak na onecie itp, ikony jak na Androidzie.
• być napisana prostym językiem, powinna być też esencją. Pamiętaj, że to od nadawcy zależy zrozumienie komunikatu. Nie jest w niej zwykle ważne dokładne opisywanie zainteresowań grupy docelowej, pomysłu na biznes, metod finansowania projektu. Usuń ze specyfikacji wszystko co zbędne.
• być uporządkowana - stworzona w postaci listy numerowanej i punktowanej.
• zawierać definicje (słownik) pojęć trudnych oraz ról w systemie.
• zawierać listę widoków (typów podstron serwisu). Przykładowe to: strona główna, strona logowania, schowek, koszyk, lista produktów, lista użytkowników, wraz z informacją czy te widoki są publiczne (dostępne dla niezalogowanych użytkownikó) czy tylko dla zalogowanych (wtedy dla któych)
• zawierać listę ról w systemie (typów użytkowników) np. administrator, redaktor, moderator, użytkownik odwiedzający. Role powinny być zdefiniowane osobno dla frontendu (publicznej części aplikacji), a osobno dla backendu (panelu administracyjnego, aplikacji CMS).
• zawierać budżet projektu. Pomaga to oszczędzić bezcenny czas analityka i przeznaczyć go na analizę pogłębioną zamiast na ponowną analizę podstawową tego samego projektu w ograniczonym budżecie. Podanie przez klienta budżetu nie ma wpływu na wysokość stawek godzinowych (te są stałe) ani na czasochłonność poszczególnych elementów procesu programowania. Pomaga to oszczędzić czas firmy niepotrzebnie poświęcany na analizę projektów, które są poniżej widełek w których firma pracuje, czy widełek w których z doświadczenia firmy można projekt zrealizować.
• zawierać poza zakresem i budżetem również termin w którym projekt ma być zrealizowany
• inne oczekiwania i preferencje - np. czy oczekiwany jest pełnowartościowy końcowy produkt czy może MVP, język programowania, posiadany serwer lub serwer na którym wiemy, że aplikacja będzie umieszczona,
• wielkość projektu - liczbę poszczególnego typu rekordów w bazie i ilość ruchu (użytkowników) planowanych w systemie. Liczba produktów, użytkowników, podstron oraz ruch mogą mieć wpływ na rekomendowane rozwiązanie (język programowania, framework, platformę). Np. 40.000 produktów, 100.000 unikalnych użytkowników miesięcznie, 5000 transakcji. 

Zastanów się jakie dokumenty w Twoim posiadaniu pomogą wykonawcy lepiej wyobrazić sobie projekt.
Weź pod uwagę, że nowe, innowacyjne (wiem, że to naduzywane słowo, ale trudno tutaj o inne) projekty są w dużej części nieznane. Wymagają pracy analityka, słuchania rekomendacji architekta, projektanta wynikających z doświadczenia. Nie denerwuj się, jeśli wycenę otrzymasz po wielu rozmowach. Żeby tego uniknąć dopracuj mocno specyfikację.

Kiedy przygotowanie specyfikacji jest szczególnie ważne?

Jak wyżej wspomniałem specyfikacja jest wg mnie niezbędna w zasadzie w każdym projekcie. Można jednak przyjąć, że istnieją sytuacje, w których nie jest potrzebna do części projektu, która jest standardowa, znana lub polegać w tym zakresie można na specyfikacji dostawcy oprogramowania.
Przynajmniej nie musi jej przygotowywać klient. Sytuacja taka ma miejsce w naszych projektach najczęściej przy tworzeniu serwisów prostych, standardowych - stron firmowych, e-commerce (choć sklepy internetowe już coraz rzadziej można nazwać standardowymi - niemal w każdym potrzebne są jakieś istotne wyróżniki konkurencyjne, unikalne funkcje).
Specyfikacja jest z drugiej strony niezbędna w projektach niestandardowych - w szczególności aplikacjach dedykowanych. 
To czy serwis jest standardowy czy nie skonsultujesz z analitykiem. Nasz doradca pomoże Ci przejść przez ten proces bez bólu.

Kto czyta specyfikację

Specyfikację po stronie wykonawcy czytają głównie programiści. W dedykowanych projektach software'owych to część programistyczna jest tą najbardziej pracochłonną, kosztowną, ale też najtrudniejszą i najbardziej pracochłonną do analizy. Kwestie związane z wyglądem serwisu - interfejsem, responsywnością są na tyle standardowe, że często wystarcza doświadczenie analityka i doradcy, żeby określić ile czasu - bezwzględnie w dniach roboczych lub względnie - w procencie całego projektu zajmie wdrożenie front endu.

Co powinna zawierać specyfikacja techniczna.

Specyfikacja opisuje jak ma działać oprogramowanie i jakie akcje będą za jego pośrednictwem możliwe dla różnego rodzaju użytkowników systemu.
Strona internetowa z istniejącym systemem CMS lub dedykowanym oprogramowaniem to system.

Celem stworzenia specyfikacji jest opisanie i przekazanie informacji na temat wymagań co do projektu wykonawcy oraz zespołowi.

Warsztaty

Możliwe jest też przeprowadzenie warsztatów, których efektem będzie wypracowanie specyfikacji. W zależności od stopnia skomplikowania projektu warsztaty takie mogą zająć pół dnia lub cały dzień roboczy.  Warsztaty są odpłatne. Jest to skuteczna metoda opracowania, dopracowania, poprawienia założeń projektu i jego specyfikacji. Alternatywą są konsultacje. Konsultacje są darmowe - jednak ich długość i ilość jest ograniczona. Są to 2-3 konsultacje po 20 minut.