Всем привет! Это ламповая история от основателей компании – рассказ о хронологии замены Jira, а также о том, как собственные разработки помогают при создании будущих сервисов. Всё что идёт ниже – расшифровка аудио с небольшой редактурой, которая записана мной. Все совпадения случайны, трюки выполнены профессионалами, за русский язык ногами не пинайте.

В начале описана общая история компании, которая поможет разобраться "что-как", затем про технологии. А на сладкое - как рынок иногда сам подсказывает куда нужно идти.

Как все начиналось 

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

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

На этой системе мы просидели буквально полгода, потом нашу компанию разделило на две. В Карбон Софт (новом юрлице) ИС «Поток» использовать не стали, потому что уходило много кодерского времени на поддержку. И мы перешли на SugarCRM, а если конкретнее, то на vTiger. Страшно сказать, но это уже было больше 10 лет назад.

vTiger, как внутренняя система, дала очень много в понимании автоматизации - как её лучше делать, что вообще требуется, какие есть грабли. По мимо этого наша команда достаточно хорошо разбиралась в автоматизации «1С», Terrasoft и, конечно, Jirа. Правда у Jira тогда была уж очень слабая автоматизация и ещё не появились плагины.

Учитывая недостатки ИС «Поток», «1С» и Sugar CRM, бродила идея, что, как только время появится, можно создать движок со своим ORM (Object-Relational Mapping), на котором можно создавать большие бизнес-продукты. Время появилось только в 2016 году, когда мы сделали первую версию CMF (Content Management Framework).

Недостатки существовавших систем 

Самый тяжелый недостаток систем, которые мы использовали – это невозможность обновления после кастомизации. Это прям самая большая боль. В Jira, кстати, это уже не так. Там, в принципе, это нормально обвязано и кастомизация как бы находится сбоку. А вот если ты SugarCRM или «1С» заточил под предприятие... То, когда нужно обновлять их, ты должен вызывать тех кодеров, которые делали заточку. А после обновления весь этот код перелопачивать, чтобы он заработал. Это отсутствие кастомизации, отсутствие модульности – это одна из главных проблем на тот момент, которая не позволяла полноценно развивать используемые программы.

Например, хотим обновить сейчас Sugar CRM, на которой у нас ещё завязаны некоторые процессы. Без перелопачивания всего кода, у нас это не выйдет (рассказчик грустно вздыхает). В новой «1С» мы больше такого не допускаем. Потому что перестали напрямую в ней делать какие-либо кастомы, все выносится в отдельные внешние модули-обработчики. Поэтому «1С» сейчас можно смело обновлять и внутрь больше ничего засовывать не будем. Однако это менее комфортно, менее удобно. Не можем дополнительные поля сделать, не можем какие-то удобные кнопочки добавить. Больно без этого. Очень больно. Но зато в будущем сможем нормально «1С» обновлять. Все таки она без апгрейда – нерабочая.

Ещё надо отметить схему построения модели. Когда ты делаешь кастомизацию, это оказывается не так просто. В «1С» она удобная, но там свой язык, который надо изучать, поддерживать и так далее. Для корпоративного продукта свой язык – это значит что нужны определенные кодеры, которых может ещё и не быть на рынке.

В SugarCRM, там архитектура больше веб-сайтовая, там нет бизнес-объектов, совсем уж тривиальный ORM. Это очень простой софт. Даже слишком простой. Поэтому, если взять все плюсы Sugar CRM, «1С» и «Битрикса», например, а потом выкинуть все минусы, то можно разработать свой движок CMF. Который мы назвали Carbon CMF. По сути, этот движок был спроектирован в 2016 году.

Создание своей CMF 

