Что вы скажете о следующем утверждении?

«Будущее разработки ПО — за ИИ-агентами. Нам больше не нужны разработчики, которые тормозят развитие бизнеса»

Если вы сеньор и согласны с этим, я начинаю сомневаться в вашей компетентности (потом объясню почему; тут нет никакой враждебности). Но если вы не сеньор и согласны с этим, то, думаю, вы, скорее всего, правы. Что? Как так? Суть копирайтинга в том, чтобы донести идею до конкретной аудитории. Поэтому для меня, как копирайтера, происходящее очевидно: одно и то же послание всеми воспринимается по-разному.

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

Но минуточку! Многие заслуженные и знаменитые разработчики тоже провозглашают смерть своей профессии. Как же так? Чья интуиция тут права? И в чём причина такого противоречия?

Задача сеньора — избегать проблем

Когда я прихожу в команду, то встречаю два типа сеньоров. Первый обычно говорит что-то в духе:

• «Я тут новый прикольный инструмент нашёл…»
• «А вот в компании <название компании, не имеющей с нашей ничего общего> делают вот так, так что…»
• «Гляньте пост, там пишут, что это — лучшая практика, нам бы тоже стоило…»

Мне такой тип сеньоров не близок. Склонны к самозащите, давно в индустрии, скорее всего, приятны в общении. Но просто не мой тип людей.

А есть и другой тип сеньора:

• «Нам это правда нужно?»
• «А что, если этого не делать?»
• «Может, пока так оставим? Вернёмся к этому позже, когда прижмёт?»

О, а вот это мой человек! Эксперт по избеганию, сокращению и повторному использованию. Он хочет как можно меньше заниматься разработкой.

Почему? Потому что в профессиональной разработке они ведут охоту на главного монстра — сложность. Особые случаи, if-условия, новые таблицы в БД, новые компоненты — всё это ужасно. Сеньор стремится к минимуму всего этого, кучу времени думая о том, действительно ли новый код так нужен. Ведь добавлять что-то в систему — значит усложнять её.

Разумеется, это упрощённый взгляд. Есть сеньоры, которые берутся за нерешённые задачи и находят новые творческие решения. И у них это выходит замечательно. Но в итоге, если на тебе лежит ответственность за работающую систему, ты начинаешь бояться сложности. Почему? Чем плоха сложность? И почему остальные этого не понимают?

Бизнес боится неопределённости

Давайте для простоты представим бизнес в виде двух циклов.

Вот первый цикл; здесь живут маркетологи, продажники, продакт-менеджеры, гендиректор:

Главная цель этого цикла — пробовать и учиться. Бизнес стремится выводить продукты на рынок, чтобы получить фидбэк и понять, представляют ли они какую-либо ценность.

Для людей в этом цикле главный монстр — неопределённость. Неопределённость жестока, ведь ни одна стратегия не даёт гарантий. Если добавить сюда фактор времени (зарплаты маркетологов/продажников, фонд оплаты труда основателей или данные для продактов), начинает казаться, что единственный способ победить неопределённость до дедлайна — это выкатывать всё на рынок как можно быстрее. Чем больше ты выводишь на рынок, тем больше получаешь обратной связи, тем сильнее (в теории) снижаешь неопределённость.

Этот цикл (все компании с него начинают) — это про скорость в чистом виде.

Но что происходит, когда у бизнеса появляются клиенты?

Сеньорам крайне важна стабильность

Обратите внимание на второй цикл. Клиенты платят за сервис.

Именно в этом цикле и вращаются многие сеньоры. Главная цель здесь — обеспечить непрерывную работу сервиса. Чтобы всё крутилось, всё было понятно, всё можно было отладить, всё можно было починить, всему можно было научить, чтобы всё было стабильно.

Сеньоры переживают за стабильность, потому что на них лежит ответственность за то, чтобы бизнес продолжал обслуживать клиентов.

А что ставит всё это под угрозу? Сложность. Из-за неё система становится менее понятной, её тяжелее отлаживать, чинить и объяснять, и в итоге она становится менее стабильной. Растёт сложность = падает стабильность = сеньор не справляется со своими обязанностями = всем плохо, платежи не проходят, все грустят.

Итак, если цель первого цикла — уменьшить неопределённость, то цель второго — совладать со сложностью.

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

Окей, теперь вы, наверное, догадываетесь, к какому ответу на заглавный вопрос я веду.

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

Вот как выглядит история для людей из первого цикла:

А вот как выглядит история для сеньора из второго цикла:

И они не совпадают! Чем больше сеньору прилетает задач по доработке системы, тем чаще ему хочется возразить: «Ну нет… Это же сложность, затраты на поддержку, читаемость кода, скорость будущей разработки, общая продуктивность…» Но это совершенно не помогает бизнесу справиться с его главной задачей — уменьшить неопределённость.

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

И его рецепт: преподносите своё решение так, чтобы оно решало и их проблему тоже.

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

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

• Нужно провести опрос? Для этого есть Google Forms.
• Нужно запилить новую фичу, чтобы проверить гипотезу? А что, если просто добавить кнопку в существующий интерфейс и посмотреть, кликают ли на неё?
• Нужен новый сервис аналитики? А для какого такого важного решения эта аналитика нам нужна? Может, начнём с одного решения, одного графика и одной метрики?
• Зачем печь огромный торт? Просто воткни свечку в мой бутерброд!

Именно это и есть искусство сеньора: научиться давать людям желаемое, проявляя изобретательность с уже имеющимся софтом.

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

Может, попробуем какой-нибудь способ побыстрее?

Слово «побыстрее» показывает, что вы понимаете их главный запрос; «какой-нибудь» намекает, что есть другой путь; «попробуем» предполагает, что решение может быть неидеальным, но вполне рабочим. Эта фраза идеально попадает в потребность бизнеса (скорость для снижения неопределённости) и в то же время оставляет сеньору пространство для манёвра: сократить, переиспользовать, а в лучшем случае — вообще ничего не делать.

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

Но! Есть огромное «но»! Кажется, что с приходом ИИ всё это теряет смысл, верно? Зачем что-то урезать? Зачем переиспользовать? Зачем избегать? Ведь ИИ может написать кучу всего за минимальное время. Однако он пока не умеет делать то, что по-прежнему делают сеньоры. Нести ответственность.

Почему сеньоры — это редакторы, а не писатели

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

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

Так изначально выглядят два бизнес-контура:

А вот как ИИ на них влияет:

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

К счастью, у сеньоров есть пара козырей в рукаве. Один из них — decoupling (разделение). Долгое время только разработчики могли создавать софт. И они отвечали сразу за оба контура.

Одна система на две цели.

А что, если у нас будут две системы, каждая для своей цели?

Аналогия: писатель торопится закончить первый черновик (его ещё называют «черновик потока сознания» — vomit draft), а потом выбирает из него то, что работает, и выбрасывает остальное. После быстрого набрасывания текста идёт редактура. Работа редактора — взять удачные куски и собрать из них что-то цельное.

