еще там говорят все "менеджеры уйдут", типа так как работа будет без них, а уйдут эксперты, когда маржинальность поедет в минус и им попросту не чем будет платить. А дальше начинается, а мы найдем новых и обучим и тут внезапно :))) возрастают косты и маржинальность еще дальше уменьшается
именно "миллиона скрытых фактов", товарищи из этой секты забывают сказать , более того лезут в бизнесы, в которых все неплохо работает и без них. Вообще для управления 23 сотрудниками не нужна вся эта бирюза...
1). Через комитет круг по инновациям, там доказываешь, как советские корабли бораздят пространство. Но так как все это зависит от голосов какихто людей, то дальше вступает в ход манипуляции людьми, чтобы эти инновации выделили. И тут будет вопрос зрелости круга инновации
2). При такой модели, самый главные вопрос, "где деньги?" Наверное его можно достичь лишь очень зрелыми людьми - "взрослыми", которые будут к этому относится не как к игре
Адепты бирюзы позиционируют это как свобода собственника, мол все проблемы решаются потом сами. Но жизнь то сильно сложнее. И вы верно заметили "уютное окружение для себя" они обычно там играют, и именно по этой причине, беда с маржинальностью, поищите отзывы про внедрение этой штуковины, искать по слову ***кратия вместо зведочек всякие разные словечки.
вы описали матричную оргструктуру или колодцы, это немного другое, представьте, что у вас руководителей больше чем 7, кто ими руководит и как информация/задачи курируют между отделами, скорее там появится какойто высокостоящий руководитель. А тут в идее, что решение о выталкивании из круга, принимают сами сотрудники...
Но только автор статьи не упомянул о том, что для того, чтобы команда вытолкнула сотрудника, она должна быть зрелой и ответственной, а на вопрос, где найти столько взрослых людей они не отвечают... А именно тут зарыт вопрос маржинальности... Такую структуру можно построить, но на очень зрелых людях...
Так же тут умолчали об одном важном факте, что при внедрении такой структуры, поменяется 80-90% коллектива, готов ваш бизнес к этому? отсюда про сложность бизнеса... одно дело менять медсестру, другое эксперта...
Все верно, NoCode платформу можно сделать только для очень простых задач, шаг вправо или влево = расстрел. Вот с low code платформами можно гораздо больше, если обычному разработчику убрать с помощью нее рутину, тогда открываются интересные возможности...
Обычно все эти платформы сыпятся на элементарной задаче, а покажите мне в этой формочки данные из этого rest....
В общем для себя я отметил, что Camundа используем в исключительных случаях, если можно не использовать, не используем.
хмм, очень интересное дистанцирование, как архитектор я реально почти не вижу в ней пользы, так как без разработчика нельзя ничего изменить, а разработчику она только мешает. Для разработки бизнес логики, хорошо описанной аналитиком, требуются разработчики уровня верх jun или middle, ни каких сеньеров и тем более архов там не требуется (java, phyton,... тут все равно).
Аналитикам бы не понимающим нафига им разрабы, неплохо бы понять, что те 20% которые они не могут сделать, занимают 80% времени :), поэтому пусть лучше пишут доку... Кубики можно и в другом редакторе рисовать...
Как мне кажется, камунда подходит только для условного роутинга скана по какому-то БП, во всех остальных случая - это лишняя хрень, которая очень дорого обходится в саппорте...
к вопросу, а зачем тогда комунда и зачем размазывать все на 2 системы в которых разные роли что то правят... ИМХО они не сойдутся, пока это не будет один человек?
Отладка в камунде это боль, так как контекстом то она не рулит, а рулят микросервисы и действительно это превращается в туже боль отладки микросервисов, особенно если кто то решил намельчить и использовал один паттерн микросервис- одна таблица. А по хорошему то надо, чтобы вся бизнес логика жила в одном sub домене core домена, тогда и проблемы не будет.
Тесты писать безусловно надо, поделитесь как на камунду вы тесты пишите?
Чтобы хранить в камунде данные, надо чтобы они там как то оказались из более надёжного источника данных, вы периодически синхронизируете кучу данных из другой бд?
а кроме Банка точки, есть еще успешные примеры? желательно в технологическом бизнесе. А то про эту точку, все кому не лень говорят.
А если собственник через фасилитатора и лид линка продвигает свою идею? манипулирует...? Вот именно к этому и придет -"возражение неквалифицировано"
поменяется 80-90% персонала, готовы к этому?
еще там говорят все "менеджеры уйдут", типа так как работа будет без них, а уйдут эксперты, когда маржинальность поедет в минус и им попросту не чем будет платить. А дальше начинается, а мы найдем новых и обучим и тут внезапно :))) возрастают косты и маржинальность еще дальше уменьшается
именно "миллиона скрытых фактов", товарищи из этой секты забывают сказать , более того лезут в бизнесы, в которых все неплохо работает и без них. Вообще для управления 23 сотрудниками не нужна вся эта бирюза...
1). Через
комитеткруг по инновациям, там доказываешь, как советские корабли бораздят пространство. Но так как все это зависит от голосов какихто людей, то дальше вступает в ход манипуляции людьми, чтобы эти инновации выделили. И тут будет вопрос зрелости круга инновации2). При такой модели, самый главные вопрос, "где деньги?" Наверное его можно достичь лишь очень зрелыми людьми - "взрослыми", которые будут к этому относится не как к игре
неплохо, что 40 лет средний, может быть поэтому работает? когда зуммеры не пытаются лезть туда , где они нифига не понимают?
верно заметили про маржинальность, обычно с внедрением этой штуки она падает
Адепты бирюзы позиционируют это как свобода собственника, мол все проблемы решаются потом сами. Но жизнь то сильно сложнее. И вы верно заметили "уютное окружение для себя" они обычно там играют, и именно по этой причине, беда с маржинальностью, поищите отзывы про внедрение этой штуковины, искать по слову ***кратия вместо зведочек всякие разные словечки.
вы описали матричную оргструктуру или колодцы, это немного другое, представьте, что у вас руководителей больше чем 7, кто ими руководит и как информация/задачи курируют между отделами, скорее там появится какойто высокостоящий руководитель. А тут в идее, что решение о выталкивании из круга, принимают сами сотрудники...
Но только автор статьи не упомянул о том, что для того, чтобы команда вытолкнула сотрудника, она должна быть зрелой и ответственной, а на вопрос, где найти столько взрослых людей они не отвечают... А именно тут зарыт вопрос маржинальности... Такую структуру можно построить, но на очень зрелых людях...
Так же тут умолчали об одном важном факте, что при внедрении такой структуры, поменяется 80-90% коллектива, готов ваш бизнес к этому? отсюда про сложность бизнеса... одно дело менять медсестру, другое эксперта...
Сколько сотрудников поменялось с начала внедрения?
Сколько выскоквалифицированых сотрудников ушло?
Сколько менеджеров (которые чисто управляли) ушло, сколько таких было, на момент начала внедрения?
Сколько учредителей свалило с момента начала внедрения?
И сам бизнес это что то высокотехеологичное или аля медсестры?
Что с маржой?
Все верно, NoCode платформу можно сделать только для очень простых задач, шаг вправо или влево = расстрел. Вот с low code платформами можно гораздо больше, если обычному разработчику убрать с помощью нее рутину, тогда открываются интересные возможности...
Обычно все эти платформы сыпятся на элементарной задаче, а покажите мне в этой формочки данные из этого rest....
В общем для себя я отметил, что Camundа используем в исключительных случаях, если можно не использовать, не используем.
хмм, очень интересное дистанцирование, как архитектор я реально почти не вижу в ней пользы, так как без разработчика нельзя ничего изменить, а разработчику она только мешает. Для разработки бизнес логики, хорошо описанной аналитиком, требуются разработчики уровня верх jun или middle, ни каких сеньеров и тем более архов там не требуется (java, phyton,... тут все равно).
Аналитикам бы не понимающим нафига им разрабы, неплохо бы понять, что те 20% которые они не могут сделать, занимают 80% времени :), поэтому пусть лучше пишут доку... Кубики можно и в другом редакторе рисовать...
Как мне кажется, камунда подходит только для условного роутинга скана по какому-то БП, во всех остальных случая - это лишняя хрень, которая очень дорого обходится в саппорте...
Вот прям в точку. Можно не писать код, но знать как он пишется обязан
а на каком количестве TPS у вас это просиходило?
к вопросу, а зачем тогда комунда и зачем размазывать все на 2 системы в которых разные роли что то правят... ИМХО они не сойдутся, пока это не будет один человек?
спасибо, этого для понимания достаточно.
Если я правильно понял, у вас тесты на камунду пишет разработчик сервисов, а не разработчик BPMN(Аналитик)?
И что будет с тестами, если аналитик стрелочку в другое место направит, потому что так бизнес решит?
Отладка в камунде это боль, так как контекстом то она не рулит, а рулят микросервисы и действительно это превращается в туже боль отладки микросервисов, особенно если кто то решил намельчить и использовал один паттерн микросервис- одна таблица. А по хорошему то надо, чтобы вся бизнес логика жила в одном sub домене core домена, тогда и проблемы не будет.
Тесты писать безусловно надо, поделитесь как на камунду вы тесты пишите?
Чтобы хранить в камунде данные, надо чтобы они там как то оказались из более надёжного источника данных, вы периодически синхронизируете кучу данных из другой бд?
А можно чуть подробнее?
В смысле процессы падали?