Прототип и ТЗ,
или
Откуда растут сайты

Мы уже писали, что путь самурая начинается с агрегации требований. После неё клиент получает структуру сайта — бесценная информация, если дать её в руки аналитику. У него они давно чешутся, чтобы сделать прототип.

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

Прототип — это схема страниц будущего сайта. Про это в нашем бложе писалось не раз и подробно, но давно — в бородатом 2012 году. С того времени многое произошло. Жизнь меняется, а вместе с ней — прототипы.

Раньше они были вкусными и сочными, с фотографиями и цветными кнопочками. Они были так хороши, что некоторым заказчикам нравились больше готового дизайна. Чтобы любовь с первого взгляда к прототипу не тормозила последующий процесс, теперь мы делаем их максимально простыми. Прототипы черно-белые, блоки отмечаются схематичными прямоугольниками, а если появляется фотография, значит, аналитик решил вас побаловать.

С 2012 одно осталось неизменным — мы всё ещё работаем в программе Axure. Хороша, чертовка. Проста и понятна.

Прототипа достойны не все страницы сайта, а только важные и сложные. Обычно это главная страница. Если делаем интернет-магазин — то корзина, форма заказа и личный кабинет. Если в разделе «О нас» задумана презентация сотрудников с портретами и мини-биографией, чтобы клиент мог выбрать, к кому обратиться и тут же оставить ему запрос на обратный звонок (заполнив для этого форму с двадцатью обязательными и невероятно важными полями), — прототипируем. Если планируется фото фасада и три строчки адресов-телефонов — обсуждаем с заказчиком и затем фиксируем в ТЗ.

В прототип можно ткнуть курсором или пальцем. При желании — распечатать и на бумаге обвести карандашиком то, что не нравится, и легко объяснить это подрядчику. Ему тоже проще передвинуть блок в прототипе, чем затем двигать этот же блок на без пяти минут готовом проекте. В итоге все в плюсе: заказчику — дешевле, а разработчикам — меньше слушать недовольное бурчание дизайнера.

На прототипе мы уже тестируем, удобно ли будет пользоваться сайтом. Так, если после агрегации требований заказчику всё ещё кажется хорошей идеей поставить на главную страницу интернет-магазина зоотоваров фото кота во всю ширину и длину 4K экрана, а кнопки с разделами «О нас», «Каталог» и «Доставка» сделать всплывающими при наведении на каждый чётный ус, — прототип может это поменять. Дайте клиенту пострадать, пытаясь найти ус самостоятельно. Да, жестоко, но это работает.

За что мы любим прототипы:

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

Бывают и заказчики-исключения, которые читают ТЗ с лупой и словарём технических терминов, а потом цитируют менеджерам. Таких огорчит столкновение с жестокой реальностью: редко какие готовые проекты хотя бы на 70% соответствуют техническому заданию. Юзабилити, бюджет, санкции — что угодно может стать причиной изменений в проекте.

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

Или, когда сайт почти готов, может оказываться, что некоторые страстно желаемые фичи при столкновении с реальностью — так себе, и лучше без них. Так ещё 5 страниц ТЗ теряют актуальность.

Мы ценим инициативу. Но ТЗ, которое написал заказчик, приходится к месту только в следующих случаях:

• Когда нужно объяснить аккаунт-менеджеру, что вам всё-таки нужно, и получить предварительную смету проекта.
• Когда не хочется потерять ценные мысли по проекту, а бумага их стерпит.

В 99% случаев техническое задание заказчика оставляет больше вопросов, чем ответов. Две крайности — или в попытке подстелить соломки заказчик добавляет в ТЗ максимум зауми и сложных оборотов, без которых можно обойтись, или всё описано на недосягаемом уровне абстракции.

Пример 1 (сто страниц чистого позитива):

Формат отображения объектов сущностей на страницах сайта, в том числе, отображение материалов в списках, фиксируется на этапе проектирования и не подлежит изменению в процессе эксплуатации сайта.

Пример 2:

Необходимо предусмотреть дополнительные возможные ограничения и условия для рассмотрения заявки.

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

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