Практическое руководство примеры и шаблоны

Содержание
  1. Должностные обязанности Аналитика
  2. Общие положения:
  3. Квалификационные требования:
  4. Должностные обязанности:
  5. Отчетность:
  6. Права:
  7. Критерии эффективности и ответственность:
  8. Подбор Аналитика кадровым агентством ФАВОРИТ
  9. Наши услуги включают:
  10. Преимущества работы с кадровым агентством ФАВОРИТ:
  11. Введение
  12. Значение в современном бизнесе 
  13. Пример работы аналитика 1С 
  14. Заключение
  15. Должностные обязанности Ведущего аналитика
  16. Подбор Ведущего Аналитика в кадровом агентстве «ФАВОРИТ»
  17. Проект
  18. Общий подход к работе системного аналитика
  19. 01 Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение
  20. 02 Определение ролей пользователей и приложений. Верхнеуровневое проектирование архитектуры
  21. Определение ролей пользователей и приложений
  22. Верхнеуровневое проектирование архитектуры
  23. 03 Выделение и описание основных сценариев работы с системой
  24. Use Case
  25. 04 Проработка альтернативных сценариев
  26. 05 Задачи на дизайнера
  27. 06 Определение ключевых данных: сущности и их свойства
  28. 07 Задачи на доработку Базы Данных
  29. 08 Задачи на подготовку тестовых данных
  30. 09 Задачи на разработку методов Backend (методов API)
  31. 10 Задачи на фронтенд / мобильные
  32. 11 Задачи на тестирование
  33. 12 Задачи на сохранение важных артефактов по документации после разработки — документация
  34. Применение описанного подхода на практике
  35. Заключение
  36. 2. Функции
  37. 3. Должностные обязанности
  38. 4. Права
  39. 5. Ответственность
  40. 6. Заключительные положения
  41. 5 главных документов аналитика
  42. Основы бизнес-анализа: вход в профессию для начинающих
  43. Документ бизнес-требований
  44. Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
  45. Технико-экономическое обоснование (ТЭО)
  46. Основы бизнес-анализа: вход в профессию для начинающих
  47. Спецификация требований или техническое задание (ТЗ)
  48. Разработка ТЗ на информационную систему по ГОСТ и SRS
  49. Проект решения
  50. Основы архитектуры и интеграции информационных систем
  51. Программа и методика испытаний (ПМИ)
  52. Разработка ТЗ на информационную систему по ГОСТ и SRS
  53. Кто такой аналитик

Должностные обязанности Аналитика

Должностная инструкция Аналитика

Общие положения:

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

Дополнительный анализ:  Бухгалтерская отчетность в стратегическом анализе это

Квалификационные требования:

  • Высшее экономическое или математическое образование.
  • Опыт работы в аналитике данных не менее 2 лет.
  • Продвинутое владение инструментами для работы с большими данными и статистическим анализом.
  • Навыки работы с аналитическими платформами и BI-системами.

Должностные обязанности:

  • Сбор и структурирование данных из различных источников.
  • Проведение маркетингового анализа и прогнозирования трендов.
  • Разработка отчетов и дашбордов для руководства.
  • Поиск путей оптимизации бизнес-процессов на основе полученных данных.

Отчетность:

Аналитик предоставляет регулярные аналитические отчеты и рекомендации по результатам исследований и анализа данных.

Права:

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

Критерии эффективности и ответственность:

Эффективность работы Аналитика оценивается по точности и своевременности аналитических отчетов, вкладу в повышение эффективности компании и успешности внедрения предложенных улучшений.

Подбор Аналитика кадровым агентством ФАВОРИТ

Агентство ФАВОРИТ — Ваш надежный партнер в поиске профессиональных и квалифицированных Аналитиков. Мы помогаем компаниям находить специалистов, критически важных для анализа данных и поддержки бизнес решений.

Наши услуги включают:

  • Бизнес-аналитика: Профессионалы, способные извлекать ценные инсайты из данных.
  • Финансовый анализ: Эксперты в прогнозировании и оптимизации финансовых потоков.
  • Маркетинговый анализ: Аналитики, определяющие эффективные маркетинговые стратегии.
  • ИТ-аналитика: Специалисты по систематизации IT-процессов и улучшению технологической инфраструктуры.

Преимущества работы с кадровым агентством ФАВОРИТ:

  • Быстрый поиск и подбор кандидатов, соответствующих вашим требованиям.
  • Тщательный отбор кандидатов на основе проверки их квалификации и опыта.
  • Доступ к широкой базе данных и уникальным инструментам отбора, который обеспечивает наилучший выбор для вашей компании.

