Стартап на 1С. Хроники (1)

Вместо предисловия

Всем привет, давненько я не отмечался статьями на Инфостарт. Меня зовут Олег и в последнее время я гордо называю себя CEO EmplDocs. EmplDocs - решение в области КЭДО, появившееся одним из первых (несомненно, лучшее в мире и самое функциональное :)), но в целом ничем другим от прочих стартапов в области КЭДО не отличающееся, кроме того, что весь Backend нашего приложения разработан на платформе 1С. Насколько мне известно, стартапы, в основе технологического стека которых лежит платформа 1С, являение не частое (иногда вообще кажется, что мы одни такие). Хотелось бы таких историй намного больше. Отчасти поэтому я хотел бы поделиться нашей историей, захвата мира надеюсь, будущего большого успеха. 

Для меня это статья некий дневник, который позволит более четко провести ретроспективу действий и решений при необходимости - что очень важно. Для вас, кто собрался прочитать, надеюсь, возможность поучиться не на своих ошибках и не наступать на те же грабли, что и мы, а самое главное - не бояться выходить на рынок ИТ продуктов, используя 1С в основе стека.

Ну и если данный труд оказался интересен и\или полезен - поставьте лайк, это небольшая, но мотивация для написания новых статей цикла.

Идеальный личный кабинет для 1С. Поиски решения и история создания EmplDocs

Над задачей личного кабинета для 1С мы задумывались очень давно и даже реализовывали её несколькими путями. То, что сложилось сейчас - результат многолетней работы.

Мы попробовали варианты:

1) Полностью в 1С

2) Фронт сделан на конструкторе сайта LowCode (WebFlow/Даже Tilda), бэк-1С

3) Отдельный фронт, отдельный бэк и синхронизация

4) Фронт сделан на LowCode движке (AppSmith) бэк - 1С

5) 1С генерирует и шаблонизирует страницы (pug внутри 1С).

6) Отдельный фронт (SPA), разработанный по принципу Backend driven. Бэк - 1С.

Остановились мы на варианте (6). Далее попробую пояснить, почему.

Начинали мы с варианта 1 - полностью в 1С. Даже сохранилась картинка - примерно вот так выглядела первая версия EmplDocs в далёком 2018-м году:

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

• Интерфейс и удобство для пользователей оставляет желать лучшего
• Определенные интерфейсные ограничения платформы 1С всё-таки присутствуют
• Лицензирование 1С
• Достаточно высокая нагрузка на сервер 1С и СУБД соответственно
• Длительное время загрузки Web клиента 1С
• Ограниченное применение в мобильной Web версии

Анализ из разряда "спасибо, КЭП" конечно, поэтому с этого варианта мы достаточно быстро переключились на вариант 2 - конструктор Web сайтов:

Видим результат визуально уже несколько лучше, но тем не менее ещё несколько далёк от современного Web приложения.

Конструктор Web сайтов мы в данном случае использовали WebFlow, хотя были и опыты на популярной Tilda, правда с несколько более простой функциональностью. WebFlow позволяет экспортировать созданный контент для использования offline.

Но, как видим, у такого варианта тоже хватает недостатков:

• функционал конструктора всё-таки не позволяет полноценно работать дизайнеру
• интерфейс не соответствует требованиям к современному Web приложению
• функционал фронтенд части ограничен возможностями конструктора

Мы также попробовали вариант 3 - отдельные бэк и фронт

Недостаток этого варианта по сути только один: жутко, люто дорого и трудозатратно. Сделать можно практически всё что угодно, ограничений никаких, просто всё очень долго и дорого - это "не 1С-ный подход". Добро пожаловать в мир большого ИТ. Допустим, вам нужно добавить поле на главный экран:

• Работает дизайнер (что хорошо)
• Работает фронтендер
• Работает бэкендер
• Они согласуют API
• Работает 1С специлист
• Согласуют API между 1С и бэкендом
• Модифицируют протокол обмена (там ещё middleware обязательно, надеюсь, все понимают)
• Далее выкатывается на прод, ну и обмены с 1С, естественно, должны отслеживаться и качественно мониториться

Кажется, это не совсем соответствует заголовку "лучший личный кабинет для 1С". Тут стоило бы, наверное, попробовать Элемент, но был 2019-й год, Элемент-а ещё не было и мы соответственно его не рассматривали. А в нынешних реалиях мы уже, конечно, не готовы отказаться от полной гибкости фронта. Ну и минимальная команда из 4-х человек (c bus factor из 8-ми) слишком много для MVP даже публичного приложения.

