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

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

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

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

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

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

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

Техническое задание выполняет две основные функции:

• Точно определяет объем работ и позволяет оценить его стоимость и сроки
• Является инструментом приемки проекта (все, что написано в ТЗ, должно быть выполнено именно так, как написано)

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

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

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

Дизайнер в ИТ = Архитектор в строительстве

Аналитик (аналитик требований, бизнес аналитик) = Конструктор

Однако никому не приходит в голову садиться за компьютер и нарисовать проект полностью самому, это большой труд, требующий квалификации и опыта. Этот труд стоит соответствующих денег. В строительстве проектирование — это 5–10% от стоимости объекта, в ИТ стоимость ТЗ может достигать 15% от общего бюджета.

В практике отрасли информационных технологий, к сожалению, крайности часто случаются — от «вот вам Техническое задание (на 2–3 страницах), делайте» до «напишите задание сами, вы же профессионалы. А мы посмотрим и примем решение, работать с вами или нет». Все сегодня разбираются в политике, футболе и информационных технологиях ).

Вот как выглядят этапы подготовки требований на практике:

Здесь можно провести аналогию по этапам. Берем пример, когда онлайн-проект реализуется по водопадной модели, а не по методологии гибкой разработки, планируемой итерациями. Рассматриваем проекты стоимостью до 3–5 миллионов рублей и длительностью от 3 до 12 месяцев (да-да, исходя из написанного выше, стоимость разработки ТЗ может составлять 300–600 тысяч рублей).

ЧАСТЫЕ ВОПРОСЫ И ЧЕСТНЫЕ ОТВЕТЫ

Естественным образом у клиентов возникают вопросы, на которые можно дать профессиональный ответ:

Может ли Клиент выполнить все этапы разработки требований самостоятельно?

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

Может ли Клиент не платить за ТЗ?

Нет, не может. Даже если формально Исполнитель, пытаясь привлечь Клиента, говорит, что сам напишет ТЗ бесплатно, то все равно стоимость его разработки (а она может быть существенной) ложится в себестоимость проекта. Но при этом весь риск берет на себя Исполнитель, и это нехорошо, прежде всего, для Заказчика! Потому что у Исполнителя нет никакой ответственности за то, что он делает.

Бывают ли успешные проекты без написания ТЗ?

Бывают. Если проект очень простой (1 страница на 1 экран с формой подписки, требований к дизайну нет), или Исполнитель делал абсолютно аналогичный проект, либо используются только уже готовые решения. Но в этом случае Заказчик должен быть готов согласиться с этими решениями и довериться Исполнителю на 100%. Таких проектов немного, большинство из них типовые.

Можно ли оценить стоимость проекта без ТЗ?

Можно. Но точность оценки будет невысокой. Итоговый проект может отличаться от первоначально названной стоимости в разы. Более того, если вы покажете ваши технические требования разным Исполнителям, то разброс в ценах может составлять 3–10 раз!. Это происходит из-за того, что подводная часть онлайн проектов может быть реализована очень по-разному, и какие реально работы Исполнитель оценивает, прочитав только Техтребования, непонятно. И каждый Исполнитель будет по-своему прав, просто он читает документ и сам себе дорисовывает в голове подводную часть айсберга! Чтобы сравнивать круглое с круглым, а зеленое с зеленым, нужно писать Техническое задание.

Можно ли сделать ТЗ, а потом уйти к другому разработчику?

Можно. Если вы платите за Техническое задание, то оно должно быть конечным продуктом, который можно показать нескольким разработчикам. У них при этом не должно возникать существенных вопросов по оценке стоимости проекта. Таким образом, вы можете получить адекватную оценку подробно описанной задачи и сравнить сравнимое.

Чем я рискую, если начну проект без ТЗ?

Вы рискуете не сделать проект. В некоторых случаях дело не доходит даже до разработки, так как непонятно, что конкретно нужно делать. Реализация проекта по типу «Придумай сам, как это должно работать» с вероятностью в 95% приведет к неудаче. Сроки затягиваются, все нервничают, проект стоит.

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

ПРИМЕР

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

КОНЦЕПЦИЯ НА САЛФЕТКЕ

ГЛАВНЫЕ ВОПРОСЫ: О ЧЕМ ПРОЕКТ?

• Цель проекта
• Принципиальный механизм решения
• Рисунок/схема с потоками информации от пользователей к системе и обратно

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

ГЛАВНЫЕ ВОПРОСЫ: ЧТО НУЖНО СДЕЛАТЬ? КАК ЭТИМ ДОЛЖНЫ ПОЛЬЗОВАТЬСЯ?

• Общее описание целей
• Какие задачи должен решать проект, какие показатели он должен изменить (технические)
• На кого проект ориентирован (пользователи с какой квалификацией будут им пользоваться)
• Требования к внешнему виду (дизайну)
• На каких платформах он должен работать
• С какими системами проект должен быть интегрирован (автоматически получать или передавать данные)
• Требования к функциям системы
• Требования к ролям пользователей
• Требования к безопасности системы

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

ГЛАВНЫЕ ВОПРОСЫ: КАК НУЖНО СДЕЛАТЬ? КАК СИСТЕМА ДОЛЖНА РАБОТАТЬ?

Типовая структура Технического задания верхнего уровня для относительно небольшой информационной системы (ИС):