Найдите идеального Аналитика для вашей компании с помощью агентства ФАВОРИТ. Свяжитесь с нами сегодня — посетите наш веб-сайт FAVORIT.PRO или звоните по номеру +7 (495) 988-55-25 для получения индивидуальных предложений.

Дополнительный анализ:  Практика Верховного Суда РФ по налоговым спорам за декабрь 2021 года

Введение

Аналитики 1С – это профессионалы, занимающие важное место в современных компаниях, обеспечивая эффективное внедрение и использование продуктов “1С”. Эта роль сочетает в себе аналитические и технические навыки, а также умение взаимодействовать с клиентами и разработчиками. Давайте подробнее рассмотрим, что включает в себя работа аналитика 1С и почему эта профессия востребована в современном бизнесе.

Практическое руководство примеры и шаблоны

Разместим вашу вакансию на 15 площадках

Роль аналитика 1С. Аналитик 1С является связующим звеном между бизнесом и продуктами компании “1С”. Их задача – совместить бизнес-процессы и технологии, чтобы сделать компанию более эффективной и прибыльной. Основной принцип работы аналитика 1С – это анализ, планирование и внедрение решений “1С” для автоматизации бизнес-процессов.

Значение в современном бизнесе 

В условиях современного рынка, где конкуренция постоянно увеличивается, компании стремятся оптимизировать свои процессы и повысить эффективность работы. Именно здесь на сцену выходят аналитики 1С. Их задача – изучить особенности бизнеса компании, выявить проблемы и потребности, а затем разработать и внедрить решения на базе продуктов “1С”, которые помогут бизнесу развиваться и приносить больше прибыли.

Основные обязанности 1С-аналитика 

Специалисты в области 1С выполняют ряд ключевых функций.

  • Консультирование клиентов. Они консультируют клиентов по возможностям продуктов “1С” для автоматизации бизнес-процессов и уточняют требования к продукту.
  • Анализ бизнес-процессов. Аналитики 1С изучают бизнес-процессы компании, выявляют проблемы и потребности клиента.
  • Проектирование решений. На основе анализа, они разрабатывают концепции автоматизации и создают технические задания для разработчиков.
  • Координация разработки. Аналитики 1С устанавливают задачи для разработчиков и контролируют процесс разработки.
  • Тестирование и сопровождение. Они проводят тестирование системы, обеспечивают ее интеграцию с другими системами и обучают сотрудников компании работать с новой системой.

Пример работы аналитика 1С 

Допустим, большая компания решает оптимизировать учет и управление своими ресурсами. Аналитик 1С начинает с анализа текущих бизнес-процессов, выявляет слабые места в учете и управлении, а также собирает требования от руководства компании. Затем он разрабатывает план внедрения продукта “1С.Управление предприятием”, который включает в себя настройку системы под требования компании, обучение сотрудников и сопровождение после внедрения. В результате компания получает более эффективные и прозрачные бизнес-процессы.

Требования к аналитику 1С Чтобы успешно работать в этой области, аналитику 1С необходимо.

  • Знать продукты “1С” и понимать их возможности.
  • Обладать базовыми знаниями в экономике и финансовом анализе.
  • Уметь описывать бизнес-процессы с помощью нотаций, таких как BPMN или IDEF0.
  • Иметь навыки визуализации информации и работать с инструментами, такими как MindManager или Miro.
  • Понимать процессы внедрения и сопровождения продуктов “1С”.
  • Уметь настраивать и интегрировать программное обеспечение.

Функции и рабочее место Аналитик 1С может работать как внутри компании, так и как внешний консультант. Он взаимодействует с руководством компании, разработчиками и конечными пользователями. Рабочее место аналитика 1С включает офисную среду, но также может включать в себя выезды к клиентам.

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

Основным инструментом аналитика 1С является компьютер, на котором установлены необходимые программы, включая продукты “1С”, инструменты анализа данных, текстовые редакторы и программы для визуализации бизнес-процессов. Аналитик также должен иметь доступ к базам данных и информации о клиентах.

Заключение

В итоге, аналитик 1С играет ключевую роль в мире бизнес-автоматизации, обеспечивая эффективное внедрение и использование продуктов “1С” в компаниях. Его аналитические и технические навыки, а также умение работать с клиентами делают его востребованным специалистом в современном бизнесе. Если вы готовы развивать свои компетенции в этой области, то карьера аналитика 1С может стать вашим путем к успешной профессиональной деятельности.

Должностные обязанности Ведущего аналитика

Должностная обязанность Ведущего Аналитика

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

