Как подготовиться к веб-разработке и получить от этого удовольствие

Любая веб-разработка — это гарантированная головная боль для заказчика. Можно ли сделать так, чтобы веб-разработка прошла легко и гладко? Честно — не знаю; но я знаю, как сделать так, чтобы головная боль от проекта была сведена к минимуму.

Чего надо остерегаться с самого начала

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

1. Экстренно писать техническое задание.
2. Деятельно искать подрядчика.
3. Проводить бесконечные совещания и выяснять, какой же сайт хочет получить руководство.
4. Пытаться угадать стоимость разработки.

Эффективная и выгодная реклама с сервисом от МегаФона

Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585. ERID LjN8K1P7y.

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

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

В самом начале нужно ответить на очень простой вопрос: чего мы хотим добиться? По-хорошему, на старте разработке мы должны достичь двух вещей:

• Собрать воедино наше представление о будущем продукте и возлагаемых на него задачах.
• Приготовить наши внутренние процессы к разработке.

Поиск и выбор подрядчика, как вы можете видеть, в первоочередные задачи не входит — это чисто прикладная (хотя и очень важная) задача. Ей мы займемся позже.

Почему вы не должны писать ТЗ

Скажу сразу: я очень скептически отношусь к идее писать ТЗ на стороне клиента. Причин тому несколько.

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

Во-вторых, ТЗ у всех разные. На рынке веб-разработки царит великое разнообразие подходов к проектированию и форматов ТЗ. Оставляя за скобками качество этого разнообразия, заметим, что разработчик, скорее всего, привык к одному из форматов, и если вы ему дадите в руки свое ТЗ — он захочет его переписать заново, так что вы потратите время впустую (ну а если разработчик не захочет переписать ваше ТЗ, то это будет свидетельствовать о том, что он недостаточно серьезно относится к этому документу — что тоже нехорошо).

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

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

Топ-менеджер ставит задачу на создание сайта. Справа различимы лица, принимающие решения. Слева различим бегущий менеджер, уточняющий задачу

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

Хорошая концепция имеет следующую структуру:

• Краткое описание продукта. В этом разделе нужно кратко, буквально в одном-двух предложениях, выразить суть разрабатываемого продукта.
• Бизнес-цели проекта. Данный раздел должен рассказывать о глобальной задаче, возлагаемой на проект, и фиксировать его KPI.
• Задачи, выполняемые продуктом. Здесь должны быть перечислены тактические задачи, которые будет выполнять проект.
• Целевая аудитория. В этом разделе уместно кратко описать целевую аудиторию продукта.
• Инфраструктурное окружение продукта. Этот раздел должен кратко описать, какие внешние системы будут взаимодействовать с разрабатываемым продуктом.
• Желаемая структура сайта. Здесь полезно указать предполагаемую структуру сайта — какие страницы будут присутствовать на сайте, в какой связи они будут находиться между собой. Впоследствии эта структура должна быть пересмотрена на этапе проектирования.
• Функциональные модули. Тут уместно прописать предполагаемые функции, которые будет выполнять продукт — опять-таки, кратко.
• Дополнительные пожелания и указания. В этот раздел следует заносить требования и пожелания, не описанные в предыдущих разделах — например, требования к адаптивности интерфейсов, указания на понравившиеся сайты и т.п. Крайне важно, чтобы пожелания были привязаны к общим бизнес-целям проекта и задачам продукта — в них обязательно должен быть конечный смысл.
• Открытые вопросы. Это самый интересный и часто забываемый раздел. Он должен содержать вопросы, на которые пока что не получается дать ответ.

Несмотря на кажущуюся сложность, концепция обычно не занимает много страниц — это всего лишь 2-4 листа убористого текста.

Почему хороших менеджеров должно быть двое

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

Менеджер со стороны заказчика презентует проект. Справа виден падающий сервер, слева — недоумевающий владелец компании. Менеджер со стороны подрядчика различим по шлему

Формулируя эти правила, необходимо сфокусироваться вот на каких важных направлениях:

• Команда. Вам понадобится команда, играющая на вашей стороне — и эта команда должна быть четко разделена по ролям. В базовом случае этими ролями будет «ответственный менеджер», «лица, принимающие решения», действующие в оговоренных случаях и рамках, и «помощники» — привлекаемые специалисты, которые будут предоставлять нужную информацию.
• KPI. До начала разработки должны быть сформулированы четкие KPI, по которым руководство компании сможет оценить, как хорошо вы справились с задачей разработки сайта. Какой это будет показатель (финансовый или какой-либо еще) — нужно формулировать в каждом случае отдельно, но и вы, и ваше руководство должны понимать критерии успешности разработки.
• Полномочия. Вместе с ответственностью к вам должны придти определенные права и привилегии; вы должны стать единой точкой коммуникации между разработчиком и представителем компании, должны обладать последним словом в решении спорных вопросов и уж точно должны обладать правом решать мелкие тактические вопросы без вынесения их на всеобщее голосование и обсуждение. Я знаю, что для опытных ушей все это звучит утопично — но, как минимум, надо стремиться к такому подходу.

