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

»
Ценности и принципы сообщества
Шаблон ТЗ, Виды ТЗ, важные составляющие

Следует различать следующие виды технических заданий:
- Технические требования (далее ТТ), написанные заказчиком, как правило на 1-3 страницах, описывающие основные функции.
- Техническое задание (далее ТЗ или Тех.задание), которое пишется для работы с заказчиком и, как правило, прикладывается к договору.
- Техническое задание для расчета стоимости (далее ТТ для расчета стоимости). Бывает разрабатывается недостаточно подробное техническое задание, с целью очертить объем задачи и дать приблизительную оценку стоимости. После разработки такого технического задания - следует произвести доработку технического задания по всем нераскрытым моментам.
- Описание задания / задачи (далее ОЗ), которое пишется для внутренней работы, пояснения взаимодействия между специалистами. В т.ч. используется в Agile подходе.

ТЗ лучше делать по ГОСТ 34.602-89. Шаблон ТЗ по ссылке здесь

Ключевые требования к Техническому заданию (далее ТЗ):
- ТЗ должно описывать весь объем функций, требуемый заказчику.
- ТЗ должно включать в себя Сценарии использования - т.е. то, как этим будет пользоваться пользователь.
- ТЗ должно отсекать те области, к которым не предъявляется требований
- ТЗ пишется в утвердительной форме в повелительном наклонении, используя фразы "Требуется, должен, необходимо, допускается".
- ТЗ должно исключать двойного толкования любого пункта. КРАЙНЕ ВАЖНО
- Рекомендуется ТЗ снабжать Скетчами, зарисовками, схемами работы.
- В ТЗ требуется указывать расчетную нагрузку, по количеству пользоватеелй и времени отклика.
- Моменты, выполнение которых трудно обеспечить, или следует проверить на этапе разработки - прямо указывать, что уточняются на этапе разработки, или подлежать проверке возможности реализации.

Оформление и обсуждение ТЗ
- Техническое задание необходимо разрабатывать либо в MS Word либо в Google Word
- При разработке ТЗ обязательно использование заголовков и разделов 1-4 уровней с нумерацией разделов.
- При разработке ТЗ как документа, следует использовать Стили! Это сокращает время приведения в нужный вид до 70%. При необходимости файл с настроенными стилями запросите у Анатолия.
- Необходимо нумеровать страницы в ТЗ, и использовать Приложения, при ссылках на большие блоки информации.
- Обсуждение ТЗ и любых других документов необходимо выполнять в режиме "Рецензирования", и использовать "Примечания" для обсуждения спорных моментов или моментов, вызывающих вопросы.
Ценности и принципы сообщества
Скетчи
При разработки мобильных приложений, ВЕБ-систем и других ИТ проектов, бывает крайне полезно готовить скетчи/прототипы/мокапы. Отличие скетчей, прототипов, мокапов - следует сюда вставить, как только будет определено это отличие, пока все это будем называть скетчами.

Процесс создания и утверждения скетчей
- Изначально скетчи рисуются на бумаге карандашом или ручкой. (это экономит от 8 до 40 часов рабочего времени по практике).
- Далее согласовываются с руководителем и при необходимости с заказчиком.
- Далее скетчи следует перерисовать в инструменте Figma.
- Ссылку на исходники в figma следует отправить Заказчику, и руководителю.

- Дальнейшее обсуждение скетчей и дальнейшей разработки дизайна рекомендуется выполнять через систему комментариев в figma.

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

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

Примеры скетчей одного из приложений приведены ниже.
Ценности и принципы сообщества
Расчетная трудоемкость
Трудоемкость разработки задания обычно следующая:
Трудоемкость рассчитана на одно мобильное приложение среднего объема ( 15-20 экранов). не зависимо на сколько платформ.
- 20 часов в первую неделю - набросать структуру, разобраться в теме, набросать первые макеты на бумаге
- 20 часов во вторую неделю - согласовать макеты с Заказчиком, перевести в электронный вид.
- 20 часов в третью неделю - написать основную текстовую, Методы взаимодействия с бекэндом
- 20 часов в 4-5 неделю - согласование всего
Итого: 80 часов

Трудоемкость при составлении ТЗ на мобильные приложения и бэкэнд среднего объема
мобильное приложение среднего объема ( 15-20 экранов), бэкэнд соответсвующий.
- 20 часов в 1 неделю - набросать структуру, разобраться в теме, набросать первые макеты на бумаге
- 20 часов в 2 неделю - согласовать макеты с Заказчиком, перевести в электронный вид.
- 20 часов в 3 неделю - написать основную текстовую, Методы взаимодействия с бекэндом
- 20 часов в 3 неделю - набросать макеты ВЕБ части, согласовать макеты с Заказчиком, перевести в электронный вид.
- 10 часов в 4 неделю - написать основную текстовую, Методы взаимодействия с бекэндом
- 30 часов в 4-6 неделю - согласование всего
Итого: 120 часов

+ до 40 ч. при сложностях в коммуникациях с заказчиком.
Ценности и принципы сообщества
Проверка работы
- ТЗ, в зависимости от Заказчика перед каждым показом заказчику или только в ключевых утверждениях заказчиком необходимо предварительно утвердить внутри компании руководителем.
- Первую версию ТЗ запрещается напрямую отправлять Заказчику, в связи с тем, что ТЗ это как правило первый документ, который получает Заказчик от нас и необходимо, чтобы он уже был качественным.
- При проверке работы Проверяющий указывает все места которые вызывают сомнения, а так же все места, допускающие неоднозначное толкование.
- После проверки ТЗ разрабатывающий дорабатывает указанные моменты
- После повторного согласования ТЗ, и в случае отсутствия критичных багов допускается отправка Заказчику.
- Следует обеспечить согласование Заказчиком Технического задания в срок 3 дня. А так же обеспечить замечания заказчика в режиме рецензирования.
- Окончательный вариант Технического задания необходимо сохранить в формате PDF, тем самым защитив от изменения, все промежуточные варианты ТЗ, убрать в отдельный каталог (ТЗ - версии) или удалить. В названии файла окончательного ТЗ следует указать дату и слово final
Обратная связь, вопросы
Комментарий
Оцените полезность видео
Все права защищены, политика конфиденциальности и все такое