Выжимка требований и обязанностей после исследования кучи вакансий, частые хотелки бизнеса и реальные задачи системного аналитика. Отсеиваем лишнее. Покажите своему руководителю, чтобы перестать делать всё, везде и сразу.
Привет! Меня зовут Кир @akxkir — системный аналитик в Монете — и за 5+ увлекательных лет в IT я успел примерить шляпы фронтендщика, техписателя, лида QA, тимлида и архитектора. Сегодня хочу поделиться взглядом на роль САнов в команде и компании в целом: кто они такие, кому и зачем нужны и какие задачи выполняют. Рассуждения будут полезны новичкам в системном анализе и всем тем, кто имеет счастье работать с САнами.
* Вы уже догадались, но «САном» я обозначаю роль Системного Аналитика (а «СА» — это Системный Анализ).
САн в теории, или Сферический САн в вакууме
Начнём с парочки хрестоматийных определений СА / САна (цитаты сокращены, расставлены акценты).
Совокупность методик и средств, используемых при исследовании и конструировании сложных систем, разработка методов выработки, принятия и обоснования решений при проектировании, создании и управлении системами.
Большая российская энциклопедия
The system analyst role leads and coordinates requirements elicitation and use-case modeling by outlining the system's functionality and delimiting the system; for example, establishing what actors and use cases exist, and how they interact.
Rational Unified Process
Специалист по решению сложных организационно-технических проблем, имеющих междисциплинарную природу.
Ответственный за анализ потребностей пользователей на предмет возможности их удовлетворения. Также его называют «постановщик задач». Основным продуктом являются организационно-технические решения, оформляемые как техническое задание.
Википедия
Звучит уже достаточно убедительно и монументально, чтобы у начинающего САна случился преждевременный кризис самоопределения. Но ничего, дальше будет хуже! А потом лучше. Но вы держитесь!
САн, как его видят в вакансиях
Продолжим накидывать на вент фактуру — посмотрим на обязанности и требования к САнам, которые чаще всего указывают в вакансиях на hh (примерно по 30 вакансиям). Также с акцентами.
Обязанности:
Интервьюировать заказчиков и пользователей.
Выявлять, собирать, анализировать и документировать требования.
Прорабатывать варианты оптимизации текущего функционала.
Предлагать решения возникающих проблем.
Планировать RoadMap и вести бэклог.
Выступать связующим звеном между разработкой и заказчиком.
Прототипировать интерфейсы и проектировать бизнес-процессы.
Участвовать в восстановлении документации проекта.
Разрабатывать ТЗ.
Ставить задачи разработчикам и дизайнерам.
Координировать работу нескольких команд разработчиков.
Разрабатывать и проектировать архитектуру.
Разрабатывать сценарии тестирования и участвовать в процессах тестирования.
Контролировать сроки выполнения и этапы работы.
Составлять функциональные спецификации.
Проектировать use cases.
Проектировать внутрисистемные и внешние интеграции (REST API).
Проектировать реляционные БД на уровне логической модели.
Составлять пользовательскую документацию (руководства, инструкции).
Проводить презентации разработанного функционала.
Требования:
Знание архитектурных подходов проектирования высоконагруженных систем.
Представление о форматах данных, применяемых в веб: XML, HTML, JSON, WSDL.
Понимание способов взаимодействия браузера и сервера: куки, сессии, HTTP, AJAX, сокеты.
Знания в области технологий: REST, SOAP, SQL, шифрование, балансировка нагрузки.
Примеры самостоятельно разработанных ТЗ, алгоритмов, интерфейсов.
Высокая коммуникабельность.
Умение работать в Jira, Confluence, вести подробную документацию требований и задач.
Хорошее понимание технического процесса разработки по Scrum и Agile.
Умение разбираться в новых сервисах и интерфейсах.
Знание английского языка не ниже Upper-Intermediate.
Опыт работы с брокерами сообщений (rabbit, kafka).
Понимание жизненного цикла процесса разработки.
Общее понимание микросервисной и монолитной архитектуры.
Опыт проектирования REST API. Умение писать Swagger, навыки работы в Postman.
Навыки декомпозиции работ по аналитике и для продукта в целом.
Знание и опыт использования инструментов визуализации: Figma, Visio, Miro, Draw.io.
Опыт ведения переговоров, проведения презентаций.
Вы ещё тут? Супер!
Немного переварив определения, вакансии на hh и добавив собственный опыт, можно кристаллизовать следующие темы (в свободном порядке):
Требования
Декомпозиция задач
Пользовательская документация
Построение дашбордов
Контроль сроков
Пользовательские интерфейсы
Тестирование
Оценка трудозатрат
Анализ данных
Архитектура
Постановка задач
Координация команды
Исследование рынка
Оптимизация процессов
Связь с внешним заказчиком
Разработка спецификаций
И вот ещё парочка вопросов к САну из уже личной практики:
Почему не работает?
Когда это сломалось?
Партнёры дали обратную связь?
Как долго это разрабатывать?
А бизнесу это вообще нужно?
Что сказать
клиентупартнёру?Проверь, оно работает?
Вот так можно выкладывать?
САн, что он должен делать по факту. Origins
С фактурой закончили. Теперь давайте разбираться, как со всем этим добром должен управляться САн (спойлер: не должен, ну или точно не со всем). Поговорим о системах.
Границы системы, как правило, чётко не определены — можно найти «серую зону», которая напрямую и не находится в самой системе, но существует ради её поддержки. Назовём эту зону контекстом.
Наша система может пересекаться контекстом с какой-либо другой. Это что касается внешних границ системы. Рассмотрим теперь её внутренности.
Состав системы рассмотрим на примере IT-продуктов, хотя основные принципы будут те же и для других областей.
Не минимальный, но джентльменский набор элементов системы:
Интерфейсы — что-то, что воспринимает входные данные от пользователя (GUI, файлы для импорта, физические кнопки, пины и т. п.).
Обработчики — собственно, код или его аналог (например, электронная схема, чип, шестерёнки, сообщающиеся сосуды — всё зависит от рассматриваемой системы), выполняющий основные бизнес-функции системы.
Данные — данные, порождаемые и/или используемые самой системой (записи в БД, сообщения в очереди, перфокарты, диски и т. д.).
Документы — некоторые артефакты реального мира (распечатки отчётов, справки, билеты и т. п.).
Связи между элементами — обозначают поток данных или управления, это процессы внутри системы.
Добавляем сигналы — это могут быть простые сообщения, вызовы, мигания лампочек и прочее. Сигнал может быть входным или выходным.
У неодноклеточных систем со временем появляется несколько источников данных и интерфейсов…
… а потом обработчики делятся на сервисы или модули, которые могут общаться через сигналы и использовать общие данные и разные интерфейсы...
Уже начинает сосать под ложечкой? Не будем доводить пример до реальной системы, да и цель не в этом. Давайте обратим внимание не столько на «объекты» внутри системы, сколько на связи между ними. Заметили, как быстро растёт количество зелёных дорожек? А ведь это именно то, как система работает, без знания этих процессов нам сухой перечень модулей и сигналов ничем не поможет, нам нужно знать взаимосвязи.
Финальная картинка — сложность есть не только внутри самой системы, но и в её контексте: какие роли за что отвечают, какие артефакты используются или порождаются системой. И да, информационной системой, по-хорошему, является весь окружающий его контекст. Хотя для удобства восприятия такое разделение кажется вполне сносным.
Получаем, что для успешного анализа системы (цель анализа тут опустим) САн должен разбираться в составных элементах системы и связях (процессах) между ними. Разумеется, это даёт огромное преимущество и в разборе инцидентов, и в написании документации, и в тестировании — практически для любой работы с системой.
Теперь понятно, из-за чего на рынке такой широкий спектр требований к САну. Ровно поэтому на практике САны часто могут заниматься не своими обязанностями, а это совсем не гуд.
Часто ли вы встречали, например, продактов или менеджеров проекта, которые тестируют свой продукт и пишут руководства пользователя? В то же время QA берёт на себя задачу выявления требований, а техписателю приходится копаться в коде, чтобы составить документы по архитектуре системы?
И где-то в этой суматохе потерялось написание спецификаций API, и теперь фронту и бэку приходится работать не просто последовательно в режиме с взаимными прерываниями, уступками и костылями, но ещё и периодически переключаться на вечные баги от техпода или QA. Но не думайте, что с появлением архитектора и САна всё сразу поменяется — обязанности нужно разделять, компетенции развивать, а границы отстаивать.
Отсекаем лишние обязанности: «Дорогая, я уменьшил скоуп наших САнов!»
Теперь вернёмся к сформулированным темам, рассмотрим их со стороны САна и обозначим явно чужие:
🟢 | Требования (влияние требований на всю систему в прямой зоне ответственности САна) |
🟢 | Декомпозиция задач (САн знает, какие части системы нужно учесть при постановке задачи) |
🟡 | Пользовательская документация (САн тут хороший помощник, но никак не ответственный) |
🟢 | Построение дашбордов (САн часто сам строит отчёты или дашборды, чтобы понять поведение системы) |
🔴 | Контроль сроков (видимо, трудности перевода или менталитета — САн к срокам отношения не имеет) |
🔴 | Пользовательские интерфейсы (было бы замечательно, но нет) |
🔴 | Тестирование (правда?) |
🟡 | Оценка трудозатрат (сложная тема, тем не менее, на своём уровне погружённости САн не сможет дать оценку для той же разработки) |
🟢 | Анализ данных (для анализа часто пригождается знание смежных частей системы) |
🟡 | Архитектура (САн может заниматься архитектурой и должен в этом разбираться, но ответственным тут может быть только архитектор) |
🟡 | Постановка задач (в отсутствии лида — да, но почему у вас нет лида?) |
🔴 | Координация команды (хочется верить, что для этого есть специальная роль, что-то вроде менеджера продукта или руководителя проекта, вот прям на языке вертится) |
🔴 | Исследование рынка (не путать с бизнес-аналитиком) |
🟢 | Оптимизация процессов (процессы — это вообще хлеб для САна) |
🟡 | Связь с внешним заказчиком (только на уровне согласованных коммуникаций с разработчиком или аналитиком внешней системы при интеграции с ней) |
🟢 | Разработка спецификаций (спецификации объединяют требования, процессы и знание системы как целого) |
Закрепим:
САн — это междисциплинарный специалист, который точечно применяет знания об общем контексте системы.
САн физически не сможет быстро выполнять задачи в любой точке системы (нужно погружение), но он способен оказывать консультации по общим принципам работы её компонентов.
Как это устроено у нас в финтехе. Порождения САна
Перейдём к конкретной конкретике. Конечно, всё зависит и от специфики проекта, и от наличиствующих ролей, и от так-истерически-сложилосьстности — поэтому вот список ролей внутри нашей команды для ориентира:
Лид продактов (продукт сложный, нужен координатор-вижионёр).
Продакты (по одному на направление внутри продукта, отвечают за бизнесовую часть).
САны (в идеале по одному на продакта, но сейчас нас меньше).
Два специалиста QA (расшарены на несколько команд).
Разработчики (тоже +/- делятся по направлениям).
Итак, в каких процессах у нас участвуют САны:
Приём задачи или проблемы (от бизнеса её нам приносит продакт).
Поиск затронутых частей системы (собственно, сам анализ).
Выявление и формализация требований, техническая постановка задачи (есть хотелка — мы выдаём требования и задачи).
Документирование и актуализация требований (по результату работы над задачей смотрим, что фактически сделали, дополняем базу знаний реализованными решениями).
Какие артефакты создают САны (зависит от задачи):
Эпики
Задачи
Архитектурные решения в ADR
Контекстные диаграммы в C4
Модели процессов в BPMN
Спецификации сервисов или компонентов
Диаграммы последовательности в Sequence UML
Логические модели данных как диаграммы классов UML
Спецификации API
Дашборды, графики, отчёты по анализу данных
Профилактика: как заметить, что делаешь чужое. Кто, если не САн?
Завершим рассуждения памяткой «Как САну не потерять себя»:
Кого замещаем | Признаки | Профилактика |
Продакт | Непонятные сроки задачи, кому и зачем она нужна. | Придерживаться шаблона заполнения задач всей командой. |
Тех. поддержка
| Требуется поиск по логам вместо глубокой аналитики. | Вести реестр частых ошибок и способов их решения, брать задачу после однозначного указания ошибки по логам. |
QA-инженер
| Составление тестовых сценариев, выявление граничных условий. | Передавать функциональные сценарии на проработку QA-инженеру до отправки задачи в разработку. |
Архитектор
| Выбор конкретных программных решений. | Не привязываться к конкретной реализации, если её ещё нужно выбрать. |
Разработчик | Детализация до уровня наименований в коде, привязка алгоритма к технической реализации. | Согласовывать оптимальный вариант решения задачи с разработчиком, предлагать несколько вариантов. |
Сегодня мы лишь слегка приоткрыли дверцу к такой удивительной, многогранной и неоднозначной роли, как Системный Аналитик. И сколько ещё впереди! А сейчас велком в комментарии — всегда интересен опыт коллег по цеху (как САнов, так и тех, кто за ними наблюдает — не просто так ведь вы открыли эту статью).
