Превратите свой ИТ-отдел в движущую силу развития граждан

Недавно я прочитал хорошо проработанную и взвешенную статью Брайана Бейтса о развитии граждан в контексте практик Agile.

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

Однако пространство без кода огромно, и есть варианты, о которых он не знает. Эти варианты резко меняют некоторые предположения, на которых основана его статья.

Но сначала: почему в этой статье изображение глиняной модели автомобиля?

Я считаю, что важно четко понимать динамику рынка, которая проявляется в корпоративных ИТ, и более активно устранять основные причины, чем просто использовать без кода, как описано в статье, и ждать, пока кто-то создаст лучшую систему без кода. день.

Какова динамика рынка и основные причины? Практически полный отказ от применения методов промышленного производства для разработки приложений.

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

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

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

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

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

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

Разница между умением и силой

Давайте возьмем очень простой пример из вашей кухни, разницу между кухонным комбайном и рисоваркой.

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

Теперь рассмотрим скромную рисоварку. Вам нужно следить за этим? Он когда-нибудь сжигал рис? Или недоварить? Нет. Может ли тот, кто никогда в жизни не готовил рис, приготовить идеальную тарелку риса, просто следуя простым инструкциям? Да. Даже лучшие повара-суши, известные своим вниманием к каждой детали, используют рисоварки. Это потому, что в рисоварку встроены навыки. Мастерство не уступает самым лучшим поварам среди людей. И совершенно неквалифицированный человек может использовать его для приготовления риса так же хорошо, как если быон был приготовлен живым лучшим шеф-поваром, а это означает, что больше нет никаких практических ограничений для сколько риса можно приготовить. Это просто вопрос о том, чтобы купить больше рисоварок и нанять первого человека, который войдет в дверь.

Разве кодирование не отличается?

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

А компиляторы используются гораздо чаще, чем вы думаете. Веб-страница, которую вы сейчас читаете, является результатом десятков промежуточных шагов компиляции. Код C был скомпилирован для создания веб-сервера Apache, на котором он, вероятно, работает. Тогда есть ваш веб-браузер. Возможно, вы используете Google Chrome, он был написан на C++ и скомпилирован на ассемблере. Chrome включает движок JavaScript V8, потому что на этой веб-странице есть JavaScript. V8 сначала интерпретирует код, а затем компилирует его, используя компиляцию JIT(Just In Time) для преобразования JavaScript в байтовый код (очень похоже на язык ассемблера) для повышения производительности. Сам JavaScript, скорее всего, изначально был написан на TypeScript, а затем перенесен в JavaScript. Chrome также выполняет аналогичную интерпретацию/компиляцию для HTML и CSS на веб-странице. Опять же, CSS почти наверняка сначала был написан на другом языке, таком как LESS, а затем перенесен в CSS.

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

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

Что это за новые опции?

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

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

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

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

Зачем ИТ-отделу это делать?

Преимущества для бизнеса очевидны, но и для ИТ-отдела также есть много преимуществ. Вот некоторые из наиболее важных:

  • Меньше ошибок. После того, как компонент отлажен, его дальнейшее использование становится безопасным.
  • Истинно Agile. Среднее время разработки нового компонента составляет 2–3 дня. Кому нужно управление проектом?
  • Снижение затрат на управление. Поскольку компоненты предназначены для повторного использования по определению, вся работа разработчиков автоматически окупается, кому нужна стадия/гейт?
  • Работа приносит больше удовольствия. Какому старшему инженеру нравится перемещать кнопку на два пикселя влево? Проектирование для повторного использования по своей сути более интересно, чем выталкивание «компромиссного кода», чтобы «просто сделать это» к какому-то крайнему сроку.

В итоге

Настоящее новое лицо Agility в не обходе ИТ-отдела. Компании пытались это сделать в 90-х, но это не сработало. Реальное новое лицо гибкости коренным образом меняет способ работы ИТ-отдела: перевод его из бизнеса проектов в бизнес платформ, нет кодовые платформы для внутреннего использования.

Адам Захари Вассерман — автор книги Фабрика хаоса: внутренняя история ИТ-отказов, доступной по адресу www.chaosfactorythebook.com.