Więcej...

Dlaczego wszystko jest dziś niedokończone?

12.05.2019  | Twardowski
Dlaczego wszystko jest dziś niedokończone?

Doskonale pamiętam dzień, który zdefiniował moją muzyczną twórczość na następne sześć lat. Był to mroźny dzień w listopadzie 2011 roku, kiedy kurier dostarczył mojego upragnionego Octatracka. Później były dwie najgorsze godziny czekania żeby doszedł do temperatury pokojowej, następnie zaś TOTALNY MINDFUCK po włączeniu i tydzień intensywnej nauki. Po dwóch tygodniach już byłem pewien, że Octatrack będzie centrum mojego sprzętowego setupu i rzeczywiście był nim przez sześć lat lat. Zrobiłem na nim trzy i pół płyty (dlaczego "i pół" wyjaśnię kiedy indziej) i, mimo że lubiłem i nadal lubię ten sampler, przez cały ten czas miałem poczucie, że pracuję na niekompletnym i niedokończonym urządzeniu.

Często łapałem się na myśleniu, że "jak dodadzą tą i tą funkcję to będzie najlepsza maszyna ever" jednocześnie będąc zadeklarowanym "zaawansowanym elektronowcem" - autentycznie chlubiłem się tym, że potrafię na nim robić utwory od początku do końca mimo istotnych ograniczeń sprzętu i systemu operacyjnego. Doskonale wiedziałem jak obchodzić lub kreatywnie wykorzystywać braki i ograniczenia. Jednocześnie cały czas miałem nadzieję, że jutro będzie ten dzień, kiedy wyjdzie nowy OS i będą w nim wszystkie rzeczy, których mi brakuje, obiecywane przez producenta od dnia premiery. Byłem też aktywny w społeczności użytkowników, wysyłałem developerom swoje propozycje upgrade’ów. Wciągnąłem się w ten sprzęt do tego stopnia, że kiedy stało się jasne, że firma całkowicie skupiła się na nowych produktach - serii Analog (które zresztą też kupiłem i oprawiłem w drewno u stolarza na Powązkach), byłem zdeterminowany, żeby zrobić własny, nieoficjalny system operacyjny / nakładkę na istniejący OS / nieoficjalny update, który zawierałby wszystkie moje upragnione a także te obiecane funkcje… Ostatecznie, po sześciu latach, doszedłem do wniosku, że po prostu muszę przebudować swój setup i zmienić to centralne urządzenie i - co za tym idzie - cały swój workflow. Żeby była jasność: nie staram się powiedzieć, że czuję się oszukany, nie mam też poczucia, że zmarnowałem te sześć lat inwestując swój czas w jeden sampler. Wprost przeciwnie - uważam, że zrobiłem na nim fajne rzeczy i dużo się nauczyłem z logiki tego urządzenia. Nauczyłem się też jeszcze jednej istotnej rzeczy: żeby, inwestując czas i pieniądze w sprzęt, najpierw szacować jego faktyczne możliwości a nie potencjał i zapowiedzi.

Doskonale wiedziałem jak obchodzić lub kreatywnie wykorzystywać braki i ograniczenia urządzenia. Jednocześnie cały czas miałem nadzieję , że jutro będzie ten dzień, kiedy wyjdzie nowy OS i będą w nim wszystkie rzeczy, których mi brakuje, obiecywane przez producenta od dnia premiery.

Przygoda z Octatrackiem i wnioski z niej płynące są absolutnie moją indywidualną refleksją, jednak Elektron jest ogólnie ciekawym przykładem: to firma, która miała przez lata chlubną reputację stale rozwijającej swoje produkty, także długo po premierze. Tę reputację udało się utrzymywać, mimo iż bodaj każde ich urządzenie w dniu swojej premiery trafiało do sprzedaży z systemem operacyjnym w wersji niższej niż 1.00 i wyrażoną wprost obietnicą, że są drobne bugi, czegoś brakuje, ale to się zaraz zmieni i każda kolejna wersja będzie czymś jeszcze większym niż użytkownik oczekiwał. I w tej praktyce - wypuszczaniu w świat niepełnych produktów - nie są odosobnieni. Ta praktyka jest powszechna. Przykłady? DSI Tempest, wypuszczony bez paru podstawowych funkcji, z ostatnim update wymuszonym petycją użytkowników; Pioneer Toraiz SP-16 z bardzo biednym OS-em, do którego na przestrzeni dwóch latach dodawano to, co powinno być od początku; wiecznie niedokończone Teenage Engineering OP-1, które doczekało się nawet grupy entuzjastów przeszukujących kod, próbując na własną rękę "dokończyć" urządzenie. Osobnym tematem, jest seria starszych MPC i osławiony JJOS - customowy system operacyjny, stworzony przez byłego pracownika Akai, rzekomo z poczucia irytacji brakiem ważnych rzeczy. Przykładów nie brakuje i wszystko wskazuje na to, że ta tendencja się utrzyma: kupując sprzęt w dniu premiery, coraz częściej kupujemy obietnicę, potencjał i zapowiedzi.