Логично было бы попробовать сократить трудозатраты на приложение кабинета, и мы попробовали вариант 4 - LowCode (не 1С-ный LowCode).

Собственно вот примерно так выглядит современная LowCode платформа AppSmith

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

Но для публичного приложения всё-таки обладает рядом недостатков:

• появляется Backend, который каким-то образом обрабатывает данные и при этом имеет закрытый код
• на фронтенде есть пусть и незначительные, но ограничения
• специалисты, разрабатывающие ПО на AppSmith, должны владеть именно функционалом AppSmith - готовых на рынке найти не так просто
• для коммерческого продукта можно столкнуться с рядом недостатков и ограничений бесплатной версии

Поэтому мы сделали ещё один заход для разработки личного кабинета в качестве MPA при генерации Web страничек на стороне 1С с использованием шаблонизаторов - вариант 5. Вот что в итоге получилось:

В итоге получился целый Framework, который ушел в OpenSource и ссылку на который здесь запрещено размещать. 

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

• для работы с шаблонами всё равно нужна верстка и нужны фронтенд разработчики, которых мы заставляем работать достаточно неудобным образом
• скорость отдачи странички всё-таки ниже, чем обычные обращения из SPA к бэкенду, временами весьма существенно.

Итак, мы пришли к современной версии фреймворка, который мы используем при разработке EmplDocs. 

И примерно вот так выглядит современная версия EmplDocs:

Фронтенд часть - полностью разработанное приложение, с одной оговоркой, что оно Backend Driven. Этим мы получаем с одной стороны "полную свободу творчества" со стороны дизайнера и фронтенд разработчика - избавляемся от ограничений. С другой стороны - обеспечиваем необходимую гибкость настроек и доработок, для которых необходимо участие в 99% случаев только 1С разработчиков, более того - в основном аналитиков. Также мы получаем отсутствие обменов и необходимости за ними следить. Отсутствие отдельного Backend приложения обеспечивает несколько большую безопасность - т.к. не появляется нового вектора атаки.

Что такое EmplDocs?

EmplDocs - это личный кабинет сотрудника c функциями КЭДО. Появилось решение в уже далёком 2018-м году. А в 2022-м с разрешением КЭДО на уровне законодательства в EmplDocs появился функционал КЭДО.

Ключевая история тут заключается в том, что по сути своей EmplDocs является логичным решением в виде дополнения для 1С:ЗУП - потому что все кадровые данные компании находятся в 1С:ЗУП (конечно, за исключением эксклюзива, где кадры где-то в SAP или БОСС кадровике). Поэтому по сути сделать фронтенд приложение и небольшое дополнение, которое позволит использовать API, казалось самым логичным решением. 

Потом уже появились более сложные подсистемы вроде согласования, графика отпусков, настройки заявок, взаимодействия с ними и т.п. Так или иначе и на текущий момент времени такое решение кажется логичной реализацией кабинета сотрудника для любой системы, и для 1С:ЗУП в частности.

Архитектура

Тут я могу прежде всего привести картинку из документации:

Она очень простая, но так может показаться не всем. В целом при OnPremise установке большая часть из перечисленного выше может не использоваться. Более того - тут ещё не отражена возможность использования EmplDocs через протокол WebSockets (база 1С не опубликована, при этом http запросы обрабатывает - магия же, да?). Сервисы EmplDocs Cloud являются опциональными, как и сторонние сервисы. В итоге остаётся по сути расширение для 1С и фронтенд часть.

Есть существенно более упрощенная версия:

Но суть примерно в том, что в системе отсутствует отдельный Backend за пределами 1С:ЗУП, а это значит:

• Нет необходимости в синхронизации данных
• В разы упрощается разработка и поддержка (по факту разберётся любой 1С-ник достаточно быстро)
• Лучше с безопасностью данных (исходный код открыт и данные никуда не утекают за пределы 1С)
• Все настройки делаются непосредственно в 1С
• Кадровые специалисты работают только в 1С

Вот так, для примера, у нас выглядят настройки одного вида заявок:

Как видите, всё, включая даже иконку и класс css, задаётся настройками внутри 1С, на начальном этапе это кажется не очень просто, но аналитики, используя наши онлайн курсы, быстро обучаются настройкам (на самом деле большая часть просто копируется и делается по аналогии)

