Меня зовут Валентина Оболенцева. Я уже 16 лет в IT, 11 из которых – в области бизнес-анализа и управления. Начинала как специалист технической поддержки – сначала первой линии, потом второй, затем перешла в системный анализ. После этого работала продакт-менеджером, проджект-менеджером, а позже стала руководителем отдела бизнес-анализа. В этой роли я отвечала за методологию, качество работы аналитиков, их развитие и корректное оформление требований.
Сейчас я руковожу управлением развития торговых процессов и регламентированного учета в компании «Росклимат». Это подразделение в IT-департаменте, включающее три отдела, которые занимаются развитием систем. Первый отдел развивает ERP, торговлю и розницу. Второй – CRM-систему, систему лояльности и инструменты ценообразования. Третий – системы регламентированного учета: ЗУП, бухгалтерию и управление персоналом. Все эти системы, кроме HR-блоков (подбор персонала и ЭДО), построены на платформе 1С.
За свою карьеру реализовала множество проектов в разных сферах: внедряла торговые и производственные ERP-системы, разрабатывала мобильные приложения, участвовала в создании банковских продуктов для малого и среднего бизнеса. В какой-то момент мне пришлось одновременно управлять пятью командами с совершенно разными направлениями. То, что помогло мне выжить и двигаться дальше, – системный подход. Он позволяет масштабировать свою работу, независимо от специфики команд.
Также я занимаюсь менторством аналитиков: если вам нужно обсудить карьерный путь или прокачать резюме – пишите.
А теперь перейдем к сути: к проблеме. Ведь без проблемы не бывает решений.
Главная проблема: давление заказчиков и постоянные запросы
Кому из вас хотя бы раз в неделю заказчики не пишут и не спрашивают: «Когда вы сделаете мою задачу?» Тем, кому не пишут, советую проверить – возможно, ваши заказчики уже уволились. Потому что иначе это выглядит странно. Давайте сразу уточним терминологию. Я буду использовать термин ЛПР – лицо, принимающее решение, или топ-менеджер. В крупных холдингах, где я в основном и работала, обычно есть несколько ключевых направлений. Каждое из них отвечает за свою бизнес-единицу или юридическое лицо и распоряжается бюджетом. Именно эти люди – ЛПР, топ-менеджеры – и есть мои основные заказчики. А под «заказчиками» в более узком смысле я имею в виду ключевых пользователей – специалистов, которых они выделяют для взаимодействия с IT. Как правило, это эксперты по конкретным направлениям: логистике, маркетингу и другим бизнес-процессам.
И вот в чем суть проблемы: заказчики постоянно пишут, требуют внимания, и на каждый запрос нужно отвечать. Чтобы ответить – нужно оценить трудозатраты, рассчитать сроки, а это отнимает огромное количество времени. Только успеешь ответить – они регистрируют новую фичу, и весь цикл начинается сначала. Если же не отвечать – начинается имиджевая проблема: «Вы не ответили вовремя», «Вы нас не слышите». В итоге запрос все равно доходит до руководства, приходится включаться – но уже с негативным фоном.
Попытки решения: сервис-деск, встречи и Excel
Мы, конечно, старались идти навстречу бизнесу: хотели показать прозрачность нашей работы, объяснить, сколько у нас запросов и чем мы заняты. Но мы не сразу решили создавать новый инструмент – сначала попробовали решить проблему тем, что уже было.
Например, мы направляли заказчиков в сервис-деск: «Регистрируйте задачи здесь, вот как это работает, смотрите – у вас много запросов, все в порядке, есть очередь». Но это оказалось неудобно: интерфейс сервис-деска не очень дружелюбен, заказчикам было лень разбираться, да и в целом процесс воспринимался как лишняя бюрократия.
Еще мы информировали команды на регулярных встречах – например, при планировании спринтов. Говорили: «Вот эти задачи мы берем, а вот эти – нет». В принципе, это помогало – но только на время встречи. Уже через пару часов после нее заказчик приходил с новой идеей: «А можно еще вот это?» – и цикл повторялся.
Кроме того, топ-менеджмент тоже хотел видеть полную картину по своим задачам. Раньше мы выгружали данные в Excel и укрупняли их – ведь топам неинтересно копаться в деталях. Их интересовало только два вопроса: «Сколько это будет стоить?» и «Когда будет готово?» Остальное – не важно.
В какой-то момент мы поняли: дальше так работать нельзя. Нужно что-то менять. Тогда мой руководитель Александр Шепелев сказал: «Хватит это терпеть. Сделаем табло, как в Сбербанке: каждый берет номерок – и знает, когда до него дойдет очередь».
Создание инструмента «Табло»
Мы разработали инструмент, который назвали «Табло». Сейчас я расскажу, что у нас получилось, как это можно повторить, а в конце – сколько времени все это может сэкономить. Давайте сначала посмотрим, как это выглядит визуально.
У инструмента есть еще верхняя часть, но я оставлю ее напоследок – чтобы вы обязательно дочитали статью до конца.
По сути, это табличка с колонками и цветовой индикацией. На самом деле, у нас получилось не одно, а два табло.
Дело в том, что у нас три ключевые роли: топ-менеджеры, тимлиды и ключевые пользователи. Тимлид мыслит масштабом своей команды: его интересует, что приходит в команду и какие задачи приоритетны именно для нее. Ключевой пользователь, как правило, мыслит так же – он ближе к операционной работе, знает, какая команда будет выполнять задачу, и часто не вникает в детали вроде того, какой конкретно аналитик или программист будет этим заниматься.
Топ-менеджерам такая детализация не нужна. Их интересует общая картина – что происходит по всем направлениям, без погружения в детали. Поэтому, хотя изначально оба табло выглядели одинаково, для топов мы решили сделать укрупненную версию.
Основная логика заложена в табло для команд – именно о нем я сейчас и расскажу. Табло для топов – это консолидированная сводка по всем командам. Можете посмотреть, какие возможности есть у каждой роли. Кстати, даже руководству IT этот инструмент оказался полезен.
Три кита системы: приоритеты, трудозатраты и сроки
Любая система управления задачами строится на трех основных элементах: сроки, приоритеты и трудозатраты.
Можно было бы начать со сроков – они, конечно, всех волнуют. Но я начну с приоритетов, потому что именно они лежат в основе планирования сроков.
Существует множество моделей оценки приоритетов. Мы рассматривали, например, скоринговые модели: с параметрами, весами, баллами – и итоговым сквозным приоритетом.
Но хочу обратить внимание: все компании разные. Очень важно, внедряя подобные инструменты у себя, учитывать текущую зрелость вашей организации. Можно принести самую продвинутую методологию – но если она не вяжется с реальной жизнью команды, она просто не заработает.
Мы это учли. У нас есть определенная внутренняя политика: мы – внутренний IT-подрядчик для холдинга. Поэтому приняли решение: если у нас, например, шесть топов, мы выполняем задачи для каждого из них по очереди. Пусть у одного топа будет 10 задач по 100 миллионов, а у другого – 10 по 100 тысяч. Мы все равно соблюдаем принцип равного доступа.
Если бы мы были внешним IT, ориентировались бы, скорее всего, на платежеспособность заказчика. Но у нас другая модель. Поэтому мы ввели три ключевых параметра приоритизации:
-
Очередность (по топам),
-
Финансовый эффект – сколько денег принесет реализация фичи,
-
Учет мнения ключевых пользователей – чтобы и они могли влиять на приоритеты.
Как работает приоритизация и цветовая индикация
Давайте посмотрим, как это устроено на практике. Результатом расчета становится первый столбец – сквозной приоритет. На его формирование влияет параметр приоритет ЛПР – числовое поле от 1 до 999.
Сейчас немного углублюсь в технические детали
Почему именно такой диапазон? Чтобы было удобно распределять задачи по «пулам» – группам приоритетов.
Например:
-
от 1 до 10 – критический приоритет,
-
от 11 до 200 – высокий,
-
далее – средний и низкий.
Мы рассматривали вариант с непрерывной нумерацией, но тогда потребовался бы механизм пересчета приоритетов при каждом изменении. А при таком подходе тимлид может просто вставлять задачи в нужный пул и уже внутри него проводить финальную приоритизацию. Это упрощает обсуждение и гибкое управление.
Также здесь используется цветовая индикация – о ней расскажу чуть позже.
Обратите внимание: некоторые задачи все равно остаются вверху списка.
Это связано с дополнительными правилами – например, у нас есть особые статусы в конце процесса, которые могут приостанавливать переприоритизацию. У вас такие статусы могут быть свои.
Если задача уже взята в работу, ее не нужно переприоритизировать – она исключается из общего процесса.
Теперь перейдем к трудозатратам. Ведь чтобы спрогнозировать сроки, нужно понимать, сколько времени займет выполнение задачи.
Чтобы сэкономить время, мы просто используем статистику выполненных задач.
Прогнозирование сроков и учет производственного календаря
Мы знаем, сколько в среднем времени команда тратит на задачу. Например, за прошедший период средняя трудоемкость составила 80 часов. В моем примере – 56 часов.
Как только заказчик регистрирует новую фичу, система автоматически проставляет трудозатраты на основе этой статистики. И уже от этого значения рассчитывается прогнозируемый срок выполнения.
Здесь появляется и цветовая логика: курсивом отображается прогнозная дата – чтобы было понятно, что это не финальное обещание, а оценка. Вы можете оформить это по-своему – так, как удобно вашим заказчикам. Мы выбрали именно такой вариант – и коллегам он понравился.
И, собственно, ради чего все затевалось – прогноз сроков.
Мы уже определили приоритеты и трудозатраты. Но нельзя забывать про реальный календарь: праздники, выходные, отпуска. Не стоит обещать сдачу задачи 5 января, если в этот день никто не работает. Поэтому обязательно используйте производственный календарь.
Еще один ключевой фактор – мощность команды. Если у вас один аналитик, один разработчик и один тестировщик – это один темп. Если разработчиков двое – темп другой. Если трое – еще быстрее.
Мы долго думали, как учесть этот параметр. Я хотела внедрить сложную модель: учитывать отпуска, технический долг, распределение ролей, разбивать по часам. Но в ходе обсуждений стало ясно – такую систему будет слишком тяжело поддерживать.
Тогда мы пришли к идее «потока». Вы можете определить свой поток как угодно: 1 аналитик + 1 разработчик – это базовая цепочка, или 1 + 2, или 2 + 2 – в зависимости от вашей команды.
Именно на основе потока и статистики формируются прогнозы сроков. Прогнозные даты отображаются на табло курсивом – чтобы всегда была понятна их условность.
Цветовая индикация изменений и работа с топ-менеджерами
Если изменились сроки или трудозатраты – система сразу дает сигнал.
Изменения подсвечиваются, подчеркиваются, выделяются цветом. Мы активно используем цветовую дифференциацию, чтобы заказчикам было проще воспринимать информацию и быстрее замечать ключевые изменения.
Немного раскрою секрет – особенно для тех, кто работает с топ-менеджерами.
Я специально оставила верхнюю часть табло напоследок. Собственно, эту часть в будущем мы даже можем выделить в отдельный дашборд.
Дело в том, что топам неинтересно листать список задач и вникать в детали.
Их интересует только общая картина – и, конечно, деньги. Чтобы эффективно с ними коммуницировать, мы ввели три ключевых финансовых показателя:
-
плановая стоимость,
-
фактическая стоимость,
-
фактическая себестоимость.
Мы задаем условную рыночную ставку – например, 1000 или 2000 рублей в час. Эту ставку умножаем на трудозатраты: сначала на плановые, потом на фактические. Так получаем стоимость задачи в рублях – по плану и по факту.
Третий столбец – реальная себестоимость, которая зависит от грейдов сотрудников. Например, задачу может выполнять джун – дольше, но дешевле.
При этом даже при превышении трудозатрат можно уложиться в общий бюджет.
И это будет видно в отчетности, что особенно ценно при общении с топами: они видят план-факт по затратам – просто, наглядно, по делу.
Есть еще один важный столбец – сумма эффекта. Здесь два уровня:
-
заявленный эффект – то, что указал инициатор,
-
подтвержденный эффект – тот, за который кто-то «взял ответственность», буквально «зуб дал». Это уже более надежная часть данных.
Также в верхней части – общие метрики. Например, с учетом текущего бэклога мы видим, что команда загружена до 25 ноября 2025 года. Это не нужно листать и высчитывать вручную – система автоматически берет последнюю задачу из прогноза и выводит дату. И мы можем четко сказать: «Если вы дадите новую задачу раньше 25 ноября – мы ничего не сдвинем. Ничего не сделать раньше. Либо необходимо пересматривать приоритеты уже запущенных задач и в итоге ничего не будет сделано, либо привлекать дополнительный бюджет (все выделенное крайне нежелательно, хотя мы все понимаем, что в бизнесе бывают срочности и форс мажоры, и с этим тоже нужно считаться)».
В итоге мы получили:
-
экономию времени тимлидов,
-
прозрачность загрузки команд,
-
понятные контрольные точки.
А вот эта табличка – вы можете посмотреть ее и адаптировать под себя.
Результат: экономия 33% времени и прозрачность процессов
Я реально посчитала, сколько времени мы сэкономили – и на чем именно: что мы перестали делать? Что стали делать реже? Что автоматизировали? Получилась внушительная цифра – 33% времени.
Да, треть рабочего времени теперь можно перераспределить. Вы можете освободить тимлидов от рутинных операций и направить их на:
-
стратегические задачи,
-
развитие команд,
-
или, если уж очень хочется, – на еще больше операционки.
Конечно, звучит как сказка: внедрили – и все пошло как по маслу. Но, поверьте, все не так просто.
Какие есть нюансы? Во-первых, возможно, у вас пока еще не зрелая среда – и инструмент будет избыточен. Во-вторых, перед запуском нужна предварительная работа:
-
согласование метрик,
-
настройка процессов,
-
вовлечение команд и топов.
Но шаг за шагом – это реализуемо.
Практические советы: логирование и упрощение
Первый важный совет – все нужно логировать. У вас должен быть единый источник данных, где фиксируются:
-
трудозатраты,
-
сроки,
-
все ключевые параметры.
Мы, например, взяли данные из Service Desk – вся информация у нас оттуда.
Но перед этим пришлось провести предварительную работу: детализировать поля, привести данные к единому формату.
Раньше мы указывали трудозатраты в виде приблизительных оценок – «большой», «средний», «маленький». Теперь они стали точными и измеримыми, и мы их системно логируем.
Второй совет – не бойтесь упрощать. Мы, как люди, склонные к системности, часто хотим сделать все максимально точно, красиво и идеально – чтобы никто не придрался. Но на первом этапе это мешает. Чтобы быстрее запустить инструмент и получить обратную связь, что-то придется упростить. Главное – запуститься. Детали можно дорабатывать потом.
Конечно, не все тимлиды сразу приняли новую систему с распростертыми объятиями. И заказчики тоже не сразу поверили в новинку. Раньше они спрашивали: «Мы ходили в Service Desk, но ничего не поняли. Расскажите, что там происходит». Теперь мы просто показываем им табло – и все становится понятно.
Итоги и рекомендации: MVP, обратная связь и постепенное улучшение
Повторю ключевые моменты:
-
Начинайте с логирования и статистики – чем раньше, тем лучше.
-
Находите амбассадоров – как в IT, так и в бизнесе.
В IT мы выбрали тимлидов, которые не просто используют инструмент, а полностью перешли на новую модель работы. Такие люди – катализаторы изменений. Ими не обязаны быть все, но должны быть хотя бы несколько.
В бизнесе мы тоже нашли своего амбассадора – и это был топ-менеджер. Он изначально был одним из заказчиков, даже – одним из идеологов инструмента. Мы показали ему результат, и он искренне оценил пользу.
Дело не в том, что мы что-то сделали и говорим: «Смотрите, какая у нас классная штука!» Важно, что реальные люди ее используют, с которыми можно обсудить процесс, что им все понятно, и что это действительно упрощает их работу.
И еще раз подчеркну: это был запуск MVP – минимально жизнеспособной версии. Затем – сбор обратной связи и поэтапное улучшение. И, честно говоря, результат получился быстрее, чем мы ожидали.
Поэтому мой совет: не пытайтесь сделать все идеально с первого раза. Не закапывайтесь в деталях. Сделайте рабочий вариант, запустите его, соберите фидбэк – и уже потом развивайте, масштабируйте, улучшайте.
Мы сами продолжаем работать над этим инструментом. Впереди – новые фичи, новые кейсы.
В заключение хочу отметить, что помимо инструмента и обоснованных расчетов для заказчиков всегда важно внимание и чувство, что их слышат. Не забывайте и об этом – к тому же теперь, когда у вас освободилось время!
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.
