Привет, Хабр!

Продолжаю делиться дискуссиями из нашего телеграм-канала Dev Q&A. На этот раз собрались поговорить о том, почему при всём богатстве инструментов — Kubernetes, CI/CD, low-code, AI-ассистенты — разработка не становится ни быстрее, ни дешевле. 

Компанию мне составили: Андрей Почтов (СТО АЭРО), Руслан Остропольский (Test IT), Алексей Каньков (Revizto), Антон Новожилов (mrnet), Генри Бабенко (Tech Lead), Яна Шакленина (Outlines Tech) и Алексей Граков (Agizo). 

Собрал ключевые мысли в статью. Получилось про три столпа эффективности, про хаос который понятнее порядка, и про то, почему скрам по книжке остановил компанию на две недели, а Waterfall принёс миллиард. 

Полная запись — в канале. А здесь — самое интересное, от третьего лица, включая мои собственные реплики как участника.

Когда говорят об эффективной разработке, обычно имеют в виду инструменты: какой CI/CD выбрать, нужен ли Kubernetes, стоит ли переходить на микросервисную архитектуру. Но инструменты — это только видимая часть.

«Эффективная разработка стоит на трёх столпах: технологии, процессы и люди. Причём в процессах зачастую больше проблем, чем в технологиях, — говорит Андрей Почтов, СТО компании АЭРО. — Если думать о том, как сделать разработку эффективной, нужно понимать окружение, которое ты строишь. Стартап на ранних этапах — там свой подход, довольно бережливый, с минимумом людей. Банк — двухнедельные релизные циклы, высокая отказоустойчивость, потому что стоимость падения гораздо выше. В рамках этих трёх столпов — технологии, процессы, команды — и выстраивается вся работа. Ты выбираешь подход, который на первый взгляд наиболее подходит к ситуации, а дальше тюнишь под свои ограничения. Не нужна платформа ради платформы. Не нужны процессы ради процессов. Есть то, что работает, — и то, что не работает».

Универсальной формулы эффективности не существует. То, что спасает стартап, убьёт корпорацию — и наоборот. Руслан Остропольский, директор по продукту Test IT, прошёл этот путь сам:

«Я работал и в стартапах, и в компаниях, которые вырастали в небольшие корпорации. Проходил все этапы. На стадии стартапа эффективность — это быстро запускать. У нас было правило: новый продукт за две недели. Цель — просто выжить и не умереть. Когда выросли до 50+ команд, эффективность стала про другое — насколько команды между собой умеют взаимодействовать. От этой зрелости зависит, нужен ли вам большой конвейер или можно обойтись костыльными инструментами и запускать быстро. Когда компания очень зрелая, цена ошибки дорогая — нужен полноценный пайплайн. А на ранних этапах один толковый инженер запустит продукт быстрее, чем команда, которая полгода будет настраивать инфраструктуру. Или у вас тысячи разработчиков, и автоматизация экономит каждому по два часа — тогда это большая эффективность. Здесь нет универсального ответа».

«Нет эффективной разработки на все случаи жизни, — подчёркивает Почтов. — Есть разработка, которая решает конкретную задачу в определённых условиях: в рамках бюджета, сроков, размера компании, количества денег, которые зарабатывает бизнес. Когда-то тебе нужна толпа бизнес-аналитиков, чтобы не совершить ошибку и не потерять кучу денег. А когда-то это лишнее звено, которое только тормозит — и тебе важнее быстрее выйти на рынок, чем строить правильную платформу, которая поможет в будущем. А может, будущее и не наступит. Мы сейчас сделаем монолит, но при этом знаем, что есть варианты сервисной архитектуры, гибридной архитектуры. Знаем, как перейдём от монолита в случае роста. Сейчас я выберу канбан, потому что понимаю, как перейду на двухнедельный цикл разработки, когда это станет нужно. Вот это умение осознанно принять решение и понимать, как ты будешь трансформироваться с развитием бизнеса — это и есть эффективная разработка», — объясняет Почтов.