Что, если сделать одну систему чисто для скорости? В ней бы работали все, кто отвечает за быстрый запуск идей: ИИ-агенты, наш собственный сгенерированный код без ревью, джуны, маркетинг и так далее. Назовём её Speed-версией системы. Она не должна быть прозрачной, её задача — сделать «достаточно хорошо», чтобы выкатить на рынок и собрать фидбэк.

И что, если бы у нас была вторая система, нацеленная на стабильность? Назовём её Scale-версией. Её проектируют сеньоры, и она должна быть стабильной, понятной и масштабируемой.

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

Фичи создаются в Speed-версии, а затем доводятся до стабильного состояния в Scale-версии.

Как это будет выглядеть на практике, может быть, не до конца ясно, но основная идея состоит в том, чтобы добиться чётко оговорённого разделения (decoupling), которое покажет: одно дело — гнаться за скоростью, и совсем другое — обеспечивать стабильность.

Представьте, что вас просят запилить нечто амбициозное, и вы отвечаете: «Без проблем, Speed-версия будет готова через 3 дня, Scale-версия — недель через 6». Они получают желаемое — скорость и движение вперёд. Вы получаете желаемое — время на изучение и проектирование. Как вам? Что скажете, сеньор-разработчики? Или мне стоит называть вас сеньор-редакторами?

Что такое продуктовое мышление и почему оно важно

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

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

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

В основе продуктового мышления лежат определенные принципы:

1. Фокус на пользователе. Команда понимает целевую аудиторию конечного продукта и ее задачи, а также способы, которыми продукт помогает их решать.
2. Ориентация на ценность, а не на процесс. На каждом этапе работы нужно задаваться вопросом: «Какую ценность это добавляет пользователю или бизнесу?»
3. Работа с метриками и результатами. Вместо работы «по инструкции» важно отслеживать, как внесенные в продукт изменения влияют на ключевые показатели (например, конверсии, retention или доход).
4. Командная ответственность за успех. В продуктовой культуре успех — это достижение целей продукта, а не только выполнение плана и качество написанного кода.

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

Как же развить продуктовое мышление у разработчиков?

Помочь им лучше понимать аудиторию

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

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

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

Познакомить с основными продуктовыми метриками

В продуктовом подходе успех определяется с помощью метрик. Разработчикам важно понимать не только, что такое ROI или LTV, но и как их интерпретировать и применять для улучшения продукта.

ROI (Return on Investment)

Измеряет соотношение доходов и затрат на продукт. Представим ситуацию: разработчики игры предложили внедрить новую механику, но после анализа ROI выяснилось, что её разработка не окупится, так как привлечёт слишком мало новых пользователей. Вместо этого они переработали текущую механику, что не только избавило компанию от убытков, но и повысило доход на 15%.

LTV (Lifetime Value)

Помогает понять, сколько ценности приносит каждый пользователь за весь свой жизненный цикл. Пример: в e-commerce проекте заметили, что покупатели с подпиской приносят в два раза больше дохода. Разработчики сосредоточились на улучшении UX страницы подписки, и это увеличило конверсию на 30%.

Retantion Rate

Демонстрирует, насколько успешно продукт удерживает пользователей. Это особенно важно для SaaS и мобильных приложений. Пример: команда приложения для медитации проанализировала поведение пользователей и добавила уведомления, напоминающие о ежедневной практике. Это помогло увеличить retention на 10%.

Привлекать к обсуждению целей продукта

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

• Приглашайте разработчиков на еженедельные встречи с продакт-менеджерами. Это поможет точнее оценивать сроки реализации фич.
• Организуйте штурмы, на которых разработчики могут высказывать свои идеи. Они могут предложить решения, не входившие в изначальный план, но существенно улучшающие опыт пользователя.
• Демонстрируйте разработчикам связь между их работой и результатами. Например, рост выручки или улучшение NPS.

Научить соблюдать баланс между качеством и сроками

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

• Выпускайте минимально жизнеспособный продукт (MVP) с ограниченным набором функций. Это позволит собрать обратную связь и убедиться в востребованности продукта, не тратя время на полную реализацию.
• Подчеркивайте важность компромиссов. Разъясняйте разработчикам, какие фичи являются must have, а какие — nice to have.
• Разбивайте рефакторинг на несколько этапов. Так команда разработчиков сможет улучшать код и одновременно продолжать выпуск новых функций.

Научить работать с обратной связью

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

Источниками обратной связи для разработчиков могут быть:

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

Развивать культуру продуктового мышления в команде

Формирование продуктового мышления требует системного подхода. Вот несколько шагов, которые могут помочь:

1. Внедрите регулярные встречи, где обсуждаются метрики, отзывы и планы.
   
2. Создавайте кросс-функциональные команды для решения ключевых задач.
   
3. Проводите внутренние тренинги и мастер-классы. Например, по продуктовой аналитике.
   
4. Обратитесь к менторству — пусть опытные сотрудники обучают новичков основам продуктового подхода, помогая им быстрее адаптироваться и понять бизнес-приоритеты.

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

По данным Strategy Partners, российский рынок ПО в 2023 году вырос на 14% до 1,25 трлн рублей, и будет расти сопоставимыми темпами до 2030 года. Поэтому увеличивается спрос не только на разработчиков, но и на других специалистов, участвующих в процессе создания новых ИТ-продуктов. И в первую очередь на продакт-менеджеров.

Менеджер продукта объединяет в себе сразу несколько функций: взаимодействует с заказчиком и собирает обратную связь от пользователей, определяет развитие продукта и порядок внедрения новых фич, отвечает за экономические показатели. И это далеко не всё. Кстати, о том, как такие специалисты непосредственно разрабатывают продукт, можно почитать здесь.

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

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

Зарплата продакт-менеджера в среднем ниже, чем у тимлида или senior-разработчика — она составляет порядка 250 тысяч рублей. Но опытному специалисту могут платить и до 500 тысяч рублей в месяц. Правда нужно буквально быть «многоруким Шивой», обладая экспертизой сразу в нескольких областях — от тайм-менеджмента до маркетинга.

Hard-скилы: без чего точно не обойтись

Можно выделить пять основных направлений, в которых продакт-менеджер должен хорошо разбираться:

1. Аналитика. Важно уметь работать с аналитическими инструментами и строить дашборды, интерпретировать выводы в эффективные для бизнеса решения.
2. Проектное управление. Нужно иметь хотя бы базовые знания о разных форматах работы команд разработки, например, SCRUM или Agile, и участвовать в ключевых встречах по мере развития проекта.
3. Исследование рынка. Продакт-менеджер должен понимать как устроен маркетинг, знать основной инструментарий, в идеальном случае – уметь проводить исследование, в том числе конкурентов, искать точки роста для продукта.
4. Финансовый менеджмент. В первую очередь речь идет о знании ключевых метрик и умении выбирать ключевые показатели, например, в рамках концепции EBITDA.
5. Знание документооборота. Если этим не заниматься, разработка превратится в хаос, а продукт – в обузу для компании. Важно фиксировать ключевые изменения в проекте, описывать их, чтобы можно было, например, быстро ввести в проект новых ИТ-специалистов.

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