И на текущий момент времени таких видов заявок у нас в базе уже несколько сотен (количество продолжает увеличиваться).

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

Позиционирование и конкуренция с классическими SaaS

На этом хочется приступить к, пожалуй, самой интересной части данного краткого дневника. А именно то, чего боятся 1С-ные команды при выходе на открытый рынок - конкуренции.

Типичные страхи:

• Да там специалисты, они лучше умеют
• Мы же Old school, а там продакты нас просто сотрут в порошок
• Стартапов на 1С нет, что мы, умнее всех, что ли?
• Мы не разработчики, мы за внедрения, разработка - это дорого
• 1С всё сделает за нас сама

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

С разрешением КЭДО - потребность в решениях КЭДО, естественно, появляется на рынке. И все, кто имел возможность и желание, в эту сторону двинутся. Кому логичнее всего сделать это? Логично, что компаниям, специализирующимся на кадровом учете и системах для кадрового учета. Могу сказать что в этом отношении 1С-WiseAdvice совсем не одинока. Практически у всех крупных аутсорсеров были и есть свои личные кабинеты. Возможно, просто кто-то стеснялся выводить их на открытый рынок, уступая его тем самым более молодым и непродуманным со всех сторон решениям.

Так или иначе, "сферический saas в вакууме" уже стал относительно простой новой областью знаний, и существует множество команд, которые хорошо умеют делать приложения:

• масштабируемые
• с приятным UX/UI
• хорошим CJM от первого контакта до оплаты
• нормально поддерживаемые (в облаке)
• с быстрым онбордингом/обучением/внедрением
• эти же команды умеют доносить ценность до клиента, выстраивать маркетинг и продажи. В целом команду, которая создаст приложение и базовое его продвижение, удовлетворяющее описанию выше, можно набрать и "с улицы" и даже взять на аутстаф.
• что же тогда? А ключевой вопрос в том, чего они НЕ могут:
• on-Premise (беспроблемный - с обновлением, кастомизацией, масштабированием)
• экспертизу - решения сложных, а не базовых кейсов, ответа на все потребности в нужной области знаний
• кастомизацию (широкую, позволяющую изменить продукт до неузнаваемости)
• крупные проекты (которые включают всё перечисленное выше и многое другое)

Если думаете, что я это всё придумал - на самом деле это не совсем правда. Ключевые недостатки SaaS уже достаточно давно описаны и проанализированы. "Серебряной пули" не существует (я в данном случае не про компанию, конечно):

Я лично, собственно, эту историю ощутил на себе ещё на примере OneRPA. Так вот, то, что не умеет SaaS, как раз ВЫ (ну и мы) очень хорошо умеете. И вопрос лишь в ценности для клиента - что то маленькое и дешевое, либо удовлетворяющее все потребности.

Ради честности, стоит отметить, что конкуренты, хорошо чувствующие себя на рынке корпоратов, у нас тоже появились. Но существенно позже, и тут уже вопрос выбора и экспертизы. Так или иначе стоимость разработки и кастомизации нашего решения дешевле в несколько раз, поэтому "нечестное преимущество" уже есть как минимум одно. Вторым наверное является большая практика и наработки сообщества 1С на корпоративном рынке. В компаниях, где есть свои отделы 1С EmplDocs чаще всего приходится очень по вкусу. Ну и как членов этого сообщества нас абсолютно не пугает "обновление измененного решения", "работа с Legacy кодом" и прочие истории с которыми вы так часто встречаетесь на проектах. Так или иначе, разработка решений по технологии описанной выше, для систем на платформе 1С даёт выигрыш в стоимости и скорости разработки в разы, если не в десятки раз, таким образом у нас есть неплохая фора перед конкурентами, ну или была по крайней мере.

Ещё одним важным преимуществом относительно классического Saas является существенное снижение рисков. Все знают уже "дивный новый мир", в котором мы живём. Ломается всё, притом достаточно активно. За персональными данными идёт отдельная охота. Поэтому сервисы (да, те самые saas), которые хранят и обрабатывают персональные данные, будут привлекать отдельное пристальное внимание злоумышленников. Но утечка персональных данных ещё не самое страшное для этих сервисов. Хуже, если взлом может привести к полной остановке сервиса (кстати, не только взлом). А для Saas безопасность обеспечить сложнее - "VPN-ом не прикроешься". Поэтому любая уязвимость может стать фатальной.

   Для бизнесов, которые это понимают, решения, подобные нашему, являются "просто кладом":

