Meetpoint publicznie

Stan

Od 11 października zamknięte trzy zadania:

• Poprawki bez sklepu — zamknięte 12 października, 72 z 93 pozycji. Tego samego dnia zrobiłem ćwiczenie, które zapowiedziałem tydzień temu: celowo zepsuta poprawka poszła na telefon, ekran profilu się wywrócił, zgłoszenie do mnie dotarło, wycofałem paczkę. Od zgłoszenia do działającego ekranu minęło 10 minut
• Powiadomienia — zamknięte 18 października, 148 ze 151: nowy trening, zmiana składu, przypomnienia przed startem, cisza nocna liczona według strefy telefonu. Jeśli w ciągu 10 minut zapisze się pięć osób, przychodzi jedno powiadomienie ze składem końcowym, a nie pięć. Po starcie treningu nic już nie przychodzi
• Zgody i polityka prywatności — zamknięte 18 października, 55 z 56: regulamin i polityka po przeglądzie prawnym, zapis, którą wersję polityki ktoś zaakceptował

I punkt, który w każdym poprzednim wpisie stał w „Co dalej”: Meetpoint jest w Sklepie Play, na razie w testach wewnętrznych. Na liście testerów jestem tylko ja, więc instalacja ze sklepu działa na jednym telefonie. Ale to już ta sama droga, którą przejdzie grupa, a nie wersja dla programisty.

Telefon znowu złapał coś, czego nie złapały testy. Powiadomienie o zmianie składu na wygaszonym telefonie z Androidem przychodziło z kilkuminutowym opóźnieniem. Bez oznaczenia jako pilne system odkłada je do najbliższego wybudzenia. Teraz przychodzi w ciągu minuty. Przy treningu o 6:45 kilka minut to różnica między „zdążę” a „już jadą”.

Decyzja tygodnia: aplikacja nie przechowuje informacji o zdrowiu, chociaż biegacze je piszą

Od 18 października pod polem planu i komentarza jest jedno zdanie: „Nie wpisuj informacji o zdrowiu”. Regulamin podaje przykład: wystarczy „lekko, 6 km” zamiast „po kontuzji kolana”.

Druga możliwość była taka: przyjąć, że takie informacje się pojawią, i obsłużyć je zgodnie z przepisami. Dane o zdrowiu to osobna kategoria w RODO. Dochodzi do nich wyraźna zgoda, inne zabezpieczenia i inna rozmowa z każdym, kto czyta politykę prywatności. Na aplikację do umawiania treningów to za dużo, a dla grupy dziesięciu znajomych nie wnosi nic.

Nie udaję, że to rozwiązuje sprawę. „Wracam po kontuzji, biegnę spokojnie” to dokładnie zdanie, które ktoś z grupy napisze, bo tak się pisze do znajomych. Prośba nie jest blokadą. Aplikacja nie sprawdza treści planów i nie będzie. Jeśli taka informacja się pojawi, autor może ją usunąć sam albo poprosić mnie o usunięcie.

Koszt: plan traci kawałek kontekstu, którego czat nie gubi. Na Messengerze napiszesz „kolano jeszcze boli, robię 5 km”, a w Meetpoincie masz tylko „5 km spokojnie”. Ten koszt przyjmuję świadomie. Wyróżnikiem Meetpointa jest to, że różne plany mieszczą się w jednym treningu. Powód, dla którego ktoś biegnie wolniej, nie jest do tego potrzebny.

Co dalej

Z czterech punktów listy sprzed tygodnia trzy są zrobione: poprawki bez sklepu z przećwiczonym wycofaniem, płatny plan serwera z codziennymi kopiami zapasowymi, wersja w sklepie. Zostały:

• gotowe zapytania liczące kryteria sukcesu, napisane przed startem, a nie wtedy, gdy będę już widział wynik
• pełny przegląd na wersji ze sklepu, na koncie innym niż moje
• dopisanie grupy do listy testerów i wysłanie zaproszenia

