Порой разработка нового продукта, автоматизация существующего процесса выглядит, как работа хирурга, который провел сложную операцию: в моменте избавил человека от серьезной проблемы, а то и вовсе спас жизнь. И на этом, как правило, история заканчивается. Однако после каждой операции есть еще одна очень важная стадия, о которой почему‑то не принято говорить — это реабилитация. И от того, как она пройдет, зависит работоспособность органов и качество жизни.
В IT‑разработке тоже есть такая стадия — это поддержка того, чем осчастливили заказчиков. Если ее упустить, то даже идеально проведенная «операция» может закончиться осложнениями. Поэтому для аналитика понимание этой стадии не менее важно, чем участие в создании нового продукта.
Все, что описано ниже, основано на моем личном опыте работы по сопровождению поставки рыночных данных в хранилище. Я не претендую на универсальность - в других командах и компаниях процессы могут быть выстроены иначе.
Чем поддержка отличается от организации работы в рамках проекта?
Цель команды заключается в том, чтобы поддерживать бизнес и существующие системы/процессы в рабочем состоянии, обеспечивать их стабильность и бесперебойность.
Соответственно, нет общей финальной даты, задачи приходят постоянно.
Тем не менее сроки выполнения работ существуют и определяются соглашением об уровне сервиса (SLA — Service Level Agreement). Оно регламентирует скорость реакции на запрос в зависимости от его приоритета, время решения, доступность сервиса/системы.
В случаях, если нужна разработка, релизы преимущественно носят нерегулярный характер и формируются по мере срочности и необходимости. Поэтому нет как таковой привязки к спринтам, кварталам и так далее. Единственным ограничением может быть заморозка изменений в соответствии с внутренними корпоративными политиками (например, в районе новогодних праздников, закрытии финансового года).
Задачи по поддержке редко приносят «вау‑результат», но без нее все рухнет. Работа не видна, когда все хорошо, но когда плохо — заметна каждому.
На мой личный взгляд, наиболее удобной методологией для организации рабочего процесса при операционной деятельности является Kanban и его инструменты визуализации в виде Kanban‑доски.
Под операционной деятельностью я имею в виду повседневную работу IT-команды в режиме сопровождения: обработку заявок, мелкие изменения, взаимодействие с пользователями и командой поддержки.
Одним из самых сложных организационных моментов, на котором ломается множество копий, является ограничение задач в работе. В теории оно направлено на то, чтобы максимальные ресурсы были брошены на завершение задачи. Однако на практике случается иное: очень быстро заканчиваются задачи, которые можно брать в работу; процесс стопорится на каком‑то этапе, потому что застрявшую задачу нельзя по тем или иным причинам двинуть дальше. Опытным путем мы пришли к тому, что сняли ограничение в количестве задач, что идет вразрез с теорией. Однако это позволило нам увеличить скорость реализации запросов разной степени сложности, переприоритезировать застрявшие задачи (а то и вовсе отправлять их в долгий ящик из‑за нецелесообразности).
В чем заключается специфика для бизнес/системного аналитика?
Как правило, бизнес‑ и/или системный аналитик только часть времени задействован в поддержке, остальное время он прикреплен к проекту/продукту. Например, фактическая занятость может быть 0,25 или 0,5 от общего количества рабочих часов, даже если это не оговорено формально. И частичную загрузку обязательно нужно учитывать при планировании работ в рамках основного проекта.
SLA‑соглашение действует не только на первую линию поддержки, но и на сопровождающую IT‑команду. Как результат, аналитику необходимо выдерживать обозначенные временные рамки, более дробные, чем в пределах проектной деятельности.
Этот пункт вытекает из предыдущего. Приходящие запросы небольшие, но требуют внимания здесь и сейчас (как минимум нужно оценить их срочность), поэтому очень важно уметь быстро переключаться между своими задачами по проектной части на вопросы по поддержке и обратно.
Кратно увеличивается количество человек, с кем необходимо общаться на ежедневной основе, в основном за счет бизнес‑пользователей.
Специфика задач требует с одной стороны глубокого понимания систем, с которыми работает аналитик, с другой — широкого корпоративного кругозора, т.к. никогда не знаешь кто с каким вопросом может прийти.
Зачастую требуется проведение исследовательской работы с дальнейшей выработкой требований/технологии/подхода по тому или иному вопросу. Именно эта часть и занимает бОльшую часть всего времени.
Как правило, разработка требований менее формализована из‑за ограниченности ресурсов, однако поддержка документации в актуальном состоянии должна находиться в постоянном фокусе внимания.
Приходящие вопросы и запросы носят непредсказуемый характер, что требует гибкой перенастройки планов на день.
Есть опасность выгорания из‑за «текучки».
Однако, аналитик в операционке получает уникальный опыт: лучше знает пользователей, видит систему «в бою», накапливает практику быстрых решений.
Как оптимизировать и наладить работу?
Опыт показал, что, не смотря на кажущуюся простоту и очевидность, крайне важно грамотно организовать свою работу, внутри команды, наладить коммуникацию с пользователями и первой линией поддержки. Иначе можно просто утонуть в количестве задач и половину их растерять.
Почта (казалось бы, что проще)
Почта — один из главных каналов, через который поступают запросы. И именно она часто становится источником хаоса: письма теряются, висят непрочитанными неделями или обрастают дублирующими переписками.
Мне удобнее всего выделять папки по категориям задач и настраивать для них правила: вопросы от бизнеса, вопросы от нашей команды, прямые задачи от руководителя, вопросы от других команд, технические письма, рассылки, уведомления общие, уведомления в моей юрисдикции. Понимая приоритет папок, сразу видишь те письма, которые требует первоочередного внимания, а какие не глядя можно отметить прочитанными.
Также может быть полезным маркировать письма по тому или иному признаку. Я для себя выработала подход, что не отмечаю прочитанными те письма из важных, которые реально не просмотрела. Или возвращаю их в непрочитанный статус, если они требуют моего ответа или дополнительного внимания. Можно к письмам прикреплять флажки, раскрашивать разными цветами.
Если почта только общая (а этого максимально стоит избегать), очень важно определить правила, по которым все члены команды понимают свои зоны ответственности, чтобы исключить ситуации, когда письмо или не берется никем, или берется в работу несколькими людьми одновременно.
Если в компании можно применять нейросети для переписки, то лучше их использовать для описания проблем/запросов, а не коротких ответов. Когда вместо простого «ОК, принято» получаешь три абзаца текста в духе «Ваше мнение очень важно для нас», «Мы сделаем все от нас зависящее», — неизбежно приходится вчитываться и тратить время. 30 секунд — мелочь для одного письма, а если таких писем несколько десятков за день?
Когда приходит вопрос, имеет смысл ответить, что он принят в работу и когда будет ответ. Так вторая сторона понимает, что его запрос не потерялся.
Мой личный максимум был 32 письма за день. Поначалу меня невероятно раздражало то, что каждый раз нужно отвечать «ОК, принято», зачем тратить на это время и электронные чернила. Однако практика показала, что одна минута экономит часы, которые могли бы уйти на уточнения и напоминания.
Треккинговая система (тоже весьма очевидно)
Вторая составляющая успеха — единый реестр задач, или треккинговая система (по типу JIRA). Что имеет смысл отслеживать:
Свои задачи. Можно завести личную Kanban‑доску (Trello и аналоги). Лично я не воспринимаю задачи в электронном виде, поэтому у меня есть блокнот, куда их записываю и зачеркиваю сделанные (как правило, в моменте порядка 20–25 активных задач). А также в этом году открыла для себя еженедельный планер: разбрасываю задачи на неделю, так мне легче планировать день и давать оценки по срокам.
Все поступающие задачи на команду. Если задача не внесена в треккинговую систему, то ее не существует. Кроме того, важно выработать процессы внутри команды, в том числе как задачи комментировать: на каком окружении была разработана задача; на каком окружении она была протестирована; подтверждение того, что дефект исправлен. Важно быть аккуратным в переводе статусов и назначении соответствующего человека, чтобы не терять время, выясняя, действительно ли можно брать задачу в работу.
Важность пункта сложно переоценить — через год уже никто не вспомнит нюансов, письма по вопросу могут быть уже удалены. Более того, треккинговые системы обеспечивают прозрачность внутрикомандных процессов и помогают оценить реальную загрузку.
Звонки по статусам всех открытых задач. В нашей команде не прижилась практика. Два раза в неделю тратили по часу и более на обсуждение всех открытых задач, повторяя одно и то же. В итоге, на ежедневных планерках обсуждаем только актуальные задачи, а руководтель команды отслеживает общую картину.
Коммуникация
Коммуникация со своей командой. Мы внутри договорились, что в случаях, когда аналитику после перевода задачи в разработку нужно по какой‑то причине вернуться к ней, пишут в личку или звонят, чтобы обратить внимание. Так как уведомлений от разных систем у нас очень много, легко можно пропустить уведомление о переводе задачи.
Коммуникация со смежными командами. Опыт показал, что стоит формализовать отношения по по‑максимуму. Хуже всего, если одни команды двигаются по своему процессу, а другие — работают над запросами «по дружбе». Если нет общей треккинговой системы, всю коммуникацию лучше вести через почту с копией всей группы/команды, чтобы исключить договоренности в личных сообщениях.
Документация
Требования проще всего сразу описывать в треккинговой системе по конкретной задаче, чтобы избежать избыточного количества ссылок.
Если формируются общие знания по системе, их можно оформить либо в отдельный документ, либо на страницах Confluence и аналогичных системах.
Всю документацию стоит хранить в едином общеизвестном месте и избегать дублирования версий. Впрочем, это касается не только поддержки, но и любой проектной/продуктовой деятельности.
Ежедневная рутина и ритуалы
Как утро начинается с умывания и зарядки (если кто‑то настолько молодец), так и рабочий день очень удобно начинать со своих ритуалов. Они помогают быть в курсе текущего положения дел и скорректировать дальнейшие планы.
Проверка почты. В среднем за ночь к нам приходит порядка 20 писем и сотня тех или иных уведомлений. 15 минут достаточно (с учетом настроенной почты), чтобы пробежаться по письмам, оценить их срочность и важность, отметить то, что нужно брать в работу.
Проверка работоспособности систем. У нас настроена Grafana, которая показывает текущее состояние всех серверов, за которые отвечает команда.
Проверка календаря встреч на текущий день. Помогает оценить количество доступных часов на выполение задач.
Дальше можно выпить чашечку кофе.
Адаптация приоритетов на день на основании пунктов выше. Какие задачи и сколько нужно брать в работу (проектные, поддержки, ответы на письма), а какие можно отложить.
Личность аналитика
Не только инструменты и процессы делают аналитика эффективным, но и его личные привычки и способности.
Развивать память и внимательность. К примеру, хорошая память на уже сделанные задачи сильно сокращает время на поиски писем, когда нужно вернуться к ним или похожим.
Сохранять энергию. Большое количество параллельных задач ментально быстро выматывает. Поэтому очень важно качественно спать, добавлять спорт в жизнь, следить за своим питанием и здоровьем.
А теперь любопытно узнать, как у вас устроена поддержка и роль аналитика в ней? Возможно, у вас есть более удачные практики или нестандартные решения. Делитесь в комментариях!
Еще больше всего интересного на моем телеграмм канале «АналитикНаводитПорядок».