Rozwój serwisu internetowego jest nieodzowną częścią rozwoju naszej działalności, a co za tym idzie wzrostu naszych potrzeb biznesowych oraz marketingowych. W przypadku pojawienia się potrzeby rozwoju serwisu internetowego zawsze warto skorzystać z pomocy specjalisty – przesłać mu swój pomysł nawet w postaci prostej formy pisemnej lub pokazać za pomocą przykładów („czasem jedno zdjęcie warte jest więcej niż 1000 słów”). Doświadczenie zaufanego specjalisty nierzadko ma bezpośrednie przełożenie na ostateczny koszt rozwoju naszego serwisu, a dokładniej na to ile możemy zaoszczędzić! Specjalista dzieląc się swoją wiedzą i zdobytym doświadczeniem wskaże nam trudniejsze (droższe) funkcjonalności oraz zaproponuje nam ich tańsze zamienniki, które przy odpowiednim zastosowaniu spełniają w pełni nasze potrzeby. Co więcej konsultacje ze specjalistą pozwolą nam na poszerzenie naszego arsenału i wiedzy w ramach wykonywanych zmian. Pamiętajmy, że doświadczonej osobie znacznie łatwiej jest znaleźć zamiennik trudnej funkcjonalności z łatwą, pokrywając przy tym nawet 95% możliwości jakie przyniesie nam dodatkowy moduł.
Świetnym przykładem takiego zamiennika jest usługa jaką oferuje chociażby GetResponse lub jego konkurenci MailChimp, Freshmail. Każda z wymienionych firm zajmuje się masową wysyłką mailingów wraz z obsługą kampanii czy zarządzaniem newsletterami. Zbudowanie takiego modułu dla naszego serwisu jest bardzo drogie, ponieważ firma musi stworzyć panel do zarządzania kontami, kampaniami, możliwość wypisywania się z newslettera, otwieranie wiadomości w przeglądarce w razie jak nie są czytelne i wiele innych potrzebnych funkcjonalności. Do tego twórcy będą musieli zadbać o dobrą jakość wysyłki, czyli, aby jak najmniej wiadomości wpadało do SPAM'u, aby to osiągnąć potrzebna jest często skomplikowana struktura serwerów oraz ciągłe monitorowanie jakości. Całość takiego rozwiązania może być bardzo kosztowna i oscylować wokół kwot rzędu 10-30 tys. złotych. Natomiast jeśli popatrzymy na ofertę usług oferowanych przez GetResponse, zobaczymy, że można przez 30 dni mieć darmowy trial, a później płacić 50zł / m-c. Licząc nawet w skali 5 lat, różnica w kosztach obu rozwiązań jest bezdyskusyjna. Mając do dyspozycji specjalistę i jego doświadczenie, możemy konsultacjami oszczędzić sobie masę pieniędzy.
Wróćmy do rozważań na temat sposobu rozwoju serwisów dedykowanych. Dobrą praktyką (i niezbędną, naszym zdaniem) jest dobra dokumentacja tworzonego rozwiązania, na którą składa się:
- - Określenie modułów lub zakresu funkcjonalności (musimy wiedzieć, jakie założenia ma spełniać serwis)
- - Dokumentacja kodu
- - Przygotowanie diagramów z działaniem kluczowych procesów
- - Przygotowanie przypadków użycia oraz to o czym nie możemy zapomnieć to scenariuszy testowych (musimy wiedzieć jak testować serwis)
- - Środowisko serwisu (musimy wiedzieć w jakim otoczeniu ma działać serwis)
Każdy rozwój serwisu musi rozszerzać lub zmieniać wyżej wymienione informacje. Przy implementacji zawsze musimy zadbać o czystość i przejrzystość kodu oraz o wykonanie scenariuszy testowych w ramach rozwijanego modułu. Pamiętajmy jednak, że nie tylko testujemy nowe scenariusze testowe (czyli te związane z nowym modułem), ale również testujemy te scenariusze z modułów, które mogły być związane ze zmianą (czyli w które zintegrowaliśmy tworząc rozwiązanie). Dlaczego jest to tak ważne? Łatwo jest zbudować nowy moduł w całkowicie oddzielnym serwisie, ale aby go sprawnie i bezbłędnie połączyć razem z innymi częściami aplikacji wymagane jest sporo pracy i doświadczenia, aby nie popsuć już istniejącej części aplikacji.
Dlaczego tak ważne jest przygotowanie każdej z wymienionych części dokumentacji. Najprościej jest to zrobić analizując, co by było, gdybyśmy jej nie mieli.
- Określenie modułów lub zakresu funkcjonalności - Często ten punkt kolokwialnie mówiąc siedzi w głowie inicjatora budowy serwisu dedykowanego oraz po czasie również w głowie jego specjalisty. Spisanie założeń i zakresu funkcjonalności, znacznie ułatwi komunikację między oboma podmiotami oraz realnie zmniejszy ilość niedomówień lub wątpliwości w ramach sposobu działania pewnych części aplikacji. Pamiętajmy, że nawet poprzez proste przeniesienie na papier swojej wizji, musi zastanowić się nad tym osoba czytająca dobrze zinterpretuje to co napisaliśmy. Nie jest to zadanie łatwe, ale oszczędność na późniejszych błędach w przekazywaniu informacji jest niebagatelna.
- Dokumentacja kodu - Zawsze wyrocznią przy sprawdzaniu działania aplikacji jest właśnie kod. Jeśli programista będzie zmuszony do napisania chociażby zdania lub frazy na temat tego co robi, automatycznie zmniejsza się ilość błędów oraz zwróconych błędnych scenariuszy testowych przez testerów. Dodatkowo ułatwia komunikację w zespole, ponieważ mając jasno opisane co robi dana funkcja lub do czego służy zmienna, implementujący nie musi tego wnioskować po kodzie. Dodatkowo rozszerzenie zespołu do pracy nad projektem nie będzie tak czasochłonne i ryzykowne mając dokładnie opisaną pracę nad serwisem
- Przygotowanie diagramów z działaniem kluczowych procesów - Analiza procesów w serwisie (chociażby rejestracji, kupna produktu, usunięcia konta i wiele innych) jest bardzo trudna bez klarownie przygotowanego diagramu. Mocno wyczerpującym jest określenie sposobu działania niektórych elementów bez przełożenia ich na papier, a przełożenie ich na papier zmusza do pokazania klarownej wizji działania. Interpretacja różnych przypadków, szczególnie tych asynchronicznych jest bardzo skomplikowana bez graficznych wspomagaczy.
- Przygotowanie przypadków użycia oraz scenariuszy testowych - Ta część bardzo szczegółowo opisuje jakie założenia ma spełniać nasz system oraz jakie różne scenariusze mają zostać wykonane przez testerów. Mając raport z testów możemy łatwo oszacować czy nasze zmiany i założenia zostały spełnione przez system, a poprzednie pozostałe nadal działają poprawnie. Pamiętajmy jak ważne jest tutaj rozpatrywanie przypadków granicznych. Przy dużej liczbie scenariuszy testowych, warto zastanowić się nad automatyzacją testów.
- Środowisko serwisu - Ten punkt jest niezwykle wartościowy pod względem przyszłościowym. Wiedząc na jakim środowisku i w jakich warunkach pracuje nasza aplikacja, możemy łatwo ocenić koszty jej dalszego rozwoju, skalowania, czy migracji.
Patrząc na to jak ważny jest każdy z tych punktów i jakie są konsekwencje z pominięcia tych elementów, myślę, że każdy jak najszybciej postanowi na ich przygotowanie. Pamiętajmy, że znacznie większe konsekwencje i trudności przynosi leczenie choroby, niż zapobieganie, a im większy serwis tym potężniejsze konsekwencje.
- Zbieranie wizji zmiany (przełożenie potrzeby biznesowej na zmianę w systemie, poprzez przygotowanie przypadków użycia i scenariuszy testowych) - My to nazywamy specyfikacją
- Oszacowanie kosztów i czasu zmiany
- Akceptacja i planowanie dat rozpoczęcia i zakończenia
- Implementacja zmian
- Testy wewnętrzne (wykonanie scenariuszy testowych)
- Wdrożenie na serwer testowy dla Klienta
- Testy zewnętrzne (często tutaj wymagamy wykonania kluczowych scenariuszy testowych i potwierdzenie ich działania przez Klienta)
- Wdrożenie na serwer produkcyjny
- Przygotowanie dokumentacji i potrzebnych procesów, jeśli takie jeszcze nie zostały wykonane
- Znaczne ograniczenie liczby błędów, które zostaną przeniesione na produkcję
- Szybsza reakcja na ewentualne błędy
- Łatwiejsza możliwość skalowania serwisu
- Nie budujemy frankensteina, tylko ciągle pracujemy nad zachowaniem spójności i wykonania serwisu m.in. dzięki ciągłej refaktoryzacji kodu
Jeżeli i Ty masz pomysł na rozwój swojego serwisu daj nam znać! Podzielimy się swoim doświadczeniem i wiedzą :)