Есть ещё одна ловушка: компании не знают, как измерить свою эффективность.

«Для каждой ситуации — своя методология, — соглашается Яна Шакленина, CPO Outlines Tech. — Что такое эффективная разработка? Это стабильная работающая инфраструктура, работа разработчиков с минимумом ошибок, короткие циклы изменений — сделал и сразу полетело. Но нужно понимать, про какую эффективность мы говорим. Нужно искать золотую середину. Когда оцениваем проект, мы должны понимать его стоимость и обсуждать с бизнесом стоимость простоя при возникновении ошибок. Оценивать, какие инциденты могут возникнуть и сколько они будут стоить. И тогда понимать: подойдёт решение на коленке или нужна целая команда девопсов с Kubernetes».

Прежде чем выбирать инструменты, нужно честно ответить на три вопроса: какую задачу мы решаем, в каких условиях и с какими людьми. Всё остальное — следствие.

Трактор есть, а поле не вспахано

Инструментов для автоматизации разработки сегодня больше, чем когда-либо. CI/CD, контейнеризация, оркестрация, low-code платформы, AI-ассистенты — рынок предлагает решения на любой вкус и бюджет. Кажется, бери и пользуйся. Но между «есть инструмент» и «умеем им пользоваться» — пропасть.

«Это как крестьянин копает лопатой — а ведь уже появились трактора с огромным количеством насадок, — проводит аналогию Александр Сахаров, директор по работе с партнёрами компании Диасофт. — Одна насадка для вспахивания, другая для засеивания, третья для чего-то ещё. То же самое в разработке: есть автоматизация DevOps и CI/CD, автоматизация тестирования, автоматизация сборок. А есть ещё автоматизация производства самого кода. Каждый раз решать задачу правильной структуры, ролей, управления логированием, горизонтальным масштабированием, добиваться единых стандартов по интерфейсу — каждый раз делать это вручную практически невозможно. Если десять лет назад ещё можно было насобирать темплейтов и как-то вручную всем этим управлять, сейчас это уже невозможно. Сейчас мест, в которых требуется автоматизация, просто огромное количество. Спроектировали процессы — из них уже код формируется. Хотим попробовать A/B-тестирование в одном регионе — запустили веточку на один сегмент, проверили, приняли решение. Весь интерфейс, весь UI/UX формируется автоматически. Если всё это делать руками в коде, фронтенд-разработчики полягут, бэкенд-разработчики полягут. Никакого нормального тестирования не проведёшь. Нужен конвейер производства, в котором все эти вещи автоматизированы. И туда же нужно добавлять искусственный интеллект: здесь AI пишет скрипт для работы с данными, здесь покрывает юнит-тестами, здесь контролирует и запускает пайплайны. Этот конвейер сегодня — суперсложная система, её на коленке в одиночку не соберёшь».

«Если человеку, который пашет на лошади, отдать трактор — он сразу начнёт на нём пахать? Думаю, нет, — возражает Антон Новожилов, руководитель цифровой интеграции и автоматизации процессов в mrnet. — Почему ямы до сих пор копают вручную, а не привозят экскаватор? Потому что работа экскаваторщиком требует опыта. Технических решений на рынке много — есть PaaS-решения, BaaS-решения, на GitHub можно набрать целый стек бесплатного опенсорсного софта хорошего качества. В технической части для того, чтобы сделать стартап или продукт, ничего сложного нет. Проблема в другом. В большинстве компаний, в том числе крупных, проблемы не технические. У них нет проблем с серверами, нет проблем с продуктами, они могут позволить себе купить любое enterprise-решение. Проблемы именно процессные. Чтобы выстроить процессы в рамках всей компании, нужны знания на стыке разработки, тестирования, эксплуатации и менеджмента. При этом инструмент может оказаться недостаточным — ты не можешь полностью отразить на нём все процессы, которые у тебя есть. Появляется какой-нибудь простой продукт, где люди сделали тудушку и говорят: мы убили Jira. Нет, не убили. Вы построили продукт, которым можно управлять компанией из пяти человек, где четверо — фаундеры. И даже если вы сделаете очень классное техническое решение, в процессах всё это может погибнуть. Разработчики учатся разрабатывать, а не заниматься менеджментом и строить кросс-командные процессы. В маленьких командах это переходит в хаос — но этот хаос понятен людям. А сложные схемы с тасками, сигналами, burndown-чартами — зачастую их просто нет. И нет по объективным причинам».

