Аббревиатура «ТЗ» (Техническое Задание) знакома, наверное, всем. Более того, многие понимают важность тех-задания при постановке задачи. Но когда дело доходит до написания документа, к огромному сожалению, даже примерных "набросков" заказчик не предоставляет. Очередной подобный случай в нашей студии, дал повод для подготовки информационного материала про важность ТЗ для разработки.
Пишем ТЗ под каждый сайт ?
Написание постановки для программиста наиболее актуально, когда разрабатывается серьёзный проект. Заказчик и исполнитель должны понимать, что одностаничник или визитка от подробного ТЗ только проиграют. Время сильно увеличится, а результат скорее всего останется прежним. Функциональный интернет-магазин в свою очередь, без технического задания только проиграет.
По статистике примерно 70% сайтов относятся к простым, несложным страницам; в силу малости размеров, подобные проекты довольно легко реализуются при грамотном account менеджере.
Доступно доносим необходимость ТЗ
«Я и так всё знаю, там просто», «Мне не нужно сложного сайта, сделаем быстро», «С дизайном проблем не будет, всё обыденно» - всё это типичные ответы на вопрос, касаемо ТЗ. Иногда заказчик словесно четко описывает требования и пожелания для своего сайта, но намного чаще на деле оказывается, что он отдаленно представляет, что ему в итоге нужно. Давайте рассмотрим пример постановки задачи заказчика для каталога Интернет - магазина:
5-6 разделов каталога, карточка товара, по аналогии с конкурентами содержит дополнительные фото, краткие характеристики товара, разумеется цену и выбор цвета, кнопка оформить заказ.
Не вдаваясь в дизайнерские нюансы, после настройки данного функционала и демонстрации его клиенту, выясняется, что необходимо ещё добавить сравнение товаров "как в Яндекс Маркете", вывод "рекомендованных" объектов под карточкой и баннер с акцией ведущий на отдельную страницу. Разумеется всё это не обговаривалось при заключении договора, не обрисовано в макете, но при этом весьма логично, согласны ?
Пойдя на встречу клиенту и сделав эти работы бесплатно, выясняется, что логично было ещё сделать в карточке выбор количества товара и добавить отзывы. Исполнитель на распутье, дальше делать всё бесплатно или выставлять счёт на дополнительные работы? Каждый прав со своей стороны. Функции приведенные выше, достаточно логичны для интернет-магазинов, но о них не было и слова в разговоре. При согласованном ТЗ таких моментов не было бы в принципе, так как логика работы каталога давала бы полную картину необходимого функционала для настройки. Плюс само задание являлось бы приложением к договору.
Важно, без ТЗ стоимость доработок может быть даже больше первоначальной стоимости сайта!
Что стоит включить в ТЗ, а от чего воздержаться ?
Исходя из многолетнего опыта, мы выработали правило, которое помогает сделать ТЗ подробным и компактным одновременно: задание пишется с изначальной оглядкой на то, что с заказчиком не удалось найти понимание и идут споры. Документ будет крайне точным, трактуемый одинаково всеми сторонами, без лишней "воды".
На примере четко видна разница всего 1 строчки из ТЗ и обычного описания:
-
Простое описание: Стандартные пункты меню, услуги компании, контакты
-
Строка из ТЗ: Главная (статичная страница), услуги (выпадающие пункты проектирование, дизайн, архитектура), проекты (переход в галерею), контакты (якорь на Яндекс карты снизу главной страницы)
Четкая формулировка и описание куда ведёт каждый раздел сразу отвечает на ряд вопросов, когда "плавающее значение стандартных пунктов" говорит скорее о том, что клиент не знает, что будет за ними. Эти пункты будут ещё меняться скорее всего не один раз. Расписывать постановку красочными эпитетами не рекомендуется.
Закончить ТЗ можно, мы бы даже сказали бы, нужно, фразой «что не оговорено — на усмотрение исполнителя».
Разделы и структура ТЗ
1. Вводная часть. Первый и единственный пункт, где можно своими словами в общих чертах описать о чём и для чего будет будущий проект. Держим в голове, что программист может видеть задание впервые и чем меньше у него будет вопросов, тем точнее будет выполнена задача.
2. Терминология. Технический язык программистов богат, общаясь с заказчикам менеджер строит диалог максимально просто и доступно. Когда речь доходит до ТЗ, ряд сложных технических терминов просто необходим. Для того, чтобы Заказчик понял о чём идёт речь в документе и был уверен что с программистом он говорит на одном языке, аккаунт приводит краткий список расшифровки этих самых терминов.
3. Цели сайта. Если ваш ресурс не относится к личному блогу или страничке по хобби, то его задачей будет получение прибыли. В данном разделе необходимо кратко расписать цели проекта (оформление Заказа, оплата товара, переход по рекламному баннеру).
4. Техническое назначение. Ознакомившись с целями и задачами, следующий пункт даёт информацию, какой функционал для этого использовать, какие необходимы модули и скрипты. Например, для покупки товара с сайта, необходима корзина товара, каталог и форма заказа.
5. Перечень данных. Ключевой раздел ТЗ, зачастую заменяемый в диалоге на оборот "возьмите у конкурентов". Перечень данных - это точные значения всего функционала веб-сайта. От новостей до формы связи, от полей каталога до строчек в калькуляторе. Данные модуля - это так называемые поля и значения, необходимые для заполнения клиентом и (или) администратором. Разберём два примера.
Стандартный модуль новостей содержит такие значения для ТЗ:
- Название новости
- Дата
- Фото
- Анонс
- Подробное описание
При этом, стандартный модуль со своими стандартными значениями может сильно изменятся в зависимости от тематики. В спортивных порталах новости могут дополнительно содержать виды спорта, календарь событий и новостей, рейтинг. Не согласовав и не указав все поля, заказчик скорее всего получит в ходе работы новые "хотелки" клиента.
Стандартная форма обратной связи содержит такие значения для ТЗ:
- ФИО
- Телефон
- Текст сообщение
При этом, в форму могут добавляться выпадающие списки для выбора города, "чекбоксы" для подключения доставки, "радиокнопки" для корректировки времени звонка. Не согласовав и не указав все поля, исполнитель снова может получить недоговоренные новые правки.
6. Списки. Встречаются разные типы списков, от похожих товаров в каталоге, до последних новостей в новостной ленте. Обычно этот пункт пропускается из-за его ненужности (по мнению клиента). Однако уже на финальных этапах начинаются корректировки этих списков, что вырисовывается в дополнительные часы работ.
7. Описание страниц сайта. С одной стороны пункт не обязателен для заполнения, нужные моменты мы указываем в опроснике, с другой стороны даже контентная страница по описанию может отличаться от прорисованной дизайнером. Для таких случаев и нужен этот пункт в ТЗ.
8. Технические требования к хостинг площадке. Хостинг является по сути третьей стороной в отношениях заказчика и исполнителя. Предоставляя дисковое пространство, провайдер не несёт ответственности за качество размещенного там материала (сайта). Но хостинг провайдер обязан предоставить новое программное обеспечение, бесперебойное оказание услуги и достаточное пространство.
На хостинге также может размещаться несколько веб-сайтов, это вполне нормальное явление и хорошая экономия средств. Могут ли сайты находиться на одной площадке физически, это ещё один вопрос, который нужно решить ДО разработки. Может быть стоит отказаться от "новомодного фреймворка", в пользу старой проверенной CMS, или заранее завести отдельную площадку под новый сайт.
Ну и наконец, хостинг-провайдер предоставляя свои услуги должен хорошо справляться с нагрузками со стороны пользователей и атаками со стороны хакеров. Часто молодые хостинг центры с очень привлекательными центрами этим требованиям не отвечают. Если клиент не уверен в выборе хостинга, лучше довериться разработчику, который отлично знает, где ресурс будет корректно и хорошо работать.
9. Контент и наполнение. Этот пункт крайне важен как для заказчика, так и для разработчика. Клиенту нужно требовать хотя бы базовое наполнение основных разделов и заведения тестовых учётных записей; исполнителю - точного описания, кто наполняет сайт (менеджер со стороны студии или контент-специалист клиента), каким образом наполняется сайт (клиент предоставляет информация сам, указывает источники откуда её взять или тексты пишет копирайтер), в каком объеме наполняются страницы.
10. Гарантийные обязательства и приёмка проекта. Договора, как правило, имеют стандартные формулировки по условиям приёмки работ. При этом индустрия сайтостроения имеет ряд нюансов, не подходящих под общее описание. К важным моментам относится исправление ошибок разработки. Этот пункт в зоне ответственности агентства даже после подписанного акта работ и получения всей оплаты.
Вместо заключения.
Разработка грамотного ТЗ - это большая трата времени. При этом заказчик будет постоянно напоминать, «почему же работы ещё не начались?», «зачем нужно столько писанины?». Но с другой стороны ТЗ сильно помогает в работе, защищает обе стороны. Стоит ли оно потраченного времени и средств? - зависит от того, на сколько хорошо понял задачу account-менеджер, и на сколько сложен проект. В любом случае техническое задание станет хорошим "подспорьем" для всех сторон.
