NevaBridge nie zaczął się jako produkt. Zaczął się jako nasz własny ból – tysiące mętnych zgłoszeń błędów na platformie, którą sami prowadzimy. Dlatego zbudowaliśmy warstwę, która zadaje właściwe pytania, zanim zgłoszenie kiedykolwiek trafi do programisty.
Zespół stojący za NevaBridge prowadzi również Calendall, popularny system do zarządzania klientami i rezerwacji terminów dla salonów. Co tydzień napływały zapytania klientów przez e-mail, czat i zgłoszenia do supportu: pytania, pomysły na funkcje i zgłoszenia błędów. Każde trzeba było przeczytać, zrozumieć i przekazać we właściwe miejsce. A gdy było to zgłoszenie błędu? Nasi programiści prawie zawsze musieli dopytywać. Która przeglądarka? Który ekran? W co dokładnie kliknąłeś, zanim przestało działać?
Zgłoszenia nie były złe. Były po prostu niekompletne. A każde dopytanie kosztowało czas, kontekst i nerwy po obu stronach. Zmierzyliśmy to: 44% wszystkich zgłoszeń błędów wymagało co najmniej jednej rundy doprecyzowania, zanim programista mógł w ogóle zacząć. Niektóre wymagały trzech lub czterech rund.
Szukaliśmy narzędzia, które rozwiązuje ten problem u źródła. Workflow, który zadaje właściwe pytania, zanim zgłoszenie trafi do programisty. Nie znaleźliśmy żadnego.
Więc zbudowaliśmy je sami. To, co zaczęło się jako wewnętrzne narzędzie dla naszego własnego zespołu supportu, stało się NevaBridge.
wszystkich zgłoszeń błędów wymagało co najmniej jednego dopytania, zanim programista mógł zacząć
dłuższy czas do pierwszego rozwiązania przy niekompletnych zgłoszeniach
Nie próbowaliśmy zbudować produktu. Próbowaliśmy rozwiązać nasz własny problem. NevaBridge istnieje, bo nikt inny nie rozwiązał tego problemu dla zespołów takich jak nasz.
Nasz zespół założycielski zbudował i prowadził platformę, na której po raz pierwszy doświadczyliśmy tego problemu. Obsłużyliśmy tysiące interakcji z supportem, sami przeprowadziliśmy triage setek zgłoszeń błędów i na własnej skórze odczuliśmy ból mętnych zgłoszeń. Tego problemu nie wyczytaliśmy w raporcie rynkowym. Przeżywaliśmy go tygodniami, przez lata.
Gdy zaczęliśmy rozwijać NevaBridge, sprowadziliśmy do zespołu CTO, który znał ten sam wzorzec z drugiej strony. Jako Senior Software Engineer w AWS przez lata stał po stronie odbierającej niekompletne zgłoszenia błędów, nawet w firmie z jednymi z najbardziej dojrzałych procesów inżynierskich w branży. Problem nie był wyjątkowy dla nas. Był strukturalny.
To połączenie kształtuje NevaBridge. Jedna strona zespołu wie, co znaczy prowadzić produkt, rozmawiać z klientami i chronić support przed szumem. Druga strona wie, czego naprawdę potrzebuje programista, by zacząć pracę nad zgłoszeniem – i jak kosztowne jest, gdy tych informacji brakuje. Nie dlatego, że dopytywanie trwa długo, ale dlatego, że każde pytanie wraca, czeka godzinami lub dniami na odpowiedź, a programista do tego czasu dawno zajmuje się czymś innym. NevaBridge powstaje na styku obu perspektyw.
prowadzenia platformy SaaS z prawdziwymi użytkownikami i prawdziwym wolumenem supportu
tworzenia oprogramowania enterprise, od startupów przez sektor publiczny po rolę Senior Engineera w AWS.
Nie budujemy z teorii. Budujemy z tysięcy prawdziwych rozmów, prawdziwych zgłoszeń i prawdziwej frustracji po obu stronach przekazania.
NevaBridge jest na wczesnym etapie. Budujemy pierwszy moduł: wewnętrzne zgłaszanie błędów. Członek zespołu opisuje problem w języku naturalnym. NevaBridge analizuje, co jest dostępne, rozpoznaje, czego brakuje, zadaje celne pytania uzupełniające i tworzy uporządkowane, gotowe dla programisty zgłoszenie w waszym systemie do śledzenia zgłoszeń.
To nie jest ogólny chatbot doklejony do formularza. NevaBridge działa na trzech poziomach. Od razu wie, czego programiści zwykle potrzebują w zgłoszeniu błędu – zbudowane na naszym własnym doświadczeniu w tworzeniu produktów, pracy z klientami pilotażowymi i analizie open-source'owych systemów do śledzenia zgłoszeń. Ponadto możecie zasilić je własną dokumentacją produktu i wcześniejszymi rozmowami o błędach, by nauczyło się waszej terminologii, waszych funkcji i waszych znanych problemów. I możecie tworzyć własne szablony zgłoszeń obok naszego sprawdzonego szablonu startowego. NevaBridge wybiera odpowiedni dla każdej rozmowy.
To właśnie to połączenie zamienia mętne zdanie w zgłoszenie, nad którym programista może od razu pracować – bez ani jednego pytania uzupełniającego.
Zaczynamy tam, gdzie ból jest największy. Zgłoszenia błędów to miejsce, gdzie luka między tym, co mówią ludzie, a tym, czego potrzebują programiści, jest największa. Zrobienie tej jednej rzeczy dobrze to fundament dla wszystkiego, co nastąpi później.
Sami używamy go każdego dnia. I szukamy zespołów, które znają ten sam ból.
moduł w produkcji, celowo wąsko zakrojony
pytań uzupełniających potrzebnych, gdy zgłoszenie pisze NevaBridge
Wolimy dostarczyć teraz jeden moduł, który rozwiązuje prawdziwy problem, niż kazać zespołom czekać, aż wszystkie trzy będą gotowe.