Урок 7 из 8 · 20 мин · обновлено

Документация и работа с командой

Как аналитик оформляет требования — техническое задание, спецификация, страницы в вики, задачи в трекере, — как согласует их с заказчиком и командой, ведёт изменения и сопровождает разработку.

Какой бывает документация

  • Техническое задание (ТЗ) — большой документ со всеми требованиями к системе. Часто нужен в госзаказах, интеграциях с внешними компаниями, когда работа идёт по договору.
  • Спецификация функции — подробное описание одной функции: «Программа лояльности».
  • Страницы в вики — внутренней базе знаний компании: живая документация, которую обновляют по ходу.
  • Задачи в трекере — пользовательские истории и задачи с критериями приёмки и ссылкой на спецификацию. Как работают трекеры — курс «Jira и Scrum».

В гибкой разработке большие ТЗ встречаются реже: требования живут в вики и задачах и уточняются по ходу. Но принципы одни.

Структура хорошего документа

Спецификация функции «Программа лояльности»:

  1. Цель и контекст — зачем делаем: увеличить повторные заказы.
  2. Термины — что такое «балл», «начисление», «списание», чтобы все понимали одинаково.
  3. Пользователи и роли — гость, бариста, менеджер.
  4. Сценарии — use case и пользовательские истории (урок 3).
  5. Функциональные и нефункциональные требования (урок 2).
  6. Схемы — процесс, последовательность, состояния (урок 4).
  7. Данные — сущности и атрибуты (урок 5).
  8. Интеграции — методы API (урок 6).
  9. Открытые вопросы — что ещё не решено и кто отвечает.
  10. История изменений — что, когда и почему изменилось.

Пишите так, чтобы документ понял новый человек в команде: коротко, конкретно, с примерами, без «и т. д.» и «прочее».

Согласование

До начала разработки требования согласуют:

  • заказчик подтверждает, что это то, что нужно бизнесу;
  • разработчики — что это реально сделать и понятно, как;
  • тестировщики — что требования проверяемы.

Удобно проводить ревью требований — встречу, где вместе проходят по документу. Вопросы, которые там всплывают, обходятся гораздо дешевле, чем переделки после разработки.

Изменения и сопровождение

Требования меняются: бизнес передумал, нашлись новые исключения, партнёр изменил API. Правила:

  • фиксируйте изменения в документе с датой и причиной, а не только в чате;
  • сообщайте команде и обновляйте связанные задачи;
  • оценивайте влияние: что ещё затронет изменение, сколько работы добавит.

Во время разработки аналитик отвечает на вопросы команды — быстро и письменно в задаче, чтобы ответ видели все. А в конце принимает результат: проверяет по критериям приёмки, что сделано то, что описано.

Попробуйте сами. Заказчик в середине спринта пишет в чат: «Давайте баллы будут не 5%, а 7%, и только по будням». Что вы сделаете, по шагам?

Пример ответа
  1. Уточнить: почему решили, с какой даты, что с заказами, уже оплаченными по 5%? Что считать будним днём — день оплаты или выдачи? Что с праздниками?
  2. Оценить влияние вместе с разработчиками: правило «только по будням» — новая логика, а не просто другое число; затронет начисление, тексты в приложении, правила программы.
  3. Обсудить с владельцем продукта, входит ли это в текущий спринт или идёт в следующий.
  4. Обновить документацию: требования, критерии приёмки, историю изменений с датой и причиной.
  5. Обновить задачи в трекере и сообщить команде, включая тестировщиков.
  6. Подтвердить письменно заказчику итоговое решение.

Мини-тест: проверьте себя

Закрепите урок: несколько вопросов, разбор ответов — в конце.

  1. Где лучше фиксировать договорённость об изменении требования?

  2. С кем аналитик согласует требования до начала разработки?

  3. Что делает аналитик, когда разработка уже идёт?