Модуль 3. Структура технического задания: что включать и как формулировать
Цель модуля
Научиться правильно структурировать техническое задание (ТЗ) для проектов, связанных с системами управления данными: BI, DWH, MDM, DQ, Lakehouse и др. Понять, какие разделы должны присутствовать в ТЗ, как они связаны между собой, какие ошибки чаще всего совершаются при написании, и как должен выглядеть результат.
Роль и функции ТЗ в проекте
Техническое задание (ТЗ) — это центральный документ проекта, который связывает:
- цели бизнеса;
- требования пользователей;
- проектные ограничения;
- архитектурные и технические решения.
Он используется для:
- согласования ожиданий между бизнесом, ИТ и подрядчиком;
- фиксации зоны ответственности;
- оценки трудозатрат и стоимости работ;
- контроля выполнения проекта и проведения приемки.
Без ТЗ:
- невозможно провести объективную приемку;
- команда разработчиков теряет ориентиры;
- растут сроки, бюджеты и объём переделок;
- заказчик может быть недоволен, даже если всё "работает" — потому что ожидания не были формализованы.
Общая структура ТЗ
Ниже представлена рекомендуемая структура ТЗ для проектов по данным. Каждый раздел будет детально разобран в следующих пунктах:
- Общие сведения
- Цели и задачи проекта
- Область охвата и ограничения
-
Требования:
- функциональные
- нефункциональные
- к данным
- к архитектуре
- Пользователи и сценарии использования
- Архитектура и потоки данных
- План-график и этапы реализации
- Критерии приёмки и оценки успеха
- Риски и предпосылки
- Приложения (матрицы соответствия, шаблоны, глоссарий)
Общие сведения
Назначение документа
Этот раздел вводит читателя в контекст проекта и описывает, зачем составлен данный документ.
Пример:
Настоящее техническое задание описывает цели, требования, архитектуру и функциональность проекта по внедрению аналитической системы на базе BI и DWH. ТЗ служит основой для согласования задач между бизнесом, ИТ и подрядчиком.
Основные сведения о проекте
- Название проекта
- Инициатор
- Ответственный за проект (владелец продукта / руководитель)
- Подрядчик или исполнители (если уже известны)
- Дата составления
- Версия ТЗ (с возможностью последующего контроля изменений)
Формат: таблица или краткий блок в начале документа.
Уровень критичности и приоритет проекта
Если ТЗ формируется в рамках портфеля проектов, здесь указывается:
- принадлежность к стратегическим/тактическим инициативам
- связи с другими проектами
- временной приоритет (квартал, год, фаза)
Пример:
Проект является частью инициативы по цифровой трансформации блока "Финансы" и входит в стратегический портфель 2025 года. Связан с проектами автоматизации бюджетирования и внедрения MDM.
Контактные лица
|
Роль |
Имя |
Организация |
Контакты |
|
Инициатор |
Иванов И.И. |
АО "Компания" |
|
|
Владелец данных |
Петрова А.А. |
Финансовый отдел |
petrovа@corp.ru |
|
Архитектор |
Смирнов С.С. |
ИТ |
Цели и задачи проекта
Зачем этот раздел важен
Раздел "Цели и задачи проекта" определяет смысл всего ТЗ. Он показывает, зачем запускается проект, какие бизнес-проблемы он решает и какие конкретные результаты ожидаются. Хорошо сформулированные цели и задачи:
- помогают согласовать ожидания;
- определяют приоритетность требований;
- являются критерием для приёмки результатов проекта.
Как формулировать цели
Цель — это бизнес-ориентированное высказывание о том, какого результата должен достичь проект. Она должна быть:
- конкретной;
- измеримой;
- достижимой;
- релевантной для бизнеса;
- ограниченной по времени.
Это соответствует критериям SMART.
Примеры целей:
- Сократить срок подготовки управленческой отчетности с 3 до 1 дня к 1 сентября 2025 года.
- Повысить точность прогноза продаж до уровня MAE < 8% по ключевым SKU в регионе Москва.
- Централизовать справочник контрагентов для всех дочерних обществ компании к концу квартала Q2.
Как формулировать задачи
Задача — это конкретное действие или шаг, ведущий к достижению цели. Она может быть:
- аналитической (сбор требований, разработка витрины);
- технической (настройка ETL, разработка дашборда);
- организационной (обучение пользователей, переход на продуктив).
Задачи должны быть связаны с одной или несколькими целями.
Примеры задач:
- Настроить интеграцию между 1С и DWH по справочникам и фактам продаж.
- Разработать витрину "Продажи по SKU" с детализацией до региона и контрагента.
- Реализовать BI-дешборд с фильтрацией по регионам, SKU, менеджерам.
Формат представления целей и задач
Обычно этот раздел оформляется в виде таблицы или подзаголовков.
Пример таблицы:
|
Цель |
Задачи |
|
Повысить прозрачность складских остатков |
1. Построить витрину остатков\n2. Реализовать BI-дешборд с drill-down\n3. Настроить правила валидации DQ по датам поставок |
|
Сократить трудозатраты на формирование отчетности |
1. Автоматизировать выгрузку из 1С\n2. Построить витрину DWH.Accounting\n3. Настроить регламентную выгрузку отчетов в Excel и рассылку |
Частые ошибки
× Цель описывает действие, а не результат: "Настроить витрину" вместо "Сократить время подготовки отчётов".
× Цель не измерима: "Повысить качество данных" без указания, по каким метрикам.
× Цель звучит как средство: "Внедрить Power BI" вместо "Повысить прозрачность данных о продажах".
× Задачи не соотносятся с целями или дублируют друг друга.
Связь с остальными разделами ТЗ
- Цели определяют, зачем разрабатываются функции (связь с разделом 4);
- Задачи влияют на состав архитектуры (раздел 6);
- По целям оценивается успех проекта (раздел 8);
- Цели — основа для рисков и предпосылок (раздел 9).
Область охвата и ограничения
Что входит в область охвата
Этот раздел определяет, какие процессы, подразделения, данные, системы и функции попадают в сферу действия проекта. Он помогает избежать недопонимания между заказчиком и исполнителями, особенно в сложных организациях.
Примеры, что можно указать:
- Процессы: управление продажами, закупками, бюджетированием, логистикой
- Подразделения: коммерческий отдел, маркетинг, производство, HR
- Системы-источники: 1С ERP, SAP, Bitrix24, Excel, API внешних систем
- Периоды данных: загрузка данных начиная с 2022 года
- География: Россия и СНГ (без Азии и Европы)
Уточнение: если проект по DWH, BI или MDM — обязательно указать, какие справочники и какие факты входят.
Что исключается из области
Этот пункт описывает зоны, не входящие в текущий проект. Он особенно важен при параллельных инициативах или поэтапной реализации.
Примеры:
- BI по блоку HR — в отдельном проекте
- Подсистемы 1С:Документооборот и ЗУП — не входят
- Разработка ML-моделей не входит в состав ТЗ
- Интеграция с новым CRM не планируется в этом этапе
Чем чётче вы опишете, что исключено — тем меньше конфликтов ожиданий.
Влияние на архитектуру и команду
Формулировка области охвата влияет:
- на объём ETL-процессов;
- на количество витрин и отчётов;
- на тип и количество подключаемых источников;
- на список вовлечённых команд (например, нужно ли участие бухгалтерии, ИБ, отдела безопасности, внешнего подрядчика).
Формат оформления
Можно оформить как перечень или таблицу с колонками:
|
Категория |
Входит в проект |
Исключено |
|
Подразделения |
Финансовый отдел, логистика |
HR, юридический отдел |
|
Процессы |
Закупки, продажи, бюджетирование |
Производственное планирование |
|
Источники |
1С ERP, SAP, Excel, Bitrix |
Google Sheets, внешние API |
|
География |
РФ, Казахстан |
ЕС, США |
|
Данные |
За 2022–2025 |
Архив до 2021 года |
Частые ошибки
× Отсутствие описания области приводит к:
- конфликтам в финальной приёмке;
- дублированию инициатив;
- проблемам на этапе сбора данных;
- недовольству заказчиков: "А почему не сделали вот это?"
× Указана слишком широкая область: "все подразделения, все данные, вся история" — при этом нет ресурсов и сроков на это.
× Отсутствует раздел "исключено" — в результате подрядчик берёт на себя больше, чем планировалось.
Требования: функциональные, нефункциональные, к данным и архитектуре
Раздел требований — самый объёмный и технически насыщенный. Его задача — зафиксировать всё, что система должна уметь (функции), как она должна работать (нефункциональные параметры), что делать с данными, и какую архитектуру использовать. Этот блок должен быть написан максимально понятно как для аналитиков, так и для разработчиков.
Функциональные требования
Функциональные требования описывают:
- поведение системы (что она делает);
- интерфейсы взаимодействия (BI-дэшборды, витрины, загрузки);
- обработки и бизнес-логику (расчёты, фильтры, правила).
Формат: Можно оформить списком или таблицей с колонками:
- ID
- Название
- Описание
- Пользователь/роль
- Приоритет (обязательное/желательное)
Пример:
|
ID |
Название |
Описание |
Роль |
Приоритет |
|
FR-01 |
Дэшборд продаж |
Отображение выручки по SKU, каналу, дате, менеджеру с drill-down |
Аналитик |
Обязательное |
|
FR-02 |
Экспорт отчёта |
Возможность выгрузки в Excel отчёта по выручке и марже |
Финдиректор |
Обязательное |
|
FR-03 |
Рассылка алертов |
Автоматическая рассылка уведомлений при падении продаж |
Руководитель отдела |
Желательное |
Нефункциональные требования
Они описывают, как должна работать система:
- производительность (время отклика, частота обновлений);
- доступность (24/7, резервирование);
- масштабируемость;
- безопасность;
- удобство поддержки;
- требования к интерфейсам и UX.
Примеры:
- Время отклика при открытии BI-дашборда не более 5 секунд при объёме до 1 млн строк.
- Система должна быть доступна не менее 99,5% времени в месяц.
- Обновление витрин не дольше 30 минут после завершения ETL.
Ошибки: × Неуказанное поведение при сбоях и высоких нагрузках × Отсутствие SLA для администраторов и пользователей
Требования к данным
Эти требования фиксируют:
- источники данных и форматы (1С, Excel, REST API);
- поля и атрибуты (что именно нужно);
- периодичность загрузки;
- правила трансформации;
- требования к качеству (валидации, допустимые значения);
- версионность и историчность.
Пример:
- Из 1С ERP загружается таблица "РеализацияТоваровУслуг" по полям: Дата, Контрагент, Номенклатура, СуммаДокумента
- Загрузка ежедневная, в 02:00, полная
- Витрина должна сохранять историю (SCD2)
Для BI и DWH важно: какие справочники обязательны (контрагенты, товары, организации, сотрудники) и как они связаны.
Ошибки: × Описание "загружаем продажи" без указания полей, источника и логики × Отсутствие упоминания версионности справочников
Архитектурные требования
Определяют:
- тип архитектуры (ETL или ELT, DWH или Lakehouse, потоковая или пакетная);
- используемые технологии и платформы (MS SQL, ClickHouse, Hadoop, Apache Airflow);
- принципы построения (Data Vault, Kimball, корпоративная модель);
- среду исполнения (on-premises / облако);
- интеграцию с другими системами.
Пример:
- Архитектура — трёхуровневая: staging → ODS → DWH
- Технология: PostgreSQL + Apache Airflow + Metabase
- Поддержка Data Vault на слое DWH
- Интеграция с API SAP (REST), выгрузка из 1С через выгрузочные регламенты
Ошибки: × Описание архитектуры на уровне "сделать выгрузку из 1С и BI в Power BI" × Отсутствие формулировки формата витрин (granularity, меры, поля)
Пользователи и сценарии использования
Почему это важно
Понимание того, кто будет пользоваться системой и как именно — критически важно для определения функционала, интерфейсов, прав доступа и даже архитектуры. Этот раздел позволяет:
- учесть реальные потребности;
- избежать лишней сложности;
- адаптировать BI и DWH под конкретные кейсы, а не абстрактные задачи.
Типы пользователей
Раздел должен перечислять ключевые роли, которые будут взаимодействовать с системой. Например:
- Бизнес-пользователь — работает с отчётами, дашбордами, принимает решения
- Аналитик — настраивает фильтры, модели, сценарии, готовит презентации
- DWH-разработчик — проектирует витрины, пишет ETL, следит за данными
- BI-разработчик — создаёт визуализации, настраивает дашборды
- Администратор — управляет пользователями, доступом, мониторингом
Формат: таблица
|
Роль |
Описание |
Примеры задач |
|
Бизнес-пользователь |
Менеджер, принимает решения на основе отчётов |
Открыть дашборд, выбрать регион, экспортировать Excel |
|
BI-разработчик |
Создаёт визуальные компоненты, настраивает фильтры |
Построить витрину «Маржа», настроить KPI |
|
Администратор |
Следит за доступами, безопасностью и логами |
Добавить пользователя, проверить логи |
Сценарии использования (use cases)
В каждом проекте должно быть от 5 до 15 основных сценариев. Они описывают типовое поведение пользователя: с какой целью он заходит в систему, какие шаги выполняет и какой результат получает.
Пример сценария:
- Название: Просмотр отчёта по марже по менеджерам
- Актор: Руководитель отдела
- Предусловие: BI-система доступна, данные загружены
-
Шаги:
- Зайти в BI-систему
- Открыть дашборд «Выручка и маржа»
- Выбрать период, регион, канал
- Посмотреть маржу по менеджерам
- Выгрузить в Excel
- Ожидаемый результат: Получен список с маржой и выручкой по каждому менеджеру в Excel-файле
Хорошая практика — делать такие сценарии с бизнесом в виде скриншотов с подписями или user-story.
Альтернатива: формулировка в формате user-story:
Как [роль], я хочу [действие], чтобы [цель].
Пример:
Как руководитель региона, я хочу сравнить выручку по ключевым клиентам за 2 года, чтобы оценить LFL-рост.
Связь с функциональными требованиями
Каждый сценарий можно связать с функциональными требованиями.
Пример:
|
Use case |
Требования |
|
Просмотр отчёта по марже |
FR-01 (дашборд), FR-02 (экспорт), FR-03 (фильтры) |
|
Мониторинг остатков на складе |
FR-05 (витрина остатков), FR-08 (настройка фильтра по SKU) |
Эта связка позволяет понять, какие требования нужны для каких ролей и где возникают критические функции.
Частые ошибки
× Отсутствие описания пользователей приводит к созданию слишком технической или, наоборот, слишком простой системы
× Нет сценариев — непонятно, как именно будет использоваться система
× Игнорируются нестандартные роли (например, подрядчики, филиалы, контрагенты)
× Сценарии не проверяются на реальных данных — в итоге отчёты сложны, неинтуитивны и не дают ценности
Архитектура и потоки данных
Зачем нужен архитектурный раздел
Раздел, описывающий архитектуру и потоки данных, формирует технический фундамент проекта. Он позволяет:
- зафиксировать принципы построения и взаимодействия компонентов системы;
- визуализировать путь данных от источников до BI или других интерфейсов;
- обосновать выбор технологий и подходов;
- предвидеть ограничения и узкие места.
Этот раздел особенно важен при внедрении DWH, Lakehouse, MDM, Data Quality, а также при миграции с OLTP на аналитические решения.
Слои архитектуры
В проектах по данным чаще всего выделяют следующие уровни (слои):
- Источник (Source systems): ERP, CRM, 1С, Excel, внешние API
- Staging: приёмник "сырых" данных, без изменений
- Operational Data Store (ODS): очищенные, унифицированные данные, но без историзации
- DWH: аналитические витрины (факты, измерения, агрегации), может быть построен по Kimball или Data Vault
- BI/Presentation Layer: отчёты, дешборды, выгрузки, визуализация
В случае MDM добавляется слой мастер-данных и их маршрутизации В случае DQ — слой правил валидации, отчётов и механизмов исправления ошибок
Типовая архитектурная схема
Включается схема, на которой изображены:
- источники данных;
- каналы загрузки и обновления (ETL/ELT);
- хранилища (разделение на слои);
- BI-системы, порталы, API, Excel и др.
Пример описания:
Данные из 1С, Excel и SAP поступают в PostgreSQL через Apache Airflow. На уровне ODS они нормализуются и проверяются. Затем формируются витрины в DWH по моделям Kimball. BI реализован в Power BI с прямым подключением к DWH.
Для больших систем полезно добавить блоки:
- Kafka / stream ingestion
- Lakehouse (Data Lake + compute engine)
- ML pipeline (если применимо)
Потоки данных (data flow)
Этот раздел отвечает на вопрос: как именно и в каком виде данные перемещаются между компонентами.
Формат:
- Таблица по каждому источнику
- Диаграмма потока (data lineage, data movement)
Пример таблицы:
|
Источник |
Объекты |
Формат |
Загрузка |
Частота |
Примечание |
|
1С ERP |
Продажи, Контрагенты |
XML |
FTP → Airflow → PostgreSQL |
1 раз в сутки |
Форма РТ0001 |
|
Excel |
Планы продаж |
XLSX |
Email → Power Automate |
1 раз в неделю |
Ручной ввод |
|
SAP |
Закупки |
API |
REST → Airflow → DWH |
Раз в 4 часа |
Онлайн-интеграция |
Принципы архитектуры
Здесь указываются принятые в проекте принципы:
- модульность и масштабируемость;
- безопасность (разделение сред, доступ по ролям);
- устойчивость к сбоям (failover, SLA);
- открытые стандарты (JSON, REST, SQL);
- поддержка историчности (например, SCD2);
- минимум ручных операций.
Пример:
Все источники данных загружаются через Airflow в staging. На каждом этапе соблюдается инвариант: данные не перезаписываются, а только добавляются. Историчность обеспечивается через surrogate-ключи и флаг активности. BI не работает напрямую с источниками — только с DWH.
Частые ошибки
× Нет архитектурной схемы, всё описано текстом
× BI подключается напрямую к источникам (OLTP), без DWH — это создаёт риски нагрузки, ошибок и неустойчивых расчётов
× ETL-процессы не описаны, не понятно, как устроена актуализация данных
× В проект включены справочники, но отсутствует описание MDM-процессов или механизмов согласования
× В системе присутствует Lake или Data Lake, но не описаны правила доступа, шифрования, версионирования
План-график и этапы реализации
Назначение раздела
План-график проекта фиксирует:
- последовательность и продолжительность этапов работ;
- точки контроля и вехи (milestones);
- ответственных за каждый этап;
- зависимость задач между собой;
- формализованную дату завершения работ и границы приёмки.
Раздел обязателен для проектов с внешними подрядчиками, а также при поэтапной реализации DWH, BI, MDM, DQ, Lakehouse.
Формат представления
Рекомендуется использовать:
- диаграмму Ганта;
- таблицу с этапами, сроками, ответственными и результатами;
- описание логики переходов между этапами ("следующий этап начинается после подписания акта по предыдущему").
Пример таблицы:
|
Этап |
Длительность |
Сроки |
Ответственный |
Результат |
|
Сбор требований |
2 недели |
01.07–15.07 |
Аналитик |
Подписанный документ требований |
|
Архитектура и ТЗ |
3 недели |
16.07–05.08 |
Архитектор |
Утверждённое ТЗ и схема архитектуры |
|
Разработка ETL |
4 недели |
06.08–02.09 |
DWH-разработчик |
Рабочие пайплайны, тестовые загрузки |
|
Разработка BI |
3 недели |
03.09–24.09 |
BI-разработчик |
Дашборды, фильтры, отчёты |
|
Тестирование |
2 недели |
25.09–09.10 |
QA + Заказчик |
Подписанный протокол тестирования |
|
Ввод в эксплуатацию |
1 неделя |
10.10–17.10 |
Проектный менеджер |
Продуктивная среда + регламенты |
Типовые этапы для разных типов проектов
BI-система:
- Сбор требований (дашборды, метрики, пользователи)
- Проектирование интерфейсов
- Подключение к источникам или DWH
- Разработка визуализаций и логики
- Тестирование, пилот, обучение
DWH:
- Описание источников
- Разработка ETL-архитектуры
- Формирование слоёв staging/ODS/DWH
- Загрузка истории и настройка актуализаций
- Разработка витрин и экспортов в BI
MDM:
- Выявление мастер-объектов
- Согласование структуры атрибутов
- Настройка источников мастер-данных
- Разработка правил дедупликации и согласования
- Настройка механизмов публикации и версионирования
DQ:
- Каталогизация источников
- Выделение критичных наборов данных
- Формализация правил качества
- Построение витрин ошибок, алерты, отчёты
- Разработка интерфейса валидации
Зависимости между этапами
Некоторые этапы возможны только после завершения других:
- Разработка BI невозможна до завершения загрузки витрин
- Финальное тестирование возможно только после настройки SLA
- Разработка интерфейсов требует готовых справочников и данных
Это важно отразить в диаграмме или таблице, иначе проект затянется или будет переделываться.
Частые ошибки
× Слишком укрупнённые этапы без понятных критериев завершения
× Отсутствие фиксации сроков по ответственным (никто не несёт ответственности за просрочку)
× Несогласованные сроки при многокомандной реализации (BI → ETL → MDM → DevOps)
× Параллельное выполнение несовместимых этапов (разработка BI и загрузка данных без витрин)
Критерии приёмки и оценки успеха
Назначение раздела
Этот раздел определяет, как заказчик будет оценивать выполнение проекта и по каким параметрам система будет считаться внедрённой и соответствующей ТЗ. Приёмочные критерии служат «якорем» при спорах, доработках и закрытии этапов.
Форматы приёмки
- Акт приёмки этапа/проекта — официальный документ, подписываемый сторонами
- Протокол тестирования — перечень проверенных функций, сценариев и результатов
- Чек-листы — контрольные таблицы для тестов, заполнения вручную или автоматически
- Примеры отчётов — как должен выглядеть результат (дашборды, витрины, мастер-данные)
Типовые критерии приёмки
Функциональные:
- Все описанные требования (FR-01…FR-10) реализованы
- BI-дэшборды соответствуют согласованным макетам
- Витрины загружаются по расписанию, фильтры работают корректно
Нефункциональные:
- BI-отчёты открываются менее чем за 5 сек при 1 млн строк
- Время выполнения ETL не превышает 40 минут
- Система доступна 99,5% времени в течение месяца
К данным:
- Все поля и таблицы загружаются в полном составе
- Качество данных соответствует требованиям (DQ-001…DQ-015)
- Справочники содержат 100% актуальные данные по состоянию на дату приёмки
К архитектуре:
- Все источники подключены согласно схеме
- Данные передаются в staging → ODS → DWH без потерь и искажений
- BI не подключается напрямую к OLTP-источникам
Управление пользователями:
- Реализована ролевая модель: аналитики, пользователи, администраторы
- Ограничения доступа настроены и протестированы
Критерии успеха проекта (бизнес)
Важно отличать формальную приёмку от оценки успеха проекта. Последнее — это бизнес-метрика внедрения:
- Повысилась прозрачность контроля (было: 2 отчёта, стало: 12 интерактивных дашбордов)
- Сократилось время подготовки аналитики (было: 2 дня Excel, стало: 10 минут в BI)
- Повысилось качество данных (уменьшение ручных правок, дублирующих строк, конфликтов справочников)
- Появилась консолидация (данные из всех филиалов в одном отчёте)
- Снижен риск принятия решений на основе ошибочных данных
Бизнес-критерии лучше формулировать вместе с заказчиком в виде user-story, KPI или качественных эффектов.
Частые ошибки
× Критерии сформулированы размыто («должна быть удобная отчётность», «надёжная система»)
× Нет формальных протоколов — спор, кто и что должен подписывать
× Не проверяются нефункциональные требования (время загрузки, отклик BI, нагрузка)
× Отсутствуют критерии к данным: может быть красивый отчёт, но с ошибочными цифрами
× Нет метрик бизнес-успеха: проект принят, но эффекта нет
Сопровождение, обучение и передача знаний
Назначение раздела
Этот раздел описывает, что должно быть сделано после завершения технических работ, чтобы:
- заказчик мог полноценно пользоваться системой;
- команда сопровождения могла её поддерживать и развивать;
- сотрудники понимали логику работы и могли повторить действия самостоятельно.
Форматы сопровождения
- Техническая поддержка: реагирование на сбои, ошибки, вопросы
- Администрирование: добавление пользователей, мониторинг, обновления
- Регламенты: что, как, кто и когда должен делать
- Гарантийный период: срок, в течение которого устраняются дефекты за счёт исполнителя
Пример формулировки:
В течение 2 месяцев после ввода в эксплуатацию осуществляется гарантийная поддержка: исправление багов, настройка расписаний, поддержка пользователей первого уровня. Далее — платная поддержка согласно SLA.
Обучение
- Обучение пользователей (бизнес): проведение обучающих сессий, видеоинструкции, презентации
- Обучение администраторов: инструкции по доступу, мониторингу, резервированию
- Обучение разработчиков (если передаётся код): структура витрин, пайплайны, описание моделей
Хорошей практикой считается запись обучающих видео с демонстрацией интерфейсов и типовых сценариев.
Пример структуры обучения:
- Вводная: архитектура, цели
- Интерфейсы: навигация, фильтры, выгрузки
- Типовые кейсы: поиск отчёта, анализ отклонений, план-факт
- Частые ошибки: «не вижу данных», «не грузится отчёт»
Передача документации
- Полный комплект ТЗ, включая обновлённые версии
- Инструкции по запуску ETL, настройке BI, справочникам
- Словари данных (Data Dictionary)
- Архитектурные схемы и диаграммы потоков
- Перечень используемых скриптов, процедур, API, моделей
Документация должна быть в редактируемом и актуальном формате (Confluence, Word, Markdown, Wiki и т.д.)
Частые ошибки
× Отсутствие инструкций — система работает, но никто не знает, как её использовать
× Нет поддержки — баги не устраняются, никто не реагирует на сбои
× Обучение проведено один раз, без записи и без материалов
× Документация дана в устаревшем PDF или не передана вовсе
× Неясно, кто и как будет сопровождать систему (внутренний IT или подрядчик)
Приложения: словарь терминов, глоссарий, ссылки, шаблоны
Назначение приложений
Приложения служат дополнением к основному телу ТЗ. Они:
- структурируют и стандартизируют термины и обозначения;
- служат справочным материалом;
- повышают единообразие при внедрении и сопровождении проекта;
- позволяют быстро адаптироваться новым участникам команды.
Словарь терминов и глоссарий
Включает ключевые понятия, используемые в проекте. Например:
|
Термин |
Определение |
|
DWH (Data Warehouse) |
Централизованное хранилище данных для аналитики |
|
ETL |
Процесс извлечения, трансформации и загрузки данных |
|
BI |
Инструмент визуализации, построения отчётов и анализа |
|
Витрина данных |
Подготовленная таблица, агрегирующая данные для BI |
|
MDM |
Управление мастер-данными (справочники, их согласование и контроль) |
|
DQ (Data Quality) |
Методы и процессы обеспечения качества данных |
Если ТЗ составлено на русском, но используются англоязычные понятия — особенно важно пояснять их.
Ссылки на внешние и внутренние документы
- ГОСТ, ISO, внутренние стандарты компании
- Методологии: Kimball, Data Vault, TOGAF
- Процедуры по безопасности, резервному копированию, DevOps
- Внутренние глоссарии, инструкции, политики IT
Пример:
Справочник полей — см. документ Field Dictionary v2.1 (ссылка в Confluence)
Шаблоны и примеры
Очень полезно включить в ТЗ:
- Шаблон витрины данных (таблица с полями, типами, описанием)
- Макет дашборда (скриншот, описание блоков и фильтров)
- Пример протокола тестирования
- Шаблон use case
- Таблицу оценки качества данных
- Примеры названий объектов и их кодировки (таблицы, поля, меры)
Форматы хранения и размещения
- Все приложения должны быть в цифровом виде и доступны команде
- Удобно хранить в едином пространстве (Confluence, Wiki, Git, Google Drive)
- Обязательно обеспечить контроль версий (versioning), особенно при правках по ходу проекта
Если проект будет развиваться по спринтам — рекомендовано завести отдельную структуру артефактов проекта
Частые ошибки
× Термины используются в ТЗ, но нигде не расшифровываются (например, «ODS», «SCD2»)
× В шаблонах отсутствуют примеры — непонятно, как ими пользоваться
× Приложения не передаются команде или теряются после внедрения
× Глоссарий оформлен как свободный текст, без структуры и таблиц
Завершив модуль 3, у участника должно быть полное понимание, как составить техническое задание по системам класса BI, DWH, MDM, DQ и др., опираясь на лучшие практики, структуру и примеры.