•  OnPremise - перс.данные за семью печатями за VPN
•  Может поддерживаться любыми специалистами по 1С даже если по какой-то причине вендора задавил автобус вендор покинул рынок

Кроме функциональных характеристик для развитого бизнеса надо учитывать нефункциональные, который главным образом касаются двух понятий: стоимость и безопасность в широком смысле этих слов. Под стоимостью в том числе понимается стоимость владения (в т.ч. OnPremise) а под безопасностью в том числе отсутствие Vendor Lock. И вот тут как раз классическим Saas очень трудно с нами конкурировать. 

Но в современном мире есть ещё одна категория ПО. Я бы назвал их "Платформенными Saas". Обычно они появляются в рамках "развития экосистемы" - когда у одной компании есть множество продуктов в схожих сферах со схоими интерфейсными компонентами (ничего не напоминает, правда?). Примерно как у 1С. Вы будете смеяться, но и внутри у них разработка всё больше напоминает классчиескеи процессы разработки в 1С. Есть команда, которая "разрабатывает базовую платформу" (об этом ниже) и транслирует процессы разработки командам, создающим продукты. Это удешевляет разработку продуктов в разы (если не в десятки раз), но в обмен на это приходится "платить" интерфейсом. 

Специфичный интерфейс, конечно, допустим для узкоспециализированных решений (ERP\HRM\Accounting) системы. Но вот именно для личного кабинета - вопрос весьма спорный. Хотя любой интерфейс это, конечно, дело субъективное и очень очень сложное. Тем не менее, мы считаем одним из главных преимуществ тот факт, что интерфейс EmplDocs от и до прорабатывается дизайнером и не ограничен возможностями и функциональными решениями той или иной платформы.

Команда и процессы

Дневник был бы, конечно, не полон, если не рассказать про команду, которая всё это делает. Преувеличить свою роль в создании данного продукта, наверное, будет не очень уместно. Рассказывать о конкретных людях тоже. Поэтому я, пожалуй, сосредоточусь на архитектуре команд, потому что это важно для любого продукта.

Писать о банальных вещах будет, наверное, скучно, можно перечислить, что, как и большинство, мы используем:

• Agile (Kanban, регулярные: дейли, обзоры, наполнения, ретроспективы) - для управления проектами и продуктом
• Jira -  для задач, confluence для внутренней документации
• Zoom - для внутренней и внешней коллаборации
• Miro - для различных продуктовых задач
• EDT - для разработки 1С, VS Code и WebStorm для Web разработки
• Gitlab - в качестве репозитория кода Gitlab CI для CI\CD процессов
• GitFlow - для организации разработки + CodeReview
• GitBook - для организации пользовательской документации
• iSpring - для организации курсов сотрудников и партнёров
• Postman - для тестирования фронтенд части, документирования API и API First подхода

Что такое API First? Мы используем при разработке (при добавлении массового функционала) подход, при котором сначала пишется API, создаётся Mock сервер, после этого backend может работать отдельно, фронтенд - отдельно. Никто никого не ждёт. Одновременно получаем готовое описанное API (в формате OpenAPI) и простые тесты. Меньше зависимостей - быстрее разработка, ну и дешевле, конечно... 

Команда полностью распределенная. Мы любим офис, но он не является чем-то необходимым для обеспечения эффективности работы.

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

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

Есть отдельные команды продаж и маркетинга, естественно, потому как без этих людей трудно говорить о каком-либо коммерческом продукте. Тем не менее, эта часть, наверное, пока не является нашей главной сильной стороной. Возможно, потому, что популярное мнение "хороший продукт продаёт себя сам" было свойственно и мне в том числе.

Естественно, в EmplDocs нет отделов и департаментов, а также какой-то строгой иерархии. Все члены большой команды EmplDoсs организованы в команды поменьше. В соответствии с общими практиками по 5-9 человек в команде. Не всегда, конечно, получается придерживаться рекомендуемой Agile численности, но так или иначе мы исправляем несоответствия.

При организации команд мы придерживаемся так или иначе определенной логики, которую иллюстрирует эта картинка:

Она, конечно, немного страшная, но давайте разбираться:

Stream-Aligned Team - команда, которая несёт ценность клиентам непосредственно, или команда, которая внедряет клиентам EmplDocs (или обучает, или поддерживает, дорабатывает)

