Русский
Русский
English
Статистика
Реклама

Рынок ит-услуг

Из песочницы Как стать специалистом по кибербезопасности? Страх и ненависть в ИБ

14.11.2020 18:04:39 | Автор: admin

Очередной раз начали появляться новости с аналитикой будто уже в следующие пару лет на рынке будет катастрофическая нехватка специалистов в области информационной безопасности (сократим до аббревиатуры ИБ). По версии ХХ в России не хватает уже порядка 30 тысяч специалистов. Звучит перспективно с точки зрения карьеры низкая конкуренция, иди и работай. Однако, как выглядит карьера ИБшника на Российском рынке?


У меня на этом рынке стаж работы приближается к круглой дате, если не считать профильное образование в этой области и за это время сформировалось устойчивое мнение о рынке ИБ в России и карьере в этой области. Дальше об этом речь и пойдет. Всё описанное дальше скорее для тех, кто решает ворваться (на самом деле достаточно просто шагнуть) в этот рынок или посмотреть на что-то другое.


Часто на разных ресурсах специализацию в области ИБ описывают как нечто сложное, загадочное, неопознанное и романтичное. В основном у всех, кто ещё не знаком с этой областью работа в ИБ ассоциируется непосредственно с хакерами и создается впечатление, что все ИБшники обладают этими навыками (взламывают сайты, крадут пароли, пробивают по IP и т.д.). Из-за этого вход на этот рынок выглядит максимально сложным и кандидату чаще кажется невозможным устроиться на работу ИБшником, не обладая этими знаниями. Однако, реалии таковы, что большинство специалистов ИБ даже не представляет, как это происходит. Более того значительная часть специалистов не особо и в ИТ разбираются. От чего же это так?


Рынок ИБ делится так же, как и все остальные рынки на заказчиков и исполнителей. Начнем с описания работы на стороне заказчиков.