Как бы вы хорошо ни сформулировали правила игры, посередине разработки неизменно возникнет какое-то третье лицо, которое скажет «Да плевать я хотел на ваши правила, делайте по-моему». Универсального контрприема нет. но есть хороший встречный вопрос «Какое бизнес-требование это удовлетворяет?». Если третье лицо не может дать внятного ответа и при этом еще и низкое по рангу, то хорошим аргументом будет «Где вы были на этапе согласований? Ваши замечания ценны, но они выходят за границы текущих договоренностей. Можем расширить границы и пересчитать сроки и стоимость».

Помните, правда будет на вашей стороне; это третье лицо будет, по факту, нарушать установленные правила, а это неплохой козырь во внутрикорпоративных разборках.

Хороший подрядчик: миф или реальность

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

Первое, чем вам надо заморочиться — это условиями выбора подрядчика. Конкретные правила могут изменяться от «Выбрали понравившихся из первой десятки Ruward» до «Устроили грандиозный тендер с десятью этапами, таблицей достижений и комиссией по закупкам». Вариантов много, но неукоснительно должно соблюдаться следующее:

• Правила отбора должны быть понятны, прозрачны и задекларированы — даже если это правило выглядит как «смотрим и выбираем понравившихся».
• Нужно определиться, что будет считаться заявкой от компании — коммерческое предложение, КП с предварительной дизайн-концепцией (картинками), КП с предварительной аналитикой или что-то иное.

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

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

Если же вам нужна «серебряная пуля» от меня на все времена — требуйте от подрядчиков только КП и внимательно следите смотрите за тем, какие дополнительные материалы будут приложены к этому КП — об этом мы поговорим чуть ниже.

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

Подрядчик продает проект заказчику. Слева направо: коммерческий директор со стороны подрядчика, менеджер со стороны подрядчика, менеджер заказчика

Я не буду в этой статье освещать все аспекты искусства проведения встреч, но отмечу самые важные вопросы, на которые надо обратить внимание:

• Кто приехал. Смотрите на состав команды, приехавшей обсуждать проект. Это будет, как минимум, человек, отвечающий за продажу (коммерческий директор/продажник/проектный менеджер, выполняющий роль продавца), но могут быть и дополнительные специалисты. Прекрасно, если на встречу приедет аналитик, который сможет предметно пообщаться по сути разрабатываемого продукта — это подтвердит интерес подрядчика к проекту и лишний раз покажет компетенции подрядчика. Отсутствие/наличие дизайнера на встрече, как правило, серьезным показателем не является, поскольку на раннем этапе выяснять подробные требования к дизайну смысла не имеет, если только речь не идет об обязательной предварительной дизайн-концепции, упоминавшейся выше.
• О чем спрашивает. Надо обратить внимание на то, какие вопросы задает подрядчик — они должны быть по делу и свидетельствовать о знакомстве с концепцией. Кроме того, нужно насторожиться, если подрядчик задает вопросы вида «А что вы хотите видеть на главной странице» и «Какое меню вы хотите — горизонтальное и вертикальное» — это значит, что подрядчик мыслит не рамками ваших задач, которые нужно решить, но делает ровно то, что вы скажете.
• О чем говорит. Нужно следить за тем, что он рассказывает о процессах разработки; эти процессы должны быть понятными, четкими и логичными — и обязательное место в них должно отводиться аналитике с проектированием, процессу работы над дизайном и составлению ТЗ. Дурной знак, если аналитикой и проектированием занимается менеджер (к сожалению, такая практика распространена на нашем рынке) — качественно эту задачу может выполнить только выделенный аналитик-проектировщик.
• Что показывает. Как правило, подрядчик приезжает с КП; оно должно четко показывать не просто глобальные цифры, а подробную разбивку на промежуточные этапы с указанием их очередности. Идеально, если к КП прилагается документ, содержащий предварительное видение продукта — это может быть наш концепт, доработанный подрядчиком или иной описательный документ.

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

Из огня да в полымя

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

Проговорим напоследок важные моменты, которые важно держать в голове на всем протяжении разработки:

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

Мнение редакции может не совпадать с мнением автора. Если у вас есть, что дополнить — будем рады вашим комментариям. Если вы хотите написать статью с вашей точкой зрения — прочитайте правила публикации на Cossa.