ТЗ на создание системы или сайта - просто о сложном

Введение

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

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

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

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

Ключевые идеи относительно ТЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как мы создаем ТЗ

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

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

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

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

Общие сведения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Структура проекта и страницы

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

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

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

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

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

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

Интеграции

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

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

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

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

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

Возможные расширения

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

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

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

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

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

Заключение

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

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

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

Автор статьи - Руслан Раянов

Cоздатель платформы Falcon Space

Платформа Falcon Space

Это снижение стоимости владения

за счет меньшего количества людей для поддержки

Это быстрое внесение изменений

по ходу эксплуатации программы

Это современный интерфейс

полная адаптация под мобильные устройства

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

If you like our articles, then please subscribe to our channel in Telegram - Falcon Space.
In it we will publish updates on articles and other materials regarding our platform.