Blog

Wiedza

Jak nie kupić kota w worku ?

Jako że tworzenie oprogramowania na zamówienie to nasza podstawowa działalność, na co dzień spotykamy się z wyzwaniem, jak zapewnić obu stronom poczucie, że będą zadowolone z efektu końcowego.

Kluczową sprawą dla sukcesu projektu, który polega na stworzeniu programu na zamówienie, jest precyzyjne określenie co program ma robić i jak ma wyglądać.

Specyfikacja projektu

Specyfikacja projektu

Specyfikacja powinna zawierać:

  • Dane wejściowe oraz ich źródło (np. plik, wprowadzenie przez użytkownika, webservice, baza danych)
  • Dane wyjściowe – format, postać, miejsce docelowe (np. ekran, drukarka, plik, folder, zapis w bazie danych, webservice)
  • Zakres przetwarzania – w jaki sposób dane wejściowe mają być przetworzone na dane wyjściowe
  • Interfejs użytkownika, czyli jak program ma wyglądać, w szczególności:
    • Menu
    • Spisanie i rozplanowanie poszczególnych ekranów (pola wyjściowe i wejściowe, przyciski)
    • Przejścia pomiędzy ekranami

 

Ta specyfikacja jest podstawą do:

  • przygotowania wyceny, z której wynika kwota wynagrodzenia zawarta w umowie
  • określenia terminu wykonania, który również jest istotnym punktem w umowie
  • zbudowania całej koncepcji rozwiązania

Prototyp

Nasze doświadczenie pokazuje, że nie wszystko, zwłaszcza jeżeli chodzi o interfejs użytkownika, daje się przewidzieć i przelać na papier w formie specyfikacji. Często dopiero, gdy zamawiający zobaczy działający program, stwierdza, że jednak nie o to mu chodziło, że chciałby coś pozmieniać, chociaż wszystko wykonano zgodnie ze specyfikacją.

Część zmian jest często możliwych do wprowadzenia, ale trzeba się liczyć z większymi kosztami i przesunięciem terminu zakończenia prac. Im zmiany bardziej rewolucyjne tym trudniej je wprowadzić w życie i tym większe koszty.

Prototyp

Dlatego w naszej pracy wykorzystujemy prototypy.

Prototyp można przeklikać w celu weryfikacji czy pierwotne założenia były prawidłowe, czy nawigacja jest optymalna i ergonomiczna. Na etapie prototypu wprowadzanie zmian jest jak najbardziej wskazane.

Prototyp nie przetwarza danych, ale pozwala dokładnie pokazać jak będzie wyglądała praca z programem. Przygotowując prototyp możemy od razu przygotować projekt szaty graficznej.

Zatwierdzony przez zlecającego prototyp jest już podstawą do wykonania prac programistycznych.

Często jest tak, że wykonanie prototypu jest przedmiotem pierwszej umowy z zamawiającym. Wtedy prototyp jest załącznikiem do właściwej umowy. Klient będąc właścicielem prototypu ma wolną rękę - może zlecić wykonanie oprogramowania nam, ale wcale nie musi – może wybrać dowolną inną firmę.

Co w sytuacji gdy na początku nie są znane wszystkie szczegóły?

Możliwy jest wariant, w którym na starcie nie określamy szczegółów całego projektu a jedynie podstawowe założenia oraz szczegóły tego, co ma być wykonane w pierwszym kroku. Metodyka ta  określana jest jako programowanie zwinne lub z ang. agile software development.

Ten wariant jest bardzo dobry zwłaszcza w sytuacjach, gdy zamawiający nie ma precyzyjnej wizji tego, co chce uzyskać, bo wizja krystalizuje się stopniowo w miarę postępu projektu. Minus jest taki, że w tym przypadku nie można określić ani kosztów całego projektu ani terminu ukończenia.

Co w sytuacji gdy na początku nie są znane wszystkie szczegóły?

W zwinnym modelu współpracy z klientem:

  • Mamy wyznaczony wspólnie wybrany kierunek
  • Wspólnie ustalamy szczegóły najbliższego etapu prac
  • Pod koniec danego etapu ustalamy szczegóły kolejnego

Unikamy w ten sposób ustalania szczegółów, które w danym momencie trudno jest ustalić, bo skupieni jesteśmy na innym zagadnieniu. Łatwiej jest też wprowadzać zmiany i nowe funkcje, których nie przewidziano na starcie. Można też zrezygnować z pomysłów, które na początku wydawały się niezbędne a trakcie implementacji okazały się nietrafione.

Podobne wpisy
lsb bulb

Masz pomysł? Porozmawiajmy

Masz pomysł? Opowiedz o swoim projekcie.