Katedra i Bazar: Jak stworzyć wielki i skomplikowany projekt, gdy masz mało zasobów i ludzi?

Wypromował ją swoim esejem (który potem został przekształcony w książkę) Eric Steven Raymond. I chociaż oryginalnie zarówno Katedra jak i Bazar dotyczyły projektów Open Source, to metodykę tą można z łatwością odnieść również do zamkniętych systemów, jak Ekademia, Windows, OSX, filmów i książek.

Zaskoczę Cię jednak. To nie jest artykuł o tym, co budujesz - piękną lecz niezmienną katedrę czy chaotyczny i żywy bazar.

To jest artykuł o tym JAK zbudować wielki projekt i jaką wybrać metodykę.

Katedra

Katedra jest budowana w pewnym sensie w ukryciu. Ludzie wiedzą, że coś jest budowane, może nawet coś widzą z zewnątrz, ale nie mają wstępu na plac budowy. Nie mogą cieszyć się i doświadczyć Katedry, póki nie zostanie skończona.

Metodykę Katedry - posuniętą do granic - stosuje Apple. Szczegóły nowego oprogramowania lub produktu poznajemy, gdy jest już gotowy lub prawie gotowy. Do prawie gotowego (beta, developer release) ma dostęp tylko nieliczna grupa developerów, lub ścisłych partnerów.

Klienci dzięki temu dostają do ręki doskonale działający, spójny i obłędnie (moje zdanie) wyglądający produkt z minimalną ilość problemów. NIE z małą, ale minimalną.

Ta metodyka jest najbardziej sexy - budujemy coś w tajemnicy miesiącami lub latami, odpalamy i cały świat pieje z zachwytu: “Jakie to cudowne!”. Taka premiera czegoś nieoczekiwanego daje też czasową przewagę nad konkurencją, która może zostać kompletnie zaskoczona naszym nowym produktem - tak jak Apple zaskoczyło świat iPhonem.

Dlaczego więc w ogóle zawracać sobie głowę jakąkolwiek inną metodyką?

Budowanie projektów w metodyce Katedry ma kilka poważnych wad, które sprawiły, że ostatecznie porzuciłem na razie plany i próby pracy w ten sposób nad wyglądem Ekademii.

PROBLEM 1: Zbudowanie Katedry wymaga bardzo szczegółowego planowania zanim cokolwiek zrobisz.

Jeśli chcesz zbudować coś tak skomplikowanego od początku do końca w sposób przemyślany, to najpierw musisz poświęcić ogromną ilość czasu na zaplanowanie tej rzeczy. Jeśli do tego ma to być tak skomplikowany system, jak Ekademia lub nawet jej wygląd (nie mówiąc o systemie operacyjnym typu OSX), planowanie staje się niezwykle trudne.

Musisz mieć albo wielu analityków i projektantów (jak Apple i inne duże firmy), albo BAAARDZO dużo czasu…. po którym jeszcze więcej spędzisz na budowaniu.

Można wybrać tę drogę, gdy masz nieprzebrane ilości gotówki na koncie od inwestora lub z długoletniej działalności, ale nie gdy budujesz projekt za własne pieniądze pochodzące z innej działalności. Specjalnie napisałem “projekt” a nie “startup”, bo ten drugi z definicji powinien rosnąć szybko.

Ekademię buduje z własnych dochodów ze szkoleń i kursów. Gdy buduję Ekademię albo pomagam Twórcom, nie zarabiam, ale za to buduję aktywa, które kiedyś będą zarabiały. Podejmuję spore ryzyko, ale podejmuję je bo wierzę w ten projekt - od 2007 r. - i dotychczas się nie myliłem.

