Разработка новых функций в IT-стартапе: как изменения в продукте несут риски и что с этим делать

Как в сервисе появляются новые функции

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

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

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

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

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

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

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

Концепция фичи «Треки», которая поможет поставить в групповом чате цель с дедлайном и отследить её

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

Как снизить количество промахов при создании новых фич

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

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

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

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

Как культура стартапа помогает создавать новые функции

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

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

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

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

Ответы работают как внутри тредов, так и в ленте чата. Можно даже ответить сообщение с комментариями

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

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

Итого

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

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