Как написать ТЗ на разработку сайта?
Некоторые заказчики полагают, что техническое задание (ТЗ) – это формальность и исполнители делают его бесплатно. В некоторых случаях это действительно так. Например, если продукт типовой и, поменяв в рыбе документа несколько параметров, получаем новое ТЗ.
В случае, если сайт разрабатывается на заказ, то написание ТЗ – это объемная кропотливая работа, которая требует не только фиксации требований заказчика, но и проработки предметной области клиента, предпроектирования отдельных модулей системы, создания тестовой функциональности для проработки узких моментов.
Поэтому отнеситесь к ТЗ с полной серьезностью. От качества проработки ТЗ сильно зависит качество реализации системы в дальнейшем. Кроме того, техническое задание может служить прототипом для будущей документации приложения.
Из чего состоит техническое задание?
Что включает в себя полноценное техническое задание?
- Структуру будущего продукта. Для разработки CRM – это состав кабинетов пользователей и их функционала (страниц). Структура – это исходный элемент для всех остальных работ по ТЗ.
- Макеты и текстовое описание всего функционала по структуре. Макеты упрощают визуализацию ТЗ и будущего сайта. Это снижает риски недопонимания между заказчиком и исполнителем. Не секрет, что исполнители больше тяготеют к техническому языку, а заказчики – к бизнес-целям. Макеты позволяют общаться на одном языке, оба видят один и тот же интерфейс и разговаривают не на абстрактном уровне, а на уровне элементов, которые одинаково понятны всем – кнопки, таблицы, меню и т.д.
- Требования по интеграции. Если система связана с внешними ресурсами, то вы должны прописать, как именно система будет взаимодействовать с ними и в каком объеме. Хороший пример – это интеграция с 1С. Не пишите в ТЗ «Сделать интеграцию с 1С»! 1С содержит сотни таблиц в базе данных. Очень трудоемко сделать интеграцию всех объектов 1С с приложением и в большинстве случаев не нужно. Лучше указать, какие именно объекты надо синхронизировать с приложением (клиенты, заказы, единицы измерения, товары и т.д.). Указывайте также предпочтительный способ реализации (например, через веб-сервисы), это позволит избежать недоразумений на стадии разработки. Согласен, вы не можете знать всех технических нюансов. В этом плане вам должен помогать исполнитель, который пишет ТЗ. Задавайте ему максимум вопросов по реализации. Его задача – предоставить вам информацию, и на ее основании вы уже решаете, какой вариант выбрать.
- Особые требования. Сюда можно отнести требования по производительности (хотя в некоторых случаях это сложно прогнозировать, т.к. приложение работает не изолированно, а в некоторой среде), требования к браузерам, требования к дизайну и др.
Насчет браузеров – указывайте список браузеров и версии для которых должно работать приложение. Некоторые авторы с легкой руки пишут такие версии, которые уже не поддерживают такие порталы как ВКонтакте (например IE8).
Если говорить о дизайне CRM, то главная его задача – не мешать пользователю. На мой взгляд, здесь не нужно придумывать велосипед – можно взять готовый шаблон и использовать его.
- Проработка узких моментов. Если в вашем проекте есть сложные механизмы, то лучше проработать их на этапе ТЗ. Это снижает риски проекта. В случае если не найдется приемлемого решения, то лучше изменить что-то на этапе ТЗ, а не на этапе разработки системы. Почему? Это дешевле. Чем раньше обнаружена ошибка, тем дешевле ее исправить. Самые дорогие ошибки – на этапе эксплуатации. Пример: автоматическая генерация пароля. Вы сделали в начале так, что пароль генерируется слишком простой. В начале проекта поменять это несложно. Теперь представьте, что у вас система запущена, и в ней работают 100 пользователей. Будет довольно непросто сменить всем пароли (поменять данные в базе, оповестить, часть пользователей не поймет что произошло, т.е. дополнительные расходы на техподдержку).
Как написать ТЗ на разработку сайта: организация процесса
Во-первых, не думайте, что исполнитель полностью напишет за вас ТЗ. Вернее он напишет, но это будет не совсем то, что вам нужно.
Во-вторых, пытаясь сэкономить на ТЗ, некоторые заказчики делают ТЗ полностью самостоятельно (лучше сначала пройти спецкурс, например, наш курс создания технического задания). Тем самым они полностью полагаются на свои решения, которые могут быть неоптимальными с технической точки зрения или с точки зрения юзабилити (удобства пользования).
На мой взгляд, наиболее предпочтительным способом является следующая схема взаимодействия:
- Исполнитель и заказчик совместно работают над ТЗ (например, через сессии по скайпу). Причем исполнитель руководит этим процессом, а заказчик выступает в роли источника знаний о системе. Иными словами, исполнитель спрашивает, а заказчик отвечает.
- Только исполнитель фиксирует изменения в ТЗ.
- Заказчик периодически анализирует ТЗ. Все ли ему понятно? Ничего не упущено? Надо чем-то дополнить?
Используя такой подход, мы достигаем того, что обе стороны держат под контролем содержимое и форму ТЗ.
Более подробно о том, как мы решаем проблему с разработкой ТЗ для сайта мы описали в другой статье.
Особенности написания ТЗ
При обсуждении темы, как написать ТЗ на разработку сайта, также следует упомянуть о случаях, когда очень трудоемко написать ТЗ сразу. Система настолько сложна и быстро меняется, что нет смысла писать сразу большое ТЗ. В этом случае необходимо определить область действия ТЗ при создании торговой площадки. Делайте ТЗ только на какую-то конкретную часть системы, например, на блок «База клиентов» или процесс «Обработка заказа от клиента».
При этом желательно иметь план внедрения модулей системы. Например, в этом году мы внедрим одни модули, а в следующем – такие-то модули.
Из опыта вспоминаются ситуации, когда некоторые заказчики хотят выполнить очень большой проект за один этап, например аналог Avito.ru. Желание заказчика понятно – он хочет избежать риска получить часть продукта, а ему нужен целостный продукт. Сам не понимая того, он движет проект к катастрофе, т.к. подобные проекты невозможно сделать одним куском за один раз. Здесь действует цикл «задумка – реализация – получение обратной связи – анализ». Вспомните, Windows не сразу стал тем, что он есть сейчас.
При этом есть и обратные примеры, когда разработка ведется фрагментарно. Новые функции появляются без всякого плана, спонтанно. Это тоже плохой вариант развития ситуации, поскольку продукт теряет фокус и функции добавляются хаотично.
Очень важный момент. Обе эти ситуации порождает заказчик, а не исполнитель. Именно заказчик определяет стиль стратегического управления продуктом. Исполнителю остается только разве что пожимать плечами и подчиниться пожеланию заказчика. Помните об этом моменте в своем проекте: если у вас большой проект, то имейте стратегический план развития сайта и не пишите большое ТЗ сразу на всю систему.
Обновление декабрь 2020. Мы написали новую статью про наш текущий подход по написанию ТЗ в блоге Falcon – Как написать Техническое задание на проект. Там вы найдете новый шаблон ТЗ на создание сайта.
P. S. Рекомендуем прочитать статью о стоимости услуг разработки ПО, которая подробно рассматривает вопрос ценообразования программирования и нюансы работы специалиста IT.