Як організована робота над системою FoodSoul: від ідеї до результату

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

FoodSoul — це жива система

FoodSoul — це не просто застосунок. За ним стоїть велика інфраструктура: CRM, зберігання та захист даних, шаблони сайтів і мобільних застосунків та тисячі ресторанів-партнерів, кожен зі своїми потребами та сценаріями роботи.

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

Як влаштована команда та структура роботи

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

Техпідтримка — перша лінія контакту з партнерами. Вона приймає звернення, розбирається в суті проблеми і або вирішує її на місці, або передає далі спеціалісту, який знає потрібну ділянку системи.

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

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

Розробники та тестувальники реалізують завдання і перевіряють їх перед випуском — від невеликих правок до масштабних доопрацювань функціоналу.

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

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

Як ми розставляємо пріоритети

Коли виникає проблема, ми діємо за одним із сценаріїв.

Масовий збій — помилка, з якою протягом дня або кількох годин зіткнулися кілька клієнтів одночасно. Це найвищий пріоритет: тестувальник і розробники підключаються негайно.

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

Стандартний баг — звернення, прийняте техпідтримкою, яке не виглядає як катастрофа. Його бере в обробку спеціаліст другої лінії, який добре знає систему. Можливі два варіанти: або з'ясовується, що це особливість роботи функціоналу, яку не врахували, тоді клієнту пояснюють рішення; або проблема дійсно існує, тоді вона потрапляє до керівника проєктів, фіксується у системі завдань із пріоритетом і відповідальним і реалізується у порядку черги. Спеціаліст техпідтримки відстежує статус і повідомляє клієнту, коли завдання виконано.

Мінорний баг — помилка, яка не впливає на роботу системи, але потребує виправлення: друкарська помилка, зсунутий елемент інтерфейсу, невірний колір кнопки. Такі завдання беруться у роботу, коли немає більш пріоритетних звернень із пунктів вище.

Побажання — ми уважно стежимо за тим, що просять партнери. Коли одне й те саме прохання надходить від кількох клієнтів, пріоритет зростає, і ми беремо його на аналітику. Будь-яка зміна стосується всіх партнерів одразу, а не лише того, хто попросив, тому перед реалізацією ми збираємо зворотний зв'язок від різних клієнтів, щоб покращення для одних не створювало незручностей для інших. Це додатковий крок, але саме він робить фінальне рішення більш зваженим.

Чому виникають баги

Розробка будь-якого складного продукту влаштована так, що помилки — це регулярна частина процесу, а не виняток. Ось із чого складається ця складність.

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

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

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

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

Вимоги уточнюються у процесі. Іноді функція реалізована саме так, як було задумано, але при реальному використанні з'ясовується, що задум варто доопрацювати. Так продукт стає точнішим із кожною ітерацією.

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

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

З повагою,

Project Manager FoodSoul