— Высшее образование в области статистики, экономики, математики или аналогичной области.
— Значительный опыт работы в анализе данных и управлении аналитическими проектами.
— Глубокое понимание методов анализа данных и статистических моделей.
— Опыт работы с аналитическими инструментами, такими как SQL, R, Python или Tableau.

— Руководство командой аналитиков и координация работы по анализу данных.
— Разработка стратегии анализа данных, методологии и инструментов аналитики.
— Проведение анализа данных для выявления трендов, проблем и возможностей.
— Создание отчетов и презентаций с аналитическими выводами и рекомендациями.
— Сотрудничество с другими отделами компании для предоставления аналитической поддержки.

Ведущий Аналитик отчитывается перед руководством компании о проведенном анализе данных, представляет отчеты с аналитическими выводами и рекомендациями.

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

Критерии эффективности деятельности и ответственность:

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

Подбор Ведущего Аналитика в кадровом агентстве «ФАВОРИТ»

Для подбора опытного и эффективного Ведущего Аналитика рекомендуется обратиться в кадровое агентство «ФАВОРИТ». Наше агентство с многолетним опытом в подборе профессиональных аналитиков поможет найти подходящего специалиста для вашей компании. Для получения дополнительной информации о наших услугах, пожалуйста, свяжитесь с нами по телефону +7 (495) 988-55-25 или оставьте запрос на сайте favorit.pro в кадровом агентстве «ФАВОРИТ».

Лучший способ понять теорию — получить больше опыта в разных проектах. Для системных и бизнес-аналитиков я постоянно показываю подходы к работе через публикацию разборов задач: БД, API, Интеграции, требования, и все, что связано с проектированием систем.

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

Проект

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

Все примеры в статье будут связаны с этим проектом.

Общий подход к работе системного аналитика

01 Знакомство с бизнес-контекстом и бизнес-требованиями, их уточнение

Во‑первых, что такое бизнес‑контекст? Это как фон, на котором мы пытаемся понять нашу задачу. В нашем случае, это может быть, например, понимание того, как сообщество общается сейчас, какие у него проблемы и какие цели оно преследует. Здесь мы можем поговорить с руководством сообщества, пообщаться с его действующими участниками, изучить их текущие способы общения — социальные сети, форумы, вебинары и так далее. Либо просто получить уже собранную информацию с описанием работы сообщества сейчас — это AS IS (описание «как есть» для проекта).

Теперь, что такое бизнес‑требования? Это то, что бизнес хочет от будущей системы. В нашем случае, это может быть, например, желание сделать процесс регистрации на вебинары проще и удобнее, или желание собрать всю информацию из разных соцсетей в одном месте. Бизнес‑требования мы также обычно собираем на встречах с заказчиком, проводим интервью и обсуждения. Это To Be — как должно быть в результате разработки.

Важно понимать, что первоначально собранные требования часто бывают не полными или не точными.

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

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

Пример списка процессов AS IS к автоматизации

Ведение списка контактов
1. Сбор контактов при регистрациях на вебинары. Информация попадает в Битрикс24, Telegram-бот сайта, Email-лист контактов.
2. Участники Telegram-каналов GetAnalyst
3. Участники YouTube-каналов GetAnalyst
4. Сбор контактов при обращении по вопросам обучения

Вебинары
1. Публикация анонса в Telegram-каналах
2. Рассылка анонса через Email
3. Передача ссылок на вебинарные комнаты
4. Выдача подарков на вебинарах

Уведомления о событиях по Email / в Telegram GetAnalyst
1. Приглашения на бесплатные вебинары
2. Напоминания о бесплатных вебинарах
3. Передача ссылок на вебинарные комнаты

Больше в посте про бизнес-процессы AS IS.

Пример подробного описания процесса AS IS

Ведение контента в TG-канале для опытных аналитиков и его

Роли:
• Администратор канала — публикация и подтверждение основного контента в канал
• Команда — разрешены к публикации только служебные собщения (напоминания о вебинарах по шаблонам), некоторые нешаблонные сообщения должны получить подтверждение перед публикацией

  1. Написание текста поста. Текст может содержать ссылки на внешние ресурсы, выделения, курсив и другие возможности стандартного редактора в Telegram. Также есть сообщения в которых есть ссылки на видео из YouTube канала.

  2. Добавление одного или нескольких изображений к посту, при необходимости.

  3. Назначение даты и времени публикации.

  4. Проверка отложенного поста в списке «Ожидает публикации».
    4.1. Пост может быть изменен. Это происходит часто, т.к. до публикации посты шлифуются по 2-3 раза при перечитывании.
    4.2. Пост может быть удален и создан заново из-за проблем с картинками и файлами, выявленными при проверке.
    4.3. Пост может быть перепланирован на другое время.

  5. Пост публикуется.
    5.1. Текст может быть отредактирован после публикации, т.к. бывают опечатки или обновления.

