Независимо от того, разрабатываете вы сайт для стартапа или создаете сложную информационную систему, отсутствие четкого технического задания на старте может привести к сложностям в процессе разработки. В этой статье мы расскажем, почему составление ТЗ — это не просто важный, а стратегически значимый этап веб-разработки, и поделимся тем, как мы подходим к его созданию, чтобы обеспечить эффективное и слаженное выполнение проекта.
Техническое задание — это документ, который фиксирует все требования клиента к продукту. В нем описано все, что должно быть реализовано в проекте. Это также важный этап коммуникации и связующее звено для всего процесса разработки, так как в ТЗ описано все так, что понимают и менеджеры, и клиент, и разработчики.
Перед стартом работ мы рекомендуем всем клиентам выделить ресурсы на детальную проработку ТЗ, особенно если проект масштабный или планирует масштабироваться.
В техническом задании мы полно и подробно описываем весь функционал и перечень работ, которые будут реализованы в рамках проекта. На основе этого описания составляем достоверную смету проекта и согласовываем работы.
В дальнейшем техническое задание послужит руководством для работы разработчиков. Требования из него можно уточнить или дополнить, но каркас системы заложен именно в стартовом ТЗ.
Таким образом, техническое задание — это гарантии для обеих сторон на проекте: заказчик будет точно знать, какой результат получит в итоге, а разработчики смогут работать без лишних правок и доработок в процессе.
Важно! Если вам важна гибкость, и вы хотите иметь возможность вносить правки по ходу процесса, мы работаем как с фиксированной ставкой, так и по схеме time and materials (T&M).
В случае с time and materials мы тоже разрабатываем ТЗ, чтобы понимать, над каким проектом работает команда, но в то же время готовы отклоняться от курса, если того потребуют обстоятельства.
Отличие в том, что time and materials предполагает другой формат оплаты услуг. Мы фиксируем затраченные ресурсы, а клиент оплачивает нашу работу по факту.
В зависимости от типа и сложности проекта, а также от типа заявки, работа над требованиями для ТЗ может отличаться.
Например, если вы стартап и у вас нет четкого видения продукта, то мы итерационно на брифах будем его составлять. Возможно это потребует времени и усилий, но в ходе работы мы придем к общему видению и реализуем проект точнее.
Если у вас уже есть продукт, сформулированные требования, свое техническое задание и даже, возможно, прототипы, то работа над ТЗ будет заключаться в ознакомлении с текстом, доработке требований, поиске лучших решений для вашего проекта и согласовании видения конечного результата.
Тем не менее, следующие три этапа — это база для большинства проектов OnePix. В зависимости от сложности разработки и скорости обратной связи от клиента, работа над ТЗ занимает в среднем от 2 до 6 недель. При разработке очень сложных систем речь может идти и о двух месяцах, но это скорее исключение, чем правило.
Первичные требования мы берем из заявки на разработку и первых звонков по проекту с менеджером. На этом этапе вы делитесь своим видением проекта, а мы фиксируем требования и при необходимости задаем уточняющие вопросы.
Далее мы направляем информацию на проработку аналитикам и обычно планируем онлайн-встречи для выяснения деталей. Информация с этих встреч фиксируется в письменном виде, и на ее основе аналитик составляет структуру ТЗ, в котором, крупными блоками обозначены требуемые функции.
Чтобы ускорить этот этап, перед заявкой вы можете заранее подумать над структурой продукта, составить понимание требований к нему, четко и подробно зафиксировать ожидания от результата.
Этот этап обычно занимает 1—2 недели.
Техническое задание мы пишем итерационно, при этом участие клиента в процессе очень важно. Так мы глубоко погрузимся в ваш бизнес и предложим лучшие решения для проекта.
- Анализ требований и создание черновика ТЗ
После составления укрупненного ТЗ мы вместе обсуждаем результат и переходим к описанию отдельных функций продукта.
Здесь обычно возникает целый пул вопросов, которые мы можем обсуждать в любом удобном формате: в комментариях к документу, сообщениями в чате или на звонках.
- Итерации и уточнения
После того, как мы доработали черновик на основании брифов и итераций, мы отправим его вам, чтобы получить обратную связь. Дорабатываем документ, пока не придем к четкому видению результата и сформулированному ТЗ, которое всех устроит.
В зависимости от сложности системы и занятости участников процесса, этап может длиться от 1 до 3 недель.
Когда техническое задание описано исчерпывающе, ни у кого больше не осталось вопросов, мы подписываем документ. Он будет являться основой для взаиморасчетов, работ по проекту и оценки результата.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
12327 тендеров
проведено за восемь лет работы нашего сайта.
Конечно, если возникнет необходимость, мы сможем внести несущественные изменения в ТЗ уже в процессе работы или поставить дополнительные задачи в бэклог. Но приступим к осмечиванию и реализации этих задач только после того, как завершим пул работ по стартовому техническому заданию.
Такой подход позволяет более эффективно работать над задачами проекта и доводить его до результата быстрее.
Для разных типов проектов структура ТЗ может немного различаться, однако общие принципы остаются неизменными.
Например, в e-commerce проектах ТЗ будет содержать более детальное описание функционала корзины, чекаута, платежных систем, личных кабинетов, бонусных и реферальных программ, механизма доставки, а для информационных систем — описание логики работы личных кабинетов и интеграции с другими сервисами.
Согласованное техническое задание обязательно включает в себя следующее описание продукта.
В этом разделе описывается общая структура проекта. Нужно продумать, кто будет пользоваться продуктом, сколько страниц нужно разработать, чтобы обеспечить каждому типу пользователей комфортный опыт взаимодействия с системой.
Рассказываем, что на упомянутых страницах должно происходить со стороны пользователя. Каким образом должен выглядеть и отрабатывать каждый элемент (блоки, кнопки, добавление в избранное, быстрый заказ и т.д.)
Подробно описываем, как именно все должно работать с точки зрения бизнес-процесса. Например, какие данные пользователей нам нужно собрать для отправки заказа, как работает корзина, как собираются отзывы, есть ли раздел избранное и т.д.
Прописываем, что из сторонних решений нужно подключить к процессам, чтобы все работало стабильно и удобно. Речь идет о CRM, 1С, интеграциях платежных шлюзов и эквайринга от разных банков.
Мы уделяем особое внимание этому пункту в ТЗ, поскольку интеграции — важная и сложная часть разработки любой системы. В зависимости от сложности бизнес-процессов, разработка этой части может занять как 50, так и 500 часов. Чтобы точно оценить фронт работ, подводные камни, ожидания от результата и избежать проблем в процессе, мы скрупулезно выясняем требования к этой части и продумываем фронт работ до старта.
Здесь обозначаем требования к системе в целом, чтобы пользоваться ей было удобно и безопасно. Основные критерии: надежность, масштабируемость, безопасность и работа с данными. Кроме того, в ТЗ мы прописываем стек, сроки и цели проекта.
Подробные примеры интеграций и внедренного функционала в eCommerce проекты есть в кейсах на нашем сайте:
Можно подходить к разработке более гибко. У нас случаются проекты, где мы стартуем без ТЗ и собираем требования уже в процессе разработки. Обычно речь идет о наших давних клиентах, которым нужно доработать действующий функционал. В таких случаях мы уверены, что поймем друг друга правильно, а требования и фронт работ можно описать в одном звонке или сообщении.
Если же речь идет о больших проектах, мы рекомендуем этап составления ТЗ не игнорировать, поскольку без него больше рисков: непонятен бюджет проекта, не понятно какой фронт работ осмечивать, на каждом этапе параллельно обсуждается все и сразу (дизайн, фронтенд, бэкенд).
Как следствие, сроки, суммы оплаты и образ результата размываются, клиент получает совсем не то, что ожидал, потому что мы поняли друг друга неверно и не перепроверили договоренности перед разработкой.
Плюс, на больших проектах делать задачи параллельно с разработкой просто неудобно, потому что приходится много раз переделывать. Чтобы хорошо было и нам, и клиенту, мы позвали в команду аналитиков и внедрили этап проработки ТЗ.
У нас были отдельные удачные кейсы, когда без ТЗ мы смогли разработать хороший продукт.
Например, Uctel сначала пришел к нам за разработкой сайта. Они дали нам референс, цветовую схему, и менеджер проекта с дизайнером набросали макет в Figma по каркасу из разных сайтов, блоков. Мы согласовали результат, передали в работу верстальщику, он сделал — все получилось.
При этом, времени и усилий менеджера проекта на такую разработку уходит очень много, потому что нужно все собрать, структурировать и донести команде. Даже при том, что наши менеджеры технически подкованы, риск не попасть в ожидания или смету при таком раскладе все равно остается.
Кстати, позже клиент пришел к нам с другим интересным проектом, приложением для проверки связи в помещениях. На нем мы тоже работали итерационно, но это было уже сложнее.
Больше в нашей практике было примеров, когда старт без ТЗ с размытой бюджетной вилкой приводит к тому, что в середине работ мы все-таки возвращаемся к написанию ТЗ, потому что возникает риск за нее улететь.
Этот опыт научил нас мыслить стратегически и теперь мы рекомендуем всем нашим клиентам уделить особое внимание этапу разработки технического задания.
Если вам нужна разработка веб-продукта с продуманной архитектурой и прогнозируемым результатом, пишите нам.