1. Общие сведения об ИС
2. Назначение и цели ИС (Требования к системе в целом)
3. Версии ИС (Веб-версия и другие)
4. Типы страниц и элементов страниц сайта (Описание основных функциональных страниц и ключевых элементов)
5. Типы (роли) пользователей (Структурированное описание всех ролей: пул возможностей и ограничений)
6. Пользовательские сценарии (User story: кто и каким образом взаимодействуем со всем функционалом сайта)
7. Структура данных (Клиенты, субъекты инфраструктуры и прочее)
8. Дерево ИС
9. Функциональные требования к ИС
10. Нефункциональные требования к ИС
11. Требования к интеграциям
12. Архитектура ИС
13. Эргономика и техническая эстетика (Макеты визуальной составляющей системы и прочее)
14. Требования к дизайну
15. Требования к тестированию
16. Этапы работ по созданию ИС
17. Порядок контроля и приемки ИС (Критерии завершенности разработки и прочее)
18. Дальнейшая поддержка продукта

На картинке приведен очень просто пример содержания ТЗ, чтобы оно уместилось на 1 странице. На практике — только содержание ТЗ может занимать 6–7 страниц A4.

ВЫВОДЫ

1. Разработка ИТ-системы, в том числе сайта, мобильного приложения или специализированного сервиса (например CRM-системы или системы бронирования) очень похожа на строительство дома. Сначала идея, общее описание, потом требования и ограчения, потом проектные решения, потом реализация, потом запуск и тестовая эксплуатация.
2. Нельзя игнорировать этап проектирования (технического задания для ИТ). При стоимости 10–15% от стоимости всего проекта качественное ТЗ позволит избежать большого количества проблем и, в итоге, сократить сроки и стоимость разработки.
3. Не пытайтесь сделать Техническое задание самостоятельно, чтобы сэкономить. Но при этом всегда делайте максимально подробные технические требования, чтобы ускорить проект.
4. При приемке ТЗ читайте его таким образом, чтобы можно было представить, как вы будете проверять работающую систему на предмет выполнения ТЗ: все пункты должны быть сформулированы четко и однозначно, напротив каждого — вы потом будете ставить галочку о выполнении.
5. После разработки подробного Технического задания вы можете отдать его на обсчет проекта в несколько разных компаний, чтобы корректно сравнить цены. На этом этапе уже разброса на порядок быть не должно.

— — — — — — — — — — — — — — — — — — — — — — — — — — — —

ПРИЛОЖЕНИЕ

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

ПРИМЕР ПРЕОБРАЗОВАНИЯ ОДНОЙ ФУНКЦИИ СИСТЕМЫ

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

КОНЦЕПЦИЯ

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

“В систему вносится информация о результатах матчей и протоколы матчей, а система должна автоматически обновлять данные в турнирных таблицах”

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

Когда специалисты начинаю детализировать задачу получается уже следующее описание:

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

• Должна быть реализована настройка изменения порядка применения критериев
• В турнирной таблице должны быть реализованы механизмы сортировки по любым столбцам
• Система должна работать на всех основных мобильных платформах
• Ввод данных в систему должны осуществлять только пользователи с правами администратора турнира путем внесения электронных протоколов
• Система должна иметь возможность забирать данные из сторонних сервисов (например SportRadar или BetRadar)
• Система должна иметь функцию выгрузки турнирной таблицы на любой сторонний сайт (виджет)

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Когда проект передается Исполнителю, он начинает задаваться вопросом “Как я это буду делать?”, и возникает существенно бОльшая детализация задачи:

(упрощено для экономии времени читателей)

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

— Должна быть реализована настройка изменения порядка применения критериев.

• Описание конечного перечня критериев
• Макет экрана настроек изменения порядка сортировки
• Описание метода изменения порядка сортировки (на сервере или на компьютере клиента)
• Ограничения по доступности изменения порядка сортировки (если турнир завершен, например)

— В турнирной таблице должны быть реализованы механизмы сортировки по любым столбцам.

• Конечный перечень столбцов, по которым необходимо проводить сортировку
• Механика поведения таблицы при нажатии на заголовки столбцов (сначала по алфавиту в прямом порядке, потом в обратном)
• Технология обновления данных (на сервере или на стороне пользователя)
• Поведение системы, если по выбранному критерию сортировки данные идентичные (вторичная сортировка)

— Система должна работать на всех основных мобильных платформах

• На каких платформах должна работать, при каких разрешениях
• Описание поведения системы и отображения данных для различных разрешений экрана и расположений (вертикальное/горизонтальное)
• Макеты страницы с турнирной таблицей для разных платформ
• Отличие в поведении таблиц при сортировке для разных платформ и разрешений экранов

— Ввод данных в систему должны осуществлять только пользователи с правами администратора турнира

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

— Система должна иметь возможность импортировать данные из сторонних сервисов (например SportRadar или BetRadar)

• Конечный перечень сторонних сервисов, из которых могут забираться данные
• Формат данных, в которых Система должна забирать информацию из каждого сервиса (описание всех полей)
• Описание процесса подключения импорта данных
• Тип импорта данных (разовая загрузка по требованию или автоматический фоновый импорт через xml-файл из определенного места на сервере)
• Описание механизма решения конфликтных ситуаций при импорте данных
• Структура базы данных (схема) с описанием полей, в которые импортируются данные
• Макет интерфейса для настройки импорта данных

— Система должна иметь функцию выгрузки турнирной таблицы на любой сторонний сайт (виджет)

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