Tworzenie specyfikacji dla wyceny i prowadzenia prac programistycznych
Nie ma nic nudniejszego niż specyfikacja prac IT. Dopóki nie odkrywamy, że dzięki niej jesteśmy w stanie zapłacić dwa, trzy, a czasem cztery razy mniej za prace programistyczne. A jeśli powiem, że Klientowi firmy programistycznej pozwoli to zarobić (zostawić w swojej kieszeni) 100.000–150.000 zł w wypadku niewielkiego projektu i ponad 400.000 zł w wypadku większych? Czy to brzmi interesująco?
Jeśli jesteś tzw. Klientem, przeczytaj ten wpis i przygotuj specyfikację wymagań dla programistów lub od razu przejdź na koniec wpisu i przekaż to zadanie komuś, kto lubi się tym zajmować.
Kiedy potrzebujemy specyfikacji?
- Zawsze kiedy pracujemy nad jakimkolwiek produktem cyfrowym — aplikacją webową, aplikacją mobilną, SaaS, oprogramowaniem dedykowanym, serwisem korporacyjnym, a nawet stroną internetową.
- Kiedy chcemy otrzymać taki produkt, na jakim nam zależy w określonym czasie i budżecie.
- Specyfikacja wymagań jest produktem procesu zwanym analizą biznesową lub analizą biznesową IT, czyli etapu analizy celów i potrzeb klienta oraz planowania prac. Połączenie analizy biznesowej z procesem UX Design potrafi przynieść ponadprzeciętne efekty biznesowe.
Do dzieła
We wcześniejszym wpisie opisaliśmy, kiedy stosować fixed price, a kiedy time & material oraz zalety i wady obu modeli rozliczeń za usługi programistyczne.
Dowiedzieliśmy się, że model fix price (rozliczenie z firmą informatyczną po z góry ustalonej cenie) jest możliwy, kiedy mamy jasne wymagania i określone terminy.
Jest to marzenie przedsiębiorcy, zakupowca w korporacji, dyrektora marketingu i obowiązek działu zamówień publicznych. Ale wymaga pracy. W zamian daje przewidywalność kosztów, transparentność i łatwość zarządzania wykonawcą, ponieważ płatności na rzecz software house zależą głównie od procentu wykonanej pracy.
Wartość specyfikacji
Wrócę do tematu korzyści finansowej, o której wspomniałem na początku. W przypadku jednego z naszych projektów dzięki przygotowaniu szczegółowej specyfikacji zaoszczędziliśmy ponad 100.000 zł. W jaki sposób?
Po pierwsze, pytając firmy programistyczne o wycenę projektu, rozmawialiśmy z nimi również o tym, ile kosztują poszczególne elementy projektu. To pozwoliło nam na pozostawienie w specyfikacji tylko tych elementów, które były nam naprawdę potrzebne.
Po drugie, nawet po rozesłaniu do software house’ów finalnej specyfikacji produktu, otrzymaliśmy oferty w przedziale 50.000-150.000 zł. Ale… wybierając tę najtańszą opcję mieliśmy pewność, że otrzymamy taki projekt, na jakim nam zależy.
Specyfikacja – główne założenia
Dokumentacja powinna być programisto-centryczna. Obowiązuje stara zasada: jeśli chcesz, żeby ktoś cię zrozumiał, mów językiem tej osoby.
Istnieje możliwość wyboru jednej z kilku dróg w tworzeniu specyfikacji do projektu IT. Najbardziej rozbudowana wersja to SRS, czyli Specyfikacja Wymagań Oprogramowania, w której zawarte są wszystkie zidentyfikowane wymagania – biznesowe, użytkowników, funkcjonalne. Ma zastosowanie w każdym projekcie IT. Jednak wymaga zaangażowania analityka biznesowego i architekta oprogramowania.
W przypadku serwisów internetowych, serwisów korporacyjnych możemy sobie pozwolić na wersję skróconą SRS, a najlepiej skupić się na dokładnym opisaniu działania serwisu na bazie projektów graficznych.
Co powinna zawierać specyfikacja serwisu internetowego?
Aby odpowiedzieć na to pytanie, trzeba określić, jak jest planowana produkcja oprogramowania. Celem zlecanych prac może być wykonanie pewnego etapu prac nad serwisem internetowym.
W wypadku, gdy chcemy wykonać tylko określony etap serwisu internetowego, planowanie można oprzeć o user stories, czyli dostarczanie funkcjonalności według sposobów korzystania z programu przez użytkowników.
Model rozliczenia fix price zakłada wytworzenie określonej wersji programu, dlatego w 90 proc. przypadków specyfikacja prac programistów będzie składać się z dwóch zasadniczych części: front-end i back-end.
Poniżej przedstawiamy prosty case: specyfikację serwisu internetowego jako komentarz do przekazywanych programistom projektów graficznych (UI).
Część front-end specyfikacji serwisu internetowego zawiera:
Dzielimy dokumentację na trzy części:
- (1) ogólne założenia i wymagania, które dotyczą całej pracy front-end;
- (2) elementy bazowe, które powtarzają się we wszystkich szablonach wdrażanego serwisu internetowego;
- (3) opis poszczególnych szablonów serwisu.
(1) Opis ogólnych założeń i wymagań projektowych zawiera:
- listę kompatybilnych przeglądarek;
- wymagania do Responsive Web Design;
- materiały UI opisujące działanie interfejsu (link na klikalny prototyp, link na zbiór zawierający projekty graficzne);
- materiały wpływające na zawartość aplikacji (webfonty, przykłady zdjęć, wideo);
- wszystkie odnośniki do plików, które pokazują cały obraz projektu.
(2) Elementy bazowe, które powtarzają się w całej stronie internetowej:
- nawigacja;
- stopka strony internetowej, zwana także „footer”;
- pasek cookies;
- favicony i opengraph images;
- style formularzy;
- animacje i ogólne style.
(3) Opis poszczególnych szablonów serwisu internetowego:
- strona główna;
- podstrona 1;
- podstrona 2;
- itd.
Część back-end specyfikacji serwisu internetowego zawiera:
Informacje o strukturze serwisu, strukturze danych, zasadach działania formularzy, infrastrukturę serwerową i informacje o zewnętrznych aplikacjach, z którymi będzie połączona aplikacja webowa.
Kilka słów o tym, co to oznacza. Struktura serwisu (albo inaczej mapa serwisu) może być wyrażona w formie wizualnej za pomocą aplikacji FlowMap, a najlepiej w formie tabeli ze strukturą adresów URL (routing table).
Struktura danych serwisu składa się z jednostek logicznych lub tzw. modeli. Dane mogą być różnych typów: krótki tekst bez formatowania do 255 znaków (string), dowolny tekst bez formatowania (text), dowolny tekst z formatowaniem i możliwością umieszczania obrazków (richtext) itd.
Każdy z tych modeli jest zarządzany z poziomu CMS. Należy opisać rodzaj danych, który może znaleźć się we właściwości modelu, domyślną wartość, wskazać wartości, które mogą być pominięte przez administratora CMS, potwierdzić, czy zawartość pola może powtarzać się.
Przygotowując specyfikację, opisujemy szczegółowo zasady współpracy z obrazkami i plikami wideo, które są obowiązkowymi elementami każdego serwisu internetowego.
Dobrze jeśli specyfikacja będzie zawierać informacje na temat SEO – zarówno na poziomie samego serwisu, jak i jego podstron. Każda z nich potrzebuje indywidualnej konfiguracji – title, description, key words, seo-title itd.
Administrator serwisu powinien mieć możliwość zarządzania strukturą nawigacji (header serwisu, footer serwisu, menu po rozwinięciu). Niby oczywiste, ale jeśli nie zostanie to omówione, może nie zostać wdrożone w CMS (Content Management System) lub wdrożone inaczej niż to sobie wyobraża klient. Dlatego opisane powinny być nie tylko zasady zarządzania serwisem na poziomie ogólnym, ale również na poziomie poszczególnych podstron.
Formularze
Czy formularz wysyła dane do CMS? Czy też robi to w formie powiadomienia mailowego? Lub może łączy się z systemem zewnętrznym, np. Mailchimp, Salesforce? To wszystko powinno znaleźć się w specyfikacji wraz z zasadami walidacji bądź uprawnień. Przykładowo, czy administrator CMS może edytować treść zapytania, które trafi do systemu? Logiczne jest, że nie powinien, ale czy powinniśmy to zakładać, czy jednak przekazać do programistów?
Infrastruktura, czyli środowisko serwerowe, w którym serwis będzie działał.
The Story standardowo opiera swoje serwisy i aplikacje o rozwiązania chmurowe AWS Amazon. W zasadzie każdy serwis korzysta z EC2, RDS, CloudFront, SES. Jest podłączany do zewnętrznych systemów analitycznych (Google Analytics, Hotjar, Yandex Metrica), a czasem do zewnętrznych systemów przetwarzania danych (wspomniane wyżej Mailchimp, Salesforce).
Dlaczego to wszystko jest takie ważne?
Wyobraź sobie projekt bez dokumentacji. Co otrzymasz na koniec? Serwis bez CMS i możliwości zarządzania kontentem?Bez zarządzania nawigacją? Bez możliwości zarządzania SEO? Serwis bez czego?
Każdy z tych elementów dodaje lub ujmuje prac programistom. Sprawia, że prace trwają krócej bądź dłużej, czasem o kilka minut, czasem o kilkadziesiąt godzin. Ale klient może dowiedzieć się o tym niestety dopiero wtedy, gdy zobaczy gotową pracę otrzymaną od producenta oprogramowania.
Każdy z wyżej opisanych elementów może okazać się szczególnie ważny dla projektu, którym zarządzasz, przesunąć termin realizacji, a nawet uniemożliwić jego start. Jakie straty wówczas poniesiesz?
Uwaga
Przedstawione w artykule przykładowe ceny nie stanowią oferty w rozumieniu Kodeksu Cywilnego.
Fotografia tytułowa: Nicepik.com
Szukasz software house?
