Модуль 19. Техническое задание (ТЗ) для закупок и аутсорса
Зачем здесь бизнес-аналитик
Роль BA — перевести бизнес-цель и SRS в юридически значимый Scope of Work (SOW)/ТЗ, по которому:
- можно провести RFI/RFP, сравнить предложения «яблоки к яблокам»;
- есть измеримые критерии приёмки и SLA/NFR;
- зафиксированы исключения, риски, IP/конфиденциальность, порядок изменений и оплаты.
BA не «пишет контракт», но задаёт структуру ТЗ, цифры и проверки, которые потом лягут в договор.
SRS vs ТЗ/SOW: в чём разница и как их связать
|
Характеристика |
SRS (требования) |
ТЗ/SOW (закупка/контракт) |
|---|---|---|
|
Фокус |
Что система должна делать |
Что поставщик обязуется поставить/сделать |
|
Язык |
Продуктово-технический |
Юридико-операционный |
|
Измеримость |
AC/NFR/traceability |
Scope, Deliverables, Milestones, Acceptance, SLA, Penalties |
|
Гибкость |
Может уточняться спринтами |
Изменения через Change Request |
|
Риск |
Технические неопределённости |
Коммерческие/юридические (сроки, качество, IP) |
Связка: ТЗ ссылается на SRS (версия/дата), но не копирует его целиком. В ТЗ — только то, что влияет на поставку, приёмку и оплату.
Закупочный конвейер и роль BA
- RFI (сбор рынка) → BA формирует 1–2 страницы: контекст, high-level scope, ограничения, вопросы рынку.
- Pre-NDA + Q&A → вендоры задают уточнения. BA фиксирует ответы в «Протокол разъяснений» — он станет частью ТЗ.
- RFP (конкурс) → BA готовит ТЗ, матрицу оценки, форму коммерческого предложения, шаблон плана работ.
- Демо/POC (где уместно) → BA задаёт сценарии и эталонные сеты для проверки.
- Оценка → BA ведёт scorecard, сводит финальную таблицу, готовит «риск-лист».
- Договор/старт → BA переносит в договор Scope, Deliverables, SLA, Acceptance, Penalties, CR-процедуру.
Структура ТЗ/SOW (скелет с примерами формулировок)
-
Цели и ожидаемые эффекты
«Сократить TTM отчётов с 10 до 3 дней, повысить Freshness D-1 к 07:00 на 99%, p95 дашборда ≤ 5 сек». -
Scope (включено)
«1) Витрина продаж DWH; 2) Семантический слой; 3) 5 дашбордов; 4) Настройка RLS; 5) Пакет документации; 6) Обучение 2×2 часа». -
Out of Scope (исключено)
«Адаптация внешней MDM-системы; лицензии BI; миграция исторических данных > 24 мес». -
Артефакты (Deliverables)
«Схема DWH (DDL), ETL-пакеты, паспорт дашборда, словарь метрик, тест-наборы, план эксплуатации». -
Требования (ссылка на SRS)
«SRS-BI-012 v1.4 от 2025-06-15; изменения — только через CR». -
NFR/SLA
Freshness, p95, доступность, DQ, безопасность, DR — с методикой измерения (см. §5). -
План работ и вехи (Milestones)
График с датами, критериями завершения и долями оплаты. -
Роли и RACI
Кто за что отвечает (вендор/заказчик). -
Критерии приёмки (Acceptance)
Измеримые тесты/эталоны, процедура зачёта и сроки на исправления. -
Оплата и штрафы
Модель (FP/T&M/гибрид), удержания/бонусы, SLA-кредиты. -
Процедура изменений (CR)
Формат, SLA оценки, влияние на сроки/стоимость. -
Конфиденциальность и IP
Background/Foreground IP, лицензии, открытый код. -
Риски и допущения
Таблица рисков с владельцами и планом B. -
Безопасность/данные
PII, маскирование, доступы, среда, логирование. -
Коммуникации и эскалации
Стэндапы, демонстрации, SteerCo, уровни инцидентов.
NFR/SLA: что и как мерить (типовой набор для BI/DWH)
DWH/ETL
- Freshness: D-1 к 07:00 лок., ≥ 99% периодов/мес. Методика: «время окончания последней успешной загрузки < 07:00».
- Надёжность загрузок: ≥ 99% успешных DAG за месяц.
- Время окна загрузки: ≤ 120 мин.
- DQ: Completeness/Consistency ≥ 99.5% на критичных таблицах (по правилам в словаре DQ).
- Lineage/каталог: опубликованы схемы и происхождение данных.
BI/панели
- p95 отклика: ≤ 5 сек при 12 мес истории.
- RLS: корректность и инвариантность итогов (суммы при разных ролях сходятся).
- Доступность ключевых страниц: ≥ 99.5%.
Безопасность
- Маскирование PII: включено в DEV/TEST/PROD; экспорт PII — запрещён по умолчанию.
- Аудит доступа: 100% действий пользователей логируется.
DR/эксплуатация
- Backups: ежедневно, ретеншн 35 дней.
- RTO/RPO: 4 часа / 1 час.
В ТЗ обязательно: метрика → целевое значение → методика измерения → источник правды → период отчётности → SLA-кредиты.
План работ, роли и управление
Пример вех (Milestones)
- M1 (T0+2 нед): Архитектурный скелет DWH + план тестов → 10%.
- M2 (T0+6 нед): Витрина продаж + DQ-правила + UAT-набор → 20%.
- M3 (T0+10 нед): 3 дашборда + RLS + паспорт → 25%.
- M4 (T0+12 нед): Семантический слой + 2 дашборда → 25%.
- M5 (T0+14 нед): Обучение + эксплуатационный пакет → 10%.
- M6 (T0+18 нед): Гарантийный месяц (SLA в норме) → 10%.
RACI (фрагмент)
|
Задача |
Вендор |
Заказчик-ИТ |
Заказчик-Бизнес |
BA |
|---|---|---|---|---|
|
SRS/методика метрик |
C |
C |
A |
R |
|
Модель DWH/ETL |
R |
C |
I |
C |
|
DQ-правила |
R |
C |
C |
A |
|
BI-дашборды |
R |
C |
C |
A |
|
UAT/приёмка |
R |
C |
A |
C |
|
Комм-план/обучение |
R |
C |
A |
C |
Коммуникации
- Статус-митинг 1×нед; демо 1×спринт; SteerCo 1×мес; канал эскалаций P1/P2/P3 с SLA ответа.
Приёмка (Acceptance) — конкретика
Общие правила
- Проверка на эталонах (файлы/SQL), список AC.
- Срок тестирования: 5 раб. дней на поставку; на исправления: до 10 раб. дней; не более 2 итераций без CR.
- Подписание Acceptance Certificate по каждой вехе.
Примеры AC для BI/DWH
- GM% совпадает с эталоном (±0,2 п.п.) на 10 тестовых наборов.
- Freshness за неделю ≥ 99% (5 рабочих дней) — отчёт из мониторинга.
- p95 ключевой панели ≤ 5 сек при 12 мес данных.
- RLS: региональный пользователь не видит чужие данные; суммы инвариантны.
- DQ-правила: Completeness ≥ 99.5% на fact_sales (отчёт приёмки приложен).
- Логи/аудит: все входы/экспорты фиксируются (выгрузка из аудита).
Модели оплаты, удержания и штрафы
Fixed Price (FP) — фиксированная стоимость за результат; хорошо при чётком scope.
T&M — почасовая/дневная ставка; гибко при discovery/изменениях.
Гибрид — FP по основным вехам + T&M на CR/исследования.
Удержания/стимулы
- Holdback 10–20% до прохождения гарантийного периода (SLA).
- SLA-кредиты: при невыполнении Freshness/p95 — кредиты/штрафы (например, −1% от стоимости за каждый 0,5 п.п. ниже цели в отчётном месяце, но не более 10%).
- Бонусы: досрочная поставка/превышение целей (по согласованию).
Изменения (CR) — как не «раздувать» контракт
- Форма CR: описание, бизнес-эффект, оценка вендора (часы/стоимость/срок), влияние на SLA/вехи.
- SLA на оценку: ≤ 3 раб. дней.
- Порог на мелкие изменения: ≤ 8 часов — в рамках буфера спринта (до N% от бюджета).
- Контроль версии SRS/методологии: любая смена формулы метрики → MAJOR.
IP, лицензии, конфиденциальность
- Background IP: наработки вендора (фреймворки/шаблоны) — остаются за вендором, предоставляется неисключительная лицензия.
- Foreground IP (артефакты проекта): исходники ETL/BI-моделей/схемы/скрипты — права передаются заказчику (work-for-hire).
- Открытый код: разрешён при согласовании, список лицензий, запрет copyleft для встраивания, обязанности по комплаенсу.
- Конфиденциальность: NDA, запрет публикаций без согласия, требования к средам (VPN, SSO, MFA), управление секретами (Vault).
- Данные: PII/коммерческая тайна — маскирование, запрет выгрузок, ретеншн, уничтожение по завершении.
Оценка вендоров: матрица и процесс
Критерии и веса (пример)
|
Критерий |
Вес |
Что смотреть |
|---|---|---|
|
Понимание предмета/подход |
25% |
Как переформулировали задачу, риски, план |
|
Команда/роли/резюме |
20% |
Seniority, наличие Data/BI/DevOps, % отвлекаемости |
|
Техника/методология |
20% |
DWH-архитектура, DQ, мониторинг, безопасность |
|
Демонстрация/POC |
15% |
Выполнили сценарии? p95/Freshness на эталонах |
|
Стоимость/TCO |
10% |
Не только ставки — и лицензии/обслуживание |
|
Риски/гибкость |
10% |
Условия CR, штрафы, гарантия, отказоустойчивость |
Процесс
- Брифинг → Q&A → Письменное предложение → Демо/POC по общему сценарию (BA готовит шаблон) → Оценка по матрице → Референсы → Неготиация условий → Выбор.
Риски контрактов и «красные флаги»
|
Риск |
Признак |
Что сделать в ТЗ/договоре |
|---|---|---|
|
Размытый scope |
«Сделаем аналитику» |
Жёсткий перечень артефактов и AC; Out of Scope |
|
Вендор-лок-ин |
Нет исходников/скриптов |
Передача Foreground IP; обязательный Git-репозиторий |
|
Отсутствие SLA-методики |
«Будет быстро» |
Метрика→способ измерения→источник→SLA-кредиты |
|
Смена команды |
«Заменим на ходу» |
Право согласования ключевых ролей; CV в приложении |
|
Невыполнимые сроки |
«Всё за месяц» |
Буфер, поэтапная оплата, пилот с ясными AC |
|
Нет безопасности |
Временные доступы «на доверии» |
SSO/MFA, секреты в Vault, запрет PII-экспортов |
|
CR-инфляция |
Микрозапросы по T&M |
Порог мелких CR; SLA оценки; лимит бюджета CR |
|
Отсутствие гарантий |
«После закрытия — пока» |
Гарантия N недель с SLA; holdback до конца |
Практика: шаблон ТЗ (копируйте и адаптируйте)
Шаблон (структура)
- Введение и цели
- Scope/Out of Scope
- Артефакты и документация
- Ссылка на SRS/методологию (версии)
- NFR/SLA и методика измерения
- План работ, Milestones, календарь
- Роли, RACI, доступы, среды
- Acceptance: тест-наборы, AC, процедуры
- Оплата: модель, вехи, удержания, SLA-кредиты
- Change Request: форма, SLA, пределы
- IP/Конфиденциальность/Безопасность
- Риски и допущения
- Коммуникации/эскалации
- Приложения (шаблоны отчётов, эталоны данных, словарь метрик)
«Пример ТЗ» под BI/DWH-проект (выжимка содержимого)
Цель: «DWH+BI для розницы: витрина продаж D-1, 5 дашбордов (GM%, OOS, Promo, LFL, Inventory), Freshness D-1 07:00 ≥ 99%, p95 ≤ 5 сек, RLS по региону».
Scope:
- DWH CORE+MARTS (sales, inventory, price).
- ETL-пайплайны (инкременты, мониторинг).
- Семантика BI + 5 дашбордов + паспорта.
- DQ-правила (Completeness/Consistency).
- Обучение (2 сессии) + эксплуатационный регламент.
NFR/SLA:
- Freshness D-1 07:00 ≥ 99% (месячно).
- Успешность DAG ≥ 99% (месячно).
- p95 панелей ≤ 5 сек.
- RLS инвариантность итогов.
- PII маскирование, аудит входов/экспортов.
Acceptance (фрагмент):
- Сверка GM% с эталоном (±0,2 п.п.).
- Дашборд «Promo & GM%»: фильтры совместно, версия методики в шапке.
- DQ-отчёт: Completeness fact_sales ≥ 99.5%.
- Мониторинг: отчёт Freshness за 10 рабочих дней.
- Документация: паспорт дашбордов, словарь метрик (RU/EN), схема DWH.
Оплата/вехи: M1…M6 как в §5, holdback 10%, SLA-кредиты до 10%/мес.
CR: форма, SLA оценки 3 дня, лимит мелких CR 5% от бюджета.
IP/Безопасность: Foreground IP → заказчику; SSO/MFA; запрещён экспорт PII; ключи в Vault.
Риски/допущения: доступ к источникам в 10 раб. дней; один контактный по бизнес-методике; каникулы релизов.
Вопрос–ответ (FAQ)
Q: У нас гибкий бэклог. Как совместить с фиксированным ТЗ?
A: Зафиксируйте рамку результата (витрины/дашборды/метрики/NFR) и процесс CR для приоритизации. Используйте гибрид FP+T&M.
Q: Нужно ли переписывать SRS в ТЗ?
A: Нет. В ТЗ — ссылка на SRS с версией. Важное — критерии приёмки и SLA, которых нет в SRS.
Q: Как доказать, что вендор «потянет»?
A: POC по общему сценарию, эталоны данных, KPI p95/Freshness/DQ, референсы, CV ключевых спецов — в приложении к ТЗ.
Q: Что делать, если сроки «горит бизнес»?
A: Делите на пилот (MVP) с жёсткими AC и NFR, остальное — доп.фаза через CR. Пропишите «каникулы изменений» на критические даты.
Q: Кто владеет методикой метрик?
A: Заказчик/BA. Вендор реализует. Смена методики — MAJOR-изменение (CR).
Чек-листы BA перед выпуском ТЗ
Содержание
- Цели измеримы и связаны с эффектом.
- Scope/Out of Scope перечислены.
- Артефакты + шаблоны приложены.
- NFR/SLA с методиками измерения.
- Acceptance с эталонами и сроками.
- План работ/вехи/оплата/holdback.
Губернанс/риски
- CR-процесс и лимиты.
- IP и лицензии описаны.
- Безопасность/PII/доступы.
- Матрица оценки вендоров.
- Протокол Q&A включён в пакет.
Adoption
- Паспорт дашбордов/метрик будет создан в поставке.
- Обучение и эксплуатация запланированы.
- RACI/эскалации согласованы.
Как бизнес-аналитик, вы превращаете абстрактные «сделайте нам BI/DWH» в контрактуемый результат: понятный Scope, измеримый SLA, прозрачная приёмка, управляемые изменения, защищённые IP и данные. С таким ТЗ закупка проходит быстро, сравнение вендоров честное, а проект заканчивается не «договором о намерениях», а реальным эффектом.