«Сколько я видел из своей практики: DevOps пытаются принести Kubernetes в компанию, им не хватает квалификации, процесс растягивается на полгода-год, и в конце концов они просто увольняются, — рассказывает Алексей Каньков, Senior Backend Developer в Revizto. — И мы возвращаемся к тому, что было. Был небольшой Docker Compose файл — к нему и вернулись. Если процессы типа Docker, Kubernetes и тому подобного всё только затягивают — это никому не нужно».

«Когда запускаем продукты, надо учитывать цели, риски и ресурсы, — говорит Руслан Остропольский, директор по продукту Test IT. — Есть классные технологии и хорошие люди, которые способны с ними работать. А есть средний и малый бизнес, который никогда в IT не заходил. Он не очень понимает, что такое разработка, но очень хочет. Таких примеров масса. В этих компаниях иногда даже есть деньги, но они не умеют запускать разработку. Нанять сильного управленца и сильного технаря, который хотя бы поставит на рельсы — не могут: это будет дороже бюджета, а сильному специалисту у них будет скучно».

Куда на самом деле утекают часы

«Больше всего потерь не в технологиях, а в процессах и людях, — говорит Андрей Почтов. — Технологий много разных. А если нет людей, которые знают, как их применять, — всё рушится. Перебираю в голове проекты, которые были провальными — их объединяет не неверно выбранная технология, а слабый менеджмент, плохие процессы, плохая бизнес-аналитика, плохая коммуникация».

«В больших компаниях есть большое количество команд, и они всё время общаются, — объясняет Антон Новожилов. — Почему общаются? Потому что синхронизация. Кто-то что-то сделал, кто-то сделал что-то другое — вы синхронизируетесь. Потом появляется четвёртая команда, она что-то сделала — вам снова нужно синхронизироваться. При этом там нет технических проблем — никто не переживает, что нет серверов или ещё чего-то. Чтобы реализовать процессы в рамках всей компании, нужны знания на стыке разработки, тестирования, эксплуатации и менеджмента. Разработчики учатся разрабатывать, а не заниматься менеджментом и строить кросс-командные процессы. В маленьких командах это переходит в хаос. Но этот хаос понятен людям — а сложные схемы с тасками, сигналами, burndown-чартами зачастую просто отсутствуют. И отсутствуют по объективным причинам».

«По опыту, очень большое число проектов заваливается из-за неправильной коммуникации — неверной, не вовремя или вообще отсутствующей синхронизации. Коммуникация — это огромная составляющая в любом проекте. И правильный процесс коммуникации и синхронизации критически важен. Инструменты и технологии должны быть соразмерны задаче, но без выстроенной коммуникации даже лучший инструмент не спасёт», — отмечает Алексей Граков, руководитель компании Agizo. 

«Проблема не всегда в инструментах, которые автоматизируют работу разработчика, — говорит Генри Бабенко, Tech Lead. — Очень часто проблема выше — в менеджменте, в процессах. Есть три этапа разработки продукта: планирование, производство, релиз и поддержка. Про производство и релиз можно долго обсуждать — где внедрить Kubernetes, какой CI/CD выбрать. А про планирование часто забывают. Именно на этом этапе нужно согласовать требования между бизнесом и разработкой, определить объёмы, риски, критерии готовности — чтобы в процессе разработки не появлялись новые вводные, которые сбивают темп. Влетающие задачи тяжело поддерживать. Разработчик работает над конкретной фичей, а тут прибегает бизнес: "Всё бросайте, у меня идея, давайте реализуем". Это портит все сроки, меняет все правила. То, на что изначально закоммитился, — всё быстро ломается. Люди начинают выгорать. Появляется хаос».