Потому что погрузить специалиста «со стороны» в ИТ-специфику можно сравнительно быстро, а вот научить человека с опытом в программировании анализу, маркетингу, документообороту и другим вещам — гораздо сложнее.

Зачем продакт-менеджеру софт-скилы

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

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

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

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

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

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

Инструментарий продакт-менеджера: примеряем жилетку Вассермана

Можно выделить несколько основных групп инструментов, которыми продакт-менеджеру стоит уметь пользоваться хотя бы на начальном уровне:

• Средства коммуникаций во всем их многообразии. Видеосвязь, мессенджеры, почта, приложения для проведения вебинаров, интерактивных презентаций, онлайн-доски и т. д.
• Инструменты работы с бэклогом. Чаще всего это Jira, но есть и российские аналоги, которые становятся все актуальнее. Сюда же можно отнести и разные приложения для работы с документооборотом в проекте.
• Разные средства визуализации. На сегодняшний день на первом месте в этой области остается Figma. Это приложение позволяет создавать простые прототипы даже с минимальными навыками работы с ним.
• Системы и сервисы, которые применяют на целевом рынке. Например, CRM, если речь идет о разработке приложений, которые связаны с маркетингом.

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

Работа менеджера продукта требует высокого уровня насмотренности в разных областях, поэтому в профессию часто приходят из смежных направлений ИТ — разработки, аналитики, маркетинга. Это кросс-функциональная специальность, которой не учат в вузе — для ее освоения без опыта работы в ИТ придется проходить курсы на образовательных платформах и в учреждениях дополнительного образования. При этом на hh.ru сейчас около 4 тыс. вакансий для менеджеров по продукту — востребованность этих специалистов, умеющих найти общий язык с бизнесом, разработчиками и клиентами, будет только расти.

Вместе с менторами Solvery и экспертами в продакт-менеджменте мы собрали подробный гайд, как создать и запустить продукт на рынке — от идеи до реализации и поддержки.

Узнать побольше про опыт Игоря, Антона и Валерии можно по ссылкам.

Шаг 1: Идея и планирование

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

Игорь Володин отмечает, что после разработки гипотезы ее нужно проверить. И здесь процесс тоже состоит из нескольких этапов:

1. Формулирование гипотезы. Определяем, что мы хотим проверить, описываем гипотезу и предполагаем, как она повлияет на продукт.
2. Создание прототипов. Разрабатываем прототипы или минимально жизнеспособные версии идеи для тестирования.
3. Проверка прототипов. Проводим тестирование, собираем обратную связь, проводим интервью с пользователями для уточнения и корректировки.
4. Анализ результатов. Сравниваем результаты тестирования с ожидаемыми эффектами, выявляем проблемы и дорабатываем идею.
5. Реализация и запуск. Если результаты тестирования положительные, продолжаем реализацию и мониторинг продукта.

Для сбора и анализа данных я использую разные инструменты: аналитические платформы, опросы, интервью и A/B тестирование. Все данные аккумулируются в единую систему, где мы их анализируем, выявляем паттерны и делаем выводы для дальнейших действий. Особенно важно учитывать как количественные, так и качественные данные для полноценного понимания потребностей рынка.

Интересно, что на старте проекта часто пропускают такой этап, как определение критериев успеха и готовности проекта. По простому — слабо синхронизируются по ожиданиям. Например, даже такая простая вещь как слово «запуск» продукта для одного человека говорит о запуске маркетинговой кампании, для другого — полученные N продаж и клиенты, которые начали продуктом пользоваться.

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

Этап 2: Дизайн и прототипирование

Один из самых важных этапов, поскольку именно от него зависит внешний вид и функционал конечного продукта. И ключевое здесь — грамотно организовать работу над MVP и проверить UX/UI прототип до разработки.

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

Работа над MVP начинается с четкого определения минимального набора функций, необходимых для проверки основных гипотез. И здесь важно сфокусироваться исключительно на них, чтобы избежать дополнительной нагрузки на команду. Для этого используют такие подходы, как Jobs to be Done или приоритизацию задач с помощью фреймворков вроде RICE, чтобы оценить как значимость идеи, так и её техническую реализуемость. Команда совместно оценивает объём работ и сроки, что позволяет сбалансировать нагрузку и избежать перегрузок.

Проверять UX/UI прототип нужно через разные виды тестирования на пользователях, близких к целевой аудитории. На ранних этапах это могут быть простые кликабельные макеты, которые тестируются через коридорные или юзабилити тесты. Пользователи выполняют ключевые действия на прототипе, а команда наблюдает за их поведением, выявляя проблемные области и потенциальные улучшения. В итоге важно получить честный и непредвзятый фидбек, чтобы внести необходимые изменения до начала разработки. Конечно, можно применять и более количественные методы, например, тепловые карты или A/B тесты, для проверки пользовательского взаимодействия на более широкой аудитории.

Этап 3: Разработка и тестирование

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

При расставлении приоритетов стоит учитывать несколько факторов:

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

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

Для автоматизации тестирования обычно используются инструменты, которые позволяют быстро и эффективно проверять основные сценарии работы продукта. Это могут быть как юнит-тесты, так и интеграционные тесты, покрывающие основные пользовательские флоу. Также применяется CI/CD, чтобы тестирование было встроено в процесс разработки и не задерживало выпуск продукта.

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

Этап 4: Обратная связь и улучшение продукта

Получение и анализ обратной связи от пользователей — ключевые элементы для успешного развития и улучшения продукта. Для этого используются различные каналы и инструменты — от форм Google Forms или NPS/CSAT до соцсетей. Аналитические инструменты помогают отслеживать поведение пользователей и выявлять проблемные места, что дополнительно усиливает понимание потребностей аудитории.

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

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

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

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

Этап 5: Запуск и поддержка

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

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

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

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

В первые 90 дней нужно активно проверять метрики — активации, вовлеченность и удержание пользователей. Если это новый продукт с нуля, ключевыми метриками будут связаны с началом воронки: онбординг пользователей, активация, оплата. А если продукт имеет более частотный характер, как, например, приложение для бронирования, то оценка возвращаемости пользователей может происходить быстрее — через 7, 14 или 30 дней. Важно понимать, какие метрики соответствуют бенчмаркам для конкретного типа продукта, чтобы адекватно оценивать результаты.

Вместо заключения: ретроспектива

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

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

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

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

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

1. Инструменты командной работы. Пять способов сплотить команду, выстроить доверительные отношения и добиться высоких результатов

Алекс Остервальдер, Стефано Мастроджакомо

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

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

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

2. Хорошая стратегия, плохая стратегия. В чем отличие и почему этоважно

Ричард Румельт

Книга учит отвечать на вопрос «для чего?» — полезный навык каждого продакта. В ней рассказывается о том, как выявить плохую стратегию, построить хорошую и понять, на чем она должна строиться, и какие метрики должна задействовать.

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

