Przeczytaj wersję webową.

Buy vs Build – 4 koszty

2024-09-09

Cześć!

W ramach dzisiejszego wydania skupimy się na problemie, który często nie daje spać po nocach liderom technicznym – Buy vs Build. Przedstawimy 4 koszty, które warto liczyć w ramach wyboru odpowiedniego podejścia.

Dodatkowo czeka na Ciebie Inżynierska prasówka.

A więc w dzisiaj mam dla Ciebie:

Miłego czytania 😀


Inżynierska prasówka

Rozpoczynamy nauki myślenia jak architekt. Kończymy case study z DDD i modernizacją legacy. A pomiędzy problemy klientów, wyzwania inżynierskich liderów i stan Code Review w branży. Zapraszam!

  1. Think like an architect: a mental model for designing your softwares - Luca Mezzalira
    Do swojego podcastu, Luca zaprosił nikogo innego, jak Rajdeep Sahaii oczywiście wyszła z tego niesamowicie ciekawa rozmowa. Tematyka obracała się wokół modeli mentalnych wymaganych przy projektowaniu rozwiązania.
    Wyszła z tego wnikliwa rozmowa na temat wielu wymiarów, jakie są istotne podczas pracy z architekturą: struktura logiczna rozwiązania, umiejętności miękkie współpracy z interesariuszami, wymagania funkcjonalne i atrybuty jakościowe. Przekrój jest szeroki.
    https://www.youtube.com/watch?v=9gEtY4Pb_8g

  2. Stop inventing product problems; start solving customer problems - Pavel Samsonov
    Lubię czytać treści Pavela, ze względu na jego mocno krytyczne spojrzenie na obszar Produktowy, UX i techniczny. W najnowszym artykule przedstawia argumenty przeciwko pracy opartej na problemach produktowych.
    Dlaczego? Zbyt często skupiamy się jedynie na tym, by dowieźć cele naszego produktu – kolejne funkcje. Zapominamy jednocześnie, co jest tak naprawdę celem naszego klienta. Obszar techniczny kończy na Resume-Driven Development – dostarcza błyskotki techniczne, zamiast rozwiązywać problemy klientów.
    https://uxdesign.cc/stop-solving-product-problems-start-solving-customer-problems-6c9cf3e28db3

  3. Rising to engineering leadership challenges at Honeycomb - Emily Nakashima
    Nie ma to jak solidna dawka opowieści z okopów. Takimi dzieli się właśnie Emily w podcaście Engineering Unblocked.
    Opowiada o tym, w jaki sposób Honeycomb pracuje nad tym, aby cała organizacja dostarczała efektywnie i jakościowo. Przytaczane są interesujące przykłady struktur organizacyjnych, kooperacji, celów. Bardzo dużo wartościowej wiedzy wprost od liderów branży.
    https://www.unblocked.fm/episodes/emily-nakashima-honeycomb/

  4. State of code review 2024 – Graphite
    Ten artykuł wzbudził ostatnio dużo kontrowersji na moim LinkedInie. Graphite zebrał od swoich klientów informacje o stanie Code Review na rok 2024.
    Dostajemy przekrojowe podsumowanie firm korzystających z Code Review, wielkości idealnego PR, czy czasów CI. Warto przeczytać, by się porównać i wyrobić sobie własną opinię o stanie branży.
    https://graphite.dev/blog/state-of-code-review-2024

  5. How Domain-Driven Design scaled a Big Ball of Mud product - Kenny Baas-Schwegler
    Kolejna historia z branży. Kenny dzieli się case study z wykorzystania DDD, aby usprawnić istniejący system Legacy.
    Otrzymujemy szczegółową prezentację wraz z technikami wykorzystanymi przez Kenniego – Wardley Mapping, Problem Space, Event Storming, Legacy Modernization, Idealized Design. Świetne studium wyzwań, ale również przykład tego, jak sobie z nimi poradzono.


