"Jeśli nie czujesz się zawstydzony pierwszą wersją swojego produktu, to wystartowałeś za późno." — Reid Hoffman W Splits stosujemy to podejście do budowania oprogramowania: najpierw spraw, żeby działało → potem zrób to dobrze → na końcu przyspiesz. Kolejność ma znaczenie. Oto czego nauczyliśmy się, realizując każdy etap:

Spraw, aby to działało = funkcjonalny prototyp. Powinno być surowe. Powinno być niedoskonałe. Szybko pokaż to użytkownikom. Jak określamy MVP: 1) Wypisz wszystko, co uważamy za ważne lub istotne dla projektu. 2) Jaki jest *absolutny minimalny* element z tej listy, który możemy ukończyć i mieć funkcjonalny prototyp?

Zrób to dobrze = napraw wszystkie zepsute elementy. Wejdź w tę fazę z wyraźnymi sygnałami z rynku: konsekwentne opinie, rosnące wykorzystanie pomimo oczywistych wad. Teraz zasłużyłeś na to, aby zainwestować więcej zasobów.

Zrób to szybko = zoptymalizuj wydajność. Szczerze mówiąc, wciąż uczymy się o tej fazie. Większość zespołów jest obecnie w trybie "zrób to dobrze" 🤷‍♂️ Ale oto inspiracja, która nas napędza:

Dlaczego to podejście działa: Sekwencjonowanie to strategia. To, czego uczysz się dzisiaj, kształtuje to, co zbudujesz jutro. Przeskakując do przodu, nie masz informacji potrzebnych do prawidłowego rozwiązywania problemów. Działanie produkuje informacje. Ale *zamierzone* działanie produkuje *bardziej użyteczne* informacje.

Pułapka polega na próbie naprawienia czegoś w tym samym czasie, gdy starasz się to zrealizować. NIE. "Daj sobie pozwolenie na wysłanie czegoś, co wiesz, że nie jest w porządku." — @wminshew