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

EvaProject позиционируется как замена Jira. Рекламные лозунги, описания, презентации - это всё хорошо, но хочется сказать о проблемах, которые пользователь получит, когда начнёт пользоваться продуктом. Зачем? Эти проблемы не лежат на поверхности, не указаны в описании, не присутствуют в рекламных буклетах и, скорее всего, даже при первоначальной оценке EvaProject, будут упущены.

Отсутствие гарантий по работе всего API

Много говорится  о том, как тут можно классно всё автоматизировать за счёт API вызовов. Присутствует официальная документация на вызовы. Но, если вы начнёте заниматься этой автоматизацией, то увидите, что далеко не все необходимые API вызовы описаны в официальной документации. Вы пойдёте в поддержку и спросит: "Что это значит, почему?". И вам ответят: это значит, что если вы будете пользоваться этим API вызовом, то никто не гарантирует вам его работоспособность. Т.е. вы должны сами понять как он работает, а потом ещё и получить отсутствие гаратий обратной совместимости. Даже более того: они не несут ответственности за использование вами этих API вызовов. Чтоб вы представляли размах бедствий: вы не сможете даже редактировать значение созданного вами нового поля (например для автоматического заполнения версий, веток кода и т.п.)

Администраторы администраторов

В EvaProject есть несколько типов администраторов. Есть администратор проекта и есть глобальный администратор. Первый, что логично, заведует конкректным проектом и всем внутри него, а второй - всей EvaProject. Ну т.е. администратор проекта - это некий руководитель проекта, а глобальный администратор - это devops, который занимается поддержкой инфраструктуры копании - подумаете вы. И ошибетёсь. Рассмотрим пример: вот вам требуется завести новое поле для задач/багов, например, вы хотите, чтобы там был список поддерживаемых ОС, т.е. фиксированный список значений. Кто это должен делать? Правильно - PO, он же занимается настройкой процессов работы команды. Но в EvaProject добавить новое поле (пользовательское поля в их терминологии) может только глобальный администратор. Т.е. мы получаем перекладывание обязанностей с руководителя на DevOps'ов.

Попробуем скалировать теперь нашу воображаемую компанию и начнём добавлять проекты. Получается, что мы должны добавлять DevOps'ов, просто чтобы они делали работу руководителей, потому что рано или поздно один перестанет справляться с потоком задач. Это не беря во внимание, что DevOps'ы не должны впринципе таким заниматься. Во-первых потому что это не их профиль, им это не интересно, а во-вторых, потому что это дополнительный человеческий фактор и они - лишнее звено, которое будет совершать ошибки, требовать дополнительной синхронизации и перепроверки результата со стороны руководиеля. А это всё что? Правильно - деньги компании, которая решила исопльзовать EvaProject.

Обладание правами на процессы/схемы/экраны

Продолжая тему  администаторов и доступов к данным, рассмотрим следующую ситуацию. PO для своего проекта нафигчаил бизнесс процессов, схем и экранов. Т.е. он выстроил flow того по каким состояниям должны дваигаться задачи/баги, добавил новых полей (которые завёл ему глобальный администратор) и т.д., в целом как обычно. Теперь проблемы - только он обладает этими объектами. Т.е. если вы добавите ещё одного администратора в этот проект (например взяли в помощь PO, или начинается передача дел), то он никаким образом никогда не сможет получить доступ к бизнес процессам и настроенным экранам/схемам. Т.е. если у вас человек уволится, исчезнет, то всё что связано с его деятельностью - будет закрыто. Единственный вариант - это дать доступ к аккаунту этого человека. Но полагаю, что тут сразу возникнет много вопросов у безопасников и аудиту производимых действий. А так же куча непонятных приседаний: это я, как руководитель нескольких проектов, должен между учётками переключаться?

Доступность пользовательских полей

Продолжим тему обладания и правами доступа. Положим у вас есть проекты и вы заводите пользовательские поля (т.е. поля с какими-то своими значениями/предназначениями), значения которых не должны быть видны никому. А они будут видны, потому что все пользовательские поля доступны всем проектам, их нельзя скрыть. Т.е. любой адинистратор любого проекта видит все поля всех проектов.

Прибитые гвоздями типы

В EvaProject есть набор базовых типов (Epic, Task agile, etc), которые хочется назвать "специальными". Вы когда начинаете работать с ними то понимаете, что на эти  типы завязана какая-то внутренняя логика и обрабатываются они по-особенному. И вам придётся самому разбираться где, почему и как они отрабатывают каждый в отедльности. Т.е. вы потратите немало сил на выяснение этого, когда будете строить бизнес-процессы. И это придётся делать каждому в отдельности. Или проводить исследование, записывать тренинг и раздавать сотрудникам.парадиг

Парадигма регулярного обновления

Кроме прочего, когда вы будете работать с продуктом и приходить в поддержку с проблемами, они будут спрашивать у вас версию и потом просить "обновитесь до последней сборки". Кажется, EvaTeam, думает, что написала типичное мобильное приложение, которое там само может обновляться в background'е и это окей. Ничего, что это часть инфраструктуры и её обновление планируется, систеа выключается, обновляется, а потом тестируется внутренними методами на то, что ничего важного не отвалилось? Т.е. это обычный процесс обновления части инфраструктуры, который есть в каждой плюс-минус зрелой организации, занимает часы, и никто не будет по запросу от тех.поддержки, без аргументации (они даже не смогут сообщить вам, что описываемая вами проблема могла быть исправлена, т.е. попросят обновиться чисто потому что у вас цифервка не последняя) просто так бежать и обновлять систему в которой работает куча людей и на которую, по изначальной идее, завязаны вообще все процессы разработки?

Вывод

Продукт кажется, не то, чтобы базирующийся на MVP, а базирующийся на протипе, после которого решили не делать MVP, а решили пустить в продакшен этот прототип выдав его за production-ready, и допиливать на ходу. А все кривые архитектурные решение так и назвали "текущее архитектурное решение" и платить за эту кривоту должен потребитель. В целом, как мне кажется, когда компания заявляет, что её продукт замена Jira и идёт подобным путём, то она должна быть куда ответственнее к подобным архитектрным решениям. Ведь если вы не вкладываете деньги в изменение кривой архитектуры, то вы перекладываете эти траты на всех ваших пользователей, причём во многократном размере, очевидно