Почему 65% задач в мобильной студии делают вручную и как это стоит 280 тыс ₽/квартал
Каждое утро Игорь открывал три мессенджера, две таблицы Excel и почту — и только после этого мог понять, что вообще происходит в команде. Звучит знакомо?
65% операционных задач в его студии делались вручную. Тестировщиков распределяли по спринтам в табличке, баги ловили по чатам, релизы согласовывали через письма. Разработчики теряли по 2-3 часа в день просто на то, чтобы переключаться между инструментами — не писать код, а искать информацию. Итог: срывы сроков каждый квартал, штрафы от клиентов, трое middle-разработчиков ушли за полгода. В деньгах — около 790 тысяч рублей потерь за полугодие.
Парадокс в том, что студия работала на современном стеке, делала качественные продукты — и при этом тонула в ручной рутине. Проблема была не в людях и не в технологиях. Проблема была в том, как всё это соединено между собой.
Контекст клиента
К нам обратился Игорь - CTO мобильной студии из Санкт-Петербурга. Команда 28 человек, оборот 18 млн ₽ в месяц, портфель из iOS и Android-проектов для B2B-клиентов. Студия работала уже четыре года, но операционная модель так и осталась «стартаперской»: спринты раскидывали в Excel, баги ловили по Telegram-чатам, а согласование релиза с клиентом превращалось в отдельный квест из писем, пересылок и звонков.
Игорь пришёл к нам не с чистого листа. Порядок пытались навести своими силами: завели доску в Notion, пробовали структурировать чаты, один из разработчиков даже написал скрипт для выгрузки задач. Ничего не прижилось. Когда за полгода ушли три middle-разработчика, а квартал закрылся с 18% срывом сроков - Игорь решил, что пора звать кого-то со стороны.
Что у них болело (в цифрах)
Мы начали с аудита. Попросили Игоря и двух тимлидов три дня фиксировать, на что уходит время. Картина оказалась предсказуемо грустной - но масштаб всё равно удивил.
Ошибка №1: Распределение спринта в Excel. Каждые две недели тимлид садился и вручную перекладывал задачи между разработчиками и тестировщиками в таблице. На это уходило в среднем 4 часа. При этом таблица никак не была связана с Jira, где лежали все задачи, - данные переносили руками. Цена одной ошибки в распределении: задача «зависала» без исполнителя на 1-2 дня, и никто этого не замечал.
Ошибка №2: Баги жили в разных чатах. Тестировщики писали о проблемах туда, где было удобно: в общий чат проекта, в личку разработчику, иногда создавали задачу в Jira, иногда нет. В итоге разработчик не понимал, что именно ему нужно фиксить прямо сейчас. Каждый тратил по 2-3 часа в день только на то, чтобы разобраться, что вообще происходит.
Ошибка №3: Согласование релиза - это был квест. Перед релизом нужно было получить подтверждение от PM, тимлида и клиента. Всё шло через email. Среднее время согласования - 6-8 часов. Несколько раз релиз задерживался просто потому, что письмо потерялось в почте.
Ошибка №4: Никто не считал потери в деньгах. Задержки релизов оборачивались штрафами по контрактам - около 340 тыс ₽ в квартал. Текучка разработчиков - это найм, онбординг, потеря контекста по проектам. Три ушедших middle за полгода стоили студии порядка 450 тыс ₽ в год. Итого: около 790 тыс ₽ потерь за полугодие. Игорь эту цифру не считал - до нашего аудита.
Ошибка №5: Выгорание как следствие, а не причина. Разработчики уходили не из-за зарплаты. Они уходили потому, что тратили по 2-3 часа в день на Excel, письма и поиск информации вместо того, чтобы писать код. Один из тимлидов сказал нам на первом интервью: «Я пришёл программировать, а не быть секретарём».
Сводная картина до начала работы:
- 65% операционных задач - вручную
- Распределение спринта: 4 часа на итерацию
- Согласование релиза: 6-8 часов
- Срыв сроков: 15-18% в квартал
- Текучка разработчиков: 10,7% в год
Что мы предложили - наш стек
Автоматизация процессов мобильной разработки iOS Android - это не про то, чтобы купить дорогую платформу и переучить всех с нуля. Для студии на 28 человек такой путь чаще всего отнимет больше времени, чем сэкономит. Наш принцип: брать то, что уже есть, и соединять это с умом.
У Игоря уже стояла Jira - и это хорошо. Jira - стандарт для управления спринтами и багами в студиях мобильной разработки. Все задачи, статусы, спринты, доски - всё там. Умеет работать с iOS и Android-проектами, поддерживает Scrum и Kanban, есть готовые интеграции с GitLab, Bitbucket, Confluence. Подходит командам от 5 до 500 человек. Минусы: интерфейс перегружен для новичков, облачная версия стоит от 850 ₽/пользователя в месяц, а настройка под конкретный процесс требует времени. Но Jira уже была - мы просто начали использовать её правильно.
Для уведомлений и согласований выбрали Telegram Bot. Вся команда уже сидела в Telegram - это ключевой момент. Не нужно ставить новое приложение, не нужно объяснять, как им пользоваться. Бот умеет отправлять сообщения с кнопками, принимать решения («согласовать» / «отклонить»), проверять роли участников. Инструмент бесплатный, но требует разработки под конкретные задачи.
Связующим звеном стал Python-скрипт - внутренний чат-бот, который мы написали специально для этого клиента. Он слушает события из Jira (старт спринта, создание бага, смена статуса), обрабатывает их по правилам, которые мы прописали вместе с Игорем, и отправляет нужные сообщения нужным людям в Telegram. Никаких новых платформ, никаких ежемесячных подписок на сторонние сервисы - только логика, которую мы контролируем полностью.
Почему не Bitrix24 и не другие комплексные платформы? Команда уже работала в Jira и Telegram, а добавление ещё одной системы означало бы переучивание 28 человек и реальный риск саботажа внедрения. Мы выбирали минимум новых сущностей при максимуме автоматизации.
Как мы это внедряли (шаги по неделям)
Дни 1-3: Аудит и карта процессов. Провели интервью с Игорем, двумя тимлидами и тремя разработчиками. Зафиксировали все ручные операции, нарисовали схему: откуда берётся задача, кто её видит, где она теряется. Определили три приоритетных потока для автоматизации: распределение спринта, маршрутизация багов, согласование релиза.
Дни 4-7: Настройка Jira и первый поток. Привели Jira в порядок: почистили статусы, настроили поля «ответственный», «приоритет», «тип задачи». Настроили вебхуки - Jira начала отправлять сигналы нашему Python-скрипту при старте спринта. Написали первую версию логики распределения: скрипт смотрит на загрузку каждого разработчика и тестировщика и предлагает тимлиду готовый вариант через Telegram-бота. Тимлид одним нажатием кнопки подтверждает или корректирует.
Дни 8-12: Маршрутизация багов. Договорились с командой: все баги - только через бота. Тестировщик пишет в специальный Telegram-чат, бот автоматически создаёт задачу в Jira с нужными полями, назначает приоритет по шаблону и пингует ответственного разработчика. Разработчик видит задачу и в Jira, и в Telegram - дублирование исчезло. На этом этапе было сопротивление: несколько тестировщиков продолжали писать «по старинке». Провели короткую встречу, объяснили, почему это важно. Через три дня привычка сформировалась.
Дни 13-18: Согласование релизов. Написали цепочку: бот отправляет PM, тимлиду и клиентскому менеджеру сообщение с кнопками «Согласовать» / «Вернуть на доработку». Каждый нажимает кнопку в Telegram - бот фиксирует решение и переводит задачу в Jira в нужный статус. Если кто-то не ответил за 2 часа - бот напоминает. Письма по email остались только для финальных документов.
Дни 19-21: Тестирование и сдача. Прогнали один полный спринт на новой системе. Зафиксировали узкие места, подправили логику напоминаний. Записали короткие видеоинструкции для команды. Передали Игорю документацию и доступы к коду.
Что получили в цифрах
| Показатель | До | После |
|---|---|---|
| Доля автоматизированных операций | 35% | 82% |
| Время на распределение спринта | 4 часа | 25 минут |
| Среднее время согласования релиза | 6-8 часов | 1,5 часа |
| Срыв сроков в квартал | 15-18% | 4-5% |
| Текучка разработчиков (год) | 10,7% | 2,1% |
| Экономия времени разработчика | - | 12-14 часов/нед |
В деньгах: штрафы за задержки релизов сократились с 340 тыс ₽ до минимальных значений. Текучка перестала съедать 450 тыс ₽ в год на найм и онбординг. Суммарный условно-чистый результат за первый квартал после внедрения - +280 тыс ₽, и это консервативная оценка, без учёта роста скорости разработки.
Игорь сформулировал главное коротко: «Разработчики перестали жаловаться на операционный мусор. Они снова пишут код, а не ищут, кому передать задачу».
Что бы мы сделали иначе
Раньше занялись бы изменением привычек, а не только техникой. Мы недооценили инерцию команды. Первые четыре дня тестировщики продолжали кидать баги в личку разработчикам - просто потому что так привыкли. Техническая часть была готова, а культурная - нет. Теперь в каждом проекте мы закладываем отдельный день на «ритуал запуска»: короткое собрание, объяснение «зачем», ответы на вопросы. Это дешевле, чем потом переделывать логику под обходные пути.
Сделали бы мониторинг с первого дня, а не с третьей недели. Логи работы бота мы начали смотреть только после сдачи проекта. Выяснилось, что одно из правил распределения задач срабатывало некорректно для задач с типом «Research» - бот назначал их по загрузке, а не по компетенции. Заметили через две недели после запуска. Будь дашборд с первого дня - поймали бы за два.
Согласовали бы формат уведомлений с командой заранее. Первая версия бота отправляла уведомления слишком часто - разработчики начали их игнорировать. Пришлось перенастраивать частоту и формат сообщений уже в процессе. Теперь мы всегда проводим короткий воркшоп с командой до начала разработки: «Как вы хотите получать уведомления? Что важно видеть сразу, что - в дайджесте?»
Можем повторить у вас
Этот кейс - про автоматизацию процессов мобильной разработки iOS Android в студии на 20-50 человек. Но та же логика работает для любой команды разработки, где есть Jira (или похожий трекер), Telegram и ручные операции, которые повторяются каждые две недели.
Кому подойдёт: студии мобильной и веб-разработки, продуктовые команды, аутсорс-компании с регулярными спринтами и релизами. Оптимально - от 10 до 60 человек.
Что нужно от вас: доступ к Jira (или другому трекеру), понимание, кто принимает решения по релизам, и 2-3 часа времени тимлида на первой неделе для аудита процессов.
Срок внедрения: 14-21 день от старта до первого раб
Что делать прямо сейчас
Если вы дочитали до этого места и узнали в кейсе свою студию — вот с чего начать сегодня, не дожидаясь «правильного момента».
- Посчитайте свои 280 тысяч. Возьмите три самых частых ручных операции в вашем процессе — смену статусов, напоминания, распределение задач. Умножьте минуты на количество повторений в месяц и на среднюю стоимость часа разработчика. Цифра, скорее всего, вас удивит.
- Запишите один повторяющийся сценарий. Что вы или тимлид делаете руками каждые две недели перед релизом? Опишите в свободной форме — это уже половина технического задания на автоматизацию.
- Проверьте, есть ли у вас Jira + Telegram. Если да — большинство сценариев из этого кейса можно повторить без замены инфраструктуры.
- Покажите статью тимлиду или PM. Пусть скажут, что из этого уже болит у них. Обычно список получается длиннее, чем ожидаешь.
Когда зовут нас
FlowFrame занимается именно такими задачами — автоматизацией процессов в командах разработки, где есть трекер, мессенджер и усталость от ручной рутины. Если хочется разобраться, что реально автоматизировать в вашей студии и сколько это займёт — загляните на сайт и напишите нашему боту: он задаст пару вопросов и поможет договориться о коротком созвоне без лишних формальностей.