Ponadto, kupując niedokończone produkty, dajemy się wciągać w proces tworzenia - w najgorszym tego rozumieniu. Kiedy użytkownik, który z założenia ma być konsumentem gotowego produktu, wciągany jest w proces developmentu, staje się w zasadzie kimś w rodzaju kolejnego beta testera. Mówiąc bardziej brutalnie: decydując się na zakup urządzenia, które jest niepełne, trochę się frajerzymy, ponieważ nie dość że płacimy cenę pełnowartościowego, dokończonego produktu, to jeszcze dorzucamy do tego swoją mimowolną pomoc w wyłapywaniu błędów - procesie, który powinien być dokonany zanim produkt trafi do użytkownika, procesie, który powinien być wewnętrzny i realizowany przez opłaconych przez producenta specjalistów… Tak teraz wygląda realia produkcji sprzętu muzycznego. Ale nie tylko: myślę, że można śmiało założyć, że takie praktyki są stosowane w tworzeniu każdego urządzenia lub programu, który można update’ować przez internet. Jedyne co pozostaje płynne, to granica, po przekroczeniu której, twórca uznaje swój produkt za gotowy - ta granica jest płynna, ponieważ każdy produkt jest inny, ale też dlatego, że to "ukończenie" jest tylko i wyłącznie wyrazem dobrej woli i deklaracji producenta.

W moim odczuciu, najbardziej jaskrawym przykładem branży, która zabrnęła za daleko opierając się na takich praktykach, są gry wideo. Jest to gigantyczna branża, według niektórych metryk większa od filmowej. Gry mają budżety porównywalne z hollywoodzkimi filmami, jednak coraz częściej, w momencie swojej premiery, są po prostu zepsute: od błędów technicznych, przez brak jakiegoś elementu, utrudniającego lub wręcz uniemożliwiającego granie, aż po niezbalansowaną rozgrywkę, tworzącą niezamierzone, nienaturalne skoki trudności. Mimo to, gracze kupują nawet miliony egzemplarzy pojedynczej gry w preorderze, płacąc cenę za pełnowartościowy, dokończony produkt wiele miesięcy przed datą premiery. Często, przynętą jest obietnica, że zakup w preorderze, da możliwość zagrania przed premierą sklepową. Decydując się na to, stajemy się finalnymi testerami, kupujemy kota w worku i dorzucamy swoją mimowolną pomoc w wyłapywaniu błędów… Brzmi znajomo? Powinno, bo znowu się sfrajerzyliśmy, tyle że tym razem na grze za dwie stówy a nie na instrumencie za kilka tysięcy. W obu przypadkach jednak mechanizm jest ten sam i ta samo jest najgorsze: przyzwolenie, które dajemy płacąc za obietnicę produktu jak za gotowy produkt oraz to, że mimo że daliśmy się w to wciągnąć i przywiązać do niegotowego produktu, to producent uzurpuje sobie określenie, w którym momencie uzna swój twór za gotowy i skończony.

