Все статьи

Итак, у вас на руках техническое задание на разработку сайта. Вы его написали сами (наше почтение!), скачали из интернета (а вы ловкач!) или, даже страшно подумать, заказали у специально обученного маркетолога, аналитика и техзадолога… эээ, ну в общем специалиста.
Документ, несомненно полезный — вон какой объемный! Слов опять же умных много, некоторые вы вообще видите в первый раз.

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

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

Как говориться, приехали…

Давайте предположим что могло пойти не так. Варианты:

• Все эти люди жадные неуверенные в себе идиоты?
• Все эти люди считают идиотом вас?
• Вам подсунули\Вы написали (ненужное зачеркнуть) никуда не годное техзадание?
• Здесь мы хотели описать вариант с наведенной порчей, но побоялись сглазить.

В целом, конечно, все версии имеют право на жизнь, но наш опыт подсказывает, что дело тут в другом:

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

Либо это вариант «мы старались предусмотреть все, даже нашествие марсиан» — предельно формализованный и напичканный витиеватой терминологией пухлый том, который до конца не осилил даже тот, кто его писал. Зачастую в этом варианте встречаются дивные «артефакты» из прошлых техзаданий (из недавнего — верстка под экран 800×600 и поддержка IE5).

В обоих случаях верно оценить сроки и стоимость проекта затруднительно.

Абимбола Мбаппе́ Лотте́н
Ведущий техзадолог
Дважды инвалид умственного труда

Как мы предлагаем избежать всего этого? Да очень просто — для любого проекта нужен прототип. Он может существовать сам по себе или быть частью технического задания, может быть интерактивным или нарисованным от руки, но именно он облегчает всю дальнейшую коммуникацию по проекту.

• Имея перед глазами прототип менеджеру проще обозначить рамки проекта. Таким образом мы уходим от необоснованных
  «вилок» по срокам и цене.
• На работу с прототипом и вы, и мы тратим значительно меньше времени, чем на чтение объемного и скучного ТЗ.
• Прототип нагляден — вы видите свою задумку еще «на берегу» и способны вносить коррективы сразу, это сильно дешевле
  правок на этапе разработки.
• Прототип — это страховка от недопонимания. Это пункты ТЗ можно толковать как угодно, прототип же выглядит одинаково
  и для вас, и для разработчика.

На этом список плюсов не заканчивается, но пора бы уже выяснить: «а что такое прототип»?

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

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

А как же техническое задание?

После оды, которую мы пропели прототипам возникает резонный вопрос: «А что с ТЗ? Эта кипа бумажек вообще не нужна?».
Весь наш опыт говорит о том, что для большинства небольших проектов полноценного техзадания не требуется. Достаточно обозначить цели проекта, критерии его завершения, упомянуть платформу на которой требуется его реализовать и создать прототип. 
Серьёзное ТЗ необходимо нечасто, например когда проект предполагает многочисленные интеграции со сторонними сервисами, (ну или если требуется пустить пыль в глаза начальству).

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

Весь наш опыт показывает — что ни одно, даже самое скрупулёзное техническое задание не выдерживает столкновения с реальностью.

«Ни один военный план не выдерживает первого же столкновения с противником»

Гельмут Карл Бернард фон Мольтке
Ну кто ж не знает старину Гельмута?
Крупный эксперт по планированию

Разработка и запуск интернет-проекта процесс пластичный и подвижный, в процессе работы над сайтом могут поменяться не только методы и решения, но даже цели проекта. Переписывать трехтомное ТЗ каждый раз никто не будет, а вот прототип можно менять «на лету».

Внутри нашей компании исторически сложилась следующая иерархия документов:

• Если ТЗ противоречит принятому прототипу — прототип главный.
• Если прототип вступил в контры с утвержденным дизайн-макетом — дизайн главный.

Работа по таким принципам существенно ускоряет процесс разработки исключая из него бесконечные согласования, пересогласования 
и поиски «той самой формулировки где-то в пятой редакции ТЗ».

Что осталось за рамками статьи?

В данной статье мы специально не стали касаться вопросов: «Что необходимо для создания качественного прототипа?», «Какой софт использовать для прототипирования?», «Все ли разделы сайта требуют прототип»? и многих других. Каждый из них требует подробного разбора и, вероятно, отдельной статьи. И мы об этом обязательно напишем. Следите за анонсами.