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

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

А система продолжает развиваться. Есть чёткое ощущение, что усиливая сложность путём тупо кодирования и не выводя на bpmn формализацию, мы полностью перестанем контролировать происходящее.

Есть подозрение, что при сложных бизнес-процессах со сложными взаимосвязями надо использовать машины состояний на основе формализованно записанных бизнес-процессов. Речь идёт о том, что изменение состояния интерфейсов привязать к точкам бизнес-процесса, что позволит понимать в сложных случаях, в какой именно точке находится пользователь.

>Есть чёткое ощущение

Есть чёткое ощущение, что плохо всё. Какие то программисты что то там закодировали. А где продакты? Что говорят QA на тему таких интерфейсов? Почему всё плохо настолько что без влезания в код ничего не понятно без программиста?

Мы собрали каких то людей в кучу. И они что то сделали. Зачем, на основе чего, почему. А хз ))))

Всем привет.
Внесу свои 5 копеек.
Каждый должен изобрести свой процессный движок ;) после чего начать использовать промышленное решение. Например Камунду. И да, процесс должен быть описан прежде чем... Ну вы в курсе ;)

Казалось бы, при чем здесь техдир

+++

я думаю, техдир не микроменеджер и это классно

ребята сами порешали, сами не смогли и пусть сами чинят)

Ты всё время забываешь, что в этом чатике собрались люди такие же, как Ты. Только старше и опытнее.

Это очень правильные вопросы, на которые есть не менее правильные ответы. Но обсуждаются сейчас не они.

Дороговатое решение. А сползти с него не менее тяжело, чем скажем с sap или жиры. В остальном да.

Очень мало, мы буквально месяц-два назад трафик начали пускать

Потом поплакать с полгодика, внедряя комунду.
Потом вепнуться к своему движку, понять чего ему не хватает и сделать наконец нормальное решение))

Это вечная боль и теребоньканье. И конечно зависит от задачи, текущих условий, настроения.
Промышленные решения избыточны и монструозны знаете зачем оно вам - используйте. Хотите свое теплое-ламповое и уверены что сделаете огого, прям нужное - ваше право.
И да, @ctodsimonov прав - это елка на которую легко залезть но тяжело спускаться. Надо хорошо подумать ;)
Наш опыт - использовать пром решение удобнее. Но эт только наш опыт ;)
Если интересны подробности - в личку.

а, что, пятница вечер, почему бы и не спросить Go или Java?

ответ будет очевидный Go или Java

я не понимаю как вообще можно выбирать го в предпочтение современным языкам

Типа F#?

типа всех, где есть аннотации или дженерики

в го есть кодогенерация