Gdybym miał poświęcić rok pracy np. nad nowym projektem graficznym lub systemem pomocy do Ekademii, przez rok bym nie zarabiał i Ekademia też by nie zarabiała. Bo efekty tej pracy zaczęłyby pracować dopiero za rok. Gdybym zlecił to zewnętrznej firmie, całość kosztowałaby bardzo dużo pieniędzy ale i tak musiałbym poświęcać mój czas na konsultowanie postępów - siłą Ekademii jest to, że nie zbudował jej programista czy grafik, ale właściciel firmy wiedzowej, który sprzedaje każdy rodzaj wiedzy wykorzystując niemalże wszystkie dostępne metody sprzedaży.

Ten problem był dla mnie główną blokadą przed wdrożeniem nowego projektu Ekademii. Pierwotnie planowałem opracować nowy design dla wszystkich podstron (a różnych stron funkcyjnych jest kilkadziesiąt) i uruchomić go konkretnego dnia na jakiejś konferencji.

Sęk w tym, że zaprojektowanie przed jakimkolwiek wdrożeniem tak rozbudowanego systemu pod względem użyteczności i estetyki to potężne i prawdę mówiąc zniechęcające wyzwanie.

Z praktyki wiem, że w trakcie używania systemu często pierwotne założenia idą do kosza właściwie anulując większe części planu. Np. ostatnie przebudowy skończyły się wyeliminowaniem wydawałoby się kluczowych elementów Ekademii lub połączeniem ich z innymi.

Powiedzmy jednak, że poświęcimy kilka miesięcy na projektowaniu. Z gotowym planem - niczym budowniczowie wieżowca, zabieramy się za budowę i dosyć szybko zderzamy się z….

PROBLEM 2: Budowanie skomplikowanego projektu TRWA NIEMIŁOSIERNIE DŁUGO, a w metodyce Katedry przez ten cały czas NIKT nie widzi rezultatu.

Jakiś czas temu zrozumiałem różnicę między inspiracją i motywacją. Zrozumiałem też, dlaczego tak wiele osób nie dociera tam, gdzie planowali.

Inspiracja wynika z czegoś niesamowitego, przełomowego lub wielkiego. Np. zbudowanie Katedry jest inspirujące. Jak napisał Simon Sinek, murarze potrafili przez całe swoje życie stawiać mury czegoś, co nie zostało nawet ukończone za ich życia, ponieważ mogli powiedzieć: “Buduję Katedrę”, zamiast “Buduję mur”.

Przy czym Katedrę, w przeciwieństwie do software’u budowanego w tej metodyce, jednak widać. Widać, że powstaje, nawet jeśli nie można jej używać. Tworzenie czegoś takiego jest inspirujące. A inspiracja jest NIEZBĘDNA, aby ruszyć z czymkolwiek.

Sęk w tym, że inspiracja to za mało. Potrzebujesz jeszcze motywacji, aby wytrwać na długiej drodze do celu. A motywacja bierze się zupełnie z czegoś innego niż inspiracja.

Inspiracja jest wielka i rzadka. Motywacja bierze się z nawet niewielkich, ale CZĘSTYCH sukcesów. A te w metodyce Katedry są wewnętrzne - np. rozwiązanie jakiegoś poważnego problemu programistycznego daje satysfakcję aż do momentu, w którym zdasz sobie sprawę, że NIKT się nigdy o tym nie dowie.

To jest wielki test wytrwałości i cierpliwości nie tylko dla Ciebie, ale dla Twojej rodziny. Ty i Twoi bliscy kładziecie na szalę swoją przyszłość bez gwarancji, że będzie ona świetlana. Dlaczego? Ponieważ ryzykujesz...

PROBLEM 3: A co jeśli gotowa Katedra nie będzie się podobała?

Duże firmy, mające do dyspozycji tysiące projektantów, programistów i analityków, są w stanie dosyć dobrze przewidzieć, co będzie się podobało… a i tak wiele (a może nawet większość) produktów NIE okazuje się sukcesem.

Dla dużej firmy nieudany produkt to poważny cios, ale zwykle do przeżycia. Dla małej firmy spędzenie roku lub 2 lat na budowaniu potejemnie (czyli bez dochodów) czegoś, co ludziom się nie spodoba oznacza często GAME OVER.

