Принципы развития productivity-сервисов на примере Хаос-контроля
Вчера мы опубликовали пост об изменении стратегии развития Хаос-контроля. Теперь хочу рассказать вам о базовых принципах развития утилитарных продуктов вроде ХК, которые мы заложили в нашу обновленную стратегию.
Во-первых, если вы еще не слышали о Хаос-контроле, то достаточно знать, что это сервис для управления проектами и задачами для людей, работающих на себя. Технически он представляет собой приложение, доступное на мобиле и ПК: iOS, Android, Windows и Mac. Есть также облако, в котором хранятся данные пользователей. В общем, классическая клиент-серверная система.
Во-вторых, работа над новым поколением продукта под кодовым названием Хаос-контроль 2 ведется уже давно, выпущено несколько альфа-версий обновленного приложения для Android и ПК, а в тестировании участвует несколько сотен пользователей. Работы проделано много, поэтому выводы о необходимости смены стратегии основываются на первых тестах обновленного продукта и опыта его развития. Если вкратце, бОльшая часть текущих наработок не будет использована.
Теперь, собственно, о принципах.
Принцип 1: кросс-платформенная разработка - это норм
Еще пару лет назад я был сильно против кросс-платформенных инструментов разработки применительно к продуктам вроде Хаос-контроля. Мои претензии к ним были следующими:
- Кросс-платформенные инструменты не успевают за изменением платформ. Например, выпускает Apple какой-нибудь HealthKit version X, а у тебя не то что раннего доступа к нему нет через бету XCode, так еще и потом ждать нужно, пока твой кросс-платформенный фреймворк начнет нормально поддерживать новую версию ОС и новое API
- Сами платформы (Apple и Google) склонны поддерживать те проекты, которые разработаны на нативных инструментах, а не сторонних фреймворках
- Кросс-платформенные решения всегда медленнее, чем нативные средства разработки
- Кросс-платформенные фреймворки обычно принадлежат каким-то мутным компаниям, которые в любой момент могут исчезнуть или перестать развивать свои решения. Необязательная зависимость от чужих инструментов - фиговая история для технологического проекта
В данный момент все эти доводы либо развалились, либо перестали быть значимыми:
- Первый пункт вообще уже либо не соответствует действительности, либо не является критичным
- Платформам, в действительности, абсолютно все равно на какой технологии разработано конкретное приложение. Главное метрики и демонстрация успешных сценариев использования пользователями платформы
- Скорость работы современных кросс-платформенных решений больше не проблема (если вообще когда-либо ею была)
Вместе с тем, параллельная разработка одного и того же приложения на iOS, Android, ПК и Web с использованием соответствующих нативных инструментов (Swift, Kotlin, и т.д.) зарекомендовала себя как супер-стрёмная история в нашем случае.
Представьте себе, что одну и ту же функциональность вам нужно реализовать и отладить 4 раза. В случае с такими комплексными продуктами, как Хаос-контроль, это практически нереально, учитывая, что у нас очень lean-команда.
Мы попробовали с Хаос-контроль 2 разиваться на нативных инструментах - нам не понравилось. Если бы мы начинали со стадии MVP, то это было бы еще реально, а в случае когда нужно с нуля разработать абсолютно новый продукт, не уступающий функционально старому, это прям долго и тяжело.
Поэтому мы приняли решение перейти на кросс-платформенный фреймворк Flutter, который лучше всех зарекомендовал себя как средство разработки как под мобильные устройства, так и под настольные платформы. Да еще и поддерживается Google.
Поэтому теперь всю внутреннюю логику мы реализуем один раз без необходимости делать одну и ту же работу 4 раза. Это сильно все упрощает и позволяет одним и тем же разработчикам заниматься сразу несколькими платформами одновременно.
В целом, я считаю, что нативная разработка для небольших команд, нацеленных сразу не несколько поддерживаемых платформ - это не вариант. Рискну даже сказать, что нативная разработка как таковая в принципе себя изжила в 99% случаев.
Принцип 2: много функций = несколько отдельных приложений
У концепции супер-приложений, вмещающих в себе широкий спектр функций, интересная история - они то в моде, то не в моде. Сейчас, своего рода, ренессанс супер-аппов благодаря банковским приложениям вроде Тинькова, в которых можно и перевод сделать, и билеты в кино купить, и початиться со знакомыми.
В случае с Хаос-контроль 2, от него ожидается:
- функциональность управления проектами и задачами
- функции делегирования и командной работы
- возможность добавления файлов, заметок и картинок к проектам и задачам
- функциональность трекера привычек
- функции тайм-трекера
- внутренний стор с косметическими элементами и игровыми механиками
- и многое(!) другое
Изначально мы собирались делать супер-апп, то есть включать всю эту функциональность в одно приложение. В результате работы по проектированию, анализу потребностей нашей целевой аудитории и возвращению здравого смысла, мы отказались от этой затеи и пришли к более разумной концепции развития зонтичного бренда, когда есть несколько приложений:
- Флагман: органайзер Хаос-контроль с возможностями управления задачами/проектами, командной работой и облачным хранилищем для файлов/ресурсов
- Приложения-сателлиты: тайм-трекер, трекер привычек, дневник и прочие
Логика такого решения в следующем:
- Не всем пользователям Хаос-контроля нужны функции вроде тайм-трекера, дневника и привычек (особенно в контексте командной работы, когда будет роль подчиненного, которому вообще ничего от жизни не надо кроме поставленных ему задач)
- Добавление этих функций в органайзер сильно усложнит жизнь как нам, так и пользователям. Это будет что-то очень монструозное, неповоротливое и трудноподдерживаемое
- С другой стороны, функции тайм-трекера и трекера привычек - это достаточно самостоятельные функции, которые востребованы пользователями без привязки к функциональности управления задачами и проектами
- Наличие нескольких приложений позволяет больше зарабатывать за счет дополнительных видов лицензий. Этот пункт больше всего напряг вокальное меньшинство пользователей, переживающих, что сейчас их любимый органайзер попилят на части и "заставят платить" за то, что у них уже было. Действительности это не соответствует. Старый органайзер не только не попилят, но еще и добавят функций под старые лицензии
При этом в комментариях к оригинальной публикации есть апологеты супер-аппов, которые считают, что они удобнее. Чтож, им я могу ответить так:
супер-апп имеет смысл только если все компоненты приложения направлены на реализацию одного ключевого бизнес-сценария.
Например, ключевой бизнесовый сценарий приложения банка Тинькофф в том, чтобы избавить пользователя от лишних денег на счету. Ключевой сценарий приложения Facebook - увеличить количество единиц контента, потребляемого пользователем за сеанс. Ключевой сценарий Яндекс.Еды - увеличить количество заказов на пользователя и т.д. То есть сценарий в каждом аппе один, хоть в них и миллион разделов.
В случае с Хаос-контролем и прочими утилитарными сервисами имеют место несколько бизнес-сценариев, попытка упаковать которые в один супер-апп приведет к созданию франкенштейна.
Поэтому зонтичный бренд.
Принцип 3: либо сетевой эффект, либо ничего
Я уже писал вот здесь, что утилитарные сервисы без функций коллаборации обречены на вечную несходимость экономики и отсутствие внятного ответа о product/market fit.
Не буду тут в это вдаваться снова, скажу лишь одно: у меня ровно ноль интереса делать продукт в котором не заложен network-эффект. В случае с Хаос-контроль 2 сетевой эффект предусмотрен следующим образом:
- Органайзер проектируется с фокусом на функции коллаборации команд (совместные проекты, делегирование и т.д.)
- Приложения-сателлиты проектируются с функциями социального взаимодействия: тайм-трекер с функциями командной работы и отчетности, трекер привычек с социальным компонентом, дневник с функциями блога
В целом, сетевой эффект - штука сложная, по ней даже отличная книга есть. Но делать продукт, не закладывая в его дизайн функции взаимодействия пользователей, крайне мало смысла. Поэтому мы уделяем этому вопросу много внимания.
Такие дела.
P.S. В качестве эксперимента я записал коротенький Reels в инсте с парой комментариев к этому посту. Посмотреть его и задружиться можно здесь.
Подписывайтесь на мой Telegram-канал, где я пишу о различных аспектах созидательной деятельности и развитии IT-продуктов.