Przegląd dopisałem do listy w tym tygodniu. Każde zadanie od września kończyło się listą rzeczy do sprawdzenia ręcznie na telefonie. Dwanaście takich list ma razem 40 punktów, których nie odhaczyłem. Część z nich sprawdzałem na wersji dla programisty, część na swoim koncie, które przeszło już wszystkie bramki. Grupa nie przejdzie żadną z tych dróg.

Najbardziej uwiera mnie link zaproszenia. Wszystkie dziewięć punktów jego listy jest otwartych, a to pierwsze, co każdy z dziesięciu kliknie. Jedna osoba, która utknie między linkiem a formularzem, to minus dziesięć procent ogłoszonego kryterium, zanim ktokolwiek umówi pierwszy trening.

Więc przechodzę całą aplikację od zera: instalacja ze sklepu, nowe konto, link zaproszenia, pierwszy trening, powiadomienia. Także to, co skończyłem we wrześniu. Wynik opiszę przed wysłaniem zaproszenia.

Licznik rusza dopiero po ostatnim punkcie.

Następny wpis: niedziela 25 października.

Stan

Od 6 października zamknięte trzy zadania:

• Zgodność ze sklepami — zamknięta 8 października, 223 z 239 pozycji: usunięcie konta w aplikacji, regulamin akceptowany przed pierwszym wpisem, filtr niedozwolonych słów, zgłaszanie komentarzy, planów i osób, blokowanie
• Link zaproszenia — zamknięty 10 października, 129 ze 134: link prowadzi przez logowanie, regulamin i pytanie o imię prosto do formularza dołączenia z wpisanym kodem, także przy zamkniętej aplikacji. Strona zaproszenia na meetpoint.team stoi i nie zapisuje w dzienniku serwera adresów z kodami
• Zgłaszanie awarii — zamknięte 11 października, 134 ze 150: każdy z 16 ekranów ma własny ekran awaryjny, a zgłoszenie, które do mnie trafia, nie niesie imienia, adresu e-mail ani treści, tylko identyfikator konta i rodzaj błędu

Pierwsze z tych zadań nie robi nic dla grupy. W dziesięcioosobowej ekipie znajomych nikt nikogo nie zgłosi ani nie zablokuje. Ale aplikacja z kontami i treściami użytkowników nie przejdzie recenzji ani w App Store, ani w Google Play bez usunięcia konta i zgłaszania, a zamknięta grupa nie zwalnia z żadnego z tych wymogów. Pierwszym użytkownikiem, który musi przejść przez Meetpoint bez potknięcia, jest recenzent sklepu.

Czwarty tydzień z rzędu ta sama rodzina, w dwóch odsłonach. Automatyczny przebieg przez ekran dwa razy trafił w przycisk schowany do połowy pod klawiaturą i uznał to za sukces — palec by go nie trafił. A sprawdzenie na telefonie złapało błąd, którego nie widziały ani testy, ani przeglądy: powiadomienie o prośbie o dołączenie otwierało zakładkę, na której próśb nie ma. Testy i przeglądy powtórzyły założenie z planu. Telefon go nie znał.

Decyzja tygodnia: poprawki bez sklepu już w pierwszej wersji dla grupy

10 października zdecydowałem, że pierwsza wersja, którą grupa zainstaluje, będzie umiała pobierać poprawki bez przechodzenia przez sklep. Bez tego każda poprawka w ośmiotygodniowym oknie to nowa wersja, recenzja sklepu (od kilku godzin do kilku dni) i ręczna aktualizacja na każdym z dziesięciu telefonów. Aplikacja wywraca się w sobotę o 6:45, przed treningiem, a poprawka dociera w poniedziałek. Grupa umówi się wtedy tam, gdzie się da. To znowu kryterium porażki wywołane czymś innym niż nawyk — tym razem awarią.

