Як побудувати ефективну систему Quality Control, коли аналогів немає

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Вітаю, я Юлія, Chief Operating Officer математичного сервісу MathMaster від Futurra Group. У цій статті я поділюся досвідом побудови системи Quality Control (далі — QC) та розповім, як нам вдалося у дві ітерації створити математичну саплай-команду з A-players.

Маркетплейси стали звичною частиною нашого життя та значно прискорили його темп — сервіси таксі, доставки їжі, оренди житла, онлайн шопінгу тощо. Втім, окрім значної щоденної користі для юзерів, ці сервіси мають між собою і ще дещо спільне — усі вони поєднують попит користувача (demand) з пропозицією від виконавців сервісу — supply side.

На початку 2022 року ми створили EdTech-продукт — освітній маркетплейс, де учні в будь-який час можуть отримувати допомогу у розв’язанні математичних задач напряму від викладачів математики. Спочатку це був застосунок-сканер, що миттєво надавав відповіді на прості математичні задачі з фото або написані від руки. Оскільки ця функція покривала до 30-40% запитів користувачів, ми зрозуміли що хочемо знайти рішення, як задовольняти більше.

«А що буде, якщо додати чат з експертами-математиками та вирішувати всі запити?» — з цієї сміливої думки почався розвиток MathMaster. Експеримент виявився успішним — ми майже одразу побачили, що спілкування з живим експертом значно збільшило довіру користувачів до нашого сервісу. Ми впевнились: люди все ще більш схильні довіряти живим людям, ніж алгоритмам.

Втім, ми також усвідомили, що розвивати продукт зі саплай-складовою — це вищий рівень складності, адже треба з нуля побудувати великий багаторівневий механізм, де усі процеси працюватимуть як годинник. А для цього слід спершу вирішити низку важливих проблем:

• навчитись масово набирати штат саплай-агентів та балансувати їхню кількість з попитом, що створює маркетинг;
• знайти оптимальний кост на операційні витрати, який не поглине виторг;
• і найскладніше — зробити послугу максимально якісною для користувача, щоб він постійно повертався.

До останнього пункту ми йшли близько року, постійно змінюючи та покращуючи процеси. Зокрема, консультувалися з командами, які створювали подібні маркетплейси із саплай, але ніша математики виявилась більш специфічною. Складність схеми перевірки відповідей в MathMaster полягає в унікальності кожного замовлення.

Навіть якщо в нашій базі існує авторозвʼязання, експерт повинен впевнитись, чи відповідає він умові задачі та чи є він правильним. Оскільки уніфікувати готові рішення для різних задач неможливо, ми повинні були створити з нуля механізм оцінки якості, який би відповідав специфіці нашого сервісу.

Виклики supply side в побудові QC-процесів

Supply side з математичними експертами — це серце MathMaster. Завдяки їм користувачі 24/7 мають під рукою репетиторів, які допоможуть з розв’язанням будь-якої задачі.

Рівень складності запитів варіюється від початкових класів школи до випускних курсів університету. Це стало передумовою поділу саплай на три лінії:

Table 1: Organizational Structure of MathMaster Supply Experts’ Team

Очевидно, що правильність відповіді на задачу користувача — це фундаментальний показник якості сервісу. Аби оцінити роботу наших експертів, ми вивели метрику Mistake Rate — відсоток помилок від кількості перевірених задач. Відповідно до цього показника ми розділили експертів на рівні кваліфікації за рейтинговою системою:

Table 2: Level of Experts’ Performance

Побудувати ефективну систему перевірки математичних рішень стало справжнім викликом через три фактори складності в роботі з supply side:

1. Операційні витрати на експертів.

За 2 роки роботи ми сумарно створили понад 1000 робочих місць для математиків, які хочуть заробляти онлайн. Бізнес має окуповувати витрати за компенсацію розв’язків та при цьому бути прибутковим.

2. Сезонність ніші.
   

