В прошлой статье мы разобрали исследование, где 43 из 68 работ указали на размытые требования как корень неверной оценки сроков.
И пообещал разобрать — что конкретно должно быть в документе, чтобы не влетать в бесконечные доработки.
Давайте на чистоту. Мы не так часто вносим правки в геймдизайн документы.
Получил GDD — сел делать. А потом неделя за неделей всплывают кейсы, которые никто не описал. Вот оно, расширение сроков.
🔸Функциональные требования
По IEEE 1471-2000 (это то самое определение архитектуры ПО по стандарту), у стейкхолдеров есть viewpoint — видение того, как система должна работать. На практике этот viewpoint и есть GDD.
Уже из него программисты должны формировать architectural description (AD) — техническую документацию по сути. В геймдеве AD почти никто не делает, потому все обычно прописывается в GDD (viewpoint).
Хороший GDD содержит:
▫️Функциональное описание механик
▫️Визуальное видение: мокапы, скетчи, референсы
▫️Краевые случаи
▫️Пользовательские истории
🔸User Stories — лучший формат
Пользовательские истории — описание требований с точки зрения пользователя, а не внутренней реализации. Вместо "выдаем награду при окончании боя" — "если бой окончен, то я вижу экран награды".
Почему это работает:
▪️Иерархическая структура "если … то …" один в один ложится в код
▪️QA берет документ и сразу получает список кейсов для проверки
▪️Легко инвертировать: "а что если НЕ?" — и ты находишь пропущенные краевые случаи
Они делятся на два типа:
▫️Happy path — основной поток без ошибок
▫️Alternative path — что происходит когда что-то пошло не так
Пример:
— Happy: если я нажму кнопку "Купить", я увижу подтверждение покупки
— Alt 1: если у меня недостаточно валюты, я увижу предложение пополнить баланс
— Alt 2: если во время покупки пропал интернет, я увижу сообщение об ошибке и мой баланс не изменится
Happy path прямолинеен и понятен. А вот устойчивые системы отличаются проработкой alternative path.
Именно на них тратится 80% усилий и именно они формируют стабильность приложения.
🔸Нефункциональные требования
Вот тут начинается самое интересное. Геймдизайнер пишет: "два игрока стреляют в мишень по очереди". Задача на 5 дней, да?
А теперь в комнату заходят нефункциональные требования:
▫️Соединение двух игроков → сервер
▫️Авторизация → база данных
▫️Синхронизация данных → протокол обмена
▫️Потеря соединения → механизм переподключения
▫️Таймаут ожидания → логика прерывания сессии
Одна строчка в GDD превратилась в инфраструктурную задачу. И это не исключение — это норма.
Нефункциональные требования — это все, что подразумевается, но не написано:
— Приложение загружается меньше 30 секунд.
— Игра не лагает.
— При разрыве соединения прогресс не теряется.
Всё "очевидное", что никто не удосуживается описать — и что потом сдвигает сроки.
🔸Как находить пропущенное
Большая ошибка — не участвовать в уточнении документов. Это часть профессиональной компетенции разработчика.
Два способа проверять документы на полноту:
1️⃣ Строишь execution path — проходишь каждый шаг user story и пытаешься сломать его. "А что если НЕ нажал?" "А что если сервер не ответил?" "А что если два события одновременно?" Каждый else, который не описан — это пропущенное требование.
2️⃣ Скармливаешь документ GPT и просишь найти проблемы. Серьезно. Он находит пропущенные краевые случаи, нестыковки и неоднозначности быстрее, чем ты прочитаешь документ второй раз.
Критерий простой:
Если в процессе чтения документа или написания кода тебе нужно что-то додумывать — значит этот момент не был учтен в требованиях.
🔻 Требования — это про снижение полиморфности системы. Чем точнее описан документ, тем меньше ты додумываешь, тем ближе результат к ожиданиям стейкхолдеров и тем точнее оценка сроков.
И только так, лично у меня, получается без всяких НО планировать и сдавать задачи в срок.
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#проектирование@UniArchitect