Produkt może się nie podobać (nie osiągnąć mitycznego market fit) z wielu powodów. Może być brzydki, może nie mieć funkcji, których ludzie oczekują, może być przekombinowany albo po tak długim czasie przestarzały. Może też w międzyczasie pojawić konkurencja, która czyni go zbędnym.

W branży gier znane są przypadki, gdy jakiś wielki, zapowiadany jak nowy megahit tytuł projektowano tak długo, że w momencie premiery był już technologicznie przestarzały.

W przypadku serwisów www jest gorzej. Gracze grają w wiele różnych gier tego samego gatunku, a widzowie oglądają wiele podobnych filmów. Użytkownicy funkcyjnych serwisów www zwykle używają jednego ulubionego.

Gdyby tego było jeszcze mało, budowa to jeden temat, przebudowa/przeprojektowanie generuje nowy...

PROBLEM 4: Przebudowa skomplikowanego projektu w metodyce Katedry wymaga budowania jej obok, albo zamknięcia na czas budowy.

Każdy trochę zaawansowany system wymaga ciągłych poprawek. Ekademia to system z ponad 500 000 linii kodu. To żywy organizm, który rozwijamy według zapotrzebowania użytkowników, zmian technologicznych i oczywiście poprawiamy błędy.

To, czego nie wie wielu początkujących programistów to fak, ze większość błędów w tak wielkim systemie pojawia się dopiero przy skali. Gdy pojawia się skala, ludzie zaczynają używać serwisu w sposób, którego nikt nie przewidział, a serwery zaczynają pokazywać nowe problemy.

Przykład z impleBOTa: Zrobienie systemu, który wyśle e-mail jest stosunkowo proste. Do momentu, w którym zaczniesz wysyłać ich bardzo dużo. Nagle objawią się limity ilościowe na niektórych portalach, problemy ze spamem oraz niezliczona liczba sposobów informowania o błędzie całkowicie niezgodna z ogólnie przyjętymi zasadami - każdy taki wyjątek trzeba uwzględnić. Żaden z tych problemów nie jest istotny przy małej skali. Przy dużej to są główne tematy, jakimi się zajmujesz i one nigdy nie znikają na stałe.

To normalne - każdy skomplikowany i popularny system tak ma.

Ale ta normalność tworzy poważny problem, jeśli równolegle budujemy nową wersję działającego systemu w metodyce Katedry.

Metodyka Katedry zakłada budowanie w ukryciu. Czyli trzeba równolegle utrzymywać 2 wersje systemu. Nie jest to problem, jeśli mówimy o kilku elementach systemu. Jest to kolosalny problem, jeśli mówimy o całym systemie, który jak Ekademia działa w modelu SaaS (albo “w chmurze”, jak to dzisiaj się nazywa).

Każda zmiana, nowość czy poprawienie błędu w takie sytuacji zmusza do pisania 2 wersji funkcji albo dopisania wyjątków w jednej funkcji. Ponieważ te wyjątki i zdublowane funkcje muszą żyć aż do końca budowy naszej Katedry, na koniec zostajemy z niebywale chaotycznym i rozrośniętym systemem, za którego wyczyszczenie chętnie weźmie się tylko masochista.

Można też wpaść na gorszy pomysł. Można uznać, że najlepiej będzie po prostu napisać nowy system od nowa, zupełnie obok. Każdemu, kto ma taki pomysł polecam poczytać, dlaczego jest to: najgorszy błąd, jaki może firma software’owa popełnić http://www.joelonsoftware.com/articles/fog0000000069.html

Dlatego wybrałem: Bazar.

Bazar to zupełnie inna metodyka. Bazar buduje często wiele osób na raz. Najważniejsze jest jednak to, że efekty (nawet cząstkowe) ich pracy widać od razu. Od razu te zmiany mogą zostać ocenione i przetestowane przez użytkowników.

