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

Нужно ли создавать ТЗ?

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

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

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

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

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

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

Что важно знать при создании технического задания

ТЗ нужно как заказчику, так и разработчику

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

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

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

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

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

Не нужно писать ТЗ сразу целиком на большую систему

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

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

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

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

ТЗ пишет технарь в соавторстве с заказчиком

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

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

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

ТЗ - это совместная работа двух сторон.

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

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

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

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

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

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

ТЗ - основание для договора

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

На основе ТЗ создается смета работ и определяются сроки.

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

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

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

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

ТЗ - это рабочий документ, а не формальность

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

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

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

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

ТЗ как описание ЧТО + КАК

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

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

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

Все, что не вошло в ТЗ, оплачивается отдельно

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

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

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

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

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

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

Как мы создаем ТЗ для сайтов на Falcon Space

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

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

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

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

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

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

Общие сведения о создаваемой системе

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

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

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

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

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

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

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

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

Именно пользователь определяет успех системы. Нет пользователя - нет системы.

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

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

Роли и объекты системы

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

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

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

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

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

Бизнес-процессы

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

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

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

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

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

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

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

Структура проекта и требования к страницам

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

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

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

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

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

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

Любая неточность или неконкретность в описании страниц - повод для будущего спора заказчика с исполнителем.

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

Интеграции с внешними системами

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

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

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

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

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

Возможные расширения сайта в будущем

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

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

Проектирование базы данных

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

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

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

Заключение

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

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

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

Источник:

33
2 комментария

Комментарий недоступен

1
Ответить

Александр, я рад, что вы уделили время статье и спасибо за комментарий.
В процессе создания ТЗ правки конечно могут вноситься. И на момент создания ТЗ у заказчика как на допросе выспрашивается информация, по многу раз уточняются моменты. Если заказчик, не понимая нюансов, говорит про сложный путь, то предлагаем варианты оптимизации какого-либо процесса. Но вот после того как ТЗ согласовано, правки мы уже не вносим. ТЗ - это документ, к нему прилагается смета на разработку, если вносить изменения, заключается договор на выполнение работ, указанных в ТЗ и смете. Если вносить изменения в ТЗ, то как это подкреплять документально?
Конечно у заказчика в процессе создания проекта могут появиться новые идеи. И вот поэтому мы действуем итеративно, и являемся сторонниками MVP («минимально жизнеспособный продукт»). Но даже если заказчик хочет все равно большую систему, уточняем, что надо реализовать в первую очередь, создаем тз на этот этап, заключаем договор, реализовываем, заказчик подписывает акт принятых работ, потом начинаем новый этап, опять тз, договор, акт и следующий этап, если требуется. Идеи по ходу разработки фиксируются в беклог, чтобы не потеряться до следующего этапа.

1
Ответить