Александр Агапитов. Фотография: Xsolla

Основатель и руководитель компании Xsolla Александр Агапитов рассказал «Форбсу» детали о массовом увольнении сотрудников в пермском офисе компании. Агапитов также ответил на вопросы всех желающих во время пресс-конференции в Google Meet.

Основатель Xsolla назвал основную причину увольнений: компания перестала показывать 40-процентный рост. Чтобы компенсировать подобное отставание, в компании решили «убрать» 10 % сотрудников с наименьшими зарплатами.

Сильнее всего сокращения коснулись пермского отделения, поскольку там зарплаты гораздо меньше (2000 долларов в месяц или ниже), чем в США. Под увольнение попали в том числе два баристы, двое хостес. Такую ситуацию Агапитов охарактеризировал следующим образом: «Кажется, что людей много, но это самые низкооплачиваемые люди, которые отсиживаются».

Увольнения коснулись в большей степени линейных сотрудников, а не топ-менеджеров.

По информации Bleeping Computer, сбой у Atlassian в работе сервисов Jira и Confluence продлится еще две недели. Его причину разработчики выяснили 7 апреля, но инцидент зашел слишком далеко, чтобы его можно было быстро исправить.

По информации Bleeping Computer, Atlassian раскрыла причину запуска скрипта, удалившего данные части клиентов и вызвавшего глобальный сбой в работе сервисов Jira и Confluence.

Разработчики из «Ростелекома» и «Ростелеком ИТ» занимаются созданием собственной платформы корпоративных коммуникаций и управления под названием «Яга» для замены инструментария Atlassian, включая Trello, Jira и Confluence.

Думаю, в каждой компании есть необходимость где-то хранить различную документацию. Самый простой пример — регламенты работ в разных отделах, шаблоны документов, стандарты качества и т.п. Вот и мне пару лет назад пришлось внедрять такую систему прежде всего для своих нужд, а уж потом ее подхватили и остальные. Понятно, что это wiki-система. Ибо только такие системы с легкостью позволяют хранить такую информацию и дают прекрасные возможности по совместной работе над ней. Тогда я выбрал движок MediaWiki. Это такая довольно аскетичная система, на которую можно прикручивать различные плагины, но все равно ее можно сравнить с Линуксом. Со временем стало понятно, что простым людям эта система дается сложно, в ней сложно контролировать структуру документов, в ней сложно работать с правами доступа к документам.

Используя мощный, настраиваемый баг/таск-трекер JIRA (или Confluence), со временем приходит понимание, что в некоторых случаях не хватает нужного функционала, которого нельзя получить из стандартных и представленных на сайте плагинов. Всвязи с этим приходиться выходит на новый уровень: собственная разработка. Когда это такое время приходит, встают вопросы: с чего начинать? В JIRA и Confluence куча зависимостей между библиотеками, как их связать воедино, что бы создать нужное? Где это все сделать?
В данной статье не будет рассказано как сделать плагин, потому что для каждого варианта требуется разные подходы. Расскажу только как подготовить платфотму для разработки.

Я хочу поделиться с вами моим опытом по настройке системы регистрации и обработки заявок Atlassian JIRA, совместно с Atlassian Confluence в качестве системы тех. поддержки пользователей. Что пишут Atlassian по поводу этого можно почитать тут: http://confluence.atlassian.com/display/JIRA/JIRA+as+a+Support+System

Есть несколько концепций организации тех. поддержки. Первая из них – это настройка отдельного проекта для каждого клиента. Но эта концепция не рациональна в связи с тем, что сотрудники тех. поддержки не видят общей картины и при большом количестве клиентов возникает переизбыток проектов. Поэтому я расскажу вам о другой концепции – с одним проектом Service Desk для всех клиентов с настроенными областями видимости.

Задача:

• Ежедневный backup mysql базы данных для JIRA и Confluence;
• Ежедневный backup директорий с attachments;
• Архивирование всех сделанных backup'ов;
• Удаление старых backup'ов.

Оговорюсь, что мне это нужно было сделать для Windows и я понимаю, что для Linux все делается проще и быстрее. Также если вы являетесь администратором, то данный топик вряд ли будет вам интересен и ничего нового вы не узнаете. Но можете использовать написанное, как готовое и проверенное решение.

Зачем?

Тот, кто когда-нибудь интересовался вопросом “подгонки” JIRA, Confluence или другого продукта Atlassian под себя, знает, что для этих целей существует Atlassian SDK.

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

Хочу немного рассказать о том, как Confluence используется в SAP: www.sdn.sap.com/irj/scn/wiki

Для тех, кто не знает, пара слов о том, что это. “Конфа” как ее часто называют — традиционная вики-система. Для каждой статьи хранит список изменений в удобной форме: можно посмотреть какие изменения внесла Маша неделю назад, а что поменял Петр полгода назад. Фишка именно в удобстве сравнения разных версий статьи. Развитые системы документооборота тоже хранят разные версии скажем doc файла, но их неудобно сравнивать. Приходится, например, выделять свои комментарии другим цветом. В вики такое зачастую не требуется. На примере википедии видно что это самый удобный способ хранить и коллективно редактировать некую систему знаний (статей).

Confluence платная. Цены сильно различаются от 10 баксов за 10 пользователей, до $12 000 для крууупных компаний. Бесплатно предоставляется проектам с открытым исходным кодом, благотворительным организациям (Non-profits and Open Source projects).

Покупаешь лицензию — получаешь исходники. Можно посмотреть как все внутри устроено, поменять что-то, если надо.

