Что такое дизайн документ

Как написать диздок

Запрос «как написать диздок», заданный в любой поисковик, даёт немало ответов, представляющих собой как перевод западных статей, так и авторские размышления на эту тему из России, или даже дизайн проекта «Курочка Ряба». В воображении читателя предстает большой единый документ, описывающий идею и геймплей игры с перечислением всех ее фич. Возможно, читатель однажды приходит с такими идеями работать геймдизайнером в крупную российскую или западную компанию, на крупный проект… И обнаруживает, что таких документов больше не существует.

О том, как написать диздок, который существует в крупных компаниях (автор этих строк работал с документацией Obsidian Entertainment, Allods Team, Raven Software, The Workshop, Slightly Mad Studios, преподает курс проектной документации в геймдизайне в Высшей школе бизнес-информатики НИУ ВШЭ на программе профессиональной переподготовки Менеджмент игровых интернет-проектов), и будет эта краткая статья. Разумеется, кому-то описанное в ней может показаться очевидным. Она рассчитана на тех, кто как раз ищет ответы на вопросы «как написать диздок» или хочет устроиться работать геймдизайнером в крупную компанию-разработчика.

Проектная документация сейчас представляет собой не большой дизайн-документ, не набор файлов MS Office, и даже не файлы в Google Docs.

Концепт-документ прост и используется для «закладывания фундамента» последующей документации, а также для того, чтобы новый сотрудник, инвестор или журналист могли быстро понять суть проекта.

Третий же документ Feature List представляет собой «разбор» описанной двумя предыдущими документами игры на компоненты. Это мостик к, собственно, разработке. Сообразно описанному в нем, продюсер или иной руководитель может составлять планы, рассчитывать майлстоуны, спринты и многое другое, но эта тема достойна отдельной статьи.

Простой же геймдизайнер, утроившись на работу в крупную компанию, вряд ли будет составлять вышеописанные три документа, но прочитать и запомнить их придётся. Основное время геймдизайнера уходит на последующий уровень — самый масштабный по объему. Это диздоки конкретных фичей, описанных в Vision и Feature List’е. К примеру, дизайн ездовых животных или дизайн нанесения клановых эмблем на броню… Впрочем, есть и куда более масштабные: дизайн системы характеристик персонажа или дизайн развития базы игрока.

Конечно же, написание диздока на этом уровне сильно зависит от конкретной фичи – это может быть как вики-документ из 10 строк, так и целый раздел с десятком вложенных документов, прикрепленными таблицами с расчетами и ссылками на собранную статистику с серверов игры.

На этой радостной ноте моя краткая статья заканчивается. Надеюсь, она была вам интересна. И можно переходить к комментариям!

Источник

Как написать дизайн-документ для игры

Оставьте надежду, если вы разрабатываете игру без диздока, потому что она вряд ли доживёт до релиза. Объясняем, зачем и как составлять диздок.

Дизайн-документ (сокращённо — диздок) — это документ, в котором содержится вся информация о создаваемой игре. Он нужен, чтобы команда, которая будет работать над проектом, понимала, что в итоге должно получиться.

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

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

В этой статье вы узнаете, что может быть в диздоке, а что там не нужно, как его составить и какие инструменты для этого использовать.

Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.

Какие инструменты использовать для создания диздока

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

Обычно я создаю папку для проекта и добавляю в неё всё: сам диздок, папку с референсами, технические задания и прочее.

Если нужно составить какую-то схему, то я пользуюсь бесплатным сервисом draw.io. В нём можно создавать что-то подобное:

Для подготовки референсов я использую GIMP (графический редактор с открытым исходным кодом) или просто делаю скриншоты и записываю экран.

Диздок — это не:

Диздок — это

подробное описание всех аспектов игры. Для удобства его можно разбить на разделы: общая информация, геймплей, сюжет, визуал и так далее. В общем разделе можно написать следующее:

Можно добавить и другие пункты, лишними подробности не будут.

Описание игровых механик и управления

Все игровые механики важно описывать очень точно. Например, вы можете указать, что игрок будет сражаться с врагами, убивать монстров и захватывать замки. Под это описание подходят как Heroes of Might and Magic, так и World of Warcraft, а они сильно различаются.

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

Кнопка E — взаимодействие с предметом или персонажем.

Взаимодействие с предметом или персонажем: игрок наводит курсор на объект и нажимает клавишу E. Тип взаимодействия зависит от типа объекта:

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

