В марте 2026 года ПАО КБ «Центр-инвест» опубликовал результаты перехода на единую систему управления IT-задачами: delivery ускорилось на 20%, коммуникация с подрядчиками — на 25% быстрее. Казалось бы, просто сменили трекер. На деле — перестроили весь процесс передачи задач между подразделениями.
Рынок кэптивных IT-подразделений крупных российских корпораций достиг 1,96 трлн рублей — рост на 21% за год. Внутренние IT-команды превратились в полноценных провайдеров сервисов: у них свои процессы, свои метрики, своя терминология. И чем профессиональнее становится внутренний IT, тем острее проблема стыка с бизнесом.
Вот типичная картина. Продуктовый менеджер фиксирует запрос в Notion: «Запустить новую фичу к релизу 15-го». Разработка ведёт бэклог в Jira. Маркетинг отслеживает свои активности в таблице. Задача проходит через три системы, два согласования, четыре переписки в Telegram — и всё равно опаздывает на спринт. Каждый отдел может показать скриншот: «Мы свою часть сделали». Но фича не запущена.
Задача перебрасывается между отделами, теряя контекст при каждой передаче, пока не зависнет где-то на стыке. Это и есть «футбол».
В этой статье разберём, почему разрозненные трекеры создают лишь иллюзию управления, как выстроить модель единого бэклога и какие конкретные настройки — статусы, роли, SLA, отчётность — превращают хаотичные передачи в управляемый сквозной процесс.
Почему задачи «летают» между отделами и никто не виноват
«Футбол» задач — не проблема людей. Это следствие архитектуры: когда каждый отдел живёт в своём трекере, задача теряет контекст при каждой передаче. Разработчики не виноваты, что не понимают бизнес-логику. Продукт не виноват, что не знает о технических ограничениях. Потери заложены в саму структуру.
Три системы — три правды
Бизнес формулирует запрос на своём языке: выручка, конверсия, срок запуска. IT переводит его в технические термины: эпик, стори, баг, технический долг. При обратной передаче результат не совпадает с ожиданиями — не потому что разработчики сделали не то, а потому что по дороге потерялся контекст «зачем».
Задача одна, а точек входа — много. Продуктовый менеджер заводит её в одном месте, тимлид дублирует в другом, дизайнер получает описание третьим способом. Каждая точка входа добавляет свой контекст и отсекает чужой. К моменту исполнения исходный смысл уже размыт.
Ownership размывается на стыке
В классической модели «передачи по цепочке» нет единого владельца результата. Бизнес считает, что задача «у IT». IT считает, что ждёт уточнений от бизнеса. Ни одна из сторон не видит полную картину.
Аналитики MWS фиксируют: компании переходят от наращивания набора инструментов к консолидации — именно потому, что «заплатки» не решают проблему стыков. Можно купить ещё один трекер, ещё один мессенджер, ещё одну BI-систему. Но пока граница между «задача у бизнеса» и «задача у IT» остаётся размытой, любой новый инструмент воспроизводит старую проблему в новом интерфейсе.
Единый бэклог ≠ «одна Jira на всех»
Единый бэклог — это единая иерархия: бизнес-идея → продуктовая инициатива → техническая задача, связанные в одном пространстве с прозрачными статусами.
Разница принципиальная. «Все работают в одном трекере» — попытка усадить маркетолога, разработчика и финансового директора за одну доску. Чаще всего проваливается: у бизнеса и IT разные рабочие ритмы, разные горизонты планирования, разная степень детализации. Разработчику нужен спринт с подзадачами на 2 часа. Директору по продукту — квартальная дорожная карта.
Единая система задач работает иначе. Каждый отдел работает в привычном формате (доска, список, матрица), но задачи связаны иерархически:
Уровень бизнеса — стратегические инициативы, привязанные к целям компании (OKR/KPI). «Увеличить конверсию в покупку на 15% к Q3».
Уровень продукта — эпики и фичи, декомпозированные из бизнес-инициатив. «Переработать страницу оформления заказа», «Добавить быструю авторизацию».
Уровень исполнения — конкретные задачи и подзадачи в спринтах команд. «Вёрстка нового флоу», «API для авторизации через Госуслуги», «A/B-тест кнопки».
Уровень инфраструктуры — задачи, которые не привязаны к конкретной фиче, но блокируют несколько инициатив: технический долг, обновление зависимостей, миграция данных.
Связь между уровнями должна быть технической — подзадачи, ссылки, иерархия в системе. Не «договорной» — устные обещания и пересылка скриншотов в чатах. Подробнее о том, как правильно строить эту иерархию, мы разбирали в материале о декомпозиции задач.
Парадокс: чем больше инструментов «для удобства каждого отдела», тем меньше управляемость. Компании, которые дают каждому отделу «свой любимый трекер» и пытаются связать их интеграциями, тратят на поддержку этих интеграций больше, чем сэкономили на «удобстве». Спрос на платформенные IT-решения в России вырос на 22% — рынок голосует за консолидацию.
Реальный кейс: как банк перевёл 100% IT-задач в единую систему и ускорил delivery на 20%
ПАО КБ «Центр-инвест» столкнулся с типичной ситуацией: задачи велись в нескольких трекерах, взаимодействие с внешними подрядчиками шло через отдельные каналы, а параллельно стояла задача импортозамещения.
Банк перешёл на единую систему управления IT-задачами на базе Redmine. Результат по данным GlobalCIO: 100% IT-задач ведутся по единым стандартам, delivery новой функциональности ускорилось на 20%, а совместная работа с внешними подрядчиками в единой системе сэкономила около 25% времени на коммуникацию.
Ключевым фактором стало не само ПО. Решение перевести все задачи в одну систему — без исключений и «параллельных» трекеров для отдельных команд — вот что дало результат. Пока хоть одна команда ведёт задачи «в стороне», единой картины нет.
Похожий паттерн описан в кейсе SimpleOne: компания объединила в ESM-платформе 9 отделов — IT, HR, АХО, бухгалтерию и другие. Операционная эффективность выросла на 33%, внедрение окупилось за 7 месяцев. 90% запросов стало поступать через единую систему вместо разрозненных каналов.
Оба кейса подтверждают одно: цифры появляются не от выбора «правильного» инструмента, а от решения сделать систему единой точкой входа для всех задач.
Как настроить общие статусы и SLA, чтобы задача не зависала на стыке
Общие статусы и SLA между отделами — механизм, который делает «зависание» задачи видимым и измеримым. Без них задача может неделями висеть на стыке, и формально никто не нарушает сроки.
Статусы как общий язык
Статусы должны быть понятны и бизнесу, и IT. «In Code Review» — понятно только разработчикам. «На проверке у команды разработки» или «Ожидает приёмки бизнесом» — понятно всем участникам.
Пример набора статусов для кросс-функциональной доски: «Идея» (запрос от бизнеса, ещё не оценённый) → «Оценка бизнесом» (продукт уточняет приоритет и критерии) → «В работе у продукта» (формируется техническое задание) → «В разработке» (IT выполняет задачу) → «На тестировании» (проверка качества) → «Приёмка бизнесом» (владелец инициативы подтверждает результат) → «Готово» (задача закрыта с подтверждённым результатом).
Семь статусов — не догма. У вас может быть пять или девять. Главное — каждый статус отвечает на вопрос «кто сейчас держит мяч?».
SLA на стыках — где задача чаще всего «умирает»
SLA нужен не на весь цикл задачи, а именно на переходы между отделами: сколько часов допустимо на «Оценку бизнесом», сколько — на «Приёмку». Без SLA на стыках разработчики сделали всё в срок, бизнес ещё не посмотрел, задача висит. Неделю. Две.
ESM-подход (Enterprise Service Management) формализует именно эти «сервисные отношения» между подразделениями: кто поставщик услуги, кто потребитель, каков SLA на каждом переходе.
В Shtab подзадачи могут находиться в проектах разных команд, оставаясь связанными с основной задачей через счётчик подзадач. Каждая команда работает в своём пространстве без лишнего контекста — при этом бизнес видит статус инициативы целиком, а IT работает с конкретными техническими задачами. Разработчикам не нужно погружаться в маркетинговую стратегию, а владельцу инициативы — в детали реализации.
О том, как настроить визуальное отображение задач под разные роли, подробно написано в материале о визуальном менеджменте.
Доски и роли: кто за что отвечает в кросс-функциональной системе
Единая система работает, когда у каждого участника есть чёткая роль, а структура досок отражает реальные потоки работы, а не организационную схему компании.
Доски по потокам ценности, а не по отделам
Доска «Отдел разработки» — вид изнутри отдела. Доска «Запуск фичи X» — сквозной поток, где видны задачи всех участников. Для кросс-функциональной работы нужны оба типа. Но управление инициативой происходит на сквозной доске. Если смотреть только на отдельские доски, никогда не увидишь, где задача застряла на стыке.
Роли, которые убирают «футбол»
Владелец инициативы (бизнес) отвечает за «зачем» и приоритет. Определяет, что должно быть сделано и почему это важно. Подтверждает результат на финальном этапе.
Продуктовый координатор переводит бизнес-запрос в задачи и следит за целостностью. Говорит на двух языках: понимает бизнес-цель и может сформулировать техническое задание.
Исполнитель (IT или другой отдел) отвечает за «как» и сроки. Работает с конкретными задачами в своём пространстве.
Приёмщик (бизнес или QA) подтверждает, что результат соответствует запросу. Именно здесь «футбол» возникает чаще всего. Вот как это выглядит на практике: разработчики закрывают тикет «Переработать страницу оформления заказа». Формально задача сделана. Через неделю продуктовый менеджер открывает страницу и видит, что форма оплаты переехала вниз, а кнопка «Купить» стала менее заметной. Конверсия падает. Начинается новый цикл: уточнение требований, правки, повторное тестирование. Две недели потеряны — потому что никто не был явно назначен приёмщиком, который проверит результат до закрытия тикета.
В Shtab можно настроить разные виды отображения в рамках одного проекта: владелец инициативы смотрит на матрицу приоритетов, исполнитель — на канбан-доску спринта, координатор — на список с пользовательскими полями. Автоматизация процессов позволяет настроить смену статуса или уведомление при переходе задачи между ролями — без ручного «пинга» в чате и без риска, что переход потеряется в потоке сообщений.
При расстановке приоритетов на уровне бизнес-инициатив удобно использовать методику Value vs Effort — она помогает владельцу инициативы принимать решения на основе соотношения ценности и затрат, а не интуиции.
Отчётность по кросс-функциональным инициативам: что показывать руководству
Отчётность по сквозным инициативам должна отвечать на один вопрос: «Где сейчас находится бизнес-результат?» — а не «сколько задач закрыто в каждом отделе».
IT закрыло 47 задач за спринт. Маркетинг выполнил 12 активностей. Но фича не запущена — потому что никто не отслеживал сквозной прогресс. Каждый отдел рапортует об успехе, а результата нет. «Количество закрытых задач» — ложная метрика, потому что она измеряет активность, а не продвижение к цели. Команда может закрывать десятки тикетов и при этом стоять на месте, если задачи не складываются в готовый результат.
Отчётность, которая реально работает, строится на нескольких уровнях.
Для C-level — процент завершения бизнес-инициатив, отклонение от плановых сроков, блокеры на стыках отделов. Ключевая метрика — cycle time от идеи до релиза: сколько дней проходит от момента, когда бизнес сформулировал запрос, до момента, когда результат доступен пользователю. Если cycle time растёт при стабильной скорости команд — проблема именно на стыках.
Для руководителей направлений — загрузка команды, SLA-нарушения на переходах, очередь задач «на входе». Здесь важно видеть, где скапливается очередь и где команда перегружена. Отдельно стоит отслеживать «время в ожидании» — долю жизненного цикла задачи, которую она проводит в статусах типа «Ожидает приёмки» или «На согласовании».
Для исполнителей — личный бэклог, дедлайны, зависимости от других команд. Минимум контекста, максимум конкретики.
Отчётность работает только если данные живут в одной системе. Когда часть задач в трекере, часть в таблице, а часть в переписке — любой дашборд показывает неполную картину. Связку «стратегия → задачи → отчёты» как систему управления мы подробно разбирали в материале о принципах управления проектами.
Неочевидный вывод: «футбол» полезен — если он управляемый
Полное устранение передач между отделами — утопия. И даже вредная цель. Разработчик не должен думать о маркетинговой стратегии. Маркетолог — о техническом долге. Специализация отделов — преимущество, а не баг. Передача задач между специалистами — нормальная часть рабочего процесса.
Проблема не в «футболе» как таковом, а в его патологиях.
Передача без контекста: задача приходит «голой», без информации о том, зачем она нужна и что считается результатом. Получатель либо угадывает, либо возвращает на уточнение — и цикл удлиняется вдвое.
Передача без владельца: каждый отвечает за свой кусок, но за конечный результат — никто. Задача «сделана» в каждом отделе по отдельности, но не собрана в целое.
Передача без SLA: задача может висеть на стыке бесконечно. Формально она «в работе». Фактически — в очереди, о которой никто не знает.
Передача без обратной связи: исполнитель не узнаёт, подошёл ли результат. Ошибки накапливаются от итерации к итерации.
Если эти патологии устранены — передачи превращаются в конвейер. А конвейер масштабируется. Именно поэтому опытные руководители проектов говорят не «мы убрали передачи между отделами», а «мы сделали каждую передачу видимой».
Task management-системы помогают назначать ответственных, сроки и контролировать исполнение — но не исправляют организационную размытость. Сначала нужно договориться о ролях и SLA, и только потом переносить договорённости в систему.
Пошаговый план: как перейти к единой системе задач за 8 недель
Переход к единой системе — не «большой взрыв». Попытка сразу перевести всю компанию в новую систему почти гарантированно провалится: слишком много изменений одновременно, слишком много сопротивления. Начинайте с одного кросс-функционального потока.
Неделя 1–2: аудит потоков. Выберите одну кросс-функциональную инициативу — например, запуск фичи или выход на новый рынок. Зафиксируйте, через какие системы и людей проходит задача сейчас. Посчитайте количество передач, среднее время «зависания» на стыках и количество возвратов на доработку. Это ваша базовая метрика, с которой будете сравнивать результат.
Неделя 3: проектирование единого потока. Определите статусы, роли (владелец, координатор, исполнитель, приёмщик), SLA на переходах. Не пытайтесь охватить все процессы — только выбранный поток. Документ на одну страницу лучше, чем регламент на сорок.
Неделя 4–5: настройка системы. Создайте проект с иерархией задач: бизнес-инициатива → продуктовые задачи → технические подзадачи. Настройте виды отображения под каждую роль. Проверьте, что автоматизации срабатывают на нужных переходах. Отдельно убедитесь, что у каждой задачи на стыке есть явный приёмщик — именно этот момент чаще всего забывают при настройке.
Неделя 6–7: пилот. Проведите один полный цикл инициативы в новой системе. Соберите обратную связь от всех участников — конкретно: где статус был непонятен? Где SLA оказался нереалистичным? Где участник не понимал, что задача ждёт именно его? Какие уведомления были лишними, а каких не хватило? Зафиксируйте каждый момент, где процесс «скрипел». Это не провал — это самые ценные данные.
Неделя 8: ретроспектива и масштабирование. Скорректируйте статусы и SLA по результатам пилота. Сравните метрики «до» и «после»: cycle time, количество возвратов, время в ожидании. Подключите следующий кросс-функциональный поток. Если инициатива включает внедрение AI-агентов, логика может отличаться — мы разбирали отдельный фреймворк в материале «12 недель до ROI».
Первый цикл будет неидеальным. Кто-то забудет обновить статус. Роли придётся уточнить. О том, как выстраивать итеративный подход к запуску процессов, подробно написано в материале «От проекта к продукту».
Инструмент следует за решением, а не наоборот
Рынок кэптивных IT-подразделений растёт на 21% в год. Спрос на платформенные решения — на 22%. Компании, которые не выстроят сквозные процессы между бизнесом и IT, будут терять скорость при каждом росте масштаба: больше команд — больше стыков, больше стыков — больше потерь контекста.
Единая система задач — это решение сделать передачу задач прозрачной, измеримой и управляемой. Контекст при передаче, явный владелец результата, SLA на стыках, обратная связь от приёмщика к исполнителю. Выбор конкретного инструмента — следствие этого решения. Кейс «Центр-инвеста» на Redmine и кейс SimpleOne на ESM-платформе показывают одно: работает не бренд трекера, а принцип «единая точка входа для всех задач, без исключений».
FAQ
Что такое единая система управления задачами?
Платформа, в которой задачи всех подразделений связаны иерархически: от стратегических целей бизнеса до конкретных технических подзадач. От «общего трекера» её отличает наличие сквозных статусов, ролей и отчётности. Например, в кейсе «Центр-инвеста» именно перевод 100% задач в одну систему — без параллельных трекеров — дал ускорение delivery на 20%. Пока хоть один отдел ведёт задачи «в стороне», сквозная картина не складывается.
Как улучшить взаимодействие между отделами?
Начать с формализации стыков: определить, кто передаёт задачу, кто принимает, в каком формате и за какое время. Критически важно назначить приёмщика — человека, который подтверждает, что результат соответствует запросу. В кейсе SimpleOne объединение 9 отделов через ESM-платформу с едиными SLA дало рост операционной эффективности на 33%. Затем перенести эти правила в систему управления задачами — с общими статусами и SLA на переходах.
Какое приложение лучше всего подходит для управления задачами в кросс-функциональной команде?
Для кросс-функциональных команд критичны четыре вещи: иерархия задач (подзадачи в разных проектах), гибкие виды отображения (канбан, список, матрица), автоматизация переходов между статусами и отчётность по сквозным инициативам. Shtab закрывает эти потребности в одной платформе: подзадачи в проектах разных команд, настраиваемые виды под каждую роль, автоматизация смены статусов. Ключевой критерий выбора — возможность работать в единой системе без необходимости «склеивать» несколько инструментов интеграциями, которые сами становятся источником проблем.