Czołem tu Bogusz 👋
Na początku jest prosto. Nie masz klientów, nie masz zgłoszeń bugów, nie masz maili supportowych.
Kodujesz sobie w spokoju, nikt Ci nie przerywa. Budujesz nowe funkcje i każdego dnia Twój produkt jest coraz fajniejszy.
Wszystko się zmienia w momencie kiedy masz już grupę klientów.
Nagle na Twoją skrzynkę mailową, chat i grupy dla użytkowników zaczynają wpadać zgłoszenia błędów.
Tu coś się nie otwiera. Tam coś się źle przelicza. Na tym telefonie coś nie działa.
Nie ma software'u bez bugów. Tam gdzie jest kod, tam będą błędy i
nieprzewidziane sytuacje.
Szczególnie, jeżeli budujesz aplikację w pojedynkę i musisz działać bardzo szybko. Na tym etapie mało kto ma czas pisać testy jednostkowe, nie mówiąc już o budżecie na testerów manualnych.
Dostajesz zgłoszenie, siadasz do naprawy buga. Nie umiesz go zreprodukować, walczysz, w końcu się udaje. Poprawka wgrana na produkcję!
Patrzysz do skrzynki pocztowej, a tam 3 nowe zgłoszenia…
A kiedy czas na nowe funkcje? Kiedy czas na realizację zadań z Twojej roadmapy? Ludzie czekają na nowości, a Ty fixujesz bugi.
Tolerancja klienta na błędy
Po pierwsze warto zastanowić się na tym czy dany błąd wymaga natychmiastowej poprawy.
Zależnie od aplikacji jaką budujesz klienci będą mieli różną tolerancję błędów.
Przykładowo u mnie w
MailingR wszystkie błędów związane z koszykiem muszą być naprawiane ASAP.
Dlaczego? Klient, który korzysta z mojego produktu i dzięki któremu sprzedaje swoje produkty cyfrowe swoim klientom liczy na to, że koszyk będzie działa bezbłędnie.
Jeżeli koszyk się zablokuje i nie będzie można kupować i mój klient zwyczajnie będzie tracił pieniądze. Dodatkowo będzie wyglądał nieprofesjonalnie w oczach swoich klientów. To nie jest do zaakceptowania.
Natomiast, jeżeli błąd będzie występował w momencie pobierania przez klienta listy transakcji w formie CSV to nikt nie straci pieniędzy i pewnie klient poczeka spokojnie na poprawkę.
Jak dzielić czas pomiędzy rozwojem, a utrzymaniem?
Dodawanie nowych funkcji i rozwój produktu jest kluczem do utrzymania tzw. "momentum" i ekscytacji
wokół Twojej aplikacji.
Każda nowa funkcja to okazja do pochwalenia się użytkownikom oraz światu jak fajnie Twój produkt się rozwija. To przyciąga nowych klientów.
Poza tym kto chciałby łatać błędy zamiast pisać nowych rzeczy? Jeżeli to jeszcze Twoje własne błędy to pół biedy, gorzej jak musisz sprzątać po kimś.
Dodatkowo do utrzymania dochodzą tematy związane z refactoringiem kodu. Szybkie wdrażanie nowych ficzerów nie sprzyja utrzymaniu dobrej architektury aplikacji. A nie warto też poświęcać znacznych ilości czasu na architekturę jak nie ma się funkcji, a klienci czekają.
To co proponuję to:
- Wyznaczenie krytycznych obszarów, w
których błędy muszą być poprawiane jak najszybciej.
- Zapisywanie i kolejkowanie mniej istotnych zgłoszeń. Bez natychmiastowej poprawy (chyba, że wymaga mniej niż 5 minut).
- Przeznaczenie 1 dnia w tygodniu tylko na poprawę błędów. Wtedy bierzemy listę błędów i lecimy po kolei z poprawkami.
Naprawa bugów jest kluczowa to długofalowego działania produktu, ale nie pozwala Ci rozwijać aplikacji tak szybko jak chcesz.
To na co warto uważać to skupienie się tylko na błędach. Na ogół fixowanie bugów nie zajmuje wiele czasu i dzięki temu daje szybkie wystrzały dopaminy (poprawione, wdrożone).
Niestety to nie zastąpi fundamentalnego rozwoju produktu, który wymaga dni lub tygodni głębokiej pracy w
skupieniu.
Jeżeli jesteś jeszcze przed klientami to ten problem jeszcze Cię nie dotyczy.
Ale warto mieć świadomość, że wraz z rozwojem biznesu poza pieniędzmi od klientów spływającymi na Twoje konto pojawią się również regularne zgłoszenia błędów. Pozdrawiam,
Bogusz
|
|
|
|
|