Кейс: спецификация, которую никто не читает
Вопрос
В команде пишут спецификации на 30 страниц, но разработчики их не читают и постоянно переспрашивают. Что изменишь?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Выяснить у разработчиков и тестировщиков, что им мешает и что нужно
Структура: короткое резюме и цель вначале, детали ниже, ссылки вместо копий
Форматы под читателя: таблицы правил, диаграммы, примеры запросов
Совместный разбор спецификации на refinement до разработки
Метрика: число уточнений и багов из-за требований
Что могут спросить следом
- Как понять, что стало лучше?
- Нужно ли сокращать объём любой ценой?
Разбор
Сначала спрошу разработчиков и тестировщиков, что мешает: часто проблема в том, что нужное спрятано среди общего текста. Перестрою документ: наверху цель и краткое описание изменений, дальше сценарии, бизнес-правила таблицей, контракты API ссылкой на OpenAPI, диаграммы вместо абзацев, примеры запросов и ответов. Убираю копии того, что живёт в других местах. Ввожу совместный разбор спецификации на refinement: 30 минут разговора экономят дни переписки. Смотрю на метрику: сколько вопросов и багов возникает из-за требований. Объём важен меньше, чем то, насколько быстро человек находит нужное.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.
Предыдущий вопрос
Кейс: ТЗ для регионального портала услуг
Следующий вопрос
Изменение требований после согласования
Термины по теме
Ещё по теме «ТЗ, ГОСТ 34 и документирование»
- Базовая линия требований
- Docs as code
- Структура спецификации фичи
- Разделы ТЗ по ГОСТ 34.602-2020
- SRS
- Зачем глоссарий
- Действующий стандарт на ТЗ
- Стадии создания АС