Platform Team - для нас, конечно, несколько громко сказано, но команда, которая организует саму "платформу", в т.ч. DevOps, вернее, конечно, DevSecOps процессы, процессы разработки и т.п. Enabling Team привносит что-то новое как в стек, так и в продукт. У нас эти функции выполняет одна команда, но смысл не потерян

В целом эта конфигурация сокращает когнитивную нагрузку относительно классической организации, но ещё есть над чем работать.

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

Финансы и эффективность

Конечно, первый вопрос, который возникает при мысли "запускать или не запускать" - вопрос финансовый. 

Большинство стартапов не становятся "единорогами", в том числе и среди классических Saas. 

Стоимость разработки, конечно, ключевая статься затрат, но по сути только на первом этапе. 

Её рассчитать не так трудно и в целом можно подготовиться "на входе". Более того, очень неплохо в этом помогает такой инструмент, как MVP.

Стоимость MVP рассчитывается достаточно легко и это по сути и есть стоимость проверки гипотезы. При внедрении MVP кому-то из "early adopters" возникает, конечно, дополнительная сумма затрат, которая уже чуть менее управляема. Но если early adopters - это компания вашей группы или холдинга, то в целом затраты воспринимаются как некоторый текущий проект, особенно если подобных решений ещё нет на рынке (а вот если они есть и устраивают - уже повод задуматься).

Дальнейшая важная часть - масштабирование. В нашем случае были достаточно крупные ошибки, которые назывались: "клиенты есть, клиентов много, клиенты платят - значит, вы в шоколаде". Клиентов всегда будет много, если вы будете продавать то, что стоит 200 рублей за 100. Но это совсем не значит, что у вас прибыльный бизнес и хороший продукт. Ценовая политика, учитывающая себестоимость, очень важна.

При этом под себестоимостью я понимаю именно полную себестоимость. Нам в этом отношении повезло - финансовый учет достался в наследство. Во многом это помогло вовремя осознать и скорректировать ошибки (если "вовремя" можно назвать дельту в несколько месяцев).

И самое главное - что отличает нас от классических Saas в худшую сторону - совсем другая маржинальность. Разработать продукт, который "внедряет себя сам" и грести деньги лопатой, наверное, мечта многих, но получается совсем у единиц, мы к ним, к сожалению, не относимся. Лицензии продавать, конечно, приятно, но их стоимость определяется рынком. Сделать их намного дороже не получится. А внедрение - классический проектный бизнес, который в плюс ко всему ещё и достаточно конкурентный. Кроме того - есть риски, есть неопределенность. Поскольку у нас большинство команды из мира 1С, у нас несколько меньше проблем с этим, но отрицательная маржинальность внедрений, особенно первых проектов, у нас присутствует. С этим пришлось столкнуться, и этот фактор "ожидаемо-неожиданный".

Но ещё одна "ожидаемо-неожиданная вещь", следующая из проектной специфики: на начальном этапе чем больше продаж - тем больше операционный минус. Почему? Всё просто:

Новая продажа = новое внедрение = нужная команда = команду нужно нанять и подготовить ещё ДО продажи.

Это было достаточно неожиданным откровением. Даже если контракт предоплатный (что не всегда получается), проектный бизнес часто требует финансирования наперёд.

И самое интересное, что стоит знать про современные финансы - ключевая ставка в 19% совсем не способствует развитию бизнеса :).

Тем не менее, КЭДО - растущий рынок - "все там будем". Расти на таком рынке, конечно, несложно, главное обгонять сам рост рынка за минусом инфляции, иначе идея выглядит уже не такой перспективной. 

Радует в этой всей истории одно - худо-бедно, но мы научились жить с крупными проектами и крупными внедрениями. Ростом мы обгоняем рост рынка, на котором крупные компании только начали переходить на КЭДО. Это получится далеко не у всех Saas. 1С-ная школа хорошо подготавливает к правде жизни :)

Что будет в следующих частях

На этом, наверное, всё в этой части. О чём ещё мог бы рассказать - специфике проектов, как мы обращаемся с релизами и боремся с багами.

Как организуем документацию и обучение аналитиков. Как мы организуем Code Review  и Perfomance review. Какие у нас новые успехи и неудачи. Верю, что статья не превратится сугубо в мой дневник и послужит кому-то мотивацией к созданию нового продукта, пусть и в непростое время.