Попит на вивчення математики залежить від пори року та роботи навчальних закладів. Під час літніх канікул, різдвяних та національних свят потреба в математичних розв’язках різко знижується, а отже експерти отримують менше задач. Під час іспитів навпаки — попит на сервіс зростає до пікових показників, і тому нам потрібно наймати та виводити на зміни велику кількість спеціалістів за екстрено короткий термін.

3. Обмежене поле для автоматизації розвʼязків.
   

Основна складність для автоматизації розвʼязків — це умова задачі, яку користувач у 90% випадків надсилає у форматі фото. Знімки можуть мати графіки, фігури, символи у Latex, нерозбірливий почерк. Для 30% запитів нашій команді розробників вдалося автоматизувати процес розв’язку. У таких випадках експерти перевіряють вже готові відповіді на достовірність, а після — миттєво надсилають їх замовникам. Решту 70% задач математики вирішують вручну, використовуючи технології для пришвидшення розрахунків.

Оскільки оцінка правильності є частиною операційних витрат, перевірка кожного розв’язку кожного експерта — це дороге задоволення. Вартість цього функціоналу перевищувала б витрати на послуги самих математичних експертів, адже спеціалісти, які можуть перевірити достовірність їхніх відповідей, — це справжні гуру математики, які викладають в університетах або займаються науковою діяльністю і, відповідно, мають вищі зарплатні очікування.

Отже, найняти однакову кількість ревʼюерів і експертів — це найпростіший шлях, яким ми піти не могли.

Нам потрібно було зрозуміти, як мінімальна кількість сильних математиків може систематично оцінювати роботу саплай в 500-1000 експертів. Ми рухались за принципом learning by doing: оптимізували систему перевірки в кілька ітерацій, відштовхуючись від її недосконалості та обмежених ресурсів на покращення.

Ітерація 1: перевірка відсотка відповідей на реальні задачі користувачів

Складність системи контролю саплай-напряму залежить від кількості спеціалістів, що надають послуги. У перший рік запуску операційного бізнесу MathMaster взяв вектор на агресивне масштабування пошукового трафіку. Для саплай це означало стрімке зростання кількості задач від юзерів, і, відповідно, збільшення команди експертів, які будуть їх розв’язувати. Та чим більша кількість математиків, тим складніше перевірити рівень кожного з них.

Перевірка якості роботи 40 експертів — це задача для одного QC-менеджера, який може охопити абсолютно всіх. Для команди такого розміру достатньо було перевіряти однакову кількість рандомно вибраних розв’язків, які відправлялися користувачам.

Ми розуміли, за якими критеріями шукати помилки:

• негативні відгуки юзерів;
• довгий час розв’язку від експерта;
• велика кількість задач в одному запиті тощо.

До того ж було легко бачити динаміку перфомансу: коли відбувається перевірка 40 експертів на постійній основі, менеджер може пам’ятати слабкі та сильні сторони кожного члена команди, так само як один вчитель добре знає всіх учнів у класі. Але коли за півтора місяця команда росте з 40 до 115 експертів, такий процес перевірки перестає бути ефективним.

Чому ітерація 2 була неминучою

Саплай стрімко наймав все більше експертів, а кількість рев’юерів в QC-команді була обмеженою. Згодом стало очевидно, що ми не можемо перевіряти кожного математика щотижня. Довелось обходитись схемою пріоритезації:

Table 3: Prioritization of checked solutions (QC System 1)

Найчастіше перевірялись новачки, чию роботу в перший місяць треба контролювати найбільше. Важливо якомога швидше визначити їх рівень і динаміку прогресу, щоб прийняти рішення про можливість подальшої співпраці. Найрідше перевірялись експерти, які помилялись найменше, та в попередній період зарекомендували себе як найсильніші математики.

Саплай ріс невпинно: ще через два місяці у команді вже було 330 експертів. Ми знали, що на цьому не зупинимось, адже планували агресивного масштабувати трафік під час початку навчального сезону у вересні.

