Ввели проектное управление в ИТ-отделе и превратили поток запросов в прибыль
проектная работа
Ввели проектное управление в ИТ-отделе и превратили поток запросов в прибыль
проектная работа
Ввели проектное управление в ИТ-отделе и превратили поток запросов в прибыль
Специфика бизнеса
Компания оказывает айти-услуги радиостанциям: подключает их к инфраструктуре онлайн-вещания, создает для них программные продукты.
Они обеспечивают работу радио в цифровой среде и монетизацию. Станции используют эти сервисы по подписке, то есть в постоянном использовании 24/7.
Основные продукты
«Радиостатистика»
Показывает, кто и когда слушает радио в онлайне, помогает принимать решения на основе данных.
Сервис музыкального тестирования
Позволяет определять музыкальные предпочтения аудитории и формировать программную политику
«Преролл-сервис»
Дает возможность вставлять рекламу в начало потока и монетизировать эфир
«Вебкарамба»
Профессиональный софт для воспроизведения радиоэфира
HLS-вещание
Стабильная технология потоковой передачи
Сервис метаданных
Передаёт слушателям информацию о звучащих треках, исполнителях, программах
Мобильные приложения
Приложения разной сложности: от простых плееров до интерактивных платформ
Это не все — в портфеле десятки рабочих сервисов.
Мы поддерживаем их бесперебойную работу, исправляем баги, обрабатываем входящие запросы от клиентов, обновляем и развиваем продукты. Параллельно готовим к запуску новые решения — как ответ на спрос рынка, так и инициативно.
Все разработки ведутся внутри компании. Есть команда программистов. Поэтому проектное управление — ключевая часть операционной модели.
Что было не так
Программных продуктов много, и каждый требует поддержки:
клиенты пишут о багах,
просят исправления,
предлагают улучшения.
После каждого обновления вылезают новые ошибки, накапливается технический долг. Почти каждый день — новые задачи, пожелания, уточнения.
В итоге поддержка сервисов стала занимать у программистов все рабочее время. Заниматься новыми продуктами — практически невозможно. Бизнес не закладывает фундамент для увеличения будущей выручки.
Крик души главного разработчика. Дорогостоящий специалист используется для затыкания дыр
Запросы от клиентов напрямую попадают к разработчикам, и те берут их в работу без фильтра и согласования. Из-за этого:
компания тратит ресурсы на доработки, за которые не получает оплату;
теряет прибыль, не монетизируя индивидуальные запросы.
Заявки от клиентов обрабатываются вразнобой, как успеваем. Из-за этого страдает репутация, клиенты ждут дольше, чем готовы, и у компании нет управляемого потока задач.
В итоге нет прогресса по ключевым продуктам, команда работает в перегрузе и по «неинтересным» задачам, создается риск увольнений.
Руководитель не видит общей картины загруженности разработчиков. Из-за этого не получается оценить реалистичные сроки по проектам. Нарушаются условия договоров по окончанию работ, страдает репутация и появляется риск влететь на пени.
Также они не могут взвешенно брать новые заказы. В итоге кормишь обещаниями потенциаольного заказчика «вот-вот вами займемся», а получение новой выручки откладывается.
Бизнес теряет деньги, рост тормозится, снижается лояльность команды.
Шаги для выхода из дыры
Было принято решение для отдела разработки внедрить проектный менеджмент.
Провели установочный звонок с командой
Собрали с каждого участника проблемы в управлении задачами. Убедились, что нужны изменения и тем самым команда морально приготовилась к новым решениям.
Формализовали принципы как строить рабочий день разработчику, чтобы было движение по собственным проектам и при этом обрабатывались запросы клиентов.
Разделили день на категории задач — теперь есть фокус и на развитие, и на поддержку
Решили взять девопс-инженера, специалиста который будет автоматизировать развертывание программ.
Ожидаемый эффект — разгрузка главного разработчика на 40%. Это время он потратит на развивающие проекты. Быстрее заработаем свои деньги.
Ввели бизнес-процесс для отсеивания запросов
Договорились, что пока по заявке клиента финслужба не даст добро «можно делать», что означает есть договор или счет оплачен, программисты ее в работу не берут.
То есть все теперь должно проходить через анализ финансиста.
Процесс назвали «Фильтр»
За первый месяц это отсеяло 20% задач. Столько же времени освободилось у разработчиков, они перестали захлебываться от бесконтрольно поступающих тикетов.
Сделали визуализацию на канбан-доске
Бизнес-процесс фильтрации задач получил визуальное отражение
Теперь вопросы отдела разработки собраны в одном месте, а не раскиданы по чатам с клиентами. Программисты не тратят время на их поиск. Они видят свою загрузку и более эффективно планируют недельный спринт.
Запросы уже отфильтрованы финслужбой и руководителем. В работе только то, что действительно нужно для развития сервисов и приносит дополнительный доход от внедрения фич.
Ввели однозначную приоритезацию
Руководитель размечает все задачи по принципу: срочно — средняя срочность — низкая срочность. Для этого ставит метки на карточки методом «светофор».
Разработчики быстро считывают объем критических вопросов и более рационально планируют свой рабочий день.
Кроме приоритетов, добавили дополнительные отметки для быстрой ориентации по объему и типу тикетов
Такая систематизация высвободила время для развития новых продуктов, а не только поддержки имеющихся.
Стали зарабатывать на фичах, которые раньше делали бесплатно
Финслужба видя запрос клиента, и если это не базовый функционал сервиса, предлагает ему сделать доработку за дополнительную оплату. 70% таких предложений отметается, а оставшаяся часть принимается, клиенты готовы платить.
Фирма получает дополнительную выручку от индивидуальных запросов пользователей.
Вытащили разработчиков из чатов и освободили им еще час в день
В чатах с клиентами оставили разработчиков номинально: они там присутствуют, но сообщения не читают и не отслеживают. Этим занимаются сотрудники техподдержки.
Инженеры поддержки видя запрос, сначала проводят его через бизнес-процесс «Фильтр». И если он там прошел, задача передается программистам. Они идут в чат и изучают только ту часть переписки, которая касается вопроса.
Им больше не надо перечитывать все сообщения и реагировать на все подряд. Это освободило команде разработки до часа рабочего времени ежедневно.
Перестали тратить время на «костыли» из-за лени клиентов
В ходе изучения и систематизации задач, которые сыпались на программистов, выяснилось, что иногда приходят запросы типа «У нас устроено так-то, ваш сервис тут выдает ошибку. Сделайте что-нибудь». То есть данные клиента изначально введены не по стандарту, а особенным, заковыристым способом.
Пример:
В одном медиахолдинге, который использует наш сервис метаданных, и джинглы, и реклама были размечены в системе как один и тот же тип элемента «джингл». В итоге отчет по рекламе работал некорректно.
Они хотели, чтобы мы написали к этому «костыль» для обхода своей же ошибки в разметке. Разработчики придумали как это сделать. И если бы не бизнес-процесс фильтрации задач, взяли бы в работу. Бизнес бы оплатил чужую нелепую хотелку.
Изменения по проектному управлению еще внедряются. Продолжение следует…
Хотите, чтобы команда не захлебывалась в заявках, а двигалась по четкому плану?
Помогу выстроить проектное управление под ваши процессы — без сложных схем, и чтобы работало в вашей реальности.