Данная статья предназначена для новичков, не совсем углубляясь в детали и термины.
Что такое ТЗ и зачем оно нужно?
ТЗ (техническое задание) - простым языком: в большинстве случаев это набор бреда и фантазий заказчика.
А если серьезно?
А если серьезно: это в первую очередь юридический документ по которому и будет создаваться ваш сайт. В нем фиксируются все требования и чем точнее и подробнее вы раскроете суть вашего ТЗ, тем точнее и лучше вас поймут исполнители или те, кто и будет заниматься разработкой вашего сайта.
Т.е., если вы где-то что-то забыли, где-то что-то не указали и "неожиданно" это нужно сделать, то придется доплатить.
Польза для вас в том, что в ТЗ вы уже расписываете все ваши фантазии и начинаете приводить их в порядок, выстраивая в структуру. Понимаете как это будет работать и сразу еще на этапе ТЗ все продумать и внести правки, чтобы не переделывать потом, потратив на это кучу времени и возможно - денег.
Кто пишет ТЗ?
В большинстве случаев в студиях есть проект-менеджер, он и занимается разработкой ТЗ. Так же этим может и заниматься сам разработчик, который может сразу подсказать как это сделать лучше и что-то посоветовать. Когда мне первый раз делали сайт, то мне как раз выделили проект-менеджера, который уже задавал мне вопросы и сразу же фиксировал их на бумаге, уточнял что должно быть на сайте, а чего не будет.
Идеально будет если вы сразу напишите что должен делать ваш сайт, так сказать определите его нишу. Еще лучше если вы заполните бриф, а так же выпишите для себя несколько сайтов, функционал и дизайн которых вам приглянулся. Это особенно хорошо, если ТЗ пишет не проект-менеджер, а вы.
А кто ты, автор? Сапожник без сапог или же могешь в ТЗ?
Изначально я определяюсь с тем, чем именно будет заниматься сайт и ищу примерные сайты, смотрю на их структуру, как они работают, где какие кнопки, сразу задаю себе вопрос почему они там и что они делают.
В моем случае (это думаю для вас не совсем подойдет) я сперва пишу ТЗ для дизайнера, а точнее я его еще и рисую. Я создаю прототипы будущих страниц сайта, т.к.:
1. Это мне поможет охватить как можно больше информации и взглянуть на ситуацию со стороны.
2. Дизайнеру гораздо легче вас понять, что вы хотите и по вашему прототипу он уже делает продакшн, естественно уточняя детали.
3. Это будет дешевле и быстрее.
Для вас же сперва будет хорошим решением определиться со структурой сайта.
И так я создаю целиком прототип будущего сайта.
Стек технологий? Это еще что? Мне просто нужен классный сайт!
Опытные разработчики сразу могут вас спросить о стеке технологий, на какой CMS будет делаться сайт и посоветовать какая лучше. Так же сразу нужно уточнить будет ли ваш сайт адаптивным или же только ПК версия, т.к., это влияет на конечную стоимость. Обычно адаптивную версию сайта (или мобильную) рисуют отдельно, т.к., если на большом мониторе много места и есть пространство как расположить элементы, то в мобильной все не так. Тут нужно уже заново продумывать логику сайта как он будет отображать данный контент, как будет его подстраивать под мобильные устройства. Так же стоит уточнить в каких именно браузерах нужна кроссбраузерность.
Прототипов страниц сайта может быть как от 1-й (лендинг), так до нескольких десятков (если проект большой и сложный - соц., сеть, агрегатор и т.п.). Сложность прототипирования в том, что нужно уметь работать в графических редакторах и если у вас есть там всплывающие окна или же при нажатии "вот на эту кнопку" должно что-то происходить - нужно это так же отразить в прототипе, а т.е., наглядно показать что именно будет происходить и как будет выглядеть (не обязательно, но желательно).
И так по цепочке, сперва вы рисуете прототипируете главную, после вы прототипируете уже страницу регистрации, авторизации, восстановление пароля. А дальше уже вы перемещаетесь внутрь сайта и там прототипируете что будет внутри - какие кнопки, где будет расположена и какая информация, что будет происходить если "вы сделаете это, а если это и это" (действие пользователя-ответ сайта) и т.д. Важно стараться учесть все сразу.
Надеюсь - это все?
Как только я заканчиваю с прототипом, я перехожу к тексту. В ТЗ я делю все по пунктам, например 1, 2, 3, или же 1.1, 1.2, и т.д. Это важно для того, что если у разработчика возникнут вопросы, то он быстро сможет ответить по какому именно пункту они возникли. В самом ТЗ сперва я вставляю скриншот из прототипа и уже расписываю что именно будет на этом участке скриншота происходить. Если это кнопки, то что произойдет при наведении указателя мыши, а что произойдет при нажатии и т.д.? Если же на сайте просто "текстовые кнопки-ссылки", то я просто указываю куда меня должно перекидывать при нажатии и обязательно указываю что это должно происходить в новой вкладке.
Просто сделайте мне красивый и удобный сайт и чтобы "вжух"...
Важно стараться избегать таких слов как "красивый", "большой", "надежный" "удобный" - ведь представление об этом у всех разное. Так же важно избегать таких слов "Хотелось бы чтобы тут было", "Думаю надо будет сделать тут вот так" - это не постановка задачи, а ваши мысли. В ТЗ вы должны уже четко определиться, что "вот здесь должно быть это", "здесь должно работать вот так".
Так же важно избегать неточностей как "Сайт должен быть быстрым" - что подразумевается под словом "Быстрый"? Сайт должен быстро открываться как при одном, так и при 100 000 пользователях? А должно подразумеваться что у сайта не должно быть нагружающих страницу скриптов, из-за которых проверка скорости загрузки сайта от Google PageSpeed выдаст плохую оценку. Нам нужна хорошая скорость загрузки по оценке от Google PageSpeed? Так и пишите. При этом 100 000 пользователей - это уже и отказоустойчивость, насколько ваш сайт готов к таким пиковым нагрузкам. Будет идеально, если вы сразу напишите что при нахождении на сайте 100 000 пользователей одновременно - скорость загрузки сайта не будет падать и он не рухнет, выдав 404 ошибку.
Если же у вас интернет-магазин, то вы сразу должны указать сколько позиций товаров отображаются на сайте пользователю. Все сразу (что повесится браузер) или же какое-то конкретное количество, а дальше подгрузка других товаров будет происходить либо через кнопку "Показать еще", либо автоподгрузка, когда пользователь "домотает" до конца страницы?
Вы могли заметить такое на Авито при листании каталогов или же в ВК, когда листаете ленту и т.д. - так работает автоподгрузка. Представьте что было бы если бы сайт автоматически выгружал вам все 6 000 записей (например) на странице пользователя в том же ВК - сам ВК может такое и стерпел бы, но вот ваш браузер нет, а ваш сайт тем более, т.к., ему нужно отобразить ваш товар и для остальных посетителей вашего сайта.
Как в прототипе, так и в ТЗ вы сразу должны определиться с цветовой гаммой сайта, в каких цветах и где они будут выполнены.
В любом случае - написать грамотное ТЗ и тем более с первого раза, еще и не забыв все учесть - задача почти нереальная. Поэтому лучше отдайте это дело профессионалам или тем кто имеет хороший опыт в написании ТЗ и прототипировании. Лучше переплатить здесь, чем потом переплатить гораздо больше, потеряв не только деньги, но и время.
В письме 1 файл - это ТЗ, можете приступать.
Хорошим тоном будет если вы разобьете ТЗ на несколько частей, а не засунете все в один ГИГАНТСКИЙ документ. Например:
Главная
Регистрация, авторизация, восстановление пароля
Личный кабинет
Страница пользователя
Страница настроек пользователя
Корзина
Страница пополнения баланса
Страница справки
Страница поиска и т.д.
Это удобно, т.к., в Trello вы сможете все разбить на этапы и отслеживать по какому именно разделу сейчас идет работа, по каким планируется (что осталось), а по каким работы завершены.
А если разделы очень большие, то лучше будет создать папку и уже там складировать несколько ТЗ, но которые связаны с конкретной задачей.
Например у меня папка "Услуги", там несколько ТЗ и они описывают все - от того как ее создать и что будет происходить, до того, как эту услугу заказать и как будет происходить сделка между пользователями. На данный момент там 4 документа.
Подведем итоги.
Пишите однозначно и точно (никаких "я думаю", "было бы неплохо").
Укажите общую информацию (заполните бриф).
Поясните сложные термины (если вы шарите).
Опишите инструменты и требования к хостингу (CMS, стек технологий).
Перечислите требования к работе сайта (скорость, отказоустойчивость).
Укажите структуру сайта (в идеале сперва лучше нарисовать на листочке).
Объясните, что будет на каждой странице (контент, кнопки).
Распишите сценарии использования сайта (сценарии действий пользователя).
Опишите дизайн (если сможете).
У ТЗ должна быть структура (ведите нумерацию пунктов).
Разбивайте ТЗ на несколько частей (чтобы было проще работать).
Не стесняйтесь спросить.
Возможно здесь можно было бы написать про Github и подобные сервисы по управлению репозиториями и контролем версиями, но это уже больше для опытных.
Рекомендую почитать: тынц
Обо мне...
Можете узнать на deamoned.com
По моим ТЗ на данный момент разрабатываются несколько действительно сложных сервисов, если кратко:
Соц., сеть профессиональных контактов, с поиском и размещением вакансий, заключение сделок и т.д. Сравнивают часто с LinkedIn.
Автоматизированный агрегатор скидок (пользователи сами создают свои акции и размещают на сайте через конструктор акций) + кэшбэк сервис.
Сервис заданий (типа YouDo).
И все 3 сайта связаны между собой, нужен всего 1 аккаунт и все это бесплатно. Ближе к лету запуск.
Плачу за это я сам, а значит что в моих интересах чтобы мои ТЗ были четкими. Ссылки не указываю, ибо пока в разработке и особо нечего показывать. Хотя самые любопытные уже нашли где посмотреть)
А пруфы?
Сделано в рамках программы Product University