У вас есть только 2 года на все. Какие ошибки мы наделали при запуске собственного digital-продукта

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

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

Мы прошли этот путь в более спокойные времена. Но глобально – в плане разработки своего продукта ничего не поменялось. В 2018 году Владимир Завертайлов, руководитель «Сибирикс», вместе с командой взялся за разработку собственного приложения — сервиса для планирования задач SingularityApp. В этой статье Владимир рассказывает о своем опыте создания цифрового продукта и дает советы новичкам продуктового бизнеса.

У вас есть функционирующая (возможно, даже успешно) компания в сфере IT. Клиенты довольны вашей работой, компания стабильно приносит прибыль, но вот беда — вы вдруг осознали, что профессионально застоялись и вам нужно свежее дыхание, бизнес-рывок. Создать внутренний цифровой продукт — вот оно, то самое решение. Мы решили заняться инструментами планирования, поскольку имели очень большой опыт их использования и были недовольны теми решениями, которые есть на рынке. Хотелось сделать что-то стоящее.

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

Еще в 2019 году исследования утверждали, что средний срок работы сотрудника в крупных компаниях вроде Facebook, Microsoft и Uber — от 1,5 до 2,5 лет. В 2022 удержать работников становится ещё сложнее. А значит, команда, с которой вы начнете запуск продукта, через пару лет сменится практически полностью, что сильно усложнит процесс.

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

1 этап. Разработка продукта

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

2 этап. Доработка и введение в эксплуатацию

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

Был период, когда единственное, чего нам не хватало для запуска – системы биллинга. Нам нужны были рекурсивные платежи, поддержка платежей Apple, Google и PayPal. Сама по себе задача довольно сложная, поскольку работает с очень чувствительным для пользователя аспектом: деньгами. Плюс юридическая оснастка (контракты с банками, онлайн-кассами, получение DUNS, разные соглашения для пользователей на сайте) требовали планомерной, вдумчивой работы.

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

3 этап. Выход на рынок

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

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

4 этап. Разработка новой версии

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

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

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

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

Бонусы, которые вы получите в процессе создания собственного продукта:

Управлять агентством и одновременно запускать проект сложно (на самом деле, почти невозможно). Придется стандартизировать все процессы, делегировать на сторону рутину, например, продвижение, PR. Для того, чтобы высвободить собственное время, можно нанять исполнительного директора и передать ему заметную часть задач по управлению агентством.

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

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

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