Od parkingu do platformy sąsiedzkiej: jak powstawały kolejne moduły

Pierwszy problem: bezpieczeństwo

Kiedy moduł parkingowy zaczął już działać z rezerwacjami godzinowymi, szybko wróciła do mnie jedna z trzech wad grupy messengerowej, o której pisałem w pierwszej części serii: publiczne ogłaszanie „wyjeżdżam na tydzień” było złym pomysłem. Skopiowanie tej logiki do aplikacji, która nazywa się „Wolny Parking”, było kuszące. Wrzucasz wolne miejsce, każdy je widzi, ktoś je bierze. Proste.

Ale to był krok wstecz w stosunku do tego, po co w ogóle zbudowałem aplikację.

Odpowiedzią stał się nowy, drugi tryb pracy parkingu: zapotrzebowania. Logika jest odwrócona. Zamiast publicznie ogłaszać, że masz wolne miejsce, mieszkaniec, który aktualnie szuka parkingu, wystawia prośbę: „potrzebuję miejsca podziemnego w bloku E, w sobotę, od 15:00 do 18:00”. Właściciel miejsca, który akurat jest nieobecny, widzi to zapotrzebowanie i może na nie odpowiedzieć z własnej inicjatywy. Informacja o tym, że czyjeś mieszkanie jest puste, nigdzie publicznie nie trafia. Wiedzą o tym tylko dwie osoby: ten, kto szuka, i ten, kto oferuje.

To wydawało się oczywiste dopiero po tym, jak problem został nazwany. Wcześniej wszyscy, łącznie ze mną, przyjmowali jako naturalne, że „dzielenie się miejscem” oznacza „publiczne ogłaszanie”. Zapotrzebowania rozbroiły to założenie.

Udostępnianie prywatne

Potem ktoś z sąsiadów zaproponował trzeci wariant: udostępnianie prywatne. Chodziło o sytuację, w której chcę oddać miejsce komuś konkretnemu: bliskiemu sąsiadowi z piętra, rodzicom przyjeżdżającym w odwiedziny, stałemu znajomemu. Nie muszę pokazywać tego miejsca reszcie osiedla, bo wiem dokładnie, kto ma z niego skorzystać.

Dodałem tę opcję. Mieszkaniec wybiera osoby z listy (po numerze telefonu), i tylko one widzą dane miejsce w aplikacji. Dla wszystkich pozostałych jest niewidoczne. To była naturalna rozbudowa tego, co już istniało, więc ją zrobiłem bez wahania. Ale wiedziałem też, że w przyszłości muszę obserwować, czy ten tryb się nie zamieni w narzędzie budowania zamkniętych grup. Na szczęście w praktyce okazał się po prostu wygodnym sposobem na przekazanie miejsca konkretnej osobie bez dodatkowego zamieszania.

Moduł pomocy sąsiedzkiej

Kiedy moduł parkingowy działał stabilnie, dostrzegłem, że ta sama logika (problem i jego rozwiązanie) ma sens także poza parkingiem.

Śledziłem grupy osiedlowe. Co chwilę ktoś pytał o korepetycje z matematyki, opiekę nad dzieckiem, serwis pralki, fachowca od klimatyzacji, wyprowadzenie psa na godzinę, odebranie paczki z paczkomatu. Niektóre z tych pytań leciały w przypadkowe grupy i niknęły po jednym dniu. Inne wracały co kilka tygodni, bo odpowiedzi były udzielane w prywatnych wiadomościach, nikt ich nie widział i ta sama osoba pytała znowu.

To była ta sama historia co przy parkingu: ludzie mają realny, powtarzalny problem, ale nie mają narzędzia, które ten problem porządkuje.