Tego nie da się dołożyć później. Mechanizm musi siedzieć w pierwszej instalacji, inaczej każdy najpierw musi sam zaktualizować aplikację ze sklepu.

Problem: README tego repozytorium mówi „Przez całe osiem tygodni nie naprawiam nic w locie”. Ta decyzja daje mi narzędzie, żeby naprawiać w locie w kilka minut. Nie udaję, że to się nie gryzie.

Więc doprecyzowuję zasadę teraz, przed startem licznika, w tym samym trybie, w jakim wolno zmieniać kryteria:

• W oknie naprawiam wyłącznie awarie: aplikacja się wywraca, dane się nie zapisują albo giną, powiadomienie nie dochodzi. To, przez co produkt nie działa — nie to, przez co działa słabo
• Nie zmieniam niczego, co zmienia sposób używania: układu ekranów, tekstów, kolejności kroków, funkcji. Także wtedy, gdy widzę, że coś przeszkadza
• Każda poprawka z okna trafia do tygodniowego wpisu: data, co się wywracało, ilu osób dotyczyło

Koszt: tracę najprostszą wersję obietnicy. „Nic nie ruszam” sprawdzi każdy. „Ruszam tylko awarie” wymaga zaufania, że granicę wyznaczam uczciwie — dlatego jest spisana tutaj, zanim zobaczę pierwszą awarię, a nie w dniu, w którym będzie mi potrzebna.

Co dalej

Lista do startu okna jest dłuższa niż tydzień temu. Strona zaproszenia i link są gotowe, ale przegląd tego, co musi się wydarzyć przed wysłaniem zaproszenia, dołożył pozycje:

• poprawki bez sklepu i ćwiczenie wycofania celowo zepsutej poprawki — przed startem, nie w trakcie
• płatny plan serwera z danymi: na darmowym projekt usypia po 7 dniach bez ruchu i nie ma kopii zapasowych. Przerwa świąteczna to martwa aplikacja w poranek treningu
• gotowe zapytania liczące kryteria sukcesu — napisane przed startem, nie wtedy, gdy będę już widział wynik
• publikacja w obu sklepach

Licznik rusza dopiero po ostatnim punkcie.

Następny wpis: niedziela 18 października.

Stan

Komentarze i podpowiedzi planów: zamknięte 28 września, 266 z 278 pozycji.

• Komentarze pod treningiem — wdrożone na produkcję 27 września. Na fizycznym telefonie trzy komentarze pod jednym treningiem dały jedno powiadomienie z treścią ostatniego, tak jak miało być
• Podpowiedzi planów — gotowe: nad polem „Co robisz?” są plany, które ktoś z grupy już kiedyś robił

Przebudowa ekranu treningu: od 28 września do 5 października, 175 z 186. Tego zadania nie było w żadnym planie — wyszło ze sprawdzania komentarzy na telefonie, opis niżej. Trzy rundy przeglądu, wszystkie zastrzeżenia zamknięte. Kod nie jest jeszcze scalony z główną wersją: czeka na ręczne sprawdzenie na telefonie, 15 punktów.

Trzeci tydzień z rzędu ta sama rodzina. Android po cichu połykał przewinięcie ekranu do pola, w którym piszesz: raz, gdy przewinięcie przyszło przed ułożeniem treści, raz, gdy treść urosła nad polem już po otwarciu klawiatury. Trzy odsłony jednego błędu i żadnej nie widziały testy jednostkowe. Widać je wyłącznie na emulatorze z długą rozmową.

Decyzja tygodnia: tydzień na jeden ekran zamiast zaproszeń

27 września, przy sprawdzaniu komentarzy z otwartą klawiaturą, nad klawiaturą stał zielony przycisk „Deklaruję udział”, a „Wyślij” był pod nim schowany. Dzień później, przy teście powiadomień, stuknięcie w „Wyślij” trafiło w deklarację.

