Web-дизайн. Перевод с технического
Стоимость — от 6400 рублей в час, но не менее 15000 рублей.
Предусмотреть все нюансы проекта в техническом задании невозможно. Во всяком случае, если речь идет о web-дизайне. Как ни странно, это положение было доказано еще в начале 70-ч годов прошлого века, то есть - в те времена, когда не то, что о web-дизайне никто и не помышлял - интернета еще не было.
Классический подход - попытка создать всеобъемлющий и всепредусматривающий проект, по которому уже вести работы, натолкнулась на пренеприятную особенность программных систем - сроки разработки проекта и сроки разработки продукта начинали стремиться к бесконечности.
Для решения этой проблемы, классический подход (его еще называют водопадным) был изменен на итерационный. При итерационном подходе, проектирование происходит постепенно - сначала проектируются наиболее общие функции системы, затем эти функции реализуются, затем происходит проектирование менее общих составляющих системы, их реализация и т.д. - вплоть до создания готового продукта.
Фактически, любая студия, создавшая (чисто эмпирически) более 10 сайтов, уже применяет итерационный подход в той или иной форме (конечно, существует вероятность, что все эти десять сайтов, на самом деле, суть клоны. Если вам нужен одиннадцатый клон - нанимайте такую студию без лишних раздумий. Если вы хотите чего-то большего...) Проблема заключается в том, что при заключении договора и создании технического задания, Заказчик, скорее всего, хочет видеть именно "всеобъемлющее и всепредусматривающее" техническое задание. И Заказчик, по своему, прав - он просто хочет знать, что именно он получит за свои деньги.
Поскольку, проблема эта далеко не уникальна, существует и простой метод ее решения - отражение в техническом задании всего перечня требований и задач, поставленных перед создаваемым сайтом. При этом, методика реализации поставленных задач, как правило, не упоминается, либо упоминается в самых общих чертах. Собственно, такое техническое задание состоит из списка требований и первой итерации проектирования. Такой подход предоставляет максимум возможностей для оперативного изменения проекта, одновременно обеспечивая надлежащий контроль за соответствием проекта поставленным задачам.
К сожалению, технические задания, составленные вышеописанным образом, встречаются не так уж и часто. Куда чаще, в технических заданиях можно найти...
Что можно найти в техническом задании?
Недостаточная информативность
"...действия, доступные менеджеру в бэк-офисе модуля Новости: ...Создать новый объект типа новость, заполнив соответствующие поля..."
Не упоминается, что добавление на сайт новости с фотографией, помимо заполнения соответствующих полей, требует еще около 40 кликов мышкой и в 70% случаев приводит к сбою системы.
Избыточная информативность
"...Главное меню сайта содержит ссылки на разделы "О компании", "Услуги", "Продукты", "Новости", "Контакты"..."
При создании дизайна сайта могут быть приняты решения, препятствующие расширению этого списка. Необходимость расширения может потребовать серьезной и дорогостоящей переделки дизайна сайта.
Перекос в сторону конкретного исполнителя
"...Исполнитель должен являться создателем CMS Имярек и предоставить доказательства о внедрении не менее 300 проектов на этой CMS..."
Подобные условия иногда встречаются в тендерных ТЗ - они сразу отпугивают всех, кроме компании, "под которую" это ТЗ написано. Конечный результат может оказаться любым (то есть, не обязательно все будет так уж плохо. Но и не обязательно, все получится именно так, как требуется Заказчику).
Двойственность трактовок
"...обеспечение идеальной архитектоники проекта..."
Не совсем понятно, как применить использование термина "архитектоника" к созданию сайта, что именно имели в виду разработчики технического задания, и какие выводы из этой фразы должен извлечь Заказчик.
Каждая студия создает техническое задание исходя из применяемых платформы разработки и методологий разработки сайтов. Определенные аспекты разработки сайта в таких технических заданиях могут освещаться не полно, либо не освещаться вовсе. С другой стороны, другие аспекты могут быть освещены излишне подробно. Наконец, в техническом задании могут встретиться и просто туманные наукообразные термины, допускающие множественную трактовку.
Аудит технического задания должен выявить проблемные положения анализируемого технического задания на разработку сайта, и поспособствовать их исправлению.
В работах по аудиту технического задания мы используем вариант итерационного метода - каждая итерация состоит из одних и тех же шагов, в случае обнаружения проблемных положений, проект технического задания отправляется на доработку (но только после прохождения всех итераций, кроме создания эскизного проекта), после доработки аудит повторяется.
Вычленение описаний функционала и дизайна, позволяющих множественное толкование
Очень важно добиться одинакового понимания терминов, используемых в техническом задании, как Исполнителем, так и Заказчиком. Иногда в этом могут помочь входящие в состав технического задания глоссарии. Чаще всего, такие глоссарии приходится дополнять. Кроме того, многие положения технического задания, при всей их внешней понятности, могут быть трактованы Исполнителем и Заказчиком по-разному, а зачастую - вообще противоположно. Причем обнаружение таких положений не специалистом может быть затруднено, а то и вовсе невозможно.
Первоочередной задачей при аудите технического задания является локализация подобных положений, уточнение их у Исполнителя и дополнительное согласование уточненных положений с Заказчиком.
Вычленение описаний функционала и дизайна, ограничивающих возможности расширения
Отдельные положения технического задания могут серьезно ограничивать будущее расширение или изменение структуры сайта. В зависимости от используемой платформы разработки, такие положения могут в будущем привести к серьезным дополнительным затратам как на переработку функционала сайта, так и на внесение изменений в дизайн сайта. Причем, положения эти также могут остаться не замеченными.
После локализации положений технического задания, ограничивающих возможности расширения и изменения сайта, проводятся консультации с Заказчиком и, при необходимости (когда выявленные ограничения с заказчиком не согласовывались), уточняется список требований
Вычленение недостаточно полных описаний функционала и дизайна
На данном этапе может потребоваться изучение выбранной для реализации платформы разработки. Если платформа разработки в готовом виде отсутствует, может потребоваться дополнить техническое задание дополнительными требованиям к дизайну и функциональности
В случае обнаружения замечаний, после прохождения первых трех этапов техническое задание может быть отправлено на доработку. После доработки, аудит повторяется.
Проверка эскизного проекта на соответствие требованиям и задачам, стоящим перед сайтом
В случае, если замечаний, неоднозначных трактовок и т.д., обнаружить не удалось, создается эскизный проект будущего сайта. Эскизный проект представляет собой комплект документов, выполненных в соответствии с RUP и представленным техническим заданием. Задача эскизного проекта - понять, можно ли по техническому заданию создать сайт, соответствующий поставленным Заказчиком требованиям и Задачам. По результатам создания эскизного проекта может быть вынесен вердикт о соответствии, либо несоответствии технического задания проекту. В последнем случае, создается перечень "узких мест" и проблемных положений. Перечень и техническое задание отправляются на доработку, после которой процедура аудита повторяется.
В среднем, полный цикл аудита технического задания на создание сайта, занимает около 4 часов.