W ten sposób powstaje wiele systemów Open Source i w ten sposób działa coraz więcej firm z branży software’owej - od otwartego Wordpress.com po zamkniętego Facebooka czy wyszukiwarki Google.

W tej metodyce system praktycznie zawsze żyje i rzadko nie ma miejsce wielkie otwarcie. Oczywiście czasami zdarzają się większe zmiany, zbudowane jak Katedra, ale między nimi pojawia się wiele więcej innych zmian.

W efekcie system czasami wydaje się chaotyczny, a niektóre jego funkcje nie współgrają idealnie z innymi. Ale to nie jest poważny problem, bo wszystkie problemy zostają błyskawicznie wychwycone i są poprawiane.

Metodyka bazaru jest bardziej naturalna, bo tak właśnie działa natura - organizmy ewoluują aż do osiągnięcia stadium prawie idealnego. W przypadku software’u dzieje się to po prostu znacznie szybciej.

Znane (być może tylko z filmu “The Social Network”) jest stwierdzenie Marka Zuckerberga, że

“Facebook nigdy nie będzie skończony.”

Żaden system budowany w metodyce bazaru nie będzie skończony, bo zawsze można coś poprawić.

Oczywiście tak samo, jak i nazwa, tak samo ten sposób pracy jest mniej sexy. Bazar kojarzy nam się z bałaganem, ale zwykle przyciąga znacznie więcej ludzi, bo zawsze coś się dzieje.

Wspomniany esej The Cathedral and the Baazar daje wiele wskazówek, które wziąłem sobie do serca budując i ulepszając Ekademię. Opiszę je wkrótce bardziej szczegółowo, a ten wywód chcę zakończyć i pochwalić się małym, ale ważnym sukcesem.

Ekademia, jako system była od dnia 1 budowania w metodlogii Bazaru. Cały czas ją ulepszaliśmy w reakcji na nasze doświadczenia i uwagi użytkowników. Jednak redesign (zmianę szaty graficznej) planowałem od dawna przeprowadzić w metodyce Katedry (mimo iż jej nie znałem do niedawna). Na siłę zwalczałem naturalną dla mnie metodykę Bazaru uważając ją na przejaw braku możliwości.

Poznanie metodyki Bazaru jako autentycznej i niezwykle skutecznej metody budowania dało mi poczucie ogromnej ulgi i odblokowała zasoby kreatywności. Dlatego zacząłem aktywnie wdrażać nowy design w Ekademii - strona po stronie. I nie czekam aż wszystko będzie gotowe.

Wdrażam to, co uda się doprowadzić do stanu akceptowalnego i lepszego, niż było wcześniej. Robię to z pełną świadomością, że wiele będzie do poprawy, ale jeśli jest chociaż trochę lepiej, to wdrażam i nie martwię się, że to nie jest jeszcze ideał.

Efekt? Wiele zmian w strefie prywatnej użytkowników Ekademii, które czasami po opublikowaniu zostały skomentowane lub skrytykowane przez najbardziej aktywnych użytkowników i od razu poprawione.

Konkretne zmiany opiszę w osobnym wpisie, ale już możesz je zobaczyć. Żaden z tych projektów nie jest ostatecznie skończony - będą zmieniane wedle potrzeb i Waszych uwag.

Nowy profil użytkownika (jeszcze będzie ulepszany)

Nowa strona z listą zakupionych i zarządzanych produktów

Nowa strona z listą notatek (chcę ją jeszcze uatrakcyjnić, tutaj możesz poczytać, jak działają)

Nowa strona z podsumowaniem zarobków i raportem sprzedażowym

Nowa strona logowania (wprowadzona nieco wcześniej)

Skoro dotarłeś/aś aż tutaj, napisz w komentarzu:

Jaką metodyką Ty budujesz swoje projekty, dlaczego i co konkretnie budujesz?

A potem koniecznie przeczytaj: 19 zasad tworzenia dobrych systemów