Разработка продуктов — процесс трудоемкий. Рынок постоянно нуждается в новых решениях, но на пути создания инноваций любую компанию подстерегают провалы. В данной статье мы собрали воедино свой собственный опыт работы в высокотехнологичном сервисе, чтобы попытаться разобраться, какие проблемы могут возникнуть при разработке нового продукта и как их избежать.
Нередко компании при разработке продукта все внимание и ресурсы направляют на процесс создания и производства. Даже если каждый этап работ выполнен «строго по технологии», результат может оказаться не таким радужным, как представлялось в начале.
Пример из практики
Три месяца назад в команде Rookee был внедрен сложный процесс системной аналитики. Аналитик должен был запрашивать и собирать маркетинговые исследования, готовить варианты решения, запрашивать финансовые расчеты, проектировать алгоритмы, ставить задачи для UX, определять бизнес-требования, проводить защиту своих решений, отслеживать результат после выкладки, передавать в эксплуатацию и т.д. Нагрузка на одного аналитика могла достигать 15 задач в день. Специалист физически не может пропустить через себя в сутки такое количество разноплановых задач. Неудивительно, что с таким объемом работа аналитика являлась узким горлышком в решении общих задач. Для повышения эффективности многие вещи происходили в обход. В итоге в компании отказались от такого сложного процесса и радикально его упростили, распределив обязанности между разными специалистами. Эффективность повысилась, а процесс аналитики стал происходить быстрее.
Как избежать
Если процесс разработки продукта слишком сложен, а результат не отвечает ожиданиям, необходимо пересмотреть текущие процессы и стать более гибким к изменениям на каждом этапе работ.
Умение работать в команде — важный навык, которым обладают далеко не все. На практике часто возникают ситуации, когда для реализации одной задачи требуется привлечение сразу нескольких специалистов.
Например, задача о внедрении промокода в систему подразумевает под собой работу и фронтенд-разработчика, и бэкенд. Если эти люди не могут договориться между собой, возможно возникновение самых разных проблем. Например, с точки зрения визуала задача будет сделана, но без алгоритма отработки механики промокода эта задача не даст никакой ценности.
Пример из практики
Когда в нашем сервисе появилось несколько разных продуктов, команды разработки у каждого продукта остались свои. Пользователь один, аккаунт один, а продукты и команды разные. Как-то нам позвонил клиент и сказал, что мы его заспамили. Оказалось, что все команды слали ему письма, когда возникали ситуации, требующие внимания (например, баланс подходил к нулю и работа сервиса могла быть приостановлена). В итоге пользователь получал в неделю порядка 40 писем от сервиса. Был проведен анализ email-рассылок. Некоторые письма объединили. Сейчас в проработке находится email-стратегия, которая окончательно исправит все недостатки.
Как избежать
Чтобы добиться синхронизации по задачам, координируйте действия команды/ команд, работающих над одним продуктом. Например, проводите общее «Демо» проектирования и разработки, уведомляйте о новых фичах другие команды. Заведите в общем доступе документ с историей релизов, которая четко описывает, что, когда и какой командой было сделано, добавив ссылку на задачу в таск-трекере.
У новых продуктов в процессе эксплуатации выявляются проблемы. Не секрет, что некоторые доработки по проектам инициированы пользователями, которые обратились в службу поддержки. Никто не спорит: продукты надо улучшать, но прежде чем бросаться «латать дыры» следует поискать корневую причину проблем.
Как избежать
Соберите обращения пользователей за достаточный отрезок времени. В зависимости от количества обращений в службу поддержки этот отрезок может составлять как неделю, так и месяц и больше. Проанализируйте вопросы выявите повторяющиеся и решайте те проблемы, на которые пользователи жалуются чаще всего. Если проблема носит блокирующий характер, то есть влияет на корректность работы пользователя в системе, решайте ее незамедлительно.
Зачастую, получив бизнес-требования заказчиков, проектировщик приступает к описанию логики работы задач. Если при этом не взять в учет технические особенности системы, может получиться решение, которое выльется в 3 месяца разработки.
Пример из практики
Однажды в Rookee произошла ситуация. Отрисовали интерфейс, в котором был мастер создания проекта в одном из продуктов: на первом шаге пользователь авторизуется в другом сервисе для получения информации из него (в Яндекс.Директе), на втором шаге выбирается список параметров для работы. Параметры получались путем выполнения запроса по токену, указанном на первом шаге.
Интерфейс показали заказчикам, согласовали, отправили разработчикам. Когда разработчики это увидели, они сказали: «Тут придется показывать кино, так как если данных у пользователя много, то ждать он может очень долго. К тому же это интерфейсное решение не user-friendly».
В результате пришлось все переделывать, учитывая обратную связь от программистов.
Как избежать
Приглашайте разработчиков участвовать в обсуждении проектов, составлении требований, вовлекайте их в проектирование. Включив разработчиков в работу на ранних этапах, можно существенно сократить время создания проекта, избежать лишних затрат на переделку и обойтись без лишних седых волос из-за срыва сроков.
Периодически коммерческих специалистов посещают гениальные идеи при создании новых продуктов или доработке старых. К сожалению, не все гениальное востребовано и реализуемо.
Пример из практики
Для увеличения объема продаж нередко используют авторские email-стратегии. Для их реализации существует множество способов: настройка отправки событий, сторонний сервис email-рассылок, который отправляет письма по сигналу вашего сервиса, реализация единой триггерной логики на стороне вашего сервиса и использование стандартного или универсального шаблона для рассылки и др.
Иногда компании решают пойти своим путем и сделать не как все. Сочиняя первое письмо для пользователей в команде думали, что оно будет последним. А потом отправили еще одно последнее письмо. И еще… Когда писем стало много, команда реализовала свой сервис по созданию шаблонов. Он делался 2 месяца и оказался не так хорош, как уже существующие специализированные сервисы. В итоге в компании пришли к оптимальному решению – интегрировали сторонний сервис рассылок.
Как избежать
Если реализация нововведения кажется слишком сложной, откажитесь от нее.
Не тратьте время на создание сервисов, которые будут явно проигрывать уже существующим. Ответьте себе на вопрос, так ли вам нужен инструмент, который сложно поддерживать, но зато свой?
Неоднозначно поставленная задача создает недоразумения, которые могут привести к нежелательным результатам. Например, аналитик может попросить: «Добавьте пять слонов рядом с полем регистрации». Для разных членов команды само собой разумеющимися могут быть разные варианты этого «рядом»: справа, слева, сверху и снизу.
Как избежать
Если требование не до конца понятно, необходимо задавать уточняющие вопросы. Членам команды следует научиться максимально детализировать каждую задачу, чтобы избежать путаницы и додумывания. Уровень детализации требований обговаривается внутри команды. Также можно разработать шаблон ТЗ, который всех устроит, и в нем максимально подробно прописывать цель задачи, логику и пользовательский интерфейс.
Как ни странно, находятся люди, которые верят: лучше привлечь как можно больше пользователей, а среди них обязательно окажется и целевая аудитория продукта. Это не так. У вас может быть специфичный продукт, потребители которого — определенный сегмент пользователей.
Пример из практики
Целевая аудитория продукта — домохозяйки, однако проекту хотелось получить много трафика. Потратив значительную сумму на рекламу, компания стала публиковать двусмысленные баннеры на крупных бизнес-порталах в надежде привести платежеспособных клиентов. Трафик сильно увеличился, а продажи — нет. Когда провели опрос, почему пользователи заходят на сайт и ничего не покупают, оказалось, что большинство из них просто не являются ЦА. Предлагаемый продукт их просто не интересовал. В рекламную кампанию были внесены изменения, и проблема через некоторое время разрешилась.
Как избежать
Изначально лучше сосредоточить свои усилия на привлечение целевого трафика и вносить корректировки в рекламные кампании и позиционирование, если посетители сайта — точно не ваши потенциальные клиенты.
Такая проблема может возникнуть при неверном планировании гипотез или низком уровне квалификации аналитиков.
Пример из практики
Компания начала тестировать две версии формы регистрации на лендинге (50% пользователей видят одну версию, 50% — другую). Затем появилась необходимость проверить другую гипотезу на зоне оплаты, и был запущен еще один тест. Это усложнило работу аналитиков, так как пришлось долго делить когорты таким образом, чтобы оценить влияние изменений на конечные действия пользователя. На сбор данных ушло гораздо больше времени, чем потребовалось бы при проведении тестов друг за другом.
Как избежать
При проведении A/B-тестов не допускайте пересечения сплитов. Старайтесь разделять пользователей так, чтобы один человек участвовал только в одном эксперименте. Если вдруг все же было запущено сразу два теста, оценивайте 4 группы:
Одна из типичных ошибок — это принятие своего мнения за мнение пользователя. Если вам нравится продукт, его дизайн и юзабилити, вы понимаете, как с ним взаимодействовать, не факт, что пользователь разделит ваш восторг.
Как избежать
При разработке каждой отдельной зоны интерфейса учитывайте визуал всего сервиса в целом. Не думайте за пользователя. Спросите у него (например, с помощью метода фокус-группы), как ему удобнее, привычнее, лучше, чего он ожидает от нового продукта. Яндекс перед запуском продуктов проводит очные тестирования: встречается с пользователями, смотрит на их реакцию, задает неудобные вопросы по своей гипотезе.
Если заранее узнать мнение пользователя о разработке, можно избежать множества проблем в дальнейшем.
При возникновении спорной ситуации в работе какого-либо системного модуля, быстрее и проще всего обратиться к логам событий. Если, конечно, они есть. Если вы ленились и не логировали события, придется потрудиться, чтобы отыскать первоисточник проблемы при ее возникновении.
Как избежать
Логируйте события по максимуму. Это не значит, что надо начать логировать каждую мелкую деталь, вроде пользовательского движения мышкой, но основная информация, происходящая с объектом, должна быть записана.
Любая компания может столкнуться с проблемами при разработке новых продуктов. Главное, признать ошибки, сделать выводы и принять меры, чтобы в будущем они не повторялись.
А в вашей практике разработки случались неудачи и как вы с ними боролись? Расскажите о своем опыте в комментариях.
Автор: Екатерина Хиндикайнен, ведущий системный аналитик сервиса Rookee
1. Забудьте о процессе, работайте на результат
Нередко компании при разработке продукта все внимание и ресурсы направляют на процесс создания и производства. Даже если каждый этап работ выполнен «строго по технологии», результат может оказаться не таким радужным, как представлялось в начале.
Пример из практики
Три месяца назад в команде Rookee был внедрен сложный процесс системной аналитики. Аналитик должен был запрашивать и собирать маркетинговые исследования, готовить варианты решения, запрашивать финансовые расчеты, проектировать алгоритмы, ставить задачи для UX, определять бизнес-требования, проводить защиту своих решений, отслеживать результат после выкладки, передавать в эксплуатацию и т.д. Нагрузка на одного аналитика могла достигать 15 задач в день. Специалист физически не может пропустить через себя в сутки такое количество разноплановых задач. Неудивительно, что с таким объемом работа аналитика являлась узким горлышком в решении общих задач. Для повышения эффективности многие вещи происходили в обход. В итоге в компании отказались от такого сложного процесса и радикально его упростили, распределив обязанности между разными специалистами. Эффективность повысилась, а процесс аналитики стал происходить быстрее.
Как избежать
Если процесс разработки продукта слишком сложен, а результат не отвечает ожиданиям, необходимо пересмотреть текущие процессы и стать более гибким к изменениям на каждом этапе работ.
2. Сохраняйте высокий уровень командной синхронизации
Умение работать в команде — важный навык, которым обладают далеко не все. На практике часто возникают ситуации, когда для реализации одной задачи требуется привлечение сразу нескольких специалистов.
Например, задача о внедрении промокода в систему подразумевает под собой работу и фронтенд-разработчика, и бэкенд. Если эти люди не могут договориться между собой, возможно возникновение самых разных проблем. Например, с точки зрения визуала задача будет сделана, но без алгоритма отработки механики промокода эта задача не даст никакой ценности.
Пример из практики
Когда в нашем сервисе появилось несколько разных продуктов, команды разработки у каждого продукта остались свои. Пользователь один, аккаунт один, а продукты и команды разные. Как-то нам позвонил клиент и сказал, что мы его заспамили. Оказалось, что все команды слали ему письма, когда возникали ситуации, требующие внимания (например, баланс подходил к нулю и работа сервиса могла быть приостановлена). В итоге пользователь получал в неделю порядка 40 писем от сервиса. Был проведен анализ email-рассылок. Некоторые письма объединили. Сейчас в проработке находится email-стратегия, которая окончательно исправит все недостатки.
Как избежать
Чтобы добиться синхронизации по задачам, координируйте действия команды/ команд, работающих над одним продуктом. Например, проводите общее «Демо» проектирования и разработки, уведомляйте о новых фичах другие команды. Заведите в общем доступе документ с историей релизов, которая четко описывает, что, когда и какой командой было сделано, добавив ссылку на задачу в таск-трекере.
3. Избегайте доработок продуктов по первому требованию пользователя
У новых продуктов в процессе эксплуатации выявляются проблемы. Не секрет, что некоторые доработки по проектам инициированы пользователями, которые обратились в службу поддержки. Никто не спорит: продукты надо улучшать, но прежде чем бросаться «латать дыры» следует поискать корневую причину проблем.
Как избежать
Соберите обращения пользователей за достаточный отрезок времени. В зависимости от количества обращений в службу поддержки этот отрезок может составлять как неделю, так и месяц и больше. Проанализируйте вопросы выявите повторяющиеся и решайте те проблемы, на которые пользователи жалуются чаще всего. Если проблема носит блокирующий характер, то есть влияет на корректность работы пользователя в системе, решайте ее незамедлительно.
4. Приглашайте разработчиков к обсуждению проекта и проектированию задач
Зачастую, получив бизнес-требования заказчиков, проектировщик приступает к описанию логики работы задач. Если при этом не взять в учет технические особенности системы, может получиться решение, которое выльется в 3 месяца разработки.
Пример из практики
Однажды в Rookee произошла ситуация. Отрисовали интерфейс, в котором был мастер создания проекта в одном из продуктов: на первом шаге пользователь авторизуется в другом сервисе для получения информации из него (в Яндекс.Директе), на втором шаге выбирается список параметров для работы. Параметры получались путем выполнения запроса по токену, указанном на первом шаге.
Интерфейс показали заказчикам, согласовали, отправили разработчикам. Когда разработчики это увидели, они сказали: «Тут придется показывать кино, так как если данных у пользователя много, то ждать он может очень долго. К тому же это интерфейсное решение не user-friendly».
В результате пришлось все переделывать, учитывая обратную связь от программистов.
Как избежать
Приглашайте разработчиков участвовать в обсуждении проектов, составлении требований, вовлекайте их в проектирование. Включив разработчиков в работу на ранних этапах, можно существенно сократить время создания проекта, избежать лишних затрат на переделку и обойтись без лишних седых волос из-за срыва сроков.
5. Упрощайте. Гениально, это когда эффективно
Периодически коммерческих специалистов посещают гениальные идеи при создании новых продуктов или доработке старых. К сожалению, не все гениальное востребовано и реализуемо.
Пример из практики
Для увеличения объема продаж нередко используют авторские email-стратегии. Для их реализации существует множество способов: настройка отправки событий, сторонний сервис email-рассылок, который отправляет письма по сигналу вашего сервиса, реализация единой триггерной логики на стороне вашего сервиса и использование стандартного или универсального шаблона для рассылки и др.
Иногда компании решают пойти своим путем и сделать не как все. Сочиняя первое письмо для пользователей в команде думали, что оно будет последним. А потом отправили еще одно последнее письмо. И еще… Когда писем стало много, команда реализовала свой сервис по созданию шаблонов. Он делался 2 месяца и оказался не так хорош, как уже существующие специализированные сервисы. В итоге в компании пришли к оптимальному решению – интегрировали сторонний сервис рассылок.
Как избежать
Если реализация нововведения кажется слишком сложной, откажитесь от нее.
Не тратьте время на создание сервисов, которые будут явно проигрывать уже существующим. Ответьте себе на вопрос, так ли вам нужен инструмент, который сложно поддерживать, но зато свой?
6. Избегайте неоднозначного интерпретирования требований
Неоднозначно поставленная задача создает недоразумения, которые могут привести к нежелательным результатам. Например, аналитик может попросить: «Добавьте пять слонов рядом с полем регистрации». Для разных членов команды само собой разумеющимися могут быть разные варианты этого «рядом»: справа, слева, сверху и снизу.
Как избежать
Если требование не до конца понятно, необходимо задавать уточняющие вопросы. Членам команды следует научиться максимально детализировать каждую задачу, чтобы избежать путаницы и додумывания. Уровень детализации требований обговаривается внутри команды. Также можно разработать шаблон ТЗ, который всех устроит, и в нем максимально подробно прописывать цель задачи, логику и пользовательский интерфейс.
7. Помните о целевой аудитории
Как ни странно, находятся люди, которые верят: лучше привлечь как можно больше пользователей, а среди них обязательно окажется и целевая аудитория продукта. Это не так. У вас может быть специфичный продукт, потребители которого — определенный сегмент пользователей.
Пример из практики
Целевая аудитория продукта — домохозяйки, однако проекту хотелось получить много трафика. Потратив значительную сумму на рекламу, компания стала публиковать двусмысленные баннеры на крупных бизнес-порталах в надежде привести платежеспособных клиентов. Трафик сильно увеличился, а продажи — нет. Когда провели опрос, почему пользователи заходят на сайт и ничего не покупают, оказалось, что большинство из них просто не являются ЦА. Предлагаемый продукт их просто не интересовал. В рекламную кампанию были внесены изменения, и проблема через некоторое время разрешилась.
Как избежать
Изначально лучше сосредоточить свои усилия на привлечение целевого трафика и вносить корректировки в рекламные кампании и позиционирование, если посетители сайта — точно не ваши потенциальные клиенты.
8. Не допускайте пересечения сплит-тестов при проверке гипотез
Такая проблема может возникнуть при неверном планировании гипотез или низком уровне квалификации аналитиков.
Пример из практики
Компания начала тестировать две версии формы регистрации на лендинге (50% пользователей видят одну версию, 50% — другую). Затем появилась необходимость проверить другую гипотезу на зоне оплаты, и был запущен еще один тест. Это усложнило работу аналитиков, так как пришлось долго делить когорты таким образом, чтобы оценить влияние изменений на конечные действия пользователя. На сбор данных ушло гораздо больше времени, чем потребовалось бы при проведении тестов друг за другом.
Как избежать
При проведении A/B-тестов не допускайте пересечения сплитов. Старайтесь разделять пользователей так, чтобы один человек участвовал только в одном эксперименте. Если вдруг все же было запущено сразу два теста, оценивайте 4 группы:
- первый вариант лендинга + первый вариант на зоне оплаты;
- первый вариант лендинга + второй вариант на зоне оплаты;
- второй вариант лендинга + первый вариант на зоне оплаты;
- второй вариант лендинга + второй вариант на зоне оплаты.
9. Не путайте свое мнение с мнением пользователя
Одна из типичных ошибок — это принятие своего мнения за мнение пользователя. Если вам нравится продукт, его дизайн и юзабилити, вы понимаете, как с ним взаимодействовать, не факт, что пользователь разделит ваш восторг.
Как избежать
При разработке каждой отдельной зоны интерфейса учитывайте визуал всего сервиса в целом. Не думайте за пользователя. Спросите у него (например, с помощью метода фокус-группы), как ему удобнее, привычнее, лучше, чего он ожидает от нового продукта. Яндекс перед запуском продуктов проводит очные тестирования: встречается с пользователями, смотрит на их реакцию, задает неудобные вопросы по своей гипотезе.
Если заранее узнать мнение пользователя о разработке, можно избежать множества проблем в дальнейшем.
10. Логируйте события по максимуму
При возникновении спорной ситуации в работе какого-либо системного модуля, быстрее и проще всего обратиться к логам событий. Если, конечно, они есть. Если вы ленились и не логировали события, придется потрудиться, чтобы отыскать первоисточник проблемы при ее возникновении.
Как избежать
Логируйте события по максимуму. Это не значит, что надо начать логировать каждую мелкую деталь, вроде пользовательского движения мышкой, но основная информация, происходящая с объектом, должна быть записана.
Заключение
Любая компания может столкнуться с проблемами при разработке новых продуктов. Главное, признать ошибки, сделать выводы и принять меры, чтобы в будущем они не повторялись.
А в вашей практике разработки случались неудачи и как вы с ними боролись? Расскажите о своем опыте в комментариях.
Автор: Екатерина Хиндикайнен, ведущий системный аналитик сервиса Rookee