Oprogramowanie i aplikacje wymagają aktualizacji. Konieczność odświeżania programów to oczywistość w branży deweloperskiej. Dzięki aktualizacjom i łatkom naprawiamy błędy, poprawiamy funkcjonalność rozwiązań i dodajemy nowe narzędzia. Nasuwa się jednak pytanie, jak często aktualizować oprogramowanie e‑commerce? Czy proces ten powinien być cykliczny i odbywać raz dziennie, raz na tydzień czy raz na miesiąc? A może kolejne wersje należy publikować jedynie wtedy, gdy wprowadzamy nową funkcję? Odpowiedź na to pytanie ma tak naprawdę największe znaczenie dla klienta, który z oprogramowania korzysta.
Oprogramowanie jako twór matematyczny
Dla wielu przedsiębiorstw właściwie oprogramowanie to koło zamachowe biznesu. Odpowiedni system ERP, CRM czy platforma e‑commerce są sercem firmy i bez nich praca poszczególnych osób i działów jest utrudniona, a nawet niemożliwa. Firmy produkujące soft coraz częściej decydują się na długoterminowe wsparcie swoich systemów. Jednakże z czasem może dojść do sytuacji, w której dana wersja oprogramowania zostaje porzucona i pozbawiona wsparcia, a jej miejsce zajmuje nowa platforma opatrzona na przykład wyższym numerem. Nie mówimy tutaj o changelogu, który wprowadza kolejne poprawki, tworząc na przykład wersje programu o numerze 1.1, 1.2, 1.2a itd., lecz o całkowitej zmianie silnika i jego możliwości. Tak było na przykład w przypadku platformy Magento, kiedy to Magento 1 po zakończeniu wsparcia zostało zastąpione przez Magento 2. Wymusiło to na użytkownikach platformy zmianę wersji, co wiązało się z dodatkowymi kosztami.
Pod koniec lat 90. pojawiły się tezy, że oprogramowanie jako twór matematyczny nie może się zestarzeć. Nic bardziej mylnego. Oprogramowanie dotyka proces starzenia technologicznego, podobnie jak w przypadku sprzętu komputerowego czy telefonów. Kolejne generacje powstają dlatego, że rozwój starych urządzeń jest zablokowany z powodu ograniczonych zasobów. Tutaj też można trochę polemizować, bowiem niejednokrotnie nowe sterowniki do karty graficznej czy płyty głównej pozwalają na poprawę jej wydajności. W takim wypadku problem jest nie tyle hardware’owy, co software’owy. To też pokazuje, jak ważny jest kod przygotowany zgodnie z zasadami programowania. Z tego też powodu w 2001 roku stworzono Manifest Agile, który do dziś systematyzuje sposób pracy programistów.
Powody starzenia się oprogramowania
Przyczyny, które mają wpływ na proces starzenia się oprogramowania leżą przeważnie po stronie deweloperów. To od nich zależy, jak często analizowane będą potrzeby odbiorców (korzystających na przykład z platformy e-commerce) i jak często pojawi się na te potrzeby odpowiedź. Dobrym przykładem jest branża gier wideo. Każda gra ma swój cykl życia, który zaczyna się na etapie premiery, a kończy w momencie zakończenia wsparcia dla produktu. Jaki to okres? Wszystko zależy jedynie od deweloperów. Przykładowo „Need for Speed Heat” został wydany 8 listopada 2019 roku, a ostatnia aktualizacja pojawia się 9 czerwca 2020 roku. Od tej chwili deweloper nie będzie wspierał produktu, który z czasem po prostu „umrze”. Taka cyfrowa śmierć nie oznacza, że gra przestanie działać, ale może być pozbawiana kolejnych funkcji (na przykład gry online pomiędzy platformami). Dla porównania znany chyba każdemu Minecraft wspierany jest od 2011 roku, a każda aktualizacja przynosi nowe poprawki i funkcje. W przypadku oprogramowania dobrym przykładem może być system operacyjny Mac Os, który wspierany i rozwijany jest od marca 2001 roku.
Jeśli z czasem użytkownikowi zacznie przeszkadzać, że gra nie rozwija się, to po prostu odłoży ją na półkę lub sprzeda i sięgnie po inny tytuł. Z oprogramowaniem e‑commerce jest inaczej. Nie możemy z dnia na dzień przenieść się pomiędzy platformami, jeśli jedna została pozbawiona wsparcia. Nie możemy też żądać od dewelopera zwrotu pieniędzy, na przykład jeśli korzystamy z platformy rozlicznej w modelu CaaS, bowiem takie oprogramowanie zawiera pełny zestaw funkcji, który zawsze będzie nam udostępniony i zawsze będziemy mogli z niego skorzystać. Przeważnie jest to zapisane w licencji użytkownika i umowie, którą „podpisujemy” podczas „wykupienia” usługi. Warto też zwrócić uwagę na jeszcze jeden aspekt. W przypadku wielu rozwiązań nowe funkcje są implementowane dopiero wtedy, gdy odpowiednio duża liczba użytkowników platformy będzie ich żądała lub zgłosi zapotrzebowanie na zmianę. Dlaczego wsparcie przestaje być dostarczane? Przeważnie dlatego, że zasoby ludzkie skierowane zostają do innego projektu, na przykład tworzenia nowego rozwiązania.
Tutaj dobrze jest wspomnieć o porzucaniu projektów z racji ich „dziurawego kodu” i liczby błędów, które się pojawiły. David Lorge Parnas z McMaster University w Hamilton w Ontario napisał w jednym ze swoich artykułów naukowych, że spotkał się z sytuacją, kiedy liczba błędów w programie przekroczyła dwa tysiące i deweloper musiał podjąć decyzję o porzuceniu go z racji ogromu pracy potrzebnej do rozwiązania wszystkich z nich.
Starzenie się i tworzenie rozbudowanych kodów
Starzenie się oprogramowania wynika także z pewnego schematu działania firmy zajmującej się jego tworzeniem. Mając „główną część silnika” możemy dopinać do niego kolejne elementy, które zaczynają tworzyć pewien trudny do dalszego rozbudowywania kod. Istnieje ryzyko, że z czasem pojawi się tak dużo dopisanych linijek, że ostatecznie platforma może przestać działać lub działać dużo gorzej niż oprogramowanie, które posiada system ciągłego wsparcia. Dodatkowo bywa tak, że nowy zespół programistów nie zawsze rozumie pierwotną koncepcję projektową, co po wprowadzeniu przez nich zmian może doprowadzić do degradacji struktury kodu.
Dobrze ten problem widać w przypadku WordPressa, gdzie wtyczki mogą bardzo spowolnić lub całkowicie zablokować działanie strony postawionej na tym oprogramowaniu. Wtyczki tym różnią się od kodu napisanego specjalnie na nasze potrzeby, że posiadają tego kodu zwykle więcej. Dzieje się tak dlatego, że wtyczki posiadają niejednokrotnie więcej ustawień, niż potrzebujemy i z których nie korzystamy. Dodatkowo każdy kod jest pisany przez inną osobę i nie mamy pewności, czy przeszedł on wszelkie potrzebne testy, by współpracować z naszą instalacją.
Dlaczego publikowanie nowych aktualizacji jest ważne?
Częstotliwość, z jaką publikujemy nowe wersje oprogramowania ma ogromny wpływ nie tylko na atrakcyjność rynkową naszej oferty (a tym samym na przychody firmy), ale także na inne aspekty, na których nam zależy. Mowa tutaj o powtarzalności transakcji, kosztach, produktywności, jakości, zadowoleniu klienta, partnerstwie i komunikacji korporacyjnej. To swoiste budowanie relacji stworzone na bazie kresek kodu.
Trzeba pamiętać, że starzenie się oprogramowania to koszty nie tylko dla dewelopera, ale także dla sprzedawcy, który używa przestarzałej platformy e‑commerce do sprzedaży produktów. Możemy wyliczyć trzy główne koszty strzegącego się softu:
- trudności z nadążeniem za rynkiem i utrata klientów na rzecz konkurencji;
- pogarszająca się struktura, brak wydajności, zasobożerność;
- dodatkowe koszty, jakie generuje oczekiwanie na naprawę pojawiających się błędów.
Częste, nawet codzienne aktualizacje przynoszą korzyści między innymi dlatego, że nie powodują tak dużych zmian i obciążeń systemowych. Gdy nowe funkcje wdrażane są małymi segmentami, można szybko dopasować oprogramowanie do zmian panujących na rynku (na przykład wprowadzić poprawki bezpieczeństwa lub zmiany w API narzędzi zewnętrznych). W przypadku rzadkich aktualizacji może okazać się, że jednorazowe duże zmiany to ogromna ilość kodu, którą trudniej kontrolować. Dodatkowo może dojść do sytuacji, w której wdrożenie nowego rozwiązania jest i tak nieaktualne w chwili jego implementacji, jeśli na przykład inny deweloper wprowadził je już dawno temu, a teraz pojawia się jego kolejna wersja.
Opóźnienia w aktualizacjach sprawiają, że nowe wersje stają się coraz mniej interesujące dla klientów. Z czasem zaczną oni więc szukać innych rozwiązań (na przykład u konkurencji), które pozwolą im podążać za panującymi na rynku trendami.
Kiedy publikować nową wersję?
W przypadku aplikacji użytkownicy końcowi nie zawsze chcą nowych wersji. Dlaczego? Ponieważ przyzwyczajeni są do starych, które już znają i są dla nich wygodne. Przykładem niech będzie edytor Gutenberg, który pojawił się wraz jedną z najnowszych wersji WordPressa. Był on na tyle skomplikowany, że użytkownicy platformy zaczęli szukać sposobu na jego usunięcie. Ilość negatywnych opinii była tak duża, że WordPress zdecydował się pozostawić użytkownikom wybór, który edytor chcą zainstalować.
Firmy deweloperskie muszą rozumieć ogólne potrzeby swoich klientów i tak zaaranżować wewnętrzne zasady i procesy, aby naprawdę oferować więcej niż konkurencja. Żeby do tego doszło, należy rozwijać oprogramowanie w sposób ciągły, upraszczając procedury wewnętrzne, zwiększając przychody i obniżając koszty ogólne.
Dostawcy złożonego oprogramowania ‒ zwłaszcza rozwiązań dla e‑commerce ‒ powinni uwzględnić następujące kwestie operacyjne i biznesowe podczas określania częstotliwości wydawania nowych produktów:
- właściwe testowanie produktu, w tym funkcji, użyteczności, wydajności oraz bezpieczeństwa;
- tworzenie, aktualizowanie i archiwizowanie dokumentacji związanych z rozwojem oprogramowania (mowa o dokumentacji technicznej, podręcznikach użytkownika i materiałach szkoleniowych);
- personalizacja i zmiany tworzone na życzenie klientów;
- integracje z innymi aplikacjami, komponentami oprogramowania i sprzętem (rozwiązania rynkowe, rozwiązania partnerskie, oprogramowanie klientów);
- zmiany przepisów prawa;
- wpływ zmian na obsługę klienta;
- sposoby tworzenia wrażenia ewolucji (potrzeby w zakresie komunikacji marketingowej, wydarzeń i ogólnie reklam).
Trzeba pamiętać, że aktualizacja to także pewne działania marketingowe, które odpowiednio przedstawione klientom, budują przewagę firmy na rynku.
Jak to robimy w merce.com?
Remedium na tego typu problemy może być oprogramowanie dostarczane w modelu CaaS, które rozwijane jest ciągle. Systematycznie dostarczane są nowe poprawki i funkcje, ale z racji architektury headless nie dochodzi tutaj do tworzenia się programistycznych potworów. Takie oprogramowanie daje nie tylko poczucie bezpieczeństwa biznesowego, ale także gwarancję skalowalności i automatycznych aktualizacji, które dostarczane są do klienta bez konieczności jego ingerowania w proces aktualizowania oprogramowania.
Jest to zupełnie inna ścieżka niż ta znana na przykład z takich rozwiązań jak WooCommerce. W przypadku CaaS, klient nie musi pobierać łatek i instalować ich po swojej stronie, bowiem wszelkie zmiany są automatycznie implementowanie. Unika on więc niebezpieczeństwa związanego z wystąpieniem błędów i problemów podczas zmian i przejść na kolejną wersję systemu.
W merce.com zdecydowaliśmy się na codzienne, chociażby niewielkie aktualizacje, które mają na celu zapewnienie naszym klientom poczucia bezpieczeństwa biznesowego. Sprzedawcy korzystający z naszych rozwiązań nie muszą martwić się o techniczne aspekty prowadzenia działalności e‑commerce. Obszary takie jak usprawnienia, aktualizacje czy monitorowanie 24/7 są obsługiwane przez wykwalifikowany zespół specjalistów. Naszą platformę aktualizujemy średnio 1500 razy w ciągu roku, co eliminuje proces starzenia się oprogramowania, a zawsze aktualne oprogramowanie buduje przewagę nad sklepami konkurencji.
