Как написать техническое задание для программиста

Как грамотно составить ТЗ программисту на доработку сайта?

Техническим заданием называется служебный документ с описанием правил выполнения работы и требований к исполнителю.

Почему важно зафиксировать весь процесс работы в виде технической документации?

1. В ТЗ прописаны договоренности между исполнителем и заказчиком, которые сложно выразить в договоре из-за использования специфической IT-терминологии.
2. Это сэкономит время на коммуникациях: зафиксированные технические решения избавят от многочисленных пересказов, подтверждений, путаницы в показаниях.
3. Документ позволит четко разделить зоны ответственности между сторонами проекта.
4. ТЗ дает возможность проанализировать будущий проект и выявить проблемы на стадии планирования.
5. Правильно составленное задание сделает поведение всех участников работы предсказуемым и избавит от возникновения многочисленных недоразумений.
6. С юридической точки зрения, наличие этого документа облегчит сторонам разрешение спорных моментов.
7. Техзадание делает возможным финансовое планирование, что является залогом успешного бизнеса. Заказчику будет заранее видно, на что расходуются его средства.

Если одна из сторон хочет сотрудничать без техзадания

Это может означать следующее:

Заказчик не устанавливает четких требований специально, чтобы затем получить часть работ бесплатно, либо он не уверен/не знает/не решил/не понимает, что ему надо.

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

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

Участники проекта

Если проект большой, дополнительно могут добавиться участники:

• Product Manager
• Руководитель проекта
• Спонсор проекта
• Тестировщики
• Технические писатели
• Кураторы
• Пользователи/потребители (например, для финального тестирования)
• И др.

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

Что дает сторонам каждый раздел ТЗ:

Раздел ТЗ

+ Для Заказчика

+ Для Разработчика

Осознание задач, которые решает проект или его доработка

Понимание сути задачи

Представление о том, каким будет готовый продукт

Уверенность в правильном понимании конечного результата

Ориентирование в сроках работ и получения планируемых результатов

Оценка трудозатрат и потребности в ресурсах

Определение более-менее точной суммы затрат и планирование бюджета

Согласованный учет всех работ проекта

Подробное описание работ и каждого этапа реализации проекта

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

Оценка результата работ

Проверка работы проекта по программе тестирования на соответствие требованиям задания

Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ

Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта

Выполнение работ с учетом обслуживания проекта в перспективе

Планируемые доработки проекта

Доработка в соответствии с новыми потребностями

Последствия составления некачественного задания

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

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

Обычно разработке качественного ТЗ мешают следующие моменты:

Заказчик не готов платить до 40% от стоимости проекта только за разработку задания. Например, можно еще до начала проектирования написать все тест-кейсы и заложить в ТЗ. Но в этом случае стоимость задания с тест-кейсами может превысить стоимость разработки, а его составление займет не один месяц. Зато это полностью снимает вопрос с ошибками в работе и упрощает приёмку.

Заказчик не знает всех деталей проекта до начала эксплуатации уже готового результата.

Исполнитель не готов без должной оплаты тратить больше ресурсов на разработку ТЗ.

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

Большинство таких проблем решает Agile (гибкий подход к работе), но это не отменяет необходимость составления ТЗ. Используйте Agile при разработке любых проектов с высокой неопределённостью. Как правило, против этого выступают только заказчики, потому что они не видят точной границы цены и сроков. Зато финальный продукт гарантировано будет выполнять поставленные задачи — Agile в разы снижает число готовых проектов, которые были заброшены из-за того, что не выполняют своих функций.

Техзадание должно отвечать на вопросы:

1. Что? (какие работы, содержание элементов)
2. Где? (расположение элементов)
3. Когда? (последовательность выполнения и установленные сроки работ)
4. Как? (технология реализации, оформление, принцип работы.) Как правило, у любого объекта должны быть функции: добавления, отображения, редактирования, удаления. А также описаны зависимости и взаимодействия с другими объектами. Иногда добавляются функции модерации, валидации, автообновления, архивации и т.п.
5. Откуда? / Куда? (при переносе и т. п.)
6. Зачем? (обоснование работ, если задание будет согласовываться с 3-м лицом)
7. Особенности.

Основные рекомендации и пояснения по написанию ТЗ

