Prostota czy elastyczność produktu?

Każda decyzja w produkcie cyfrowym albo coś domyka, albo zostawia otwarte. I obie opcje mają rację jednocześnie.

Dlaczego warto domykać?

Bo prostota jest tania i szybka. Im prostszy produkt, tym taniej go utrzymać, tym szybciej dowozisz, tym łatwiej użytkownik go rozumie. Każda wycięta funkcja to mniej kodu, mniej decyzji, mniej rzeczy, które mogą się zepsuć. Zespół, który domyka, idzie szybciej dziś.

W programowaniu ta strona ma swoją zasadę: YAGNI, You Aren’t Gonna Need It. Martin Fowler opisuje jej koszt wprost: funkcja zbudowana „na zapas” kosztuje budowę, opóźnia to, co potrzebne teraz, i dokłada złożoności, którą trzeba nosić. Często okazuje się też, że gdy potrzeba w końcu przychodzi, wygląda inaczej, niż zakładaliśmy.

Dlaczego warto zostawiać opcje?

Bo rynek się zmienia, a hipotezy padają. Produkt, który zabetonował jedną drogę, płaci za każdy zwrot przepisaniem. Każda zachowana opcja to ubezpieczenie od dnia, w którym założenie okaże się błędne. Zespół, który zostawia luz, przetrwa zmianę jutro.

Carliss Baldwin i Kim Clark opisali modułową architekturę językiem opcji finansowych. Granica między modułami jest opcją: pozwala wymienić jeden element bez ruszania reszty. Taka opcja ma wartość tym większą, im większa niepewność. Podobnie działa agile jako opcjonalność: krótkie iteracje kupują prawo do zmiany zdania.

Czy da się mieć jedno i drugie?

Nie da się mieć obu naraz. Prostota dziś kupowana jest sztywnością jutro. Elastyczność jutro kupowana jest złożonością dziś. Każdy wybór po jednej stronie odbiera coś po drugiej.

Tego napięcia nie rozwiązuje się raz. Wraca przy każdej większej decyzji: przy wyborze bazy danych, przy projektowaniu API, przy decyzji, czy funkcja ma być konfigurowalna.

Jak słaby zespół rozstrzyga to napięcie?

Nawykiem. Zawsze domyka, bo „nie komplikujmy”, albo zawsze zostawia furtki, bo „a co jeśli”. Pierwsze daje produkt, który nie nadąża za rynkiem. Drugie produkt, którego nikt nie umie utrzymać.

Drugi nawyk jest bliski temu, przed czym ostrzegał Donald Knuth, pisząc o przedwczesnej optymalizacji. Elastyczność dodana „na wszelki wypadek” jest optymalizacją pod przyszłość, której jeszcze nie znamy.

Jak mocny zespół podejmuje takie decyzje?

Osobno dla każdej decyzji. Pyta: czy to założenie jest na tyle pewne, że warto za nie zapłacić sztywnością? Tam, gdzie tak, domyka bez sentymentu. Tam, gdzie nie, płaci za opcję świadomie.

Kilka pytań, które pomagają ocenić założenie:

Ile kosztuje odwrócenie decyzji? Jeśli mało, domykaj i ucz się. Jeśli dużo, zastanów się dwa razy.
Co już wiemy? Założenie potwierdzone przez dane z rynku można domknąć. Założenie z prezentacji zarządu warto zostawić otwarte.
Kiedy dowiemy się więcej? Jeśli za miesiąc, czasem lepiej poczekać z decyzją, zamiast budować furtkę.
Kto zapłaci za złożoność? Opcja, którą utrzymuje zespół przez lata, kosztuje więcej, niż widać w dniu jej dodania.

Dobra strategia produktowa polega na tym, by wiedzieć, którą z nich kupujesz przy każdej decyzji i jaką cenę za to płacisz.

Bibliografia

Baldwin, C. Y., Clark, K. B. (2000). Design Rules, Vol. 1: The Power of Modularity. MIT Press.
Fowler, M. (2015). Yagni. martinfowler.com/bliki/Yagni.html.
Knuth, D. E. (1974). Structured Programming with go to Statements. ACM Computing Surveys, 6(4), 261–301.

💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem

Ten o domykaniu i opcjach