Jak napisać specyfikację wymagań oprogramowania (SRS) dla MVP startupu?

Działamy w branży tworzenia aplikacji i każdego dnia spotykamy ludzi, którzy przychodzą do nas, by porozmawiać o swoich pomysłach na biznes. Jak możesz się spodziewać, każdy przedsiębiorca ma inny pomysł, oferuje inną wartość i stara się zaspokajać różne potrzeby klientów. Jednak za każdym razem pojawiają się te same pytania: ile zajmie zbudowanie aplikacji? Ile to będzie kosztować? Kiedy możecie zacząć? Na te pytania każdy zespół musi umieć odpowiedzieć, zanim weźmie się do pracy.

Czym jest specyfikacja wymagań oprogramowania?

Myślimy o specyfikacji wymagań oprogramowania (SRS) jak o mapie drogowej rozwoju produktu. Gdy budujesz firmę, wszyscy mówią, żeby mieć biznesplan. Można go modyfikować po drodze, ale musisz mieć go pod ręką, by śledzić postępy i planować to, co przed Tobą. 

Tak samo jest z Twoim oprogramowaniem. Powinno być częścią ogólnego biznesplanu, ale samo przedsięwzięcie tworzenia aplikacji ma taki poziom złożoności, że zasługuje na oddzielny plan. Wchodzenie w development bez niego to jak przejęcie steru statku bez mapy i z załogą mówiącą po klingońsku.

Jak napisać specyfikację wymagań oprogramowania?

Co sekundę powstają 3 nowe startupy, czyli 11 000 na godzinę i 260 000 dziennie. To oznacza, że jeśli nie będziesz rozwijać się wystarczająco szybko, łatwo zostaniesz w tyle za nową konkurencją. Kluczowe jest wyprzedzanie rynku, a dobry plan (czytaj: SRS) to właśnie to, czego potrzebujesz.

Wybierz właściwy tech stack

Specyfikacja zawiera wszystkie wymagania funkcjonalne Twojego przyszłego produktu. Mając je spisane, możesz podjąć właściwe decyzje dotyczące wyboru technologii. Musisz wziąć pod uwagę szybkość, możliwości skalowania, koszt przyszłego utrzymania i integracje — z jednej strony, by niepotrzebnie nie komplikować aplikacji, a z drugiej, by była gotowa na szybki wzrost.

Wybierz właściwy zespół

Dobrze napisana specyfikacja wymagań oprogramowania pozwala doprecyzować potrzeby w zakresie tech stack i skali projektu, co z kolei czyni Twoje potrzeby rekrutacyjne krystalicznie jasnymi. Dzięki temu zbudujesz zespół, którego kompetencje idealnie pasują do projektu. W końcu, zanim znajdziesz właściwych ludzi do pracy, musisz dokładnie wiedzieć, jaka to praca, prawda?

Nie idź w waterfall...

Szukając w Google fraz „Project Specification Template”, „SRS example” lub „how to create SRS”, najprawdopodobniej trafisz na ogromne, niejasne dokumenty liczące po kilkadziesiąt stron tekstu i szczegółowych opisów. To raczej nie pasuje do podejścia „lean startup”, prawda? Te monstrualne dokumenty to zwykle relikty podejścia zarządzania typu „waterfall”. Wymagało ono zaplanowania projektu od A do Z już na samym początku. To prowadziło do rozrostu dokumentacji, która musiała zawierać wszystkie funkcje, profile użytkowników itd. finalnego produktu.

…lepiej płyń z prądem

Dla „lean startupu” idealnym rozwiązaniem jest przygotowanie okrojonej do minimum wersji dokumentu SRS. Ponad 20 startupów, z którymi już pracowaliśmy, pozwoliło nam wypracować zestaw zasad i dobrych praktyk, które sprawdzają się w większości projektów software’owych. Te podstawowe reguły znajdziesz poniżej — stosowanie ich usprawni przygotowanie Twojej specyfikacji wymagań oprogramowania.

Najlepsze praktyki pisania specyfikacji wymagań oprogramowania

Zainwestuj czas teraz, oszczędzisz później