02 Определение ролей пользователей и приложений. Верхнеуровневое проектирование архитектуры

Определение ролей пользователей и приложений

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

Участники, например, хотят легко регистрироваться на вебинары и читать новости. Организаторы вебинаров хотят удобно запланировать и анонсировать событие. Модераторы хотят следить за общением внутри сообщества и модерировать его при необходимости. Наша задача — понять и описать все эти роли и их потребности.

По итогам получится список ролей и пользовательские требования To Be для каждой из них.

Верхнеуровневое проектирование архитектуры

Сначала выделяем компоненты системы — отдельные приложения, сервисы:

  • сервер Backend, который будет обрабатывать запросы от приложения, и может включать в себя подсистемы (сервисы, микросервисы),

  • база данных для хранения информации о пользователях, вебинарах и новостях,

  • внешние системы — источники данных, из которых надо получать данные и в которые их надо передавать (интеграции).

Для визуализации архитектуры можно использовать нотацию C4.

Примеры по проектированию архитектуры в нотации C4

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

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

03 Выделение и описание основных сценариев работы с системой

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

Use Case

Для описания сценариев очень удобно использовать формат use case. Use case — это описание того, как система и пользователи взаимодействуют друг с другом для достижения какой-то цели. Use case включает в себя не только последовательность действий, но и роли, которые участвуют в этом взаимодействии, и возможные альтернативные сценарии.

Основное удобство формата use case в том, что он позволяет представить сценарии взаимодействия с системой в простой и понятной форме. Use case показывает, какие роли участвуют в сценарии, что они делают, и как система на это реагирует. Это помогает всей команде лучше понять, как должна работать система, и учесть все возможные варианты взаимодействия пользователей с системой.

04 Проработка альтернативных сценариев

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

На примере мобильного приложения для сообщества. Мы уже описали основной сценарий «Регистрация на вебинар», где пользователь успешно зарегистрируется на интересующий его вебинар. Но что, если вебинар уже прошел? Или если пользователь уже зарегистрировался на этот вебинар? Или если подключение к интернету пропало во время регистрации?

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

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

05 Задачи на дизайнера

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

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

Иногда системный аналитик рисует макеты, используя Figma, Miro, Draw.io, Axure RP Pro или другие инструменты.

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

Важно! Про макеты на ошибки

Неоднократно сталкивалась с ситуацией, когда работу с дизайнером завершили, во всю идет разработка, а макеты на ошибки отрисовать забыли.

Важно учесть, что в постановке задачи на дизайнера должны быть перечислены не только экраны для Happy Path (счастливого пути работы приложения), но и для отображения ошибок.

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

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

06 Определение ключевых данных: сущности и их свойства

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

Вернемся к нашему примеру мобильного приложения для сообщества. Основными сущностями в нашем случае могут быть «Пользователь», «Вебинар» и «Новость». У каждой из этих сущностей будут свои свойства. Например, у «Пользователя» могут быть свойства «Имя», «Email», «Дата регистрации», и т.д. У «Вебинара» — «Название», «Дата и время», «Описание», «Организатор», и так далее.

Также мы должны определить, как эти сущности связаны друг с другом. Например, «Пользователь» может быть зарегистрирован на одном или нескольких «Вебинарах». Эта информация важна, потому что она поможет нам понять, как должна быть организована база данных нашего приложения.

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

От того, насколько продуманно будет создана БД и определены сущности, зависит масштабируемость системы в будущем.

07 Задачи на доработку Базы Данных

Прежде чем программисты начнут разрабатывать методы Backend, им нужно подготовить базу данных.

  • создать новые таблицы,

  • добавить поля в существующие таблицы,

  • сделать миграции данных (перенос и автозаполнение),

  • иногда поменять типы данных, удалить лишние поля и так далее.

Для этого аналитик на основе выделенных сущностей сначала проектирует логическую или физическую модель базы данных (если работа с реляционной БД), а затем ставит задачи на разработчиков:

Шаблон Confluence и инструкция

08 Задачи на подготовку тестовых данных

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

Эта задача может быть сделана как системным аналитиком, так и смело передана на тестировщика.

