Модуль 2: Формулировка целей и задач проекта в ТЗ
Зачем нужны цели и задачи в техническом задании
Цели — это обоснование необходимости проекта, отражающее желаемое будущее состояние. Задачи — это конкретные шаги, которые необходимо предпринять для достижения этих целей. Техническое задание без чётко сформулированных целей и задач превращается в набор пожеланий, а не рабочий документ. Правильно оформленные цели и задачи позволяют:
- выстроить общее понимание результата между заказчиком и исполнителем;
- превратить идеи в измеряемые и реализуемые действия;
- обеспечить основу для последующей декомпозиции требований и контроля реализации проекта;
- минимизировать риск изменения объема работ в процессе реализации;
- задать метрики оценки успешности проекта.
Особенно важны формализованные цели в проектах, связанных с данными (BI, DWH, Lakehouse, MDM, Data Quality и пр.), где отсутствует один конечный продукт, а результат — это система, предоставляющая возможности для анализа, моделирования, управления и принятия решений. Здесь цели помогают соединить интересы различных стейкхолдеров, определить бизнес-ценность и устранить риск «просто красивой визуализации» без практической пользы.
Отличие бизнес-целей от ИТ-целей
Одной из распространённых ошибок при составлении технического задания является подмена бизнес-целей ИТ-целями. Это приводит к тому, что проект теряет связь с бизнес-ценностью, а реализация может уйти в сторону от изначальных ожиданий.
Примеры:
- Бизнес-цель: "Снизить издержки на логистику на 10% к концу финансового года."
- ИТ-цель: "Внедрить дашборд по логистическим затратам с детализацией по филиалам."
Бизнес-цель ориентирована на результат, который влияет на эффективность бизнеса, в то время как ИТ-цель описывает средство достижения этой цели. В техническом задании необходимо указывать обе, но делать упор на связь между ними: как техническое решение помогает достичь бизнес-результата.
Полезная практика — в каждом разделе технического задания, где описывается та или иная задача, явно указывать, какую бизнес-цель она поддерживает. Это не только обеспечивает фокус команды, но и помогает при защите бюджета и общении с руководством.
Модель SMART
Модель SMART — универсальный инструмент для формулировки целей, который особенно важен при работе над техническим заданием. SMART — это аббревиатура, обозначающая:
- Specific (конкретная): цель должна быть чёткой и понятной. Не «улучшить отчётность», а «создать дашборд по продажам с детализацией до SKU».
- Measurable (измеримая): должно быть понятно, как измерить достижение цели. Например, «сократить ручной труд по отчётности на 80%».
- Achievable (достижимая): цель должна быть реалистичной в условиях ограничений времени, бюджета, ресурсов.
- Relevant (релевантная): цель должна быть связана с приоритетами бизнеса.
- Time-bound (ограниченная по времени): должна быть указана конкретная дата или период, к которому необходимо достичь результата.
Техническое задание, в котором цели сформулированы по SMART, легче защищать перед стейкхолдерами, контролировать на этапе реализации и использовать при приёмке проекта.
Цели по уровням: стратегические, тактические, операционные
Целесообразно структурировать цели в техническом задании по уровням — это помогает выстроить логическую пирамиду, от верхнеуровневых мотиваций к конкретным действиям.
Стратегические цели отражают высокоуровневые намерения компании:
- Выйти в новую категорию продуктов
- Повысить маржинальность на уровне всей сети
- Стать лидером в отрасли по уровню автоматизации процессов
Тактические цели уточняют, через какие направления будет реализована стратегия:
- Внедрить процессное планирование
- Повысить прозрачность цепочки поставок
- Централизовать хранилище данных
Операционные цели описывают конкретные шаги, реализуемые в проекте:
- Создать витрину по выручке и себестоимости
- Настроить процесс обновления справочников через MDM
- Реализовать BI-дэшборд «ABC XYZ-анализ» по SKU
При написании технического задания важно проследить, чтобы каждый нижестоящий уровень целей имел обоснование выше. Это обеспечивает логичную иерархию задач и помогает избежать «висящих» требований, не связанных с бизнес-целями.
Типовые ошибки при формулировке целей
Даже самые опытные аналитики и руководители проектов часто допускают ошибки при формулировке целей в техническом задании. Эти ошибки приводят к размытым ожиданиям, проблемам при реализации и трудностям на этапе приёмки результатов. Ниже рассмотрены наиболее частые ошибки и их последствия:
1. Подмена цели средством:
- Пример ошибки: «Внедрить BI-систему»
- Почему это проблема: BI — это инструмент. Цель должна описывать, что именно нужно достичь с его помощью (например, «обеспечить оперативный доступ к ключевым KPI по продажам»).
2. Отсутствие измеримости:
- Пример: «Повысить прозрачность бизнес-процессов»
- Почему это проблема: без метрик прозрачность невозможно измерить. Лучше: «Сократить количество несогласованных заказов на 25% за счёт введения статуса заказа и алертов».
3. Размытые формулировки:
- Пример: «Улучшить отчётность»
- Как переформулировать: «Сократить срок подготовки отчётности по логистике с 4 до 1 дня путём автоматизации выгрузок и расчётов в BI»
4. Смесь задач и целей:
- Ошибка: «Настроить ETL-процесс для загрузки данных из CRM»
- Это задача, а не цель. Цель: «Обеспечить включение клиентской активности в модель расчёта LTV на ежедневной основе»
5. Конфликт целей между департаментами:
- Один отдел хочет гибкую аналитику, другой — жёсткий контроль за расчётами. Без увязки целей на стратегическом уровне такие конфликты влекут за собой технические проблемы (например, спор по поводу уровня агрегации данных)
6. Отсутствие привязки ко времени:
- Без указания сроков даже хорошо сформулированная цель превращается в пожелание. Например, «Снизить уровень возвратов» должно дополняться «...до конца второго квартала»
7. Игнорирование текущего уровня зрелости процессов:
- Цель «Внедрить единое хранилище данных» не учитывает, что у компании нет нормализованных справочников. Следует сначала задать промежуточную цель — «Навести порядок в справочнике товаров с точностью не ниже 98%»
Во избежание этих ошибок рекомендуется:
- проводить сессии ревью целей с бизнесом и ИТ;
- использовать шаблоны целей с примерами SMART-формулировок;
- проверять наличие связи между целью и измеримой метрикой;
- сопоставлять формулировки с реальной архитектурой компании и её текущими процессами.
Методы сбора целей и задач
Правильно собранные цели и задачи — это основа качественного технического задания. Недостаточно просто записать, что сказали пользователи — необходимо провести полноценную аналитическую работу по извлечению, интерпретации и согласованию целей. Ниже приведены ключевые методы, применяемые для сбора целей и задач в проектах по BI, DWH, MDM, системам качества данных и другим проектам, связанным с данными.
1. Интервью с ключевыми заинтересованными сторонами
Классический способ выявления потребностей. Интервью позволяют:
- Уточнить реальную мотивацию и проблемы, стоящие за задачами;
- Понять контекст использования данных;
- Выявить скрытые цели, которые не всегда формулируются напрямую.
Интервью необходимо структурировать по ролям:
- Руководители (бизнес-цели, KPI, проблемы управления);
- Аналитики (текущие отчеты, трудозатраты);
- ИТ-специалисты (источники, инфраструктура, ограничения);
- Операционные сотрудники (болевые точки в ежедневной работе).
Полезно использовать заранее подготовленные шаблоны вопросов, адаптированные под предметную область: например, для логистики — вопросы про сроки, возвраты, маршруты; для продаж — про цели по выручке, категории, регионы и др.
2. Воркшопы и фасилитационные сессии
Позволяют собрать сразу несколько точек зрения в одной комнате. Особенно эффективны:
- на старте крупных трансформационных проектов;
- в компаниях с матричной структурой и конфликтующими целями;
- при необходимости получить buy-in от топов и быстро приоритизировать задачи.
На воркшопе участники формулируют бизнес-проблемы, цели и задачи, классифицируют их, уточняют взаимосвязи. Важно наличие модератора, а также применение техник фасилитации (например, визуальные канвасы, метод «5 Почему», диаграммы Ishikawa и пр.).
3. Анализ текущей отчётности и рабочих Excel-файлов
В любой организации существует «теневая» аналитика в виде Excel-файлов. Из них можно получить:
- часто используемые показатели;
- способы группировки и фильтрации данных;
- ручные расчёты, которые требуют автоматизации;
- слабые места, например, дублирование расчётов в разных файлах.
Полезно составить список всех регулярно используемых файлов, проанализировать их структуру, источники данных и способы распространения (рассылки, выгрузки и пр.). Это помогает понять, какие цели могут стоять за автоматизацией.
4. Анализ процессов и регламентов
Регламенты, должностные инструкции, схемы процессов позволяют понять:
- где в бизнесе возникают точки принятия решений;
- какие данные используются при этих решениях;
- что можно измерить, автоматизировать или контролировать.
Например, процесс согласования бюджета может включать множество итераций и ручных сверок. Это даёт цель: «сократить время согласования до 3 дней за счёт централизованной системы бюджетирования».
5. Анализ боли и метрик ошибок
Цели и задачи часто возникают не от желания что-то улучшить, а от боли:
- сотрудники тратят по 3 часа на подготовку отчёта;
- ошибки в расчётах приводят к потере выручки;
- нет прозрачности в премиях, что создаёт напряжение в коллективе.
Выявление этих болей — источник конкретных задач. Для этого можно использовать опросы, жалобы, отчёты об ошибках, данные об инцидентах.
6. Карты процессов и CJM
Для сквозных процессов (например, от заказа до поставки) или клиентских маршрутов (Customer Journey Map) полезно использовать визуальные инструменты. Они помогают:
- выявить ключевые точки данных на каждом этапе;
- зафиксировать ожидания пользователей;
- связать цели BI/MDM с операционной реальностью.
7. Анализ данных об использовании текущих систем
Если BI или DWH уже внедрены, можно собрать статистику:
- какие отчёты наиболее востребованы;
- какие поля чаще фильтруются;
- какие дашборды не используются вовсе (значит, цели устарели).
Это даёт основу для уточнения или перераспределения целей и задач.
8. Выявление целевых KPI и стратегических показателей
Если организация имеет стратегические KPI (например, в Balanced Scorecard), проект должен быть на них ориентирован. Увязка целей технического задания с этими показателями повышает значимость проекта и упрощает обоснование инвестиций.
9. Использование фреймворков целей и требований
Для систематизации целей применяют подходы:
- GQM (Goal-Question-Metric): цель → какие вопросы нужно задать → какие метрики измерить;
- OKR (Objectives and Key Results);
- Business Model Canvas и Value Proposition Canvas (для стартапов и продуктового BI);
- Архитектурные подходы TOGAF / ArchiMate (для крупных трансформаций).
Применение одного из фреймворков позволяет описывать цели стандартизованно и согласовывать их между командами.
Как связать цели с требованиями в техническом задании
Связь между целями и требованиями — один из ключевых элементов логики технического задания. Без этой связи проект превращается в набор невзаимосвязанных задач, а система — в хаотичное нагромождение функций. Грамотно выстроенная связка «цель → задача → требование» обеспечивает прозрачность и управляемость проекта.
Зачем нужна связка целей и требований:
- Обеспечивает прозрачность: можно объяснить, зачем нужно то или иное требование.
- Защищает проект от «ползущего» объема (scope creep): любые новые требования проверяются на соответствие целям.
- Упрощает приёмку проекта: если цели достигнуты и требования выполнены, проект можно считать успешным.
- Помогает приоритетизировать: задачи, не связанные с ключевыми целями, можно вынести за рамки или отложить.
Пошаговый подход к формированию связки:
- Сформулируйте бизнес-цели проекта Пример: «Сократить потери от out-of-stock на 15% к концу Q3»
-
Разложите цели на задачи (механизмы достижения) Пример:
- Создать витрину фактических остатков
- Реализовать прогноз потребления по SKU
- Настроить алерты на рисковые позиции
- Определите требования к данным и системам для выполнения задач Пример:
- Наличие в DWH таблицы остатков с детализацией до SKU/день
- Наличие справочника минимальных остатков
- Расчёт прогноза через ML-модель с обновлением раз в сутки
- BI-дэшборд с тепловой картой рисков по регионам
- Зафиксируйте связку в таблице соответствия
|
Цель |
Задача |
Требование |
|
Снизить out-of-stock на 15% |
Витрина остатков |
Таблица DWH.Inventory |
|
Прогноз потребления |
ML-модель + витрина прогноза |
|
|
Настройка алертов |
BI-дэшборд «OOS Alert Map» |
Практики для поддержки связки целей и требований:
- Использование шаблонов «цель-задача-требование»: каждая бизнес-цель расписывается до уровня технических требований и обоснования необходимости каждого элемента.
- Трассируемость (traceability matrix): в системах управления требованиями (Jira, Confluence, Notion, ReqView и др.) можно построить таблицу связей: «Goal → Feature → Requirement → Test Case → Result». Это даёт сквозной контроль.
- Моделирование связей в BPMN, ArchiMate или C4-диаграммах: позволяет наглядно показать, какие компоненты архитектуры соответствуют каким целям.
- Проверка новых требований на соответствие целям: каждое новое требование проверяется через вопрос «Какую цель оно поддерживает?». Если ответа нет — оно исключается или откладывается.
Ошибки при построении связки:
- Требование существует «само по себе» без задачи и цели.
- Цель декларирована, но не имеет задач и требований.
- Требования не согласованы между собой и нарушают целевую архитектуру.
- Уровень детализации требований не соответствует уровню целей (например, бизнес-цель «снижение издержек», а требование — «создать фильтр по складам»).
Советы:
- На этапе защиты проекта перед стейкхолдерами обязательно показывайте связку целей и требований: это повышает доверие.
- Применяйте визуальные средства: дерево целей, таблицы соответствия, графы требований.
- Уточняйте цели в процессе: если выяснилось, что задача технически не имеет смысла — вернитесь к цели и пересмотрите её формулировку.
Как зафиксировать цели и задачи в теле технического задания
Формулировка и размещение целей и задач в теле технического задания требует точности, логики и структурного подхода. От этого зависит не только прозрачность документа, но и управляемость проектом на всех этапах: от инициации до внедрения и поддержки.
1. Где в структуре технического задания должны быть отражены цели и задачи?
Обычно структура технического задания включает следующие ключевые разделы:
- Введение / Общие положения
- Цели проекта
- Задачи проекта
- Функциональные и нефункциональные требования
- Архитектура
- Интеграции и источники данных
- План-график и критерии приемки
Раздел «Цели проекта» должен идти сразу после вводной части и быть максимально понятным как бизнесу, так и исполнителю. Следом должен идти блок «Задачи проекта», который раскрывает, через какие конкретные направления будет достигнута каждая цель.
2. Пример оформления раздела целей
Цели проекта
Проект направлен на достижение следующих бизнес-целей:
- Повысить достоверность управленческой отчетности по выручке, маржинальности и затратам.
- Сократить трудозатраты на сбор и сведение данных по филиалам с 12 часов до 2 часов в месяц.
- Обеспечить прозрачность данных для расчета премий, устранить спорные ситуации.
- Сформировать единое хранилище для консолидации данных продаж, затрат и нормативов.
При необходимости бизнес-цели могут быть детализированы в подцели или подгруппы — например, по направлениям деятельности, по департаментам, по группам стейкхолдеров.
3. Пример оформления раздела задач
Задачи проекта
Для достижения целей проекта требуется решить следующие задачи:
- Разработать и внедрить витрину данных по фактическим продажам с детализацией до SKU/день.
- Разработать BI-дэшборд «Финансовая эффективность» с расчётом прибыли по филиалам.
- Реализовать алгоритм распределения затрат по нормативам.
- Обеспечить механизм контроля качества данных на этапе загрузки (валидация, логирование).
- Настроить интеграцию с 1С:ERP и 1С:ЗУП для автоматического получения данных о себестоимости и фонде оплаты труда.
Каждая задача должна быть конкретной, измеримой, технически реализуемой и согласованной с архитектурой и ограничениями проекта.
4. Таблицы связей целей, задач и требований
Для сложных проектов полезно размещать отдельные таблицы, связывающие цели, задачи и функциональные требования. Это усиливает трассируемость и помогает всем участникам видеть общий контекст.
Пример:
|
Цель |
Задача |
Функциональные требования |
|
Повышение достоверности отчётности |
Создать витрину по продажам |
Наличие витрины Sales.Facts |
|
Снижение трудозатрат |
Автоматизировать расчёты |
BI-дэшборд «Финансы», автообновление |
|
Прозрачность премий |
Связать ФОТ и KPI |
Интеграция с 1С:ЗУП, справочник премий |
5. Требования к стилю и языку
- Формулировки должны быть однозначными и лаконичными.
- Избегать глаголов в сослагательном наклонении: не «должна бы обеспечиваться», а «должна обеспечить».
- Каждая цель и задача должна быть отделена и нумерована.
- При необходимости прикладываются схемы, диаграммы, ссылки на регламенты и инструкции.
6. Примеры плохих формулировок и их улучшения
|
Плохо |
Хорошо |
|
Улучшить аналитику |
Реализовать витрину ABC-анализ по SKU с обновлением ежедневно |
|
Сделать удобно |
Обеспечить drill-down с уровня бренда до SKU в BI-дэшборде «Продажи» |
|
Сделать дешево |
Реализовать решение на текущей инфраструктуре с использованием open-source инструментов |
7. Дополнительные элементы фиксации
- Карта целей и задач — визуальная схема, связывающая ключевые цели, задачи и показатели.
- Приложения — более подробные описания требований, схемы, примеры отчетов, KPI.
- Утверждение целей — цели должны быть согласованы и утверждены стейкхолдерами. Это фиксируется в виде отдельного акта, согласованного документа или электронного согласования.
Чётко и логично оформленные цели и задачи в теле технического задания позволяют не только правильно стартовать проект, но и эффективно управлять им на всех этапах. Это основа для будущего контроля реализации, измерения успешности и анализа отклонений.
Как согласовать цели и задачи между бизнесом и ИТ
Один из самых чувствительных моментов при разработке технического задания — это согласование целей и задач между бизнесом и ИТ-подразделениями. Без этой синхронизации проект рискует провалиться: либо потому, что ИТ построит не то, что нужно, либо потому, что бизнес не будет использовать то, что построено.
Зачем нужно согласование?
- Обеспечить общее понимание, что именно разрабатывается и зачем.
- Снизить риск неправильной интерпретации бизнес-целей ИТ-командой.
- Убедиться, что цели достижимы с учетом имеющейся инфраструктуры.
- Согласовать приоритеты при наличии ограниченных ресурсов.
Основные различия в восприятии целей:
|
Аспект |
Бизнес |
ИТ |
|
Ожидание |
Быстрый результат, удобство, влияние на показатели |
Техническая реализуемость, надежность, поддержка |
|
Язык |
Показатели, процессы, деньги |
Таблицы, API, скрипты |
|
Масштаб |
Видит общую картину |
Углубляется в детали реализации |
Подход к согласованию целей:
- Создание двуязычного слоя
Необходимо перевести цели бизнеса на язык технических требований, сохранив бизнес-смысл. Этим занимается аналитик или архитектор, выступающий «переводчиком» между бизнесом и ИТ. Он должен уметь:
- интерпретировать метрики и KPI в термины архитектуры;
- объяснять ИТ-решения с позиции бизнес-ценности;
- документировать цели в форме, понятной обеим сторонам.
- Проведение согласовательных сессий
Идеальный формат — небольшие очные встречи с участием ключевых представителей от бизнеса и ИТ. На таких встречах:
- обсуждаются и корректируются цели и задачи;
- снимаются технологические ограничения;
- уточняются приоритеты задач и разделение ответственности.
Важно обеспечить модерацию таких встреч и наличие артефактов (протоколов, схем, таблиц связей). Без этого есть риск, что договоренности останутся «в воздухе».
- Матрица ответственности (RACI)
Для согласования задач важно определить, кто:
- Responsible (отвечает за выполнение)
- Accountable (несёт ответственность за результат)
- Consulted (должен быть привлечён к обсуждению)
- Informed (должен быть в курсе)
Пример:
|
Задача |
Бизнес |
Аналитик |
ИТ-архитектор |
BI-разработчик |
|
Формулировка целей |
A |
R |
C |
I |
|
Проектирование витрины |
C |
R |
A |
R |
|
Разработка дэшборда |
I |
C |
C |
R |
- Визуализация целей и архитектуры
Бизнесу сложно понимать архитектурные схемы, поэтому полезно строить:
- карты целей и задач;
- схемы потоков данных с подписями бизнес-смыслов;
- макеты будущих отчётов;
- примеры витрин с пояснениями, какие данные и метрики там будут представлены.
- Использование артефактов технического задания как инструмента согласования
Техническое задание — это не просто документ для исполнения, но и средство коммуникации. В него должны быть включены:
- Согласованные цели
- Таблицы связи целей и требований
- Подписи или согласования ключевых заинтересованных сторон
- История правок и версий документа
- Согласование бизнес-приоритетов и технических ограничений
Типовая ситуация — бизнес хочет «всё и сразу», а ИТ говорит «через 6 месяцев и не всё». Необходимо:
- сформировать MVP (минимально жизнеспособный результат);
- выделить приоритетные витрины/дашборды/процессы;
- зафиксировать то, что попадает в первую очередь реализации, а что отложено.
- Фиксация согласования и юридическая значимость
Все согласованные цели и задачи должны быть:
- оформлены в виде версии технического задания;
- подписаны или зафиксированы в системе управления проектами;
- иметь статус «утверждено», с указанием даты и ответственных.
Согласование целей и задач между бизнесом и ИТ — это не разовая встреча, а итеративный процесс коммуникации, документирования, перевода и приоритизации. Только при взаимном уважении, готовности к диалогу и прозрачности процессов можно добиться, чтобы система, описанная в техническом задании, действительно принесла бизнесу ценность.
Как описывать метрики успешности достижения целей
Формулировка метрик успешности — это способ перевести абстрактные цели в измеримые критерии, позволяющие оценить, достигнуты ли они после реализации проекта. В техническом задании такие метрики играют ключевую роль: они служат точкой отсчёта для оценки результата, позволяют организовать контроль и приёмку, обеспечивают прозрачность взаимодействия между заказчиком и исполнителем.
Зачем фиксировать метрики успешности в техническом задании?
- Устанавливают чёткие ожидания по результату;
- Являются критерием приёмки проекта;
- Помогают управлять ожиданиями заинтересованных сторон;
- Способствуют фокусировке на действительно важных результатах;
- Позволяют измерять эффект внедрения и ROI.
Какими должны быть метрики?
Метрики должны быть SMART:
- Specific (конкретные);
- Measurable (измеримые);
- Achievable (достижимые);
- Relevant (релевантные);
- Time-bound (ограниченные по времени).
Примеры хороших и плохих метрик:
|
Плохо |
Хорошо |
|
Сделать BI более удобным |
Сократить среднее время открытия отчёта с 12 до 3 секунд |
|
Автоматизировать аналитику |
Исключить 80% ручных операций по расчёту выручки в Excel |
|
Улучшить качество данных |
Увеличить долю валидных записей в справочнике контрагентов до 98% |
|
Повысить прозрачность |
Обеспечить доступ к витрине маржинальности для 10 ключевых руководителей до 1 октября |
Типы метрик:
-
Технические метрики
- Время загрузки отчёта
- Время обновления витрины
- Время отклика BI-системы
- Объём данных в витринах
- Организационные и процессные
- Количество пользователей, активно работающих в системе
- Время подготовки отчётности
- Количество вручную обрабатываемых Excel-файлов
- Доля автоматизированных отчётов
- Уровень out-of-stock
- Точность прогноза спроса
- Средний срок закрытия бюджетного цикла
- Уровень обоснованности премий
- ROI от проекта (через снижение затрат / рост продаж)
- Бизнес-метрики
Как зафиксировать метрики в техническом задании?
Можно использовать таблицу вида:
|
Цель |
Метрика |
Целевое значение |
Способ измерения |
Срок |
|
Снизить трудозатраты на отчётность |
Время подготовки отчёта по филиалам |
≤ 2 ч/мес |
Опрос пользователей + замеры |
Через 1 мес после запуска |
|
Повысить прозрачность премий |
Доля согласованных выплат без споров |
≥ 95% |
Отчёт службы персонала |
Через 3 мес |
|
Улучшить качество справочника |
Доля валидных ИНН |
≥ 98% |
Валидация по справочникам ФНС |
После 2 итераций загрузки |
Методы сбора и измерения метрик:
- Системные логи и мониторинг (для технических метрик);
- Опросы и анкетирования (для восприятия удобства и процессов);
- Анализ операционных данных (времени, ошибок, возвратов);
- BI-дашборды с KPI-панелями (включить в состав проекта);
- Сравнение до / после (снимки показателей до внедрения и после).
Ошибки при работе с метриками:
- Формулировка метрик без связи с целями;
- Отсутствие измеримости («улучшить», «повысить» без чисел);
- Нереалистичность (цель за 1 месяц — в 10 раз сократить расходы);
- Отсутствие методики измерения (как проверить, что цель достигнута);
- Отсутствие сроков (цель без дедлайна — бесконечна).
Кто отвечает за метрики:
- Заказчик (бизнес): формулирует желаемый эффект и подтверждает достижение;
- Аналитик: помогает перевести цели в измеримые показатели;
- Исполнитель (ИТ): реализует инструменты, позволяющие измерить результат;
- Команда проекта: фиксирует в техническом задании, отслеживает реализацию.
Метрики и приёмка проекта:
При финальной приёмке проекта важно пройтись по всем зафиксированным метрикам и убедиться в их достижении. В акт приёмки могут быть включены выдержки из BI-отчетов, скриншоты, системные логи, результаты замеров и анкет.
Метрики успешности — это способ сделать цели технического задания проверяемыми. Они превращают декларации в критерии, по которым можно судить об успехе проекта. Без метрик техническое задание будет расплывчатым и мало полезным, особенно в спорных ситуациях.
Итог модуля 2:
- Вы научились выявлять бизнес-проблему и превращать её в цель
- Вы умеете разложить цель на задачи и конкретные требования
- Вы понимаете структуру целей (стратегическая → операционная → инструментальная)
- Вы умеете согласовывать цели со стейкхолдерами и фиксировать их в ТЗ
- У вас есть шаблоны, примеры и упражнения для практики