Проектирование фреймворка: то есть ORM-модель, структура приложения, принцип подключения модулей, айдишники, базы данных, API — все это разрабатывалось сразу же под некий большой универсал. Чтобы, условно говоря, можно было хоть с SAP R/3 конкурировать, хоть с Oracle Application. Исключить большие ограничения вверх, чтобы на этом фреймворке можно было разрабатывать приложения любого масштаба. В этом фреймворке сразу же рассчитывали на большие Enterprise-решения. При этом не забывали что есть ещё и малый бизнес со своими потребностями. А когда разработали CMF, стали клепать приложение.

SAP ,Oracle, «1С». У них объектная модель во многом такая же — очень мощная. Мы хотели достичь… точнее сказать, найти компромисс между мощностью объектной модели, её удобством, и при этом оставить легкость программирования. Поэтому мы оставили язык Python как базу для автоматизации и программирования. А объекты сделали такими, которые можно бесконечно расширять, максимально соответствуя идеологии объектной модели. По сути, совместили объектную модель Python и бизнес-объекты, и реализовали это у нас как один объект. Например, задача — единый объект: и с точки зрения бизнеса, и с точки зрения Python. За счет этого ей очень удобно пользоваться.

Наша объектная модель, с одной стороны, сложнее, конечно, чем в Django или, например, в SQLAlchemy. Но зато она позволяет не делать всякие колхозы для того, чтобы превратить тонкие модели — в бизнес-модели. У нас сразу же ORM создает бизнес-модели. То есть они реализованы с возможностью автоматизации и построения на этих объектах сразу же больших бизнес-приложений. Чтобы можно автоматизировать предприятие любого размера, делать любые дополнительные модули и бесконечно его масштабировать. Это все было учтено при проектировании этого фреймворка.

Ещё интересно посмотреть на историю систем, которые уже упоминались. «1С» начал с того, что он сделал себе движок с базой данных и с языком. И это абсолютно типичная ситуация. Мы сделали то же, но в качестве языка взяли Python. Просто расширили его — сделали свой более бизнесовый ORM, чтоб можно было получать готовые бизнес объекты простыми запросами без SQL (в чем то подход схож с DDD).

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

То есть у нас структура проекта, структура приложения немного отличается от стандартного Python-приложения, чтобы быть более гибкой.  Такое использование ORM делает разработку проще, так как закрывает от программиста базу данных и избавляет от сложных join и т.п. И поэтому ему не нужно задумываться о правильности всяких запросов. Он может очень быстро разрабатывать и не отвлекаться.

Почему теперь мы всё быстро разрабатываем? Да потому что фреймворк изначально разрабатывался для так называемой RAD-разработки (rapid application development). Движок мы разрабатывали с 2016-го по 2020 год, и сейчас он постоянно развивается и совершенствуется. Он 7 лет в боевой эксплуатации на разных продуктах. Серьезный взрослый движок уже.

Эти особенности дали в будущем большой плюс, который помог при быстром импортозамещении. На таком фреймворке скорость разработки в 3-5 раз быстрее, чем на каких-либо других. Если сравнить типичные Django, Flask, стандартный Python, то у нас очень высокая скорость разработки. 

По сути, мы сделали подход «1С», но на Python. То есть объектная модель через точку и все в таком духе. Весьма удобно.

t1=CmfTask.get(code='bug-45')
t1.project.name
t1.status.status_type.name

Пример модели с точкой

Мы сделали фреймворк, на котором можно строить большие и сразу же продуманные приложения. Чтобы они были масштабируемые и кластеризуемые. И сразу же задумались о том, что мы создадим на основе этого движка несколько продуктов. Первыми из них стали Task Manager, Wiki-система похожая на Confluence и CRM-система.

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

Процесс разработки и осознание потребности рынка 

