Niedawno rozmawiałem z klientem, który miał dylemat. Chcieli zaktualizować istniejącą aplikację, co zrodziło ważne pytanie. Czy powinni budować na tym, co już mają, czy zacząć od zera z niestandardowym oprogramowaniem?
Oczywiście żaden projekt nie jest taki sam. Jeśli musisz zadać to pytanie, najpierw poświęciłbym czas na sprawdzenie potrzeb twojego projektu. Ale to nie wyjaśnia, dlaczego jeden wybór może być lepszy od drugiego.
W dzisiejszym blogu chciałem pokazać dwa studia przypadków z pomocą Karola Wiszowatego, dyrektora ds. dostaw i dyrektora operacyjnego. I opisać, dlaczego podjęto decyzję o rozbudowie istniejącego rozwiązania lub rozpoczęciu od zera. A także zalety i wady każdego podejścia.
Rozwijanie istniejących rozwiązań
W pierwszym studium przypadku chcę wyjaśnić projekt, w którym pierwotnie podjęto decyzję o zbudowaniu niektórych funkcji na istniejącym rozwiązaniu. Zacznijmy od tła, klient jest jednym z największych dystrybutorów biletów w Europie. Fakt ten był ważny dla decyzji o budowie na istniejącej architekturze. Ale dlaczego?
Kontekst
Kiedy Beckerbillett zwrócił się do nas, ich istniejący system był już uruchomiony. Od około trzech lat byli w trakcie cyfrowej przebudowy, współpracując z zespołem wewnętrznych programistów. Jednak w okresie pandemii sprzedaż cyfrowa gwałtownie wzrosła, a system wykazywał oznaki, że nie może skalować się wraz z popytem. Wtedy właśnie zwrócili się do nas z prośbą o pomoc w rozszerzeniu możliwości ich sklepu internetowego.
Jak zawsze, rozpoczęliśmy projekt od audytu, przyglądając się "stanowi obecnemu" i temu, jak możemy przejść do "stanu pożądanego". Z technicznego punktu widzenia łatwiej byłoby zbudować system od podstaw. Wprowadzanie zmian i wdrażanie nowych funkcji jest trudniejsze w przypadku starszych systemów i jest to jedna z wad budowania na istniejących rozwiązaniach.
Decyzja z klientem
Dlaczego więc tego nie zrobiliśmy? Cóż, tworzenie aplikacji od zera wymaga czasu. Aby utrzymać silną pozycję na rynku, zmiany musiały następować w szybszym tempie.
Decyzja o rozbudowie istniejącego rozwiązania została podjęta z perspektywy biznesowej. Wszelkie zmiany w istniejącym rozwiązaniu musiały zostać wprowadzone tak, aby nie miały wpływu na model biznesowy i pozycję rynkową.
Wspólnie z klientem nasz zespół .NET opracował mapę drogową aktualizacji wraz z kamieniami milowymi, które musieliśmy osiągnąć. Zajęło nam to więcej czasu niż zaczynanie od zera, co jest kolejnym minusem budowania na istniejącej infrastrukturze. Ważne było jednak to, że użytkownicy otrzymywali nowe funkcje przez cały proces aktualizacji bez żadnych przerw.
Wyniki
W rezultacie projekt rozwijał się naturalnie w miarę upływu czasu, z dodawanymi zmianami w celu zwiększenia funkcjonalności, przy jednoczesnym zapewnieniu, że będzie on działał jak zwykle. Ale to nie wszystko, w tym samym czasie zespół .NET opracował system API, zbudowany od podstaw, do współpracy z partnerami klienta.
Decyzja o oparciu się na istniejącym rozwiązaniu Beckerbillett, pomimo jego wyzwań, była podyktowana potrzebą szybkich zmian w celu utrzymania pozycji rynkowej. Stopniowo ulepszając system i dodając nowe funkcje, byliśmy w stanie zmodernizować go w ciągu roku, zapewniając jednocześnie nieprzerwane działanie. Nasze podejście koncentrowało się na jednym module na raz, pozwalając zespołowi na zwiększenie funkcjonalności przy jednoczesnym zachowaniu normalnej działalności.
A jeśli chcesz dowiedzieć się więcej, mamy już pełne studium przypadku tutaj
Kiedy bazowanie na istniejących rozwiązaniach nie zadziała?
Bazowanie na istniejącym rozwiązaniu ma pewne zalety. W poprzednim przykładzie głównym czynnikiem decydującym o wyborze rozwiązania było upewnienie się, że wszystko przebiega zgodnie z planem, przy jednoczesnym szybkim wdrożeniu zmian. W tym przypadku był to właściwy wybór. Ale nie będzie to działać we wszystkich sytuacjach, więc należy pamiętać o następujących kwestiach.
Odbudowa może kosztować więcej
Bez przebudowy istniejącego rozwiązania może dojść do sytuacji, z której nie będzie wyjścia. A to może kosztować więcej w dłuższej perspektywie.
Na przykład patrzysz na obecną sytuację rynkową i myślisz: "Brakuje nam tej funkcji", ale ze względu na istniejące rozwiązanie możesz nie być w stanie szybko wdrożyć zmian. Co gorsza, obejście może kosztować znacznie więcej.
Dobrym tego przykładem są aplikacje natywne dla chmury. Jeśli zdecydujesz się przenieść swój projekt do chmury, posiadanie niestandardowej aplikacji, która jest gotowa na chmurę, jest znacznie łatwiejsze niż próba przeciągnięcia starych rozwiązań do tego samego stanu.
Ogranicza wybór technologii
Kolejną wadą jest ograniczenie wyboru technologii. Nie zawsze jest to problem, ponieważ wiele technologii może ze sobą współpracować, ale niektóre technologie są lepiej dostosowane do określonych projektów. I znowu, możesz znaleźć się w sytuacji, w której dodawanie nowych funkcji może być trudniejsze z powodu konfliktów.
Jednym z przykładów może być tworzenie aplikacji cross-mobile. Projektowanie zarówno dla Androida, jak i iOS jest możliwe, pomyśl o React Native, ale jeśli jesteś już ograniczony do jednej technologii, może to nie być wykonalny wybór.
Możesz nie być w stanie znaleźć odpowiednich specjalistów
I wreszcie, istnieje rynek dla inżynierów oprogramowania. Pomyśl o podaży i popycie. Jeśli rozpoczynasz projekt w określonej technologii, ogranicza cię to do ekspertów dostępnych w danym momencie.
Tak więc, gdy rozpoczynasz projekt z konkretną technologią, możesz nie być w stanie znaleźć odpowiednich specjalistów.
Tworzenie niestandardowego oprogramowania
W drugim studium przypadku przyjrzymy się sytuacji, w której tworzenie niestandardowego oprogramowania było właściwym wyborem i dlaczego. I znowu, zacznijmy od tła.
Kontekst
USA-AUTO-ONLINE zajmuje się skupem i wysyłką samochodów z USA do Polski. Działalność klienta szybko się rozwijała, a USA Auto Online chciało poprawić doświadczenia użytkowników końcowych. Jednak ich stary portal nie był w stanie obsłużyć dużej liczby dostępnych aukcji i rosnącej liczby odwiedzających. Nie mógł również wspierać ich planów ekspansji.
Ich oryginalna platforma borykała się z kilkoma problemami. Powolny czas ładowania i wyższe koszty utrzymania w chmurze.
Chociaż możliwe było dodanie do starego rozwiązania, koszt dodania nowych funkcji byłby znacznie większy niż rozpoczęcie od zera. Dlatego w dłuższej perspektywie byłoby to droższe.
Nie było też gwarancji, że obecne rozwiązanie poradzi sobie z planowanymi zmianami. Mogliśmy znaleźć się w sytuacji, w której zapędzilibyśmy się w kozi róg. Oznaczałoby to, że poświęciliśmy dużo czasu (i pieniędzy) i nadal musielibyśmy przebudowywać system.
Zamiast wkładać wiele wysiłku w rozwiązanie istniejących problemów, obie strony zdecydowały, że najlepszym rozwiązaniem będzie rozwiązanie niestandardowe. Ze starego systemu byliśmy w stanie wyodrębnić MVP i szybko go przebudować. Dla firmy oznaczało to normalną pracę , podczas gdy my skoncentrowaliśmy się na dodawaniu funkcji typu "nice-to-have".
Szybka odpowiedź
Tworzenie niestandardowego oprogramowania wymaga czasu. Aby złagodzić ten negatywny wpływ, zespół zrobił dwie rzeczy.
- Zaczynając od nisko wiszących owoców, zespół wprowadził kilka mniejszych funkcji do starego systemu. Pomogło to złagodzić istniejące problemy na kilka miesięcy, podczas gdy nowa aplikacja była budowana.
- Jak najszybsze wprowadzenie nowego systemu jako MVP.W tym przypadku zespół zbudował projekt wokół podstawowych funkcji, aby szybko doprowadzić go do stanu gotowości. Z planem dodania dodatkowych funkcji w miarę upływu czasu.
Jest to jedna z zalet tworzenia oprogramowania na zamówienie, z odpowiednią architekturą, nowe funkcje mogą być dodawane bez obawy o napotkanie blokady.
Wynik
Wprowadziliśmy duże ulepszenia w zakresie wydajności aukcji. Aukcje ładują się teraz 10 razy szybciej, a złożone zapytania z filtrami są 100 razy szybsze. Zoptymalizowaliśmy również aktualizacje aukcji z 2 godzin do zaledwie 7 minut.
W tym przypadku decyzja o zbudowaniu niestandardowego oprogramowania była motywowana tym, że stary portal nie był w stanie zaspokoić potrzeb klienta. Jednocześnie upewniając się, że nowy system może zostać zaktualizowany o nowe funkcje przy niższych kosztach.
Jeśli chcesz dowiedzieć się więcej o USA-AUTO-ONLINE, tutaj znajdziesz pełne studium przypadku.
Ile kosztuje tworzenie niestandardowego oprogramowania?
Myślę, że ważne jest również, aby zająć się słoniem w pokoju, a mianowicie kosztami. Tworzenie oprogramowania na zamówienie wiąże się z wyższymi kosztami początkowymi niż budowanie na istniejących rozwiązaniach. Jest to kwestia, którą wiele osób bierze pod uwagę w pierwszej kolejności.
Jednak w tym przypadku, ze względu na oszczędności w wydajności, ogólne koszty eksploatacji strony internetowej spadły, zapewniając oszczędności w dłuższej perspektywie. I choć bazowanie na istniejących rozwiązaniach może wiązać się z niższymi kosztami początkowymi, może ostatecznie kosztować więcej. W poprzednim przykładzie wdrożenie zmian wiązałoby się z wyższymi kosztami, ponieważ wymagało więcej czasu (czyli wynagrodzeń) na dostarczenie nowych funkcji.
W obu przypadkach, cel projektu będzie dyktował, które podejście może być bardziej kosztowne.
Podsumowanie punktów
W obu poprzednich przykładach decyzja o wyborze jednego podejścia była podyktowana potrzebami klienta. Jednakże, jako podsumowanie tych punktów, chciałem podzielić się ogólnymi wskazówkami na temat zalet i wad każdego podejścia.
Zalety korzystania z istniejących rozwiązań:
- Oszczędność czasu - czas wprowadzania nowych funkcji na rynek jest krótszy (w porównaniu z czasem potrzebnym na przebudowę całego systemu od podstaw).
- Opłacalność w krótkim okresie - eliminuje potrzebę budowania od podstaw.
- Bezproblemowa integracja - kompatybilność z istniejącymi systemami.
- Znajomość użytkownika - Płynne przejście dla użytkowników.
Wady bazowania na istniejących rozwiązaniach:
- Ograniczenia techniczne - potencjalne ograniczenia dotyczące funkcji i technologii.
- Problemy ze starszymi rozwiązaniami - złożoność i utrudniona skalowalność.
- Ograniczona elastyczność - ograniczenia w zakresie innowacji i nowych technologii.
- Zależność od wcześniejszych decyzji - ograniczenia projektowe wynikające z istniejącej architektury.
- Zwykle na dłuższą metęjest to droższe i bardziej czasochłonne.
Zalety tworzenia oprogramowania na zamówienie:
- Pełna kontrola - dostosowanie do potrzeb projektu.
- Wdrożenie nowoczesnych technologii - Wykorzystanie najnowszych technologii.
- Większa elastyczność - dostosowanie systemu do konkretnych wymagań.
- Czyste konto - możliwość poprawy wydajności i jakości kodu.
- W dłuższej perspektywie, w przypadku projektów planowanych na lata,jest to podejście opłacalne.
Wady tworzenia oprogramowania na zamówienie
- Czasochłonność - budowanie całego systemu od podstaw.
- Zwiększone koszty - Wyższe początkowe inwestycje w rozwój i testowanie.
- Wyższe ryzyko - potencjalne opóźnienia i nieprzewidziane wyzwania.
- Adaptacja użytkownika - krzywe uczenia się i potencjalny opór przed zmianami.
Wnioski
Jaki jest więc właściwy wybór? Zacząć od zera czy wykorzystać to, co już mamy. Odpowiedź leży po stronie projektu. Nie ma magicznej formuły na odpowiedź na to pytanie. Zanim zdecydujesz się na jedno podejście, musisz mieć pewność co do następujących kwestii.
Jakatechnologia będzie najlepsza dla Twoich potrzeb? Jak duży jest projekt? Jakie są podstawowe funkcje? Co ma robić w przyszłości? Czy będzie musiał dostosowywać się do zmieniających się rynków? Jaki jest budżet? Jaki jest harmonogram? Czy masz własny zespół?
Wydaje się, że jest to długa lista rzeczy do rozważenia, ale tutaj powinieneś zaufać ekspertom, którzy pomogą Ci podjąć najbardziej świadomą decyzję dotyczącą Twojego projektu. Jeśli chcesz porozmawiać o najlepszym rozwiązaniu dla swojego projektu, możesz umówić się na spotkanie już dziś.