NevaBridge починався не як продукт. Він починався як наш власний біль: тисячі розпливчастих баг-репортів на платформі, яку ми самі обслуговуємо. Тож ми побудували шар, який ставить правильні запитання ще до того, як тікет потрапить до розробника.
Команда NevaBridge також обслуговує Calendall — популярну систему управління клієнтами та планування зустрічей для салонів. Щотижня надходили запити клієнтів електронною поштою, у чаті та через тікети підтримки: запитання, ідеї функцій і баг-репорти. Кожен треба було прочитати, зрозуміти й перенаправити в потрібне місце. А якщо це був баг-репорт? Нашим розробникам майже завжди доводилося перепитувати. Який браузер? Який екран? На що саме ти натиснув, перш ніж усе перестало працювати?
Повідомлення не були поганими. Вони просто були неповними. І кожне уточнення коштувало часу, контексту й нервів обом сторонам. Ми це виміряли: 44% усіх баг-репортів потребували щонайменше одного раунду уточнень, перш ніж розробник міг хоча б почати. Деякі потребували трьох або чотирьох раундів.
Ми шукали інструмент, який розв'язує цю проблему в самому джерелі. Робочий процес, що ставить правильні запитання, перш ніж тікет потрапить до розробника. Ми не знайшли жодного.
Тож ми побудували його самі. Те, що починалося як внутрішній інструмент для нашої власної команди підтримки, перетворилося на NevaBridge.
усіх баг-репортів потребували щонайменше одного уточнення, перш ніж розробник міг почати
довший час до першого розв'язання у разі неповних повідомлень
Ми не намагалися побудувати продукт. Ми намагалися розв'язати власний біль. NevaBridge існує тому, що ніхто інший не розв'язав цю проблему для команд на кшталт нашої.
Наша команда засновників побудувала й обслуговувала платформу, на якій ми вперше пережили цю проблему. Ми обробили тисячі взаємодій з підтримкою, самі провели триаж сотень баг-репортів і на власній шкірі відчули біль розпливчастих тікетів. Ми не вичитали цю больову точку у звіті про ринок. Ми проживали її тижнями, роками поспіль.
Коли ми почали розробляти NevaBridge, ми залучили до команди CTO, який знав той самий патерн з іншого боку. Як Senior Software Engineer в AWS він роками стояв на приймальному боці неповних баг-репортів, навіть у компанії з одними з найзріліших інженерних процесів у галузі. Проблема не була унікальною для нас. Вона була структурною.
Ця комбінація формує NevaBridge. Один бік команди знає, що означає обслуговувати продукт, спілкуватися з клієнтами та захищати підтримку від шуму. Інший бік знає, що насправді потрібно розробнику, щоб почати роботу над issue — і наскільки дорого це обходиться, коли цієї інформації бракує. Не тому, що уточнення довге, а тому, що кожне запитання відправляється назад, годинами чи днями чекає на відповідь, а розробник на той час уже давно працює над чимось іншим. NevaBridge постає на перетині обох перспектив.
обслуговування SaaS-платформи з реальними користувачами та реальним обсягом підтримки
розробки enterprise-програмного забезпечення, від стартапів і державного сектору до ролі Senior Engineer в AWS.
Ми будуємо не з теорії. Ми будуємо з тисяч реальних розмов, реальних тікетів і реального розчарування з обох боків передавання.
NevaBridge на ранньому етапі. Ми будуємо перший модуль: внутрішнє баг-репортування. Член команди описує проблему природною мовою. NevaBridge аналізує, що є, розпізнає, чого бракує, ставить цільові уточнювальні запитання й створює структурований, готовий для розробника тікет у вашій системі відстеження задач.
Це не загальний чатбот, накладений на форму. NevaBridge працює на трьох рівнях. З коробки він уже знає, що зазвичай потрібно розробникам у баг-репорті — побудовано на нашому власному досвіді розробки продуктів, роботи з пілотними клієнтами та аналізу систем відстеження задач з відкритим кодом. Понад те, ви можете живити його власною документацією продукту та минулими розмовами про баги, щоб він вивчив вашу термінологію, ваші функції та ваші відомі issue. І ви можете створювати власні шаблони звітів поряд з нашим перевіреним стартовим шаблоном. NevaBridge обирає відповідний для кожної розмови.
Саме ця комбінація перетворює розпливчасте речення на тікет, над яким розробник може одразу працювати — без жодного уточнювального запитання.
Ми починаємо там, де біль найбільший. Баг-репорти — це місце, де розрив між тим, що кажуть люди, і тим, що потрібно розробникам, найбільший. Зробити цю одну річ добре — це основа для всього, що йде далі.
Ми користуємося ним самі, щодня. І ми шукаємо команди, які знають той самий біль.
модуль у продакшені, свідомо вузький
уточнювальних запитань потрібно, коли NevaBridge пише тікет
Ми радше зараз надамо модуль, що розв'язує реальну проблему, ніж змусимо команди чекати, доки всі три будуть готові.