Например, в случае нашего приложения для сообщества, мы можем создать несколько тестовых «Пользователей» с разными параметрами — с корректными и некорректными email’ами, зарегистрированными на разное количество «Вебинаров», и т. д. Мы также можем создать несколько тестовых «Вебинаров» и «Новостей» с различными свойствами.

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

09 Задачи на разработку методов Backend (методов API)

В работе приложений существует нечто, что помогает передавать данные между разными частями системы, например, между пользовательским интерфейсом (фронтендом) и сервером (бекендом). Это называется API, или Application Programming Interface.

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

Для каждого метода API, системный аналитик должен определить, какие данные он принимает на вход (например, данные для регистрации нового пользователя), и что он возвращает на выход (например, подтверждение успешной регистрации).

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

Пример задачи на бэкенд — шаблон постановки задачи + инструкция

10 Задачи на фронтенд / мобильные

Фронтенд и мобильная разработка – это та часть работы, которую видит и непосредственно использует конечный пользователь. В нашем случае это мобильное приложение для сообщества, где пользователи могут регистрироваться на вебинары и следить за новостями.

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

Вот пример таких задач:

  1. Создание экрана регистрации на вебинар.

  2. Отображение списка доступных вебинаров.

  3. Создание уведомлений о предстоящих вебинарах.

  4. Добавление возможности читать новости сообщества в приложении.

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

Пример задачи на фронтенд — шаблон постановки задачи

11 Задачи на тестирование

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

Допустим, в случае нашего приложения для сообщества, задачи могут выглядеть так:

  1. Проверить, происходит ли корректная регистрация пользователя на вебинар.

  2. Убедиться, что новости сообщества отображаются правильно и актуальны.

  3. Проверить работу уведомлений о предстоящих вебинарах.

  4. Протестировать работу приложения на разных устройствах и разных версиях операционной системы.

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

12 Задачи на сохранение важных артефактов по документации после разработки — документация

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

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

В случае нашего приложения для сообщества, системный аналитик может сохранить следующую документацию:

  1. Документы, описывающие функциональные требования и пользовательские сценарии.

  2. Диаграммы и схемы, включая C4 диаграммы архитектуры системы и Use Case диаграммы.

  3. Документы с описанием ключевых данных, сущностей и их свойств.

  4. Документацию API и описание логики работы методов.

  5. Документы с результатами тестирования и проблемами, обнаруженными в процессе разработки (особенности и известные проблемы).

Все это может быть собрано в ранее приведенных шаблонах требований для Confluence.

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

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

Про процесс документирования:

Применение описанного подхода на практике

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

Подборка моих блогов с теорией + примерами требований + диаграмм + постановок задач: здесь. В ней вы найдете шаблоны Сonfluence, структуру документов и примеры описаний для каждого этапа работы аналитика над задачей.

Заключение

Это общий подход. Он адаптируется в зависимости от типа задачи и проекта. Я его придерживаюсь, чтобы не упустить шаги по проработке требований и точно определить весь список задач, которые нужно создать и распределить на команду.

--------------------------------
(наименование организации)
УТВЕРЖДАЮ

ДОЛЖНОСТНАЯ ИНСТРУКЦИЯ
------------------------------
(наименование должности)
00.00.0000               N 000
---------  -------------------
(подпись)  (инициалы, фамилия)
Аналитика                         00.00.0000

1.1. Аналитик относится к категории специалистов.

1.2. На должность:

— аналитика принимается лицо, имеющее высшее профессиональное образование, без предъявления требований к стажу работы;

— аналитика II категории принимается (переводится) лицо, имеющее высшее профессиональное образование и стаж работы по направлению профессиональной деятельности не менее 5 лет, в том числе в должности аналитика не менее 2 лет;

— аналитика I категории принимается (переводится) лицо, имеющее высшее профессиональное образование и стаж работы по направлению профессиональной деятельности не менее 10 лет, в том числе в должности аналитика II категории не менее 5 лет.

1.3. Аналитик должен знать:

— законы и иные нормативные правовые акты в области осуществления аналитической деятельности;

— порядок выработки практических рекомендаций;

— методы сбора, оценки и анализа информации;

— основы экономики, организации производства, труда и управления;

— основы трудового законодательства;

— Правила внутреннего трудового распорядка;

— правила охраны труда и пожарной безопасности;

1.4. Аналитик в своей деятельности руководствуется:

    - Положением о _______________________________________________________;
(наименование структурного подразделения)

— настоящей должностной инструкцией;

    - _____________________________________________________________________
(иными актами и документами, непосредственно связанными
__________________________________________________________________________.
с трудовой функцией аналитика)
1.5. Аналитик подчиняется непосредственно _____________________________
__________________________________________________________________________.
(наименование должности руководителя)

