• Home
  • Blog
  • Specyfikacja projektu IT – jak ją napisać i dlaczego warto?

ORGANIZACJA, AUTOMATYZACJA PROCESÓW

17.08.2021 - Przeczytasz w 7 min.

Specyfikacja projektu IT – jak ją napisać i dlaczego warto?

17.08.2021 - Przeczytasz w 7 min.

Innowacyjne firmy generują wiele pomysłów na rozwiązanie problemów. Zarówno problemów ich pracowników, jak i bolączek ich potencjalnych klientów. Niezależnie od tego czy pomysł jest rewolucyjny i podbije serca tysięcy użytkowników, czy chodzi o proste usprawnienie i automatyzację procesu, aby idea miała szansę się ziścić, trzeba ją przelać na papier.

specyfikacja-projektu-it-po-co-ja-tworzyc-jak-ja-stworzyc Blog RST

Czym jest Specyfikacja projektu?

Specyfikacja projektu informatycznego to dokument zawierający opis wymagań produktu.

Specyfikacja przybliża: 

  • założenia tworzonej aplikacji, 
  • jej główne funkcjonalności 
  • oraz problemy, które ma rozwiązać.


Jej stworzenie jest wstępem do współpracy z software housem, ponieważ pozwala Ci przedstawić nie tylko z pomysł, ale też oczekiwania odnośnie jego realizacji i wdrożenia.

 

Po co tworzyć specyfikację projektu IT? 

  1. Przygotowanie dobrej specyfikacji projektu informatycznego umożliwia software house’owi wstępną ocenę ilości pracy, zaplanowanie zespołu, niezbędnych narzędzi i wstępne wyliczenie jak dużo czasu zajmą prace deweloperskie nad Twoim projektem. 
  2. Na podstawie tych założeń i szacunków software house przedstawia ofertę. Dzięki temu, już na wstępnym etapie możesz zweryfikować czy planowany budżet wystarczy do zrealizowania projektu.
  3. Specyfikacja jest dla software house’u również informacją, jakimi wartościami kieruje się zlecający, na jakich rynkach i w jakich obszarach działa. Dzięki temu obie strony przekonają się czy będą dla siebie odpowiednimi partnerami.
  4. Analiza potrzeb i wymagań pozwala software house’owi zweryfikować czy posiada doświadczenie, zasoby i technologię aby zrealizować projekt.

Oprócz tego dobrze stworzona specyfikacja określa cele projektu. Pozwala na analizę konkurencji, potencjalnych trudności i pomaga podjąć decyzję o ewentualnym porzuceniu projektu już w fazie pomysłu.


Dokument powinien obejmować nie tylko zakres funkcjonalności, które mają zostać wdrożone, ale identyfikować też elementy poza zakresem, które nie będą wchodziły w skład wymagań, a które mogą mieć kluczowy wpływ na powodzenie projektu (np. zmiany w przepisach, dostępność półproduktów, narzędzi, technologii itp.). 

Co powinna zawierać dokumentacja projektu IT?

Ok, znamy już cel i zalety dobrze stworzonej dokumentacji. Ale co tak naprawdę powinno się w niej znaleźć? Jak bardzo szczegółowe powinny być opisy funkcjonalności, aby nie pozostawić zbyt dużej swobody interpretacji i jednocześnie nie zawęzić pola na rozwiązania technologiczne?

  • główne potrzeby i cel jaki ma produkt wspierać;
  • grupę docelową (w przypadku rozwiązania wewnętrznego np.: pracownicy firmy, księgowi, dział kadr lub w przypadku aplikacji ogólnodostępnej np.: użytkownicy poszukujący usług stomatologicznych)

 

1. Opis projektu

Dobrze stworzona specyfikacja nie odpowiada na pytanie JAK (Jak powinien wyglądać interfejs użytkownika, jak powinny zachowywać się poszczególne komponenty, czy z jakich gotowych elementów należy skorzystać). Skupienie się na problemie do rozwiązania i tym CO ma być zrobione pozwala software house’owi na zaproponowanie optymalnych rozwiązań i odpowiedniej technologii (np. gotowego rozwiązania lub zbudowania dedykowanego oprogramowania).

Ogólny opis projektu pozwala na zrozumienie kontekstu i domeny biznesowej, w której będzie funkcjonował produkt.

 

2. Wymagania funkcjonalne