3. Наш айсберг тает

Джон Коттер, Холгер Ратгебер

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

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

4. Финансы для нефинансистов

Людмила Ярухина

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

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

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

Александр Остервальдер

Книга, как понятно из названия, о том, как строятся непобедимые компании. Она продолжает серию книг про создание крепких бизнес-моделей, но именно со стороны сборки компании и процессов.

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

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

Общаться нужно много

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

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

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

Конфликты будут возникать регулярно

Например, когда не хватает ресурсов, или когда у стейкхолдеров разные интересы.

Допустим, маркетингу нужно, чтобы продукт или фича вышли под определённое событие. Разработка понимает, что уложиться в намеченные сроки не получится. И продакту нужно решить, что приоритетнее: запустить продукт к событию, потому что он привлечёт новых пользователей более дешёвым способом (ведь стоимость привлечения клиентов тоже важна), или отложить выпуск, но показать продукт без багов.

Мой совет: потратить дополнительное время и подробнее изучить кейс. Да, есть правило — занимать рынок быстрее и потом разбираться. Но так велика вероятность выпустить что-то некачественное.

Если все команды обиделись друг на друга, продакт, как лидер, будет их мирить.

Принимать решения придётся вообще постоянно

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

Например, мне нужно было увеличить показатель с 18% на 25+% конверсии из пользователей, которые скачали приложение, в зарегистрированных пользователей в течение 14 дней. Менять что-то серьёзное в рабочей версии продукта было бы сложно. Я выдвинул гипотезу, что можно скрыть некритичную форму для заполнения при регистрации — и показатель вырастет. Так и вышло. Времени и ресурсов на это ушло минимальное количество.

Главное — понимать, как расставить приоритеты. В этом помогают фреймворки. Например, я использую методологию MoSCoW (Must have, Should have, Could have, Won’t have), чтобы определить, что точно должно быть в продукте, что — желательно, и чего не должно быть в принципе.

Как и подстраиваться под новые вводные

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

Поэтому постоянно нужно подстраивать продукт и работу команды под меняющиеся реалии.

Полностью отдаться процессу не получится

Умение анализировать большие объёмы данных как внутренних, так и внешних, — важный навык для продакт-менеджера. Но по-настоящему полезным он будет только если специалист понимает, какой результат принесёт этот анализ.

Бывает, что продакт застревает в исследовании: бесконечно ищет информацию, уверенный, что так он точно убережёт себя и продукт от рисков. И это только вредит результату: сроки «едут», а половина информации вообще оказывается бесполезной.

В среднем, на анализ показателей и исследования желательно тратить один рабочий день в неделю.

Нужно быть готовым к выгоранию

Менеджер тратит много времени и сил на проект, постоянно принимает решения, несёт за всё ответственность. Но продукт может не взлететь, показать не те результаты. Тогда руки опускаются, возникает неуверенность в своих силах.

Я был готов к этому, потому что заранее прошёл два курса, прокачивал софт-скилы, навыки продаж. Но на первых порах всё равно ловил себя на мысли, что раздражают встречи и постоянные объяснения ТЗ, которое я достаточно понятно составлял. Тогда банально учился отдыхать и менять обстановку.

Важно работать над work-life balance, наполнять свободное время любимыми хобби. Иначе на длинной дистанции выгорание обязательно случится. Я знаю продактов, которые уходили из профессии, потому что от постоянного стресса потеряли здоровье и мотивацию.

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

Бюрократия

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

Пока ты разрабатываешь продукт, бюрократии мало. Но когда презентуешь проект и выпускаешь в коммерческое плавание, обязательно сталкиваешься с согласованием процессов, договоров. Этот путь нужно пройти достойно! Главное — заложить больше времени, чем предполагаешь.

Не всегда на рынке есть «идеальные» вакансии

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

Продакт-менеджеров ищут не только в IT, но и в других сферах. Если вы хотите работать именно с технологиями, подходящую вакансию ещё придётся поискать.

Итак, что важно знать, прежде чем становиться продактом?

• Нужно много говорить: со своей командой, с другими командами, с заказчиками. Иначе у продукта будут проблемы.
• С бюрократией придётся сталкиваться постоянно: договоры, запросы, заявления и прочее.
• Не факт, что вам сразу удастся взять в работу продукт, который перевернёт рынок.
• Выгорание — это не миф. И нужно будет прокачивать софты и трепетно относиться work-life balance.

Как устроена работа в продуктовой команде в Дзене

Мы работаем по принципу SCRUM.

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

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

Как возникают идеи новых продуктовых фич

Идеи фич обычно появляются из нескольких источников:

• из общения с аудиторией продукта с помощью исследований;
• из аналитики продуктовых метрик;
• из анализа рынка и конкурентного анализа;
• из обращений в поддержку.

А ещё запросы и идеи могут поступать от коллег: например, команда разработки предложила ввести возможность делать подборки в каналах авторов.

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

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

Как новые фичи проходят верификацию для MVP

Доводим фичу до разработки

Для этого нужно пройти несколько этапов.

1. Продуктовый анализ, который заканчивается процессом продуктового ревью.

Его результатом становится артефакт в виде User Story, где, в частности, есть ответы на следующие важные вопросы:

• есть ли вообще проблема?
• что это за проблема?
• чья это проблема, продакта или пользователей, какого объёма аудитории?
• почему её нужно решать?
• на какие метрики это повлияет?
• как сильно это повлияет на метрики?
• спустя какое время мы ждём положительный эффект?

2. UX, side-by-side исследования и т. д. Порой после них вносятся существенные корректировки в предлагаемые интерфейсы. В исследования отдаются как уже готовые макеты дизайна, так и мокапы и варфреймы (wireframe).

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

После этого фичи отправляются на тестирование, это отдельный большой процесс.

Проводим тестирование

Единого паттерна тестирования новых фич нет. Он отличается в зависимости от изменений, которые мы хотим внедрить.

Если изменения небольшие, то можно провести A/B-тестирование, посмотреть на метрики и сразу реализовать фичу в продакшене.

С помощью А/В мы также можем довольно быстро на большом объёме пользователей понять, что идёт не так не только в продукте, но и в технической реализации, например, найти баги. Некоторые ошибки сложно заметить на тестировании до релиза. Но мы можем протестировать фичу на A/B и уже на следующий день понять, что у нас не так, отключить её и вернуть в доработку.

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

Иногда мы проводим тестирование прототипов на пользователях. Можем даже спросить у коллег в офисе, нравится ли им нововведение.

Если метрики после А/В-тестирования растут, то мы раскатываем фичу в продукт.

Проверяем метрики в экспериментах

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

Бывает, что эксперименты стали красными. Значит, какие-то метрики просели. В этом случае мы смотрим на ключевые, которые напрямую влияют на бизнес, они должны быть в порядке. Если всё красное, то, естественно, фичу не выпускаем. Если там серые показатели, просажены какие-то незначительные метрики, то решаем по логике предыдущего примера.