1. Чем больше масштаб проекта, тем более объемным должно быть техническое задание.
2. Необходимо указывать реально осуществимые сроки выполнения работ с учетом времени на согласование проектной документации и приемо-сдаточных мероприятий. Стоит обратить внимание на ответственность заказчика за бездействие с его стороны или на форс-мажоры, тормозящие выполнение работ.
3. Программисту нужны четкие условия. Формулировки “как вариант”, “примерно”, “около”, “где-то рядом”, “там, где лучше по вашему мнению”, — неприемлемы. Требования и характеристики, которые носят субъективный характер, бессмысленны с практической и ошибочны с юридической точек зрения.
4. Чтобы сделать задачу по созданию какого-либо функционального модуля понятной для программиста, в техзадании размещают гиперссылки на те страницы, где есть нужные элементы интерфейса и функции, и дают к ним подробные пояснения. Также прилагают скриншоты с выделением интересующего фрагмента.
5. Если дизайна для страниц нет или он не так важен для заказчика, программист может использовать прототипы, о чем после согласования указывается в задании.
6. ТЗ должно быть удобным и понятным для всех сторон проекта, подробно описывать все этапы и подпункты даже по самым незначительным работам. Программист и менеджер не всегда имеют представление о том, что необходимо заказчику, поэтому важно своевременно обнаружить и согласовать все несогласованные детали.

7 типовых ошибок

1. Нечеткие цели и задачи.
2. Мало деталей в технической информации.
3. Размытые или неустановленные сроки.
4. Нет согласованности по всем вопросам между сторонами.
5. Нет регламента взаимодействия.
6. Нет ответственных лиц.
7. Нет критериев оценки результата.

Пример правильного технического задания на доработку проекта

Задача:
Разместить на сайт www.site.name.ru новую страницу, где будут размещены контакты и фотографии продавцов-консультантов, а также онлайн чат.

Описание:

1. ГДЕ? Добавить в главное верхнее меню сайта новый раздел «Ваш консультант» между разделами «Блог» и «Наши клиенты».
2. КУДА? URL новой страницы сделать: /vash_konsultant.htm
3. КАК? Макет новой страницы взять со страницы “Наши врачи”. Только вместо врачей будут консультанты.
4. ЧТО? Структура страницы следующая:
   • заголовок: Ваш консультант — по центру (в стиле других заголовков страниц сайта);
   • 3 блока в ряд, имеющие поля:
     • с фотографиями продавцов размером 400*600 (выравнивание по центру);
     • Ф.И.О. продавцов под фотографиями (текстовый формат с возможностью правки);
     • телефон общий у всех: 555-555-55 под Ф.И.О. (текстовый формат с возможностью правки);
     • электронный адрес под телефоном (e-mail: site2@mail.ru );
     • кнопка «Получить консультацию» ниже всех полей, размер кнопки, цвет и форма в стиле кнопок на сайте (см. кнопка «Сделать заказ» на url: /katalog.ru ).
5. ОТКУДА? Данные консультантов должны правиться в редакторе сайта. Также должны редактироваться теги TITLE, DESCRIPTION, H1.

Также внизу разместить форму заказа.

1. ГДЕ? Под списком консультантов, над футером.
2. ЧТО? Три поля:
   • Имя
   • Номер телефона
   • Содержание заявки
3. КАК? Обязательные для заполнения поля: Имя и Номер телефона. Оформление сделать по образцу формы обратной связи. Если обязательное поле не заполнено, то должно выводиться сообщение, как в форме обратной связи.
4. КУДА? Заявку отправлять на email заказчика: info@common.com
5. КАК? Оформление письма в свободной форме.
6. ОСОБЕННОСТИ Защиту от ботов поставить, как на форме обратной связи.
   При отправке заявки, если все заполнено правильно, в Яндекс-метрику должно отсылаться событие “Отправка заявки”.
7. НЕ ЗАБЫТЬ О ПРАВИЛАХ ПРИЁМКИ
   Проверить:
   • На странице не должно быть незакрытых HTML-тегов.
   • Проверить адаптив на мобильных устройствах Android с разрешением ***x**** и ****x****, и планшетах с разрешением 1280×1024.
   • Проверить работу в браузерах Safari, Chrome, Mozilla.