To nie jest kosmetyka. Jedno z kryteriów sukcesu brzmi: co najmniej 7 z 10 osób deklaruje udział w przynajmniej jednym treningu. Pomyłka palca to dokładnie zdarzenie, które ten licznik liczy, i w wyniku nie da się jej odróżnić od prawdziwej deklaracji. Przy dziesięciu osobach jedna taka to 10 punktów procentowych.

Więc zamiast strony zaproszenia — jeden ekran od nowa:

• Komentarze mają osobny ekran, a nad klawiaturą stoi tam tylko pole i przycisk wysyłania
• „Dołączam” stoi pod polem planu, więc nie da się go nacisnąć, pisząc komentarz
• Edycja i odwołanie treningu przeszły do menu w rogu

Zasada przebudowy: na ekranie treningu nie ma ani jednego dużego przycisku. 30 września dopisałem do niej jeden wyjątek: „Tak, odwołaj” jest duże, ale tylko na czas pytania o odwołanie, bo tego nie da się cofnąć. Dwie inne decyzje zmieniłem dopiero po zobaczeniu ich na telefonie: pole planu było za wąskie na typowy opis treningu, a miejsce startu ginęło pod datą w dwóch liniach. Wszystkie trzy zmiany są dopisane w dokumencie wymagań, z datą, obok pierwotnej wersji.

Koszt: tydzień bez niczego nowego dla grupy. Poprawka linku otwieranego przy zamkniętej aplikacji jest gotowa od 26 września, ale leży na osobnej gałęzi i do aplikacji jeszcze nie weszła. Strona zaproszenia przesuwa się trzeci tydzień z rzędu.

Co dalej

Ręczne sprawdzenie przebudowy na telefonie i scalenie z główną wersją. Potem poprawka linku przy zamkniętej aplikacji z 26 września — sprawdzić ją i wpuścić do aplikacji, razem ze stuknięciem w powiadomienie. Dalej bez zmian: strona zaproszenia → bariera pierwszego uruchomienia. Licznik rusza dopiero po ostatnim punkcie.

Następny wpis w niedzielę 11 października.

Stan

Najpierw poprawka do poprzedniego wpisu. Napisałem tam, że wszystkie wymagania MVP z dokumentu z 2 września są zaimplementowane. Nieprawda. Komentarze pod treningiem i podpowiedzi planów od początku leżały poza pierwszym planem i do tego tygodnia nie istniały. Poprawiam tutaj, a nie w tamtym pliku — to repozytorium jest po to, żeby takich rzeczy nie dało się po cichu przepisać.

Plan 004 (edycja i odwołanie treningu, archiwum grupy, zakładki): zamknięty 24 września, 358 z 398 pozycji. Lista urosła od zeszłej niedzieli o 63 pozycje, głównie poprawki po przeglądach.

• Zakładki na ekranie grupy i archiwum treningów — gotowe
• Powiadomienia o odwołaniu i zmianie terminu — wdrożone na produkcję, push o odwołaniu doszedł na fizyczny telefon

„Umów trening" z ekranu głównego: zamknięte 25 września, 121 z 131. Tego nie było w żadnym planie. Wyszło z mojego własnego przeklikania aplikacji na telefonie: najczęstszą czynność w produkcie dało się zrobić tylko z ekranu grupy, dwa kroki od miejsca, w którym się ląduje. Teraz przycisk jest przyklejony do dołu ekranu głównego, a formularz ma wybór grupy.

Komentarze i podpowiedzi planów: w toku, 219 z 244.

• Komentarze pod treningiem — gotowe w kodzie: dodawanie, edycja z dopiskiem „edytowano", usuwanie, powiadomienie o nowym komentarzu. Jeszcze nie na produkcji
• Wyjście z grupy pyta, czy zostawić swoje komentarze, czy je usunąć
• Podpowiedzi planów z historii grupy — baza i logika gotowe, ekran nietknięty

