От идеи до реализации: роль системного аналитика в проекте

Здравствуйте, меня зовут Плеско Юлия. Я работаю системным аналитиком в Gems уже полтора года. Сегодня я расскажу о своей работе, так сказать, приоткрою завесу тайны. Каждый день я исследую не только проектные задачи, но и погружаюсь всё глубже в предметную область. Моя задача понять, что хочет на самом деле заказчик и пользователь, чтобы сформулировать и передать задачу в разработку. Потом донести эту мысль тестировщикам, чтобы протестировать реализованный кусок проекта. А в финале всё задокументировать, то есть перевести на пользовательский язык то, чему мы научили систему. В этом мне помогают технические писатели, которые, в свою очередь, готовят всевозможные руководства для пользователей. Параллельно со всеми этими процессами я фиксирую всё, что происходит на проекте: документирую требования и те изменения, которые мы берем в работу в ходе реализации проекта.

Так выглядит моя работа, если пытаться описать её в один абзац, но на самом деле каждый этап намного больше и объёмнее. Так как мы ищем к нам нового члена команды, то расскажу чуть детальнее: об общего перейдём к частному.

Первый этап — планирование

Любой проект начинается с планирования, как бы банально это не звучало. Начиная реализацию задачи, мы составляем некий план — концепцию развития того или иного модуля. Даже если это какой-то небольшой кусок, мы должны понимать, к чему мы движемся. Этот документ должен содержать описание функциональности будущего модуля или его части — это верхнеуровневое видение продукта. Если привести простой пример концепции, то её содержание звучало бы так: «Солнце должно вставать на восходе, а садиться на западе».

На основе концепции совместно с директором продукта мы прописываем конкретные шаги, которые позволят достичь цели и реализовать описанное представление. Если продолжать пример с солнцем, то тут мы пропишем, когда и в каких точках должно быть солнце, чтобы восход состоялся в такое-то время.

Второй этап — исследование или уточнение требований

На мой взгляд, это ключевой этап, так как от качества сбора информации зависит удовлетворённость заказчика результатом после завершения проекта, то есть выполнили мы задачу или нет своим решением. Моя задача понять потребности пользователей и ожидания заказчиков, для этого я взаимодействую с большим количеством людей и изучаю нормативно-правовую базу.

Ключевые источники информации системного аналитика

1. Заказчики — они непосредственно понимают, какую задачу предстоит решать, какие процессы уже существуют, какие артефакты есть на каждом этапе этого процесса, какие люди и в каких ролях задействованы.

2. Коллеги — специалисты команд внедрения — у них есть опыт работы над проектами в 55-ти регионах России, а значит они могут поделиться лучшими практиками или рассказать, на какие “подводные камни” можно напороться.

3. НПА — достоверный источник информации, который даёт понимание как должна функционировать та или иная система, каким требованиям должна удовлетворять.

Методы сбора информации

Перед началом исследования у меня на руках есть контракт (договор) и техническое задание на разработку, но это формальный документ, который далеко не всегда позволяет решить задачи пользователей. Исследование позволяет нам быть более проактивными, что, в свою очередь, помогает нам создавать адаптивные системы, а значит делать интерфейсы и логику в процессах удобнее, понятнее и привычнее для пользователей.

На этом этапе я получаю информацию не только путём анкетирования или интервьюирования посредством вопросов, но и путём наблюдения за рутинными действиями специалистов.

В большинстве своём такого рода взаимодействие строится в онлайн-формате, когда есть чёткий тайминг и регламент встречи. Бывают случаи, когда есть возможность пообщаться с заказчиком вживую, но у меня буквально пару раз было так. Живое общение всё же в большинстве случаев информативнее и душевнее, так как у нас почти нет ограничения по времени, пользователи более расположены к беседе и чаще делятся живыми историями из практики, которые помогают лучше понять тонкости выстроенных процессов.

А если говорить в общем, то частота созвонов или встреч варьируются от проекта к проекту, а ещё зависят от этапа проекта. Например, в период сдачи проектов количество созвонов увеличивается. Если на начальном этапе чаще созвоны инициируем мы, то ближе к завершению — заказчик, так как в процессе тестирования возникает всё больше вопросов. У меня всё весьма волнообразно: может быть 3-4 встречи в день, а может быть две-три недели вообще без созвонов.