Wymagania funkcjonalne to opis kluczowych funkcjonalności nowego produktu. Warto przygotować je w postaci tzw. „user stories”, ponieważ pozwala to na uwzględnienie perspektyw różnych użytkowników i poznanie problemów, których wcześniej mogliśmy nie zauważać.

User Story (pol. Historyjka Użytkownika) to bardzo popularny sposób tworzenia wymagań. Opiera się na historii użytkownika, czyli modelu: Kto? Co? Dlaczego? 

Przykładowe User Stories:

  • jako użytkownik e-biblioteki chcę wyszukać książkę po tytule, aby ją wypożyczyć;
  • jako potencjalny klient księgarni, chcę przeczytać recenzje książek, aby zdecydować, którą kupić;
  • jako pracownik magazynowy sklepu odzieżowego, chcę sprawdzić listę produktów w zamówieniu, aby upewnić się, że zamówienie jest kompletne.

Tworzenie wymagań funkcjonalnych na podstawie user story umożliwia spojrzenie na produkt z perspektywy różnych użytkowników i ich potrzeb. Pozwala również na stworzenie prostego schematu zależności pomiędzy poszczególnymi funkcjonalnościami i ustalenie kolejnych kroków jakie będzie musiał przejść użytkownik korzystając z produktu (user flow).

W trakcie spisywania wymagań funkcjonalnych może okazać się, że jest ich bardzo dużo i pojawi się naturalna potrzeba ich priorytetyzowania. Część z nich będzie niezbędna do zrealizowania podstawowego celu produktu, inne natomiast pomogą wyróżnić produkt na tle konkurencji lub po prostu będą wywoływać efekt „wow”. Pojawią się również pomysły, które można odłożyć na półkę i zrealizować jeśli pozwoli na to budżet i czas. 

Dobrze przygotowana specyfikacja projektu powinna skupiać się na najważniejszych tematach, dlatego warto przypisać im właściwe priorytety, aby móc skupić się na tych najważniejszych. Przykłady najciekawszych narzędzi do priorytetyzowania wymagań pokażę na końcu.

 

3. Wymagania niefunkcjonalne

O ile wymagania funkcjonalne wychodzą naturalnie w trakcie rozwijania specyfikacji (w końcu opisują konkretne działania i akcje wynikające z używania produktu), to wymagania niefunkcjonalne mogą być trudniejsze do zdefiniowania.

Nie opisują one funkcji. Skupiają się na jakości i wszystkim co dzieje się “w tle”.
Z pozoru wydają się mniej “sexy”, jednak ich pominięcie lub zlekceważenie może doprowadzić do powstania produktu, który jest ładny, ale nieużyteczny.

 

Wymagania niefunkcjonalne skupiają się m.in. na wydajności, kompatybilności, użyteczności, bezpieczeństwie czy utrzymaniu produktu).

 

Przykładem wymagań niefunkcjonalnych mogą być:

  • szybkość działania aplikacji, reakcji na konkretnie działanie użytkowników, wyrażona w wartościach liczbowych
  • sposób zabezpieczania danych (np. danych logowania, przechowywanych dokumentów);
  • maksymalna ilość użytkowników mogących korzystać z aplikacji; jednocześnie;
  • maksymalna wielkość ładowanego pliku;
  • wspierane przeglądarki internetowe i systemy operacyjne;
  • deadline i budżet – tak, to wymaganie niefunkcjonalne;
  • wymagania i ograniczenia technologiczne (np. w związku z ograniczeniami kraju, na który ma zostać wprowadzony produkt).

 

Niezwykle ważne jest, aby wymagania funkcjonalne i niefunkcjonalne były spisane precyzyjnie i szczegółowo, aby nie pozostawiały miejsca na interpretację. Warto upewnić się, że zamiast określeń “dużo”, “mało”, “szybko”, “wolno” itd. podane są konkretne wartości liczbowe, np. wielkość i nazwa czcionki, ilość sekund na odpowiedź serwera, czy rozmiar i kolor przycisku. 

Dokładne opisanie wymagań bardzo ułatwi Ci współpracę z software housem i zminimalizuje ryzyko nieporozumień, czy konieczności organizowania dodatkowych spotkań, a w efekcie zminimalizuje też straty finansowe.

 

4. Design