Jedna rzecz, której nie chcę zgubić, drugi tydzień z rzędu z tej samej rodziny. Odmiana „1 członek, 2 członkowie, 5 członków" przechodziła wszystkie testy jednostkowe i wywalała się na telefonie. Testy chodzą w innym silniku JavaScriptu niż aplikacja, a silnik na telefonie nie ma funkcji do odmiany liczebników. Wyłapane w trakcie budowy, nie na telefonie kogoś z grupy. Odmiana jest teraz spisana ręcznie.

Decyzja tygodnia: komentarze z powiadomieniem przed stroną zaproszenia

Tydzień temu napisałem, że strona zaproszenia przesuwa się o tydzień, może dwa. Minął tydzień i przesuwa się dalej.

Poprawienie godziny załatwia „może 18:20?". Nie załatwia „kto bierze klucz do szatni?". Bez miejsca na rozmowę przypiętą do treningu te wiadomości wrócą na Messengera, a za nimi umawianie. Ten sam mechanizm co tydzień temu: kryterium porażki wywołane brakiem funkcji, nie brakiem nawyku.

Komentarze bez powiadomienia przegrałyby z Messengerem od pierwszego tygodnia — nikt nie wchodzi do aplikacji sprawdzić, czy ktoś coś napisał. Więc push jest od razu, ale podmieniany: trzy komentarze pod jednym treningiem to jedna pozycja na telefonie, nie trzy.

Koszt, który wolę nazwać: 24 września wyszło, że link otwierany przy zamkniętej aplikacji gubi adres i ląduje na ekranie głównym. Oznaczyłem to jako następne zadanie. Od tamtej pory zrobiłem dwa inne. To dokładnie ta ścieżka, którą pójdzie każdy członek grupy klikający w zaproszenie — bez niej strona zaproszenia nie ma dokąd prowadzić.

Co dalej

Dokończyć podpowiedzi planów i wdrożyć komentarze na produkcję. Potem link otwierany przy zamkniętej aplikacji, razem ze stuknięciem w powiadomienie — ta sama mechanika. Dalej lista bez zmian: strona zaproszenia otwierana z linku → bariera pierwszego uruchomienia. Licznik rusza dopiero po ostatnim punkcie.

Następny wpis wyjątkowo we wtorek 6 października, nie jak zwykle w niedzielę.

Stan

Rdzeń produktu istnieje. Tydzień temu nie było ekranu, który cokolwiek komukolwiek pokazuje — dziś jest oś czasu treningów, umawianie treningu, ekran treningu z uczestnikami pogrupowanymi według planu. Wszystkie wymagania MVP z dokumentu z 2 września są zaimplementowane, ostatnim był limit użyć kodu zaproszenia.

Fundament (plany 001–003): 202 z 210 pozycji. Otwarte zostały zrzuty ekranu i dwa testy ręczne.

• Grupy i zaproszenia — gotowe: kod zaproszenia z limitem użyć, poczekalnia, unieważnianie, opuszczenie i usunięcie z grupy
• Treningi — gotowe: oś czasu, umawianie, deklaracja udziału i jej wycofanie, plany rozbieżne w jednym treningu
• Powiadomienia — działają na produkcji, potwierdzone dostarczeniem na fizyczny telefon, nie samą konfiguracją
• Jest przepis na wydanie paczki Android dla grupy

Plan 004 (edycja i odwołanie treningu, archiwum grupy, zakładki): 182 z 335.

• Stan treningu w bazie — gotowy: odwołanie jest znacznikiem czasu, nie usunięciem wiersza, i jest nieodwracalne; pilnuje tego wyzwalacz, nie kod aplikacji
• Odwołanie i edycja na ekranie treningu — gotowe, testy end-to-end 9/9 na urządzeniu
• Zakładki na ekranie grupy, archiwum, powiadomienia o odwołaniu i zmianie terminu — nietknięte