«Основной вызов будущего — умение выстраивать коммуникацию, умение по-другому собирать и формулировать бизнес-требования, чтобы теперь не только люди понимали, но и машины, — говорит Андрей Почтов. — Эффективность или неэффективность кроется не в технологиях, а в процессах коммуникации и передачи знаний. Раньше был принцип Two-Pizza Team — команда, которую можно накормить двумя пиццами. Сейчас команды уменьшают ещё сильнее. Google экспериментирует с командами по 3–4 человека. Супер-сеньоры, которые за счёт меньших потерь на коммуникацию дают больший результат. Вся эффективность будущего — в уменьшении команд и росте T-shaped специалистов, чтобы в рамках одной головы умещалось как можно больше задач. Технологии нам уже дали. Следующий этап — улучшение коммуникации».

«У нас в средней команде сегодня 4–5 человек. Раньше ту же работу делали 10–15. При этом это миды и джуны — вчетвером-впятером делают столько же и лучше, чем раньше полноценная команда из 10–15 человек. Это de facto то, что мы сейчас имеем», — говорит Александр Сахаров.

Если это не приносит денег — зачем?

«Эффективность — это не про процессы, — утверждает Алексей Каньков. — Это про то, насколько быстро мы можем донести желание бизнеса в продакшн. Насколько быстро прийти от идеи до момента, когда она приносит деньги. Если процессы типа Docker, Kubernetes и тому подобного всё только затягивают — это никому не нужно. Бизнесу интересны деньги. Если на коленке собранный скрипт работает и приносит деньги — это гораздо лучше, чем сложная система уровня крупных компаний. Владельцу бизнеса не нужна архитектура Яндекса. Ему нужно, чтобы продукт приносил деньги — и как можно быстрее. Потому что он, может быть, на последнее всё это собирает, лишь бы стартануло».

«Если приходишь с какими-то решениями — CI/CD, AI, что угодно — нужно продать эту идею, — говорит Антон Новожилов. — Продать руководству компании, основателям, инвесторам, совету директоров. Объяснить, как внедрение CI/CD конвертируется в деньги. Чтобы это не выглядело развлечением разработчиков — нажали кнопочку, и всё как-то полетело. У разработчиков есть такая проблема: они могут потратить несколько недель на автоматизацию того, что делается по часу три раза в год. И это признают практически все разработчики. Даже если у вас простой сервер с монолитной архитектурой, и всё это приносит деньги — переход на какие-то улучшения, уход от ручного тестирования к автоматическому, может не принести деньги, а только их потратить. Люди могут уйти из компании, разочаровавшись, что не внедрили state-of-the-art решения. Но бизнес — про другое. Он про зарабатывание денег и про то, чтобы всем было на что жить».

Есть и другая сторона медали. Экономия на архитектуре может обойтись дороже, чем казалось.

«Я с трудом представляю, как сидит бизнесмен и говорит: давайте абы что запилим и посмотрим, работает или нет, — возражает Александр Сахаров. — Оказывается, работает. Покупаю рекламу, нагоняю на портал трафик — и удивляюсь, что то, что сделано, не тянет нагрузку, не защищено по инфобезу. Все люди, которым я заплатил за то, чтобы они пришли и начали пользоваться, узнают, что сайт не работает, данные утекли, а я ещё сяду в тюрьму. Я в таких ситуациях бывал много раз — у меня своих бизнесов достаточно много было запущено. И никогда нет возможности сказать: ой, мы тут просто попробовали, извините, теперь будем нанимать нормальную команду, всё выбрасывать, всё переписывать и терять ещё полгода».