Z doświadczenia w pracy przy projektach IT wiem, że dla klienta przynoszącego projekt do software house’u wygląd layoutów, położenie i kolor przycisków często są kluczowymi elementami aplikacji. Niestety ilość czasu poświęconego na szlifowanie designu nie zawsze ma wprost proporcjonalne przełożenie na konwersję, czy zadowolenie użytkowników.

Oczywiście wygląd produktu, zgodny z najnowszymi trendami jest bardzo ważny, bo to on decyduje o efekcie „wow” i może wyróżnić produkt na tle konkurencji. Warto jednak pamiętać, że dobrze zdefiniowane i opisane cele oraz wymagania funkcjonalne będą decydować o tym, czy proponowane rozwiązanie faktycznie trafi do użytkowników i odpowie na ich potrzeby.

Dobrą praktyką jest przygotowanie przez designera gotowych makiet UI, na których znajdziemy konkretne widoki, listę czcionek, ikon, kolorów zastosowanych w projekcie. Bardzo ułatwi to późniejszą implementację.

Ok, wiemy już jak powinna wyglądać dobrze stworzona specyfikacja projektu IT i co powinna zawierać. Ale jak nie popaść w przesadę? Czy można napisać za dużo?

rozmiar-specyfikacji-projektu-it

Wielkość dokumentacji. Czy 50 stron to dużo?

Oczywiście odpowiedzią będzie „to zależy”.

Z doświadczenia wiem, że specyfikacja może mieścić się zarówno na X jak i na Y stronach. Jej wielkość zależy od wielkości projektu i złożoności problemu, jaki chcemy rozwiązać.  Dokumentacja powinna zawierać kluczowe informacje i spriorytetyzowane wymagania, dlatego polecam szczerze przeanalizować, czy każdy z pomysłów faktycznie przybliża produkt do celu. 

Trzeba brać pod uwagę, że każdy kolejny pomysł na funkcjonalność to kolejna złotówka, którą trzeba dołożyć do projektu i wydłużenie daty „premiery” produktu o kolejny dzień. 

 

Jak pozyskiwać i priorytetyzować wymagania? Praktyczne narzędzia

W tworzeniu dokumentacji i pracy nad wymaganiami może pomóc Ci profesjonalny Analityk Biznesowy, który zbierze wymagania z użyciem odpowiednich narzędzi czy serii warsztatów.  Jednym z takich warsztatów może być User Story Mapping. 

a) User Story Mapping

W trakcie takiego warsztatu buduje się mapę produktu, spisuje konkretne funkcjonalności, kroki i luźne pomysły, a następnie przekłada na język User Story i decyduje o priorytetach. Zaproszenie na takie spotkanie różnych przedstawicieli biznesu czy potencjalnego partnera po stronie software house’u może przynieść nieoczekiwane rezultaty w postaci nowych pomysłów, ale również skonfrontowania wizji z potencjalnymi użytkownikami czy wytwórcami.

 

b) MoSCoW

Specyfikacja projektu IT, aby maksymalizować wartość produktu jaki będzie można wdrożyć w zakładanym czasie i budżecie, musi zakładać priorytetyzowanie wymagań.

W analizie biznesowej powszechnie wykorzystywana jest technika MoSCoW. Na jej podstawie każdej funkcjonalności przypisuje się priorytet:

  • Must have „musi być”,
  • Should „powinien być”,
  • Could „może być”,
  • Won’t (this time) „nie musi być teraz, ale możemy wrócić do tego w przyszłości”.

 

Wykorzystanie tej metody pomoże Ci ułożyć wymagania w kolejności, a z części nawet zrezygnować i pozbyć się wrażenia że wszystkie elementy są krytyczne. Pamiętaj jednak, że wymagania „z dołu” listy będą „wypadać” jako pierwsze w przypadku problemów z dotrzymaniem terminów czy przekroczeniem zaplanowanego budżetu.

 

c) Macierz Eisenhowera i Action Priority Matrix

Technika MoSCoW pomoże Ci zidentyfikować elementy kluczowe, ale warto poznać inne narzędzia, które pomagają uzyskać szerszą perspektywę i podjąć lepsze decyzje.

Jednym z najbardziej wszechstronnych narzędzi tego typu jest macierz Eisenhowera, którą można modyfikować na różne sposoby w zależności od potrzeb. Jej fantastyczną zaletą jest umożliwienie obiektywnej oceny poszczególnych funkcjonalności pod kątem faktycznej wartości dodanej i szybka odpowiedź jak zaadresować poszczególne tematy.