После созвонов я фиксирую основную мысль общения, прописываю достигли ли мы обозначенной цели встречи, какие возражения возникли или какие были замечания.

Документация этапа

Артефактами первого этапа являются уточнённые технические требования и понимание, что конкретно предстоит реализовать. Моя задача понять, как объединить пожелания заказчика, возможности наших команд, возможности системы и требования НПА.

Этот этап происходит при реализации проекта не единожды, а на каждом шаге реализации концепции, которая написана на первом этапе. То есть мы берём в работу первый пункт концепции — уточняем требования к функционалу — выявляем и фиксируем требования, которые будут непосредственно переданы команде разработки в формате задач. По сути, я должна прийти в команду и сказать ребятам: «Модуль должен делать то и то для того и того». Дальше ребята уже понимают, что нужно конкретно сделать, чтобы это стало осуществимо, а дальше декомпозируют задачу и распределяют между собой. Если снова продолжать пример с восходом солнца, то требования — это то, что конкретно нужно сделать, чтобы солнце оказалось в точке X в час Y, при этом чтобы светило с яркостью Z, а также другие важные переменные, которые мы определим в требованиях.

Третий этап — разработка и тестирование

Обычно над проектом работает целая команда: backend и frontend разработчики, тестировщики, иногда дизайнеры и аналитик. Перед тем как заняться непосредственной реализацией мы фиксируем все «хотелки» в бэклоге команды, на него и будем в дальнейшем ориентироваться. Главное при разработке, чтобы задачи не противоречили концепции в области общего видения реализации модуля.

Мы делим задачи с учётом трудозатрат и сроков выполнения. Разработчики планируются на спринт, то есть две недели, а команда аналитиков живёт скорее неделями. В начале или в конце недели я планирую свою работу, ориентируясь на задачи, которые разработчики собираются брать в работу в этот период. Моя цель — идти не просто в ногу с ними, а немного опережать, чтобы они могли реализовывать мои наработки.

Каждый день начинается с дэйли — небольшого совещания, где мы обсуждаем планы команды. Затем я приступаю к своей работе: я ещё больше детализирую задачу, опираясь на бэклог, концепцию и технические требования. В итоге у меня должно получиться что-то такое: «сделай это таким способом, положив это туда и если нужно обратно».

С дизайнером мы прорабатываем требования и согласуем решения. Например, если я знаю, что пользователю привычно, чтобы кнопка была красной, она и должна остаться красной. а не синей или, скажем, зелёной. Наша задача сделать не просто красивый интерфейс, но и интуитивно понятный пользователю.

Здесь я много времени уделяю подготовке всевозможных инструкций. Например, с тестировщиками — для подготовки инструкций для интеграторов, то есть для тех, кто будет устанавливать нашу наработку — чаще всего, это наши команды внедрения. По завершении работ буду взаимодействовать с техническими писателями для подготовки инструкций пользователей и администраторов, то есть для тех, кто будет решать свои рабочие задачи или настраивать и обслуживать эти процессы в моменте. По итогу каждый должен понимать, что и где искать, как сделать, чтобы получить результат.

Четвёртый этап — демонстрация и обучение

Непосредственное обучение пользователей проводят внедренцы, моя же задача научить их. Как правило, это происходит, когда мы демонстрируем наработку на обзорах спринта. Если вдруг у коллег будет много вопросов, то мы с радостью расскажем и покажем функционал в любое время.

Здесь может сложиться впечатление, что мы учим только на готовых продуктах. Совсем нет. Мы всегда делимся с заказчиками и пользователями тем, что узнаём сами: будь то трактовка НПА, правила работы, которые используют другие регионы и многое другое. Да, это не обучение работе с системой, но это важные элементы, которые необходимо знать и учитывать. Мы хотим, все процессы наших заказчиков по мере возможности сделать единообразными и правильными.

Работа системного аналитика — это не просто выполнение задач, а создание связующего звена между заказчиком и командой разработки. Каждый этап проекта требует внимательности и глубокого понимания как потребностей пользователей, так и технических возможностей системы.

В следующей статье мы расскажем о работе аналитика на примере реального проекта.