Как написать техническое задание для программиста 1с образец
Модная нынче тема - составление ТЗ и формирование технических требований. Внесу свою маленькую лепту в виде примеров из личной практики и того, каким я вижу идеальное описание задачи. Задачи, которую можно просто взять и сделать! Без лишних вопросов.
Называть вещи своими именами, конкретизировать
Прописывать названия печатных форм, заголовков форм объектов в точности так, как они выглядят в конфигурации или в пользовательском интерфейсе.
Почему так : Разработчику может быть известно о других вариантах объекта, о которых пользователь не догадывается или они ему недоступны в силу ограниченных прав. Также пользователи склонны упрощать названия часто используемых объектов, когда общаются между собой, и также пишут в технических заданиях. Но для разработчика это может быть не так очевидно.
Плохой вариант : “При печати заказа выводится строка про НДС, а когда смотрю Акты на печать, ее нет”
- Не указано, из какого документа и какая печатная форма выводится. То, что это документ “Заказ”, не очевидно. Возможно, это печатная форма так называется, а документ подразумевается совсем другой.
- Не понятно, о какой строке про НДС идет речь, и в каком месте печ.формы это можно увидеть?
- Где пользователь смотрит то, что он называет “Акты на печать”? Если это ПФ, тогда что за признак “на печать”? И что такое “Акт”? - печатная форма или документ? Если это ПФ, то какая именно? Печатных форм со словом Акт может быть несколько.
Возможный хороший вариант : При формировании печатной формы “Акт выполненных работ (наш)” из формы документа “Заказ клиента”, перед подписями ответственных есть строка “Не включая НДС, согласно пп. 777 такого-то Положения”. А если формировать ту же печ.форму из обработки “Реестр печатных форм” с установленным флажком “На печать”, то эта строка пропадает.
Описывать цель доработки
Прежде чем писать о том, что нужно сделать, хорошо, когда есть упоминание, для чего это нужно.
Почему так : Из контекста цели можно понять, как именно реализовать отдельные детали, если их описание отсутствует или недостаточно подробно описано в ТЗ. Опытный разработчик/архитектор при этом может предложить более эффективный вариант решения, внести коррективы или внести дополнительные предложения, как лучше реализовать. А от каких-то решений, наоборот, отговорит в силу их неэффективности.
Плохой вариант : Прошу в отчет “Анализ продаж по распродажам” добавить колонку “Дата отгрузки партии”
Почему плохо : Нет уточнения, для чего нужна колонка? - для дополнительной группировки, какого-то анализа или для отбора строк этого отчета, чтобы потом результат подставить в другой отчет?
Возможный хороший вариант : В связи с частыми жалобами на просроченную продукцию во время промоакций, требуется дополнительный анализ отгружаемых партий в торговый зал, чтобы понимать сроки их логистики. Было бы удобно добавить колонку “Дата отгрузки партии” в отчет “Анализ продаж по распродажам”. Это бы позволило выгрузить отчет в Excel и отобрать строки с критичными сроками.
Вывод : Оказывается, отчет вообще не устраивает пользователя. Он просто пытается решить новую назревшую проблему подручными средствами.
Рассказать, что не устраивает в существующем функционале
По аналогии с предыдущим примером (см. “Описывать цель доработки”), при средних и крупных доработках хорошо бы знать, что именно не устраивает в текущей ситуации и почему требуется разработка? Возможно, часть задач можно закрыть функционалом смежных подсистем конфигурации, о которых пользователь не знает, или открыть ему доступ к дополнительным объектам/функциям, которые позволять это сделать.
Иногда бывает и так, что неудобен порядок выполнения каких-то операций, или расположение элементов на форме/в интерфейсе. Из-за этого пользователь может отказываться от использования новой доработки и продолжать делать “по старинке”.
Предоставить пример ожидаемого результата или референсы
Картинка, пример отчета в Excel, скрин из другой программы (“хочу также”), или хотя бы словесное описание того, что должно присутствовать в результате.
Описывать порядок и правила получения данных
Подробно описывать, откуда должны браться данные (например, для отчета), их порядок получения и алгоритм расчета.
Почему так : Вопрос даже не в том, что это уменьшает число вопросов программиста к постановщику. Зачастую при недостаточном описании разработчик принимается за реализацию похожих показателей из смежной подсистемы, или по инерции берется за неверный вариант, с которым работал недавно по другой задаче, потому что “на слуху”.
Плохой вариант : Для нового отчета по партиям добавить информацию о себестоимости.
Почему плохо : Не ясно, что за информация о себестоимости нужна, сколько должно быть новых колонок и каких? - себестоимость единицы, партии или всего наличного остатка. И что следует понимать под “себестоимостью”, она бывает фактической, полной, производственной, включающей или нет различные косвенные суммы.
Возможный хороший вариант : Прошу добавить в отчет по партиям колонку “Себестоимость единицы”, которую следует рассчитать как стоимость всех поступлений от поставщика и доп.услуг, разделенную на общее количество поступлений за период отчета.
В жизни очень часто бывает так, что человек не может объяснить, что хочет, даже в бытовых вещах. Когда дело доходит до объяснения программисту своих «хотелок», человек просто впадает в ступор.
Кто должен писать ТЗ?
В идеале ТЗ должен составлять заказчик — только он знает, что ему нужно. Но на практике из-за низкой компетенции заказчика в сфере 1С часто это приходится делать исполнителю. Заказчик устно озвучивает свои потребности, а программист(консультант) оформляет это в письменной форме.
Зачем нужно техническое задание?
Любые доработки в системе 1С, в идеале, должны сопровождаться техническим заданием. Это, во-первых, четкое определение задачи, сроков и метода выполнения. Во-вторых, это документ, с помощью которого решаются все спорные моменты в будущем. Писать ТЗ или нет — дело, конечно, Ваше, лично мне ТЗ облегчает работу и общение с клиентом.
Что должно содержать в себе техническое задание?
Тех. задание обязательно должно содержать в себе:
- цель — задача, которую мы решим, реализуя данное ТЗ;
- описание — краткое изложение предстоящих доработок;
- способ реализации — подробное описание методов решения цели. В этом пункте необходимо описать все нюансы задачи на языке программиста: какие регистры, справочники создаем/редактируем, как должен выглядеть интерфейс и т.д. Если Вы не владеете «языком программиста», но «что-то слышали», лучше не пытаться писать на техническом языке — получается достаточно весело. Описание должно быть однозначным и не вызывать вопросов. Также может содержать в себе пример реализации подобного решения в другой сфере;
- оценка работы — очень важный пункт, описание трудозатрат.
Также существуют государственные стандарты к написанию ТЗ — ГОСТы. На практике мало где применяются, но бывает, заказчик настаивает на этом.
По опыту, при сдаче работ очень часто возникают ситуации вроде «а мы Вам тогда-то говорили же…», что не очень приятно, и зачастую приходится переделывать работу целиком. Поэтому хорошо написанное ТЗ сильно облегчает жизнь обеих сторон.
Примеры и образцы ТЗ для 1С
Небольшая подборка, которую я нашел в свободном доступе в сети. Начиная от самых простых и доступных, заканчивая достаточно сложными документами:
Для того, чтобы Вам как заказчику, консультанту или методологу понять, что нужно разработчику 1С для того, чтобы доработать Вашу систему или разработать новую, нужно понимать, какими категориями информации он оперирует в ходе своей работы. Это сильно упростит программисту понимание того, что же от него хотят.
В данной статье я постараюсь кратко и, при этом, достаточно полно объяснить, что Вам нужно написать в техническом задании помимо общих разделов с глоссарием, титульным листом и описанием бизнес-требований.
Данные правила легко соблюдать даже при написании кратких пользовательских историй, если Вы создаете их в рамках проекта SCRUM / Agile.
Итак, приступим.
Для начала вы должны понимать, что же на самом деле в 90% случаев программирует программист 1C:
- Формы ввода информации
- Контрольные процедуры
- Модель данных
- Алгоритмы автоматического заполнения данных
- Формы вывода информации
Формы ввода информации
Это могут быть как формы ввода в систему какой-либо информации (документы, элементы справочников, таблицы с данными), так и формы загрузки этих данных откуда-нибудь по шаблону (например, Excel или XML и другие форматы для интеграции с другими системами).
Не забывайте указывать перечень кнопок-команд, которыми пользователь должен командовать Вашей системой.
Если техническое задание не содержит продуманного Вами заранее прообраза таких форм или шаблонов, то программист будет придумывать их по своему усмотрению, а Вы будете жаловаться, что вам это неудобно в работе.
Контрольные процедуры
В бизнес-процессах эти процедуры являются предварительными контролями, чтобы вам было понятно. Т.е. это такие контроли, которые система делает сама в тот момент, когда пользователь с той или иной ролью пытается работать с системой, и выдает предупреждение или намеренно прерывает работу пользователя, не позволяя ему выполнить задуманное.
В эту категорию попадают:
- Матрицы ролевого доступа
- Правила предоставления доступа к полям форм и данных
- Проверки корректности заполнения данных в формах ввода
- Процедуры сверки данных
Модель данных
Конечно, программист сделает модель данных так, как ему подскажет его опыт на текущий момент. Если программист опытный, он сделает эффективную структуру данных. А если не очень — то не очень.
Если Вы тоже «не очень» программист, то единственное полезное, что Вы сможете в этой части написать для программиста, это будут базовые характеристики модели данных:
- Перечень бизнес-объектов, с которыми имеет дело пользователь и отношения между ними, ссылки на какие объекты в каких объектах должны храниться
- Состав полей данных (табличка в эксель) по каждому бизнес-объекту, у которого есть форма ввода
- Поддержка иерархичности — нужна или нет
- Сколько данных планируется хранить
- Регулярность ввода и изменения этих данных
- Нужно ли хранить в одном объекте несколько таблиц данных, и если да, то с какими аналитиками, будет ли какой-либо другой объект ссылаться на записи этих таблиц
- Поддержка хранения данных с историей по датам — нужна или нет
- Поддержка расчета итогов на какую-либо дату, или оборотов за период — нужна или нет
- Поддержка двойной бухгалтерской записи — нужна или нет
- Поддержка вытесняющих графиков величин во времени — нужна или нет
- Поддержка процессов взаимодействия пользователей по объекту — нужна или нет
Алгоритмы автоматического заполнения данных
Если у Вас формы ввода содержат много полей или таблиц, Ваши пользователи вряд ли захотят каждый раз заполнять все поля с чистого листа.
Здесь Вы должны продумать, какие поля или таблицы могут быть заполнены по другим полям или таблицам этого или других бизнес-объектов.
Так же, здесь Вы продумываете зависимые автоматические заполнения форм ввода в зависимости от только что измененных полей пользователем. Например, после выбора номенклатуры пользователю не надо выбирать ее основную единицу измерения, система подставит ее по-умолчанию сама.
Формы вывода информации
В эту категорию попадают отчеты и формы объектов «на просмотр» или «выбор». Понятное дело, программист не должен сам придумывать форму отчета, которую Вы представляете себе совершенно определенным образом.
Нарисуйте прообраз такого отчета в Excel, желательно, с формулами и комментариями, откуда брать информацию, и вложите в ТЗ. Этого достаточно.
Так же сюда попадают формы выгрузки данных в Excel или XML и другие форматы для интеграции с другими системами.
Формы ввода и вывода часто могут объединяться с алгоритмами заполнения данных и контрольными процедурами в функциональные интерактивные АРМы пользователей, дополняться кнопками, вызывающими определенные действия и события в системе. Тем не менее, к ним применимы те же самые принципы написания технического задания, с учетом этих особенностей.
Обеспечив программиста этим нехитрым набором сведений в техническом задании, вы на 90% застрахуете себя от того, что он сделает что-то не то.
P.S. Ну разве что у Вас работает не настоящий программист 1С. Может он лучше пишет на python?
Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…
И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):
ГОСТ 34
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы рекомендует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.
Согласно ГОСТ 34 техническое задание должно включать следующие разделы:
1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки
При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.
ГОСТ 19
“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:
1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.
Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.
IEEE STD 830-1998
Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий.
Согласно стандарту техническое задание должно включать следующие разделы:
- 1. Назначение
- 2. Область действия
- 3. Определения, акронимы и сокращения
- 4. Ссылки
- 5. Краткий обзор
- 1. Взаимодействие продукта (с другими продуктами и компонентами)
- 2. Функции продукта (краткое описание)
- 3. Характеристики пользователя
- 4. Ограничения
- 5. Допущения и зависимости
- 1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2. Интерфейсы аппаратного обеспечения
- 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который легко найти в Интернете. Как и примеры, правда, на англ. языке.
Мне же больше нравится адаптированный шаблон Карла Вигерса, который я использую при разработки ТЗ для коммерческих компаний. И вообще дедушка Вигерс предоставляет множество полезных рекомендаций по работе с требованиями (куда идут деньги при покупке этих рекомендаций, читайте в начале красным). Ну а его книжку вы уже несколько раз, надеюсь, перечитали.
Данный стандарт содержит два шаблона спецификации требований:
• System requirements specification (SyRS)
• Software requirements specification (SRS)System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.
SyRS может содержать следующие разделы:
- 1. Назначение системы
- 2. Содержание системы (границы системы)
- 3. Обзор системы
- 1. Содержание системы
- 2. Функции системы
- 3. Характеристики пользователей
3. Системные требования
- 1. Функциональные требования
- 2. Требования к юзабилити
- 3. Требования к производительности
- 4. Интерфейс (взаимодействие) системы
- 5. Операции системы
- 6. Состояния системы
- 7. Физические характеристики
- 8. Условия окружения
- 9. Требования к безопасности
- 10. Управление информацией
- 11. Политики и правила
- 12. Требования к обслуживанию системы на протяжении ее жизненного цикла
- 13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке
- 1. Предположения и зависимости
- 2. Аббревиатуры и сокращений
SRS может содержать следующие разделы:
- 1. Назначение
- 2. Содержание (границы)
- 3. Обзор продукта
- 1. Взаимодействие продукта (с другими продуктами и компонентами)
- 2. Функции продукта (краткое описание)
- 3. Характеристики пользователей
- 4. Ограничения
3. Детальные требования
- 1. Требования к внешним интерфейсам
- 2. Функции продукта
- 3. Требования к юзабилити
- 4. Требования к производительности
- 5. Требования к логической структуре БД
- 6. Ограничения проектирования
- 7. Системные свойства ПО
- 8. Дополнительные требования
- 1. Предположения и зависимости
- 2. Аббревиатуры и сокращений
Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.
Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:
• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):- 1. Цель.
- 2. Краткая сводка возможностей.
- 3. Определения, акронимы и сокращения.
- 4. Ссылки.
- 5. Краткое содержание.
- 1. Обзор вариантов использований.
- 2. Предположения и зависимости.
- 1. Описание вариантов использования.
- 2. Дополнительные требования.
- 3. Другие функциональные требования.
- 4. Нефункциональные требования.
SWEBOK, BABOK и пр.
SWEBOK, BABOK, а также множество других методологий разработки ПО и сводов знаний при упоминании SRS ссылаются на вышеупомянутые зарубежные стандарты.
Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.
А как же Agile?
Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.
Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.
Заключение
Как говорится, каждому проекту свое техническое задание. При правильном использовании любого из вышеперечисленных стандартов можно брать эти шаблоны для написания ТЗ, естественно адаптируя их под себя.
Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.
Ну а кто дочитал до конца — тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).
Компьютерные игры — относительно молодая отрасль, которая в перспективе сменит киноиндустрию, так-же как кинофильмы заменили театр. Создание игры — это коллективное творчество, во многом напоминающее создание кинофильма. Кроме того, создание компьютерных игр — одна из самых сложных IT задач, поскольку она включает все себя практические все IT области.
Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.
Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.
Я намеренно оставил за кадром другие документы: концепцию, экономическое обоснование и ТЗ для других исполнителей. Это позволило сфокусироваться на одной теме и осветить ее и только ее достаточно подробно.
Самое важное:
- Четкое понимание конечного результата. (Контроль качества.)
- Сроки исполнения.
Зачем нужна документация:
Какие бывают документы:
- Концепция («Про че игра?»)
- Спецификация (Что мы хотим получить?)
- Техническое задание (Как это устроено — именно о нем будет идти речь.)
- План работ (Как мы это будем делать.)
Кто участвует в обсуждении ТЗ:
- Геймдизайнер (Написание документации)
- Архитектор (Отслеживание полноты и подробности описания, декомпозиция.)
- Программист (Оценка объемов работ.)
Требования к оформлению документации:
- Форматирование. (Легко напечатать и приятно читать/держать в руках)
- Выделение ключевых фраз. (Для чтения документа по диагонали)
- Составление списков. (Вместо сплошного текста)
- Разбиение длинных списков по группам. (По три пункта в группе)
- Многократные повторения. (Избегать ссылок по документу)
- Дата, номер страницы, количество страниц, нумерация пунктов. (Для точных ссылок при обсуждении прочитанного)
- Оглавление, список документов, история изменений. (Для поиска по документации/версиям)
Требования к содержанию ТЗ
- Русский язык. (Никаких мемов, искаженных аглийских терминов, албанского языка и прочего мусора. Даже внутреннюю документацию читают очень многие.)
- Никаких общих слов типа:
- все возможные варианты
- карта придумывается компьютером
- взаимодействие различных объектов
- после всех действий и т.д.
- Все названия видов сущностей(классов) должны иметь:
- русское название (для игрока)
- английское (для кода)
- краткое описание (расшифровка/подсказка/комментарий)
- Сущность должна иметь только одно название. (Чтобы “броня” не превращалась на другой странице в “армор” или “щит”).
- Предложения должны быть полными и понятными читателю без пристального изучения контекста. (Не надо подразумевать, что читатель сам догадается до того, что подразумевал автор)
- Все что можно измерить, должно быть измерено.
- размеры картинки в пикселях и байтах
- количество столбцов и клеток в таблице
- количество символов в текстовом поле
- количество оружия на уровень
- время сессии и т.д.
Главные требования к результату работы программиста:
- Гибкость системы к изменениям. (Динамические требования.)
- Автоматический сбор данных об ошибках. (Обратная связь.)
- Простота запуска и настройки заказчиком. (Демонстрация результата.)
Первый этап написания ТЗ:
Описание предметной области, ее формализация в понятных программистам терминах.
- База данных (метаданные)
- список типов объектов
- характеристики объектов
- связь/зависимость между объектами
- Бизнес-процессы (полный игровой цикл)
- список процессов (сценарии работы)
- список функционала (что должен уметь)
- список ожидаемых изменений (что вообще может быть)
Второй этап написания ТЗ:
- Интерфейс (визуальная часть)
- список экранов игры с названиями (или группы элементов)
- список элементов на каждом экране с названиями и текстом подсказок
- описание поведения элементов (подмигивание, подсказка, блокирование, всплывающие диалоги и т. д.)
- Админка (управление)
- сервер (жизненные/системные показатели )
- игровой контент(распродажи, квесты, монстры, вещи, магазины, дроп, локации и т.д.)
- игровые данные(контент генерируемый игроками)
- статистика и отчеты (какую статистику нужно собирать?)
Третий этап написания ТЗ:
Как мы собираемся это все делать.
- Исследование необходимых технологий
- Список требований к каждой технологии
- Описание тестов/демонстрации работы каждой технологии
- Список будущих требований/возможных проблем (что дальше?)
- Список требований к разным видам контента(ресурсов) для игры (размеры картинки мечей, длинна названий квестов, разновидности спецэффектов, размеры видеороликов и т.д.).
- Список небходимых инструментов для работы с контентом (редактор карт, админка квестов, ).
- Расстановка приоритетов по задачам.
- Требования к первой работающей сборке (что должен уметь первый прототип).
- Список остальных итераций разработки проекта с требованиями к их результатам. (Что нужно показать в конце каждого этапа, чтобы закончить его)
Сопровождение документации
- Большая часть того, что написано на первых этапах – устареет и будет нуждаться в переписке заново задолго до окончания планирования.
- Главный принцип первых этапов планирования: расставить список разделов и составить список вопросов по каждому разделу.
- Чем ниже детализация на начальных этапах – тем лучше. (количество типов оружия, вместо полного списка с названиями, количество квестов по уровням, вместо их подробного перечня и т.п.)
- Чем легче найти нужный пункт в документации и изменить его, не затрагивая остальное – тем лучше. Поэтому нужно избегать графических схем и сплошного текста из сложноподчиненных предложений. Оставьте графические презентации и эмоциональные описания для финальной отчетности.
- После каждого цикла планирования — проверять и тестировать полноту документации и равномерность уровня ее детализации. (Если в доме из 5 комнат описана только одна – нужно описать остальные четыре, или выкинуть подробное описание одной комнаты, чтобы все комнаты были описаны одинаково подробно.)
- Составить список неудобных вопросов. Темные пятна всегда есть, и их стараются обойти и замолчать, не осознавая этого.
- Предоставлять краткие инструкции конечным исполнителям. Конечные исполнители не должны сталкиваться с полной документацией, и мучительными поисками нужного упоминания по всему объему.
- Признак мастерства: каждый следующий уровень планирования уточняет, но не изменяет результаты описания более абстрактных уровней. Именно хороший навык перемещения по уровням абстрагирования/детализации позволяет перейти от припадочного описания деталей к планомерному перечислению сущностей.
Срезание углов
- Проект в 2-3 месяца.
- Команда из 2-3 человек.
- Ограниченный бюджет. (Он всегда ограничен)
- Нет требований к документации. (Никто не знает как надо делать)
- От нее нет никакой пользы. (Никогда не использовали документацию)
Первые шаги
Настоятельно рекомендуется новичкам выбирать в качестве первых проектов «клоны» классических игр. Пока нет успешного опыта такой игры — нет виденья всего цикла разработки продукта. А значит нет понимания того, как дойти до финиша.
Не стоит начинать разработку игры, не написав хотя бы двух полноценных ТЗ в качестве упражнения. Это может быть ТЗ по арканоиду. Но это обязательно должен быть ТЗ по которому разработчики смогут написать полноценный арканоид, даже если они никогда не видели этой игры прежде.Читайте также: