Обновление Март 2020. Мы сделали подробную статью Как сделать платформу аукционного типа – со скринами демо и описанием как что работает.
На собственном опыте мы поняли следующее – техническое задание (далее ТЗ) должен составлять только технический специалист. Если не продумать сразу как система будет работать изнутри, то ваш проект может быть оторван от реальности.
Разработка технического задания обязательно подразумевает привлечение технического специалиста.
В идеале это должен быть будущий разработчик системы (например, ведущий программист группы разработки). Тем самым во время написания ТЗ он погрузится в ваши процессы и одновременно будет продумывать реализацию проекта в реальности. Также он сможет вам сразу указать, где будут возникать утечки бюджета и времени на несущественные функции.
Обычно заказчик не очень разбирается, что сделать просто, а что сложно. Задача автора ТЗ – дать информацию о мелких малозначащих деталях, которые могут отнять уйму ресурсов и, по возможности, предложить более подходящее решение.
Важное значение имеет плотное взаимодействие. Вы должны “держать руку на пульсе” и постоянно проверять правильно ли вас понял разработчик. Хорошо, если автор ТЗ понимает цели вашего бизнеса и основные бизнес-процессы. В этом плане автор должен уметь совмещать технические знания и общее понимание вашего бизнеса.
Наиболее подходящий формат взаимодействия между автором и заказчиком: автор определяет структуру ТЗ, пишет основные блоки и при необходимости задает вопросы заказчику. Тем самым роль заказчика в написании ТЗ сводится к тому, чтобы заполнять “белые пятна” проекта в видении автора ТЗ.
Самый лучший язык общения между техническим специалистом и предпринимателем – это картинки.
Картинки понимают все. Рисуйте макеты, делайте скрины, чертите схемы. Они гораздо лучше позволяют понять суть вопросов, нежели общее текстовое описание.
Если говорить непосредственно о создании ТЗ, то его можно разбить на несколько этапов:
- Определение процессов и понятий, т.е. разработчик должен понимать в целом предметную область будущего маркетплейса.
- Определение структуры маркетплейса (кабинеты и страницы с адресами URL).
- Рисование макетов + написание спецификаций на страницы проекта.
- Создание общих требований (дизайн, производительность, верстка, устройства, языки, внедрение и т.д.)
В нашем понимании, задача заказчика – хорошо написать концепцию проекта. Задача разработчика – на основании концепции и обратной связи от клиента сделать детальное ТЗ.
Чем лучше и детальнее написано ТЗ, тем меньше вопросов возникает потом.
Мы включаем проектирование решений в ТЗ. Это позволяет убрать “узкие места” проекта на самых ранних этапах, когда изменить требования будет просто. Наш опыт подсказывает, что двигать проект с размытым ТЗ очень и очень сложно. Заказчик всегда понимает все вопросы в свою пользу. Появляются дополнительные требования, которые будут находиться в промежуточном состоянии. Разработчики реализуют так, как они понимают (если в ТЗ нет конкретики), а заказчик имеет в виду совсем другое. Начинаются переделки, что приводит к выходу за бюджет, срываются сроки и т.д. А вся эта ситуация возникла лишь из-за того, что кто-то очень хотел побыстрее начать проект. В итоге именно это приводит обратному результату.
В общем, считайте ТЗ краеугольным камнем технической части проекта. Если ТЗ написано хорошо, то многие вопросы реализации проекта сильно упрощаются.
P.S. Без ТЗ можно обойтись, если вы работаете по схеме TimeAndMaterial: заказчик берет на себя часть функций менеджера и сам дает задачи по системе. А оплата выполняется по факту затрат.
Если вы все таки решили создавать ТЗ самостоятельно – прочитайте статью Как написать техническое задание самостоятельно. Также вы можете посмотреть нашу статью в Falcon блоге про создание ТЗ для проектов Falcon Space
Если у вас пока только общая идея проекта, то первым делом необходимо создать концепцию маркетплейса. Там вы найдете шаблон концепции проекта.
CRM и сайт компании в одном флаконе.
Личные кабинеты для клиентов и сотрудников вашей компании.