«С чего начать разработку ТЗ?»
В первую очередь мы должны понимать, что нужно разобраться с самым базовым пластом, на котором будет лежать наш продукт — с задачи. Любой продукт можно описать с пяти различных сторон. Во-первых продукт выполняет задачи для своего владельца, и это понятно, ведь у владельца есть те или иные задачи, которые он хочет решить при помощи действий того или иного характера, и всё это завязано так или иначе на деньгах; во-вторых, чтобы эти задачи для заказчика выполнялись, продукт должен быть полезен для пользователя; и есть ещё перечень задач пользовательских.

В идеале должно получаться, что у нас есть пользовательские задачи, которые выполняет пользователь. Он переходит в удовлетворённое состояние. В этом состоянии он генерирует какой-то профит заказчику. Заказчик получает профит, удовлетворяет свои задачи; все расходятся довольные.

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

Пользователь взаимодействует с нашим продуктом через пользовательский интерфейс, — это ещё один важнейший компонент, описывающий продукт.

И кроме того, заказчик, когда взаимодействует со своим продуктом, он тоже взаимодействует через некие интерфейсы, но они уже более технические. — Это система администрирования, выгрузки, какая-то внутренняя кухня нашего продукта.

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

Мы называем этот документ — концепт.

Этот документ начинает рождаться ещё на моменте прицела, когда мы только встречаемся с заказчиком, поговорили с ним, поняли общую задачу, и можем крупными мазками накидать представление о продукте.

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

И документ этот выглядит следующим образом. ( показывает )

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

Вот так выглядит фрагмент концепта. Как мы видим, он оформлен в виде таблички и в нём приведены параметры — кто у нас является целевой аудиторией, причём эта целевая аудитория — не в плане маркетинга, что это женщина от 25 до 35 лет с количеством детей от полутора до трёх.

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

Обычно ещё добавляются задачи заказчика, но обычно их не так много и прописать их можно несколькими абзацами.

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

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

Заключается он в том, что мы берём каждую из целевых аудиторий, которые у нас есть в сегментах, и для каждой аудитории мы придумываем конкретного человека, у которого есть жена, ипотека и машина «Тойота», квартира в Балашихе съёмная. Мы придумываем его, находим ему фотографию. Мы его описываем и через его глаза расписываем конкретную задачу.

На экране сейчас у нас простая задача для нашего фейкового продукта по ознакомлению представителей СМИ с информацией о компании. У него есть контекст, у него есть конечная цель, у него есть перечень шагов, которые актуальны для него самого. И эти истории с пользователями очень полезно проговаривать с заказчиками. Не раз с помощью таких портретов были найдены интересные шаги, возникли мелочи, нестандартные решения, выявлены неочевидные вещи, которые ускользали при рассмотрении своей аудитории как «женщина от 25-35 лет».

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

Мы не выясняли, какими инструментами будет работать пользователь, на какие кнопки нажимать, и куда переходить. Мы в это не вторгались. Мы манипулировали более абстрактными понятиями, которые помогают нам выявить с какой информацией у нас работает продукт, с какой будет работать пользователь.

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

Многие после аналитики говорят: «Да, давайте создавать ТЗ!» — Но время ТЗ ещё не пришло. В ТЗ очень сложно вносить правки, этот документ очень сложно составляется, и его нужно откладывать на тот момент, когда всё станет ясно.

Прежде чем это случится, нам нужно заняться архитектурой проекта. А строится она на отдельном описании структуры системы, отдельном описании интерфейса, отдельно описанных логических схем, структуры данных,  и как это всё связано с внешними ресурсами.

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

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

Вот ещё некий пример, на котором мы можем расписать какие-то логические схемы, которые свойственны нашему продукту. То есть мы ещё расписываем шестерёнки. 

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

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

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

И когда мы работаем над прототипами — это заслуживает на самом деле отдельной лекции, но главное держать в голове три постулата:

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

Если на сайте запланирована интерактивность, то лучше, чтоб уже на прототипах это было видно, если это не отнимает много времени.

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

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

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

Но в ТЗ мы должны будем прописать, что на главной странице слайдер; и горе тому дизайнеру, который на этот слайдер покуситься.  А по какому праву мы сделали упор на этот слайдер — сказать сложно.

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

И когда мы отвязываем дизайн-макеты от ТЗ, и делаем их до ТЗ, — у нас получается волшебный момент, — ТЗ у нас завершает этап работы над продуктом, и завершает по сути этап дизайна. И это трогательным образом бьётся ещё с западным пониманием слова «дизайн».

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

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