+‑ с июня 2022г. в 8 раз выросло количество обращений на импортозамещение этих сервисов в EvaTeam.
Был 1 а стало 8?
Мы в EvaTeam полгода закрывали разрыв по функциональности с Jira и Confluence.
К декабрю 2022 закрыли разрыв (осталось улучшить популярные плагины типа «structure») + сделали крутой импорт.
Возможность крутить шурупы отверткой а не шуриком тоже можно считать за "закрытие разрыва в функционале". Но какое-то оно сомнительное
Основной болью на декабрь 2022г. оставался интерфейс (по словам клиентов). Он был немного другой, пользователи не хотели привыкать. Было принято стратегическое решение — сделать полный клон. Вариант интерфейса «Jira».
Жаль, что нам так и не удалось заслушать начальника транспортного цеха увидеть в статье примеры интерфейса, который будет... или есть... или что... или когда...????
Ниже описание со скриншотами того, что удалось разработать за полгода. Российские разработчики сделали за полгода то, что разрабатывалось и внедрялось 20 лет (первый релиз Jira 2002г.).
Не смешите рынок, а то потенциальные покупатели помрут со смеху - кому продавать будете? ))))
====
Я конечно понимаю, что хочется со всех сил пропиарить свой продукт, но... Нельзя же уж совсем так.
Когда ты слышишь слова "мы сделали клон жиры" и т.д. и потом реально заходишь в этот "клон", то ... ощущения не передать словами: толи плакать хочется, толи смеяться, толи еще чего...
Очень уж "клон" похож на студенческую поделку с основным лозунгом разработки "пофиг как, но чтоб было хоть как-нибудь и быстро". И самое главное - после этого еще с год-два я не пойду смотреть на это изделие, даже если вы выпустите еще сотню статей "мы уже все переделали, у нас прям все ваще ваххх как". Отличная антиреклама.
Я подозреваю, что Space делала отдельная команда, которая была не в курсе разработок YouTrack и TeamCity — ну по крайней мере технически.
Или Space делали для… эээ, а для кого? Неужели свои собственные разработчики не пользовались своими собственными YouTrack и TeamCity? Такое разве может быть?
А если пользовались — и как они теперь живут, бедные, в трех системах? Или в одной, но урезанной, но зато с коммуникациями?
Не одна версия по уму не может быть правдивой, но как ни крути, а версия должна быть
JetBrains, мы вас теряем? :))
Тот же вопрос и тоже «слегка» озадачен: создан универсальный инструмент для совместной работы cо всем и вся, но почему-то с «демо-версией» работы с задачами, больше никак тут не назвать существующий механизм Issues в Space. И это при существовании нормального YouTrack.
Возникает сразу вопрос: почему не впихнули одно в другое? Ну как так? Или над Space (как обычно) работали совсем другие люди и про YouTrack были «не в курсе», а потом уже было поздно? )))
В итоге то проблема так и не решена:
* есть отдельный инструмент Space для коммуникаций и документации, с расширенной информацией по командам и т.д., в общем, неплохая вещь — ну когда будут готовы процессы для бизнес-подразделений (code-review для документов и т.д.). Да, для разрабов все есть, кроме одного: нет нормального функционала задач. И как они живут? Или подразумевается, что все разрабы, вот все десятки и сотни разрабов (а в будущем и обычных пользователей), настолько дисциплинированы и адекватны, что без ошибок будут делать всю работу и ни разу не пихнут задачу не в тот статус? Роботы? ))
* и есть отдельный инструмент YouTrack для работы над задачами — с воркфлоу и т.д., который частично пересекается по функционалу. Ну а если его сконнектить со Slack, то будут и коммуникации более-менее
И для того, чтобы иметь и тот и тот функционал, пользователи будут все-равно работать в разных системах
Хотя решение объединения систем напрашивается само собой — и тогда бы с чистой душой можно было и использовать и предлагать такой продукт для любой потребности, какая возникнет у компании: хочешь задачи — на, хочешь коммуникации — на, хочешь ci/cd/git/code review — бери, хочешь команды — пожалуйста, хочешь это все вместе — да без проблем
Ыыыыыыыыыы
Не всем получится жрать кактус — многие его не смогут даже попробовать
Ну например возьмем пример, когда есть AD, коннект к внешним СУБД и все воркфлоу обвешаны скриптами — и тут облако не светит. Уж не говоря про требования ФЗ и СБ
ДЦ при 10000 пользователей тоже не светит — там цена невменяемая
Хошь не хошь, а такому клиенту за 3 года надо найти, куда свалить
Мы видим очередное подтверждение теории «чем дальше в лес больше денег, тем меньше остается мозгов»
Атлассиан решили дальше строить свою жизнь исключительно с домохозяйками — а кто еще может работать в облаке? Это же мучительные мучения — взять только одну асинхронную модель, не говоря уж про кучу всего другого, чему нет никаких аналогов в облаке
Честно говоря, не представляю, как крупный клиент с жирной жирой может уйти в облако — это просто невозможно, хоть даже бесплатно оно будет
ДЦ — с ценой, которая озвучена, проще свою жиру написать
Обчим, жира гудбай, атлассиан гудбай, видимо так
Надо искать что-то другое
Не, оно конечно, если вдруг от атласианов начнут валить — ну или сообщать, что свалят — большие и жирные клиенты, оно может и вправит мозги, но что-то я не уверен: если люди решили, что они умеют летать и начали разбег к обрыву, то их уже не остановить
Я добавлю более явно, что нужно еще уметь использовать мультитул
Не нужно его прижимать со всей дури, это действует как раз в обратную сторону — ничего не пилится
Хотя по опыту конечно же мы думаем, что чем сильнее держать и прижимать, тем лучше
Вот тут мультитул отличается от всех остальных — его надо держать очень нежно :), практически чтобы он давил своим весом, ну типа того.
Все это оттого, что он работает через вибрацию насадки относительно материала, а если его сильно прижать, то таких вибраций уже не будет — будут вибрации всего мультитула относительно насадки и материала.
Поэтому у начинающих (как у меня) бывает, что «нифига оно не работает, выкинуть его да и все»
Однако стоит только держать его правильно — и все становится хорошо
Как только работать им научишься — то и сразу проблем нет, зачем и как его использовать
Но таки да, он очень специфический инструмент
И лучше кстати брать его проводным, а не аккумуляторным, потому что аккума очень уж на мало хватает, жрет он быстро их
Но железо и даже алюминь я бы им не пилил — лучше ножовкой по металлу, руками, чем им
Вот дерево/пластик и т.д. — самое то
А, понял, про что вы. :)
Нет, не пойдет: JQL используется только для выборки списка заявок по параметрам. К служебным данным он отношения не имеет
И боюсь API не сможет выдать данные по параметрам настройки конкретного экрана на портале сервисдеска
Т.е. данные по заявке то я могу получить разными способами, но вот как называется конкретное поле на конкретном экране конкретного портала — я думаю что только через sql. Может конечно и еще как-то, но мне sql ближе — на нем все быстрее, понятнее и можно добраться до всех данных, какие есть в бд
И кстати, ScriptRunner становится платным — причем очень платным для количества лицензий начиная от 250 (http://www.adaptavist.com/w/continuing-to-develop-scriptrunner-for-jira/). Дешевле купить все плагины JJUPIN и т.д. от кеплера
Если у вас один тип запросов и всегда один набор полей, то да, сойдет, как альтернатива создания запроса напрямую через Жиру
Ну да, он умеет создавать от указанного пользователя, это хорошо.
Правда я не смог заставить его работать нормально — статистику использования он не показывал
Но если у вас много типов запросов, много категорий, от которых зависит набор полей, если нужны расширенные комментарии к полям и вообще другие названия для них в зависимости от типа и категории — тут только JSD
Он вовремя подоспел — мы перевели всю техподдержку у себя на Жиру
Разработка до этого перешла, через Жиру
Вообще в Жире очень низкий порог вхождения нового пользователя, который ни разу ее не видел и вообще ни с чем таким не работал
Он практически нулевой
Но через email нельзя заполнить никакие поля, кроме описания и темы
А если брать явное создание запросов пользователем, то в Жире можно указать все, что надо (выпадающие списки, даты и т.п.)
JSD дает более удобную работу с этим всем — человек вообще может даже и не знать, как на самом деле выглядит заявка в Жире, подавая заявки через JSD
Так по почте и т.д. — это все сама Жира
А Service Desk — это удобная настраиваемая морда для подачи заявок и удобная их обработка: SLA + очереди + отчеты
Настроить можно без проблем, если что-то уже приходилось настраивать в Жире
Есть уже плагин, добавляющий некоторые плюшки к JSD, которых там нет и руки до них у Атлассиана вряд ли быстро дойдут
Но это шире, чем просто Service Desk
Или вообще — это не Service Desk :)
Ну в понимании этого термина, как Служба Поддержки пользователей, реагирующая на их запросы
ServiceDesk, если прямо переводить — служба поддержки.
Кого и как вы ей поддерживаете — ваше личное дело, никакие итили и т.д. тут никому не могут ничего указывать
Что есть служба поддержки?
Это заявка пользователя и работы по ней., т.е. простейший баг-трекер. А если обработка не в стиле «принял — обработал — закрыл», то это уже совсем не простейший баг-трекер, а нормальный процесс
Касаемо Жиры
У нас на ней сделан и SD, и процесс разработки, и процессы между отделами компании, и т.д.
А JIRA Service Desk вообще очень сильно продвинул Жиру в смысле приема заявок от пользователей
Я потихоньку пишу краткую статью про JIRA Service Desk (JSD), там информация будет о нем, возможно вам поможет.
Надеюсь за недельку закончить
По поводу применимости
Проблема JSD в том, что пользователь должен залогиниться в систему, чтобы написать через JSD заявку
Если у вас все пользователи видят Жиру и нет проблем с количеством лицензий — то смело можно использовать. Если один из этих пунктов в пролете — то остается только по письмам создавать задания от единого универсального пользователя
Если исходить из того, что у нас все хорошо с дисциплиной, то остается только процессы сделать нормальными — а тут поможет и этот набор средств, и любой другой, лишь бы в них уметь работать
Может стоит лучше расписать, чем поможет именно данный инструмент и как с ним работать, чтобы он помог.
Хотя я боюсь, что обычно все наоборот: и процессы есть (вроде), и средств полно — а толку нет, потому что нет дисциплины. И это самое сложное. После процессов.
Кстати, ко всем средствам я бы добавил очень важное требование — легкое изменение под требования процессов. Мы пока поставили процессы, раза три их меняли, а вместе с ними и процессы трекера. Но он позволяет это делать относительно быстро и просто. А если нет? :)
Не, я боюсь, бОльшая часть из перечисленных проблем вообще никак не связана с техническими возможностями
Каша из требований будет и в вики тоже, если нет четкого понимания по структуре и составу требований. А если есть понимание — то хоть в почте, будет все хорошо. Хотя таки да, с вики легче в итоге, даже бардак легче делать :)
Трекер да, поможет — но только в качестве хранилища задач
Файлы и сообщения — да хоть где, лишь бы удобно было. А лучше без файлов
Про страх я не очень понял, а сбор лайков — это вообще вряд ли к процессу управления относится
Живая лента — вообще не понял, чем она может помочь
Но! Это все средства, причем для организации любого процесса, хоть с рисками, хоть без
Но даже имея все эти средства, риск того, что все это не поможет — никак не меньше, чем без средств.
Потому что на самом деле важно другое (ИМХО, из опыта):
1. Дисциплина
2. Правильное управление всеми этими процессами
3. Дисциплина
Вот об этом бы поговорить и обменяться опытом, хорошим и плохим
Честно говоря, надеялся, что в статье таки будет то, о чем написано в начале:
Примечательно, что концентрация на борьбе с рисками и известными причинами проблем — неожиданно приносит огромную пользу. Скажу больше — именно устранение препятствий в некоторых современных методологиях (scrum) — и является гарантией достижения цели проекта.
Но ничего такого не нашел, никакого описания вообще никакой борьбы ни с чем
То, что нужен набор инструментов — это и так каждому понятно. Но почему именно таких, какие в статье, и чем же «трекер задач, лучше с поддержкой иерархии и бизнес-процессов» поможет лучше, чем просто трекер задач...?
Но я бы оставил вообще как причину только одну дисциплину
Боевой опыт помогает только тогда, когда все остальное не помогло, в особенности дисциплина, и поэтому приходится делать проект за 3 дня, который уже 2 месяца все никак и никуда.
Правда в этом случае опыт помогает тому, у кого он есть
А если бы была дисциплина, то опыт бы помог и тем, у кого нет опыта
ЗЫ А не, еще внутренняя бюрократия, когда вместо быстрого решения проводится 25 совещаний, где из пустого в порожнее переливаются одни и те же обсуждения. Хотя это тоже наверное к дисциплине
У нас тоже так: плагин ставишь, понеслось до 95% процессор жрать, тупить и т.д.
Пока была небольшая нагрузка и мало заявок, было нормально, теперь плагины и прочее обновляю только по вечерам/ночам, когда почти никто не работает, иначе ждут долго, минут по 10, пока рассосется
Что оно там делает в этот момент, непонятно
Еще сильно все зависит от количества памяти: сейчас дадено 10 Гиг, сама по себе почти не падает, но надо бы еще 4-6 выдать, для верности, иногда впритык. Очень они, такие приложения, когда оно внутри себя объекты строит и по индексам ходит, любят память, много памяти. И диски любят, и процессоры тоже :)
Эммммм... ну ладно, по порядку ;)
+‑ с июня 2022г. в 8 раз выросло количество обращений на импортозамещение этих сервисов в EvaTeam.
Был 1 а стало 8?
Мы в EvaTeam полгода закрывали разрыв по функциональности с Jira и Confluence.
К декабрю 2022 закрыли разрыв (осталось улучшить популярные плагины типа «structure») + сделали крутой импорт.
Возможность крутить шурупы отверткой а не шуриком тоже можно считать за "закрытие разрыва в функционале". Но какое-то оно сомнительное
Основной болью на декабрь 2022г. оставался интерфейс (по словам клиентов). Он был немного другой, пользователи не хотели привыкать. Было принято стратегическое решение — сделать полный клон. Вариант интерфейса «Jira».
Жаль, что нам так и не удалось
заслушать начальника транспортного цехаувидеть в статье примеры интерфейса, который будет... или есть... или что... или когда...????Ниже описание со скриншотами того, что удалось разработать за полгода. Российские разработчики сделали за полгода то, что разрабатывалось и внедрялось 20 лет (первый релиз Jira 2002г.).
Не смешите рынок, а то потенциальные покупатели помрут со смеху - кому продавать будете? ))))
====
Я конечно понимаю, что хочется со всех сил пропиарить свой продукт, но... Нельзя же уж совсем так.
Когда ты слышишь слова "мы сделали клон жиры" и т.д. и потом реально заходишь в этот "клон", то ... ощущения не передать словами: толи плакать хочется, толи смеяться, толи еще чего...
Очень уж "клон" похож на студенческую поделку с основным лозунгом разработки "пофиг как, но чтоб было хоть как-нибудь и быстро". И самое главное - после этого еще с год-два я не пойду смотреть на это изделие, даже если вы выпустите еще сотню статей "мы уже все переделали, у нас прям все ваще ваххх как". Отличная антиреклама.
А потом ты вдруг видишь цену.... )))))
Или Space делали для… эээ, а для кого? Неужели свои собственные разработчики не пользовались своими собственными YouTrack и TeamCity? Такое разве может быть?
А если пользовались — и как они теперь живут, бедные, в трех системах? Или в одной, но урезанной, но зато с коммуникациями?
Не одна версия по уму не может быть правдивой, но как ни крути, а версия должна быть
JetBrains, мы вас теряем? :))
Возникает сразу вопрос: почему не впихнули одно в другое? Ну как так? Или над Space (как обычно) работали совсем другие люди и про YouTrack были «не в курсе», а потом уже было поздно? )))
В итоге то проблема так и не решена:
* есть отдельный инструмент Space для коммуникаций и документации, с расширенной информацией по командам и т.д., в общем, неплохая вещь — ну когда будут готовы процессы для бизнес-подразделений (code-review для документов и т.д.). Да, для разрабов все есть, кроме одного: нет нормального функционала задач. И как они живут? Или подразумевается, что все разрабы, вот все десятки и сотни разрабов (а в будущем и обычных пользователей), настолько дисциплинированы и адекватны, что без ошибок будут делать всю работу и ни разу не пихнут задачу не в тот статус? Роботы? ))
* и есть отдельный инструмент YouTrack для работы над задачами — с воркфлоу и т.д., который частично пересекается по функционалу. Ну а если его сконнектить со Slack, то будут и коммуникации более-менее
И для того, чтобы иметь и тот и тот функционал, пользователи будут все-равно работать в разных системах
Хотя решение объединения систем напрашивается само собой — и тогда бы с чистой душой можно было и использовать и предлагать такой продукт для любой потребности, какая возникнет у компании: хочешь задачи — на, хочешь коммуникации — на, хочешь ci/cd/git/code review — бери, хочешь команды — пожалуйста, хочешь это все вместе — да без проблем
Ыыыыыыыыыы
Ну например возьмем пример, когда есть AD, коннект к внешним СУБД и все воркфлоу обвешаны скриптами — и тут облако не светит. Уж не говоря про требования ФЗ и СБ
ДЦ при 10000 пользователей тоже не светит — там цена невменяемая
Хошь не хошь, а такому клиенту за 3 года надо найти, куда свалить
дальше в лесбольше денег, тем меньше остается мозгов»Атлассиан решили дальше строить свою жизнь исключительно с домохозяйками — а кто еще может работать в облаке? Это же мучительные мучения — взять только одну асинхронную модель, не говоря уж про кучу всего другого, чему нет никаких аналогов в облаке
Честно говоря, не представляю, как крупный клиент с жирной жирой может уйти в облако — это просто невозможно, хоть даже бесплатно оно будет
ДЦ — с ценой, которая озвучена, проще свою жиру написать
Обчим, жира гудбай, атлассиан гудбай, видимо так
Надо искать что-то другое
Не, оно конечно, если вдруг от атласианов начнут валить — ну или сообщать, что свалят — большие и жирные клиенты, оно может и вправит мозги, но что-то я не уверен: если люди решили, что они умеют летать и начали разбег к обрыву, то их уже не остановить
Не нужно его прижимать со всей дури, это действует как раз в обратную сторону — ничего не пилится
Хотя по опыту конечно же мы думаем, что чем сильнее держать и прижимать, тем лучше
Вот тут мультитул отличается от всех остальных — его надо держать очень нежно :), практически чтобы он давил своим весом, ну типа того.
Все это оттого, что он работает через вибрацию насадки относительно материала, а если его сильно прижать, то таких вибраций уже не будет — будут вибрации всего мультитула относительно насадки и материала.
Поэтому у начинающих (как у меня) бывает, что «нифига оно не работает, выкинуть его да и все»
Однако стоит только держать его правильно — и все становится хорошо
Как только работать им научишься — то и сразу проблем нет, зачем и как его использовать
Но таки да, он очень специфический инструмент
И лучше кстати брать его проводным, а не аккумуляторным, потому что аккума очень уж на мало хватает, жрет он быстро их
Но железо и даже алюминь я бы им не пилил — лучше ножовкой по металлу, руками, чем им
Вот дерево/пластик и т.д. — самое то
Нет, не пойдет: JQL используется только для выборки списка заявок по параметрам. К служебным данным он отношения не имеет
И боюсь API не сможет выдать данные по параметрам настройки конкретного экрана на портале сервисдеска
Т.е. данные по заявке то я могу получить разными способами, но вот как называется конкретное поле на конкретном экране конкретного портала — я думаю что только через sql. Может конечно и еще как-то, но мне sql ближе — на нем все быстрее, понятнее и можно добраться до всех данных, какие есть в бд
И кстати, ScriptRunner становится платным — причем очень платным для количества лицензий начиная от 250 (http://www.adaptavist.com/w/continuing-to-develop-scriptrunner-for-jira/). Дешевле купить все плагины JJUPIN и т.д. от кеплера
Ну да, он умеет создавать от указанного пользователя, это хорошо.
Правда я не смог заставить его работать нормально — статистику использования он не показывал
Но если у вас много типов запросов, много категорий, от которых зависит набор полей, если нужны расширенные комментарии к полям и вообще другие названия для них в зависимости от типа и категории — тут только JSD
Он вовремя подоспел — мы перевели всю техподдержку у себя на Жиру
Разработка до этого перешла, через Жиру
Вообще в Жире очень низкий порог вхождения нового пользователя, который ни разу ее не видел и вообще ни с чем таким не работал
Он практически нулевой
Но через email нельзя заполнить никакие поля, кроме описания и темы
А если брать явное создание запросов пользователем, то в Жире можно указать все, что надо (выпадающие списки, даты и т.п.)
JSD дает более удобную работу с этим всем — человек вообще может даже и не знать, как на самом деле выглядит заявка в Жире, подавая заявки через JSD
А Service Desk — это удобная настраиваемая морда для подачи заявок и удобная их обработка: SLA + очереди + отчеты
Настроить можно без проблем, если что-то уже приходилось настраивать в Жире
Есть уже плагин, добавляющий некоторые плюшки к JSD, которых там нет и руки до них у Атлассиана вряд ли быстро дойдут
Или вообще — это не Service Desk :)
Ну в понимании этого термина, как Служба Поддержки пользователей, реагирующая на их запросы
ServiceDesk, если прямо переводить — служба поддержки.
Кого и как вы ей поддерживаете — ваше личное дело, никакие итили и т.д. тут никому не могут ничего указывать
Что есть служба поддержки?
Это заявка пользователя и работы по ней., т.е. простейший баг-трекер. А если обработка не в стиле «принял — обработал — закрыл», то это уже совсем не простейший баг-трекер, а нормальный процесс
Касаемо Жиры
У нас на ней сделан и SD, и процесс разработки, и процессы между отделами компании, и т.д.
А JIRA Service Desk вообще очень сильно продвинул Жиру в смысле приема заявок от пользователей
Надеюсь за недельку закончить
По поводу применимости
Проблема JSD в том, что пользователь должен залогиниться в систему, чтобы написать через JSD заявку
Если у вас все пользователи видят Жиру и нет проблем с количеством лицензий — то смело можно использовать. Если один из этих пунктов в пролете — то остается только по письмам создавать задания от единого универсального пользователя
Если исходить из того, что у нас все хорошо с дисциплиной, то остается только процессы сделать нормальными — а тут поможет и этот набор средств, и любой другой, лишь бы в них уметь работать
Может стоит лучше расписать, чем поможет именно данный инструмент и как с ним работать, чтобы он помог.
Хотя я боюсь, что обычно все наоборот: и процессы есть (вроде), и средств полно — а толку нет, потому что нет дисциплины. И это самое сложное. После процессов.
Кстати, ко всем средствам я бы добавил очень важное требование — легкое изменение под требования процессов. Мы пока поставили процессы, раза три их меняли, а вместе с ними и процессы трекера. Но он позволяет это делать относительно быстро и просто. А если нет? :)
Каша из требований будет и в вики тоже, если нет четкого понимания по структуре и составу требований. А если есть понимание — то хоть в почте, будет все хорошо. Хотя таки да, с вики легче в итоге, даже бардак легче делать :)
Трекер да, поможет — но только в качестве хранилища задач
Файлы и сообщения — да хоть где, лишь бы удобно было. А лучше без файлов
Про страх я не очень понял, а сбор лайков — это вообще вряд ли к процессу управления относится
Живая лента — вообще не понял, чем она может помочь
Но! Это все средства, причем для организации любого процесса, хоть с рисками, хоть без
Но даже имея все эти средства, риск того, что все это не поможет — никак не меньше, чем без средств.
Потому что на самом деле важно другое (ИМХО, из опыта):
1. Дисциплина
2. Правильное управление всеми этими процессами
3. Дисциплина
Вот об этом бы поговорить и обменяться опытом, хорошим и плохим
Но ничего такого не нашел, никакого описания вообще никакой борьбы ни с чем
То, что нужен набор инструментов — это и так каждому понятно. Но почему именно таких, какие в статье, и чем же «трекер задач, лучше с поддержкой иерархии и бизнес-процессов» поможет лучше, чем просто трекер задач...?
Но я бы оставил вообще как причину только одну дисциплину
Боевой опыт помогает только тогда, когда все остальное не помогло, в особенности дисциплина, и поэтому приходится делать проект за 3 дня, который уже 2 месяца все никак и никуда.
Правда в этом случае опыт помогает тому, у кого он есть
А если бы была дисциплина, то опыт бы помог и тем, у кого нет опыта
ЗЫ А не, еще внутренняя бюрократия, когда вместо быстрого решения проводится 25 совещаний, где из пустого в порожнее переливаются одни и те же обсуждения. Хотя это тоже наверное к дисциплине
Пока была небольшая нагрузка и мало заявок, было нормально, теперь плагины и прочее обновляю только по вечерам/ночам, когда почти никто не работает, иначе ждут долго, минут по 10, пока рассосется
Что оно там делает в этот момент, непонятно
Еще сильно все зависит от количества памяти: сейчас дадено 10 Гиг, сама по себе почти не падает, но надо бы еще 4-6 выдать, для верности, иногда впритык. Очень они, такие приложения, когда оно внутри себя объекты строит и по индексам ходит, любят память, много памяти. И диски любят, и процессоры тоже :)