Сайты. SEO.
Хочу сайт
Хочу SEO
Хочу лендинг
Потеряли исходники?
Контакты
+7 (812) 318-74-97

Офис в Санкт-Петербурге

hello@web-industry.pro Подробнее
С чего начать разработку ТЗ?

С чего начать разработку ТЗ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И вот, когда мы разобрались со всеми требованиями к продукту,  мы поняли архитектуру, мы поняли, как интерфейс выглядит, потому что это важнейшая часть. Его нужно действительно детализировать, понять эмоции и так далее, мы можем писать ТЗ.
Перед началом работы Школа интернет-маркетинга Курсы 1С-Битрикс О САЙТАХ О SEO Аудиты и рекомендации по созданию и продвижению сайтов Кейсы Вопросы и ответы Помощь
Говорит и показывает Яндекс
Сфера информационных технологий такова, что нужно все время держать руку на пульсе, чтобы оставаться на плаву. Тренды изменяются молниеносно, новшества, которые прежде казались фантастикой, становятся частью нашей жизни, еще вчера безупречно работавшие инструменты сегодня не просто бесполезны, но даже могут навредить... Хотите всегда быть в курсе происходящего? Позвольте нам быть вашим гидом! 

Здесь мы собираем свежие новости, гайды, FAQ'и, статьи и прочую информацию, которую считаем интересной и полезной. Следите за обновлениями!
Форма заказа
Чтобы сделать сайт еще удобнее, мы анализируем пользовательский опыт - собираем данные...
Подробнее
Чтобы сделать сайт еще удобнее, мы анализируем пользовательский опыт - собираем данные с помощью файлов cookie, журналов истории доступа и web-счетчиков. Согласно Федеральному закону «О персональных данных» мы обязаны сообщить вам об этом. Продолжая работу с ресурсом, вы выражаете согласие на обработку ваших данных. Более подробная информация размещена в разделе «Политика конфиденциальности»