Например, в процессе создания роликов на старте мы тестировали три гипотезы:

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

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

Мы остановились на последнем подходе, потому что эта гипотеза показала самые высокие результаты на тестировании. Сейчас пользователю предлагается самому решить, хочет он видеть ролики в первую очередь или нет.

А вот как дизайнеры учили смотреть ролики Дзена

Какие фичи мы внедряли и как

Мы ускоряли загрузку сайта на dzen.ru. Это важная метрика, потому что там загружаются и поиск «Яндекса», и Дзен. Чтобы ускорить сервис, мы делали загрузку страницы двумя чанками — кусками страницы. Сначала мы отдаём пользователю чанк с поиском, потом отдаём второй чанк со страницей. Это позволяет отдавать строку поиска буквально за миллисекунды.

А вот в части Дзена сложная машинерия: нужно учитывать рекомендации для юзера. Это занимает сотни миллисекунд, поэтому мы отдаём его чуть позже. И так как пользователь уже начал получать контент и взаимодействовать со страницей, ожидание для него становится менее тягостным.

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

Скорость загрузки мы увеличиваем не просто так. Мы хотим, чтобы пользователям быстрее отдавался интерфейс, UI–элементы, чтобы он быстрее мог с ним начать взаимодействовать, что-то поискать. Тем самым мы решаем количество вхождений в поиск и уменьшаем количество отказов пользования сервисом.

Такие фичи пользователь не осознаёт. По ним нельзя провести кастдев и спросить, понравилось это людям или нет. По таким фичам мы отслеживаем микс продуктовых и технических метрик. Часть из этих фич не нужно тестировать в А/В, потому что не надо доказывать, что высокая скорость загрузки это хорошо. Это оценка по здравому смыслу.

Бывает, что техническое решение не даёт ощутимого прироста в моменте, но может влиять на продукт спустя время.Люди привыкли, что все приложения работают нативно, ничего не лагает. Если мы сделаем более плавный скролл, то это, скорее всего, не повлияет на метрику прямо сейчас. Но зато у пользователей накопится знание, что Дзен — качественный быстрый продукт.

Как мы работали с негативным фидбэком

Бывало, что MVP продукта успешно прошёл этап проработки, а на выходе в прод на большую аудиторию собрал неоднозначные отзывы. Например, Студия автора. Это личный кабинет, где автор создаёт новые публикации, смотрит за статистикой, управляет постами, комментариями и монетизацией.

У этого продукта есть главная страница. Мы провели UX–исследование, по которому выяснили, что она перегружена, это мешает автору сориентироваться. Тогда мы решили её облегчить: убрали оттуда все блоки, которые были доступны также на вкладках внутри продукта, и оставили только то, чего там не было.

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

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

Как на этапе MVP продукта мы понимали, что именно нужно дорабатывать

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

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

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

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

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

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

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

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

На самом деле не бывает неуспешных MVP. Если что-то не сработало, это калибрует нас и позволяет двигаться дальше к другим идеям.

Можно ли избежать страха и ненависти как клиента, так и конечных пользователей? Равно как и потери значительной части времени специалистов от общего количества часов разработки? Мы в агентстве CHILLICODE считаем, что да. И в этом нам может помочь применение методологии CI/CD.

Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.

В свое время Генри Форд перевел создание автомобилей от ручной сборки к поточному конвейерному производству, перевернув тем самым промышленность своего времени. Принцип действия CI/CD (Continuous Integration & Continuous Deployment) в чем-то похож на конвейер: методика выполняет интеграционную функцию, включая различные типы автоматических тестов на каждом этапе, с последующей доставкой и развёртыванием кода в готовый продукт для конечного пользователя.

Мы у себя с недавнего времени внедрили CI/CD в большинство  наших проектов, что позволило выстроить процесс релиза обновлений буквально в один клик, снизить риски появления багов, внедрив автотестирование и анализ качества кода перед каждым релизом, а также исключить особенности различий окружения хоста разработчика и сервера путем упаковки приложения в так называемые «контейнеры».

Многим клиентам, чей формат проекта подразумевает регулярные обновления, мы предлагаем работать с нами вместе с настроенной системой CI/CD. Потратив немного времени на старте на настройку окружения для непрерывной интеграции, мы сократим риски и сможем предложить клиенту высвободившиеся часы на более сложные задачи.

Какие этапы релиза можно автоматизировать?

Тестирование и контроль качества

Конечно же, об этом речь должна пойти в первую очередь. Тестировщиков нельзя полностью заменить, но львиную долю повторяющихся проверок можно автоматизировать путем модульного и регрессионного тестирования. Мы предлагаем автоматизацию в квадрате. CI/CD имитирует среду выполнения конечного сервера и запускает тесты автоматически, чтобы подтвердить работоспособность программного обеспечения и полностью исключить возможность выпустить в релиз продукт при возникновении ошибки. И клиент всегда будет уверен, что обновление не повредит работоспособности проекта.

Сборка и упаковка кода

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

Открытая отчетность

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

Как обезопасить релиз?

В каких местах могут возникнуть проблемы?

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

Как предохраниться от логических ошибок функциональности и багов?

Чтобы полностью исключить ошибки при деплое стоит комбинированно подойти к каждой итерации разработки продукта. Мы в CHILLICODE проводим релизы проектов в 5 этапов:

1. После разработки новой фичи разработчик создает запрос на слияние ветки с новой функциональностью в основную ветвь приложения.
2. Тимлид проекта перед слиянием проверяет качество его кода и при возникновении проблем отправляет код на доработку.
3. После принятия запроса на слияние приложение проходит несколько этапов автоматического тестирования, анализа качества кода и разворачивается на нашем стейдж сервере.
4. Выделенный QA специалист дополнительно проверяет всю функциональность приложения на стейдж серверах перед показом клиенту.
5. И уже после одобрения клиентом всех правок мы отправляем приложение в релиз.

Что делать если критическая ошибка все равно осталась незамеченной и попала в прод?

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

Итого

При работе с CI/CD мы имеем:

• Сокращение действий для деплоя до одного клика.
• Снижение рисков появления потенциальных ошибок.
• Автоматизация модульных и регрессионных тестов.
• Щепетильный контроль качества кода.
• Контейнеризация приложений и исключение различий среды разработки со средой выполнения.
• Возможность моментального отката версии приложения при возникновении критических ситуаций.
• Общее сокращение времени разработки на 10-20%.

Внедряйте CI/CD в свои проекты, как это делаем мы в агентстве и пользуйтесь на здоровье. Если вы все еще сомневаетесь или остались какие-то вопросы, пишите комментарии и мы постараемся ответить.

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

Есть много программных инструментов, которые управляют этим потоком. Некоторые из них бесплатны, а за использование других придётся заплатить. Ниже кратко опишем 3 самых популярных.

Jenkins

Это автономный сервер автоматизации с открытым исходным кодом. Его можно использовать для автоматизации всех видов задач, связанных со сборкой, тестированием, поставкой или развёртыванием программного обеспечения.

