один огромный заказчик с государственным участием, с административным ресурсом, связями в органах и с пониманием, что он диктует условия и по цене и по требованиям
Десять вендоров, из которых только у 7 есть хоть какой-то продукт, из них только 4 способны организовать поддержку и развитие, из них только два способны "заинтересовать" ключевых менеджеров заказчика (иногда даже с ними афиллированы), и имеют достаточно собственного административного ресурса, чтобы получить сертификацию гос регуляторов, если она необходима
Победит тот, кто выживет подковерной политике
Все пункты надуманны и все совпадения случайны
Руководство типичного вендора должно иметь набор особых качеств, которые приведут к победе в таких условиях. Хорошо, если эти качества есть, тогда госзаказ будет, но качественный продукт - под большим вопросом
Для работы же на рынке, где ваш продукт купят "не потому, что заставили", нужен совершенно другой набор качеств. Но гос заказчика с ним не получить, а значит - не выжить.
Ситуация изменится только тогда, когда гос заказчик перестанет быть единственной возможностью для вендора заработать достаточно, чтобы самостоятельно развивать продукт. Но для этого надо дать вздохнуть частному бизнесу, а уж у кого для этого должен измениться набор качеств, я лучше скажу что не знаю
А вот я когда-то давно всего за две минуты зарегал бесплатный акк у atlassian и тащу на нем три проекта в Jira, один из которых - маленький enterprise, я привыкаю к продукту, я выдал доступы своим клиентам, небольшой иностранный мобильный телеком уже смотрит и возможно думает себе заиметь лицензию (странно, но у них ещё нет).. смог бы я аналогично поступить с EvaTeam?
Это ранние произведения, дальше книги взрослеют вместе с авторами, все логично. Багровые тучи и Амальтею и прочие ранние вещи хорошо читать в подростковом возрасте
Ложная слепота - мне показалось что переводчик не вывез сложности задумки автора, в итоге в красоту развязки пришлось просто поверить, вместо того, чтобы понять её. Думал попробовать в оригинале, чтобы проверить - а не автор ли перемудрил, но потом усомнился в целесообразности.. читал в переводе кажется Смушковича
Цифровая трансформация, гибкое решение, комплексный подход, глубокая кастомизация, открытый код, возможности, автоматическая генерация, поддержка ИИ, микросеовисная архитектура - эти слова можно увидеть в рекламных буклетах и сайтах практически любого программного продукта, но они ничего не говорят о том, что на этом продукте реально можно сделать.
Вагон положительных характеристик и ноль информации о назначении систем
Верно ли я понял, что все перечисленные системы предназначены для того, чтобы легко рисовать веб-сайты с формами ввода/вывода данных для работы сотрудников?
Wedotechnologies, ныне Mobileum, уже 20 лет развивает практически то, что описано. Скорость разработки нового функционала просто космическая, и этой разработкой действительно занимаются те же люди, кто вникает в бизнес-требования. Проект для клиента, который мы делали вчетвером 1.5 года имел примерно такую же (если не выше) сложность, как и проект в Альфе, рассчитанный на несколько лет и с командой около 40 человек на старте. Но они не продают это как продукт, они лишь делают на нем проекты для своих клиентов, к сожалению.
Жаль, мало кто понимает преимущества low code, все кормят толпы разработчиков, аналитиков, архитекторов, тестировщиков, девопсов и менеджеров для каждого клиентского проекта, вместо того чтобы держать их только для разработки конструктора, а клиентские проекты отдать тем, кто в одном лице осознает бизнес-требования и сможет собрать функционал из конструктора сам, как мы и делали иногда прямо на глазах клиента, прямо на митинге.
Я в течение 5 лет участвовал в разработке очень сложных промышленных решений на одной очень интересной low-code платформе, и могу сказать следующее:
1) миф об ограниченности применения low-code платформ бытует среди адептов классической разработки лишь только потому, что в широком доступе (к сожалению) нельзя найти и потестировать достаточно "взрослые" платформы. То, что можно найти, по сути предлагает либо простые конструкторы простых веб-сайтов, либо негибкие конструкторы для типовых бизнес-задач вроде склада, онлайн-магазина и т.п., не рассчитанные на масштабирование. Я работал с системой, которая может решить (и решает) очень сложные задачи, связанные с обработкой больших потоков данных в телекомах, процессит сотни гигабайт критичных данных в сутки, реализует коммерческие расчеты с многоуровневыми агрегациями, и при всем при этом позволяет адаптировать бизнес-логику расчетов на лету, что мы и делали, зачастую прямо по ходу совещаний с заказчиком.
2) утверждение, что для разработки на low-code необязательно быть программистом - в корне неверно. Я скажу, что как раз наоборот. Архитектору, у которого в руках мощнейший инструмент, позволяющий собрать сложный функционал в одиночку за полдня, не нужны разработчики совсем, т.к. он соберет этот функционал сам. Поэтому хорошая команда для разработки на low-code - это команда универсальных людей, каждый из которых способен выполнять функции бизнес-аналитика, архитектора и разработчика одновременно. Назовите такого человека как хотите. Он с утра слушает бизнес-требования на совещании с заказчиком, к вечеру готова примерная архитектура, к вечеру следующего дня готов прототип, наутро обсуждение прототипа с заказчиком на предмет соответствия ожиданиям, затем две недели ожидания доступа к источникам, пару дней на отладку, и затем выкат в прод. Я реально работал именно так. Это очень интересно.
3) "в чем же смысл low-code, если для каждый разработчик должен быть архитектором?" - спросите вы. Смысл в следующем: проект в одном иностранном телекоме с сумасшедшими по сложности бизнес-требованиями наша команда из 4-5 человек реализовала за полтора года на low-code, причем оставила огромные возможности для дальнейшего развития функционала. После этого меня занесло в российский финсектор в классический проект разработки "с нуля" с бизнес-требованиями примерно в два раза проще, и на этом проекте только в самом его начале в чате сидело почти 40 человек (аналитики, архитекторы, разработчики, тестировщики, документалисты, менеджеры), проект был рассчитан, если не ошибаюсь, на 4 года с перспективами продления. Результат при этом прогнозировался слабокастомизируемый. Считайте сами.
4) Простота "квадратиков" и "стрелочек" не является препятствием. В хорошем low-code есть пара-тройка типов пустых "квадратиков", которые предлагают написать себя самостоятельно на нескольких доступных языках. "Сделай свой квадратик" - это тоже интересно и мощно.
4) Очень жаль, что подобных платформ пока не найти не то что в свободном доступе, но и за более-менее вменяемые деньги. Лицензия же в 50 тыс евро - не для всех. Я с надеждой присматриваюсь к каждой компании, заявившей себя как разработчик low-code платформы, и очень жду, что кто-то поверит в подобный подход, инвестирует в раработку и сможет реализовать low-code платформу, включающую (в идеале):
конструктор модели данных, отображаемой на несколько типов хранилищ - например, на MySQL, Postgres, Oracle, Hive
конструктор веб-интерфейсов
конструктор отчетов
ETL-инструмент с хотя бы минимальным набором возможностей интеграции с источниками
кейс-менеджмент
Нужна первая версия подобной системы, нужен вывод ее в Open Source, чтобы небольшие команды программистов могли быстро реализовывать средние по сложности проекты за небольшие деньги, накапливали экспертизу, нужно сделать такую платформу известным и зарекомендовавшим себя инструментом, который развивается и совершенствуется, и тогда вендор сможет зарабатывать хорошие деньги на реализации больших и сложных проектов силами небольшого числа специалистов.
Инкрементальную загрузку умеет делать только один ETL-инструмент: RAID от компании Mobileum. Все остальные барахтаются в парадигме "последней даты загрузки" и вылезти из этой песочницы никак не могут, результатом является необходимость отдельных пайплайнов для начальной загрузки и перезагрузки данных, что есть прошлый век.
Типичная картина работы на отечественном рынке:
один огромный заказчик с государственным участием, с административным ресурсом, связями в органах и с пониманием, что он диктует условия и по цене и по требованиям
Десять вендоров, из которых только у 7 есть хоть какой-то продукт, из них только 4 способны организовать поддержку и развитие, из них только два способны "заинтересовать" ключевых менеджеров заказчика (иногда даже с ними афиллированы), и имеют достаточно собственного административного ресурса, чтобы получить сертификацию гос регуляторов, если она необходима
Победит тот, кто выживет подковерной политике
Все пункты надуманны и все совпадения случайны
Руководство типичного вендора должно иметь набор особых качеств, которые приведут к победе в таких условиях. Хорошо, если эти качества есть, тогда госзаказ будет, но качественный продукт - под большим вопросом
Для работы же на рынке, где ваш продукт купят "не потому, что заставили", нужен совершенно другой набор качеств. Но гос заказчика с ним не получить, а значит - не выжить.
Ситуация изменится только тогда, когда гос заказчик перестанет быть единственной возможностью для вендора заработать достаточно, чтобы самостоятельно развивать продукт. Но для этого надо дать вздохнуть частному бизнесу, а уж у кого для этого должен измениться набор качеств, я лучше скажу что не знаю
А вот я когда-то давно всего за две минуты зарегал бесплатный акк у atlassian и тащу на нем три проекта в Jira, один из которых - маленький enterprise, я привыкаю к продукту, я выдал доступы своим клиентам, небольшой иностранный мобильный телеком уже смотрит и возможно думает себе заиметь лицензию (странно, но у них ещё нет).. смог бы я аналогично поступить с EvaTeam?
Это ранние произведения, дальше книги взрослеют вместе с авторами, все логично. Багровые тучи и Амальтею и прочие ранние вещи хорошо читать в подростковом возрасте
Ложная слепота - мне показалось что переводчик не вывез сложности задумки автора, в итоге в красоту развязки пришлось просто поверить, вместо того, чтобы понять её. Думал попробовать в оригинале, чтобы проверить - а не автор ли перемудрил, но потом усомнился в целесообразности.. читал в переводе кажется Смушковича
Цифровая трансформация, гибкое решение, комплексный подход, глубокая кастомизация, открытый код, возможности, автоматическая генерация, поддержка ИИ, микросеовисная архитектура - эти слова можно увидеть в рекламных буклетах и сайтах практически любого программного продукта, но они ничего не говорят о том, что на этом продукте реально можно сделать.
Вагон положительных характеристик и ноль информации о назначении систем
Верно ли я понял, что все перечисленные системы предназначены для того, чтобы легко рисовать веб-сайты с формами ввода/вывода данных для работы сотрудников?
Сумма долей всех ОС на графике около 210%. Заказ нормально отработать вы не смогли
Wedotechnologies, ныне Mobileum, уже 20 лет развивает практически то, что описано. Скорость разработки нового функционала просто космическая, и этой разработкой действительно занимаются те же люди, кто вникает в бизнес-требования. Проект для клиента, который мы делали вчетвером 1.5 года имел примерно такую же (если не выше) сложность, как и проект в Альфе, рассчитанный на несколько лет и с командой около 40 человек на старте. Но они не продают это как продукт, они лишь делают на нем проекты для своих клиентов, к сожалению.
Жаль, мало кто понимает преимущества low code, все кормят толпы разработчиков, аналитиков, архитекторов, тестировщиков, девопсов и менеджеров для каждого клиентского проекта, вместо того чтобы держать их только для разработки конструктора, а клиентские проекты отдать тем, кто в одном лице осознает бизнес-требования и сможет собрать функционал из конструктора сам, как мы и делали иногда прямо на глазах клиента, прямо на митинге.
Я в течение 5 лет участвовал в разработке очень сложных промышленных решений на одной очень интересной low-code платформе, и могу сказать следующее:
1) миф об ограниченности применения low-code платформ бытует среди адептов классической разработки лишь только потому, что в широком доступе (к сожалению) нельзя найти и потестировать достаточно "взрослые" платформы. То, что можно найти, по сути предлагает либо простые конструкторы простых веб-сайтов, либо негибкие конструкторы для типовых бизнес-задач вроде склада, онлайн-магазина и т.п., не рассчитанные на масштабирование. Я работал с системой, которая может решить (и решает) очень сложные задачи, связанные с обработкой больших потоков данных в телекомах, процессит сотни гигабайт критичных данных в сутки, реализует коммерческие расчеты с многоуровневыми агрегациями, и при всем при этом позволяет адаптировать бизнес-логику расчетов на лету, что мы и делали, зачастую прямо по ходу совещаний с заказчиком.
2) утверждение, что для разработки на low-code необязательно быть программистом - в корне неверно. Я скажу, что как раз наоборот. Архитектору, у которого в руках мощнейший инструмент, позволяющий собрать сложный функционал в одиночку за полдня, не нужны разработчики совсем, т.к. он соберет этот функционал сам. Поэтому хорошая команда для разработки на low-code - это команда универсальных людей, каждый из которых способен выполнять функции бизнес-аналитика, архитектора и разработчика одновременно. Назовите такого человека как хотите. Он с утра слушает бизнес-требования на совещании с заказчиком, к вечеру готова примерная архитектура, к вечеру следующего дня готов прототип, наутро обсуждение прототипа с заказчиком на предмет соответствия ожиданиям, затем две недели ожидания доступа к источникам, пару дней на отладку, и затем выкат в прод. Я реально работал именно так. Это очень интересно.
3) "в чем же смысл low-code, если для каждый разработчик должен быть архитектором?" - спросите вы. Смысл в следующем: проект в одном иностранном телекоме с сумасшедшими по сложности бизнес-требованиями наша команда из 4-5 человек реализовала за полтора года на low-code, причем оставила огромные возможности для дальнейшего развития функционала. После этого меня занесло в российский финсектор в классический проект разработки "с нуля" с бизнес-требованиями примерно в два раза проще, и на этом проекте только в самом его начале в чате сидело почти 40 человек (аналитики, архитекторы, разработчики, тестировщики, документалисты, менеджеры), проект был рассчитан, если не ошибаюсь, на 4 года с перспективами продления. Результат при этом прогнозировался слабокастомизируемый. Считайте сами.
4) Простота "квадратиков" и "стрелочек" не является препятствием. В хорошем low-code есть пара-тройка типов пустых "квадратиков", которые предлагают написать себя самостоятельно на нескольких доступных языках. "Сделай свой квадратик" - это тоже интересно и мощно.
4) Очень жаль, что подобных платформ пока не найти не то что в свободном доступе, но и за более-менее вменяемые деньги. Лицензия же в 50 тыс евро - не для всех. Я с надеждой присматриваюсь к каждой компании, заявившей себя как разработчик low-code платформы, и очень жду, что кто-то поверит в подобный подход, инвестирует в раработку и сможет реализовать low-code платформу, включающую (в идеале):
конструктор модели данных, отображаемой на несколько типов хранилищ - например, на MySQL, Postgres, Oracle, Hive
конструктор веб-интерфейсов
конструктор отчетов
ETL-инструмент с хотя бы минимальным набором возможностей интеграции с источниками
кейс-менеджмент
Нужна первая версия подобной системы, нужен вывод ее в Open Source, чтобы небольшие команды программистов могли быстро реализовывать средние по сложности проекты за небольшие деньги, накапливали экспертизу, нужно сделать такую платформу известным и зарекомендовавшим себя инструментом, который развивается и совершенствуется, и тогда вендор сможет зарабатывать хорошие деньги на реализации больших и сложных проектов силами небольшого числа специалистов.
Жаль, что этого не случится.
Я бы сказал, что факт выноса этого на Хабр с именами и наименованиями говорит за то, что они не так уж далеки от истины в оценке culture fitting
Инкрементальную загрузку умеет делать только один ETL-инструмент: RAID от компании Mobileum. Все остальные барахтаются в парадигме "последней даты загрузки" и вылезти из этой песочницы никак не могут, результатом является необходимость отдельных пайплайнов для начальной загрузки и перезагрузки данных, что есть прошлый век.