1.6. В период отсутствия аналитика (отпуска, болезни, пр.) его обязанности исполняет работник, назначенный в установленном порядке, который приобретает соответствующие права и несет ответственность за неисполнение или ненадлежащее исполнение обязанностей, возложенных на него в связи с замещением.

2. Функции

2.1. Проведение аналитических исследований.

2.2. Подготовка и оформление отчетной и учетной документации.

3. Должностные обязанности

Аналитик исполняет следующие обязанности:

3.1. Организует аналитическое и методическое обеспечение проведения исследовательских работ.

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

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

3.4. Составляет необходимую отчетную документацию.

3.5. Координирует деятельность соисполнителей при совместном выполнении работ с другими структурными подразделениями организации.

    3.6. _________________________________________________________________.
(иные обязанности)

4. Права

Аналитик имеет право:

4.1. Участвовать в обсуждении проектов решений руководства организации.

4.2. По согласованию с непосредственным руководителем привлекать к решению поставленных перед ним задач других работников.

4.3. Запрашивать и получать от работников других структурных подразделений необходимую информацию, документы.

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

4.5. Требовать от руководства организации оказания содействия в исполнении должностных обязанностей.

    4.6. _________________________________________________________________.
(иные права)

5. Ответственность

5.1. Аналитик привлекается к ответственности:

— за ненадлежащее исполнение или неисполнение своих должностных обязанностей, предусмотренных настоящей должностной инструкцией, — в порядке, установленном действующим трудовым законодательством Российской Федерации;

— за правонарушения и преступления, совершенные в процессе своей деятельности, — в порядке, установленном действующим административным, уголовным и гражданским законодательством Российской Федерации;

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

6. Заключительные положения

    6.1.   Настоящая   должностная   инструкция   разработана   на   основе
Квалификационной характеристики   должности   "Аналитик"  (Квалификационный
справочник  должностей  руководителей,  специалистов  и   других  служащих,
утвержденный Постановлением Минтруда России от 21.08.1998 N 37), __________
__________________________________________________________________________.
(реквизиты иных актов и документов)
6.2.   Ознакомление   работника  с  настоящей  должностной  инструкцией
осуществляется при приеме на работу (до подписания трудового договора).
Факт   ознакомления   работника  с  настоящей  должностной  инструкцией
подтверждается ____________________________________________________________
(росписью в листе ознакомления, являющемся неотъемлемой
___________________________________________________________________________
частью настоящей инструкции (в журнале ознакомления
___________________________________________________________________________
с должностными инструкциями); в экземпляре должностной инструкции,
__________________________________________________________________________.
хранящемся у работодателя; иным способом)

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

5 главных документов аналитика

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

  • Документ бизнес-требований (BRD, Business Requirements Document);
  • ТЭО (Технико-Экономическое обоснование, бизнес-кейс);
  • Спецификация требований к решению (ТЗ, Техническое задание);
  • Проект решения;
  • Программа и методика испытаний (ПМИ).

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

Основы бизнес-анализа: вход в профессию для начинающих

Код курса
INTRO
Ближайшая дата курса

30 сентября, 2024

Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.

Документ бизнес-требований

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

Обычно BRD (Business Requirements Document) разрабатывает бизнес-аналитик, а основными потребителями изложенной в нем информации являются Заказчик, Менеджер проекта и Системный аналитик. Этот документ создается в самом начале любого проекта или даже на стадии предпроектного обследования (discovery) и содержит как минимум следующие пункты:

  • Краткое описание проекта;
  • Цели проекта;
  • Бизнес-контекст текущей ситуации (as is);
  • Вернеуровневое видение желаемой ситуации (as to be), включая видение решения;
  • Границы и содержание проекта (scope);
  • Бизнес-требования;
  • Ключевые стейкхолдеры;
  • Главные требования стейкхолдеров;
  • Ограничения проекта.

При разработке документа пригодятся следующие техники бизнес-анализа:

  • BACCM (Business Analysis Core Concept Model) – модель базовых понятий бизнес-анализа, которая позволяет определить границы и содержание проекта, ответив ответы на 6 вопросов: что включает Изменение, какова Потребность, какое будет Решение, кто Стейкхолдеры, какова ожидаемая Ценность, каков Контекст.
  • Канва бизнес-модели и цепочка создания ценности;
  • CATWOE;
  • Анализ стейкхолдеров;
  • Бенчмаркинг и анализ рынка;
  • Причинно-следственный анализ (диаграмма Исикавы, метод 5Why);
  • Нотации моделирования бизнес-процессов (IDEF0, BPMN, EPC);
  • Анализ бизнес-правил, в т.ч. DMN-модели.

Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)

