Как готовилось ТЗ вместе с клиентом в проектах?

Процесс разработки Технического Задания (ТЗ) с клиентом: структурированный подход

Разработка ТЗ — это совместный и итеративный процесс, где я выступаю как медиатор между бизнес-целями клиента и техническими возможностями команды. Мой подход основан на десятилетии практики и строится на принципах гибкой методологии (Agile) и управления требованиями. Вот ключевые этапы:

1. Предпроектное исследование и погружение

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

• Серия воркшопов и интервью: Провожу встречи с ключевыми стейкхолдерами (заказчики, конечные пользователи, эксперты предметной области). Цель — выявить боли, цели и ожидания.
• Анализ существующих процессов: Если это доработка или замена системы, детально изучаем текущий workflow. Часто использую нотацию BPMN для визуализации.

  <!-- Упрощенный пример схемы процесса согласования заявки -->
  <bpmn:process id="ApprovalProcess">
      <bpmn:startEvent id="start"/>
      <bpmn:task id="submitRequest" name="Подача заявки"/>
      <bpmn:exclusiveGateway id="gateway1"/>
      <bpmn:task id="managerApprove" name="Согласование руководителем"/>
      <bpmn:task id="financeApprove" name="Согласование финансами"/>
      <bpmn:endEvent id="end"/>
      <!-- ... потоки ... -->
  </bpmn:process>
  

• Формулировка Vision & Scope: Создаем короткий документ «Видение проекта», который фиксирует высоуровневые цели, целевую аудиторию, ключевые преимущества и границы (scope). Это «Северная звезда» для всего проекта.

2. Декомпозиция и проработка требований

Здесь мы трансформируем общие пожелания в конкретные, измеримые пункты.

• Работа с пользовательскими историями (User Stories): Использую формат «Как [роль], я хочу [возможность], чтобы [ценность/выгода]». Это делает требования понятными для всех.

  Как: Менеджер по продажам
  Я хочу: видеть на дашборде сводку по просроченным платежам клиентов
  Чтобы: оперативно инициировать процесс напоминания и снизить дебиторскую задолженность.
  

• Приоритизация по методу MoSCoW: Совместно с клиентом классифицируем требования на:

    *   **Must have** — без этого система неработоспособна.
    *   **Should have** — важные, но не критические функции.
    *   **Could have** — желательные улучшения.
    *   **Won't have** — осознанно откладываем на будущее.

• Создание прототипов и wireframes: Визуализация (даже в виде простых скетчей в Figma или Miro) в разы сокращает недопонимание. Клиент «видит» будущий интерфейс и вносит правки на ранней стадии, когда их стоимость минималь​​на.

3. Формализация в документ ТЗ и спецификацию

На этом этапе структурируем все наработки. Мой подход — делать ТЗ «живым» и удобочитаемым.

• Структура документа:

    1.  **Общее описание:** Цели, стейкхолдеры, глоссарий.
    2.  **Бизнес-требования:** Vision, цели, KPI (например, "сократить время обработки заявки на 30%").
    3.  **Функциональные требования:** Детализированные сценарии использования (Use Cases), пользовательские истории, правила бизнес-логики.
    4.  **Нефункциональные требования:** Производительность, безопасность, нагрузка (например, "система должна выдерживать 1000 одновременных пользователей"), UX-требования.
    5.  **Ограничения:** Технический стек (если задан), сроки, бюджет, нормативные требования (GDPR, 152-ФЗ).
    6.  **Приложения:** Прототипы, схемы API, диаграммы данных.

• Использование четких критериев приемки (Acceptance Criteria): Для каждой истории или функции прописываем условия, при которых она считается выполненной. Это основа для тестирования.

  # Пример критериев приемки для истории о сбросе пароля
  Feature: Сброс пароля пользователя
    Scenario: Успешный запрос на сброс пароля
      Given Пользователь находится на странице входа
      When Он нажимает ссылку "Забыли пароль?"
      And Вводит зарегистрированный email и нажимает "Отправить"
      Then Система показывает сообщение "Инструкции отправлены на ваш email"
      And На указанный email отправляется письмо с уникальной ссылкой для сброса
  

4. Согласование, итерации и базирование

• Проведение очных или онлайн-сессий защиты ТЗ: Поочередно проходим по каждому разделу, разъясняю технические нюансы, фиксируем замечания.
• Ведение реестра требований (Requirements Traceability Matrix): Позволяет отслеживать связь между бизнес-целью, требованием, задачей в Jira и тест-кейсом. Это ключ к управлению изменениями.
• Подписание версии 1.0: После устранения всех противоречий ТЗ утверждается всеми сторонами и становится базовой версией (baseline). Любые последующие изменения формально проходят через процесс управления изменениями (Change Request Process).

Ключевые принципы успеха:

• Постоянная коммуникация: Регулярные встречи, использование общих досок (Miro), прозрачность процесса.
• Общий язык: Искореняем жаргон, объясняю технические моменты на бизнес-примерах, и наоборот.
• Фокус на ценности: Каждое требование должно быть связано с бизнес-целью из Vision. Постоянно задаю вопрос: «Какую проблему клиента это решает?».
• Гибкость и реализм: Помогаю клиенту осознать компромиссы между сроком, бюджетом и функционалом («Железный треугольник»). Часто MVP (Minimum Viable Product) оказывается оптимальным стартом.

Итоговое ТЗ — это не просто документ для «галочки», а рабочий контракт и навигационная карта для всей команды, который минимизирует риски недопонимания и является фундаментом для успешной реализации проекта.