Втратили від $100 000 на невдалих проєктах: Burny Games про факапи, закриті проєкти, і відправлений фідбек не тим кандидатам
Режим читання збільшує текст, прибирає всю зайву інформацію зі сторінки і дозволяє зосередитися на матеріалі. Тут ви можете вимкнути його в будь-який момент.
Ви коли-небудь відчували легкий тремор у руках в момент усвідомлення факапу — коли здається, що земля йде з-під ніг, прірва підступає і нічого вже не вдасться виправити?
У колонці для Vector Анатолій Геніс, СЕО Burny Games, української компанії і паблішера мобільних ігор у жанрі пазлів, розповів про памʼятні кейси за чотири роки компанії. Як і на основі яких метрик компанія зупиняла розробку продуктів, чому перейшли до автономних бізнес-юнітів замість крос-проєктного розподілу ресурсів та чим відрізняється паблішинг-модель компанії від стандартного конвеєрного підходу.
Три закриті проєкти: перфекціонізм на MVP-стадії коштує дорого
За чотири роки ми зупинили розробку кількох проєктів: Super Cooker, Balls Path, Block Brush, Colorwood Screw. Кожен мав обнадійливі сигнали на старті — але коли метрики не давали підстав для масштабування, ми зупинялися. Я не назву ці історії факапами, але вони точно багато чому нас навчили.
Colorwood Screw — найчіткіший приклад того, як перфекціонізм переміг прагматичний підхід. Команда настільки загорілася ідеєю, що з першого дня пішла в pixel-perfect-графіку і складний продакшн-пайплайн замість швидкого тесту. Хотіли зайти у знайомий жанр і стати в ньому найкращими. Поки полірували — ринок пішов далі. CPI вийшов за межі допустимого, перший день не дав потрібних цифр. Бездоганна реалізація не рятує проєкт, якщо пропущено вікно.
Super Cooker — шість місяців розробки, і гра так і не знайшла свого гравця. UX-апдейти, нові фічі, ще один раунд тестів — але механіка просто не давала достатнього плейтайму, а трафік дорожчав. Block Brush стартував непогано — 100 000 завантажень, — але на довгій дистанції гравці не залишалися.
Ми втратили близько $100 000 на невдалих старих проєктах, без урахування витрат на команду. Частину коштів вдалося повернути, але тоді ми так і не вийшли на рівень, де продукт можна масштабувати.
Тепер усі стопери узгоджуються до старту. Не після першого спринту і не тоді, коли команда вже емоційно вкладена в ідею, а до того, як написано перший рядок коду. Якщо проєкт не вкладається в ці межі — ми закриваємо його без тривалих дискусій.
Пропущений деплой і AI, який виявився уважнішим за людину
Минулого листопада ми завершили успішний A/B-тест. Метрики виглядали добре, рішення було прийняте — розкочуємо виграшний варіант. Але через помилку в конфігурації він так і не потрапив у продакшн. Через брак контексту під час підміни на період відпусток пропустили перевірку виведення коду в продакшн (деплою) після завершення тесту. Чотири дні виграшний варіант існував у системі, але не для гравців.
Спрацював наш пілотний AI-агент для моніторингу аналітики — стороння фіча в сервісі, яку команда тестувала як додатковий шар до внутрішніх алерт-систем. Ми підключили його до дашборду одного з A/B-тестів, і під час моніторингу він зафіксував аномалію: написав у Slack, що одна з тестових груп, ймовірно, перестала працювати, оскільки за частиною графіків було видно різке й нелогічне просідання метрик.
Після цього ми одразу перевірили конфігурацію і виявили, що на етапі фіналізації тесту були некоректно застосовані налаштування, які й спричинили збій. Завдяки цьому алерту швидко знайшли й виправили проблему.
Цей момент змінив ставлення до автоматизації. Це стало підтвердженням стратегії: правильні інструменти підстраховують команду там, де людина працює поза звичним контекстом. З процесного боку все простіше: підміна потребує чекпойнта після деплою.
Схожа історія сталася в іншій команді під час допомоги новій колезі, яка працювала другий тиждень у компанії. Виник конфлікт у Git — інструменті, який зберігає історію всіх змін у проєкті й не дає одному члену команди випадково стерти роботу іншого. Конфлікт виникає, коли двоє редагують один файл одночасно і система не розуміє, яку версію залишити. Було запропоновано повернутися до попередньої версії файлів, але перед цим не зробили резервну копію.
У результаті весь шматок роботи нової колеги зник. Частину задачі вдалося відновити через перезапуск Unity — рушія, в якому створюється гра, — решту вона відтворювала вручну. Ця історія стала показовим прикладом того, що навіть досвідчені фахівці та ліди відділів помиляються не менше за інших.
Фідбек у чаті, де сидів кандидат, і лист не тому адресату
Комунікаційні факапи — окрема історія. Їх не видно в дашборді, але вони осідають надовго. У нас була відкрита вакансія менеджера для команди з дев’яти людей. Вона довго не закривалася, але всередині команди був сильний кандидат, якого ми розглядали на підвищення замість зовнішнього найму.
У нас є стандартна процедура для внутрішніх переходів: підготувати письмовий огляд можливих ризиків. У чат вакансії надіслали детальний фідбек щодо кандидатури — із сильними сторонами, зонами росту та нюансами, які варто врахувати.
За кілька хвилин колега, не перевіривши список учасників, тегнув у тому ж чаті самого кандидата з питанням про ці ризики. Він був там як інтерв’юер від команди і прочитав усе — включно з тим, що явно призначалося не йому. Кандидат (він же інтерв’юер) відреагував спокійно і зріло: сказав, що розуміє ці ризики і готовий із ними працювати. Підвищення відбулося, і він веде команду досі.
Перевіряти список учасників перед відвертим фідбеком — тепер перше, що робить кожен у подібній ситуації. Крім того, ми змінили підхід до процесів, щоб менше залежати від людського фактору: розвели канали комунікації за рівнем чутливості та перенесли ключову взаємодію в HR-системи — TalentLyft для роботи з кандидатами і Hibob, де весь фідбек зберігається централізовано. Також зараз автоматизуємо процес ротації фахівців у Hibob, поєднуючи Performance Review і 360°-фідбек, щоб рішення ухвалювалися на основі даних, а не суб’єктивних оцінок.
Схожа ситуація сталася під час налагодження стратегічного партнерства, але з іншим фіналом. Під час надсилання інтролиста через поспіх обрали помилкового адресата: однакове ім’я, але інша компанія. Усі троє прочитали повідомлення і замість незручної паузи вирішили познайомитися. Знайшли спільні точки та домовилися про дзвінок. Згодом зробили правильне інтро, але продуктивна розмова вже відбулася сама собою.
У висновку авторка помилкового листа написала: «Треба вчасно йти у відпустку». Це про те, що перевантажена людина робить прості помилки на автопілоті. І зменшення цього перевантаження — відповідальність менеджменту.
Іконка конкурента в пості і QR-коди на вокзалі
Наприкінці 2024 року команда комунікацій готувала допис про ігри Burny Games. Для однієї публікації ми використали іконку конкурентів, яка візуально була дуже схожа на нашу й тому випадково опинилась у теці з рештою креативів. Помилку після публікації помітила продуктова команда.
Під час підготовки до конференції вирішили ще раз перевірити QR-коди на вже готовій POS-продукції. Виявилося, що жоден із них не читався. Одразу надіслали запит до технічної команди: «Алярм, у нас код 502».
За пів години пошуку виявили баг на стороні сервісу. Написали напряму CTO цього сервісу, і технічну помилку виправили за кілька годин. Пізніше помітили ще одну проблему: на частині носіїв коди були фізично замалі для більшості камер. Матеріали вчасно замінили, і в результаті конференція перевищила KPI.
Досвід не рятує від помилок (але допомагає з ними жити)
У нас fail-friendly-культура про систему швидкої реакції та рефлексію факапів. Кожен із них проходить такий цикл: помітили → розібрали → внесли зміну в процес → закріпили в роботі.
Чек-ліст із цього досвіду:
- Чи є перевірка після важливих змін? Реліз, деплой, новий процес — за кожною зміною має стояти конкретна людина, яка відповідає за цей напрям.
- Чи зрозумілий процес без додаткових пояснень? Фундаментальні речі мають бути зафіксовані. Новачку варто пояснити суть і мотивувати ставити запитання. У нас не соромно не знати й хотіти розібратись.
- Чи завершується розбір факапу конкретною зміною? Не кожен інцидент потребує нового регламенту, але кожен — якогось фіксованого кроку: уточнення в документації, зміни в шаблоні або додаткової перевірки на етапі здачі.
- Чи однаково уважно ставитесь до комунікації на всіх рівнях? Внутрішня і зовнішня комунікація потребують такого ж ревʼю як продукт. Помилка в листі партнеру або мовчання там, де очікували відповідь — не окей.
- Чи є у команди звичка питати «як не допустити повторення» після кожного збою? Це питання ставимо регулярно.
Більше про це
Ребрендинг в $500 000: навіщо його робити, коли продукт і так заробляє — досвід Nebula
Будь-яку статтю можна зберегти в закладки на сайті, щоб прочитати її пізніше.
Партнерські матеріали
