Проблемматика
Всем участникам процесса разработки сайтов, как заказчику, так и команде исполнителя, хотелось бы видеть идеальное ТЗ — понятное и в полной мере описывающее создаваемый программный продукт.
Но иногда бывает так, что ТЗ превращается в объемное произведение с множеством «воды», которое никто не хочет читать: «Просто сделайте мне сайт, я не буду читать 250 страниц», заявляет Ольга Петровна, будто в жизни у нее предостаточно времени на литературные шедевры.
А еще ТЗ бывает написано на техническом языке, который для заказчика как магия: «Я не могу это подписать, я не понимаю, что там написано», возмущается Сергей Петрович, не желая оказаться в заклинательном круге терминологии.
Некоторые технические задания не содержат четких указаний для разработчиков: «Мне не нужно ваше ТЗ, там все равно нет ничего полезного, я все сделаю по макетам», категоричен разработчик Станислав, который явно предпочитает импровизацию с обходом инструкций.
И вот, наконец, после мучительной разработки технического задания, приходится пересчитывать смету: «Боже, теперь придется пересчитывать смету и согласовывать допник», вздыхает менеджер Всеволод.
А хотелось бы, чтобы техническое задание помогало создавать продукт, а не мешало процессу 😀
Давайте разберемся что же делать и кто виноват.
Стабильность или итеративность: что лучше?
Есть два основных подхода в разработке продуктов — Waterfall и итеративная разработка.
Waterfall — как классика жанра. Это последовательное движение через этапы разработки, где возврат на предыдущий невозможен. В данном методе проектирование стоит на первом месте, формируя основу для всех последующих этапов. Это помогает точно оценить сроки и бюджет.
С другой стороны, итеративный подход — Agile. Здесь нет точных бюджета и сроков, только некоторые прикидки. Сначала создается минимально жизнеспособный продукт (MVP), а затем следует поэтапная итеративная доработка MVP. Требования формируются и оцениваются в процессе итераций, что позволяет гибко реагировать на изменения.
В каждом методе есть свои плюсы и минусы. Waterfall — надежный и понятный, но не всем подходит, потому что не позволяет внести коррективы. Он хорош в основном для проектов с четкими требованиями и опытными разработчиками. Например, мы часто используем этот подход при создании корпоративных сайтов, которых, кажется, сделали миллион, поэтому уже точно знаем, что к чему.
Agile нужен, когда дело касается стартапов или когда заказчик не знает на 100%, что хочет. Или продукт такой сложный, что его сразу описать невозможно. В таких случаях нельзя проектировать весь продукт — рынок изменяется, заказчик меняет видение, а ТЗ превращается в бумагу для поджига.
При старте итеративного проекта мы предоставляем клиенту предварительную оценку, определяем роли и юзкейсы (Use case). Ключевым компонентом на этапе итерации является обширная схема сценариев использования. Каждая итерация представляет собой совокупность этих сценариев, в рамках которых мы выбираем определенные юзкейсы, разрабатываем проект и программирование. Техническое задание также присутствует, однако оно охватывает полный цикл только в рамках конкретной итерации. Этот метод мы используем как в Waterfall, так и в итеративной разработке.
Разработка сайтов — это длительный процесс, который не завершится за один день. Поэтому мы регулярно обновляем ТЗ и поддерживаем постоянное взаимодействие с заказчиком. Этот обмен позволяет нам заранее выявлять возможные отклонения и вносить изменения на более ранних этапах разработки. Такой подход предотвращает ситуации, когда мы, находясь на грани завершения проекта, обнаруживаем, что часть технического задания утратила актуальность. Можно сказать, что мы используем гибридный подход, который обладает большей гибкостью, и позволяет нам адаптироваться и вносить коррективы даже на более поздних этапах разработки.
Наш подход в разработке ТЗ
Создание технического задания не заканчивается подписанием финального акта. Это процесс, который не завершается никогда.
Да, мы знаем, что это утверждение конфликтует с подходом: «Подписал смету ➡️ Создал ТЗ ➡️ Сделал сайт». И ниже мы расскажем, как это работает у нас.
Наши главные принципы при разработке технического задания — не перегружать деталями, ТЗ должно отвечать на вопрос «что сделать, а не как», адаптивный подход и постоянное развитие ТЗ. Также мы считаем, что лучше не 200 страниц текста, а наглядные схемы, которые говорят больше, чем тысяча слов. Чем проще задание, тем лучше для заказчика. Поэтому мы стараемся включать различные схемы в наши ТЗ:
- Роли и юзкейсы: функционал
- Структура сайта
- ER-схема: структура данных
- Диаграммы процессов: описание сложных взаимодействий/функций системы
- Прототипы сайта: работа интерфейсов
Чтобы никого не запутать, мы используем аннотации к графикам. Роли пользователей и функционал делаем в виде дерева, где функционал зависит от разделов и прочих элементов. Для более сложных частей используем EPC, это позволяет нам наглядно отобразить сложно-функциональные аспекты.
И еще: техническое задание мы рассматриваем как процесс, а не конечный продукт. Идеальное ТЗ невозможно создать изначально, и мы часто слышим это на конференциях: «Согласовали смету, сделали ТЗ, но оно выходит за бюджет, что делать?!». Поэтому создавать детальный документ в 200 страниц не имеет смысла. Вместо этого мы его развиваем и актуализируем на протяжении всего процесса разработки, а иногда даже после завершения проекта.
А теперь расскажем подробнее о процессе.
Пресейл: основа качественного ТЗ
Многих проблем с техническим заданием можно избежать, если проводить качественный пресейл. На этом этапе наш менеджер проекта составляет карту юзкейсов с привязкой к структуре сайта.
«Юзкейс — это основа при оценке проекта, так как каждый из юзкейсов подлежит разработке в виде макета и программирования»
Карту юзкейсов мы используем во всем процессе разработки:
- при формализации оценки в виде сметы,
- при разработке прототипов и макетов,
- при создании кода: верстки и backend-программирования,
- при тестировании проекта и приемке результата заказчиком.
По сути, карта юзкейсов — это то, о чем мы договариваемся с клиентом и то, что мы делаем в рамках разработки сайта.
Процесс оценки в Pitcher проходит следующим образом:
- Менеджер проекта проговаривает функционал с заказчиком в терминах юзкейсов.
- Данные формализуются в виде сметы, где каждый юзкейс выделен отдельными строками (дизайн/frontend/программирование).
- Оценка менеджера проверяется тимлидом и разработчиками конкретных артефактов — макеты, верстка, программирование.
- Смета утверждается заказчиком.
И результатом всего является смета проекта, детализированная в юзкейсах.
И когда проект уже близок к прототипированию, часто появиться новые идеи, которые могут помочь пользователям достичь целей. В таких случаях мы расширяем карту юзкейсов, чтобы учесть свежие идеи, которые внесут еще больше ценности в проект.
Проектирование будущего сайта
Следующим этапом идет проектирование сайта. Его задача — формализовать сведения о проекте в виде ТЗ, как понятного всем документа, который будет регламентировать дальнейшую разработку.
Здесь мы разрабатываем вариант технического задания, который будет подписан заказчиком как результат работ по этапу «Проектирование».
По сути, на данном этапе две задачи:
1. Дизайнер создает кликабельные прототипы разрабатываемого сайта
В ходе этапа мы формируем два ключевых компонента, придающих нашим идеям визуальное воплощение.
Первое — креативная концепция. Это своеобразный первый взгляд на будущее оформление сайта. Здесь мы создаем прототип основных страниц, который содержит ключевые элементы, формирующие работу анимаций и общую визуальную концепцию. Этот этап мы оформляем в качестве видеопрезентации, в которой заказчику наглядно показываем дизайнерские идеи. Особый акцент делаем на деталях анимаций, их взаимодействии с интерфейсом и выборе творческих решений, таких, как 3D и др. Нам важно, чтобы заказчик не только услышал, но и увидел, что мы готовы воплотить в проекте.
Вторым важным компонентом являются кликабельные прототипы всех страниц сайта. Они представляют из себя виртуальный тур по интерфейсу, где заказчик может ознакомиться с внешним видом различных страниц и функционалом будущего сайта. Задача кликабельных прототипов заключается в том, чтобы клиент не просто просмотрел, но и взаимодействовал с интерфейсом, протестировал его функциональность. Мы уделяем особое внимание деталям интерфейса, чтобы создать комфортное и интуитивно понятное взаимодействие.
Вместе с прототипами мы используем схемы и текстовые описания для предоставления заказчику более глубокого понимания проекта. Например, ER-схемы раскрывают структуру данных, а EPC-диаграммы подробно описывают внутренние процессы, которые не всегда можно полностью визуализировать только с использованием прототипов.
ER-схема (структура данных):
EPC-диаграмма (процесс):
2. Аналитик формализует задание в виде документа
Все созданные артефакты на предыдущем сайте сводится в один документ, который дополняется текстовым описанием функционала, процессов и структуры данных. Также мы указываем все технические требования: необходимое программное обеспечение, какие адаптивные разрешения будем поддерживать, чтобы обеспечить удобство использования на различных устройствах.
Финальный документ содержит:
- Технические требования:
- Версии программного обеспечения хостинга
- Поддерживаемые браузеры
- Требования к адаптиву
- Шрифты
- Структуру сайта
- Прототипы системы
- Описание сложно-функционирующих разделов:
- Юзкейсы
- Модели данных
- Описание процессов
Но такой подход, увы, не исключает возможности изменений в Техническом задании, которые могут повлиять на стоимость проекта. Иногда это происходит после прототипирования и дизайна, либо если заказчик добавляет юзкейсы. В каждом конкретном случае подобные вопросы мы рассматриваем индивидуально. Если возникает нечто, что может повлиять на бюджет, но необходимо для достижения желаемого результата, мы обсуждаем это с заказчиком. Затем принимаем решение — либо исключаем изменения из проекта, либо корректируем бюджет.
Как итог: техническое задание включает в себя требования, прототипы, юзкейсы и готово к подписанию.
Актуализация ТЗ на поддержке
Путь по созданию ТЗ начинается еще на этапе пресейла — формируется структура сайта, юзкейсы и первые наброски структуры данных, которые затем более детально разрабатываются в процессе проектирования. По мере продвижения, появляются подробные ER-схемы, уточняются юзкейсы, возникают прототипы, и весь документ актуализируется в процессе разработки. Даже после завершения проектирования, дизайнер может предложить улучшения визуальной части, изменить контролы, или реализовать интересные решения для работы интерфейсов — все это требует актуализации.
Так, в процессе разработки мы создаем актуальное ТЗ, полностью описывающее программный продукт.
Когда же мы переходим к этапу поддержки проекта, продолжаем актуализировать техническое задание, учитывая появление новых юзкейсов и интерфейсов. Это необходимо, например, при подключении команды заказчика к процессу, чтобы они понимали, как все работает. Или при выходе новых сотрудников на проект, чтобы они также быстро вошли в курс дела. Таким образом, техническое задание превращается в проектную документацию, которая служит основой для заказчика и для команды разработки и поддержки.