Koszty dookoła Build vs Buy

Decyzja “kupić czy zbudować” to klasyczne starcie dwóch światów:

  • Buy: Sprawdzone rozwiązanie, szybkie wdrożenie, ale w ograniczona kontrola i możliwości dostosowania.
  • Build: Dokładnie to, czego chcemy, kosztem czasu i niepewnych wydatków.

W tym artykule nie będziemy się skupiać na tym jak zebrać wymagane funkcje i atrybuty jakościowe czy ocenie dostawców oprogramowania. Te aspekty są dokładnie omówione w artykule ThoughtWorks.

My natomiast zajmiemy się czymś równie istotnym, a często pomijanym - kosztami. Będziemy starali się określić co buduje Total Cost of Ownership.

4 koszty

Niezależnie od tego, czy kupujemy, czy budujemy, zawsze ponosimy koszty. To nie podlega dyskusji. Pytanie brzmi:

  • Czy faktycznie liczymy wszystko, za co płacimy?

Jeśli nie prowadzimy szczegółowych kalkulacji, łatwo wpaść w pułapkę.

  • Skupiamy się wtedy tylko na początkowym koszcie, zapominając o długoterminowych wydatkach.
  • Nie wliczamy pracy utrzymaniowej, która potrafi przerosnąć pierwotne założenia.
  • Co gorsza, poświęcamy cenny czas na budowanie czegoś, co niekoniecznie jest naszą przewagą konkurencyjną.

By uniknąć tych problemów, warto spojrzeć na zagadnienie szerzej. W kolejnych punktach przyjrzymy się czterem kluczowym kosztom, które zawsze powinniśmy brać pod uwagę.

Oto koszty, które omówimy:

IMG1.jpg

Aby nasza przygoda miała sens, warto ją oprzeć o przykład biznesowy.

E-commerce i system lojalnościowy

Wyobraź sobie, że prowadzisz prężnie działający sklep internetowy. Twój biznes rośnie, ale zauważasz, że klienci coraz rzadziej wracają po kolejne zakupy. Potrzebujesz czegoś, co zwiększy ich lojalność i zaangażowanie. System lojalnościowy z elementami gamifikacji wydaje się idealnym rozwiązaniem.

Na rynku istnieje już gotowe rozwiązanie - polska platforma Open Loyalty.

IMG2.png

Oferuje ona standardowe funkcje programu lojalnościowego, ale też zaawansowane elementy gamifikacji, jak wyzwania, odznaki czy rankingi. Brzmi kusząco, prawda?

Stoisz przed klasycznym dylematem: kupić licencję na Open Loyalty i dostosować narzędzie do swoich potrzeb, czy może zbudować własny system od podstaw? To właśnie na tym przykładzie będziemy się opierać w dalszej części artykułu.

(disclaimer – nie znam modelu sprzedażowego OL, więc poniższy opis traktuj jako założenia)

Koszt napisania

Koszt napisania to pierwszy z czterech kluczowych aspektów, które musimy rozważyć. Choć może się wydawać, że dotyczy on tylko opcji “build”, to w rzeczywistości pojawia się w obu scenariuszach.

W przypadku zakupu Open Loyalty (opcja “buy”), nie unikniemy kosztów związanych z integracją i konfiguracją.

  • Trzeba będzie dostosować system do naszego sklepu, co może zająć około 2-3 miesiące pracy zespołu 3-4 osobowego.
  • Zaangażowani są nie tylko developerzy (integracja API, customizacja interfejsu), ale też testerzy (sprawdzenie poprawności działania) czy specjaliści UX (dostosowanie wyglądu do naszej marki).
  • Do tego dochodzi czas na konfigurację reguł lojalnościowych, scenariuszy gamifikacji czy integrację z istniejącymi systemami (np. CRM, system mailingowy).