Сами же взаимодействия можно оформить в виде таблицы:

Источник

С чего начинаются видеоигры (ч. 2): дизайн-документ

Содержание:
1. Теория (что такое дизайн-документ, из чего он состоит);
2. Практика (пример рабочего дизайн-документа);
3. Итоги (видеоигра, сделанная по дизайн-документу).

«Слово „трудность“ совершенно не должно существовать для творческого ума»

Вступление,
которое связывает текст с предыдущей частью
и вносит в него лёгкую философскую нотку

Вооружившись знаниями из первой части и потренировавшись в составлении концепт-документа «на кошках», самое время переходить к дальнейшей работе! На очереди – дизайн-документ. Иногда его ещё называют «диздок», реже – «ДД», а особые языковые садисты именуют «ГДД» (вероятно, от английского Game Design Document) и «Вижн» (от английского Vision – подразумевается «ви́дение игры»). Пожалуйста, не будьте языковыми садистами.

Теория,
которая могла выглядеть сплошной стеной текста,
если бы не две картинки

Дизайн-документ – полное описание будущей видеоигры. От своего предшественника, концепт-документа, отличается максимально возможной детальностью и проработкой каждого затрагиваемого аспекта – это и механики, и уровни, и сюжет, и интерфейс, и вообще всё, что должно быть в игре. В определённом смысле дизайн-документ можно назвать подробным планом, в котором указано, что надо делать, но не указано кем и как (для этого существуют другие документы).
Дизайн-документ составляют для упрощения работы и повышения её эффективности. Большинство видеоигр включают в себя такое количество компонентов и взаимосвязей, которое не влезет ни в одну голову. А ведь есть ещё коллеги, они нуждаются в актуальной информации и если не смогут найти её «на бумаге», то начнут постоянно задавать вопросы. При вербальном обмене информацией сначала что-то забудется, затем вспомнится то, чего не было, потом перепутается всё, что уже есть, – и так снова и снова. Результаты обычно не радостные:
а) многократные переделки одних и тех же элементов;
б) дублирование работы;
в) хаос во взаимодействии с коллегами;
г) постепенное разноплановое изменение общей структуры и, как следствие, нарушение целостности готовой видеоигры.

Разработка игры без документации

С помощью дизайн-документа всего вышеперечисленного легко избежать или, по крайней мере, снизить до терпимого минимума. Ответственным за эту работу назначается игровой дизайнер (он же геймдизайнер, иногда – гейм-дизайнер (от английского game designer) – в общем, название профессии распространённое, но не устоявшееся в написании). Он необязательно будет один – всё зависит от сложности разрабатываемой игры. Так, например, над документацией ролевой игры количество трудящихся игровых дизайнеров может считаться не в «человеках», а в отделах. Небольшие же аркады, головоломки, платфомеры, «сайд-скроллеры» и прочие им подобные видеоигры менее требовательны, и для их разработки порой достаточно не только одного игрового дизайнера, но и вообще одного человека.
Как и в случае с концепт-документами, при составлении диздока опираются не на официальные правила типа ГОСТа (их просто нет), а на здравый смысл и проверенные временем и опытом общие рекомендации.