Требуемое дополнительное ПО: Java Runtime Environment (JRE) версии 8.

Требования к «железу»:

• минимальные — 256 Мбайт оперативной памяти, 1 Гбайт места на жёстком диске;
• рекомендуемые — 1 Гбайт оперативной памяти, 50 Гбайт места на жёстком диске.

Архитектура основана на модели распределенных вычислений (Master/Slave).

Jenkins Server — это базовая установка, отвечающая за хостинг GUI, организацию и выполнение сборки.

Jenkins Node/Slave/Build Server — устройства, которые могут быть настроены для выполнения функций по сборке от имени главного узла.

Пошаговая установка для Linux

Добавьте репозиторий Jenkins в систему.

Обновите репозиторий пакетов

Установите Jenkins

Теперь Jenkins должен быть доступен в вашей системе по умолчанию через порт 8080.

Перейдите в браузере по адресу http://localhost:8080. Вам будет предложено ввести начальный пароль пользователя с правами администратора. Найти его можно в файле /var/lib/jenkins/secrets/initialAdminPassword.

Теперь настройка выполнена и можно начать создавать свои потоки CI/CD. Вот несколько примеров того, как выглядит графический интерфейс.

Преимущества:

• масштабируемость благодаря архитектуре Master/Slave;
• включает в себя REST XML/JSON API;
• подключение большого количества расширений, благодаря плагинам, которые добавляют множество функций;
• большое и активное онлайн-сообщество, которое является хорошим ресурсом поддержки и примеров реализации.

Недостатки:

• нет аналитики;
• устаревший интерфейс по сравнению с другими инструментами.

TeamCity

Это коммерческий сервер для CI/CD от компании JetBrains. Он известен своей простой настройкой и красивым пользовательским интерфейсом. TeamCity имеет мощный набор функций прямо «из коробки» и растущую экосистему плагинов.

Требуемое дополнительное ПО: Java Runtime Environment (JRE) версии 8.

Имея относительно скромный сервер (3,2 Гбайта ОЗУ, двухъядерный процессор 3,2 ГГц, один жёсткий диск и сетевой адаптер с пропускной способностью 1 Гбайт), вы можете получить следующее:

• 60 проектов и 300 конфигураций сборки;
• более 300 сборок в день;
• около 2 Мбайта log-журнала на сборку;
• 50 агентов сборки (компоновки);
• 50 пользователей web-версии и 30 пользователей IDE;
• 100 возможных подключений внешней СКВ (в основном Perforce и Subversion с использованием проверки сервера), средний интервал проверки изменений составляет 120 секунд;
• более 150 изменений в день;
• база данных (MySQL) работает на той же машине;
• серверный процесс TeamCity имеет следующие настройки JVM: -Xmx1100m -XX:MaxPermSize=120m.

Требования к агенту в основном определяются запущенными сборками. Задача сервера TeamCity состоит в том, чтобы отслеживать все подключённые агенты, а также распределять сборки из очереди по этим агентам на основе требований совместимости и сообщать о результатах. Агенты могут иметь разные платформы, операционные системы и предварительно сконфигурированные среды.

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

Пошаговая установка для Linux

Используйте архив TeamCity<номер версии>.tar.gz, чтобы вручную установить TeamCity в комплекте с контейнером сервлета Tomcat. Архив можно скачать отсюда.

При первом запуске TeamCity можно выбрать тип базы данных SQL, в которой будут храниться данные о сборке.

По умолчанию TeamCity работает на http://localhost:8111/ и имеет одного зарегистрированного агента сборки, который работает на той же машине.

Преимущества:

• простота использования/настройки;
• удобный интерфейс;
• встроенные функции;
• служба поддержки;
• предлагает RESTful API;
• хорошо задокументирован;
• хорошая защищённость «из коробки»;
• быстрая и простая установка/настройка.

Недостатки:

• ограниченная интеграция;
• является коммерческим инструментом;
• маленькое сообщество, но оно растёт.

GoCD

Это ещё один инструмент CI/CD с открытым исходным кодом.

Требуемое ПО: Java Runtime Environment (JRE) версии 8.

Требования к «железу».

• Сервер:ОЗУ: минимум 1 Гбайт, рекомендуется 2 Гбайта;Процессор: минимум 2 ядра, 2 ГГц;Жёсткий диск: минимум 1 ГБ свободного места.
• Агент:ОЗУ: минимум 128 Мбайт, рекомендуется 256 Мбайт;Процессор: минимум 2 ГГц.

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

Схема конвейера (Stages/Jobs/Tasks):

Пошаговая установка для Linux

По умолчанию GoCD работает на http://localhost:8153/.

Преимущества:

• открытый исходный код;
• простая установка;
• подробная документация;
• дружественный графический интерфейс;
• Пошаговое отображение пути развёртывания в одном представлении;
• хороший обзор структуры конвейера;
• GoCD оптимизирует рабочий процесс CD в популярных облачных средах, таких как Kubernetes, Docker, AWS;
• GoCD помогает устранять неисправности в конвейере, отслеживая каждое изменение от коммита до развертывания в режиме реального времени.

Недостатки:

• вам нужно установить хотя бы одного агента;
• нет главной консоли для отображения всех выполненных заданий;
• в конфигурации конвейера вы должны создать по одной задаче для каждой команды, которую вы хотите выполнить;
• чтобы установить плагин, нужно поместить файл .jar в <go-server-location>/plugins/external и перезапустить сервер;
• небольшое сообщество.

Подведём итоги

Это всего лишь 3 примера, но есть и много других инструментов, связанных с CD. Выбор правильного для вас может быть непростым, поэтому обратить внимание стоит на важные аспекты, от которых и будет зависеть выбор.

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

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

Уделите больше внимание к особым требованиям вашего развёртывания. Их специфика может помочь сузить список подходящих инструментов и сэкономить время.

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

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

Как обычно происходит?

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

За эффективностью сайта часто никто не следит. Хорошо, если с проектом работает интернет-маркетолог и хотя бы иногда смотрит Google Analytics или Яндекс.Метрику. У некоторых даже есть отчеты по маркетингу, где видно количество посетителей. Нужно больше продаж? Давайте увеличим бюджет на контекстную рекламу или расширим семантическое ядро для SEO. Таким банальным вещам, как цели сайта и отслеживание конверсии, уделяют внимание немногие. О расчете стоимости посетителя и анализе эффективности по каналам я вообще молчу. А происходит это потому, что хороших маркетологов у нас в стране крайне мало, так как все “пишут код” на аутсорсе и не умеют работать с продуктами, да и сами предприниматели не сильно понимают, что делать со своими сайтами.