Основными заказчиками на рынке ИБ выступают Государственные организации (далее сокращу просто до слова ГОСы, банки, крупный и средний бизнес. Так сложилось, что половина моего трудового стажа прошла именно в Государственных организациях. О специфики работы в этом секторе можно написать книгу, но, всё же, постараюсь сократить до необходимого минимума.


Начнем с того, что главное задачей в ГОСах в ИБ является не защита от злобных хакеров и вредоносного программного обеспечения, а выполнение законодательных и отраслевых требований, и это является главной проблемой на Российском рынке. Зачастую в этом секторе важнее понимать какие законы в области ИБ существуют, как они трактуются, как они касаются конкретной организации и как их можно обойти закрыть. По факту это работа с бумажками: составление внутренней распорядительной документации, регламентов и положений, связанных с государственной и коммерческой тайнами, а также обработке информации, связанной с персональными данными или данными для служебного пользования. Здесь требуется знать как категорировать информацию, какая часть информационной системы к какой категории относится, и какими средствами защиты это должно закрываться (последнее описано курирующими государственными службами), и нужно ли вообще это защищать. При этом при всем, есть ещё отраслевые требования, которые могут быть шире, чем законодательные требования, приказы и положения. В этих секторах нет устоявшегося стандарта расположения блока ИБ в штате организации. ИБшники могут как существовать в блоке ИТ, так и в отдельном управлении. Однако, техническая сторона ИБ (внедрение средств защиты информации, настройка и сопровождение) ложится на блок ИТ (и это не только в ГОСах так). Связано это с тем, что бюджет на информационные системы как на актив ложится именно на блок ИТ. Отсюда возникает другая проблема бюджет на обеспечение средствами защиты информационной системы организации формируется именно в блоке ИТ. Из-за этого ИБшники и ИТ постоянно воюют за приоритезацию бюджета. При этом, если блок ИБ не сможет донести до руководства ИТ необходимость закупки того или иного решения ИБ, то в бюджетный план на следующий год это и не попадет. У высшего руководства тоже не всегда получается добиться поддержки, потому что в данном случае нужно описывать также экономическую целесообразность закупки того или иного решения (или сервиса). А как показать возможный финансовый ущерб от хакерской атаки, если она в этой организации ещё не возникала? Да и большинство организаций уверены, что их никто не атакует и они никому не нужны. В итоге приходится жить с тем, что имеешь!


image


Однако, недопонимание встречается не только со стороны ИТ, но и ИБ из-за отсутствия необходимых технических компетенций (а когда им их повышать, если они только что и делают, так это пишут проклятые бумажки): требования законодательства обязуют использовать в информационных системах средства от несанкционированного доступа, которое жрет достаточно много компьютерных ресурсов так ещё и является агентским решением, которое должно устанавливаться на каждую рабочую станцию в организации. А если это предприятие с 4к пользователями, где парк машин с ОС Windows 7 и не потому, что сложно закупить (хотя это тоже требует не мало финансов) новые версии Windows 10, а потому что этот парк компьютеров устаревший и не потянет эту операционную систему, а тут ещё и агент средства защиты информации будет жрать ресурсы как бешеный.


В итоге для того, чтобы внедрить только одно решение уже потребуется обновить парк компьютеров! Просто представьте сколько это денег! А они не у каждого ГОСа есть, а зачастую ещё главная отраслевая компания распоряжается этими финансами, а не само предприятие.


Конечно, это не везде так, но из-за таких ситуаций рабочими обязанностями обычного специалиста являются задачи по маранию бумаги. Не идет речь о работе с какими-то инцидентами информационной безопасности, нет работы с технической составляющей (напомню этим занимаются ИТшники). Отсутствует даже возможность узнать на сколько текущая ситуация в компании расходится со стандартами ИБ. Уже через год такой работы молодой специалист полезет на стенку от скуки, и эта работа будет больше связанна с менеджментом вопросов ИБ, вот такая романтика.


Проработав год в такой компании, единственное, чему вы научитесь, это выполнять требования ИБ в конкретной организации, у вас не появится каких-то специфичных знаний в области ИБ, которые в дальнейшем вам помогут успешно продвигаться по карьерной лестнице (хотя каждый себе сам ставит потолок), расширить кругозор не получится.


Несомненно, вы начнете разбираться в законодательной базе, это полезно. Но для того, чтобы изучить эту базу и понять требуется не так много времени. Для такой работы не требуется специфических знаний в ИБ. Но HR упорно продолжают писать в требованиях, что вы должны знать как работать с различными средствами защиты информации, знать всю законодательную базу, иметь высшее специализированное образование и вообще опыт работы не менее 3-х лет (это всё там даже применить не получится). А ЗП предложат всего 60-80к. Не так давно увидел объявление одной такой крупной компании в Москве:


image


Наименование такого прекрасного работодателя закрасил, но если вдруг кто заинтересовался, то по этому описанию и сами сможете определить.


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


Но за пределами госсектора всё обстоит гораздо лучше. Там не все относятся к ИБ так, будто главная задача это защититься от законодательных требований. В банках и крупных коммерческих организациях чаще всего уже сформирована финансовая оценка информационных активов компании и выбить бюджет на защиту этих активов у руководства не является сложной задачей. Нет требований к конкретным средствам защиты информации (здесь имеется в виду, что в некоторых государственных компаниях в отраслевых требованиях прописано у какого производителя закупать то или иное решение ИБ). Здесь и руками дадут пощупать и заставят разбирать вопросы легитимности того или иного инцидента ИБ, возникшего в инфраструктуре компании, да и ИТ с ИБ дружат лучше. И в этих секторах подбор специалиста будет уже более узконаправленный: под задачи менеджмента ИБ, сопровождения средств защиты информации, безопасную разработку программного обеспечения организации, поиск уязвимостей в инфраструктуре нанимаются отдельные специалисты, которым не вменяют в задачи делать всё подряд. Но надо учитывать, что большинство компаний не проявляют желания плодить разный парк производителей средств защиты информации (сократим до СЗИ) у себя в инфраструктуре. И это нормально, не всё так хорошо интегрируется с различными СЗИ. Подружить из между собой не всегда решаемая задача. Поэтому не особо надейтесь расширить свой кругозор по линейке производителей, но это и ненужно.


Освоив один класс решений, вы сможете уже интуитивно понять, как работать с решением другого производителя. В таких компаниях вы получите знания как работать с нормативной базой в этом секторе, будь то банк или промышленное производство, поймете, как выглядит модель угроз конкретно для вашего сектора, возможно, даже получите опыт управления проектами ИБ, взаимодействуя с подрядчиками. Такой опыт ценится на рынке, да и уровень зарплат в таких компаниях выше, чем в госсекторе.


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

Подробнее..

О рынке Data Science и машинного обучения

05.03.2021 16:08:13 | Автор: admin
image

Волею судьбы мне посчастливилось последние 1,5 2 месяца заниматься анализом рынка Data Science и Machine Learning. И появилось желание об этом написать хотя бы несколько строк. Так что скорее всего получится небольшая заметка, а не основательная статья.



Подразделения маркетинга в крупных компаниях


Data Science здесь востребован для анализа продаж, рынков, сегментации клиентов и исследования их поведения. Скорее всего в данном случае работа аналитика в большой степени сводится к агрегированию данных, построению дашбордов и настройке маркетинговых кампаний. Последняя задача это задача оптимизации, внутри которой строятся модели предсказывающие реакцию клиента на рекламу, всевозможные акции и скидки при распродаже.

Управление рисками в Банках и страховых компаниях


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

R&D лаборатории


R&D Research and Development. В рамках работы таких лабораторий часто проводятся фундаментальные исследования с разработкой новых алгоритмов и архитектур машинного обучения. Специалисты, которые требуются в таких областях, намного в большей степени специализируются и глубже копают, чем классические дата-сайентисты. Профессионалы в R&D часто называют себя инженерами машинного или глубокого обучения или просто математиками.
Вот несколько примеров задач: разработка обучаемых агентов в компьютерных играх, управление роботизированной техникой, беспилотные летательные аппараты, автономное вождение.

Продуктовые стартапы:


Эпоха стартапов пока еще не закончилась. По прежнему остается популярной тема запуска стартапов и венчурного инвестирования. Главная особенность данной сферы ориентация на цельный продукт. Машинное обучение, если и используется, то главный фактор его полезности это повышение usability продукта и user experience (UX).

Например, мобильное приложение дополненной реальности для детей. Популярность такого приложения может в большей степени зависеть не от бездушной метрики качества, а от яркости и зрелищности картинки. Еще один пример: чат-бот для обучения английскому языку или просто для фана. Метрики качества совсем не очевидны. Чат-бот может высказаться и не в тему, а это будет звучать прикольно и наберет просмотры, клики и лайки. Нетрудно догадаться к чему я здесь веду. Заработать такого рода приложения или сайты могут как минимум на рекламе.

Интеграторы, IT-консалтинг


Компании-интеграторы и консалтинговые услуги востребованы, поскольку агрегируют опыт и знания. Их главная ценность заключается в человеческом капитале. Для запуска любого проекта с автоматизацией и машинным обучением требуется знание сразу множества профессионалов из совершенно разных сфер. Ни один человек не в состоянии совместить в себе одновременно экспертизу в лучших отраслевых практиках (банкинг, ритейл, реклама, социальные медиа) и знание всего технологического стека. Яркий пример, практика MLOps (подмножество практик DevOps в применении к машинному обучению) предлагаемая компанией Неософт. Альтернативный вариант перевода бизнеса на новый уровень заключается в найме целой команды, а это делается на за два щелчка пальцами.

Вендоры и разработчики ПО


Автоматизация и модернизация бизнеса строится с одной стороны на готовых решениях, а с другой стороны не может обойтись без кастомизации. Задача кастомизации под конкретную инфраструктуру и модель бизнеса конечно же может решаться и интеграторами на уровне настроек покупного готового ПО. Но часто для того, чтобы получить конкурентное преимущество компания должна доносить до рынка какое-то свое уникальное сервисное или продуктовое предложение. К примеру, сторонних разработчиков вроде EPAM привлекают даже такие компании, как Google или Facebook.

Технологические IT-компании гиганты и платформы


Среди технологических гигантов ну кончено же можно назвать поисковики (Google, Yandex), онлайн-торговлю (Amazon, Alibaba), социальные сети (Facebook, Instagram, WeChat). Эти ребята, если им что-то нужно, частенько покупают стартапы и компании целиком и делают из них свои внутренние структурные подразделения.

Устойчивая тенденция в последние годы связана с переходом всего и вся на облачные платформы. В связи с чем строятся целые экосистемы сервисов-партнеров на базе таких платформ как Azure, AWS или Google Cloud. В частности данные сервисы предлагают кастомизированный доступ к возможностям machine learning и data mining.

Итог:


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

Low-code с точки зрения разработчиков есть ли плюсы для инженеров?

13.04.2021 16:13:10 | Автор: admin

В прошлой статье о low-code в enterprise-решениях я обращался к бизнесу. Однако на Хабре бльшая часть пользователей инженеры (Кэп!), и в комментариях к статье я увидел резонное количество типичных возражений по LCDP (low-code development platforms). И пока те, кто не знает про Эффект Даннинга Крююгера, уже ищут кнопку dislike, давайте разберем наиболее частые заблуждения и мысли.

В этой статье я хочу разобрать наиболее частые заблуждения.

  1. Low-code это использование готовых продуктов.

  2. Под low-code понимают развитые code-first платформы. Кто-то из коллег приводил в пример даже WordPress.

  3. В low-code отсутствует нормальный DevOps (code review, versioning, deploy, etc.), нормальное переиспользование кода и прочие абстракции.

  4. Разработчикам лучше писать код с готовой ценностью, а не разрабатывать конструкторы.

  5. Low-code можно не понимать, это какой-то артефакт. Мы продолжим кодить как обычно. Впрочем, некоторые разработчики и про DevOps до сих пор не всё понимают и думают, что это должность. Так что с low-code ситуация не уникальна.

Кратко о состоянии отрасли

Потребность в разработке растёт. Дефицит специалистов в отрасли сейчас легко отследить на примере роста окладов: он опережает рост производительности труда в IT-сфере.

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

Расходы на разработку увеличиваются, и одновременно возникает конфликт интересов: бизнесу нужно меняться быстрее, а разработчики хотят интересных задач. Но бльшая часть изменений у бизнеса неинтересная.

На подобные вызовы IT-отрасль всегда отвечала повышением уровня абстракции и упрощением разработки. Эпоху ассемблера сменила эпоха C++, затем наступила эпоха высокоуровневых языков с полным отсутствием управления памятью и ресурсами и далее количество фреймворков и библиотек только увеличивалось.

Нет никаких предпосылок к изменению этого тренда. Давайте порассуждаем, сможет ли low-code продолжить его.

Low-code это не философия?

В Рунете каждая статья о low-code заканчивается комментариями о несовершенстве конкретного продукта (продуктов). Отдельно о продуктах поговорим чуть ниже, а для начала предлагаю подумать о концепции low-code в целом.

Философия code-first

Разработчики поставляют заказчику конечную ценность. Вёрстка элементов, новые поля в сущностях, логика расчёта и потоки интеграции всё это реализуется через программный код. Да, у него бывают какие-то настройки, которые иногда позволяют вносить изменения без привлечения разработчиков. Но на большую часть change requests всё-таки отвечают разработчики.

При этом у разработчиков неизбежно возникают два желания.

  1. Как бы нам писать только интересный код, а скучные операционные задачи передать кому-нибудь другому? К нам пусть обращаются лишь в редких кейсах, количество которых в идеале должно уменьшаться и дальше.

  2. Если нас и просят об операционных изменениях, пусть делают это более конкретно. На коммуникацию должно уходить меньше времени. И хотелось бы, чтобы разбираться в собственном коде, который, возможно, полгода никто не трогал, было проще.

В code-first реализовать эти желания не получается.

Философия low-code

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

  • Являются самодокументируемыми в подавляющем большинстве случаев.

  • В каждом компоненте есть настройки, которые делают его переиспользуемым.

Здесь важно отметить, что в code-first платформах тоже много настроек, и они даже разнесены по компонентам. Однако на практике их применение не позволяет снять с разработчика большую часть операционной работы.

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

  • Если требуется какая-то очень эксклюзивная логика (один из компонентов отсутствует) и эта логика явно не будет переиспользуемой, вы сможете вставить нужный компонент, написав небольшой кусочек кода. В отличие от code-first систем, здесь не нужно писать весь модуль или микросервис вы вставите код в нужный фрагмент без сервисной обвязки (сахара). Часто такой код легко читается не только разработчиком, но и опытным менеджером или бизнес-аналитиком и состоит из 220 строк.

Сталкиваясь с новым требованием, вы или собираете новый функционал в уже созданном конструкторе, или дописываете в нём активити и компоненты, если они отсутствуют.

Если посмотреть на low-code разработку глазами code-first разработчика, то меняется в первую очередь уровень абстракции компонентов. Кроме привычных сервисов, библиотек, конструкторов, есть ещё один, более высокий уровень абстракции абстракция бизнес-логики.

Это справедливо и при использовании готовых LCDP, и при разработке в парадигме low-code.

Low-code путают с развитыми code-first платформами

В дискуссиях я раз за разом сталкиваюсь с тем, что под low-code понимаются просто очень гибкие системы. Например, Битрикс потому что в нём же есть бизнес-процессы и моделирование таблиц или WordPress.

LCDP это такая платформа, в которой всё сделано на базе конструктора, ведь если это не так, рано или поздно поддержание такой платформы перейдёт в code-first.

Я бы обозначил следующие критерии LCDP.

  1. Ядро системы содержит только элементы конструктора и всё, что к нему относится, т. е. вам не придётся применять code-first подход для реализации того, для чего предназначена LCDP.

  2. В графическом редакторе можно вставить код там, где он нужен. А в некоторых платформах можно и слегка переопределить код текущего компонента.

Приведу излюбленные нами примеры.

  • ETL / ESB Talend low-code механизмы для построения интеграций.

  • Mendix, Pega, Appian, OutSystems, Caspio как платформы для создания приложений разного класса.

  • Reify, Builder.io, Bildr для фронта.

  • Из новичков 2021 года Corteza (полностью open-source, Go + Vue.js), Amazon Honeycode.

  • Для игроманов давно ли вы смотрели на Unity и продукты на его основе? Видели ли Construct?

  • Российские ELMA BPM, Creatio (разработка Террасофт) и Comindware, универсальная CUBA Platform, Jmix.

  • Продукты особо крупных вендоров Microsoft Power Apps, Oracle APEX, Salesforce Platform, IBM BAS, SAP BTP.

  • Частично open-source Builder.io (фронт), Bonita, Joget.

Есть и пограничные случаи. Например, Pimcore, которая в части фронта, workflow, моделирования инфомоделей с калькулируемыми полями является по своей сути low-code (с некоторыми оговорками, но это не тема данной статьи). Если же пытаться делать что-то за рамками этого, вы свалитесь в традиционное поддержание монолита.

Или тот же Битрикс. В нём удобно моделировать данные и строить бизнес-процессы, в которые при желании упаковывается PHP-код в low-code стиле (т. е. без длинных инициализаций). Однако огромный объём коробочного функционала, созданного не в LCDP-стиле, и отсутствие развитых инструментов low-code в других частях приводят к традиционному code-first.

Короче, если вы слышите, что мы пробовали low-code платформу и у нас ничего не получилось, советую разобраться в деталях. Может быть:

  • это была не LCDP;

  • это была действительно плохая LCDP (такого сколько угодно);

  • команда пыталась писать в LCDP больше кода, чем нужно. Вместо переиспользуемости один кастомный компонент, куда вставляется огромная портянка кода, мы встречали такое!

Low-code не содержит традиционных средств контроля, привычных разработчику (code review, deploy)

Это миф. Вы найдёте эти компоненты в подавляющем большинстве платформ. Многие (Mendix, Pega) имеют собственные CI с элементами low-code.

Хотя, безусловно, проводить ревью не всегда просто. Если с кодом компонентов всё понятно там всё так же, как и в традиционном code-first, то по поводу того, что можно сделать в конструкторе

Представьте, вы разработали на Unity ходилку-стрелялку, поменяли стены, добавили горы, а потом сохранили и отправили всё это на ревью. Понятно, что версионировать изменение каждой стены вы не станете, и у вас будут огромные версии изменений, разобраться в которых в принципе будет достаточно сложно. Тем более когда дело касается визуальных изменений и вставок кода. Процесс ревью это осложняет в той мере, в какой увеличивается количество изменений за один коммит.

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

Разработчикам лучше писать код с готовой ценностью, а не разрабатывать конструкторы

Разработчики обычно брезгливо относятся к самой идее того, что могут что-то накликать мышкой. Между тем подавляющее большинство задач разработчика не rocket science, а рутина. Та самая, которой заниматься неинтересно и от которой хочется побыстрее избавиться.

В рамках проекта вы ограничены в выборе задач. Маловероятно, что к вам будут попадать исключительно интересные и креативные (это подразумевает, что кто-то другой займётся скучными задачами, и тогда всё вышесказанное применимо и к этому бедному человеку). Совсем не заниматься мелкими, а порой и однотипными, скучными вопросами почти невозможно. Просто потому, что кто-то ими должен заниматься.

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

Чем быстрее вы закрываете скучные задачи, тем больше времени у вас освобождается на более интересные. Более того, вы статистически чаще будете получать интересные задачи, потому что перерыв на рутину сократится в разы.

А что с реально талантливыми разработчиками, теми, кто любую самую сложную задачу делает изящно и быстро?

Сдав задачу в виде кода и получив через полгода change request, они сталкиваются со следующим:

  • надо вспомнить, как тут что написано;

  • надо бы отрефакторить код быстро устаревает.

Но очень редкая команда подписывается под рефакторинг. И редкий бизнес-пользователь поймёт, почему минорную правку ему оценили в несколько дней.

Что в итоге? Мы хотели писать интересный код, но через какое-то время ничего интересного не пишем. Нам остаются операционка и угрызения совести за то, что тут всё уже не очень красиво.

Если же вы мыслите в плоскости LCDP, дело не ограничивается только более быстрым решением рутинных задач. Рефакторинг происходит не на уровне конечных ценностей, а на более высоком уровне абстракции на уровне реализации компонента конструктора. Как следствие, вам приходится больше думать и больше проектировать. Меньше областей остаются без вашего надзора, сделать плохо поддерживаемую задачу в LCDP намного сложнее ввиду того, что как минимум плохой нейминг или плохую логику могут обнаружить даже не разработчики. Сам подход заставляет вас больше мыслить абстракциями.

Лирическое отступление. Многие тимлиды конкретно для себя решают эту задачу так: реализацией занимаются другие члены команды, а они думают. Ни к чему хорошему это не приводит. Такие тимлиды часто начинают скучать по коду, а команда в целом становится более хрупкой. Антихрупкость таких людей обеспечивается за счёт хрупкости других членов команды, которые выступают в качестве машинисток. Этому пороку могут быть подвержены и традиционные, и low-code разработчики.

Low-code можно не понимать, это какой-то артефакт. Лучше продолжим кодить как обычно

Можно не думать о будущем разработки, если допустить, что:

  • количество задач для разработчиков будет расти не медленнее, чем количество самих разработчиков и субститутов разработки (с учётом повышающейся производительности труда);

  • бизнес сможет оплачивать растущие аппетиты разработки и не разорится при этом (т. е. ROI в IT всегда будет положительным);

  • другие типы инвестиций не будут конкурировать с инвестициями в IT.

Давайте проведём мысленный эксперимент и прикинем, насколько всё это вероятно в реальной жизни.

Количество задач для разработчиков будет расти не медленнее, чем количество самих разработчиков и субститутов разработки

Сейчас дефицит разработчиков в мире около 10%. Я не могу предсказать будущее, но могу представить, какие условия нужны, чтобы этот дефицит оставался всегда.

Первое: производительность разработчиков не должна повышаться настолько, чтобы она могла компенсировать разницу в дефиците (т. е. на 10% относительно нынешней производительности).

Второе: количество разработчиков не должно расти быстрее, чем количество задач. Дополнительное условие количество субститутов разработки не должно снижать этот дефицит.

А это противоречит фундаментальному закону спроса и предложения, ведь спрос всегда балансируется предложением до равновесного значения.

Что мы видим сейчас?

  • Огромное количество людей или думают о переквалификации в IT, или уже находятся в процессе переквалификации. По данным опросов, каждый пятый разработчик не имеет профильного образования и пришёл в IT после окончания курсов. И это не считая повальных курсов программирования даже с детского сада и школы и всё увеличивающегося потока студентов IT-специальностей в вузах. IT начинает отбирать потенциальных специалистов у других специальностей. Этот маховик раскручивается медленно, но верно.

  • В отчётах инвестиционных банков рынок no-code решений (которые являются прямыми субститутами разработки) уже сейчас выглядит примерно так. И если вы посмотрите на этот список, то увидите, что количество продуктов растёт. Наберите в поисковике название любой компании low-code/no-code и вы поймёте, что почти все от российского Сбера до американской Apple думают о том, как существенно повысить производительность труда в разработке.

  • В конце концов, дисбаланс на рынке труда легко прослеживается на соотношении стоимости управленцев (на которых лежит бльшая ответственность и на которых завязаны мультипликаторы) и мидлов (на которых ответственности существенно меньше). Разрыв по доходам в 34 раза, и это не случайность.

При 20 миллионах разработчиков в мире одна только Индия поставляет на рынок по миллиону разработчиков ежегодно (с ежегодным увеличением этого количества), т. е. существует некоторая вероятность, что в будущем дефицит разработчиков может не сохраниться. Есть и более радикальные суждения: у Германа Грефа, например, или у футуролога Герда Леонгарда.

Бизнес сможет оплачивать растущие аппетиты разработки и не разорится при этом

Чем дороже разработка, тем больше разрыв между технологическими компаниями и всеми остальными. Те, остальные, вынуждены встраиваться в экосистемы гигантов. А экосистемы гигантов имеют очень высокую производительность труда (в силу объёмов). Это само по себе заставляет компании уходить в чужие экосистемы.

Было время, когда затраты на IT были несущественными. Но программное обеспечение становится всё более сложным и разнообразным, и стоимость ИТ-инфраструктуры является значимым фактором для стартапов и одной из основных статей бюджета. Чем дороже IT, тем больше субститутов для инвестиций.

Другие типы инвестиций не будут конкурировать с инвестициями в IT

Почему в IT сейчас много денег? Организации видят в цифровизации хорошо окупаемые инвестиции. Волна цифровизации пройдёт (все компании будут в какой-то степени диджитализированы, а прочие уйдут с рынка), нужно будет сопровождать и поддерживать применённые решения. При всё растущей стоимости IT не встанет ли вопрос о поиске иных источников заработка?

Не станет ли на каком-то этапе стоимость IT столь значимой, что будет автоматически отсекать большую часть новых ныне рентабельных проектов?

В заключение

Я рекомендую разработчикам посмотреть в сторону low-code и как минимум выполнить несколько задач на любой из таких платформ для расширения собственных границ.

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru