Любая веб-разработка — это гарантированная головная боль для заказчика. Можно ли сделать так, чтобы веб-разработка прошла легко и гладко? Честно — не знаю; но я знаю, как сделать так, чтобы головная боль от проекта была сведена к минимуму.
Чего надо остерегаться с самого начала
Итак, перед вами стоит задача — заказать для родной компании новый сайт. Доблестный менеджер обычно начинает хвататься за одно из следующих направлений:
- Экстренно писать техническое задание.
- Деятельно искать подрядчика.
- Проводить бесконечные совещания и выяснять, какой же сайт хочет получить руководство.
- Пытаться угадать стоимость разработки.
Все эти подходы на первый взгляд выглядят разумно, но беда в том, что они предпринимаются бессистемно и не служат какой-то единой цели помимо туманного «сделать сайт».
В самом начале нужно ответить на очень простой вопрос: чего мы хотим добиться? По-хорошему, на старте разработке мы должны достичь двух вещей:
Продвижение медцентров и клиник: три кейса о SEO, TikTok и Instagram*
Как получить измеримые результаты в фарммаркетинге.
Показываем на примерах →
Спецпроект
- Собрать воедино наше представление о будущем продукте и возлагаемых на него задачах.
- Приготовить наши внутренние процессы к разработке.
Поиск и выбор подрядчика, как вы можете видеть, в первоочередные задачи не входит — это чисто прикладная (хотя и очень важная) задача. Ей мы займемся позже.
Почему вы не должны писать ТЗ
Скажу сразу: я очень скептически отношусь к идее писать ТЗ на стороне клиента. Причин тому несколько.
Во-первых, заказчик не является специалистом по составлению ТЗ. Хорошее ТЗ, корректно и ответственно описывающее разрабатываемый продукт — это комплексный документ, который должен отвечать целому ряду требований — однозначности, системности, непротиворечивости, полноты, отчуждаемости. Цена ошибки при составлении ТЗ слишком велика, и поэтому составлением ТЗ должен заниматься человек с хорошо развитыми навыками аналитика-проектировщика и с соответствующим опытом — к примеру, у нас в Notamedia за это отвечает особый отдел.
Во-вторых, ТЗ у всех разные. На рынке веб-разработки царит великое разнообразие подходов к проектированию и форматов ТЗ. Оставляя за скобками качество этого разнообразия, заметим, что разработчик, скорее всего, привык к одному из форматов, и если вы ему дадите в руки свое ТЗ — он захочет его переписать заново, так что вы потратите время впустую (ну а если разработчик не захочет переписать ваше ТЗ, то это будет свидетельствовать о том, что он недостаточно серьезно относится к этому документу — что тоже нехорошо).
В-третьих, писать ТЗ до начала этапа аналитики и проектирования не имеет никакого смысла. Правильное проектирование — многоступенчатый процесс, который включает в себя несколько промежуточных документов и точек согласований, причем ТЗ в этом процессе появляется в самую последнюю очередь, когда закончены все творческие поиски и рассмотрены все альтернативы.
Таким образом, составлять ТЗ до начала разработки может только тот заказчик, который или любит ставить телегу впереди лошади, или настолько уверен в своих навыках проектировщика, что способен сходу написать корректное ТЗ (наверное, такое бывает — но лично я такого не встречал).
Делать же нужно вот что. Вам нужно составить не ТЗ, но емкий документ, который не будет вдаваться в детали, но будет давать информацию, необходимую для начала разработки. Такой «легкий» документ послужит хорошим началом для разговора с разработчиком, и называется он концепция продукта.
Хорошая концепция имеет следующую структуру:
- Краткое описание продукта. В этом разделе нужно кратко, буквально в одном-двух предложениях, выразить суть разрабатываемого продукта.
- Бизнес-цели проекта. Данный раздел должен рассказывать о глобальной задаче, возлагаемой на проект, и фиксировать его KPI.
- Задачи, выполняемые продуктом. Здесь должны быть перечислены тактические задачи, которые будет выполнять проект.
- Целевая аудитория. В этом разделе уместно кратко описать целевую аудиторию продукта.
- Инфраструктурное окружение продукта. Этот раздел должен кратко описать, какие внешние системы будут взаимодействовать с разрабатываемым продуктом.
- Желаемая структура сайта. Здесь полезно указать предполагаемую структуру сайта — какие страницы будут присутствовать на сайте, в какой связи они будут находиться между собой. Впоследствии эта структура должна быть пересмотрена на этапе проектирования.
- Функциональные модули. Тут уместно прописать предполагаемые функции, которые будет выполнять продукт — опять-таки, кратко.
- Дополнительные пожелания и указания. В этот раздел следует заносить требования и пожелания, не описанные в предыдущих разделах — например, требования к адаптивности интерфейсов, указания на понравившиеся сайты и т.п. Крайне важно, чтобы пожелания были привязаны к общим бизнес-целям проекта и задачам продукта — в них обязательно должен быть конечный смысл.
- Открытые вопросы. Это самый интересный и часто забываемый раздел. Он должен содержать вопросы, на которые пока что не получается дать ответ.
Несмотря на кажущуюся сложность, концепция обычно не занимает много страниц — это всего лишь 2-4 листа убористого текста.
Почему хороших менеджеров должно быть двое
Параллельно с формированием концепции полезно озаботиться подготовкой внутренних процессов к разработке. Изначально должны быть прописаны правила игры, по которым будет вестись работа, и они должны быть логичны и понятны для всех действующих сторон.
Формулируя эти правила, необходимо сфокусироваться вот на каких важных направлениях:
- Команда. Вам понадобится команда, играющая на вашей стороне — и эта команда должна быть четко разделена по ролям. В базовом случае этими ролями будет «ответственный менеджер», «лица, принимающие решения», действующие в оговоренных случаях и рамках, и «помощники» — привлекаемые специалисты, которые будут предоставлять нужную информацию.
- KPI. До начала разработки должны быть сформулированы четкие KPI, по которым руководство компании сможет оценить, как хорошо вы справились с задачей разработки сайта. Какой это будет показатель (финансовый или какой-либо еще) — нужно формулировать в каждом случае отдельно, но и вы, и ваше руководство должны понимать критерии успешности разработки.
- Полномочия. Вместе с ответственностью к вам должны придти определенные права и привилегии; вы должны стать единой точкой коммуникации между разработчиком и представителем компании, должны обладать последним словом в решении спорных вопросов и уж точно должны обладать правом решать мелкие тактические вопросы без вынесения их на всеобщее голосование и обсуждение. Я знаю, что для опытных ушей все это звучит утопично — но, как минимум, надо стремиться к такому подходу.
Как бы вы хорошо ни сформулировали правила игры, посередине разработки неизменно возникнет какое-то третье лицо, которое скажет «Да плевать я хотел на ваши правила, делайте по-моему». Универсального контрприема нет. но есть хороший встречный вопрос «Какое бизнес-требование это удовлетворяет?». Если третье лицо не может дать внятного ответа и при этом еще и низкое по рангу, то хорошим аргументом будет «Где вы были на этапе согласований? Ваши замечания ценны, но они выходят за границы текущих договоренностей. Можем расширить границы и пересчитать сроки и стоимость».
Помните, правда будет на вашей стороне; это третье лицо будет, по факту, нарушать установленные правила, а это неплохой козырь во внутрикорпоративных разборках.
Хороший подрядчик: миф или реальность
Когда понятны процессы и суть продукта, можно приступать к самому вкусному — выбору подрядчика. Я остановлюсь на самых главных моментах, на которых я в свое время набил много шишек, работая как на стороне заказчика, так и на стороне агентства.
Первое, чем вам надо заморочиться — это условиями выбора подрядчика. Конкретные правила могут изменяться от «Выбрали понравившихся из первой десятки Ruward» до «Устроили грандиозный тендер с десятью этапами, таблицей достижений и комиссией по закупкам». Вариантов много, но неукоснительно должно соблюдаться следующее:
- Правила отбора должны быть понятны, прозрачны и задекларированы — даже если это правило выглядит как «смотрим и выбираем понравившихся».
- Нужно определиться, что будет считаться заявкой от компании — коммерческое предложение, КП с предварительной дизайн-концепцией (картинками), КП с предварительной аналитикой или что-то иное.
Разумеется, всем заказчикам интересно увидеть дизайн-концепцию еще на этапе отбора претендентов, но надо учесть, что солидные разработчики будут готовы вложиться в неоплачиваемые дизайн-макеты только в том случае, если размещение вашего бренда в их портфеле перевесит риски бесплатной работы на пресейле. Если вы не представляете крупный, известный и «вкусный» бренд, но непременно хотите дизайн-макетов — будьте готовы, что в кандидатах у вас останутся в основном небольшие «молодые» студии.
Второй вариант — можно устроить оплачиваемый тендер, участие в котором будет оплачиваться компаниям-подрядчикам. Это хороший и надежный вариант, но он требует изначальных инвестиций.
Если же вам нужна «серебряная пуля» от меня на все времена — требуйте от подрядчиков только КП и внимательно следите смотрите за тем, какие дополнительные материалы будут приложены к этому КП — об этом мы поговорим чуть ниже.
На этапе отбора кандидатов крайне полезно отправить концепцию, подготовленную на первом этапе. Данный документ вместе с присланным КП должен стать предметом для первичных переговоров.
Я не буду в этой статье освещать все аспекты искусства проведения встреч, но отмечу самые важные вопросы, на которые надо обратить внимание:
- Кто приехал. Смотрите на состав команды, приехавшей обсуждать проект. Это будет, как минимум, человек, отвечающий за продажу (коммерческий директор/продажник/проектный менеджер, выполняющий роль продавца), но могут быть и дополнительные специалисты. Прекрасно, если на встречу приедет аналитик, который сможет предметно пообщаться по сути разрабатываемого продукта — это подтвердит интерес подрядчика к проекту и лишний раз покажет компетенции подрядчика. Отсутствие/наличие дизайнера на встрече, как правило, серьезным показателем не является, поскольку на раннем этапе выяснять подробные требования к дизайну смысла не имеет, если только речь не идет об обязательной предварительной дизайн-концепции, упоминавшейся выше.
- О чем спрашивает. Надо обратить внимание на то, какие вопросы задает подрядчик — они должны быть по делу и свидетельствовать о знакомстве с концепцией. Кроме того, нужно насторожиться, если подрядчик задает вопросы вида «А что вы хотите видеть на главной странице» и «Какое меню вы хотите — горизонтальное и вертикальное» — это значит, что подрядчик мыслит не рамками ваших задач, которые нужно решить, но делает ровно то, что вы скажете.
- О чем говорит. Нужно следить за тем, что он рассказывает о процессах разработки; эти процессы должны быть понятными, четкими и логичными — и обязательное место в них должно отводиться аналитике с проектированием, процессу работы над дизайном и составлению ТЗ. Дурной знак, если аналитикой и проектированием занимается менеджер (к сожалению, такая практика распространена на нашем рынке) — качественно эту задачу может выполнить только выделенный аналитик-проектировщик.
- Что показывает. Как правило, подрядчик приезжает с КП; оно должно четко показывать не просто глобальные цифры, а подробную разбивку на промежуточные этапы с указанием их очередности. Идеально, если к КП прилагается документ, содержащий предварительное видение продукта — это может быть наш концепт, доработанный подрядчиком или иной описательный документ.
Нельзя обходить стороной и тему договорных отношений — какой будет договор, какими будут приложения к нему и т.п. Подобные вещи могут стать серьезным камнем преткновения.
Из огня да в полымя
Поговорив со всеми кандидатами, вам остается лишь выбрать самого достойного, подписать с ним договор и приступить к разработке. С этой минуты у вас начнется новая жизнь — жизнь тяжелая, нервная, но интересная. И она будет тем более интересной и тем менее нервной, чем больше времени и сил вы вложите в подготовку.
Проговорим напоследок важные моменты, которые важно держать в голове на всем протяжении разработки:
|
Выполнив эти правила, можно рассчитывать на то, что подготовка к разработке пройдет максимально продуктивно и полезно для всей последующей работы. Легко не будет, но вы точно будете во всеоружии — а это главное.
Мнение редакции может не совпадать с мнением автора. Если у вас есть, что дополнить — будем рады вашим комментариям. Если вы хотите написать статью с вашей точкой зрения — прочитайте правила публикации на Cossa.
Источник:
