Как стать автором
Обновить
0
EvaTeam
Замена Jira, Confluence, Jira Service Management

Как рынок заставил нас сделать аналог Jira (расшифровка аудио записи)

Уровень сложностиПростой
Время на прочтение11 мин
Количество просмотров6.7K

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

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

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

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

Это пример задач за год, которые мы тогда вели на бумажках
Это пример задач за год, которые мы тогда вели на бумажках

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

Интерфейс ИС «Поток» - системы собственной разработки и первой попытки нормально организовать управление
Интерфейс ИС «Поток» - системы собственной разработки и первой попытки нормально организовать управление

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

Интерфейс нашего vTiger: тут и задачи, и сделки, и всё на свете
Интерфейс нашего vTiger: тут и задачи, и сделки, и всё на свете
А ещё у нас была "Агата", которая следила за сроками задач
А ещё у нас была "Агата", которая следила за сроками задач

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 просто тут обвязала своими щупальцами всю Россию, и хочет остановить нам работоспособность огромного количества системообразующих и просто огромных предприятий.

Как Atlassian уходил с рынка
Как Atlassian уходил с рынка

Мы решили, что мы такое не допустим. Перешли на 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% стартапов на этапе начала разработки разрабатывали совсем другой продукт, и их рынок потом утащил в другое место". И мы почувствовали это на себе. Вот как-то так, товарищи.

Теги:
Хабы:
Всего голосов 10: ↑9 и ↓1+11
Комментарии6

Публикации

Информация

Сайт
www.evateam.ru
Дата регистрации
Дата основания
2000
Численность
101–200 человек
Местоположение
Россия

Истории