К 2020 году у нас начал формироваться некий комбайн, который позволяет обвязать обычное предприятие различной автоматизацией. Но пока не IT-отдел. Вообще, изначально все продумано: то есть все сущности, объекты бизнесовые, толстые модели, возможность автоматизации, тюнинга — все это изначально закладывалось в движке. Потом поверх этого можно было под конкретную отрасль или под конкретную задачу все это дело очень быстро создать. Ну и быстро напилить веб-интерфейс. Примерно к середине 2020 года начали обвязывать все наши отделы и заменять сторонние продукты. В 2022 году мы ещё получили грант РФРИТ в рамках федерального проекта «Цифровые технологии» национальной программы «Цифровая экономика», который позволил расширить команду проекта. А к маю, у нас уже пошел уклон в сторону какого-то баг/таск-трекера напоминающего Jira.

Если честно, при этом в начале не было понимания выстрелит это или нет. То есть как максимум, мы бы залезли в конкуренцию с каким-нибудь Битриксом и всё. Отжали бы у них процентов 20-30 рынка. Но в итоге получилось что мы разработали супергибкий движок, благодаря которому смогли вовремя свернуть и легко перейти из конкуренции с Битриксом, в сторону импортозамещение Jira.

Просто взяли и перешли на "Джиру" без проблем.

Весной прошлого года, появился интересный спрос от клиентов. Рынок начал подозрительно шевелиться, а мы к нему прислушиваться и общаться с клиентами. Пришло неожиданное понимание, что наша система очень уж похожа на Jira. И мы начали ее модифицировать всё ближе к зарубежному продукту.

В марте 2022 года сначала подумали «Jira, да кому она нужна». Но всё же решили прощупать тему. Наш отдел маркетинга начал исследовать, работать с нашими партнерами, выяснять объем рынка, выяснять по предприятиям, и плюс сами предприятия стали на нас выходить. И мы увидели, что рынок не просто большой, он огромный. Jira просто тут обвязала своими щупальцами всю Россию, и хочет остановить нам работоспособность огромного количества системообразующих и просто огромных предприятий.

Мы решили, что мы такое не допустим. Перешли на 12-часовой рабочий день (многие менеджеры даже больше работают) и просто целый год работали с четверной нагрузкой. Решили выпустить такой продукт и замещать Jira, чтобы не допустить остановки производственных процессов у компаний, попавших под удар. Ну и в принципе, мы сделали такой продукт, который позволит не останавливаться производственным предприятиям и импортозаместиться.

В марте мы еще только думали о таком развитии, а в апреле, когда плотно пошли общения с клиентами, знакомыми предприятиями и разными менеджерами, мы решили — это сегмент и надо в него заходить. Тем более, что продукт очень быстро можно поправить, и дальше только плагины надо будет допиливать. Приняли решение о том, что нужно полностью менять дизайн и отчасти внутреннюю архитектуру, чтобы максимально удобно можно было соскакивать с Jira на нашу систему. Даже вынуждено сделали на время уклон в сторону именно IT. Но в целом, это был аналог Jira и Confluence. Потом уже решили, что надо вообще весь стек Atlassian заменять. Ведь у нас движок позволяет быстро разрабатывать другие приложения. Но для начала занялись именно Jira и Confluence.

По сути, продукт на тот момент на 80% архитектурно позволял стать аналогом Jira. Только дизайн был другой. Поэтому быстро поменяли дизайн, некоторые объекты привели в большее соответствие с объектами Jira (хотя, они и так были очень похожи).

Сначала переделали модуль документов, более-менее нормально его выпустили, и стали потом уже что-то добивать. Модуль "Jira" переделывали дольше, но тоже переделали. Кстати, бизнес-процессы и прочие важные функции у нас были готовы к июлю. В августе мы уже ACL напилили. То есть мы буквально за два месяца сделали существенное изменение продукта, просто гигантское, и стали похожи на Jira по внутреннему устройству. Ну, и дальше уже поняли, что это тренд, и надо добивать. Работали целый год, и вот получили продукт, который уже для малых и средних предприятий покрывает Jira на сто процентов. Для больших предприятий основной функционал готов, но там всегда есть свои требования, под которые можно гибко подстраиваться. 

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

