ХЭНДБУК ЗАКАЗЧИКА

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

Отвечаем на вопросы, которые вы стесняетесь задать. Включая популярные «Что это за фигня?» и «Нафига мне эта фигня?»
Мы уже писали, что путь самурая начинается с агрегации требований. После неё клиент получает структуру сайта — бесценная информация, если дать её в руки аналитику. У него они давно чешутся, чтобы сделать прототип.

В этом месте мы огорчим желающих здесь и сейчас получить ТЗ. Увы, вечер за увлекательной бюрократической кипой бумажек мы пока оттянем. Время строить и крушить прототипы!
Что-что, простите?
Прототип — это схема страниц будущего сайта. Про это в нашем бложе писалось не раз и подробно, но давно — в бородатом 2012 году. С того времени многое произошло: Эппл напрягся, Крым наш, лайк в Фэйсбуке уже не очень-то и лайк. Жизнь меняется, а вместе с ней — прототипы.

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

С 2012 одно осталось неизменным — мы всё ещё работаем в программе Axure. Хороша, чертовка. Проста и понятна.
Что будем прототипировать?
Прототипа достойны не все страницы сайта, а только важные и сложные. Обычно это главная страница. Если делаем интернет-магазин — то корзина, форма заказа и личный кабинет. Если в разделе «О нас» задумана презентация сотрудников с портретами и мини-биографией, чтобы клиент мог выбрать, к кому обратиться и тут же оставить ему запрос на обратный звонок (заполнив для этого форму с двадцатью обязательными и невероятно важными полями), — прототипируем. Если планируется фото фасада и три строчки адресов-телефонов — обсуждаем с заказчиком и затем фиксируем в ТЗ.
И зачем мне прототип?
Прототип помогает нам понять, что хочет заказчик видеть на своем сайте, какой функционал нужен его клиентам. А заказчик так вникнет в предметную область. На прототипах клиенты подробно описывают, почему нужен такой функционал, объясняют специфику работы сайта и т.д.

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

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

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

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

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


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

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

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

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

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

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

Пример 2:

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

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

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

Комментарии

У вас есть проект?

Давайте обсудим его. Продумаем. И сделаем!

Заказать клёвый проект
Заявка отправлена
Спасибо, ваша заявка отправлена. Эксперт студии Сибирикс свяжется с вами в ближайшее время для уточнения подробностей.