Bogusz Pękalski🚀 Naprawiać bugi czy budować nowe funkcje?

10:43 11.01.2024·4 min read

Kolejny newsletter, jak zwykle w czwartek.

👉 Poprzednie maile przeczytasz TUTAJ.
👉Dziś o 19:00 LIVE + Q&A o aplikacjach SaaS. Dołącz TUTAJ.

Uwaga: Pierwsze spotkanie z mentorem o sprzedaży w SaaS od 20 tys. MRR do ponad 0,5 miliona MRR już we wtorek. Szczegóły na dole.

🐞  Ile czasu poświęcać na naprawę błędów i utrzymanie, a ile na budowę nowych funkcji?

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.

📧 CO NOWEGO W MAILINGR

Wdrożyliśmy właśnie nową, przełomową funkcję w MailingR.

Koszyk bezpośrednio na Twojej, dowolnej stronie. Bez przekierowania.

=> Tutaj instrukcja, wideo i koszyk testowy

🚀 CO NOWEGO W AKADEMII SAAS

Już we wtorek 16.01 o 19:00 odbędzie się pierwszy z mentoringów w ramach 10 edycji Akademii SaaS.

Sprzedaż w SaaS z Kacprem Kostrzewą.

Kacper ma na swoim koncie takie sukcesy:

Rozwój Scanye z 20k -> 500k MRR (teraz ok. 700+ tys. i dalej rośnie).
Rozwój Moniti z 50k -> 150k MRR (+ wyjście global).

Do poniedziałku można jeszcze dołączyć do Akademii SaaS i załapać się na to niepowtarzalne spotkanie mentorskie.

=> Drzwi otwarte. Dołącz teraz i załap się na wszystkie mentoringi

To wszystko na dziś. Do usłyszenia za tydzień! 🔥

Pozdrawiam,
Bogusz