PS. Стоимость и сроки исполнения, как правило, указываются отдельно в приложении к договору. Исполнитель выставит стоимость работ, исходя из прописанных в техзадании задач. Чем больше пожеланий – тем больше будет стоимость.

Как грамотно составить ТЗ для программиста

186

Назначение, цели ТЗ

Итак, техническое задание, сокращенно ТЗ, уже довольно давно служит для формального описания того, что мы собственно хотим видеть в конечном продукте. Не является исключением и ТЗ для разработки web-ресурса. По своей сути — это база для разработки сайта. В нем указываются все положения, прямо или косвенно касающиеся сайта.

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

Есть мнение некоторых “побитых” опытом людей, что техническое задание надо писать так, как будто с ним вы будете присутствовать на суде и использовать его в качестве защиты. Может это и крайность, но тем не менее — повод лишний раз задуматься о важности хорошо написанного и детализированного ТЗ.

По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.

Составление ТЗ как правило выполняют руководитель проекта или непосредственно программист при участии заказчика, который предоставляет основную информацию.

Чем детализированнее ТЗ (в разумных пределах конечно), тем лучше для обеих сторон — как для клиента, так и для исполнителя работы. В выигрыше так сказать оба:
— клиент будет уверен, что все задуманное им в проекте четко прописано и должно быть реализовано в соответствии с ТЗ.
— исполнитель – застрахован от множества мелких или крупных корректировок и доработок, опять же опираясь на то самое ТЗ.

Существует мнение, что без ТЗ можно обойтись. Например, один из доводов — задача слишком творческая, что бы уложить ее в рамки ТЗ. Такое мнение, скорее всего, скрывает нехватку опыта и профессионализма в данной области. Считаю такое мнение ошибочным, так как почти все в сайтостроении можно формализовать и представить в ТЗ и составить его – это скорее дело опыта.

Общие рекомендации по написанию ТЗ

• Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
• Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
• В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
• Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит? Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
• Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях ( благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
• Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.

Справка

Прототип — это графическая схема размещения элементов интерфейса. Грубо говоря, нарисованная в специальной программе страница со всеми элементами.

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

Из популярных можно выделить:
— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;
— среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много — выбирай, осваивай, рисуй…

Общая структура ТЗ. От абстракции к конкретике

Одна из возможных структур сайта, подчеркну возможных, может выглядеть примерно так:

1. Общая информация о сайте.
2. Функциональное назначение сайта.
3. Понятия и термины
4. Описание модулей сайта
5. Функциональные характеристики
6. Описание страниц.
7. Резервирование и надежность.
8. Хостинг для сайта.

1. Общая информация о сайте
Здесь достаточно несколько предложений для того что бы ввести в курс дела, что за сайт или модуль будет разрабатываться и его цель в общем. Пишется вольным стилем.

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

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

4. Описание модулей сайта
Этот раздел включает список модулей, которые используются на сайте. Это вполне например может быть упоминаемая выше форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:

• Поле «Ваш имя»;
• Поле «Ваш е-mail»;
• Поле «Ваш вопрос»;
• Поле ввода капчи для защиты от спам-роботов.

И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса?» или что-то в этом роде.

5. Функциональные характеристики
Сюда можно отнести, например, список браузеров, где сайт должен корректно отображаться и работать. Например, некоторые заказчики могут требовать, что бы их сайт работал корректно и в небезызвестном Internet Explorer 6, что бы не терять хоть и небольшую, но долю возможных посетителей.
Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и по настройке сервера.

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

6. Описание страниц сайта
Это довольно обширный пункт, где прорисовуются все страницы сайта и пишутся комментарии к их работе.
Также может приводиться общая структура страниц сайта. Так называемые «высокоуровневые» прототипы. Например, для простого сайта-каталога это может быть:

Для каждой конкретной страницы могут рисоваться прототипы с подробными комментариями по каждому из элементов интерфейса с их поведением.
Страницы, используемые для админ-панели обычно уазываются отдельно от спубличных страниц. Эти два раздела в свою очередь могут группироваться в свои отдельные подразделы. Здесь стоит следить, чтобы прототипы не конфликтовали с их описанием, и не возникало никаких противоречий. Примером прототипа определенной страницы сайта может быть:

Остальные страницы

Последние два раздела ТЗ мы не будет рассматривать детально, скажу вкратце, что одно из требований к надежности может включать настройку резервного копирования БД.

Требования к хостингу может включать доступную физическую память для сайта, пропускную способность канала, поддержку используемой базы данных и ряд других требований, предъявляемых для корректной работы сайта.

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

Выводы: Надо сказать, что такая структура разделов ТЗ не претендует на всю полноту (по крайней мере для больших стратегических проектов), но основные моменты все же охватывает.

Надо подчеркнуть, что всё вышеизложенное является только рекомендациями, основанными на опыте людей, работающих в сфере сайтостроения и никак не является жестким требованием, предъявляемым к написанию ТЗ.

От абстрактной идеи к готовой механике: как гейм-дизайнеру составить ТЗ для программиста

С примерами технического задания и советами от гейм-дизайнеров.

Когда идея игровой механики возникает в голове гейм-дизайнера, она существует в виде абстрактной задумки, у которой нет конкретного воплощения. И чтобы реализовать ее в реальности, он должен как-то объяснить программисту, в чем ее суть — гейм-дизайнеру нужно понятно и однозначно описать свою затею, чтобы разработчик воплотил ее в виде работающей механики.

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

В этом тексте мы ответим на вопросы, как в студиях составляют ТЗ, какие детали там обязательно расписывают, нужны ли референсы и многое другое. Своим опытом поделились: ведущий гейм-дизайнер студии ITT Михаил Сипцов, ведущий гейм-дизайнер студии Panzerdog Олег Снисаренко, ведущий программист ITT Олег Агеев, старший гейм-дизайнер ITT Алексей Анискин.

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

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

Хорошая практика в составлении ТЗ — идти от общего к частному. В самом начале стоит написать общий принцип работы фичи. Например: «Добавляем возможность делать кувырок. Во время переката есть период неуязвимости». А дальше нужно последовательно описать механику, разбивая информацию по блокам — подробно описать ее с точки зрения геймплея, настроек и так далее.

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

• можно ли использовать кувырок во время других действий — прерывает ли он текущее действие или нет;
• можно ли использовать другие действия во время переката — например, может ли персонаж использовать зелья в процессе этого действия;
• как во время кувырка персонаж взаимодействует с другими объектами — ломает ли он объекты, сквозь которые проходит;
• есть ли зависимость параметров кувырка и характеристик героя — например, герой в тяжелой броне перекатывается на меньшее расстояние.

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

Также стоит учитывать, что ТЗ нужно не только гейм-дизайнеру и программисту, но и другим членам команды. Например, QA-специалисты используют ТЗ, чтобы проверить правильно ли работает механика. В некоторых случаях исполнитель или заказчик конкретной фичи может поменяться, а зафиксированное ТЗ поможет сохранить оригинальную задумку.

Наличие референсов заметно упрощает работу — чем сложнее сущность, тем заметнее их помощь. В зависимости от ситуации можно обойтись схемой, а где-то можно приложить ссылку на ролик из YouTube. Чаще всего референсы нужны в том случае, если гейм-дизайнер не уверен в том, что добился полного взаимопонимания с программистом.

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

Для большинства новых пешек в Rush Royale существует этап пре-продакшна, на котором мы из кирпичиков собираем что-то максимально близкое к желаемому результату, попутно ставя задачи на новые механики для программистов.
Чем больше прототипов делает сам гейм-дизайнер, тем больше ошибок он может предвосхитить. Меньше переделок — больше успеваешь сделать в срок, меньше жалоб на «сырой дизайн». Так что делать прототипы, может быть даже не для своей игры, а «для души» — это рекомендация для любого гейм-дизайнера.

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

«Танцовщица с клинками»

Эта механика предназначена для игры Rush Royale в жанре Merge Tower Defence, в которой пользователи выставляют на стол пешки, стреляющие по проходящим мимо противникам. Монстры стремятся достичь ворот замка и уничтожить его. Пешки стреляют по врагу, увеличивая свой урон или меняя определенные параметры при правильной расстановке.

Для пешки «Танцовщица с клинками» текстовое описание работы выглядит следующим образом:

«Атакует первую цель. Если по соседству (на ближайших клетках по горизонтали и вертикали) нет других танцовщиц, то переходит в усиленный режим, увеличивая свою скорость атаки и урон. Урон увеличивается с количеством танцовщиц на поле боя. Максимальный бонус достигается при восьми танцовщицах».

Сами пешки представляют собой некие универсальные сущности, на которые надстраиваются уникальные механики. При этом у всех пешек есть стандартные параметры: например, «урон» и «скорость атаки».

Чтобы из базовой пешки сделать «Танцовщицу с клинками», нужно реализовать следующие механики:

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

В итоге у «Танцовщицы с клинками» есть несколько характеристик, настройкой которых занимается гейм-дизайнер:

• урон;
• интервал между атаками;
• ускорение;
• боевой дух;
• минимальное усиление;
• максимальное усиление.

Механика переключения режимов выглядит так:

«Имеет 2 weapon механики. При условии равенства каунтера соседей 0, начинает работать изменение параметров, заданное в PawnBladeDancer_NeighborAttackChange и PawnBladeDancer_NeighborIntervalChange».

«Падение зомби из труб»

В этой части речь пойдет про механику «доставки» зомби на поле боя в изометрическом шутере.

«Нам нужно, чтобы зомби могли выпадать из труб. Сами трубы могут быть любых форм и размеров. Выпадать зомби будут по стандартным сплайнам, которые будут преднастроены в сценах.

Предлагаю сделать новый компонент, который вешаем на юнита. В нем указываем:

• кость, за которую прицепляем рэгдолл к сплайну;
• список коллайдеров, для которых отключаем физику на время полета;
• минимальную скорость, с которой тащим юнита по сплайну.

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

• переводим юнита из рэгдолла в нормальный режим и включаем аниматор;
• дергаем триггер Spawn в аниматоре;
• включаем прочую логику (можно выбрать как цель, нанести урон и так далее)».

В результате получается, что зомби неуязвимы во время «доставки» на поле боя, но сразу после спавна они становятся полноценными целями.

Возможность определять и сравнивать угол движения аватара

А эта механика предназначается для экшен-RPG от третьего лица.

«Что нужно сделать: в зависимости от угла движения аватара относительно сторон света (направления ветра) ускорять его или замедлять. Например, если ветер дует на север и аватар едет под углом не более 45° к северу, то ускорять, а если более 135° — то замедлять.

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

Тут нужен калкер, который сможет определить угол между аватаром и локатором или угол аватара относительно абсолютных координат мира.

Есть AngleCalcerToLocator или AngleCalcerRelative, они были сделаны для эффекта EffectSpin, чтобы задавать угол поворота. Но эти калкеры не получается использовать с PredicateGreater (нельзя даже соединить их в ДД). Хотелось бы заставить эти калкеры работать с предикатом или изобрести иной способ вычисления угла движения аватара».

Как грамотно составить техническое задание для программиста

Бывает, что сайт готов, но ему не хватает некоторых важных функций: почтовой программы, онлайн-калькулятора, интеграции с 1с, нет обязательных полей в CMS и т.д. Функции просто не попали в техническое задание. Чтобы этого не произошло, в этой статье подробно рассказывается, как правильно составить техническое задание (ТЗ) для программиста, чтобы не возникало проблем в будущем.

Структура ТЗ

Чтобы правильно обработать техническое задание программисту, необходимо правильно обозначить структуру. Выделим основные разделы, которые в любом случае должны присутствовать в ТЗ.

Определение цели проекта

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

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

Полный бюджет проекта

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

Перечень необходимых работ

Без полного перечня планируемых работ невозможно представить единый грамотный мандат. Это должно быть легко для понимания и написано в виде абзацев.

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

Кроме того, у программистов во время проекта всегда есть возможность отклонить любую активность, которая ранее не была включена в список. Или включить их все равно в ТЗ, но за дополнительную плату. Для работодателя список вакансий дает подробное представление о задачах, выполняемых на каждом конкретном этапе.

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

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

Оценивание результата проекта

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

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

Сроки выполнения работ

Без срока выполнения заказа не может быть ТЗ. Да, бывают ситуации, когда изначально очень сложно определить весь объем работ. Или, когда обычная деятельность по проекту завершена, возникают форс-мажорные обстоятельства, которые вынуждают сдвигать сроки выполнения работ. Но, в любом случае, это должно быть хотя бы предварительное время для работы над проектом.

Для подрядчиков крайний срок выполнения заказа позволяет объективно оценить свои потребности в ресурсах и трудозатраты (рабочее время) на ранней стадии. Для клиента — полная ориентация в плане работы, позволяющая планировать все остальные свои проекты. Часто бывает, что работа над определенными ТЗ является лишь неотъемлемой частью какого-то большого проекта. И это не может продолжаться, пока эта конкретная работа не будет сделана.

Будущее обслуживание проекта

Всегда, даже после самого удачного проекта, через какое-то время могут быть обнаружены ошибки («баги»), которые необходимо немедленно исправить. Поэтому в любом техническом задании все запланированные работы должны учитывать дальнейшее обслуживание объекта.

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

Выявление проблем

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

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

Пример ТЗ для программиста

Приведем реальный пример технического задания для веб-разработчика на тему: «Доработка полей в CMS». Эти ТЗ содержат следующие элементы с деятельностью:

• Цель проекта: доработать поля в CMS.
• Исходная информация. Возникла путаница в отношении того, какое поле за что отвечает, в какой модели, за какие функции. В результате оптимизация этих элементов не удалась. Подробнее.
• Описание. Есть 2 типа страниц: посты и страницы.

Сообщение, пример — https: //… Страницы, пример — https://…

Пример того, что у разных типов разные поля. Для типа записи есть такое поле:

Для типа страницы такого поля нет:

Какие поля нужны / что нужно отображать:

1. Тег заголовка: заголовок окна браузера
2. Тег Meta description — описание страницы
3. Тег H1 — заголовок (основной) на странице
4. Заголовок страницы в хлебной крошке
5. Имя в меню сайта
6. Заголовок страницы в области администрирования

Для следующих элементов необходимо создать отдельные поля:

1. Метка заголовка.
2. Мета-тег описания.
3. Этикетка H1.
4. Заголовок страницы в хлебной крошке.
5. Дайте им понятные имена (чтобы однозначно понять, что это поле должно делать).
6. Сгруппируйте их на странице редактирования.

1. Тег title — это заголовок окна браузера.
2. Тег Meta description — описание страницы.
3. Тег h1 — это (основной) заголовок на странице.
4. Заголовок страницы в хлебной крошке.
5. Название в меню сайта — укажите откуда оно.
6. Заголовок страницы в админке: укажите откуда оно взято.

На странице редактирования обязательны указанные выше поля:

1. размещены рядом друг с другом;
2. в указанной выше последовательности;
3. присвойте им указанные имена.

Площадь для размещения полей:

• Оценка проблемы. На это у разработчика уходит . рабочих дней.
• Бюджет . руб.

Основные рекомендации и пояснения по написанию ТЗ

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

• Чем масштабнее сам проект, тем больше людей в нем задействовано, соответственно увеличивается объем технического задания.
• При необходимости техническое задание должно содержать ссылки и скриншоты необходимых элементов функций разработки и интерфейса с подробными обоснованиями.
• Техническое задание должно быть четким и понятным. ТЗ нельзя отправлять программисту как бесформенный «холст», его нужно разбивать на точки. Также должны быть вставлены все фазы проекта и подпункты для наименее важных работ.
• Должны быть созданы реальные условия труда. В них также должно быть указано время согласования проектной документации между разработчиком и заказчиком.
• ТЗ должны содержать только четкие формулировки. Многие проекты «провалились» или их сроки были сорваны только из-за того, что заказчик не смог правильно выставить конкретные технические условия.
• Заказчик должен указать в ТЗ, может ли программист использовать прототипы, если в задании нет дизайна страниц.

Главные ошибки при составлении ТЗ

Как бы грамотно ни было разработано техническое задание для разработчика, однако в каждом письменном техническом задании есть типовые ошибки. Рассмотрим самое основное:

• В техническом задании расплывчато указаны задачи и задачи проекта.
• Недостаточная техническая информация. Конечно, программист может связаться с заказчиком в любое время, но это лишняя трата драгоценного времени.
• Неясные сроки выполнения задачи.
• Несогласованность между заказчиком и исполнителем.
• В тендерных спецификациях нет единого регламента, что также способствует взаимодействию сторон.
• Ответственные лица в ТЗ не прописаны.
• Отсутствие в спецификации компонента, объективно оценивающего результат.

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

Если у вас есть не решенные задачи или вам нужно создать сайт, то можете написать мне, здесь — Заказать сайт.