В 2018–2019 году мы уже догадывались, что нужно какое-то импортозамещение, потому что как-то немного странно, что Росатом зависит от зарубежного вендора. Джира проникала в структуру незаметно и понемногу, и в какой-то момент оказалось, что на ней ведутся многие проекты кроме строительства АЭС и других объектов. И речь не про ИТ-проекты, а вообще про все проекты, которые у нас есть.
Пару лет мы лежали в сторону поиска аналога (которого на самом деле нет).
1 февраля 2021 году Atlassian объявил о прекращении поддержки серверной версии. Решили запланировать переезд в дата-центр, но увидели, что это такой хитрый способ поднять цену в полтора раза. Стало грустно, но аналогов на рынке всё ещё не было.
Потом был технический сбой на 2 недели. Люди за 2 недели потеряли свои данные. Стало ещё грустнее.
Потом пришло письмо счастья, что аккаунты РФ будут отключены. Но сроки не обозначили.
В общем, мы опять огляделись в поисках аналогов для проектов нашего масштаба, взяли решения нескольких вендоров для сравнения, чуть не сошли с ума от прекрасных стратегий их продажи и доработок продуктов прямо во время презентаций, плюнули и написали своё отраслевое решение. Которое ещё и предлагаем другим российским компаниям.
Что пошло не так с Джирой
Во-первых, она произведена не здесь.
Во-вторых, они поднимали цены, нарушали работу сервиса и под конец сообщили, что прекратят поддержку российских аккаунтов.
В-третьих, у них там есть пара фатальных то ли уязвимостей, то ли ставших известными бекдоров, которые существенно снижают безопасность без внешних патчей или прикрытия умными файрволами.
В-четвёртых, у нас появилась идея окуклиться в своей серверной версии в замкнутом контуре за DMZ. Вроде бы отлично, у нас есть хорошая команда поддержки, хорошая команда разработчиков, где-то костыликом подопрём, где-то в свою разработку уйдём.
А надо сказать, что к нам иногда приходят друзья и коллеги из ФСБ. Всё-таки мы Росатом, без таких друзей и коллег работать не получится. И вот они сказали, что уязвимости по их анализу там такие, что лучше всё это сразу закопать. Если кому-то интересно, они критичные уязвимости публикуют в реестре в открытом доступе: можно посмотреть актуальные известные им дыры в корпоративном ПО разных версий.
В-пятых, примерно в это же время нас поразил плагин draw.io: мы однажды заходим после обновления в Confluence, открываем очередную схему, а там пусто. Он ничего нам не сохранил.
В общем, терпеть было нельзя и надо было переходить на отечественное решение.
Отечественные решения откровенно лажали
Мы большие. В смысле, реально очень крупная компания с не менее крупными проектами. Мы хорошо документируем все проекты, потому что у нас есть собственные стандарты того, как не надо делать разработку AS IS, чтобы потом про наши объекты не снимали по два сериала на инцидент. Так вот, с такими размерами проектов никто на российском рынке просто не работал. Ну или делали вид, что работали, но по факту переварить такое количество задач и пользователей не могли.
Нам важно, чтобы и таск-трекер, и база знаний были вместе. Обычно на российском рынке либо то, либо другое. Либо криво прикрученная Вики к таск-трекеру. И это чаще всего даже не система управления проектами, программами, портфелями, а это просто таск-трекеры. Там есть задачки, есть канбан-доска, и, будет здорово, если там ещё гант окажется, вообще бинго, джекпот.
У проектов начиная от обслуживания атомных ледоколов и заканчивая разработкой роботов разные методологии. Их надо настраивать по-разному, у них разные процессы и разные автоматизации. Каждый взаимодействует со своими системами своим собственным образом.
У решений были очевидные плюсы, но идеально подходящего не нашлось.
Самая частая проблема — то, что каждый проект ведётся отдельно. Например, нет сквозного поиска между проектами, нельзя импортировать бизнес-процесс из соседнего проекта, нельзя взять какой-то объект. Банально, если вам надо собрать отчёт по проектам в Томске, у вас никогда не будет сводной статистики — у вас будет 20–30 записей отдельно, и склеивать их придётся вручную в Экселе. А нам нужно много сквозной аналитики, и мы постоянно соединяем данные с разных проектов.
Ещё у нас 15–20 тысяч задач в одном проекте, а есть проекты и по 150–200 тысяч задач. И это часто просто убивало имеющиеся системы, потому что они не могли достаточно масштабироваться, чтобы это переварить.
Поэтому часть решений не прошла этот отбор, дальше внутри системы у нас в Atlassian велись абсолютно разные проекты.
Ещё нам хотелось удобный и понятный интерфейс. Наши пользователи довольно избалованные, им нужно, чтобы было красиво, просто и понятно. Потому что внутри мы именно так и делаем. Ну, по крайней мере, стараемся. Им важна оперативность устранения ошибок, например, а не сидеть и смотреть 30 секунд, как что-то грузится.
Нам нужна была техподдержка — первая, вторая и третья линии. На пилотах мы загружали по 100–150 задач за пачку, и даже это часто роняло возможности поддержки, потому что при ошибках каждый отдельный пользователь пытался дозвониться и понять, что случилось.
Нам нужны были интеграции с огромным количеством наших корпоративных систем.
Всё это мы вынесли в техтребования, отдали российским компаниям, сгенерировали несколько тестовых проектов со случайными данными — но с валидаторами, кастомными полями, разными наворотами, разными типами задач и так далее. Дальше мы пробовали это мигрировать из Джиры в систему вендоров, которые участвовали в предзакупочной процедуре.
Если очень коротко, выяснилось, что все системы заточены под простые типовые проекты. Где-то совершенно ужасный интерфейс с точки зрения полезности представления (например, нужно найти все задачи с меткой «срочно», захожу в поиск во всех проектах, а у меня эта метка «срочно» в каждом проекте как отдельный объект — и на выходе портянка на 50 экранов, в которой поиск идёт по каждому ��тдельному проекту, и просто понять, что уже горит и как, невозможно).
Ещё одна особенность — у нас кросс-проектная команда. Человек может быть на 0,25 в одном проекте и на 0,75 в другом, иметь разные роли и так далее. Нужны сквозные функции для управления всем этим.
У кого-то была ужасная поддержка: например, мы при миграции репортили ошибки со скриншотами, а нам даже не отвечали, что взяли их в работу. Я на своём опыте боюсь даже представить, что случится, если мы не будем отвечать нашим пользователям или если бы мы им отвечали так же долго, как некоторые.
Ну и вишенкой на торте стали скрытые платежи. Некоторые решения нам всё же понравились, и вендоры обещали их доработать. Ок, доходим до коммерческого предложения, а там система делится на модули. И нам в базовом расчёте в конкурсе дали два базовых с обрезанным функционалом. Начинаем считать полный, а там ещё 2 нолика приписались. И так плюс-минус везде, начинаем получать детализацию — выясняется, что надо доплатить за каждый чих. Кто-то не мог предоставить техподдержку: например, нужно учитывать часовой пояс. Или формально техподержка есть, но не более 10 запросов в месяц — остальное за дополнительную плату. В одном из коммерческих предложений у нас были пересечения только на 2–3 часа в рабочее время с некоторыми филиалами, и это не давало полноценно пользоваться поддержкой. Вендор считал такую ситуацию нормальной.
Или вот история. Как-то к нам пришли разработчики, провели демонстрацию, мы посмотрели их систему. Говорим, по функционалу очень сильно отстаёт, очень долго доделывать, наверное, не подходит. Вроде бы мирно разошлись. Через какое-то время мне присылают ссылку на телеграм-канал, где этот чудесный разработчик анонсирует, что они чуть ли не внедряют свою систему в одной ОЧЕНЬ БОЛЬШОЙ компании, которая занимается атомной промышленностью, но название они говорить не могут. Ну да, у нас же в стране очень много таких компаний. А потом смотрим на их сайт, а там уже наш логотип, уже наше название в качестве заказчиков. Мы, конечно, привлекли юристов, этот вопрос решился достаточно оперативно.
В результате длительного конкурса в качестве победителя был выбран null.
В общем, рынок нас опечалил. Ничего такого, что хотелось бы внедрять, не было.
«Ну напишите сами тогда, если такие умные»
Собственно, оценивая затраты на доработку того, что было, и собственную разработку, внезапно выяснилось, что если у нас будет ядро системы, то всё остальное окупится. То есть если бы нашлись опенсорсные решения с подходящими лицензиями, которые можно было бы форкнуть и дорабатывать у нас, — это было бы прекрасно с точки зрения рациональности проекта.
Они нашлись. Что удивительно, даже удалось соблюсти все условия лицензии, здесь мы очень нагрузили юридический департамент.
Основные компоненты из OpenProject, Nextcloud, OnlyOffice.
Проблем с опенсорсом две: во-первых, вы не можете выбрать стек разработки (в нашем случае это Ruby on Rails), во-вторых, потом всё то, что вы соберёте, надо как-то сертифицировать у ФСТЭК.
С рельсами проблема в том, что в какой-то момент все разработчики куда-то делись. Но мы посмотрели по рынку и выяснили, что явление почему-то было временным и сейчас они то ли вернулись, то ли появились ещё откуда-то. Рынок наполнился специалистами снова.
ФСТЭК же фактически фиксирует ядро в каком-то статичном состоянии, и если вы хотите внести апдейт, нужно проходить сертификацию заново.
Мы форкнули OpenProject, но участвуем в сообществе, мы официальные community member, имеем возможность сами заводить задачи, выполнять задачи других участников. Как мои разработчики смеются, что это очень странно работать на госкорпорацию и коммитить в опенсорс. Мы не обрубили все концы по обновлениям, время от времени смотрим, что хорошо дружит с нашей версией, и втягиваем.
Надо сказать, что у нас очень много кастомных требований. У Atlassian есть маркетплейс плагинов, и мы им активно пользовались. Например, был темпо-таймшипт, у нас там фиксирование трудозатрат, их планирование. Там, где плагинов не хватало, многое мы делали через скриптранер (на Groovy). Часто это были костыли. В новой системе многое из того, что обходилось костылями на скриптах, сразу же стало особенностями ядра — мы убирали мешающие ограничения. Например, банальная вещь — попробуйте быстро и просто разделить один проект на два подпроекта. Вас ждёт много интересного в стеке Atlassian.
Важно было ещё отвязать решение от окружения. Из-за импортозамещения не очень понятно, что будет завтра. Какие базы данных, какие ОС, какие браузеры. Лучше уж расширить варианты того, с чем может работать система, а то если инфраструктура сменится, пользователи будут вынуждены искать IE 6.0, чтобы вставить флешку с ЭЦП. Мы такого точно не хотим ) И новых шагов миграции не хотим.
Сейчас платформа включена в реестр российского ПО (реестровая запись от 08.02.2024 № 21435).
Миграция
Дальше встал вопрос миграции. Мигрировали мы в новую систему постепенно. Не нужно приходить в понедельник утром, брать рубильник, отключать всё и говорить: «Добро пожаловать!»
Никому не понравится, правда.
Так долго растягивали миграцию по простой причине, потому что для каждого проекта выбирали удобное время. Это какой-то релиз, окончание спринта, это помогло нам разгрузить нашу техническую поддержку и тренеров, которые проводили обучение сотрудников. В план миграции мы за эти полгода безостановочно, без единого дня простоя, без единой потерянной точечки перенесли всю информацию уже в свою систему.
Всем советую, прошло на удивление гладко.
Мы обычно переносили те данные, которые есть на текущий момент, например, в начале спринта, и потихонечку обучали команду на этих данных в течение пары-тройки недель, пока шёл спринт. А потом уже команда привыкала, что нужно сюда кликнуть, вот здесь посмотреть, что это вот так оказывается работает и это даже прикольнее чем было. Потом мы довносили в систему только ту дельту, которая произошла за эти 2–3 недели. Конечно, это вызывает нагрузку на поддержку, год мы поддерживали сразу две системы. Но сейчас полегче, потому что Джира и Конфа уже выведены из эксплуатации.
В итоге перенесли больше 2 тысяч проектов, более 50 тысяч активных задач и в целом больше 200 тысяч задач, которые не в фазе работы.
Конечно, пользователи не очень любят что-то новое, да никто особо что-то новое не любит. Это нужно заново привыкать, адаптироваться, подстраиваться. С одной стороны, жалоб у нас было меньше нормального количества, потому что пользователи знали, что вариантов выбора у них ровно два: либо документы от руки, либо новая система. Никто не настаивал, но поскольку есть много связанных проектов, вручную документы готовил бы целый отдел. Кто-то поначалу пробовал вести учёт задач и документацию в офисных пакетах, но довольно быстро они поняли, что лучше уж разобраться с новой системой.
Второй важный аспект — мы собрали для пользователей комьюнити. Это такая штука, куда сотрудники могут заходить и задавать вопросы, общаться между собой, предлагать новые функции. Можно голосовать за приоритет задач в беклоге. Функции с наибольшим количеством голосов попадают в следующий релиз автоматически.
И тут случилось чудо. Пользователи стали бороться не с системой, а за свои доработки. Появилось сарафанное радио, появилась политика, и, самое интересное, что те, кто голосовал за функции, считали их своими. И рассказывали про них коллегам. «Смотрите, смотрите, там в системе моя функция, я сделал, сейчас будет так удобно, так здорово, я вам всё покажу, ещё и вас научу этим пользоваться». В общем, мы стали руками для проектных руководителей.
Особенности решения
Третьей важной частью задачи была возм��жность вынуть данные из системы. Элементарно для бекапа или миграции. Какие бы вы ни выбрали пути, которыми вы хотите пойти, всегда нужно иметь с собой маленький чёрный чемоданчик, который вы в любой момент возьмёте и из этой системы раз и навсегда уйдёте. Да и бекапы должны быть в читаемом формате.
Кстати, если вы когда-нибудь пробовали смотреть бекапы Atlassian, то с радостью сообщу, что они читаются только продуктами Atlassian. И если вам заблокировали аккаунт, то развернуть вы его можете примерно нигде. У одного из внешних заказчиков сертификат безопасности просрочился, и они на 2 недели вывалились из работы и потеряли свои данные. Очень повезло, что мы им тогда делали тестовую миграцию, они прибежали и: «Вот то, что вы перенесли, можно мы используем дальше в работе?» — и мы им конвертировали их же бекап. Если что, там у людей были госзакупки, контракты, деньги, горели сроки — и такие эксцессы могут вызвать глобальные задержки.
Благодаря комьюнити мы увидели, как люди согласовывают документы перед сдачей проекта в эксплуатацию. Вообще в Atlassian есть плагин, позволяющий работать с офисным пакетом документов вместе, но он не прошёл нашу безопасность. И оказалось, что раньше в Confluence люди шарили экран на видеоконференции и вместе правили. Медленно и печально. Мы им прикрутили удобный мультиплеер в модуле для работы с документами, и теперь они видят курсоры друг друга и очень радуются. Сразу скажу, что стандартные решения не всегда подходят, потому что если вы когда-нибудь загоняли в 100-страничный документ 25 человек, каждое действие которых меняет разбивку на страницы, то примерно понимаете, о каком аде может идти речь. А ещё ведь надо делать нормальную историю версий и возможность работать с каждой правкой.
Потом нам понадобился хороший поиск. Поиск должен осуществляться не только в темах и описании задач, но в кастомных полях, комментариях, внутри документов, в теме документов, везде, в совещаниях. Потому что иногда пользователи приходят и говорят: «У меня была какая-то задача или документ, но я не уверен. Даже не знаю в каком конкретно проекте» — надо, чтобы он нашёл по тому, что помнит.
Сделали много независимых настроек для каждого проекта. Хотите спринты, канбаны, хотите водопады, хотите ещё что-то. Любые подходы. Это помогло нам внутрь системы привлечь те направления, которые раньше про Джиру даже не знали и не думали туда заходить.
Очень хорошо получилось с совещаниями. Старый стандартный процесс был такой: ставим встречу в календарь через почту, туда пишем повестку в Джире. Во время встречи можно прям отмечать галочками прогресс по повестке. Мы эту систему расширили, потому что раньше пользователи искали, что было на совещании, в почте. Теперь мы прямо из Атом.Проекта даём возможность создать встречу с повесткой, к задаче крепить совещания и сразу смотреть, что на них было. Можно сделать срез — какие у нас были совещания по этому проекту. Ага, вот списочек, вот об этом договорились, вот такие задачи созданы, вот сейчас они в таком состоянии, а вот тут надо обсудить, но ещё не обсудили.
Как попробовать
Мы можем дать демодоступ. ПО серверное, устанавливается в прод-версии на серверах заказчика, может устанавливаться и работать в закрытом контуре без доступа в интернет. Это потому что мы госкорпорация, нам в облако нельзя. Из коробки есть в том числе интеграция с GitLab и GitHub.
У нас сейчас есть демонстрационный контур, он вынесен вовне и доступен из интернета. На наших мощностях работать не даём, потому что мы за безопасность. Всем спокойнее спится, если ваши данные хранятся у вас. Ну и несмотря на то, что система разработана в госкорпорации, есть партнёры, через которых мы без огромного количества бумаг работаем.
