Кто должен писать ТЗ?

Кто должен писать техническое задание (ТЗ)?

Вопрос о авторстве технического задания (ТЗ) является одним из фундаментальных в управлении IT-проектами, и однозначного ответа на него нет. Ответ зависит от модели проекта, организационной структуры, сложности продукта и доступных ресурсов. Однако, исходя из моего опыта управления проектами, я могу выделить несколько ключевых подходов и принципов.

Основные модели авторства ТЗ

В классической водопадной модели (Waterfall) или при работе по фиксированному контракту, где требования должны быть четко фиксированы до начала разработки, процесс создания ТЗ часто централизован и формализован. Здесь могут быть следующие варианты:

• Системный аналитик или бизнес-аналитик — это идеальный вариант. Этот специалист выступает как «переводчик» между бизнесом и технической командой. Он собирает потребности от клиента или бизнес-спонсора, анализирует их, структурирует, прорабатывает детали и оформляет в виде формального документа.

  # Пример структуры данных в ТЗ для аналитика (в реальности это текстовый документ)
  # Раздел "Функциональные требования"
  requirements = {
      "user_registration": {
          "description": "Форма регистрации нового пользователя",
          "inputs": ["email", "password", "full_name"],
          "validation_rules": {"email": "regex_pattern", "password": "min_length_8"},
          "outputs": ["success_message", "user_id_in_database"]
      }
  }
  

• Проектный менеджер — в небольших компаниях или при отсутствии аналитика эту функцию часто берет на себя менеджер. Его преимущество — глубокое понимание целей проекта и ограничений (время, бюджет). Риск — возможный недостаток технической экспертизы для детализации требований.
• Архитектор или ведущий разработчик — иногда, особенно для технически сложных или инфраструктурных проектов, ТЗ лучше пишет технический лидер. Он может наиболее точно описать системы, интеграции, API и технические ограничения.

В современных гибких методологиях (Agile, Scrum) понятие единого, статичного ТЗ трансформируется. Здесь требования живут и меняются.

• Продуктовый владелец (Product Owner) — в Scrum это ключевая роль. PO отвечает за максимизацию ценности продукта и бэклог продукта (Product Backlog). Он формулирует требования в виде стейментов пользователя (User Stories) и критериев приемки (Acceptance Criteria). Техническое задание в классическом смысле заменяется постоянно обновляемым бэклогом.

  // Пример User Story в формате Connextra
  // Как <Роль пользователя>,
  // я хочу <Функциональность>,
  // чтобы <Бизнес-ценность/цель>.
  String userStory = "Как зарегистрированный пользователь, " +
                     "я хочу фильтровать список товаров по цене, " +
                     "чтобы быстро найти наиболее бюджетные варианты.";
  

• Команда в целом — в Agile процесс выработки требований часто коллективный. Разработчики, тестировщики и дизайнеры участвуют в их проработке на планировании спринта (Sprint Planning) и рефинементах бэклога (Backlog Refinement). Фактически, ТЗ (в виде детализированных историй и задач) пишется совместно.

Ключевые принципы и выводы

На практике я руководствуюсь следующими принципами:

1. Ответственность должна быть четко назначена. Независимо от того, кто физически пишет текст, должна быть явно назначенная роль (Аналитик, PO, PM), которая несет ответственность за полноту, точность и актуальность требований.
2. ТЗ — это результат коммуникации, а не единоличного творения. Идеальный ТЗ рождается в коллаборации: бизнес / клиент предоставляет потребности и цели, аналитик / PO структурирует их, техническая команда (архитекторы, разработчики) оценивает реализуемость и предлагает решения, тестировщики думают о критериях качества.
3. Качество важнее авторства. Независимо от автора, ТЗ должно соответствовать критериям:

    *   **Понятность** для всех сторон (бизнес, разработка, тестирование).
    *   **Полнота** и отсутствие противоречий.
    *   **Тестируемость** — требования должны быть проверяемыми.
    *   **Реализуемость** с учетом технических и ресурсных ограничений.

1. Процесс важнее документа. В Agile ценность представляет не документ «ТЗ», а живой процесс постоянного обсуждения, детализации и приоритизации требований, который обслуживает команда разработки.

Таким образом, прямым ответом будет: ТЗ должен писать тот, кто обладает наибольшей экспертизой для превращения бизнес-потребностей в четкие, выполнимые инструкции для команды разработки, и этот процесс должен быть максимально вовлекающим для всех ключевых стейкхолдеров проекта. В большинстве современных проектов это либо Бизнес-аналитик, либо Продуктовый владелец, выступающие как центральные узлы в сети коммуникации между бизнесом и технической командой.