Баньте этого

/ban -k addtele

чтобы команду набрать, нужен питч, вроде бы

Если ты сейчас засядешь за написание диздока, то этим всё может и закончиться

Больше полу года работаю гейм дизайнером и пока составить диздок чтобы ни у кого не возникло ни одного вопроса - не получилось (кстати отметил для себя, что для художников проще, они сами додумают если ты не указал какого цвета пуговицы должны быть на манжетах, а вот если ты программисту не написал в доке как внутреигровой календарь должен реагировать на высокостный год в случае если во время карантина рак на горе таки свиснул - то девелоперы сами не додумают)))) )

Но возможно это я просто туповатый и никак не могу нормальные доки команде писать)

))) +10% в эфире это круто

а чего не 50%

То же самое, абсолютно каждую запчасть, об которую столкнутся на стадии реализации, нереально учесть, поэтому диздоки всегда дополняются по ходу пьесы)

Предусмотреть все все кейсы вот так сходу, еще и когда ограничен во времени практически невозможно, если возможно вообще. Я для интереса начал вести метрику "Количество вопросов на механику в доке по фиче" +)

Уже 5 лет работаю. Сделать описание таким чтобы прям все кейсы описать получается редко. Возникают вопросы и это нормально
Самый оптимальный стиль написания документации что я нашел - краткое тезисное описание функционала фичи.
Без использования фраз, которые могут быть поняты двояко. Без сложных словесных оборотов

Вот не надо тут. Программисты всё додумывают за геймдизайнерами, просто не делают это ибо это не описано ))))

У нас так: гд отвечает на вопросы лично или в слаке. Если что-то серьёзное, что может многим в команде пригодиться - то в диздок вносится. Каждую пуговку прописывать смысла нет.

а потом одному ответил А, другому Б и вышло В

С другой стороны даже самый кривой мокап интерфейса может часы, а то и дни работы сэкономить

писать требования надо под конкретного человека, а не "для программиста".

Кому-то текст понятнее, кому-то схема, кому-то макеты окон, флоумап.

Наиболее надёжный в моей практике способ составления требований - описать как всё это выглядит со стороны пользователя по этапам ("игрок жмёт кнопку - происходит то-то"). Детали реализации в данном случае излишни.

Негативные кейсы нужно описывать (не хватает денег, нет интернета и т.п.) - программист не должен "додумывать", т.к. "додумку" потом будет тестировать тестировщик и так или иначе вопрос "как это должно работать" всё равно прилетит ГД.

Всегда устраивать встречи перед реализацией фичи для синхронизации вижена, вопросов и т.п.

Ну и дружить надо со своими программистами, давать им влиять на требования, мотивировать давать обратную связь - это будет только в том случае, если ты их слышишь.

Да это то понятно. никто ж не спорит.

Это хорошо, когда ты можешь точно знать, кто именно будет делать фичу. Но в большинстве случае решает это лид программист. Поэтому особо подстраиваться под человека не получится.

какие-то вещи всё равно можно контролировать, степень детализации например (в зависимости от опыта человека на проекте), погружение в контекст