Техническое задание на разработку сайта. Шаблон ТЗ

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

На практике получается все немного сложнее:

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

Экономия на создании ТЗ в итоге оборачивается большими дополнительными расходами на переработки системы.

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

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

Заказчик получит в точности, что он хочет, что он прописал и согласовал в ТЗ.

Исполнитель четко понимает, что ему нужно сделать. Ни больше, ни меньше.

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

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

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

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

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

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

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

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

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

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

На практике довольно часто вижу ситуацию, что заказчик очень поверхностно понимает, что он хочет видеть в проекте и ждет, что исполнитель ему предложит варианты, а он выберет (то ли это влияние ЕГЭ, то ли сказки об Илье Муромце, где камень ограничивает ему выбор движения).

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

ТЗ лучше писать с будущим исполнителем системы. Так вы сэкономите на ознакомлении команды разработки с бизнес-логикой. Будет более точное понимание проекта и его нюансов.

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

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

Хороший вариант построения работы между подрядчиком и заказчиком - это работа по этапам, где каждый этап состоит из ТЗ, сметы на этап и срока.

Плохо написанное ТЗ или его отсутствие полностью разрушает эту схему работы:

• невозможно определить детально смету, разработчик будет перезакладываться там, где требования написаны общими словами (например, "интеграция 1С");
• сроки скорее всего не будут выдержаны, т.к. в ходе работ появятся новые неучтенные требования;
• очень сложно будет принимать работы. Будут постоянные споры, что входит / не входит в состав работ.

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

На создание ТЗ есть ГОСТЫ. Но имеет ли смысл им следовать? Множество требований просто не актуальны (они созданы более 30 лет назад), документы очень громоздкие, создание подобных ТЗ - это отдельный большой проект.

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

ТЗ не обязательно должно содержать чисто описание "что нужно реализовать".

В некоторых случаях целесообразно сразу в этом документе проработать и вопрос "как" - детали проектирования системы.

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

ТЗ имеет свои рамки.

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

В некоторых случаях сталкивался с таким откликом: "Это вы забыли это включить в ТЗ, поэтому это ваша недоработка".

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

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

Далее мы рассмотрим наш вариант создания ТЗ - документа проектирования системы на Falcon Space.

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

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

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

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

Давайте пройдемся по разделам нашего шаблона

Раздел дает понимание исполнителю (зачастую и заказчику) для чего стоит делать систему, и в чем заключается ее ключевая особенность.

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

Профилей пользователя может быть несколько. Мы называем их ролями (директор, оператор, кассир и т.д.)

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

Как потребитель решает свою задачу сейчас без системы? Какую добавленную ценность будет давать система для пользователя?

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

Не понимая стимула пользователя, вы просто сделаете еще никому не нужную систему.

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

Закройте все потребности пользователя, и ваша система будет на коне.

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

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

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

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

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

Определите основные бизнес-процессы. Начните с главных.

Учитывайте следующие моменты по описанию процессов:

• Опишите базовую последовательность действий. В случае сложных процессов с ветвлениями логики можно сделать блок-схему.
• Используйте артефакты. Артефакт - это некий вещественное доказательство, что очередное действие было совершено. Это может быть запись в журнале, документ, уведомление, клеймо (минутка для шутки).
• Не усложняйте излишне новый процесс. Лучше внедрить сначала простой процесс, а потом постепенно его шлифовать и видоизменять по необходимости. Сложно описанный процесс сложно реализовать, сложно внедрять в практику и переделывать.
• Укажите для процесса, что является фактором, триггером и результатом на выходе. Триггер запускает процесс, актор (actor) выполняет основную работу в процессе, результат - это артефакт на выходе после выполнения всех действий процесса.

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

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

Также в этом разделе имеет смысл описать ключевые ограничения бизнес-логики, на которые следует обратить внимание исполнителям (например, что Сотрудник может быть привязан к одному Управлению).

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

Первое - опишите структуру страниц по ролям в виде таблицы. Есть неавторизованная область (куда может зайти любой желающий) и кабинет для каждой роли.Для каждой страницы укажите URL и краткое описание. Данная таблица является картой всего проекта, неким скелетом приложения.

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

Мы используем для разработки нашу платформу Falcon Space, а это определяет наш способ создания страниц (размещения компонентов). Мы сразу указываем более точно привязку к нашим компонентам в требованиях страниц - это ускоряет процесс выполнения задач. Не нужно дополнительно расписывать как реализовывать ту или иную функциональность, т.е. создавать дополнительный документ комментариев к ТЗ для разработчика)

Описание каждой страницы может содержать следующие элементы:

• Что выводим на странице: таблицы, формы, какие колонки, какие кнопки будут доступны, будут ли модальные формы, подтаблицы, комментарии. Максимально детально и конкретно.
• Действия управляющих кнопок. Как должна работать та или иная кнопка. Что меняется в состоянии объектов. Что выводится пользователю в случае успеха/провала операции. Какие проверки надо сделать и т.д.
• Ограничения доступа. Кто имеет доступ к странице. Есть ли специфические ограничения доступа (не просто по роли, а, например, только автор задачи может менять ее дедлайн).

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

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

1. Какие данные необходимо передавать между системами и в каких направлениях. Не нужно писать просто "интеграция всего и вся". Вам нужны конкретные данные, именно их и надо определить. Желательно определить точный формат самих данных, не просто передача Товара, а передача в виде такой-то JSON структуры.

2. В каком формате и по какому протоколу будут передаваться данные. Например, с помощью GET запросов по HTTPS протоколу с использованием формата JSON.

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

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

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

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

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

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

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

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

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

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

Шаблон ТЗ

Источник: