Разработка технического задания биржи

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

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

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

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

Если говорить непосредственно о создании ТЗ, то его можно разбить на несколько этапов:

  1. Определение процессов и понятий, т.е. разработчик  должен понимать в целом предметную область будущей биржи.
  2. Определение структуры биржи (кабинеты и страницы с адресами URL).
  3. Рисование макетов + написание спецификаций на страницы проекта.
  4. Создание общих требований (дизайн, производительность, верстка, устройства, языки, внедрение и т.д.)

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

Чем лучше и детальнее написано ТЗ, тем меньше вопросов возникает потом. Мы включаем проектирование решений в ТЗ. Это позволяет убрать “узкие места” проекта на самых ранних этапах, когда изменить требования будет просто. Наш опыт подсказывает, что двигать проект с размытым ТЗ очень и очень сложно. Заказчик всегда понимает все вопросы в свою пользу. Появляются дополнительные требования, которые будут находиться в промежуточном состоянии. Разработчики реализуют так, как они понимают (если в ТЗ нет конкретики), а заказчик имеет в виду совсем другое. Начинаются переделки, что приводит к выходу за бюджет, срываются сроки и т.д. А вся эта ситуация возникла лишь из-за того, что кто-то очень хотел побыстрее начать проект. В итоге именно это приводит обратному результату.

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

P.S. Без ТЗ можно обойтись, если вы работаете по схеме TimeAndMaterial: заказчик берет на себя часть функций менеджера и сам дает задачи по системе. А оплата выполняется по факту затрат.

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

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

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

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