Nawiązuję do gier z jeszcze jednego powodu. W moim odczuciu bowiem, taki stan rzeczy wziął się z przeniesienia do innych branż praktyk pierwotnie wymyślonych i stosowanych w zarządzaniu projektowaniem oprogramowania. Chodzi o iteracyjne podejście do realizacji projektów. Twórca Scruma - jednej z metodyk tego podejścia, stosowanej powszechnie, także w branży gier - z rękawa sypie przykładami dziedzin innych niż projektowanie oprogramowana, w których taką metodykę z powodzeniem zastosowano: od planowania domowego remontu, poprzez organizację zajęć z chemii w holenderskiej szkole średniej aż po produkcję samochodów. To bardzo modna (bo przynosząca doskonałe efekty) metodyka i kiedy patrzę zarówno na moją półkę z grami, jak i na moją półkę z instrumentami muzycznymi, jestem przekonany, że wszystkie powstały w oparciu o nią. Po pierwsze dlatego, że praktycznie każdy instrument ma w sobie jakieś oprogramowanie a po drugie - tym bardziej jestem tego pewien, kiedy widzę produkt rozwijany także po premierze. Dlaczego? Bowiem, w dość dużym uproszczeniu, iteracyjne podejście zakłada, że pracę dzieli się na krótkie etapy (sprinty) a każdy taki etap kończy się wygenerowaniem funkcjonalnego elementu lub prototypu produktu. Czyli, jeśli na przykład produkuję w ten sposób sampler, w trakcie jednego etapu pracuję nad funkcją slice’owania sampli a na zakończenie tego etapu muszę pokazać funkcję slice działającą jak w gotowym produkcie. I tak systematycznie dokładam, mając na bieżąco możliwość sprawdzenia czy wszystko działa (bo przecież generuję kolejną wersję na końcu każdego etapu). Wszystko jest super, ale w pewnym momencie naturalnie przyjdzie pokusa: może mam już wystarczająco dużo żeby pokazać ten sampler? A może mam wystarczająco dużo, żeby zacząć sprzedawać ten sampler? Przecież będę generował kolejne iteracje, dokładające kolejne funkcje i mogę to tak samo robić już po sklepowej premierze!

Kupując sprzęt w dniu premiery, coraz częściej kupujemy obietnicę, potencjał i zapowiedzi. Ponadto, kupując niedokończone produkty, dajemy się wciągać w proces tworzenia - w najgorszym tego rozumieniu.

Niestety taka pokusa jest wręcz wbudowana w tak zorganizowany proces. I to z jak najlepszych pobudek: filozofia Scruma zakłada, że cały proces produkcyjny jest otwarty, transparentny, dostępny na każdym etapie dla każdego i tym samym angażujący klienta. I właśnie żeby wykonana praca była mierzalna i widoczna także dla managera/zamawiającego/inwestora, który przecież nie musi się znać na tajnikach programowania, na koniec etapu generuje się te działające prototypy. Łatwo sobie wyobrazić w tym miejscu inwestora nastawionego na uzyskanie jak najszybciej jak najwyższego zwrotu z inwestycji. Inwestora, dla którego proces mający optymalizować pracę zespołową jest jakąś idealistyczną mrzonką. Inwestora, który sobie myśli: "to co mi dzisiaj pokazali spokojnie mogłoby trafić do sklepów". Trudniej zaś sobie wyobrazić, żeby konsument, czy też jak kto woli - end user - miał wgląd w tworzenie produktu wcześniej, niż kiedy ów produkt trafi na rynek. Można więc postawić argument, że sprzedając niepełny produkt, realizuje się właśnie zaangażowanie klienta w tworzenie, ale od razu na zdrowy rozsądek widać, że to bardzo duże nadużycie - pomylenie definicji i postawienie tej metodyki na głowie. Wspomniany wcześniej autor Scruma - Jeff Sutherland - jest w ogóle fascynującym człowiekiem: skończył akademię wojskową West Point, służył jako pilot w misjach zwiadowczych trakcie wojny w Wietnamie, odpowiadał za wdrożenie bankomatów, doradzał licznym firmom i potem spisał swoje dobre rady. Co więcej, Sutherland jest dogłębnie przekonany, że Scrum uratuje cały świat przed zagładą jeśli zastosujemy go odpowiednio szeroko, bo będziemy super produktywni, nauczymy się pracować zespołowo i zaczniemy dostrzegać wyższe cele a nie tylko czubek własnego nosa. To naprawdę wielki paradoks, że tą naprawdę sensowną i popartą wynikami ideę tak łatwo jest postawić na głowie, manipulując udziałem klienta w procesie produkcyjnym i upłynniając definicję gotowości produktu.

Z tego wszystkiego rysuje się dość smutny obraz, ale jestem sobie w stanie wyobrazić przynajmniej jeden nieoczekiwany pozytyw: świadomość, że niedokończone produkty są sprzedawane jako gotowe, bardzo skutecznie gasi zapędy do impulsywnego kupowania. A przynajmniej powinna, ponieważ nic się nie zmieni, dopóki to my - konsumenci - nie przestaniemy dawać producentom przyzwolenia wciąż kupując. Albo też możemy być cyniczni i przyłączyć się do tego procesu i kiedy sami występujemy w roli twórców - twórców muzyki - też wypuścić niegotowy produkt i robić kolejne jego iteracje po premierze, tak jak Kanye West zrobil z TLOP. Każdemu zaś, kto uważa, że takie albumy to przyszłość muzyki, serdecznie polecam ten esej i próbę postawienia się w roli konsumenta na końcu łańcucha.