Z kolei budując własne rozwiązanie kosztem jest czas naszych ludzi poświęcony na dostarczenie danego rozwiązania.

  • Praca developerska jest najbardziej istotnym czynnikiem – koszt będzie znaczny.
  • Nie można pominąć jednak zaangażowania pozostałych ról - analityków biznesowych (określenie dokładnych wymagań), specjalistów UX/UI (zaprojektowanie interfejsu), ekspertów od gamifikacji (opracowanie angażujących mechanizmów).
  • Nie zapominajmy też o czasie na research, planowanie architektury czy tworzenie dokumentacji.

Ewidentnie szala przechyla się w stronę BUY – BUILD ma zdecydowanie wyższy koszt napisania. Czas wrócić na środek 😉

Koszt zakupu

Koszt zakupu to drugi kluczowy aspekt, który musimy wziąć pod uwagę. Choć intuicyjnie kojarzymy go z opcją “buy”, to w rzeczywistości dotyczy on obu scenariuszy - zarówno zakupu gotowego rozwiązania, jak i budowy własnego.

W przypadku zakupu Open Loyalty (opcja “buy”), musimy liczyć się z następującymi kosztami:

  • Licencja startowa na korzystanie z systemu.
  • Ewentualne dodatkowe moduły czy funkcje, które nie są w pakiecie podstawowym.
  • Koszty wdrożenia i szkoleń dla zespołu.
  • Potencjalne koszty customizacji, jeśli standardowe funkcje nie spełniają wszystkich naszych potrzeb.

Z kolei budując własne rozwiązanie (opcja “build”), pozornie unikamy kosztów zakupu. Ale czy na pewno?

  • Koszty narzędzi deweloperskich i licencji na oprogramowanie potrzebne do budowy systemu
  • Wydatki na infrastrukturę - serwery, bazy danych, systemy monitoringu
  • Koszty systemów do testowania i zapewnienia jakości
  • Ewentualne koszty konsultacji czy szkoleń dla zespołu w nowych technologiach

Wbrew pozorom, koszty zakupu w opcji “build” mogą się sumować do znaczących kwot. Nie dajmy się zwieść iluzji, że budując sami, wszystko mamy za darmo.

Koszt utrzymania

Koszt utrzymania to trzeci kluczowy aspekt, często niedoceniany przy podejmowaniu decyzji “buy vs build”. To właśnie on potrafi zaskoczyć nas w dłuższej perspektywie, niezależnie od wybranej opcji.

W przypadku zakupu Open Loyalty (opcja “buy”), musimy liczyć się z następującymi kosztami rekurencyjnymi:

  • Regularne opłaty za licencję - miesięczne lub roczne
  • Koszty wsparcia technicznego i utrzymania
  • Opłaty za aktualizacje systemu i nowe funkcjonalności
  • Potencjalne koszty związane ze skalowaniem - gdy nasz biznes rośnie, rosną też opłaty

Z kolei budując własne rozwiązanie (opcja “build”), koszty utrzymania mogą być mniej oczywiste, ale równie znaczące:

  • Czas zespołu poświęcony na bieżące utrzymanie i naprawę błędów.
  • Koszty aktualizacji systemu - zarówno pod kątem bezpieczeństwa, jak i nowych funkcji.
  • Wydatki związane z infrastrukturą - serwery, bazy danych, monitoring.
  • Koszty szkoleń i rozwoju zespołu, by nadążał za zmieniającymi się technologiami.

To jak z samochodem - nie wystarczy go kupić, trzeba go też tankować, serwisować, kupować AC i OC. Nasz system lojalnościowy to nasz “samochód” w świecie e-commerce - musimy o niego dbać, niezależnie od tego, czy kupiliśmy go w salonie, czy zbudowaliśmy w garażu.

W obu przypadkach koszty utrzymania mogą z czasem przewyższyć początkowe wydatki na wdrożenie.

Koszt utraconej szansy

Koszt utraconej szansy to czwarty, często pomijany aspekt decyzji “buy vs build”. To spojrzenie z zupełnie innej perspektywy, które może całkowicie zmienić nasze podejście do wyboru.

