Produkt z bazaru

Im prostszy produkt, tym lepiej. Im prostszy produkt, tym więcej zastosowań może znaleźć… wymyślonych przez samych użytkowników.

Złapałem się na tym, że skupiony na analizie danych i próby ich zamknięcia w algorytm, zapomniałem o niekatedralnym rozwoju produktu. Jeśli ktoś nie jest zaznajomiony z dychotomią katedra — bazar w budowaniu software/produktu IT, to wyjaśnię krótko. Oryginalny artykuł z 1997 r. dot. rozwoju oprogramowania typu open source. Twórca koncepcji, Eric S. Raymond przedstawił na przykładzie Linuxa dwa podejścia w software development: katedra rozumiana jako rozwój up-bottom oraz bazar, czyli odwrotny kierunek. Skupił się na samym kodzie źródłowym. W przypadku katedry, twórcy oprogramowania robią nowe wersje aplikacji, pracując nad nimi w “murach katedry”, do której nikt nie ma dostępu poza samymi twórcami. Bazar jest przeciwieństwem katedry — każdy ma dostęp do kodu źródłowego i może nad nim pracować, udostępniając go w ten sam sposób innym. Najlepszym przykładem podejścia bazarowego jest dzieło Linusa Torvaldsa.

Nie przekłamię rzeczywistości, jeśli napiszę, że model katedry dominuje we współczesnym software engineering. Jego upowszechnienie powoduje, że kolejni programiści rzadko zastanawiają się nad alternatywami. O ile pierwotny artykuł dotyczył głównie przewagi open source nad zamkniętymi projektami, to dychotomię katedra — bazar należy postrzegać zdecydowanie szerzej. W moim przypadku — w krojeniu nowego produktu na potrzeby użytkownika.

Zrobić wstępne badania rynkowe, ankiety, może nawet pogłębione wywiady czy grupy fokusowe. Opracować specyfikację produktu, założenia funkcjonalności. Przygotować prototyp i betę. Zapytać jeszcze raz o opinię end-userów. Wnieść trochę poprawek. Wydać końcowy produkt. Oooops. Produkt nie trafił w potrzeby użytkownika.

Po prześledzeniu X takich przypadków, zaczynam znajdować podobieństwa. Niby są robione badania wśród użytkowników, ale pojawiają się z nimi dwa problemy: 1) są robione jako coś dodatkowego, a nie podstawowy (definiujący) element planu produktowego; 2) badania obejmują tylko część zagadnień — reszta jest dodawana w trakcie produkcji bez sprawdzenia, czy powinny zostać dodane. Twórcy, zamknięci w swojej wysokiej wieży katedralnej, pracując w pocie czoła nad czymś, co w ich mniemaniu lud na bazarze potrzebuje. Lud jednak nie potrzebuje nowej encyklopedii botanicznej, a zwykłej motyki do uprawiania tychże roślin (taki przykład jako coś skomplikowanego i trudnego w odczycie, a prostego i użytecznego).

Dlatego bazaar-product development jest nie tylko hipsterską alternatywą, ale czymś co przynosi wymierne korzyści, zarówno twórcom (np. mniejsze koszty), jak i odbiorcom (wreszcie mają produkt, który potrzebują).

Z tego względu postanowiłem trochę zmienić kierunek rozwoju Knee Wearable i czym prędzej przejść do pre-alfa testów. Tak, pre-alfa, ponieważ do alfy jeszcze nam brakuje. Nie chcę tworzyć produktu, rozmijającego się z potrzebami grupy, na której najbardziej mi zależy. Nie jestem w stanie wymyślić wszystkich zastosowań urządzenia. Chcę stworzyć narzędzie, którego zastosowanie znajdą sami użytkownicy. Doszedłem do takiego wniosku podczas wczorajszego treningu, gdy zorientowałem się, że rozwijany produkt nie spełnia moich własnych wymagań.

W najbliższych dniach (oby) powinienem wrzucić tutaj, jak również na profil FB, zaproszenie do pre-alfa testów. Dostarczymy prototyp z kawałkiem softu. Co wy już z tym zrobicie… to my chętnie posłuchamy.

W katedrze Kościoła czy uniwersytetu przekaz jest jednokierunkowy — kaznodzieja lub profesor mówi, reszta słucha. Na bazarze wszyscy mówią i wszyscy słuchają.