Bardzo polecam macierz w wydaniu chłopaków z Agile Force:

Inną wersja macierzy Eisenhowera jest Macierz APM (Action Priority Matrix) oceniającą nakład pracy i wpływ. Ta metoda sprawdzi się tam, gdzie najważniejsza jest efektywność. Kiedy masz mało czasu, nie możesz zrobić wszystkiego, ale chcesz podjąć najlepszą możliwą decyzję.

Stosując Action Priority Matrix analizujesz zadania wg dwóch kryteriów:

  • Wysiłku, jaki trzeba włożyć w wykonanie zadania. (Ile pracy i zaangażowania ono wymaga?)
  • Korzyści, które możesz osiągnąć, kiedy zrealizujesz zadanie. (Co zyskasz?)
Action-Priority-Matrix

d) Feature Buckets Prioritization

Kolejną metodą ułatwiającą wybór najtrafniejszych rozwiązań jest wymyślona przez Adama Nasha (jeden z byłych szefów Dropboxa), Feature Buckets Prioritization. Zakłada ona, że wszystkie pomysły można przypisać do jednej z czterech grup:

  • Poprawiające metryki – Funkcje, które wpłyną pozytywnie na liczbowe cele, które sobie stawiamy. Czyli np. rozwiązania, które zwiększą liczbę klientów, wydłużą czas korzystania z usługi itp. Efekty tych pomysłów da się zmierzyć.
  • Życzenia klientów – To sugestie „z rynku”. Nasi użytkownicy domagają się określonego rozwiązania i wyraźnie dają nam to do zrozumienia.
  • Urozmaicenia – Czyli lubiane przez nas innowacje albo różne cuda, które nie są potrzebne, ale są po prostu fajne, widowiskowe albo modne. To rzeczy, których sukces trudno mierzyć i zaplanować, ale potrafią nas wyróżnić i dodają charakteru.
  • Strategiczne – I wreszcie na końcu, te pomysły, które są związane z długookresowym pomysłem na rozwój. Pasują do wizji i przyszłości, a niekoniecznie tego co tu i teraz.

Co z tym zrobić? Kiedy podzielimy już całość na grupy, staramy się zachować równowagę, wprowadzając rozwiązania z każdego worka. Celem jest więc balans i zdrowa proporcja. Nie chcemy przesadzić ani z innowacjami, ani gonieniem za metrykami. Ważna ma być strategia i nasza wizja, ale też pomysły płynące od klientów.

 

Podsumowanie

Przygotowanie dobrej specyfikacji projektu, choć jest pracochłonne i wymagające, ma kluczowe znaczenie w budowaniu produktu i nawiązywaniu współpracy z partnerami. Warto w trakcie jej opracowywania korzystać z pomocy specjalistów (m.in. Analityka Biznesowego oraz UX/UI designera), ponieważ koszt przełożenia wizji na dokładny i kompletny zapis funkcjonalności jest niewspółmierny z potencjalnym ryzykiem nieporozumień wynikających z niedokładnych opisów czy wręcz luk w wymaganiach.

Obszerna i szczegółowa dokumentacja skupiająca się jednocześnie na najważniejszych potrzebach jest kluczem do sukcesu produktu.

Ocena artykułu

Udostępnij

Marika Witek-Dyrduła

Marika Witek-Dyrduła

Scrum Master

Specjalistka o szerokiej wiedzy w zakresie metodologii Agile, z ponad 6-letnim doświadczeniem w pracy w międzynarodowym środowisku. Jako Certified Scrum Master promuje współpracę, transparentność i rozwiązywanie problemów. Stawia na efektywną komunikację zarówno w zespole, jak i z interesariuszami. Ekspert w priorytetyzacji zadań i optymalizacji przepływów pracy. Ma doświadczenie w dostarczaniu wysokiej jakości oprogramowania, na czas i w ramach budżetu.

Nasz serwis internetowy używa plików cookies do prawidłowego działania strony. Korzystanie z serwisu bez zmiany ustawień dla plików cookies oznacza, że będą one zapisywane w pamięci urządzenia. Ustawienia te można zmieniać w przeglądarce internetowej. Więcej informacji udostępniamy w Polityce plików cookies.