Dodałem moduł pomocy sąsiedzkiej. Mieszkaniec może wystawić zapotrzebowanie na coś, czego potrzebuje: przedmiot (wiertarka, drabina, latarka), drobną usługę sąsiedzką (wyprowadzenie psa, odbiór paczki, opieka nad kotem) albo coś pilnego, jak brakujące jajko do szarlotki. Inni mieszkańcy widzą listę, mogą odpowiedzieć, pomóc, porozmawiać.

Po paru tygodniach dodałem do tego drugi tryb: polecanych fachowców. To już inna kategoria. Nie chodzi o drobną przysługę, tylko o usługę komercyjną. Hydraulik, elektryk, mechanik samochodowy, osoba sprzątająca, korepetytor, złota rączka. Rozdzieliłem to świadomie, bo łączenie „pożycz mi drabinę” z „polecam mojego hydraulika” pod jednym przyciskiem tworzyło bałagan. Sąsiedzka przysługa i komercyjna usługa to są dwa różne światy i mieszanie ich w jednej liście pogarszało jedno i drugie.

Baza polecanych fachowców jest budowana oddolnie. Każdy mieszkaniec może dodać kogoś, kto u niego pracował i zrobił dobrą robotę, opisać krótko, jakie usługi świadczy, i dodać ocenę w formie gwiazdek. Inni mieszkańcy mogą potem do tego samego fachowca dopisać własną opinię, którą widzi reszta osiedla. Różnica w stosunku do standardowego googlowania polega nie tyle na technologii, co na kontekście: za każdą oceną stoi konkretny sąsiad, którego można zapytać osobiście, dlaczego ocenił tak a nie inaczej.

Bezpieczeństwo, dostęp i RODO

Im więcej funkcji dodawałem, tym wyraźniej rozumiałem, że dostęp do aplikacji nie może być otwarty. WolnyParking nie jest grupą na Messengerze. Żeby miała sens, musi być ograniczona do ludzi, którzy realnie mieszkają na tym samym osiedlu. Inaczej każdy mechanizm zaufania się rozsypuje.

Zacząłem od prostego hasła podawanego przy rejestracji, ale to było rozwiązanie tymczasowe. Zastąpiłem je kodem QR i linkiem z zaproszeniem, który każdy nowy mieszkaniec dostaje od administratora lub od zapraszającego sąsiada. Do tego doszła weryfikacja SMS: mieszkaniec musi podać numer telefonu i potwierdzić go kodem, zanim otrzyma dostęp. Numer telefonu pełni od razu dwie role: jest loginem przy kolejnych logowaniach i jednocześnie warstwą weryfikacji tożsamości.

Do aplikacji podłączyłem dwa kanały powiadomień: SMS do spraw pilnych i push do komunikatów ogólnych. Dzięki temu informacja „ktoś chce ci udostępnić miejsce, którego szukałeś” idzie SMS-em, bo wymaga reakcji. Ogłoszenie o remoncie windy leci pushem, bo można je przeczytać przy okazji.

RODO było osobnym wyzwaniem. Domyślnie aplikacja nie pokazuje imion, nazwisk ani pełnych numerów telefonów. Inni mieszkańcy widzą wyłącznie cztery ostatnie cyfry numeru i na tym się kończy. Dopiero jeśli świadomie zdecyduję się udostępnić swój pełny kontakt (numer plus imię) w konkretnej sprawie, druga strona otrzymuje te dane SMS-em. To jest zawsze moja decyzja, a nie domyślne zachowanie aplikacji. Dane są szyfrowane, logi minimalne, a w aplikacji nie ma ani jednej funkcji, która wymagałaby więcej informacji o użytkowniku, niż jest absolutnie konieczne. Założenie jest proste: mniej danych to mniej problemów.

Drobne funkcje, które okazały się ważne

