Наверное, история создания многих клиентских сервисов начиналась в пределах собственной компании. Сначала придумали костыль, чтобы решить свою проблему. Затем, когда все полетело, — решение отправили в мир. Так было со многими продуктами Контура и сервисами нашего Удостоверяющего центра в частности. Как понять, будет ли полезен ваш продукт другим клиентам, и стоит ли в это вообще ввязываться, расскажу я — Сергей Лапшин, менеджер проектов в Удостоверяющем центре Контура. В УЦ занимаюсь многими проектами. Но свой рассказ сегодня буду вести на примере сервиса Корпоративный центр регистрации. Если кратко: он позволяет компаниям получать сертификаты электронной подписи и идентифицировать личность будущих владельцев на рабочих местах.
Сначала введу в контекст
Мы крупный коммерческий удостоверяющий центр. Наша работа завязана вокруг электронных подписей и главой ценности — обеспечить сертификатами КЭП клиентов.
За помощью к нам обращаются корпоративные клиенты и небольшие организации. Технически и юридически мы обеспечиваем их необходимыми инструментами для электронного документооборота: сертификатами ЭП и сопутствующими сервисами.
И делаем мы это разными способами:
стандартный — это, конечно, веб-интерфейсы.
если клиенту удобно работать в собственной информационной системе — предоставляем API-решения.
разветвленным структурам отдаем часть процесса подготовки запроса на сертификат, чтобы некоторые процессы они могли выполнять самостоятельно.
среди клиентов у нас есть даже удостоверяющие центры — для них у нас есть on-prem решение.
Многие продукты появлялись как внутренние сервисы
Например, прототипом сервиса Корпоративный центр регистрации стал интерфейс, который мы использовали для подготовки заявок на сертификат в наших офисах продаж. Тогда он выполнял лишь ограниченную часть операций.
Потом для взаимодействия продуктов Контура с удостоверяющим центром мы стали использовать API Корпоративного центра регистрации. На старте он был просто внутренним инструментом, а потом стал успешным коммерческим продуктом. Сейчас он позволяет нам взаимодействовать с другими разработчиками ПО и предоставлять им услуги УЦ как кусочек собственного сценария — особенно это хорошо работает в кЭДО.
Однажды мы пошли дальше и обернули в продукт всю нашу инфраструктуру, построенную вокруг удостоверяющего центра, и начали продавать её другим коммерческим УЦ. Самым успешным из этих продуктов стал КЦР, он пережил уже несколько изменений и сейчас полностью ориентирован на внешних потребителей.
Есть план, и его можно придерживаться
Обычно процесс превращения внутреннего сервиса в продукт выглядит так:
Компания решает какую-то собственную задачу, изучает контекст и набивает шишки.
Исследует рынок или работает со входящими запросами.
Понимает, что у клиентов есть запрос на решение такой же проблемы.
Оценивает масштабируемость продукта и считает бизнес модель.
Проводит техническую и юридическую аналитику и разработку для отделения продукта от своей инфраструктуры.
Успешно продает и масштабирует.
Или набивает шишки и закрывает проект. Такое бывает тоже.
Как исключить последний пункт из плана
В процессе запуска многое может пойти в разрез с ожиданиями. Чтобы держать ситуацию под контролем, сфокусируйте внимание вот на чем:
1. Если не готовы заниматься заказной разработкой, решение должно быть тиражируемым.
Даже запрос с большим чеком, но без рынка, приведет вас к режиму выживаемости: придется заниматься системной интеграцией и заказной разработкой. А такое продуктовое развитие может пойти вразрез с ценностями вашей команды и стратегией компании.
2. Процессы клиента могут сильно отличаться от ваших.
Проверьте, насколько универсально ваше решение. Возможно, и у вас, и у клиента была одна и та же проблема, но процессы в ваших компаниях, стандарты качества и взгляд на работу с рисками сильно разнятся.
3. Решения не существуют в вакууме. Думайте про отделяемую инфраструктуру на старте.
IT-продукт — это не только интерфейсы, поля для ввода и сценарии. Не забывайте, что еще это и инфраструктурные решения: СУБД, инструменты управления правами, балансировщики и др.
Как это работает в конкретной компании — нужно обязательно выяснить. Да, если предоставляете продукт как SAAS, то можете обойтись небольшим техническим ревью. Но если это on-prem, будьте готовы к большому бандлу задач для разработки. Очень часто этот пункт остается зря недооценен.
4. Думайте про систему доступа
На старте проверьте: насколько система управления правами доступа подходит для клиентских сценариев, а также насколько безопасны ваши чувствительные данные.
У внутреннего продукта больше шансов на успех
Вообще, разглядеть хороший продукт среди собственных и вывести его во внешний мир проще, чем создавать новый, опираясь на исследовательские данные. Но чтобы он успешно тиражировался и решал не только вашу задачу, обращайте внимание на детали во время реализации. С отделением MVP могут быть проблемы, но с другой стороны опыт и экспертиза в решении подобной задачи помогут лучше понять потребителя и дать ему лучшее решение.