Привет, Хабр! Меня зовут Дима, я руковожу отделом в Петрович-Тех. Мы делаем ИТ для строительного ритейла, моя команда занимается поддержкой. В статье хочу рассказать о том, как мы наводили порядок в работе с бэклогом для внутреннего продукта – что делать, когда постоянно много задач, приоритеты меняются, стейкхолдеры недовольны.
Когда речь заходит о продуктах внешних, для такого контекста есть немало полезных подходов и практик: всевозможные Scrum/Kanban, спринты, скоринг и приоритизация бэклога, кросс-функциональные команды из людей с T-shaped навыками и продуктовым образом мышления.
Под внутренними продуктами в контексте этой статьи я имею в виду продукты для внутренних пользователей. Это могут быть готовые решения или собственные разработки, которыми пользуются коллеги – оцифровываем и автоматизируем наши внутренние бизнес-процессы.
По сравнению с внешними, внутренние продукты зачастую “догоняют”. Для внешних – 2-недельные спринты и разные там CI/CD; для внутренних – непрерывный поток задач, задачи берутся в работу по мере поступления. Работа делается, но сложно давать прогнозы, когда что будет готово — в любой момент времени может прилететь непредсказуемое количество задач, которые поменяют все планы. Не хватает людей – «вот сначала разберёмся со срочными задачами бизнеса, тогда займёмся этим».
В какой-то момент мы решили, что “хватит это терпеть” – попробовали радикально изменить работу с бэклогом внутренних продуктов. Стали приоритизировать задачи, активнее вовлекли стейкхолдеров в процесс планирования, отфильтровали неважные задачи, наладили процесс работы с багами и инцидентами.
В результате сейчас для каждой задачи из бэклога мы знаем, на кого она влияет, сколько таких людей, откуда задача взялась, какие там ключевые метрики и приоритеты относительно других задач. Очередь из просроченных задач практически сведена на нет.
Давайте расскажу, как мы к этому пришли.
Контекст: кастомизируем коробку
Моя команда — 12 человек, системные администраторы и специалисты технической поддержки.
Продукт, о котором пойдёт речь в статье — Naumen Сontact Center (дальше в тексте — Naumen). Это российская платформа омниканального обслуживания клиентов. Поддерживает все популярные каналы: звонки, почта, мессенджеры, соцсети, чат на сайте и остальные. Все обращения клиентов из разных каналов мы принимаем в одном месте, у нас единая очередь обработки контактов и единая история обращения.
Как это часто бывает с готовыми решениями, в какой-то момент мы захотели подстроить и доработать инструмент под свои особенности. Примеры наших типовых задач: передача адреса заказа из 1С в Naumen и обратно; создание дашборда для быстрого реагирования на проседания по уровню сервиса; кастомизация анкеты для удобства оператора и быстроты оформления заказа клиенту.
Для этих доработок мы выделили разработчика; сначала одного, потом больше. Со временем начались сложности с бэклогом и распределением задач — собственно, статья как раз о том, как мы с этим всем разбирались.
Глобально, проблем было две:
общая очередь задач и отсутствие приоритизации — все задачи заводились в единый список, задачи с низким приоритетом для бизнеса могли решаться быстрее, чем задачи с высоким приоритетом для команды;
задачи после разработки не передавались в техническую поддержку; часто по закрытым задачам не было документации; как результат, когда сервисы падали, было мучительно больно разбираться, в чём именно причина и как это починить.
За решение этих проблем мы взялись совместно с коллегами из бизнеса.
Как налаживали процесс
Цели, которые мы поставили перед собой, звучали так:
увеличить скорость разработки приоритетных задач для кастомизации Naumen;
передать уже имеющиеся сервисы в поддержку; вновь создаваемые сервисы – передавать по умолчанию;
согласовать изменения со всеми стейкхолдерами.
Со всеми заинтересованными мы договорились про процесс “кураторства”: от каждого отдела будет выделенный человек, который будет отвечать за задачи на разработку от своего направления. Соответственно, получили шесть кураторов: от отдела развития, логистики, качества, IT, проектов, продаж.
Куратор создавал что-то вроде верхнего уровня воронки, в которую попадали идеи от сотрудников отдела или от технической поддержки. Если куратор согласовывал пришедшую задачу, дальше она отправлялась на оценку разработчику и дальнейшее согласование с группой всех остальных кураторов.
Согласование кураторами проводилось на общей встрече, где каждый высказывал свое мнение, согласен или не согласен с актуальностью задачи, постановкой решения, оценкой на разработку.
Мы описали процесс с правилами, по которым нужно было работать техподдержке, кураторами и разработчикам.
Определили критерии оценки и подготовили Jira для управлении потоком задач. Договорились про формат документации для задач, которые разработчики передают в техническую поддержку.
Для систематизации оценки задач зафиксировали критерии: дедлайн, категория ценности, тип запроса, объем в часах, количество затрагиваемых пользователей, экономическая выгода за 12 месяцев. Для каждого критерия ввели его “вес”.
Логика с “весами” такая. Допустим, задача влияет на «не более 500 пользователей»; фиксируем “вес” критерия для такого уровня (например, конкретно для такого значения этого критерия – значение равно 3). После указания всех шести критериев мы суммируем эти “веса”, и у нас получается итоговая оценка, которая становится численным выражением приоритета.
Показатели вносятся и суммируются в Jira. После обсуждения кураторами у задачи есть три пути: (1) уйти в разработку, (2) быть отклонённой (“не будем делать”), (3) отправиться в банк идей (“сделаем когда-нибудь”).
На общей встрече кураторов отсеивается примерно 25% идей. Причины могли быть разные – например, вендор сам планировал в продукте подобные изменения.
Довольно распространённая причина отсеивания: задача потеряла актуальность с течением времени. Например, одно время мы пользовались услугами аутсорсингового контакт-центра; в бэклоге были задачи в духе “пусть внешний контакт-центр ещё и почтовые обращения получает”. Потом мы в большей степени стали опираться на собственные контакт-центры; так что задачи про расширение функциональности для аутсорсинговых стали не актуальны.
Ещё одна из причин отсеивания — нецелесообразность реализации. Или по-другому – дороже сделать, чем получим пользы. Экономическую выгоду оценивали стейкхолдеры от бизнесы; со своей стороны мы отнимали от неё стоимость разработки. Если получалось близко к нулю или меньше, задача не бралась в работу.
В банк идей уходили задачи, по которым было некачественно проработанное техническое задание или идея была хорошая, но пока недостаточно средств на реализацию, или не хватало прочих оснований для реализации.
Процесса в Jira содержит 10 статусов:
После выполнения задачи разработчик документирует её и передаёт на согласование в техническую поддержку. Те со своей стороны или согласовывает документацию, или запрашивают комментарии по непонятным для них пунктам. После ответов на все опросы задача закрывается технической поддержкой.
Для описания документации был подготовлен шаблон, чтобы было понятно, в каком формате ожидаем описание от разработчика.
С процессом случались проблемы – например, задачи могли начать зависать, не исполняться. Чтобы разобраться, где мы тормозим, воспользовались Kanban. Так мы определили максимальное количество задач, которые мы передаем в разработку, а также определили, сколько нужно людей, чтобы успевать разгрести всю очередь задач.
Строители с собственной стройкой
Благодаря внедрению оценки по критериям и вовлечению кураторов от бизнеса, мы научились категоризировать обращения, сортировать, поднимать в приоритете действительно значимые. Теперь первыми в очереди стоят задачи с высшим приоритетом, общее количество задач в бэклоге уменьшилось (и не пугает своим объемом), а бизнес имеет прозрачный и понятный механизм приоритизации и видит результаты.
Такой подход высвободил нам время, чтобы закрыть техдолг, привести в порядок технические решения и дописать документацию. Как результат — наладить процесс передачи сервисов из разработки на сопровождение.
Есть такое выражение – “сапожник с сапогами”. В контексте продуктовой разработки это может означать: давайте ко внутренним продуктам относиться так же, как к внешним. На деле такое отношение может достигаться сложнее, чем хотелось бы: внешние продукты – понятные, про деньги; внутренние – часто про комфорт команды, удобство, а это может быть менее железобетонными аргументами, чем прямая прибыль; “внутренние пользователи – все свои, могут и потерпеть”.
На мой взгляд один из главных результатов нашего нового подхода к управлению бэклогом внутреннего продукта – не только в формальных показателях экономической выгоды и скорости поставки, но в области командной динамики. За счёт вовлечения бизнеса и постоянного диалога мы стали на шаг дальше от обезличенного формата “заказчик – исполнитель” и стали на шаг ближе к “делаем одно общее дело, каждый со своей стороны, но вместе”.
Продолжаем строить в этом направлении!