«В каждой автоматизации, в каждой оптимизации должна быть бизнес-ценность, — говорит Яна Шакленина. — Когда мы оцениваем проект, мы должны понимать его стоимость и обсуждать с бизнесом стоимость простоя при возникновении ошибок. Оценивать, какие инциденты могут возникнуть, и сколько они будут стоить. И тогда понимать: подойдёт решение на коленке или нужна целая команда девопсов. В каждом месте должно быть то, что соответствует ситуации. Нужно учитывать оценку рисков, описание мероприятий для их предотвращения, перечень мер по устранению инцидентов и скорейшей локализации. Когда возникают риски неэффективной разработки или ошибки в инфраструктуре — чья это зона ответственности? Когда ответственность заканчивается на разработчике, когда на исполнителе, когда переходит на сторону заказчика? Особенно если в его инфраструктуре произошёл инцидент, из-за которого говорят, что продукт работает неэффективно. Всё это влияет на репутацию».

«Мы внедряем AI, код пишется агентами, а не руками — но здесь возникает вопрос ответственности, — отмечает Новожилов. — Если код в каком-нибудь Cloudflare был написан агентом, и из-за него лежит пол интернета — кто ответственный? Человек, который решил внедрить AI? Тот, кто запустил агента? Ровно так же с инфраструктурой: мы принимаем стратегическое решение изменить инфраструктуру, Kubernetes падает — кто виноват? Мы оценивали, что у нас есть опыт и мы не столкнёмся с проблемами. Есть много примеров успешного внедрения. Но у нас пошло не так. Кто несёт ответственность — CTO, совет директоров? Здесь очень много вопросов».

«Если оценивать те требования, которые ставились раньше — да, их можно сделать быстрее и дешевле. Но бизнесу сейчас этого мало. Мы внедряем AI — но не для того, чтобы просто сделать одностраничный сайт. Бизнесу это неинтересно. Бизнес понимает, как он может зарабатывать на новой автоматизации, на новой функциональности. Рынок диктует стоимость разработки. Мы не можем оценивать зарплату разработчиков без понимания, сколько стоит хлеб и молоко. Нужно понимать, насколько эффективен тот cost, который мы предлагаем заказчику. Из этого складывается репутация наших компаний», — говорит Яна Шакленина. 

Хаос, который понятен, лучше порядка, который пугает?

«Есть сервер, на нём что-то работает — бизнесу это понятно, это очень понятная вещь, — объясняет Антон Новожилов. — Когда ты приходишь и говоришь: сейчас накрутим Kubernetes, будут докеры, потом в разных геозонах всё развернём — бизнесу непонятно. Нет прямой связи между Kubernetes и увеличением выручки в 2–3 раза. Хаос — он хоть и хаос, но понятен бизнесу: мы теряем сколько-то денег, но так это работает, есть какая-то выручка. А вы принесёте что-то другое — и непонятно, как это изменит ситуацию. Мы должны инвестировать миллионы в улучшение инфраструктуры — а что изменится? Как это повлияет на деньги? Я работал в компании, мы строили процессы. Так как у нас было недостаточно опыта, позвали ребят, которые профессионально занимались скрамом. Они пришли и сказали: всё понятно, сделаем вам классный скрам — прямо по книжке. Вот книжка, вот скрам-мастер, сейчас всё внедрим. Компания на две недели просто остановилась. Вся работа, всё, что делали люди — они настолько не понимали эти процессы, настолько они противоречили тому, как на самом деле работали люди, что компания встала. Сверху, как руководитель, я это видел. Это ввергало в шок: а почему, а что произошло? В какой-то момент мы поняли, что так не работает. Сказали людям спасибо, но давайте мы как-нибудь сами. Построили свой процесс на основе базового Waterfall — и построили компанию, которая за полтора десятка лет дошла до миллиарда рублей выручки. Это работало. Хороший способ оценить эффективность — если результат работы приносит достаточно много денег».