Код курса
MODP
Ближайшая дата курса

7 октября, 2024

Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.

Технико-экономическое обоснование (ТЭО)

Документ технико-экономического обоснования или бизнес-кейс нужен, чтобы подтвердить целесообразность проекта, обосновать его необходимость с точки зрения бизнес-контекста, оценить экономическую выгоду от реализации и дать исходную информацию для старта. Бизнес-аналитик разрабатывает такой документ для Заказчика, Менеджера проекта и Спонсор или других ключевых лиц, принимающих решения (ЛПР) о старте проекта. Обычно такой документ создается в начале проекта или на стадии предпроектного обследования (discovery). ТЭО особенно необходимо, если проект является крупной инициативой, предполагает существенные инвестиции ресурсов (время, деньги, люди) и включает много компонентов (процессов, организационных структур и информационных систем). ТЭО должно включать следующие пункты:

  • Описание бизнес-потребности;
  • Анализ текущей ситуации;
  • Описание будущей ситуации с точки зрения финансов и рисков;
  • Варианты решения (альтернативы);
  • Критерии выбора решения;
  • Сравнение альтернатив, включая финансовые показатели и риски;
  • Выбор наиболее оптимальной альтернативы;
  • Необходимые для реализации ресурсы;
  • План реализации (ключевые этапы проекта, зависимости, роли и задачи участников).

Подробнее о том, что именно представляет собой этот документ я писала здесь. Чтобы не повторяться, перечислю техники, которые используются при разработке ТЭО:

Основы бизнес-анализа: вход в профессию для начинающих

Код курса
INTRO
Ближайшая дата курса

30 сентября, 2024

Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.

Спецификация требований или техническое задание (ТЗ)

ТЗ необходимо, чтобы описать функциональные и нефункциональные требования к решению с детализацией, достаточной для его проектирования и реализации. Обычно такой документ составляет системный аналитик на основании BRD или концепции решения от бизнес-аналитика. Основной целевой аудиторий документа ТЗ являются эксперты доменной области, представители Заказчика и члены команды реализации (Архитектор, Разработчик, Тестировщик, Специалист по внедрению).

Разработку технического задания можно начать после одобрения документа бизнес-требований и ТЭО. Точный состав спецификации требований регламентируется стандартом, которому она должна соответствовать, например, ГОСТ 34.602-2020, ГОСТ 19781-90, SRS по IEEE 830-1998, ISO IEEE 29148-2011 или внутренний шаблон ТЗ. В любом случае, этот документ должен включать следующие разделы:

  • цели и назначение решения;
  • характеристика объектов внедрения, например, краткое описание текущих бизнес-процессов (as is) и информационных систем;
  • функциональные требования;
  • модели данных (концептуальные или инфологические);
  • нефункциональные требования, включая ограничения;
  • переходные требования, т.е. как подготовить объект внедрения к вводу решения;
  • требования к документированию.

Помимо вышеперечисленных практик и подходов, для разработки ТЗ используются следующие техники системного и бизнес-анализа:

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса

16 сентября, 2024

Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.

Проект решения

Как я недавно отмечала здесь, одних только требований, упакованных в полное и консистентное ТЗ, недостаточно для реалиазации. Необходимо материализованное представление дизайна решения, которое будет удовлетворять этим требованиям. Проект должен описывать компоненты логической и физической архитектуры решения, включая рекомендуемый стек технологий. Обычно такой документ составляет Архитектор или Системный аналитик, обладающий необходимыми для этого компетенциями. Именно проект решения лежит в основе постановок задач на реализацию, т.е. потребителями информации, изложенной в этом документе являются Разработчик и Тестировщик. Причем роль Разработчик относится не только к программисту, но и к UI/UX-дизайнеру.

Разработать проект решения можно после после одобрения ТЗ, отразив точки зрения на архитектуру решения, указанные в ГОСТ Р 57193-2016, SEBoK, ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011. Для этого документ должен как минимум содержать следующие пункты:

  • контекст проектируемой ИС;
  • архитектурная категория;
  • структура элементов системы;
  • взаимодействие элементов архитектуры между собой и реакции в ответ на внешние события;
  • протоколы сетевого и межсистемного взаимодействия, в т.ч. по веб-API;
  • форматы и схемы данных;
  • стек технологий;
  • физические схемы моделей баз данных для выбранных СУБД;
  • ограничения и подходящие конфигурации настройки компонентов системы;
  • порядок реализации спроектированной архитектуры, основанный на технических зависимостях одних компонентов от других.

