Продуктовая разработка: как получаются действительно хорошие сайты

Уже подняли много вопросов, не так ли? Начнём с самого непонятного:

Что такое продуктовая разработка?

Если кратко — это доставка ценностей. Они лежат на двух уровнях: внешний уровень потребителя и внутренний уровень бизнес-процессов. Обо всём по порядку.

Уровень потребителя.

Это то, что мы видим, заходя на сайт как обычный посетитель. Здесь в главных ролях выступают:

1. УТП (уникальное торговое предложение). Это тексты, заголовки, схемы, таблицы, отзывы, картинки и видео, которые рассказывают нам о том, как компания решает наши проблемы и избавляет от боли. В основном это и есть главный предмет продуктовой разработки. Цель — наименьшим количеством итераций проверить гипотезы и найти путь доставки до пользователей идеи о том, что именно ваша компания и ваш продукт может решить их задачу лучше, чем другие.

   Итерация — это когда мы сделали действие > проверили результат > снова сделали действие, но с учётом полученного опыта. Пример: запустили страницу на сайте, версия 1.0 > пользователи жалуются, что на мобилке старница медленно загружается > Доработали и выпустили версию 1.1, где починили скорость. Но тут же заметили, что не работает слайдер > выкатили версию 1.2, где всё работает. Каждая новая версия — это итерация.

   Здесь уместно дать ссылки на статьи по темам УТП и итеративности (в конце этой статьи они продублированы, так что не обязательно переходить сейчас):

   Как написать хорошее УТП >

   Релизный метод развития дизайна сайтов >

2. Удобство использования. Это пресловутые UI/UX (интерфейс и опыт взаимодействия). На рынках с высокой конкуренцией компании должны делать всё возможное, чтобы пользователь мог не только начать решать свою задачу, но ещё делать это просто и желательно с удовольствием. Поэтому сайт должен быть логичным, навигация — интуитивной (насколько это возможно), кнопки должны работать, страницы быстро загружаться, сообщения отправляться, ответы от компании приходить максимально быстро. Словом, фичи сайта должны работать.

3. Красота. Она всегда относительна и очень субъективна. И тем не менее — важна, потому что дизайн, который не только функционален, но ещё и эмоционален, гораздо лучше, чем когда это не так.

Горькая правда:

Уровень бизнес-процессов.

Сайт должен быть понятен и удобен не только тем, кто покупает и приносит деньги, но и сотрудникам компании, которые обеспечивают её процессы. Об этом тоже важно думать и создавать среду для комфортного решения задач под капотом.

Возьмём к примеру рядовую задачу: публикация нового товара в каталоге. Потребитель, заходя в карточку товара, обращает внимание на фото, характеристики, описание, видео, отзывы и прочее — на то, что влияет на принятие решения о покупке. Все эти материалы на сайт ведь кто-то загружает, так? А кто это делает? Как это происходит? Какой у этого человека опыт работы в админках? Сколько времени, которое оплачивает работодатель, это занимает? 10 минут? Час? Или вообще, когда дело доходит до обновления каталога, все тут же уходят на больничный, лишь бы этим не заниматься?

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

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

***

«Зачем мне дорогой сайт, если можно сделать дешёвый на “Тильде”?»

Это возражение входит в ТОП-3 возражений.

Конфликт дешёвого и дорогого сайта возникает, когда мы задачей делаем разработку софта, а не улучшение процессов и рост бизнеса. В этой логике заказчик видит сайты товарами с универсальными товарными характеристиками. Например, количество страниц, количество символов текста, функционал отправки сообщений, возможность публиковать новости. А раз так, то логика подсказывает купить у тех, кто предлагает лучшую цену при схожих видимых характеристиках. В этот момент мало кто думает, на чём будет сделан сайт: на Тильде, на Вордпрессе или на Битриксе.

Сайт как софт

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

При таком подходе заказчик берёт на себя продуктовую разработку, а подрядчикам делегирует только техническую часть.

Цель разработчиков сайта в таком подходе — сделать софт по ТЗ да побыстрее, поскольку цена не только невысокая, но и, как правило фиксированная (этим и берут), так что чем быстрее сделают — тем выше маржинальность. Они не касаются бизнес-процессов компании заказчика и вообще не вовлекаются в продукт. Им по сути пофиг, кто будет пользоваться сайтом, и про что он вообще. Логика примерно такая: мы договорились о разработке сайта с N-количеством страниц. Мы поработали и вот вам сайт с N-количеством страниц. Всё, ура! Заплатите нам и мы пошли.

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

Продуктовый подход к разработке сайта

Он сильно отличается от подхода «Сайт как софт». Разработка продукта — это вообще не разработка софта. Здесь предметом разработки является доставка ценности и тестирование гипотез.

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

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