Jedna rzecz z tego tygodnia, której nie chcę zgubić. W dniu, w którym zapisałem, że MVP jest zaimplementowane, na fizycznym telefonie nie dało się umówić treningu. Dwa błędy najwyższej wagi, oba niewidoczne dla zielonych testów — testowały warstwę danych, nie ścieżkę palcem przez ekran. Od tamtego dnia flow umówienia treningu jest testowany przez interfejs. „Zielone" znaczyło tyle, ile pokrywało.

Decyzja tygodnia: edycja i odwołanie przed stroną zaproszenia

Tydzień temu zapisałem kolejność do startu okna: grupy → strona zaproszenia → treningi → bariera pierwszego uruchomienia. Nie trzymam się jej. Strona zaproszenia czeka, a po domknięciu treningów poszedłem w coś, czego na tamtej liście nie było: poprawienie i odwołanie treningu.

Powód: treningu z pomyłkową godziną nie dało się poprawić ani odwołać. Grupa, która ustali w aplikacji 18:00, a potem ktoś rzuci „może 18:20?", załatwi to tam, gdzie się da — na Messengerze. To jest dokładnie pierwsze kryterium porażki, tylko wywołane przez brak funkcji, nie przez brak nawyku. Test, który pada z takiego powodu, niczego nie mierzy.

Z tego samego powodu termin może zmienić każdy uczestnik, nie tylko autor. Negocjacja godziny to jedyna rzecz, którą Messenger robi lepiej niż przycisk — więc przycisk musi być w zasięgu każdego, kto ma powód go użyć.

Koszt: strona zaproszenia przesuwa się o tydzień, może dwa. Kolejność listy się zmienia, kryteria nie.

Co dalej

Dokończyć plan 004: zakładki, archiwum, powiadomienia o odwołaniu i zmianie. Potem wracam do listy: strona zaproszenia otwierana z linku → bariera pierwszego uruchomienia. Licznik rusza dopiero po ostatnim punkcie.

Następny wpis: niedziela 27 września.

Stan

94 ze 167 pozycji listy zadań odhaczone.

• Fundament danych — gotowy: schemat, polityki dostępu na poziomie bazy, testy
• Konto i wejście — gotowe: logowanie kodem z maila, testy end-to-end zielone
• Grupy i zaproszenia — w toku
• Treningi, czyli rdzeń produktu — nietknięte

Ostatnia linijka jest ważniejsza niż procent nad nią. 56% odhaczonych pozycji przy nietkniętym rdzeniu znaczy tyle, że zbudowałem dotąd wyłącznie rzeczy, których użytkownik nigdy nie zobaczy. Nie istnieje jeszcze ani jeden ekran, który cokolwiek komukolwiek pokazuje.

Decyzja tygodnia: kryteria ogłaszam teraz, nie w dniu startu

Plan zakładał, że kryteria sukcesu publikuję w dniu wysłania zaproszenia grupie — razem ze startem ośmiotygodniowego okna. Zmieniam to. Publikuję je dziś, jakieś cztery miesiące wcześniej.

Powód jest jeden. Kryteria ogłoszone w dniu startu i kryteria napisane w dniu startu wyglądają identycznie — nie ma czym ich odróżnić, więc cała deklaracja jest pusta. Kryteria ogłoszone wtedy, gdy nie istnieje jeszcze ekran, który cokolwiek robi, odróżniają się same.

Koszt jest realny i wolę go zapisać teraz, niż tłumaczyć się z niego w lutym: próg 7 z 10 jest od dziś zamrożony, a nie mam jeszcze rozstrzygniętej bariery pierwszego uruchomienia. Jedna osoba, która utknie na instalacji i przepisywaniu kodu z maila, to minus 10% ogłoszonego wyniku — i nie będę mógł tego progu ruszyć. Wolę ten koszt niż deklarację bez pokrycia.

Co dalej

Kolejność do startu okna: grupy i zaproszenia → strona zaproszenia otwierana z linku → treningi → bariera pierwszego uruchomienia. Licznik rusza dopiero po ostatnim punkcie.

Następny wpis: niedziela 20 września.