Где пишешь ТЗ?

Где и как я пишу Техническое Задание (ТЗ) в IT-проектах

Как IT Project Manager с 10+ лет опыта, я рассматриваю Техническое Задание (ТЗ) не как единый документ, созданный в одном месте, а как живой артефакт проекта, который эволюционирует и существует в нескольких взаимосвязанных формах и инструментах. Место его написания напрямую зависит от фазы проекта, аудитории и требований к совместной работе.

Основные "места" создания и хранения ТЗ

Я использую комбинацию следующих инструментов и платформ:

1. Специализированные инструменты для управления требованиями и документацией:

    *   **Confluence:** Это основная "витрина" и источник истины для финальных, согласованных версий ТЗ. Здесь структурируются разделы, ведется история изменений, настраиваются разрешения и интеграции с Jira.
    *   **Notion / Google Docs:** Часто использую на ранних этапах для быстрого совместного мозгового штурма, черновиков и сбора первоначальных требований от стейкхолдеров, благодаря удобному режиму реального времени.

1. Системы управления проектами и задачами (как детализированная часть ТЗ):

    *   **Jira / Azure DevOps / YouTrack:** Сами **User Stories**, **Epics** и **Tasks** с четкими критериями приемки (**Acceptance Criteria — AC**) являются исполняемой, атомарной частью ТЗ. Связь между кодом, тестами и требованием становится прозрачной.

```markdown
// Пример User Story в Jira как часть ТЗ:
**Epic:** Разработка личного кабинета пользователя.
**Story:** US-42 - Возможность смены пароля.
**Описание:** Как авторизованный пользователь, я хочу иметь возможность изменить свой пароль в настройках профиля, чтобы обеспечить безопасность аккаунта.
**Критерии приемки (AC):**
1. В разделе "Настройки безопасности" отображается кнопка "Изменить пароль".
2. При нажатии открывается модальное окно с полями: "Текущий пароль", "Новый пароль", "Подтверждение нового пароля".
3. Система валидирует, что "Текущий пароль" совпадает с действующим.
4. Система проверяет сложность "Нового пароля" (мин. 8 символов, буквы в разном регистре, цифра).
5. Поля "Новый пароль" и "Подтверждение" должны совпадать.
6. После успешной смены пароля система показывает toast-уведомление об успехе и разлогинивает пользователя.
```

3. Диаграммы и модели (для визуализации требований):

    *   **Miro / FigJam / Draw.io:** Использую для создания **BPMN** (Business Process Model and Notation), **UML**-диаграмм (Use Case, Sequence, State), карт пользовательских путешествий (**User Journey Maps**), wireframes. Эти визуальные артефакты — неотъемлемая часть ТЗ, делающая сложные процессы понятными.

1. Репозитории кода (для технических спецификаций):

    *   **Git (GitLab, GitHub, Bitbucket):** Технические детали, API-контракты (например, в формате **OpenAPI/Swagger**), архитектурные решения часто документируются прямо в репозитории в виде `README.md`, `ADR` (Architecture Decision Record) или в вики. Это обеспечивает близость документации к коду.

```yaml
# Пример фрагмента OpenAPI-спецификации в репозитории (часть ТЗ для API)
paths:
  /api/v1/user/password:
    put:
      summary: Смена пароля пользователя
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/PasswordChangeRequest'
      responses:
        '200':
          description: Пароль успешно изменен
```

Мой процесс и принципы

Само "написание" — это процесс, а не разовое действие:

• Итеративность: ТЗ редко рождается в готовом виде. Мы начинаем с Vision & Scope документа или Product Requirements Document (PRD) в Confluence, затем детализируем в виде пользовательских историй и прототипов.
• Коллаборация: ТЗ пишется вместе с командой (аналитиками, разработчиками, тестировщиками, дизайнерами) и ключевыми стейкхолдерами. Сессии по уточнению требований (Backlog Refinement) — ключевой формат.
• Единственный источник истины (Single Source of Truth): Я стремлюсь к тому, чтобы каждая часть требования была описана единожды и в нужном месте, а все инструменты были связаны (например, ссылка из Jira-таска на Confluence и на макет в Figma).
• Живой документ: ТЗ обновляется по мере поступления новых знаний, изменений на рынке или корректировок приоритетов. Устаревшее ТЗ хуже, чем его отсутствие.

Итог: Я не пишу ТЗ в одном конкретном месте. Я формирую и управляю совокупностью артефактов (документы, задачи, диаграммы, прототипы, API-спецификации), которые вместе составляют полное, понятное и исполняемое Техническое Задание. Ключевые инструменты — Confluence как хранилище согласованного знания и Jira как движок для исполнения, связанные с другими специализированными сервисами для дизайна, прототипирования и документирования кода.