При разработке проекта решения пригодятся следующие техники:

  • Прототипирование;
  • UML-диаграммы и схемы С4;
  • Документирование структуры данных и системных вызовов, например, в виде спецификации OpenAPI для REST API или AsyncAPI для асинхронной интеграции.

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

Основы архитектуры и интеграции информационных систем

Код курса
OAIS
Ближайшая дата курса

26 августа, 2024

Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.

Программа и методика испытаний (ПМИ)

Этот документ содержит одну или несколько методик испытаний объекта поставки, включая перечень проверок и допустимых результатов, чтобы показать, насколько результат отвечает требованиям ТЗ. Обычно ПМИ совместно разрабатывается бизнес-аналитиком и системным аналитиком, если эти роли разделены между разными людьми. Потребителями изложенной в ПМИ информации являются Заказчик, Менеджер проекта и Тестировщик. Очень важно, чтобы ПМИ была согласована с представителем Заказчика, который отвечает за приемку, чтобы во время приемочных испытаний не возникло желания проверить работу решения в ранее неизвестных условиях, т.к. подобный тест не пройдет в 99% случаях .

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

По ГОСТ Р 59795-2021 состав ПМИ для автоматизированной системы включает следующие пункты:

  • краткое описание объекта испытаний (наименование системы и ее компонентный состав);
  • цель испытаний (цели и задачи, которые должны быть достигнуты и решены в процессе испытаний);
  • общие положения (регламенты, место и время испытаний; организации, участники, результаты предыдущих испытаний);
  • объем испытаний (этапы испытаний и проверок, нормативные количественные и качественные значения показателей, последовательность проведения и режима испытаний, работ по завершении испытаний и порядок их проведения);
  • условия и порядок проведения испытаний, включая меры обеспечения безопасности и требования к участникам испытаний;
  • материально-техническое обеспечение испытаний, включая задачи и обязанности участников по их поставке и подготовке. Например, для приемочного тестирования ИС в этом пункте может быть указано, на чьей стороне (Заказчика или Исполнителя) разворачивается тестовый стенд и кто отвечает за его работоспособность.
  • метрологическое обеспечение испытаний, включая задачи и обязанности участников по их поставке и подготовке. К примеру, для ИС в этом разделе ПМИ можно указать, какой бенчмаркинговый тест будет использоваться для оценки производительности, а также какими инструментами будут логироваться и оцениваться результаты.
  • отчетность — список отчетных документов, включая перечисление участников, которые должны их разработать, согласовать и утвердить, а также сроки их оформления. Обычно отчетными документами являются акт и отчет о результатах испытаний, акт технического состояния системы после испытаний.
  • приложения – методики испытаний, математические и прочие модели для оценки качества объекта испытаний.

Разработка ТЗ на информационную систему по ГОСТ и SRS

Код курса
TTIS
Ближайшая дата курса

16 сентября, 2024

Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.

Для наглядности, зачем нужен каждый из рассмотренных документов, и что он включает я составила таблицу, которую можно использовать в качестве шпаргалки для начинающего аналитика. Скачивайте и пользуйтесь на здоровье!)

Ключевые артефакты аналитика
Ключевые артефакты аналитика

А научиться составлять все рассмотренные и другие артефакты, включая полезные техники вам помогут мои курсы в Школе прикладного бизнес-анализа на базе лицензированного учебного центра обучения и повышения квалификации системных и бизнес-аналитиков в Москве:

Практическое руководство примеры и шаблоны

25 рабочих гипотез для увеличения конверсии на 40%

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

На что обратить внимание? Каким бы ни был специалист – товарным, финансовым, системным – для сбора и обработки данных ему понадобится освоить определенные инструменты: от дашбордов до аналитических сервисов.

Кто такой аналитик

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

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

кто такой аналитик

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

  • игрушку «Железный человек» часто покупают в паре с образом «Капитан Америка»;
  • а героя «Дарт Вейдер» – вместе с «Люк Скайуокер».

Вы заинтересовались данными и решили добавить в магазин новые рекомендации. Так можно проверить гипотезу о том, что модели, продающиеся в паре, могут существенно увеличивать прибыль. Вы оценили, что продажи смогут повыситься на 7 %.

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

23 A/B теста для B2B, которые повысили конверсию сайта в 4 раза

  • 10 критических ошибок В2В маркетинга
  • 5 полезных инструментов для В2В

Background image
Background image

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

Оцените статью
Аналитик-эксперт
Добавить комментарий