За интерфейсом сайта тоже никто не следит. Было бы очень интересно посмотреть на статистику по использованию карты кликов самими владельцами сайтов. Думаю, большая половина её никогда не использовала вообще, а ведь это базовый инструмент, который позволяет отслеживать эффективность интерфейса. Чаще всего интерфейс сделали и забыли, по крайней мере до полного редизайна сайта. Мало кто вспоминает про большие проекты, которые постоянно проводят A/B-тестирование, чтобы анализировать эффективность интерфейса и повышать её. Именно от интерфейса зависит конверсия, а значит, и эффективность всех маркетинговых усилий. Добиться роста продаж можно несколькими путями: например, увеличением маркетингового бюджета, что позволит привести больше трафика на сайт, или улучшением интерфейса, что при равном количестве пользователей сайта даст больше продаж. Второй вариант более правильный и должен идти в списке дел раньше. То есть сначала мы должны добиться максимальной конверсии, а потом уже вкладывать деньги в рекламу, чтобы каждый доллар тратился с максимальной отдачей. Или, в крайнем случае, делать это параллельно.

По технологиям тоже все сложно. Постепенно технология, на которой сделан сайт,  начинает устаревать. Выходят новые версии языка, фреймворка или CMS. Обновляться до новой версии никто не хочет, не видя особой разницы для бизнеса. Зачем? Ведь сайт работает! Постепенно в проекте накапливается много старого кода, так как на его рефакторинг при доработке также не хватает денег и времени. Unit-тесты сразу никто не писал, накапливаются и ошибки. Стоимость поддержки начинает непрерывно расти. Технология стареет иногда так, что даже официальную документацию уже сложно найти, а обилие устаревшего кода сильно тормозит программиста. Да и программисты часто успевают поменяться на проекте, а старые после себя крайне редко оставляют документацию. Но этого никто не замечает, ведь задачи в итоге решаются, проект приносит деньги, стоимость поддержки никто не оценивает…

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

Знакомая ситуация? Узнаете себя или своих знакомых?

Первичные документы и информация

Для начала нужно убедиться, что у нас есть все необходимые документы и доступы для дальнейшей работы.

Приводим в актуальное состояние или создаем с нуля:

1. Доступы к сайту. Прежде всего по FTP и SSH, это нужно для дальнейшей его разработки. Во вторую очередь — к системе управления сайтом.
2. Документация. Каждый разработчик должен вести документацию: что пишет, где хранится, как работает и т.д. Чем больше проект, тем больше документации по нему должно быть. Обычно этим пунктом пренебрегают, и новому разработчику очень сложно разобраться в старом коде. По моим ощущениям, документация есть у менее, чем 10% проектов. И если её у вас сейчас нет, то самое время её сделать, а потом еще отдать сторонней компании на проверку.
3. Сторонние сервисы. Доступ к Google Analytics и Google Search Console, Яндекс.Метрики и Яндекс.Вебмастер, в некоторых ресурсах есть и ряд специфических интеграций, доступы по ним тоже должны быть.
4. Маркетинговая статистика. Если ранее проводили рекламные кампании, по ним должна быть статистика. SEO? По каким словам, как менялись позиции, были ли фильтры и т.д.  PPC? По каким словам, каким ставкам, какие объявления и т.д. SMM? Доступ к фан-страницам, статистика упоминания бренда, статистика по трафику и т.д. Чем больше старой статистики, тем более эффективной можно сделать дальнейшую маркетинговую активность.
5. Аудиты. Если ранее проводились какие-либо аудиты — то же самое: должны быть отчеты и результаты.
6. Описание проекта. Хорошо, когда у нас что-то понятное и стандартное, типа интернет-магазина. Но часто бывают огромные системы, полное понимание которых должно содержаться в специальном структурированном документе. Например, взять хотя бы какую-либо систему расчета рейтинга. У любого нового разработчика будет куча вопросов: “По какой формуле высчитывается?”, “С чем связана?”, “Для чего нужна?” и т.д. А это ведь обычная функция, которая в интерфейсе может выражаться всего одним числом, но быть связанной со всем на сайте.

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

Стратегия развития

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

Для начала нам стоит прислушаться к самим пользователям. Это можно сделать, изучая их поведение на сайте с помощью Google Analytics, Яндекс.Метрики или других инструментов. Можно напрямую запрашивать обратную связь через формы обратной связи или интервью. Можно использовать метод “разумного заимствования” у конкурентов. И еще сотни разных способов. Опять же, многое зависит от проекта. Если он более-менее стандартный и на рынке много аналогов, то должны быть известны Best practices, их нужно просто применить. Если уникален — то тут сложнее, придется экспериментировать.

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

Алгоритм системной работы над проектом следующий:

1. Провести всесторонний аудит проекта.
2. Запросить обратную связь пользователей.
3. Проанализировать прямых и косвенных конкурентов.
4. Выявить самые ожидаемые и прибыльные для проекта функции.
5. Расставить приоритеты по внедрению.
6. Проработать каждый пункт и внедрить.
7. Отслеживать эффективность внедрений.

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

Большие компании планируют на несколько лет вперед. Когда речь идет об интернет-проекте, даже маленьком, нужно планировать хотя бы на год, а лучше на 3-5 лет. А дальше, постоянно слушая клиентов, эту стратегию можно корректировать. Конечно, в Интернете все постоянно меняется, но кто не имеет цели, тот к ней точно не дойдет.

Product Development

То, что мало кто умеет делать, но от чего зависит вообще весь бизнес. Это развитие продукта вокруг клиента и его проблем. Методология направлена на то, чтобы тщательно и постоянно анализировать потребности клиентов и улучшать продукт. То есть работа над теми вещами, которые приносят деньги проекту. И эта методология применима ко всем проектам. Главное — ответить на вопрос: “Что еще нужно клиенту?”.

Представим, что у нас проект, который предоставляет какую-то услугу или продает какой-то товар. Как нам увеличить продажи? Всегда есть тысяча способов: можно с товаром давать в подарок что-то бесплатно, можно улучшить предоставление услуги (скорость, качество, сервис), можно вообще придумать новый продукт в рамках существующего проекта. Или другой пример, более близкий к нашим реалиям: до сих пор у многих интернет-магазинов нет возможности купить что-либо в кредит. А ведь в оффлайне более 50% товаров продается в кредит! То есть многие интернет-магазины теряют очень большую долю клиентов, хотя, возможно, они вполне успешны и могут продавать действительно много товаров и даже не подозревать, что теряют десятки процентов недополученной прибыли. И таких примеров очень много, они есть в каждом интернет-проекте.

Действительно ли вы делаете всё для развития ваших клиентов? А может, они могут покупать больше и чаще? Эти вопросы мало кто себе задает, и тут часто кроется огромная недополученная прибыль.

Интерфейс и дизайн

Тут самое главное — понимать, что красивая картинка еще не означает удобный интерфейс. У каждого сайта и каждой страницы есть цель(и). И эффективность интерфейса может измеряться только тем, достигает он поставленных целей или нет. Это необязательно продажа чего-либо, это могут быть регистрации, количество просмотренных страниц, написание комментариев и т.д. Все эти цели измеряемы, и над улучшением каждой из них нужно работать. Проблема старых проектов в том, что такие цели чаще всего даже не ставятся. Многие мыслят очень широкими категориями: “У нас есть продукт, нужно его продать”.