5. Игровые объекты.
То, что располагается на уровнях, и то, с чем игрок может взаимодействовать. Объекты, на которые можно запрыгнуть, подлезть под них, обойти, упереться лбом (кроме стен уровня). Объекты, которые можно толкнуть, собрать, перетащить, выбросить, уничтожить или пораниться при столкновении. Одним словом – список. В него скрупулёзно вносится всё до последнего пикселя. Если у объектов есть характеристики и свойства, они тоже указываются (вес, количество единиц здоровья, изменение чего-либо при активации – добавление патронов или брони, уменьшение энергии). И чем больше таких вот характеристик, тем менее понятно будет выглядеть список, если делать его в виде простого перечисления. На помощь придут лучшие друзья игрового дизайнера – таблицы.
6. Сюжет.
История мира, описания персонажей и монстров, диалоги, задания – всё, что относится к литературно-художественному тексту.
7. Система звуков и музыки.
Заполнение данного пункта может вызвать проблемы у игровых дизайнеров, начисто лишённых музыкального слуха, но кое-какие действия выполнить придётся. Указать количество музыкальных композиций и, по возможности, их жанровую принадлежность. Перечислить объекты, которые должны издавать звуки, и дать краткое описание: звук падающего камня, звук лазерного выстрела, звук сменяемой обоймы, звук мотора.
При необходимости добавляются данные о персонажах, которых необходимо озвучить: количество, половая принадлежность, возраст, особые приметы (акцент, хрипение).
В некоторых видеоиграх звуки и музыка являются не дополнением, а частью или основой игрового процесса: ритм-игры; представители жанров «стелс» и «хоррор», где важно слушать и слышать. Здесь важно составить и расписать систему от и до: какие действия должен совершать игрок при прослушивании музыки, какая погрешность допускается при ошибочных действиях; на каком расстоянии затихают звуки, каков радиус слышимости у персонажей.
8. Система сохранений и загрузок.
Сохранения условно можно разделить на два типа – автоматические и ручные. Разница между ними в том, что первые происходят при заданных разработчиком условиях и без вмешательства игрока (например, через расположенные на уровне контрольные точки), а выполнение вторых зависит исключительно от игрока – человек должен нажать кнопку «Сохранить», иначе достигнутый им прогресс будет утерян. К типу системы добавляется список объектов и значений, которые должны сохраняться и загружаться.
9. Система социального взаимодействия.
Социум – это люди, и варианты игрового общения с ними должны найти отражение в дизайн-документе. Хороший пример – массовые многопользовательские онлайн-игры, сама их суть сводится к постоянному взаимодействию – и ради достижения целей, и так, из любви к искусству. Однако не ММО едиными! Социальная сторона одиночных видеоигр может выражаться таблицами рекордов, достижениями, локальным и кооперативным мультиплеером, обменом предметами.
10. Система ролевых элементов.
РПГ (от английского RPG – role-playing game) – видеоигра, в которой нужно отыгрывать роли. Абсолютно любые роли – важен сам факт, а не конечный набор. Механики отыгрыша создают относительную свободу действий, вариативность игровых элементов и способствуют многократным повторным прохождениям с отличающимся результатом. Подобные возможности вызывают у игроков настолько большой интерес, что другие жанры нередко заимствуют элементы РПГ для собственного улучшения и развития.
Примеры ролевых элементов:
а) выбор персонажей и прокачка их характеристик;
б) взаимодействие с игровым миром и влияние на него;
в) «деревья» навыков и диалогов (выбор пути развития);
г) свобода перемещения.
При работе с системой ролевых элементов стоит учитывать, что каждый новый вариант развития значительно повышает сложность её составления и последующего тестирования.

На этом основные пункты заканчиваются. Какие-то из них могут оказаться лишними, о других не упомянуто в силу их меньшей распространённости, третьи пока ещё не существуют. Главное, что нужно понимать: чем больше информации об игре упорядочено и записано в дизайн-документ, тем проще будет работать. И речь идёт не столько о игровом дизайнере (хотя проще будет и ему, безусловно), сколько о его коллегах – это те самые люди, которые превращают документацию в рабочий продукт.
Забота о коллегах проявляется и в поддержании чистоты: в дизайн-документе нет места заметкам, размышлениям, сомнениям, неточностям, двояким толкованиям, шуткам (если они не являются частью сюжета). Лишнее должно оставаться в черновиках.

Уже не теория,
ещё не практика

Дизайн-документ – это, в основном, текст и цифры (расчёты, формулы, графики). Инструменты для работы соответствующие – текстовые редакторы и электронные таблицы.
1. Локальные редакторы и таблицы (например, «Ворд» и «Эксель»).
К достоинствам можно отнести расположение файлов (к ним всегда есть доступ) и удобство работы (полный набор возможностей, оформление, простота использования). К недостаткам – сложности с получением доступа у других людей, проблемы навигации (диздок не всегда представляет собой один большой файл, чаще он разбит на логические части, каждая часть – в отдельном файле, и если все они – локальные «вордовские» и «экселевские» документы, то ориентироваться в них непросто).
2. Облачные редакторы и таблицы (например, «Гугл документы», «Яндекс.Диск»).
Плюсы и минусы предыдущего пункта меняются местами. Доступ к облачным документам легко выдать любому количеству людей, проблема навигации исчезает благодаря гиперссылкам и их более удобному использованию. Заплатить за это придётся урезанными возможностями оформления и вечным удалённым доступом (нет интернета? заблокировали учётную запись? увы).
3. Корпоративные редакторы и таблицы (например, решения на основе вики-движка).
Объединение двух предыдущих пунктов – облачный инструмент, который находится в локальной сети.

