Close

Jak zamówić usługi software house taniej

Jak wybrać dobry software house, cz. 2

Tworzenie specyfikacji wymagań 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 PLN w przypadku niewielkiego projektu i ponad 400.000 PLN w przypadku większych? Czy to brzmi interesująco?

Jeśli jesteś na tak, 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 wymagań?

  • 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ść ponad przecię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 cenie z góry ustalonej) 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 technicznej

Wrócę do tematu korzyści finansowej, o której wspomniałem na początku. W przypadku jednego z naszych projektów zaoszczędziliśmy ponad 100.000 złotych dzięki przygotowaniu szczegółowej specyfikacji. W jaki sposób? 

Po pierwsze, pytając firmy programistyczne o wycenę projektu, rozmawialiśmy z nimi również o tym, które elementy projektu, ile kosztują. 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 od 50.000 do 150.000 złotych. Ale… wybierając tą najtańszą opcję mieliśmy pewność, że otrzymamy taki projekt, na jakim nam zależy.

Specyfikacja funkcjonalna – główne założenia

Dokumentacja powinna być programisto-centryczna. Obowiązuje stara zasada. Jeśli chcesz, żeby ktoś nas zrozumiał, mów językiem tej osoby.

Co powinna zawierać specyfikacja wymagań?

Aby odpowiedzieć na to pytanie, trzeba określić, jak jest planowana produkcja oprogramowania. Celem zlecanych prac może być wykonanie części aplikacji lub całości, czyli określonej wersji programu.

W przypadku gdy chcemy wykonać tylko część aplikacji, planowanie można oprzeć o user stories, czyli dostarczanie funkcjonalności wg sposobów korzystania z programu przez użytkowników. Wykonując od razu całość aplikacji online, zwykle dzielimy prace na front-end i back-end.

Model rozliczenia fix price zakłada wytworzenie określonej wersji programu, dlatego w 90% przypadków specyfikacja prac IT będzie składać się z dwóch zasadniczych części: front-end i back-end.

Poniżej przedstawiamy prosty case — specyfikację strony internetowej firmy.

Część front-end specyfikacji strony internetowej zawiera:

Jak to robimy w The Story? 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 strony internetowej 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 w formie powiadomienia mailowego, czy łączy się z systemem zewnętrznym (np. Mailchimp, Salesforce)? To wszystko powinno znaleźć się w specyfikacji wraz z zasadami walidacji, bądź uprawnień. Np. 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? Serwis bez zarządzania nawigacją? Serwis 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?


Więc jak wybrać software house? Nie musisz przez to przechodzić sam(a)

Jeśli musisz przejść przez proces przygotowania specyfikacji na potrzeby swojego produktu (SaaS, aplikacji webowej lub mobilnej, serwisu korporacyjnego) zapraszamy do kontaktu. Pomożemy Tobie zaplanować prace programistyczne nad produktem, przygotować specyfikację wymagań, która dowiezie projekt oraz zaoszczędzi masę pieniędzy i nerwów. Aby to zrobić, wystarczy wysłać mail’a na adres tell@thestory.pl.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Close