По мере проникновения Интернета в жизнь, мне все чаще приходится общаться с людьми, которые имеют идеи и хотят "что-то такое” сделать в Интернете для развития своего бизнеса, персонального продвижения, зарабатывания денег и др. При этом, как правило, они сами не очень четко понимают, что именно им нужно. А даже если и понимают, то не в состоянии это четко сформулировать – из за нехватки опыта и/или времени (как правило, это люди очень занятые).
И когда, так и не сформулировав это, они выбирают разработчика и доходят до стадии разработки проекта, начинаются стандартные проблемы – заказчик получает не то, что он хотел (потому что за него додумал исполнитель), а на доделку и переделку нужно дополнительное время и деньги. В результате, как правило, получается вечно недоделанный проект, который заказчика не устраивает, и все остаются недовольны друг другом.
При этом практика предварительной подготовки ТЗ, которую практикуют исполнители (причем не все, а только хорошие), как правило, не спасает – так как полноценное ТЗ – это большой и сложный (десятки, а то и сотни страниц), в основном технический документ, который редкий заказчик способен полностью прочитать и понять.
Моя практика показывает, что этих проблем можно в значительной степени избежать, если предварять разработку ТЗ подготовкой по сути другого документа – КОНЦЕПЦИИ проекта, описывающей требования верхнего уровня, сформулированные в терминологии заказчика.
В отличии от ТЗ, концепцию можно содержательно согласовывать с первыми лицами заказчика, потому что более глубокие вещи им непонятны и неинтересны. В то же время эта информация, внятно изложенная и утвержденная, дает достаточные ориентиры для подготовки ТЗ.
Наличие утвержденной концепции очень сильно облегчает дальнейшее взаимодействие между заказчиком и исполнителем - особенно для больших корпоративных заказчиков, так как для ответов подавляющего большинства вопросов к ТЗ и сайту типа "Почему именно так?" или "Почему этого нет?" можно сослаться на утвержденную концепцию.
Что должно входить в концепцию
- краткое описание сути бизнеса, оргструктуры и количественных характеристик компании и ее бизнеса. Этот раздел нужен в основном не заказчику, а самому разработчику концепции – чтобы "сверить часы” с заказчиком, и убедиться, что ничего существенного для разработки концепции не упущено.
- Цели, которые заказчик хочет достичь с помощью разрабатываемого проекта, с обязательным указанием приоритетов (например – увеличить розничные продажи, расширить партнерскую сеть, повысить инвестиционную привлекательность компании и др.).
- Основные задачи, которые должен решать сайт для достижения указанных целей (например – для увеличения розничных продаж предоставлять полную информацию по продуктовой линейке и обеспечить возможность он-лайн заказа на сайте, для расширения партнерской сети – информировать потенциальных партнеров о преимуществах и условиях работы, иметь закрытый раздел для партнеров с информацией для них, предоставлять возможность заказа с учетом их скидок и др.) Основных задач много не бывает – как правило, не более десятка.
- возможно более полное перечисление целевых групп (сегментов целевой аудитории), на которых ориентирован сайт, и описание - зачем они нам нужны (фактически - ПР-концепция сайта, которую по идее должны делать штатные ПР-щики, но почти никогда не делают). На этом этапе важно правильно и точно определить целевую аудиторию сайта и проекта в целом. О том как это сделать можно узнать тут: https://cpalive.pro/11930/.
- перечень и характеристики информации/сервисов, которые мы планируем предоставлять этим целевым группам. Если нужна обратная связь с этими ЦА – то какая, и зачем.
- информационное окружение сайта ( какую информацию откуда брать брать и кому отдавать) - с привязкой к оргструктуре и автоматическим системам заказчика
- перечень и краткое описание основных технологических (бизнес-) процессов по обслуживанию сайта и его посетителей с проекцией на оргструктуру заказчика - т.е. кто что из перечисленного должен делать. Тут может выясниться, что часть функций выполнять некому, и требуется найм дополнительных сотрудников или аутсорсеров.
- если проект предполагает какую-то креативную или социальную активность со стороны аудитории (user-generated content, прямые коммуникации между пользователями или в группах и др.) – то описание системы мотиваторов – т.е. зачем и почему пользователи будут делать то, что мы от них ожидаем.
- количественные и нагрузочные требования к проекту – ожидаемые размеры баз данных, частота обновления информации, предельная посещаемость сайта (раздельно – анонимными и авторизованными пользователями), ожидаемое количество пользовательских транзакций по типам.
- Этапность ввода проекта в эксплуатацию. Зачатую проект может быть разделен на такие блоки, что их есть смыл разрабатывать и вводить в эксплуатацию поэтапно. Если это возможно – это почти всегда целесообразно. Эту логику тоже есть смысл описать в концепции и согласовать с заказчиком.
Но при всем при этом в объем концепции не должен превышать 15-20 страниц. При большем объеме она не сможет выполнить свою основную функцию – быть полностью понятой и согласованной с лицом, принимающим решения со стороны заказчика.
Организация процесса заказа и разработки
Итак, как должен быть по хорошему устроен процесс заказа проекта?
1. Разработка концепции. Разработать ее может сам заказчик, представитель разработчика, или отдельный приглашенный консультант. Разработка концепции – это скорее работа для бизнес-аналитика, но от него также требуется знание азов ПР, хорошее знаний Интернет-технологий и реалий современного Интернет. Концепция должна быть обязательно согласована с заказчиком, причем факт согласование должен быть четко зафиксирован. Не согласовав концепцию двигаться дальше нельзя.
2. Разработка ТЗ на основании концепции. ТЗ – это подробный технический документ, объемом обычно 50-100 страниц. Основная задача ТЗ – не столько описать задачу для исполнителя, сколько дать критерии для приемки-сдачи работ. ТЗ также должно быть формально согласовано с заказчиком (правда, это действительно обычно формально, так как редкий заказчик полностью осилит такой объем). Разрабатывать ТЗ может тот же специалист, что готовил концепцию. Если ТЗ готовят другие исполнители, оно должно быть согласовано с разработчиком концепции.
Что должно быть в ТЗ – это предмет отдельной статьи, которую я может быть. как-нибудь соберусь написать. Но если предполагается поэтапный ввод проекта - в ТЗ должен быть раздел, посвященный последовательности ввода сайта в эксплуатацию – с перечнем этапов и детальным описанием каждого этапа (какие блоки/модули/функциональность/типы страниц из описанных выше он включает).
Не забудьте также включить в ТЗ требования к сайту с точки зрения поисковой оптимизации – переделывать потом может оказаться сложно и дорого.
3. Выбор исполнителя и определение срока и бюджетов. Наличие ТЗ дает высокую степень независимости от исполнителя, так что пространство выбора сильно расширяется – можно даже проводить открытый тендер. Впрочем, все равно желательно, чтобы у исполнителя были хорошие рекомендации от знакомых людей. Потому что даже при достаточно детальном ТЗ у исполнителя все равно остается широкий простор для принятия решений, и желательно, чтобы эти решения были изначально разумными – меньше переделывать придется. Но даже при идеальном соответствии ТЗ почти всегда проект приходится доделывать – и в силу изменения понимания с течением времени, и из-за того, что каким бы подробным ТЗ не было, все равно найдутся моменты, которые сделаны в соответствии с ТЗ, но получились неудобными и некрасивыми. Поэтому целесообразно изначально заложить в бюджет процентов на 30%-50% больше, чем указано в договоре с исполнителем.
4. Собственно, разработка. Разработка и приемка-сдача происходит на основании ТЗ. Но это – отдельная тема, про которую написано достаточно много. Здесь я отмечу несколько важных моментов, которые часто упускаются.
- крайне важно до начала верстки согласовать дизайн не только главной страницы, но и основных типов внутренних страниц.
- надзирать над разработкой должен со стороны заказчика человек, который детально знает ТЗ, а лучше – принимал участие в его написании.
- реализацию, приемку-сдачу и оплату работ желательно вести как можно более мелкими этапами, причем желательно привязывать это к вводу отдельных блоков в эксплуатацию. В начале работы конечно, идет некоторый "темный” подготовительный этап, результаты которого заказчик не может контролировать. Желательно, чтобы бюджет этого этапа не превышал 50% общего. Но дальше целесообразно как можно быстрее запустить проект в начальном объеме, и все дополнительные блоки принимать по факту ввода в эксплуатацию.
- сотрудников, которые будут заниматься обслуживанием проекта со стороны заказчика, желательно включать в процесс как можно раньше – на этапе приемки-сдачи соответствующих блоков. Во первых, они быстрее наберут квалификацию, во вторых – выступят идеальными бета-тестерами.
Заключение
Практика, к сожалению, показывает, что даже при соблюдении правильной последовательности шагов результат не всегда бывает удовлетворительным.
Очень много проблем возникает при вводе в эксплуатацию – службы заказчика, как правило, оказываются неготовыми, а когда работа наконец начинается, вылезают в большом количестве ранее не замеченные дефекты реализации или ТЗ…
Сроки разработки не соблюдаются почти никогда – к этому тоже нужно быть готовым.
Регулярно так же бывает, что требования заказчика меняются по ходу дела – но тут хорошей страховкой являются утвержденные ТЗ и концепция.
Но все равно – при описанном выше подходе количество проблем и затрат нервной энергии существенно меньше, чем "в среднем по больнице”.