Продолжая тему двух предыдущих постов (первый и второй), в которых проводилось исследование на тему управления знаниями и были рассказаны основные результаты, хотелось бы углубиться в практическую составляющую данной проблемы. Вопросов для обсуждения здесь предостаточно, но основной — существуют ли инструменты, позволяющие удовлетворить все потребности бизнеса в части управления знаниями? Попробуем ответить на этот вопрос со своей «колокольни».

Начиная с 2009-го года, компания Atlassian, производитель известного issue-tracker JIRA и корпоративной wiki Confluence, проводит ежегодное мероприятие под названием Atlassian Summit.

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



По традиции Саммит проходит в Сан-Франциско, где расположен один из офисов компании, и в этом году я впервые побывал там. Хочу немного поделиться с вами новостями из мира Atlassian, да и просто впечатлениями.

За несколько дней до весны в линейке продуктов компании Atlassian большое и, самое главное, долгожданное событие: случился релиз Confluence 5 с ощутимыми изменениями в пользовательском интерфейсе и огромным количеством новых фич. Под катом обзор возможностей Confluence 5 с некоторым количеством картинок и большим количеством ссылок.

CEO Atlassian как бы говорит нам, что они отлично потрудились над Confluence 5

Казалось бы, совсем недавно вышел Confluence 5, который принес пользователям уйму новых фич: новое визуальное представление, возможность переключения между приложениями непосредственно из wiki, нотификации о том, что добавлен комментарий либо содержимое страницы кем-либо изменено. Тем не менее, уже ощущается дыхание версии 5.1 Atlassian Confluence, которая направлена на упрощение процесса содания страниц с помощью технологии Blueprints. Blueprints помогает пользователям понять, какое содержимое они хотят создать и показываeт, как это сделать, буквально проводя пользователей за руку до получения готовой к просмотру wiki-страницы.

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

Дорогие друзья!

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

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

Преамбула: «Что такое Payler сегодня?»
● Основные компоненты продукта: антифрод, ядро шлюза, публичные и внутренние API, модули процессинга, административные интерфейсы мерчанта, мобильные клиенты, внутренние утилиты;
● Продукту несколько месяцев, получен сертификат на соответствие PCI DSS, появились первые клиенты;
● Используемые технологии: C#, Python, Ruby, MySQL, Redis, Angular.js etc.;
● Команда:
○ Backend: 3 разработчика, которые периодически переключаются между компонентами;
○ Frontend: 1 разработчик;
○ Mobile: 2 разработчика — 1 iOS, 1 Android;
○ Системный администратор.

Во вторник, 21 апреля, Mail.Ru Group организует первый Moscow Atlassian Meetup. В офисе компании соберутся эксперты в области организации общения с пользователями и управления проектами. В программе события — доклады по продуктам Atlassian (JIRA, Confluence и другим), а после — их обсуждение и общение единомышленников в свободной обстановке.

21 апреля мы организовали в Mail.Ru Group мероприятие для обмена опытом использования JIRA и других продуктов Atlassian — Moscow Atlassian Meetup.

Событие было запланировано на 19 часов, но посетители начали собираться уже за полчаса до начала. В ожидании докладов кто-то подключался к Wi-Fi, а кто-то наливал себе кофе. Когда все собрались, зал был полон — на встрече было более 100 человек, еще 200 наблюдали за происходящим с помощью онлайн-трансляции. В этом посте я хочу опубликовать видеозаписи и слайды докладов, а также подробнее рассказать о самих докладах.

Автоматизация работы редакции контентных проектов
Андрей Молчанов, Mail.Ru Group

Первый доклад на конференции был мой. Я рассказывал о том, каким образом с помощью JIRA и разработанного нами плагина удалось автоматизировать часть рутинной работы редакции.

Редакция — это люди, которые обеспечивают наши контентные проекты (Леди Mail.Ru, Hi-Tech Mail.Ru и др.) материалами. Обеспечивают — значит заказывают статьи у внешних и внутренних авторов, оплачивают их, размещают на сайте и затем анализируют статистику.

Сначала мы реализовали учет каждого материала — от заказа до оплаты в виде JIRA Issue. Это позволило вести списки статей на дашборде вместо традиционных записей в блокноте или почте. Кроме того, мы подключили наш Calendar Plugin для наглядного отображения редакционного плана.

5 лет мы развиваем инфраструктуру Mail.Ru Group, используя продукты Atlassian. Все это время мы постоянно сталкивались с дефицитом специалистов по этим продуктам, к тому же сообщество в России практически не развито. Ответы на все вопросы приходилось искать самим, сражаясь с проблемами, трудностями и службой поддержки Atlassian.

20 октября в офисе компании Mail.Ru Group во второй раз соберутся участники сообщества Moscow Atlassian. Единомышленники поделятся практическим опытом и обсудят тонкости использования продуктов линейки Atlassian. В программе, как обычно, несколько докладов и общение гостей за чашкой кофе.

Практически во всех местах моей работы программистом для разработки использовали всего два продукта: багтрекинг и систему контроля версий. Чаще всего это были Atlassian Jira и SVN. В принципе, наличие этих двух систем здорово упорядочивает общение всех участников процесса разработки и положительно влияет на качество работы отдела и продукта.

Года 4 назад я морально, а затем и фактически дорос до уровня тимлида. Взгляды стали шире и выше текущих процессов. В голову стали приходить разные мысли о мотивации, оптимизации, автоматизации и прочих -циях. В этой статье я хотел бы поделиться опытом из разряда технических компетенций тимлида: как автоматизировать ежедневные процессы (например, автоматическая сборка продукта, выкладывание, документирование, управление правами т.д. и т.п.).

После третьей страницы текста моей статьи, я решил разделить ее на 2 блока:

• Настройка ПО, сопровождающего процесс разработки.
• Описание Workflow.

Итак. Настройка ПО, сопровождающего процесс разработки