Артефакты аналитика

1.

Артефакты
аналитика

2.

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

3.

С кем и как взаимодействует аналитик?
Дизайнеры
Разработчики
Тестировщики
Пользователи
системы
Руководитель
проекта
АНАЛИТИК
Руководители
со стороны
заказчика
IT-специалисты
заказчика
Менеджеры,
технологи

4.

5.

Что такое техническое задание?
Техническое задание (англ. requirements document) — документ, где описаны цель
проекта, из каких частей он состоит, какие результаты ожидаются и каким способом
их можно достичь.
Иногда ТЕХНИЧЕСКОЕ ЗАДАНИЕ называют СПЕЦИФИКАЦИЕЙ ТРЕБОВАНИЙ (англ. Software Requirements
Specification, SRS), но между этими документами есть отличия.
Спецификация, как и ТЗ, содержит информацию
о требованиях к проекту, но:
требования детализированы до системного уровня;
структура документа более строгая;
объём документации больше.
Иностранные компании предпочитают работать именно со спецификациями,
а в России больше распространены ТЗ, структура которых адаптируется под
проект или компанию.

6.

Кто оформляет техническое задание
Каждый участник вносит свой вклад в документацию:
1.Бизнес-аналитик проводит анализ бизнес-потребностей и требований заказчика, определяет
функциональные и нефункциональные требования, взаимодействует с заказчиком и другими
заинтересованными сторонами.
2.Системный аналитик занимается анализом и описанием решения с точки зрения системы. Для этого он
взаимодействует с бизнес-аналитиком и разработчиками.
3.Заказчик передаёт свои требования и ожидания от проекта, даёт обратную связь и утверждает
окончательное ТЗ.
4.Разработчики и архитектор системы предлагают технические решения, оценивая реализуемость
требований на основании структуры, возможностей и ограничений системы.
5.Дизайнеры могут указать на важные требования относительно дизайна, цветовой схемы, компоновки
элементов и взаимодействия с пользователем.
6.Тестировщики помогают определить требования к тестированию и проверке функциональности проекта.
Они могут предложить варианты тестовых сценариев и требования к качеству, которые необходимо учесть в
ТЗ.
7.Менеджер проекта согласовывает в ТЗ информацию о процессе разработки и следит за сроками выполнен
ия работ.

7.

Из чего состоит техническое задание?
1.Введение с общей информацией о проекте, его целях, контексте и описанием текущей проблемы или потребности.
2.Список участников проекта, то есть тех, кто принимает участие в проектировании решения. Зачастую достаточно
заказчика, менеджера проекта, ответственного аналитика и разработчика.
3.Глоссарий с указанием терминов и сокращений, которые используются в документации, — так читатели ТЗ будут в
едином контексте.
4.Основные требования: список основных функций, возможности, ограничения и взаимодействие с другими система
ми, а также требования к производительности, безопасности, масштабируемости и другим особенностям продукта.
5.Требования к документации, где фиксируется, что будет разработан пакет руководств-инструкций, ПМИ, протокол
ПСИ и так далее.
6.Архитектура и дизайн. В этой части — общая архитектура системы, используемые технологии, платформы,
инструменты, описание модулей, интерфейсов и так далее.
7.Интеграции и взаимодействия, где указаны требования и протоколы для взаимодействия с другими системами,
API, форматы данных и схемы коммуникации.
8.Порядок контроля и приёмки, который содержит тестовые сценарии, ожидаемые результаты и критерии приёмки.
9.Стадии и этапы разработки, а также сроки их выполнения.
10.Возможные риски, где описаны сложности или негативные последствия, которые могут повлиять на проект. Тут
же указаны планы по их снижению или управлению.
11.Приложения с артефактами в виде диаграмм, прототипов, описания API и другой документации.

8.

Стандарты оформления технических заданий

9.

Примеры
спецификаций
и ТЗ

10.

Структура документа
ГОСТ 34.602 предлагает следующую структуру разделов документа Техническое
задание:
• общие сведения;
• назначение и цели создания (развития) системы;
• характеристика объектов автоматизации;
• требования к системе;
• состав и содержание работ по созданию системы;
• порядок контроля и приемки системы;
• требования к составу и содержанию работ по подготовке объекта автоматизации к
вводу системы в действие;
требования к документированию;
источники разработки
Подраздел «Цели создания системы» и раздел «Требования к системе» имеют
непосредственное отношение к отражению классификации требований.

11.

Соотнесение типов требований (Вигерс)
и ГОСТ 34.602

12.

Протоколы встреч;
Опросные листы;
Планы интервью;
Модели бизнес - про
цессов
Техническое задание
Постановка задач на
дизайн
(протоктипы, мокапы)
Постановка задач
на разработку
• ER-диаграмма;
• Sequence
диаграмма;
• Спецификация
OpenAPI;
Протокол демонастрации
функционала
Пользовательская
документация

13.

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

14.

Советы по началу работы в компании для
аналитика
1
Уточните у коллег, какие
артефакты являются
ключевыми в работе
Подробнее остановитесь на
этих артефактах, определите
формат, их жизненный цикл
3
2 Запросите доступы к
системам и трекерам
4 Смоделируйте для себя диаграммы
рабочего процесса.
Это можно сделать в виде обычной бло
к-схемы или UML диаграммы активност
и, главное условие – схема должна быт
ь понятна вам
5
Начните формировать словарь
терминов применяющихся при
работе над проектами организации,
если это необходимо
Каждая организация – это мини
социальная среда, у каждой своя
терминология
Определите зоны ответственности
каждого участника команды,
заказчиков и т д.

15.

Thanks !