Alex.Miller
Member
Когда три года назад наша команда столкнулась с потоком мелких запросов от бизнес-отделов, я почти сдался. Каждый месяц десятками приходили просьбы: дашборд для аналитики, форма сбора заявок, автоматическое согласование договоров. Разработчики уходили в долгую разработку, а бизнес нервничал. Тогда мы дали продукт-менеджеру доступ к Mendix и посмотрели, что произойдёт. Через две недели он собрал то, на что раньше уходило два спринта.
Нажать чтобы Перейти на сайт
Первое чувство — паника. Я реально думал, что low-code убьёт мою команду. Но через полгода картина стала другой. Да, часть рутинных задач ушла от разработчиков, зато освободилось время на сложную архитектуру, интеграции и оптимизацию, которые никто в low-code не решит. Мы перестали быть «поставщиками тикетов» и стали полноценными партнёрами бизнеса.
При этом low-code не без проблем. Уже через восемь месяцев мы уперлись в потолок: платформа не позволяла делать нужные интеграции с legacy-системами, производительность падала при росте нагрузки, а отладка превращалась в квест. Мы потратили месяц на то, чтобы перевести критичный модуль обратно на Python и FastAPI. Но это был осознанный выбор, а не откат назад.
Сегодня я смотрю на low-code как на инструмент, который меняет роль разработчика, а не отменяет её. Мы переключились с написания кода на проектирование архитектур, наставничество и решение нестандартных задач. При этом продукт-менеджеры и бизнес-аналитики получили самостоятельность и перестали ждать нас в очереди. Скорость доставки решений выросла в три раза, а количество багов в продакшене — нет, потому что критичную логику мы по-прежнему пишем руками.
Узнать подробнее →
Мой личный вывод после трёх лет практики: low-code не убивает разработчиков. Он убивает разработчиков, которые не хотят расти. Если ты готов уйти от написания CRUD-ов в архитектуру, безопасность, DevOps и менторство — ты станешь ценнее, а не дешевле. А если нет — да, тебя действительно заменит безкодовый конструктор за пару лет.
А вы сталкивались с low-code в своей практике? Помогает он вашей команде расти или создаёт новые проблемы? Расскажите в комментариях — интересно узнать, как другие выстраивают баланс между кодом и конструкторами.
По теме советую почитать: Cloud-решения для масштабирования стартапа: мой опыт
Нажать чтобы Перейти на сайтПервое чувство — паника. Я реально думал, что low-code убьёт мою команду. Но через полгода картина стала другой. Да, часть рутинных задач ушла от разработчиков, зато освободилось время на сложную архитектуру, интеграции и оптимизацию, которые никто в low-code не решит. Мы перестали быть «поставщиками тикетов» и стали полноценными партнёрами бизнеса.
При этом low-code не без проблем. Уже через восемь месяцев мы уперлись в потолок: платформа не позволяла делать нужные интеграции с legacy-системами, производительность падала при росте нагрузки, а отладка превращалась в квест. Мы потратили месяц на то, чтобы перевести критичный модуль обратно на Python и FastAPI. Но это был осознанный выбор, а не откат назад.
Сегодня я смотрю на low-code как на инструмент, который меняет роль разработчика, а не отменяет её. Мы переключились с написания кода на проектирование архитектур, наставничество и решение нестандартных задач. При этом продукт-менеджеры и бизнес-аналитики получили самостоятельность и перестали ждать нас в очереди. Скорость доставки решений выросла в три раза, а количество багов в продакшене — нет, потому что критичную логику мы по-прежнему пишем руками.
Узнать подробнее →Мой личный вывод после трёх лет практики: low-code не убивает разработчиков. Он убивает разработчиков, которые не хотят расти. Если ты готов уйти от написания CRUD-ов в архитектуру, безопасность, DevOps и менторство — ты станешь ценнее, а не дешевле. А если нет — да, тебя действительно заменит безкодовый конструктор за пару лет.
А вы сталкивались с low-code в своей практике? Помогает он вашей команде расти или создаёт новые проблемы? Расскажите в комментариях — интересно узнать, как другие выстраивают баланс между кодом и конструкторами.
По теме советую почитать: Cloud-решения для масштабирования стартапа: мой опыт