«Где средняя скорость автомобиля выше — в Германии, где строгие правила, светофоры и даже пешеходный переход строго регламентирован? Или в Индии или Вьетнаме, где никаких правил нет и каждый делает, что хочет? Это аналог вопроса о полезности шаблонов и правил, которые позволяют ускорять производство», - говорит Александр Сахаров.

«Шаблоны — это унификация лучших практик, которые были набиты сложными шишками разными людьми, — говорит Яна Шакленина. — Шаблоны как методология управления, шаблоны в плане сервисов и инструментов разработки — это отличная штука. При разработке шаблонов учитываются практики и цели, которые общи для многих. Но когда мы говорим про кастомизацию — не каждый продукт поддаётся той кастомизации, которая нужна. Грамотный подход к управлению проектом и проработке бизнес-требований иногда помогает раскрыть заказчику глаза: ему больше подойдёт стандартный классический подход, чем выдумывание своего космолёта, который непонятно, взлетит или нет».

«Когда приходишь в крупный бизнес, где есть огромное количество согласований, подрядчики, люди, которым нужно донести свою точку зрения до разработчика — возникают проблемы из-за отсутствия правил, — рассказывает Генри Бабенко. — Ты не можешь быть уверен, что то, что хочешь сделать как разработчик, зайдёт бизнесу. Поэтому важно стандартизировать разработку, особенно если это бизнес крупнее стартапа из десяти человек. Чтобы было понятно, на что вообще команда способна. Приносишь продукт, говоришь: хочу сделать классное приложение, давайте замутим. Начинаем работать — и выясняется, что команда не умеет между собой взаимодействовать. Почему? Потому что наняли не пять сеньоров с лидовским бэкграундом, а обычных разработчиков — всех всегда хотят дешевле. Они начинают не ладить, конфликтовать. Лучший вариант — нанять управленца, который выстроит формальные процессы, и технические, и менеджерские, которые помогут команде двигаться вперёд».

Будущее: меньше людей, больше ответственности

«За 15 лет в разработке я видел два кардинальных изменения, — говорит Андрей Почтов. — Первое — когда появилась сервисная архитектура и потребовались платформы для автоматизации. Второе происходит сейчас — разработка меняется за счёт искусственного интеллекта, GPT-технологий. В ближайшие год-два она точно станет эффективнее, это уже доказано. Но основной вызов будущего — не технологии. Это умение выстраивать коммуникацию, умение по-другому собирать и формулировать бизнес-требования, чтобы теперь не только люди понимали, но и машины».

Low-code платформы и AI ускоряют этот процесс.

«Бизнес не стремится увеличивать количество людей — стремится повышать эффективность, — говорит Алексей Граков. — Low-code позволяет создавать бизнес-приложения быстро: набросал сущности, связи, фильтры — автоматически всё есть, API есть. Раньше это месяцами делали, сейчас — готово за часы. И low-code легко интегрируется с AI: один блок BPM может отвечать за общение с нейросетью. Разработка дешевеет, но появляются новые вызовы, которых раньше не было. Джунам сложнее зайти в отрасль — они уже должны быть новыми мидлами с ходу».

«Часто говорят: на рынке не хватает грамотных разработчиков, — говорит Яна Шакленина. — Но какой навык важнее всего? Эффективный менеджмент. Не хватает управленцев, которые в конкретном проекте с конкретным заказчиком поймут: где нужно ускориться, где лучше замедлиться и провести дополнительную аналитику. Научить человека ездить на тракторе — одна задача. А как команде трактористов спахать поле максимально эффективно, с учётом погодных условий — это задача для управленцев. Нужно больше вкладывать в менторство, в выращивание таких специалистов. Это точка роста, которая даёт импульс к развитию».

А как считаете вы? Поделитесь своим мнением в комментариях.