Czas to pieniądz, ale nie daj się zwieść — wskakiwanie w projekt na główkę bez żadnej pracy wstępnej czy planowania jest nieodpowiedzialne. Zwinność oznacza dostosowywanie planu do zmieniających się okoliczności, a nie pójście na pełne YOLO i „zobaczymy, co będzie”. Plan musi istnieć. Podejście „lean” wymaga szybkiego działania i łatwych pivotów, kiedy trzeba. Przygotowanie dokumentu specyfikacji może na początku wydawać się stratą czasu, ale to konieczny krok, który oszczędzi Ci mnóstwo godzin na etapie developmentu. Zaufaj nam — nauczyliśmy się tego na własnej skórze. 

Dokument wymagań jest głównym źródłem informacji dla developerów przy projektowaniu Twojej aplikacji, więc musisz zadbać o jego jakość. Jeśli zrobisz to dobrze, pozwoli zespołowi deweloperskiemu produktywnie zrealizować Twój pomysł bez zbędnej pracy. Twoje MVP z dużo większym prawdopodobieństwem zostanie dostarczone na czas i z wszystkimi wymaganymi funkcjonalnościami.

Bądź szybki, ale precyzyjny

Dobrym sposobem na oszczędność czasu jest przygotowanie pierwszego szkicu specyfikacji w 1–2 godziny i jak najszybsze zebranie feedbacku od zespołu. Następnie poświęć kolejne 1–2 godziny na uaktualnienie dokumentu o otrzymane uwagi i gotowe. 

Z naszego doświadczenia wynika, że druga wersja zwykle wystarcza, by zacząć pracę z zespołem developerskim. Nie ma sensu na starcie wymyślać niepotrzebnych szczegółów. Twoje MVP powinno pozostać możliwie podstawowe. I bardzo prawdopodobne, że po drodze i tak będziesz zmieniać projekt. Trzymaj się podstaw, ale zadbaj o klarowny opis pomysłu.

Miejcie wspólną wizję

Zanim zacznie się jakikolwiek development, upewnij się, że zespół dąży do tego samego celu i dzieli tę samą wizję projektu. Dlatego planowanie przed kodowaniem to klucz do efektywności. Każdy musi rozumieć cały produkt, wymagane funkcje, widoki do zaimplementowania oraz początkowe cele projektu.

Udostępnij specyfikację

Specyfikacji nie powinien pisać PM w odosobnieniu, by potem przynieść ją zespołowi jak rozkaz. Upewnij się, że dzielisz się dokumentem tak, by zespół miał stały dostęp do najnowszej wersji. Udostępnij go w Google Docs lub gdziekolwiek wolisz, ale pozwól na współpracę w czasie rzeczywistym. Dzięki temu wszyscy będą na tej samej stronie i unikniecie wielu problemów.

Bądź elastyczny

Bardzo częstym błędem PM-ów jest tworzenie zbyt sztywnej specyfikacji i kurczowe trzymanie się jej pierwszej iteracji. Podejście „lean” wymaga elastyczności i umiejętności manewrowania — to samo dotyczy specyfikacji. Z naszego doświadczenia wynika, że ostatnie 20% (albo i więcej) specyfikacji powstaje już w trakcie developmentu. Pozwala to zespołom dostosować aplikacje do nowych potrzeb biznesowych, dodając lub usuwając funkcje w MVP.

Zbierz feedback

Koniecznie pokaż pierwszą wersję SRS kilku osobom. Poproś zarówno technicznych, jak i nietechnicznych znajomych o opinię. Czy dokument jest zrozumiały? Czy zakres jest właściwy? Zbierz te uwagi, nanieś je w specyfikacji i możesz ruszać dalej. Wczesny feedback jest dla startupów naprawdę ważny — oszczędzi Ci mnóstwo czasu i pieniędzy! Pamiętaj, by być otwartym na sugestie i stale ulepszać SRS po drodze. Bądź agile!

Uruchomiliśmy własny szablon Software Requirement Specification! Daj znać, co o nim myślisz! Napisz do nas na hello@start-up.house.