NevaBridge bir ürün olarak başlamadı. Kendi sancımız olarak başladı: kendi işlettiğimiz bir platformda binlerce belirsiz hata raporu. Bu yüzden, bir ticket bir geliştiriciye ulaşmadan önce doğru soruları soran katmanı inşa ettik.
NevaBridge'in arkasındaki ekip aynı zamanda salonlar için popüler bir müşteri yönetimi ve randevu planlama sistemi olan Calendall'ı da işletiyor. Her hafta e-posta, sohbet ve destek ticket'ları aracılığıyla müşteri talepleri geliyordu: sorular, özellik fikirleri ve hata raporları. Her biri okunmalı, anlaşılmalı ve doğru yere yönlendirilmeli. Ve bir hata raporuysa? Geliştiricilerimiz neredeyse her zaman açıklama istemek zorunda kalıyordu. Hangi tarayıcı? Hangi ekran? Bozulmadan önce tam olarak neye tıkladın?
Raporlar kötü değildi. Sadece eksikti. Ve her açıklama talebi her iki tarafta da zaman, bağlam ve sinir harcatıyordu. Bunu ölçtük: tüm hata raporlarının %44'ü, bir geliştirici işe başlayabilmeden önce en az bir netleştirme turuna ihtiyaç duyuyordu. Bazıları üç veya dört tura ihtiyaç duyuyordu.
Bu sorunu kaynağında çözen bir araç aradık. Ticket geliştiriciye ulaşmadan önce doğru soruları soran bir iş akışı. Hiç bulamadık.
Bu yüzden kendimiz inşa ettik. Kendi destek ekibimiz için dahili bir araç olarak başlayan şey NevaBridge'e dönüştü.
tüm hata raporlarının, bir geliştirici başlayabilmeden önce en az bir açıklamaya ihtiyaç duyduğu oran
eksik raporlarda ilk çözüme kadar geçen daha uzun süre
Bir ürün inşa etmeye çalışmadık. Kendi sancımızı çözmeye çalıştık. NevaBridge var çünkü bizim gibi ekipler için bu sorunu başka kimse çözmedi.
Kurucu ekibimiz, bu sorunu ilk kez yaşadığımız platformu inşa etti ve işletti. Binlerce destek etkileşimini yürüttük, yüzlerce hata raporunu kendimiz triaj ettik ve belirsiz ticket'ların sancısını bizzat yaşadık. Bu sancı noktasını bir pazar raporunda okumadık. Onu haftalarca, yıllar boyunca yaşadık.
NevaBridge'i geliştirmeye başladığımızda, aynı tabloyu diğer taraftan bilen bir CTO'yu ekibe kattık. AWS'te Senior Software Engineer olarak, sektörün en olgun mühendislik süreçlerinden bazılarına sahip bir şirkette bile, yıllarca eksik hata raporlarının alıcı tarafında durmuştu. Sorun bize özgü değildi. Yapısaldı.
Bu kombinasyon NevaBridge'i şekillendiriyor. Ekibin bir tarafı bir ürünü işletmenin, müşterilerle konuşmanın ve desteği gürültüden korumanın ne demek olduğunu biliyor. Diğer taraf, bir geliştiricinin bir issue'ya başlamak için gerçekten neye ihtiyaç duyduğunu – ve bu bilgiler eksik olduğunda işin ne kadar pahalıya mal olduğunu biliyor. Açıklama uzun sürdüğü için değil; her geri soru geri gönderildiği, saatlerce veya günlerce yanıt beklediği ve geliştirici o zamana kadar çoktan başka bir şey üzerinde çalıştığı için. NevaBridge her iki bakış açısının kesişiminde doğuyor.
gerçek kullanıcıları ve gerçek destek hacmi olan bir SaaS platformunu işletme
startup'lardan ve kamu sektöründen AWS'teki Senior Engineer rolüne kadar enterprise yazılım geliştirme.
Teoriden inşa etmiyoruz. Binlerce gerçek sohbetten, gerçek ticket'lardan ve devir teslimin her iki tarafındaki gerçek hayal kırıklığından inşa ediyoruz.
NevaBridge henüz erken aşamada. İlk modülü inşa ediyoruz: dahili hata raporlama. Bir ekip üyesi bir sorunu doğal dille açıklıyor. NevaBridge neyin var olduğunu analiz ediyor, neyin eksik olduğunu fark ediyor, hedefli geri sorular soruyor ve sorun takip sisteminizde yapılandırılmış, geliştiriciye hazır bir ticket oluşturuyor.
Bu, bir formun üzerine oturtulmuş genel bir chatbot değil. NevaBridge üç düzeyde çalışıyor. Kutudan çıktığı haliyle, geliştiricilerin bir hata raporunda tipik olarak neye ihtiyaç duyduğunu zaten biliyor – ürün geliştirme, pilot müşterilerle çalışma ve açık kaynaklı sorun takip sistemlerini analiz etme konusundaki kendi deneyimimizden inşa edilmiş. Bunun ötesinde, terminolojinizi, özelliklerinizi ve bilinen issue'larınızı öğrenmesi için onu kendi ürün dokümantasyonunuz ve geçmiş hata sohbetlerinizle besleyebilirsiniz. Ve kanıtlanmış başlangıç şablonumuzun yanında kendi rapor şablonlarınızı oluşturabilirsiniz. NevaBridge her sohbet için uygun olanı seçiyor.
İşte bu kombinasyon, belirsiz bir cümleyi bir geliştiricinin hemen üzerinde çalışabileceği bir ticket'a dönüştürüyor – tek bir geri soru olmadan.
Sancının en büyük olduğu yerden başlıyoruz. Hata raporları, insanların söyledikleri ile geliştiricilerin ihtiyaç duyduğu arasındaki açığın en büyük olduğu yer. Bu tek şeyi iyi yapmak, sonrasında gelen her şeyin temeli.
Onu her gün kendimiz kullanıyoruz. Ve aynı sancıyı bilen ekipler arıyoruz.
üretimde modül, bilinçli olarak dar tutuldu
NevaBridge ticket'ı yazdığında gereken geri soru
Üçü de hazır olana kadar ekipleri bekletmektense, gerçek bir sorunu çözen bir modülü şimdi sunmayı tercih ederiz.