Для начала нужно определить основные KPI сайта и самых важных его разделов. Это лучше делать с UX/UI проектировщиком, который хорошо разбирается в проектировании и тематике проекта. Затем нужно проанализировать Google Analytics и Яндекс.Метрику, изучить поведение пользователей. Затем собрать обратную связь от пользователей и подумать над Product Development. И уже после этого начинать улучшать интерфейс, имея на руках все нужные материалы.

Изменения можно внедрять двумя способами:

1. Вслепую, когда мы основываемся на опыте проектировщика.
2. Через A/B-тестирование, когда эффективность каждого эксперимента замеряется.

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

Старый интерфейс можно постоянно перерабатывать и улучшать. Но всегда есть новые идеи, развитие того, что есть. Это должен быть непрерывный процесс, непрерывное улучшение. Как правило, первоначальное видение проекта, когда разрабатывается его MVP, с  течением времени довольно быстро меняется. Это происходит несколько раз: сначала — когда он только начинает разрабатываться, а потом — когда проект уже работает, и начинают идти первые отзывы от пользователей. Иногда проекты меняются не только внешне, но и меняют свою основную идею. Это еще одна причина, почему нужно слушать пользователей и на основе их обратной связи внедрять улучшения.

В октябре во всем мире количество мобильных пользователей в мире превысило количество десктопных. Но при этом у многих проектов есть проблемы с адаптивностью под разные устройства. Мало того, что многие старые сайты не адаптивнs изначально, так даже у адаптивных обычно много проблем и недоработок. Ведь типов устройств сейчас очень много, и учесть все не просто. Адаптивность можно всегда доделать или улучшить уже существующую, но, к сожалению, об этом задумываются далеко не все.

Кроме проектирования интерфейса, еще можно и нужно работать с версткой и графикой. Её можно оптимизировать, чтобы сайт загружался быстрее. Это даст больше удовлетворения пользователям, да и поисковые системы будут выше показывать сайт в результатах поиска. Проверить скорость загрузки сайта можно тут. Проверить корректность отображения в разных браузерах тут. Проверка SEO параметров сайта тут. Проверить на ошибки верстки тут. Google, кстати, не так давно начал учитывать и ошибки валидности, и чем больше их, тем ниже сайт.

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

Технологии

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

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

Соблюдать чистоту нужно не только в коде, но в самом наборе технологий. Чем больше проект, тем больше технологий там может использоваться, но тут важно выбирать технологии взвешенно и не по тому, что знает программист, а по тому, что действительно эффективно для решения той или иной задачи. Часть проекта с ростом количества посетителей может понадобиться переписать, не все можно масштабировать, особенно если была заложена неправильная архитектура и не предусмотрена возможность масштабирования, что встречается довольно часто. Иногда нужно переписывать весь сайт, если он сразу писался, скажем, на CMS, а его посещаемость выросла и сайт начал тормозить или вообще падать. В любом случае нужно проводить хороший технический анализ, прежде чем принимать решения по технологиям. Более детально про технологии мы писали в статье: “Выбор технологий для большого и не очень проекта” — но эта статья больше про новые проекты, а не про старые.

В современном мире существует много разных сторонних сервисов, которые подключать часто довольно выгодно. Например, сервисы товарных рекомендаций для интернет-магазинов, платежные агрегаторы, сервисы логина через социальные сети, отправка смс, различные CRM и т.д. То есть у владельца сайта часто есть выбор: писать свою уникальную систему или воспользоваться сторонним сервисом. Оба варианта вполне имеют место быть. Тут важно понимать, что использование стороннего сервиса — это дешево, но все данные находятся у этого сервиса,  и мы ограничены его функциональностью. Поэтому  подобными сервисами, в основном, пользуются  более мелкие сайты, а крупные разрабатывают свои уникальные системы. Как правило, проекты запускаются с минимальным количеством сервисов, а в процессе жизни сайта их становится все больше. Многие почему-то считают, что подключить такие сервисы проблематично. На самом деле чаще всего это довольно простая задача. Такие сервисы имеют свою API и хорошую документацию, что делает их подключение задачей несложной.

Сервера и инфраструктура

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

С большими сайтами (на фреймворках или чистом языке) все значительно проще. Заранее можно сделать нагрузочное тестирование и выяснить, сколько посетителей выдержат текущие сервера. Обычно замеряются два показателя: стандартная и пиковая нагрузки. Затем нужно сделать расчет нагрузок, который позволит понять, когда, как и сколько добавлять серверов, чтобы решение работало без проблем. Часто начинают с одного сервера, затем появляется отдельный сервер для БД, затем их становится несколько и т.д.

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

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

Контент

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

Должна быть контент-стратегия, как часть общей стратегии развития ресурса, в которой будет обозначено, какой контент, как, куда и когда нужно публиковать.

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

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

Маркетинг и продвижение

С первого взгляда кажется, что тут все очень просто: нужно больше продаж, просто закупаем больше трафика, и дело в шляпе! На самом деле, как и с самим сайтом, здесь есть над чем работать и что улучшать. Есть замечательная цитата Джона Ванамейкера: “Я знаю, что половина моего рекламного бюджета расходуется впустую. Беда в том, что я не знаю, какая именно половина”. Это довольно старая мысль — в современном мире есть много инструментов измерения эффективности. Более того, мы говорим об интернет-проектах, где все можно измерять и улучшать, этим и нужно пользоваться.

Для начала нужно подготовить сам сайт. Первым делом проверить, насколько он оптимизирован под поисковые системы. Информации по SEO очень много, например, 20 правил SEO-оптимизации eCommerce проектов. Затем проверить контент сайта: он должен быть не только оптимизирован под поисковые системы, но и мотивировать пользователей совершать какие-то действия. Отдельно стоит проверить интерфейс:  он тоже должен побуждать пользователей к каким-то полезным для проекта действиям. Для контекстной рекламы нужно создать специальные посадочные страницы, чтобы увеличить конверсию и т.д. Действий по подготовке сайта довольно много, и почти все они влияют на конверсию, средний чек и т.д. Другими словами, это нужно сделать, чтобы получить максимальный эффект от посетителей, попавших на сайт.

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

Анализ эффективности и корректировка стратегии

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

Так что же делать с работающим сайтом?

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

С чего именно начать, зависит от конкретного проекта. Многие сайты настолько устаревают, что их приходится полностью переделывать. Большие сайты постоянно обновляются, маленькие существенно преображаются раз в 3-5 лет, главное — не стоять на месте. И этот процесс должен быть системным, всеобъемлющим. Нельзя поработать над сайтом, но забыть про маркетинг, или наоборот. Нельзя улучшать только одну из сфер, потому что другие будут отставать, и эффекта синергии не будет. Если вы еще не начали активно повышать эффективность вашего проекта или этот процесс по какой-то причине очень медленный, то самое время этим заняться, ведь скоро Новый Год, и он должен стать новым этапом развития проекта.