Часть клиентов, у кого лицензия Jira ещё не кончилась, стали заранее ставить пилоты. Кто-то сразу начал отделы переводить, чтобы, когда у них закончится лицензия, они могли остальных перевести партиями. Миссией стала помощь предприятиям и государственным организациям с переездом на российское ПО. Мы уже сделали продукт, который по малым и средним предприятиям на сто процентов замещает Jira и Confluence. По большим предприятиям основной функционал реализован, а дальше уже кастомные доработки и узкоспециализированные плагины. В общем постепенно спасаем компании. И наши партнеры нам в этом помогают. Это прямо круглосуточная работа. Мы пашем, пашем, пашем. Наши партнеры тоже пашут, их отделы интеграции пашут. Потому что, сами подумайте, Jira тут 30 лет интегрировалась, а теперь нужно за год-два, переводить огромное количество предприятий. Срок сжатый, нужно тридцать лет сжать в два-три года. Это очень сложно. Но пока мы за счет нашей команды и партнеров делаем всё возможное.

Стоит уточнить, что есть микро клиенты, с которыми мы общались, и которые переехали, например, на Яндекс.Трекер. В ходе такого общения выяснилось, что у них и не было привязки к продукту Jira. Это здорово что они могут так решить задачу. Потому что те, кто привязан к Jira и к ее модели, они вряд ли смогут переехать на подобное ПО. Потому что потеряют огромное количество функционала. Просто написать какой-то трекер, в котором задачи, доски и так далее – это несложно. А вот сделать, чтобы поверх всего этого была грамотная автоматизация, популярные и доступные технологии. И в целом понимание того, что вообще нужно большим предприятиям и так далее… Это уже не просто. 

У нас это есть, потому что мы долгое время занимались ERP для операторов связи. Примерно с 2004 года и до сих пор. Там есть такие автоматизации масштабные и крутые, что обзавидуешься. Но все это, конечно, в основном для операторов связи.

Тут кстати важный момент. Мы ведь технологию сначала создали. Как, например, «Яндекс». Знаете ведь для чего он сначала свой движок создал? У них search engine изначала был для обработки большого набора документов. Ему кидаешь кучу документов, он по ним проводит search, строит индекс, и ты можешь потом по этим документам быстро что-нибудь найти. А потом они решили: «А давайте попробуем это к вебке прикрутить». И прикрутили. И офигели как это кайфово. Так что, когда у тебя есть разработанная крутая технология, выходить на рынок гораздо проще. А у нас этих технологий много – и для управление облаками, свой супервизор и многое другое. Ну и конечно есть знания как на Linux вообще построить серьезные, большие платформы и ещё много чего. 

Тут есть такая интересная мысль: "Когда у тебя есть технологии и, например, фреймворк, а ты чувствуешь что не туда пошел, тогда ты можешь быстро сменить рынок и конечный продукт. Для этого можно срезать верхнюю часть продукта и разработать уже другой продукт. И, кстати, «Яндекс» здесь отличный пример. Вначале он не мог продавать свой продукт. Search engine по документам – кому он вообще нужен? Библиотекам каким-то. Но технология-то была. Взяли эту технологию, прикрутили к вебу, когда Интернет стал более популярен, и вуаля! Компания, обладающая технологическими преимуществами с точки зрения разработки, с точки зрения знаний и опыта, гораздо проще адаптируется на рынке. Поэтому когда возникла потребность напилить Jira за год, мы взяли все наши технологии и знания, применили их и вышли на этот рынок. Могли бы выйти на какой-то другой за счет этих же технологий и знаний, но вот тут этот рынок сам нас нашел. И за счет того, что наши технологии наработаны, есть готовый фреймворк и главное опыт, мы есть те – кто мы есть.

Тут можно сказать цитатой о стартапах (хотя мы уже давно не такие): "90% стартапов на этапе начала разработки разрабатывали совсем другой продукт, и их рынок потом утащил в другое место". И мы почувствовали это на себе. Вот как-то так, товарищи.