Как написать ТЗ на разработку сайта?

Некоторые заказчики полагают, что техническое задание (ТЗ) – это формальность и исполнители делают его бесплатно.

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

В случае, если сайт разрабатывается на заказ, то написание ТЗ – это объемная кропотливая работа, которая требует не только фиксации требований заказчика, но и проработки предметной области клиента, предпроектирования отдельных модулей системы, создания тестовой функциональности для проработки узких моментов.

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

Из чего состоит техническое задание?

Что включает в себя полноценное техническое задание?

  1. Структуру будущего продукта. Для разработки CRM – это состав кабинетов пользователей и их функционала (страниц). Структура – это исходный элемент для всех остальных работ по ТЗ.
  2. Макеты и текстовое описание всего функционала по структуре. Макеты упрощают визуализацию ТЗ и будущего сайта. Это снижает риски недопонимания между заказчиком и исполнителем. Не секрет, что исполнители больше тяготеют к техническому языку, а заказчики – к бизнес-целям. Макеты позволяют общаться на одном языке, оба видят один и тот же интерфейс и разговаривают не на абстрактном уровне, а на уровне элементов, которые одинаково понятны всем – кнопки, таблицы, меню и т.д.
  3. Требования по интеграции. Если система связана с внешними ресурсами, то вы должны прописать, как именно система будет взаимодействовать с ними и в каком объеме. Хороший пример – это интеграция с 1С. Не пишите в ТЗ «Сделать интеграцию с 1С»! 1С содержит сотни таблиц в базе данных. Очень трудоемко сделать интеграцию всех объектов 1С с приложением и в большинстве случаев не нужно. Лучше указать, какие именно объекты надо синхронизировать с приложением (клиенты, заказы, единицы измерения, товары и т.д.). Указывайте также предпочтительный способ реализации (например, через веб-сервисы), это позволит избежать недоразумений на стадии разработки. Согласен, вы не можете знать всех технических нюансов. В этом плане вам должен помогать исполнитель, который пишет ТЗ. Задавайте ему максимум вопросов по реализации. Его задача – предоставить вам информацию, и на ее основании вы уже решаете, какой вариант выбрать.
  4. Особые требования. Сюда можно отнести требования по производительности (хотя в некоторых случаях это сложно прогнозировать, т.к. приложение работает не изолированно, а в некоторой среде), требования к браузерам, требования к дизайну и др.

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

Если говорить о дизайне CRM, то главная его задача – не мешать пользователю. На мой взгляд, здесь не нужно придумывать велосипед – можно взять готовый шаблон и использовать его.

  1. Проработка узких моментов. Если в вашем проекте есть сложные механизмы, то лучше проработать их на этапе ТЗ. Это снижает риски проекта. В случае если не найдется приемлемого решения, то лучше изменить что-то на этапе ТЗ, а не на этапе разработки системы. Почему? Это дешевле. Чем раньше обнаружена ошибка, тем дешевле ее исправить. Самые дорогие ошибки – на этапе эксплуатации. Пример: автоматическая генерация пароля. Вы сделали в начале так, что пароль генерируется слишком простой. В начале проекта поменять это несложно. Теперь представьте, что у вас система запущена, и в ней работают 100 пользователей. Будет довольно непросто сменить всем пароли (поменять данные в базе, оповестить, часть пользователей не поймет что произошло, т.е. дополнительные расходы на техподдержку).

Как написать ТЗ на разработку сайта: организация процесса

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

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

На мой взгляд, наиболее предпочтительным способом является следующая схема взаимодействия:

  1. Исполнитель и заказчик совместно работают над ТЗ (например, через сессии по скайпу). Причем исполнитель руководит этим процессом, а заказчик выступает в роли источника знаний о системе. Иными словами, исполнитель спрашивает, а заказчик отвечает.
  2. Только исполнитель фиксирует изменения в ТЗ.
  3. Заказчик периодически анализирует ТЗ. Все ли ему понятно? Ничего не упущено? Надо чем-то дополнить?

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

Особенности написания ТЗ

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

При этом желательно иметь план внедрения модулей системы. Например, в этом году мы внедрим одни модули, а в следующем – такие-то модули.

Из опыта вспоминаются ситуации, когда некоторые заказчики хотят выполнить очень большой проект за один этап, например аналог Avito.ru. Желание заказчика понятно – он хочет избежать риска получить часть продукта, а ему нужен целостный продукт. Сам не понимая того, он движет проект к катастрофе, т.к. подобные проекты невозможно сделать одним куском за один раз. Здесь действует цикл «задумка – реализация – получение обратной связи – анализ». Вспомните, Windows не сразу стал тем, что он есть сейчас.

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

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

Добавить комментарий

Ваш e-mail не будет опубликован.