Ответ вслух Middle ТЗ, ГОСТ 34 и документирование обновлено

Кейс: спецификация, которую никто не читает

Вопрос

В команде пишут спецификации на 30 страниц, но разработчики их не читают и постоянно переспрашивают. Что изменишь?

Попробуйте сами

Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.

Показать ответ и разбор

Коротко

Сначала спрошу разработчиков и тестировщиков, что мешает: часто проблема в том, что нужное спрятано среди общего текста. Перестрою документ: наверху цель и краткое описание изменений, дальше сценарии, бизнес-правила таблицей, контракты API ссылкой на OpenAPI, диаграммы вместо абзацев, примеры запросов и ответов.

Что должно прозвучать в ответе

  • Выяснить у разработчиков и тестировщиков, что им мешает и что нужно

  • Структура: короткое резюме и цель вначале, детали ниже, ссылки вместо копий

  • Форматы под читателя: таблицы правил, диаграммы, примеры запросов

  • Совместный разбор спецификации на refinement до разработки

  • Метрика: число уточнений и багов из-за требований

Что могут спросить следом

  • Как понять, что стало лучше?
  • Нужно ли сокращать объём любой ценой?

Разбор

Сначала спрошу разработчиков и тестировщиков, что мешает: часто проблема в том, что нужное спрятано среди общего текста. Перестрою документ: наверху цель и краткое описание изменений, дальше сценарии, бизнес-правила таблицей, контракты API ссылкой на OpenAPI, диаграммы вместо абзацев, примеры запросов и ответов. Убираю копии того, что живёт в других местах. Ввожу совместный разбор спецификации на refinement: 30 минут разговора экономят дни переписки. Смотрю на метрику: сколько вопросов и багов возникает из-за требований. Объём важен меньше, чем то, насколько быстро человек находит нужное.

Ответьте сами, а не прочитайте

В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.

Термины по теме