A NevaBridge-ről

Megépítettük az eszközt, amelyet nem találtunk.

A NevaBridge nem termékként indult. A saját fájdalmunkként indult – több ezer homályos hibajelentés egy platformon, amelyet mi magunk üzemeltetünk. Ezért megépítettük azt a réteget, amely felteszi a megfelelő kérdéseket, mielőtt egy hibajegy valaha is eljutna egy fejlesztőhöz.

01A PROBLÉMA, AMELYET MAGUNK IS MEGÉLTÜNK

Egy olyan problémából született, amelyet egyetlen létező eszköz sem tudott megoldani.

A NevaBridge mögött álló csapat üzemelteti a Calendallt is, egy népszerű ügyfélkezelő és időpontfoglaló rendszert szalonok számára. Minden héten érkeztek ügyfélmegkeresések e-mailben, chatben és support hibajegyeken keresztül: kérdések, funkcióötletek és hibajelentések. Mindegyiket el kellett olvasni, megérteni és a megfelelő helyre továbbítani. És ha hibajelentés volt? A fejlesztőinknek szinte mindig rá kellett kérdezniük. Melyik böngésző? Melyik képernyő? Pontosan mire kattintott, mielőtt elromlott?

A jelentések nem voltak rosszak. Csak hiányosak. És minden pontosítás időbe, kontextusba és idegekbe került mindkét oldalon. Megmértük: az összes hibajelentés 44%-ához legalább egy tisztázási kör kellett, mielőtt egy fejlesztő egyáltalán elkezdhette volna. Némelyikhez három-négy kör.

Kerestünk egy eszközt, amely a forrásnál oldja meg ezt a problémát. Egy munkafolyamatot, amely felteszi a megfelelő kérdéseket, mielőtt a hibajegy a fejlesztőhöz ér. Nem találtunk egyet sem.

Ezért magunk építettük meg. Ami a saját support csapatunk belső eszközeként indult, abból lett a NevaBridge.

44%

az összes hibajelentésnek legalább egy pontosítás kellett, mielőtt egy fejlesztő elkezdhette

178%

hosszabb idő az első megoldásig a hiányos jelentéseknél

Nem terméket próbáltunk építeni. A saját fájó pontunkat próbáltuk megoldani. A NevaBridge azért létezik, mert senki más nem oldotta meg ezt a problémát a hozzánk hasonló csapatok számára.

02EGY CSAPAT, AMELY MINDKÉT KALAPOT VISELI

Az üzemeltetés találkozik a fejlesztéssel.

Az alapító csapatunk építette és üzemeltette azt a platformot, ahol ezt a problémát először megéltük. Több ezer support interakciót kezeltünk, több száz hibajelentést mi magunk triázsoltunk, és a homályos hibajegyek fájdalmát saját bőrünkön tapasztaltuk. Ezt a fájó pontot nem egy piaci jelentésben olvastuk. Heteken át, éveken keresztül éltük.

Amikor elkezdtük fejleszteni a NevaBridge-et, behoztunk a csapatba egy CTO-t, aki ugyanezt a mintát a másik oldalról ismerte. Senior Software Engineerként az AWS-nél éveken át a hiányos hibajelentések fogadó oldalán állt, méghozzá egy olyan cégnél, amely az iparág egyik legérettebb fejlesztési folyamataival rendelkezik. A probléma nem csak nálunk volt egyedi. Strukturális volt.

Ez a kombináció formálja a NevaBridge-et. A csapat egyik oldala tudja, mit jelent egy terméket üzemeltetni, ügyfelekkel beszélni és a supportot megóvni a zajtól. A másik oldal tudja, mire van valóban szüksége egy fejlesztőnek ahhoz, hogy elkezdjen egy issue-t – és milyen drága, ha ezek az információk hiányoznak. Nem azért, mert a pontosítás sokáig tart, hanem mert minden visszakérdezés visszamegy, órákig vagy napokig vár válaszra, a fejlesztő pedig addigra már rég mással foglalkozik. A NevaBridge a két nézőpont metszéspontjában születik.

4 év

egy SaaS platform üzemeltetése valódi felhasználókkal és valódi support mennyiséggel

12 év

enterprise szoftverfejlesztés, startupoktól a közszférán át az AWS Senior Engineer szerepéig.

Nem elméletből építünk. Több ezer valódi beszélgetésből, valódi hibajegyből és valódi frusztrációból építünk az átadás mindkét oldalán.

03AHOL MOST TARTUNK

Egy modul. Jól megcsinálva.

A NevaBridge korai fázisban van. Az első modult építjük: belső hibajelentés. Egy csapattag természetes nyelven ír le egy problémát. A NevaBridge elemzi, mi van meg, felismeri, mi hiányzik, célzott pontosító kérdéseket tesz fel, és egy strukturált, fejlesztésre kész hibajegyet hoz létre a hibajegykezelő rendszerében.

Ez nem egy űrlapra ráhúzott általános chatbot. A NevaBridge három szinten működik. Alapból már tudja, mire van általában szüksége a fejlesztőknek egy hibajelentésben – a termékfejlesztésben, a pilotügyfelekkel való munkában és a nyílt forráskódú hibajegykezelő rendszerek elemzésében szerzett saját tapasztalatainkból építve. Ezen felül feltöltheti a saját termékdokumentációjával és korábbi hibabeszélgetésekkel, hogy megtanulja az Önök terminológiáját, funkcióit és ismert issue-jait. És létrehozhat saját jelentéssablonokat a bevált kezdő sablonunk mellett. A NevaBridge minden beszélgetéshez a megfelelőt választja.

Éppen ez a kombináció alakít egy homályos mondatot olyan hibajeggyé, amelyen egy fejlesztő azonnal dolgozni tud – egyetlen pontosító kérdés nélkül.

Ott kezdjük, ahol a fájdalom a legnagyobb. A hibajelentések azok a helyek, ahol a legnagyobb a szakadék aközött, amit az emberek mondanak, és amire a fejlesztőknek szükségük van. Ezt az egy dolgot jól megcsinálni az alapja mindennek, ami ezután következik.

Mi magunk is használjuk, minden nap. És olyan csapatokat keresünk, akik ugyanezt a fájdalmat ismerik.

1

modul éles üzemben, szándékosan szűkre szabva

0

pontosító kérdés szükséges, ha a hibajegyet a NevaBridge írja

Inkább most adunk át egy modult, amely valódi problémát old meg, mintsem hogy a csapatokat megvárakoztassuk, amíg mind a három elkészül.