Posłużmy się cytatem z Investopedii:

Opportunity cost represents the potential benefits that a business, an investor, or an individual consumer misses out on when choosing one alternative over another.

Opportunity Cost, czyli Koszt Utraconej Szansy, to koncepcja ekonomiczna, która doskonale przekłada się na świat IT. W kontekście naszego systemu lojalnościowego wygląda to następująco:

  • Budując własny system (opcja “build”):
    • Poświęcamy czas i zasoby, które moglibyśmy wykorzystać na rozwijanie kluczowych funkcji naszego e-commerce.
    • Nie skupiamy się na tym, co naprawdę wyróżnia nas na rynku.
    • Ryzykujemy, że konkurencja nas wyprzedzi w innych obszarach.
  • Kupując gotowe rozwiązanie (opcja “buy”):
    • Możemy szybciej skupić się na tym, co naprawdę ważne dla naszego biznesu.
    • Wykorzystujemy czas i zasoby na innowacje w obszarach, które są naszą przewagą konkurencyjną.
    • Potencjalnie szybciej reagujemy na zmiany rynkowe i potrzeby klientów.

Kluczowe pytanie brzmi: czy budowa systemu lojalnościowego to naprawdę to, co wyróżni nas na rynku? A może lepiej kupić sprawdzone rozwiązanie i skupić się na innych, unikalnych aspektach naszego e-commerce?

Koszt utraconej szansy to nie tylko pieniądze - to także czas, innowacje i potencjalne zyski, które mogliśmy osiągnąć, zajmując się czymś innym.

Podsumowanie kosztów

Przyswoiwszy sobie całą tę wiedzę, możemy spróbować zebrać wszystkie koszty w jednym miejscu. To kluczowy krok, który pozwoli podjąć maksymalnie świadomą decyzję.

Oto przykładowa tabelka zbierająca koszty dla naszego systemu lojalnościowego:

Rodzaj kosztu Buy Build
Koszt napisania Integracja API, customizacja interfejsu, konfiguracja reguł Czas developerów, analityków, UX/UI designerów, ekspertów od gamifikacji
Koszt zakupu Licencja roczna, dodatkowe moduły, szkolenia Narzędzia deweloperskie, infrastruktura, systemy monitoringu
Koszt utrzymania Opłaty za wsparcie, aktualizacje, skalowanie Czas zespołu na utrzymanie, aktualizacje zabezpieczeń, rozwój funkcji
Koszt utraconej szansy Mniejsza elastyczność, uzależnienie od dostawcy Czas niepoświęcony na rozwój kluczowych funkcji biznesowych

Na podstawie takiego zestawienia możemy dopiero w sposób bardziej świadomy podejmować decyzję.

Pamiętajmy jednak, że nie chodzi tylko o liczby. Koszt utraconej szansy, choć trudny do dokładnego oszacowania, może mieć kluczowe znaczenie dla przyszłości naszego biznesu. Warto więc dokładnie przemyśleć, co jest dla nas najważniejsze w danym momencie i na czym chcemy skupić nasze zasoby.

Podsumowanie

Od kosztów, jak od podatków, nie da się uciec. Ale można kosztami zarządzać tak, by ponosić je w sposób świadomy i widoczny.

A Ty, o jakich kosztach nie pomyślałeś / pomyślałaś w ramach Build vs Buy? Co Cię zaatakowało w pewnym momencie projektu? Daj znać w odpowiedzi na maila 😊


📧 Prześlij dalej

Dzięki, że doczytałeś(aś) do końca. 😊

Wszystkie poprzednie wydania newslettera są dostępne tutaj.

Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję.

A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się.

Polecam się na przyszłość!
Radek Maziarka

Radek Maziarka
"Inżynierskie podejście do produktów cyfrowych."

P.S. Co myślisz o tym newsletterze? Odpisz :)