Пара слов,
которые влезли без очереди

Конечно же, каждый человек волен вести документацию так, как велит его творческая натура. Однако единообразие и умеренная серьёзность ещё никому не вредили.

Практика,
которая поможет закрепить теорию

Источник

Диздок, или написание проектной документации

Диздок упоминают в разговорах, о нём шепчутся на форумах, примеры его ищут и зелёные новички, и бывалые разработчики. Случается, что под тусклым светом уличного фонаря происходит сделка. Фигура в тёмном капюшоне украдкой передаёт ссылку на «Месть курочки Рябы». Конечно, таинственный гонец не имеет злого умысла, но деяние совершено…

Техуманитарный диздок

Однако что такое «диздок»? – может спросить читатель. В двух словах – это написанная «на бумаге» игра. К такому документу обращаются за информацией все участники команды разработчиков. Тут можно найти описание геймплейных механик, математические модели баланса, разветвлённый сюжет игры, указания музыканту, список звуков и визуальных эффектов… По крайней мере этому нас учат «классические» примеры диздоков. Самым известным из них в России является, конечно, документ «Месть курочки Рябы» из далёкого 2004-го года. А вот ещё один экземпляр заготовки диздока, намедни попавший мне на глаза на Reddit’е.

Как видите, структура у них крайне похожа – документ предназначен одновременно для всех и ни для кого. Он написан «техуманитарным» языком, который уже теряет смысл для программиста, но ещё недостаточно понятен для художника. К тому же колоссальный размер диздока ведёт за собой сложность навигации, чтения, поддержания текста в чистом и актуальном состоянии. Вам, должно быть, знаком термин «информационный шум»; участники команды будут сражаться именно с этой проблемой в поисках нужной информации. Если гранд-мастер гейм-дизайна 90-го уровня и сможет управляться с возникающими сложностями, то подумайте о новичках, какой диздок напишут они?

На этой сногсшибательной ноте я хотел бы предложить альтернативный вариант диздока, основанный на гранулировании документации, – она делится на небольшие, чёткие задания так, что исполнитель не тратит время на поиск и фильтрацию информации, но может тут же приступать к работе. Кто-то крикнет из зала, что обособленность задачи является минусом. И будет отчасти прав, ведь исполнитель не видит общей картины и работает на своём огороженном участке. Именно тут получает шанс блеснуть золотым, отполированным до блеска разумом Его Управленчество руководитель проекта.

Он способен донести до команды текущее состояние проекта, рассказать как о возникших сложностях, так и об успехах, которых добились разработчики. В его рукаве спрятано множество инструментов. Одним из них может быть «аджайл», но об этом я расскажу чуть позже. Там же, – чуть позже, – будут ссылки на мой вариант проектной документации.

Зима, случайно попавшая в тренд

Много месяцев назад мне посчастливилось наткнуться на тёплую ламповую «adarkroom». Поиграв до утра и опоздав на работу, я вдохновился. Простые игровые механики и полное отсутствие графики послужили катализатором для воображения, раскрывшегося феерией красок в голове. Так родилась идея проекта «Survive the Winter», игры с простыми игровыми механиками и наличием графики. Ряд обстоятельств, правда, не позволил начать полноценную разработку, и идея была заброшена в комод.

За одним прекрасным обеденным перерывом я наткнулся на заданный на форуме вопрос. Неопытный разработчик попросил пример диздока, хотел разобраться, как проектировать игру. Ответы завсегдатаев состояли в основном из скудных попыток троллинга и ссылок на «Месть курочки Рябы». В тот день зародилась Идея. «Survive the Winter» – это фиктивная мобильная игра; она как бы есть, но её нет. Я решил воспользоваться старым концептом, и на его основе создать открытую документацию по созданию игры с нуля. «Ворох файлов в Google Docs, ряд макетов интерфейсов, а также щедрая россыпь тасков и технических заданий в Trello могут стать наглядным примером как для совсем зелёных новичков, так и для девелоперов с опытом», – вычурно подумал я, приступая к работе.

Являясь духовным наследником игры «adarkroom», «Survive the Winter» является вариацией «кликера». Последнее время этот жанр набирает всё большую популярность. Коллеги в интернет-издании «Цукерберг Позвонит» написали статью с анализом текущего состояния, а также возможных перспектив «кликеров».

Геймплей фиктивной игры