Po paru tygodniach stabilnego działania pojawiła się kolejna partia feedbacku, tym razem dotycząca drobnych rzeczy. Komentarze. Udostępniający miejsce może zostawić publiczną notatkę dla rezerwujących, na przykład „proszę parkować tyłem, bo z przodu jest słupek” albo „uwaga na lewą ścianę, miejsce wąskie”. Z drugiej strony mieszkaniec, który wystawia zapotrzebowanie, może dodać swoje własne preferencje: „szukam miejsca zewnętrznego przy bloku E, ale może być też przy bloku F”. A po samej rezerwacji korzystający może wysłać prywatną wiadomość SMS bezpośrednio do udostępniającego, w stylu „dzięki, już wyjeżdżam, miejsce wolne od 14:15”. Same drobiazgi, ale to one sprawiły, że z narzędzia do rezerwacji zrobiło się narzędzie do krótkiej rozmowy między konkretnymi osobami, które akurat mają ze sobą coś do załatwienia.

Pilot na dwóch blokach

Nawet gdy aplikacja już wyglądała na stabilną, miałem świadomość, że jeszcze jej nie chcę puszczać na całe osiedle. Niestabilne wdrożenie dla kilkuset użytkowników to pewna katastrofa wizerunkowa. Wystarczy jeden negatywny komentarz na grupie, i adopcja staje w miejscu. Postanowiłem skupić się na dwóch blokach stanowiących jedną wspólnotę. Razem z kilkoma zaufanymi sąsiadami, którzy od początku byli w pętli testowej, zaczęliśmy używać aplikacji jak produkcyjnej, ale tylko wewnętrznie.

Dzięki temu nawet jeśli coś poszło nie tak, feedback wracał do mnie, a nie w komentarze publiczne. Mogłem poprawiać bez presji i bez rozczarowania ludzi, którzy nie mieli pojęcia, że to świeży projekt. Dwa bloki jednej wspólnoty były dobrym kompromisem: wystarczająco dużo realnych przypadków użycia, żeby zbierać sensowny feedback, i wystarczająco mało osób, żeby nikt nie zraził się, kiedy coś chwilowo nie działało.

Jako twórca aplikacji nie chciałem głośno jej chwalić. Robili to inni, a ja liczyłem, że w ten sposób adopcja pójdzie sama. Tak się zresztą działo: bez kampanii reklamowej, bez spotu, bez notki na grupie „drodzy mieszkańcy, mam dla was aplikację”.

Dwie lekcje z tego etapu

Z rozbudowy aplikacji w platformę sąsiedzką wyniosłem dwie rzeczy, które dzisiaj są dla mnie fundamentem każdej decyzji projektowej.

Pierwsza: bezpieczeństwo trzeba wbudować od początku, a nie dodawać jako opcję. Kiedy zorientowałem się, że publiczne ogłoszenia o wolnych miejscach są problemem, dodałem zapotrzebowania jako pełnowartościowy tryb aplikacji, nie jako przełącznik do włączenia w ustawieniach. Różnica jest fundamentalna. Funkcje bezpieczeństwa, które użytkownik musi sam włączyć, zwykle nie są włączone.

Druga: mała grupa zaufanych testerów daje więcej niż szybkie otwarcie aplikacji na wszystkich. Nie potrzebowałem setek użytkowników, potrzebowałem kilku, którzy powiedzą mi szczerze, co jest źle. Dwa bloki jednej wspólnoty w zupełności wystarczyły, a ryzyko, że coś nieudanego zostanie publicznie zapamiętane, zostało sprowadzone do minimum.

Co było dalej

Do tego momentu historia wygląda jak klasyczne „oddolny projekt dla sąsiadów rośnie organicznie”. Tak wyglądała z zewnątrz. Od środka jednak działo się coś innego. Aplikacja od pierwszego dnia generowała koszty, a ja coraz wyraźniej rozumiałem, że ktoś w końcu za to musi zapłacić. W trzecim tekście z serii opisuję, jak wyglądał ten moment uświadomienia, dlaczego mikro-abonamenty dla mieszkańców odrzuciłem w kilka dni i co wydarzyło się na rocznym zebraniu, które przesądziło o kierunku rozwoju produktu.