Щоб досягти цієї мети та покрити деманд восени, операційна команда повинна була підготувати до роботи близько 500-600 експертів. Стало очевидно, що дійсна система перевірки розв’язків вже не змогла б охопити таку велику команду, зокрема, через дві гострі проблеми:

• різна частота перевірок (для А/В/С та D-рівнів);
• об’єктивність оцінки та динаміка перфомансу.

Результати перевірок одних і тих самих експертів щоразу разюче відрізнялись. Топові перформери могли різко опускатись вниз рейтингу одного тижня, а потім повернутись на перші місця наступного.

1. Плинність кадрів

Через нестабільність результатів було важко визначати, якого експерта варто залишити в команді, а з яким якнайшвидше попрощатись. Ми бачили, що найм експертів не зупинявся: в один тиждень ми могли найняти 20 нових експертів та одночасно звільнити 10 з тих, хто вже якийсь час з нами пропрацював.

Без ефективної системи перевірки саплай не може забезпечити високу якість сервісу для користувача. Тому ми поставили собі за мету зробити апдейт, з урахуванням наступних факторів:

• рівні умови перевірки для всіх експертів (метод з рандомно обраними задачами не спрацював);
• однакова частота оцінювання всіх експертів та зрозуміла динаміка перфомансу;
• відмова від масштабування команди рев’юерів для мінімізації операційних витрат;
• автоматизація запуску перевірки та репортів з результатами;
• можливість швидко визначати експертів, які багато помиляються, та швидко прощатися з ними.

Ітерація 2: автоматизована система перевірки

Нам вдалося реалізувати апдейт системи, відштовхуючись від недоліків попередньої ітерації. Наші розробники реалізували автоматизацію запуску перевірок менше, ніж за місяць, що було блискавично швидко. Далі операційна команда завдяки системній роботі з експертами впродовж пів року підняла якість сервісу MathMaster на новий рівень. Ось що було зроблено.

1. Відмова від масштабування команди рев’юерів.

Оскільки наймати велику кількість рев’юерів дорого та довго, ми поставили собі запитання: а хто може їх замінити? Наші найсильніші математики — це Line 3, вони розв’язують найскладніші задачі користувачів, а значить мають достатню компетенцію, щоб перевіряти розв’язки експертів Line 1 i Line 2.

Далі нам треба було розрахувати capacity команди рев’юерів з метою оцінки відповідей Line 3-експертів, які розв’язують 20% задач у застосунку. Це адекватна цифра для покриття потреби в перевірці командою рев’юерів. Навіть за умов агресивного масштабування, досить реально найняти ще кількох сильних математиків у Quality Control та не збільшувати штат, рівноцінний розміру команди експертів.

2. Рівні умови перевірки.

Раніше ми перевіряли рандомно обрані розв’язки. Це були різні задачі за рівнем складності та галуззю математики. Так ми могли визначити відсоток помилок у перевіреній кількості задач, але не могли порівняти експертів між собою.

Для того, щоб об’єктивно визначати рівень перфомансу експертів (A/B/C/D), важливо порівнювати їх в рівних умовах. Отже, ми вирішили створити три набори однакових задач для кожної окремої лінії експертів та відправляти їх під виглядом реальних запитів від користувачів.

За такої системи ми платимо за перевірку задачі тричі: 1) за її створення, 2) за розв’язок, 3) за оцінку. На перший погляд, такий підхід може здатися абсурдним, але розрахунки показали, що це вдвічі дешевше за паралельне масштабування команд експертів та рев’юерів.

Ми змогли зменшити ціну за перевірку шляхом того, що показуємо Line 3 готове покрокове рішення, і все, що їм залишається зробити — звірити розв’язок Line 1/Line 2 з правильною відповіддю рев’юера. Оскільки така робота значно простіша за розв’язок з нуля, то і перевірка коштує вдвічі дешевше. Line 3 оцінює правильність відповідей інших експертів, коли попит від користувачів спадає (зазвичай це нічний час).

3. Автоматизація запуску системи перевірки.

