Bogusz P臋kalski馃殌 Naprawia膰 bugi czy budowa膰 nowe funkcje?
4 min read

Czo艂em tu Bogusz 馃憢

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




















Wys艂a艂em do Ciebie t臋 wiadomo艣膰 poniewa偶 zapisa艂e艣 si臋 na newsletter lub webinar Akademii SaaS Wszystkie informacje odno艣nie przetwarzania Twoich danych znajdziesz w naszej polityce prywatno艣ci.