Особенно хорош продуктовый подход для новых или сложных продуктов.

Пример нового продукта: облачная бухгалтерия банков для бизнеса. Сейчас это уже не новый продукт, а стандарт онлайн-банкинга. Никто не помнит, кто сделал это первым. Но те, кто это придумал и сделал, совершенно точно занимались продуктовой разработкой. Они выявили боль предпринимателей и создали для них ценность, которая вывела этот банк в лидеры. А хороший продукт, как известно, копируется конкурентами очень быстро. Так случилось и с онлайн-бухгалтерией.

Примером сложного продукта: промышленное оборудование или корпоративное ПО. Любые сложные и дорогущие станки и программы — это всегда а) длительные циклы B2B продаж; б) жёсткая конкуренция и опять-таки копирование решений; в) потребность в сильном сервисе и технической поддержке г) обучающие программы для клиентов и сотрудников; д) большое количество людей, вовлечённых в разработку продукта, продажи и поддержку. И дальше по алфавиту. Здесь без продуктовой разработки не обойтись — очень много всего.

Подробное ТЗ при продуктовом подходе — зло

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

Думаем примерно в такой логике: Сначала мы сделаем что-то небольшое, например, запишем цикл видосиков и покажем их нашей аудитории. Если увидим позитивный отклик и посыпятся запросы на подробности, то сделаем посадочную страницу, чтобы менеджер перестал консультировать всех персонально и первым шагом мог отправить ссылку на посадочную страницу для ознакомления. Потом будем принимать решение, что делаем дальше. Такая разработка идёт в унисон или немного на опережение формированию бизнес-процессов компании.

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

Скорость тестирования гипотез и качество анализа обратной связи — вот, что имеет значение. Вместо ТЗ в продуктовой разработке применяется итеративный подход, когда большая задача разбивается на этапы и спринты с измеряемыми результатами и понятными сроками. Для координации используется «дорожная карта» проекта (road map).

Когда нужно съесть слона, то единственный верный способ это сделать — есть его по кусочкам. Продуктовая разработка — это работа, требующая стратегического мышления, вовлечённости в бизнес-процессы, слаженной команды и стальных нервов. Это другой уровень ответственности, нежели разработка сайтов как софта.

***

Кому подойдут недорогие шаблонные сайты?

Дешёвый сайт не всегда равно плохой сайт. Мы видели много очень дорогих и совершенно бесполезных сайтов. Быстрые шаблонные решения норм, если:

1. Надо вчера, а денег нет. Вы только начинаете, а в реквизитах нужно указать сайт, иначе стрёмно. Сайт на первое время.

2. Сами справляетесь с доставкой ценностей. Вы из тех, кто прекрасно понимает свой продукт, шарит в маркетинге, пишет крутые тексты и готов самостоятельно формулировать и проверять гипотезы (либо у вас есть своя команда). Вам просто нужны руки, которые соберут сайт за вас. Но есть нюанс: ваши возможности всё равно будут сильно ограничены. Подробнее прочитаете ниже под заголовком «Минусы».

3. Простой продукт и конкуренция только по цене. Когда вообще не нужно ничего объяснять про продукт. Бизнес-процессы отлажены. Цикл сделки короткий. Делаете, как все, только у вас дешевле. Бани-бочки, например (кстати, компактные модульные бани тоже когда-то были новым продуктом, требующим продуктовой разработки).

Минусы дешёвых сайтов на готовых шаблонах:

И они тут жирные, хотя их предпочитают не замечать те, кто принципиально ищет подешевле. 

Во-первых, вы на деле с вероятностью 99.9% столкнётесь с отсутствием мотивации и заинтересованности в развитии вашего бизнеса и сайта у разработчика. Продуктовая разработка как была, так и останется целиком и полностью на вас. Это будет отбирать ваше внимание и сбивать фокус с управления.

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

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

***

Когда нужна продуктовая разработка?

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

2. Вы хотите быть лидером рынка. И понимаете необходимость постоянных улучшений продукта. В этом случае дорабатываться должны ещё и средства доставки ценностей, одним из которых является сайт. В компании должна быть команда по продукту (внешняя или внутренняя), способная быстро тестировать гипотезы, анализировать информацию и помогать принимать решения по оптимизации текущих бизнес-процессов или разработке новых.

***

За продуктовой разработкой можно прийти в студию «Пиратский»

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

Также мы готовы рассматривать предложения партнёрства с маркетинговыми агентствами и дизайн-студиями, чтобы вместе решать сложные задачи. Например, мы можем помочь собрать и запустить сайт на Битриксе, если у вас нет своих спецов, а заказчику надо именно на нём.

Спасибо, что дочитали! Надеемся, внесли немного ясности :)

***

Продублированные ссылки:

Как написать хорошее УТП >

Релизный метод развития дизайна сайтов >