За першої ітерації вибір експертів та задач, які треба перевірити, відбувався вручну. Коли в MathMaster працювало менш як 100 математиків, нам вдавалось підтримувати систематичність оцінки для кожного з них. Проте коли ми найняли 300+ експертів, стало складно фіксувати порядок перевірки.

Кожного дня до нас приєднувалось багато новачків, тому дуже швидко група математиків, яка підпадала під «пріоритет 1», стала найбільшою, а ресурсів команди Quality Control лишалось менше для експертів «пріоритету 2/3/4».

Table 3: Prioritization of checked solutions (QC System 1)

Це порушувало систематичність оцінки рівня спеціалістів та перетворило процес перевірки на суцільний хаос.

Оскільки за новою системою Quality Control ми оцінювали рівень експертів за однаковими задачами, ми змогли автоматизувати повний цикл перевірки, а саме, за такою схемою:

Table 4: The automation scheme for the entire QC cycle

Така автоматизація забрала більшу частину monkey job з команди QC. Відтоді фокусом її менеджера стало відстежування основних метрик і динаміки якості перфомансу експертів, а основною задачею ревʼюерів — підготовка задач для перших двох ліній, пильний нагляд за якістю розв’язків Line 3 та їхньою об’єктивністю оцінювання Line 1 та Line 2.

4. Швидкі звільнення на користь A-players

Коли ми перейшли на систему оцінювання за однаковими задачами, почали виявляти вдвічі більшу кількість помилок, ніж за рандомним алгоритмом оцінки. І справа не в тому, що експерти почали помилятись більше, а в тому, що новий підхід показував більш реалістичну картину.

QC-команда приділяла багато уваги підвищенню кваліфікації експертів, щоб вони менше помилялись. Проте фокус на навчанні не приніс помітних результатів. Проаналізувавши, що робить наших найкращих експертів A-players, ми зрозуміли, що їх всіх об’єднують три спільні характеристики в роботі:

• хороша математична база;
• швидкість розвʼязку (завдяки вправному використанню інструментів для автоматизації);
• відповідальне ставлення до користувача.

Ми зрозуміли, що задача підняти рівень тих математиків, які багато помиляються, не приведе нас до покращення рівня сервісу. Натомість вирішили зосередитись на двох фундаментальних процесах:

1. Автоматизація виявлення D-level-експертів. Ми швидко попереджаємо їх про негативний результат і даємо останній шанс виправити перфоманс. Як тільки система виявляє нижній поріг якості, одразу запускається новий сет задач для оцінки. Далі рішення приймається автоматично: якщо експерт показує значно кращий результат, ми продовжуємо співпрацю, якщо прогресу хоча б до С-level немає, ми даунгрейдимо експерта або ж і зовсім припиняємо з ним співпрацю.
2. Підняття планки для нових кандидатів. Ми поставили собі за мету наймати тільки найкращих експертів і допускати до користувачів лише тих, хто припустився не більше однієї помилки під час тестової зміни.

Результат апдейту Quality Control

Завдяки автоматизованій системі перевірки розвʼязків ми оновили команду експертів та змогли довести, що правильність розв’язку впливає на монетизацію продукту. Наша команда провела А/В-тест та виявила, що APRS (average revenue per subscription) користувачів, яким задачі розвʼязували A-level-експерти, вищий на 35%, ніж у тих, над чиїм запитом працювали математики рівня B/C/D.

Апдейт системи QC допоміг нам:

• зменшити mistake rate команди з 18% до 8%;
• збільшити відсоток топових спеціалістів з 40% до 65%;
• налагодити частоту і системність перевірки для всіх математиків: відтепер 80% експертів у команді мають понад дві перевірки на місяць.

Table 5: Comparison of 1st & 2nd Quality Control system updates

Отже, методом спроб та помилок, наша команда упродовж двох ітерацій змогла побудувати ефективну систему Quality Control, завдяки якій стало можливим масштабувати саплай та не втрачати у якості.