«Survive the Winter» основывается на менеджменте четырёх ресурсов: еды и дров на складе, сытости и тепла. Соответственно, от игрока требуется вовремя ходить на охоту, запасаться хворостом, кушать и разводить костёр. Временами происходят «события». Появляется окошко с текстом: «Среди зарослей орешника вы приметили затаившегося кролика. Привычным жестом вы натягиваете тетиву. Выстрелить?». После чего пользователь решает, как поступить. Например, ответив положительно, получает сообщение: «Предназначенная для охоты на оленя стрела насквозь пробивает крошечное тельце зверька и с треском врезается в сухую корягу», вместе с тем герой получает +5 единиц мяса. Эти «события» могут иметь самые разные последствия, начиная с получения дополнительного мяса и заканчивая травмой героя (дебафф, усложняющий игру). Они же постепенно раскрывают сюжет игры.

На первый взгляд может показаться, что проект маленький и несложный в разработке, даже если запланировать высокий production value (то есть исключительное качество продукта). Но так ли это? Разработчики часто недооценивают количество работы, идущее в небольшой по их меркам проект. Я считаю, что игра размера «Survive the Winter» является отличным способом достичь моей цели – показать людям ещё альтернативный пример диздока.

Большая документация маленького проекта

Откровенно говоря, я сам не ожидал, что документация разрастётся настолько широко. Посмотрите на полный список задач в Trello. Заметьте, там доступен горизонтальный скроллинг, открывающий новые столбцы. Отмечу, что уже был проведён препродакшн, то есть предварительная работа, поиск информации, исследования. Это избавляет нас от большей части задач по проектированию и гейм-дизайну. Теперь основной объём работы лежит на плечах программистов. Если бы задачи из подготовительного этапа остались на доске, то размер её был бы в полтора раза больше.

Документация ведётся с использованием двух сервисов: Google Docs + Spreadsheets и Trello. В Google Docs хранятся общие документы, такие как описание проекта или список фич. Там же спрятаны технические задания, на которые ссылаются карточки из Trello. Сам Trello используется как «бэклог», то есть склад всех доступных для работы задач. Пробежав глазами по Trello, любой специалист может наглядно увидеть проект целиком, визуально оценить прогресс команды, но в первую очередь такое отображение удобно для менеджера. Менеджером, замечу, может быть как продюсер, так и программист или любой другой ответственный специалист, если размер команды невелик.

Если вы работаете по гибким методологиям, то под «спринты» стоит создать отдельную доску, и в неё переносить задачи из «бэклога». Как следствие, можно будет наглядно оценить как общее состояние проекта, так и состояние текущего «спринта». Если объём работы для вашего проект заметно больше, чем для «Survive the Winter», то общая доска-«бэклог» может превратиться в помеху: все задачи не поместятся, вы начнёте в них путаться. Придётся поднять сервис таск-трекинга по типа Jira или Redmine. Тем не менее, для большинства инди-разработчиков Trello должен подходить идеально. В противном случае рекомендую внимательнее изучить размер проекта, вероятно, он слишком большой?

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

На всякий случай расскажу чуть-чуть про «спринты» и «аджайл» для тех, кто ещё не познакомился с этим веянием в методологиях разработки программного обеспечения. Под «спринтом» подразумевается небольшой отрезок времени, как правило длиной в одну или две недели. В начале «спринта» команда проводит встречу и решает, какие задачи будут точно выполнены за выделенное время. Ключевая цель при выборе задач – это получить конкретный работающий функционал к концу «спринта». Соответственно, во время заключительной встречи команде демонстрируется рабочее демо, на этом «спринт» считается завершенным.

«Спринт» является также прекрасным инструментом по поддержанию мотивации, ведь люди трудятся вместе ради достижения общей цели, – рабочего функционала в демо, – подбадривая друг друга, и к концу выделенного отрезка времени они получают осязаемый результат, что всегда приятно. Более того, даже если над игрой трудится один разработчик, «спринты» всё равно являются отличным мотиватором: разработчик не «пилит» какой-то абстрактный код, а реализует конкретную игровую фичу, которую можно будет пощупать непосредственно в «билде» игры. «Билд» же, в свою очередь, можно дать потискать друзьям и знакомым.

Структура основной доски Trello удобна для общего управления проектом, но не подходит для «спринтов». Есть смысл выбранные для очередного «спринта» задачи брать из доски-«бэклога», который можно сравнить с большим мешком с подарками, и переносить эти задачи в новую, отдельную доску, рассчитанную на один «спринт».

Тут же хочу заметить (и посыпать голову пеплом), что документация «Survive the Winter» в текущем её исполнении напоминает водопадную модель. Эта методология отличается тем, что заранее готовятся все задачи, после чего передаются исполнителям. Проект движется по предварительно выложенным рельсам, он становится негибким, любые изменения вносить сложно, – они буквально крошат его жесткую структуру, грозя массивными разрушениями, срывами сроков и выходом за рамки бюджета. Мне пришлось создать именно такую общую доску с задачами, спроектированными заранее и с особой тщательностью, чтобы наглядно показать разработчикам документацию целиком, как бы с высоты птичьего полёта.

Распределённый диздок

На доске-«бэклоге» карточки сгруппированы по смыслу и разложены по приоритету, чтобы самые важные были всегда на виду. Можно пойти ещё дальше и сгруппировать задачи по фичам. Иными словами, чтобы иметь фичу «событие» (помните, я рассказывал про бедного кролика, насквозь пробитого стрелой?), надо реализовать для неё всплывающее окошко, брать откуда-то текст, дать кнопки выбора варианта ответа на «событие», и так далее. То есть каждой отдельной фиче принадлежат несколько задач. Таким образом специалист сможет видеть, какая задача связана с какой, и какой общей целью они объединены. Поэтому важно создать несколько особых документов, отражающих каждую сферу проекта, то есть: программирование, графика, гейм-дизайн, звук и другие. Получается тесная интеграция с принципами гибких методологий разработки. Каждая фича представляет из себя спроектированный «на бумаге» функционал. В то же время каждый спринт стремится создать демо, в котором реализован цельный работающий функционал. В итоге всё служит достижению общей цели.

Тернистый путь проектировщика

Вы наверняка уже успели пощёлкать по задачам в Trello. В каждой вы видите выжимку информации, рассчитанную на конкретного специалиста. Если это программист, он получает больше технических описаний, если художник – больше описаний ощущений («от игры должно веять холодом!»). Создавая технические задания для разных специалистов, нужно стремиться понимать тип их мышления, знать, что для них важно, а что – пустые слова. Это следует всегда держать в голове. Документы надо создавать с высокой детализацией, чтобы специалист не тратил время, додумывая и заполняя пробелы за проектировщиком. В лучшем случае это ведет к фрустрации, в худшем окажется, что часть работы потом придётся переделывать.

Проектирование игры требует массу времени; важно не попасть в ловушку, считая, что составление задач и техзаданий – быстрый процесс, которым можно заниматься как бы между делом. При создании технических заданий для команды приходится глубоко анализировать игру, затем разбивать её на крошечные кусочки, давая им чёткое и однозначное описание, чтобы работать по такой задаче исполнителю было комфортно. Это долго. Занимаясь этим в свободное от работы время и в выходные, мне пришлось потратить около двух месяцев на «Survive the Winter».

Не меньше времени уходит на поиск информации. Многие задачи требуют предварительной подготовки, проведения исследований, фильтрования информационного шума. Например, при создании кроссплатформенной мобильной игры, описывая для художника техническое задание по рисованию иконок для приложения, нужно заранее перелопатить увесистые гайды от магазинов Apple, Android, Amazon и WP8 (самая замороченная платформа, очень много иконок и тайлов, но гайд грамотный). Вы не можете просто накидать в задаче ссылок, вам надо самостоятельно пойти и сделать из тонны текста выжимку, оставив исполнителю только важную для него информацию. Между тем, разбивая документацию на небольшие, но выполнимые задачи, хорошим тоном будет рассказывать команде, где и какая ещё информация доступна. Ведь всегда есть интересные и важные документы за пределами их обособленной задачи, запланированной на текущий спринт.

Заключительные мысли

Документация находится в постоянном состоянии Work in Progress. Это значит, что хоть основная работа выполнена и крепкий фундамент заложен, но хочется развивать и улучшать проект, добавляя новый контент и допиливая существующий. Если у вас есть пожелания или предложения – всегда рад услышать. Этот пример документации – не истина в последней инстанции. Автор допускает, что есть более продвинутые и гибкие методы работы, но в свободном доступе примеров нет. Я предлагаю свой вариант и призываю к обсуждению. Предполагается, что от этого выиграют все.

Источник