Чтобы деплой прошёл без проблем, нужно подготовить воспроизводимый артефакт, проверить совместимость версий и заранее определить условия остановки или отката релиза. Подробнее об этих процессах и опыте работы с высоконагруженными системами рассказала команда RWB.

Сначала разделим деплой и релиз

Деплой отвечает за доставку кода или собранного артефакта в проде. Релиз начинается тогда, когда новое поведение становится доступно пользователям. Эти события могут происходить одновременно, но если будете разделять — получите больше контроля.

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

Держите в фокусе четыре параметра:

1. какой именно артефакт попадает в среду;
2. какая доля запросов или пользователей видит изменение;
3. по каким сигналам выкладка продолжается или останавливается;
4. сколько времени занимает возврат к рабочей версии.

Время восстановления тоже нужно определить заранее. Например, отключение функции через флаг должно занимать не более 1–5 минут, возврат к предыдущей стабильной версии — до 15 минут. Для сбоев, затрагивающих базу данных или требующих ручного вмешательства, устанавливают отдельное целевое время восстановления — например, 30–60 минут. Эти значения служат отправной точкой: уточняйте их с учётом критичности сервиса, архитектуры и требований бизнеса.

Один артефакт для всех сред

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

С подобной проблемой столкнулись и мы в RWB. При непрерывной интеграции и доставке (CI/CD) пайплайны для разных сред запускались независимо. Из-за повторной сборки в прод мог попасть образ, который не проходил проверку на стейджинге.

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

Для прода в RWB добавили отдельное правило. Если пайплайн не находит ранее собранный образ, выкладка завершается ошибкой. Правило находится непосредственно в коде пайплайна.

После внедрения этого подхода RWB еженедельно пропускает около 700 сборок. Это 30% сборок с включённой фичей и 5% общего числа сборок через CI/CD. Главное — между тестированием и продом сохраняется один и тот же исполняемый код.

Поэтапная выкладка ограничивает радиус сбоя

Даже проверенный артефакт может повести себя иначе на реальном трафике. Помогает поэтапная доставка изменений — новая версия постепенно охватывает всё больше пользователей.

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

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

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

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

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

Метрики, которые останавливают релиз

Статус контейнера Running подтверждает только запуск процесса. Для решения о продолжении выкладки нужны сигналы нескольких уровней.

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

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

Feature flags управляют доступностью функции

Feature flag позволяет изменить поведение приложения без новой выкладки кода. С его помощью вы можете открыть функцию внутренним пользователям, заданному сегменту или небольшой доле аудитории. При проблеме флаг работает как kill switch — оперативный выключатель функции.

Флаг не заменяет канареечную выкладку контейнера. Эти механизмы контролируют разные уровни:

• канареечная выкладка проверяет новую версию приложения и её взаимодействие с инфраструктурой;
• feature flag управляет отдельным пользовательским сценарием внутри уже развёрнутой версии.

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

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

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

Миграции данных требуют собственного плана отката

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

Для изменений, затрагивающих схему данных, применяют подход expand–migrate–contract:

1. Сначала вы расширяете модель данных: добавляете новую колонку, таблицу или поле события, сохраняя старую структуру.
2. Затем выкатываете код, который понимает оба формата. При необходимости сервис некоторое время пишет данные одновременно в старое и новое представление.
3. После миграции чтение переключается на новый формат, а вы проверяете результат на прод-нагрузке.
4. Старую структуру удаляют отдельным релизом, когда предыдущая версия приложения больше не понадобится для отката.

Да, эта последовательность увеличивает число этапов, зато сохраняет совместимость между версиями. Для API и очередей действует тот же принцип: потребители должны уметь обрабатывать новые поля, а производитель — учитывать время обновления зависимых сервисов.

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

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

Откат нужно репетировать

В рабочий сценарий нужно включить:

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

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

Проблему можно исправлять новой версией, если миграция уже изменила большой объём данных и предыдущий код больше не поддерживает новый формат. Поэтому сценарий отката нужно учитывать ещё до начала миграции: определить условия, при которых возврат к старой версии уже невозможен, назначить ответственных и описать последовательность восстановления в runbook — пошаговой инструкции для дежурных инженеров.

Минимальный набор перед первой управляемой выкладкой

Для первой управляемой выкладки не обязательно сразу строить сложную платформу поэтапной доставки. Базовый процесс можно собрать из нескольких понятных правил:

• прод получает тот же артефакт, который прошёл проверки;
• релиз начинается с ограниченного трафика или аудитории;
• метрики имеют заранее определённые условия остановки.

Когда вам уже понятен процесс, можно автоматизировать продвижение между этапами, сравнение метрик и откат. Автоматизация в этом случае ускоряет готовый процесс и снижает количество ручных действий.

Вместо вывода

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

Для разработчика это карта спроса. Если пилоты есть почти у всех, а в прод доходит половина, то основная работа сейчас не в том, чтобы «прикрутить модель», а в том, чтобы довести её до надёжной эксплуатации: данные, интеграции, контроль качества и стоимость. Именно там исследование и находит барьеры. Оговорка о выборке: 52 компании — это крупный бизнес, и выводы не переносятся на средние и малые компании; публикация в «Ведомостях» помечена как партнёрский материал, а полную версию исследования на сайте «Инфосистем Джет» можно только запросить.

• 86% крупных компаний используют или тестируют LLM; 53% перевели решения на генеративном ИИ в промышленную эксплуатацию.
• Агенты: полуавтономные (с контролем человека) осваивают 59%, полностью автономные 25%, мультиагентные 23%; в проде соответственно 15%, 8% и 8%.
• 44% крупных компаний отказываются от внедрения ИИ-агентов; барьеры: стоимость серверов (58%), юридические риски (56%), отсутствие устойчивого экономического эффекта (46%).
• Где ИИ уже применяют: контакт-центры и поддержка (75%), аналитика и BI (63%), внутренние ИТ-службы и сервис-деск (60%).
• Выборка: 52 крупные компании, около 450 тыс. сотрудников, семь глубинных интервью; полная версия исследования по запросу.

Разрыв между пилотом и продом

Самая показательная пара цифр относится к агентам. Полуавтономных агентов, где человек проверяет результат, осваивают 59% компаний, но в промышленной эксплуатации они лишь у 15%. Для полностью автономных систем разрыв ещё резче: 25% против 8%. Авторы формулируют это прямо: «настоящего бума ИИ-агентов пока не случилось». Пилот сделать легко, а отвечать за агента, который сам совершает действия в учётной системе, компании не спешат.

По словам Максима Андрианова из «Инфосистем Джет», которого цитируют «Ведомости», без данных искусственный интеллект не приносит ожидаемого экономического эффекта.

Три барьера

Первый — деньги на железо: 58% называют стоимость серверов главным препятствием. Второй — юридические риски, 56%: персональные данные, ответственность за решения модели, требования регуляторов. Третий — экономика: 46% не видят устойчивого эффекта уже на стадии пилота. Отдельная цифра того же опроса: 44% крупных компаний отказываются от внедрения агентов; связывать её с предыдущей причинно исследование не берётся, и мы тоже.

Где ИИ уже работает

Ниши предсказуемые, но полезно видеть их в цифрах: контакт-центры и поддержка клиентов у 75% респондентов, аналитика и BI у 63%, внутренние ИТ-службы и сервис-деск у 60%. Это задачи с большим потоком однотипных текстов, где ошибку модели легко поймать и дёшево исправить. Разработка ПО как отдельная ниша в опубликованной выжимке не выделена.

Что это значит для разработчика

• Спрос смещается от «умею вызвать API модели» к «умею довести до прода»: оценка качества, наблюдаемость, ограничение стоимости, откат при деградации.
• Работа с данными снова главный навык: интеграция с учётными системами, очистка и разметка, права доступа к корпоративным источникам.
• Локальный инференс и оптимизация под ограниченное железо востребованы: стоимость серверов назвали главным барьером 58% компаний.
• Комплаенс становится частью задачи: где хранятся данные, что уходит в модель, как это объяснить юристам.
• Агенты с полной автономией пока редкость; полезнее уметь строить полуавтономные сценарии с проверкой человеком, которые реально доходят до прода.

Контекст

Для сравнения авторы приводят глобальный опрос McKinsey State of AI 2025: 88% компаний в мире применяют ИИ хотя бы в одной функции, а влияние на прибыль до вычета процентов и налогов фиксируют 39%. Российские 86% по проникновению выглядят сопоставимо, но по доле компаний с измеримым эффектом сравнить нельзя: методики разные. Полную версию исследования «Инфосистемы Джет» отдают по запросу на своём сайте; редакция запросила её и дополнит материал, если в полном тексте окажутся данные по разработке ПО.

Источники: Достичь ИИ-зрелости: 86% крупных компаний внедрили большие языковые модели («Ведомости», партнёрский материал), Страница исследования на сайте «Инфосистем Джет»

Изображение на обложке: скриншот jet.su

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

• Счёт цифрового рубля открывается на платформе Банка России через раздел «Цифровой рубль» в приложении подключённого банка; один счёт на физлицо или компанию, у ИП два.
• Лимит пополнения для физлиц — 300 тыс. рублей в месяц, для бизнеса лимита нет; тратить накопленное можно без ограничений.
• Для граждан операции бесплатны; для бизнеса комиссии не взимаются до конца 2026 года, тарифы с 2027 года установлены отдельным решением Банка России от 28 августа.
• Принимать цифровые рубли обязаны с 1 сентября 2026 года торговые компании с выручкой свыше 120 млн рублей, у которых на 1 января 2026 года был договор с крупнейшим банком-участником; торговые точки с выручкой до 5 млн рублей освобождены.
• Все банки с универсальной лицензией подключаются к 1 сентября 2027 года, с базовой — к 1 сентября 2028 года; сроки закреплены законом 248-ФЗ.

Как это устроено

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

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

Доступные операции: переводы между гражданами и компаниями, платежи в бюджет и из бюджета, оплата покупок, возвраты. Открытие и закрытие счёта бесплатны, для граждан бесплатны все платежи и переводы. Для бизнеса действует льготный период до конца 2026 года; тарифы для индивидуальных предпринимателей и компаний с 2027 года установлены отдельным решением Совета директоров Банка России от 28 августа 2026 года. По вопросам работы с цифровыми рублями регулятор советует обращаться сначала в свой банк, затем на горячую линию Банка России по цифровому рублю: 8 800 301 30 00, короткий номер 301 с мобильного или +7 499 300 3 301.

Сроки для банков и магазинов

Внедрение идёт волнами. С 1 сентября 2026 года инфраструктуру открывают крупнейшие банки, а торговые компании с выручкой свыше 120 млн рублей в год, у которых на 1 января 2026 года был договор с таким банком, обязаны принимать цифровые рубли. С 1 сентября 2027 года такую возможность должны обеспечить все банки с универсальной лицензией, с 1 сентября 2028 года — банки с базовой лицензией. Торговые точки с выручкой меньше 5 млн рублей от обязанности освобождены, как и торговые точки там, где нет интернета. Обязательные сроки для банков и продавцов закреплены федеральным законом 248-ФЗ, а решение Банка России определяет лимиты, перечень операций и порядок добровольного раннего подключения остальных банков.

Что это значит для разработчика платёжной интеграции

Технически приём идёт через банк-участник, поэтому прямой интеграции с платформой Банка России у магазина нет: интерфейс и документацию даёт ваш банк. Возвраты уходят обратно на цифровой счёт покупателя, а не на карту, и это отдельная ветка в логике рефандов и чеков. Лимит 300 тыс. рублей в месяц касается пополнения счёта физлицом; расход ограничен только остатком на счёте.

• Узнайте у своего банка, как он подключает приём цифровых рублей и какие интерфейсы даёт; для крупнейших банков это уже сентябрь 2026 года.
• Заложите в модель данных третий тип платежа рядом с картой и СБП: у него свои статусы, свой возврат и своя сверка.
• Возвраты: средства уходят обратно на цифровой счёт покупателя; учитывайте это в логике рефандов и в чеках.
• Комиссии для бизнеса появятся с 2027 года по тарифам решения от 28 августа; не зашивайте «бесплатно» в расчёт стоимости платежей.
• Торговые точки с выручкой до 5 млн рублей, точки без интернета и, до сентября 2027 года, клиенты банков вне списка крупнейших могут не спешить: для них цифровой рубль пока добровольный.

Контекст

Пилот цифрового рубля стартовал в августе 2023 года на ограниченном круге клиентов и банков. К концу сентября 2025 года в нём было открыто больше 2,5 тыс. кошельков и проведено больше 90 тыс. операций. Массовый запуск дважды переносили. Следующая проверка — сентябрь 2027 года, когда к платформе должны подключиться все банки с универсальной лицензией, и тарифы для бизнеса, которые начнут действовать с января.

Источники: Сообщение Банка России о старте с 1 сентября, Решение Совета директоров Банка России от 28.08.2026, Страница проекта «Цифровой рубль»

Изображение на обложке: Банк России

Насколько рынок к этому готов, показал Руцентр в данных, опубликованных 1 сентября: идентификацию прошли 42,2% его администраторов и 25,7% пользователей Рег.ру (данные на конец августа). Вместе эти два регистратора контролируют около 68% российского доменного рынка. Для команды разработки это значит одно: домены продукта, записанные на бывших сотрудников или незнакомых людей, при следующем продлении могут зависнуть.

• Закон 569-ФЗ действует с 1 сентября 2026 года и распространяется на зоны .ru, .рф и .su; идентификация через ЕСИА при регистрации, продлении и изменении данных.
• Готовность по данным Руцентра на 1 сентября: 42,2% его администраторов, 25,7% у Рег.ру; ещё в начале июня через ЕСИА прошли администраторы 256 тыс. доменов в Руцентре и 456 тыс. в Рег.ру.
• Санкции для неидентифицированных пока не применяются: переходный режим до включения регистратора в специальный перечень либо до 18 января 2027 года.
• Для нерезидентов с 2 июня работает trustee-сервис Рунити; для юрлиц на момент публикации CNews идентификацию проводил Руцентр.
• По данным Руцентра, 38,5% компаний сталкивались с сайтами-имитаторами бренда, а двухфакторную аутентификацию в аккаунте регистратора используют 15–16% владельцев.

Что именно требует закон

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

Зарегистрировать домен сможет любой, как и раньше, добавляется обязательная идентификация через ЕСИА.

Важная деталь: ограничения для тех, кто не прошёл идентификацию, 1 сентября не включаются. Действует переходный период: до включения конкретного регистратора в специальный перечень либо до 18 января 2027 года. Точный порядок последствий для каждого неидентифицированного домена в открытых источниках не раскрыт; это главный вопрос, который стоит задать своему регистратору. Времени меньше, чем кажется: домены продлеваются раз в год, и у части владельцев дата продления попадёт уже внутрь жёсткого режима.

Почему это касается разработчиков

Домен — корень всего: DNS, TLS-сертификаты, почта, OAuth-редиректы, вебхуки. В той же публикации Руцентр приводит цифры, которые объясняют, зачем регулятор это делает: 38,5% компаний сталкивались с сайтами-имитаторами бренда, 35,9% — со сканированием инфраструктуры и попытками перехвата управления, а двухфакторную аутентификацию в аккаунтах регистраторов используют лишь 15–16%; опрос охватывал преимущественно крупный бизнес, а не всех владельцев доменов. С июня по август было отозвано 6 997 SSL-сертификатов, из них 4 677 GlobalSign. Физлица владеют 72,7% доменов в зоне .ru и 82,9% в зоне .рф.

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

Что проверить сегодня

• Составьте список доменов продукта с датами продления и посмотрите в WHOIS или личном кабинете, кто указан администратором: физлицо, ИП или юрлицо.
• Домены на сотрудников переоформите на юрлицо через процедуру передачи у регистратора; сделать это сейчас проще, чем после блокировки.
• Убедитесь, что у администратора-юрлица есть подтверждённая учётная запись организации на Госуслугах и доступ к ней не у одного человека.
• Включите двухфакторную аутентификацию в аккаунте регистратора и переведите вход на корпоративную почту.
• Если домены записаны на иностранное лицо или компанию, уточните у регистратора условия trustee-сервиса: с 2 июня такой есть у Рунити.
• Домены в .com, .io, .dev и других международных зонах закон не затрагивает, но защиты от «увольнения владельца» они тоже не дают, так что инвентаризация полезна всем.

Что дальше

Ключевая дата — 18 января 2027 года, конец переходного периода для регистраторов, не попавших в перечень раньше. До этого момента регистраторы будут догонять показатели готовности рассылками и напоминаниями. Порядок последствий для неидентифицированного домена в открытых источниках пока не раскрыт; редакция будет следить за разъяснениями Координационного центра доменов .RU/.РФ.

Источники: Руцентр: готовность администраторов к идентификации (CNews, 1 сентября 2026), Рунити запустила сервис для нерезидентов (CNews, 2 июня 2026), Федеральный закон от 29.12.2025 № 569-ФЗ

Изображение на обложке: скриншот esia.gosuslugi.ru

В AutoGPT, где на момент интервью у репозитория было свыше 180 тысяч звёзд и 150 открытых PR, большая часть этих PR создана агентами: Copilot, OpenClaw, собственными инструментами команды и сторонними ботами. Большинство мейнтенеров реагируют просто: закрыть дверь, отключить пулреквесты, не тратить силы на чужой LLM-вывод. Но у Николаса Тиндла, одного из основателей ИИ-инженерии в AutoGPT, другой взгляд: «По сути, кто-то другой платит за ваши вычислительные ресурсы. Если контрибьютор хочет потратить свои токены на улучшение вашего проекта — пусть тратит. Главное, сделать так, чтобы единственный путь внутрь проходил через ваши правила.»

ИИ-first контрибьютор — это разработчик, который отдаёт написание кода, тестов или документации генеративной модели, либо самоходный агент, который клонирует репозиторий, ищет issue, пишет код и открывает PR. Для мейнтенера результат одинаков: в репозиторий приходит поток кода, который часто не учитывает контекст проекта и требует ревью.

Агенты не ищут документацию сами — они читают то, что лежит рядом с кодом. AGENTS.md и CLAUDE.md в нужных директориях работают лучше, чем вики.

Пропускные ворота должны быть автоматическими и однозначными: шаблон PR, тест-план, CI как стена, CLA как детектор человека.

Не все ворота стоит оставлять включёнными: автоматические комментарии об ошибках CI быстро превращаются в шум.

Плохой AGENTS.md хуже, чем его отсутствие: избыточные инструкции засоряют контекст и ломают поведение агентов.

Мейнтенер всё ещё решает, что принимать: закрыть PR и переписать самому — тоже валидный выбор.

Проблема не в документации, а в её обнаружении

Первое, что пробовала сделать AutoGPT, — улучшить CONTRIBUTING.md, написать подробную вики и обновить гайды. Это не сработало. Дело в том, что агенты не ходят по ссылкам и не ищут документацию в разделах репозитория. Они смотрят на то, что находится в текущей директории и на один-два уровня выше. Если инструкция не лежит там, где агент работает, для него её не существует.

Сначала команда добавила файлы CLAUDE.md, потому что Claude открывал пулреквесты без достаточного контекста о репозитории. Потом выяснилось, что Copilot и Codex эти файлы игнорируют — они не Claude. Решением стал централизованный AGENTS.md, на который указывают все специфичные для модели файлы.

Важный нюанс: AGENTS.md действует внутри директории. Если агент работает в backend/, он видит правила для бэкенда. Если динамически загружается навык, связанный с фронтендом, агент может не знать, в какой директории искать инструкции — и навык сам должен ему подсказать путь. Поэтому в AutoGPT файл AGENTS.md лежит рядом с кодом, который он регулирует.

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

Фронтенд-инженер AutoGPT устал от одного и того же класса сломанных PR в open source-проекте и оформил гайд как навык. Теперь каждый агент, который касается репозитория, видит триггер и выполняет правило. Бэкенд делает то же самое: не набрал 80% покрытия — PR не пройдёт.

Ворота для ИИ-контрибьюторов в open source

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

Шаблон пулреквеста как пропускной пункт

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

Тест-план, который запускает код

В шаблоне есть раздел тест-плана, и его формулировка незаметно подсказывает агенту протестировать пулреквест. Эта фраза активирует навык test PR: агент устанавливает браузер, разворачивает приложение и проверяет изменение. Агент пришёл поставить галочку, а в итоге запустил код. После этого сломанные PR стали редкостью. Осталась другая проблема — PR, которые работают, но не вписываются в дорожную карту.

CI — стена, а не рекомендация

Codecov и другие проверки настроены как required checks. Агент открывает PR, через несколько минут видит, что мёрж заблокирован, загружает навык с тестами и добивается покрытия. Никто не просил — инфраструктура сама направила агента.

CLA (Contributor License Agreement) как детектор человека

AutoGPT использует двойную лицензию, но Тиндл советует лицензионное соглашение участника (Contributor License Agreement, CLA) любому проекту, даже MIT. Подписание требует браузера и OAuth-потока GitHub на отдельном домене. Сегодня агенты с этим справляются плохо — и это хорошо, потому что большинство мейнтенеров не хотят, чтобы агент ходил в GitHub от их имени. Если CLA не подписан в течение недели, PR закрывается с комментарием «подпишите CLA и переоткройте».

SHA коммита перед закрытием замечания

Часть агентов закрывает все треды ревью, не исправляя код. В AutoGPT есть навык pr-address, который описывает допустимую последовательность: исправить, закоммитить, запушить, ответить, потом разрешить тред. Ответ должен содержать полный SHA коммита, полученный через git rev-parse HEAD, чтобы агент не подсунул старый хеш. Навык явно называет антипаттерны: «Acknowledged» — не исправление, и ссылка на коммит, который не трогает указанную строку, тоже не считается.

Ворота, от которых пришлось отказаться

Когда CI падает, AutoGPT изначально запускала агента, который читал лог и писал комментарий, что сломалось. Первая версия использовала Claude Code внутри GitHub Actions с аутентификацией в CI — лишняя широкая учётная запись. Потом перешли на Copilot внутри рабочего процесса: тот же результат, но без лишних кредов.

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

Четыре ловушки, которые стоит записать

• Плохой AGENTS.md хуже, чем его отсутствие. В AutoGPT сначала разбросали файлы повсюду и засорили контекст. Если поведение агентов ухудшилось — перечитайте, что вы написали.
• GraphQL API GitHub быстро исчерпывает лимит запросов. Если каждый инструмент в команде ходит в CLI как отдельный пользователь, лимит закончится. Создайте GitHub App и аутентифицируйте CLI через неё.
• Сложное ревью стоит реальных денег. У AutoGPT PR проходит через клон ветки, восемь агентов с разными ролями, запуск стека и скриншоты. Круто, но дорого. Сейчас эту процедуру запускают только для совсем маленьких или крупных PR.
• Проверяйте авторизованные приложения. Каждый протестированный инструмент оставляет OAuth-разрешение. Если перестали использовать приложение — удалите его из настроек GitHub.

Не всё в open source решается воротами

Тиндл подчёркивает два тезиса, которые не связаны с инструментами. Первый: вы не обязаны принимать каждый пулреквест. Мёржить чужой LLM-вывод — асимметричная сделка: вы будете поддерживать этот код вечно. Закрыть PR и переписать решение самому — валидный выбор.

GitHub даёт мейнтенерам ручки: можно отключить пулреквесты целиком, ограничить создание issue только участникам с правами collaborator или требовать предварительного обсуждения. Если хотите — вообще закройте приём внешнего кода, как это сделали в SQLite: они принимают только баг-репорты. У вашего проекта тоже может быть своя граница.

Второй тезис: когда вы закрываете PR, но переписываете его идею сами, добавьте автора как соавтора, если это уместно. В AutoGPT 800 контрибьюторов, и один дополнительный соавтор ничего не стоит. Для большинства людей важно, что их проблему заметили и исправили.

Выводы

Open source развивался, делая сотрудничество явным: лицензии формализовали разрешения, issue сделали работу видимой, пулреквесты превратили ревью в общую практику. Инструкции для агентов в репозитории — следующий шаг в этом направлении. Правильная форма ещё не устоялась: у AutoGPT уже третья версия AGENTS.md, и она появилась потому, что команда сначала развёртывала плохие версии и смотрела, что с ними делают агенты.

Тиндл советует мейнтенерам записываться в программу обратной связи GitHub — maintainers.github.com:

You've got to go there. You've got to sign up. It gets you all the connections you want at GitHub. That's where I learned about all this stuff, and where I share it.

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

Если тема интересна, загляните в разделы tproger: open source, GitHub и искусственный интеллект.

Источник: GitHub Blog — Your contributors are AI-first now. Is your project?

В статье loops определяются просто: агент повторяет циклы работы до тех пор, пока не выполнится условие остановки. Разница между типами циклов Anthropic выводит из четырёх вещей: что запускает цикл, что его останавливает, какая примитивная команда Claude Code используется и для каких задач это подходит.

Что такое loop в Claude Code

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

Для российских разработчиков, которые часто запускают Claude Code на удалённом сервере по SSH, это особенно удобно: можно настроить цикл, который работает, пока вы спите, и присылает отчёт утром в Telegram или Slack. Главное — не забыть про лимиты токенов, потому что неограниченный цикл способен съесть месячный бюджет за одну ночь.

Claude Code предлагает четыре типа loops: turn-based, goal-based, time-based и proactive.

Каждый цикл характеризуется триггером, условием остановки и подходящей командой: ручной prompt, /goal, /loop//schedule или автоматическая рутина.

Качество результата зависит от проверочных навыков (SKILL.md) и чистоты кодовой базы, а не только от самого цикла.

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

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

Четыре типа циклов

Turn-based: ручной цикл

Самый простой и самый знакомый вид. Пользователь отправляет prompt, Claude собирает контекст, вносит правки, запускает тесты и возвращает результат. После этого человек проверяет работу и пишет следующий prompt. Каждый такой оборот — это один turn.

По мнению команды Claude Code, здесь ключевой рычаг — не более длинный prompt, а проверочный SKILL.md. Если вы обычно вручную открываете dev-сервер, кликаете по новой кнопке, проверяете консоль и запускаете Lighthouse, эти шаги стоит записать в skill. Чем более количественные проверки вы зададите, тем чаще Claude сможет сам понять, что задача выполнена.

Goal-based: цикл с целью через /goal

Когда задача сложная и одного оборота недостаточно, помогает команда /goal. Вы явно описываете критерий успеха и максимальное число попыток. Каждый раз, когда Claude хочет остановиться, оценочная модель проверяет условие: если цель не достигнута — агент возвращается к работе.

Чем более детерминирован критерий, тем лучше. «Сделай хорошо» — плохая цель. «Добейся Lighthouse Performance ≥ 90, не более 5 попыток» — хорошая. То же самое работает для числа пройденных тестов, покрытия кода или отсутствия ошибок линтера.

Time-based: цикл по расписанию /loop и /schedule

Некоторые задачи не требуют вашего присутствия: утренняя сводка по Slack, проверка PR на ревью, мониторинг CI. Для таких случаев есть /loop: команда повторяет prompt через заданный интервал, пока вы её не отмените или пока работа не закончится.

/loop работает на вашем компьютере, поэтому при выключении терминала цикл остановится. Если нужно, чтобы агент работал в облаке даже с закрытым ноутбуком, используется /schedule — эта команда создаёт рутину, которая запускается по расписанию на серверах Anthropic (research preview).

Proactive: проактивные рутины

Проактивные циклы объединяют всё вышеперечисленное: /schedule для запуска по событию или расписанию, /goal для критерия готовности, skills для проверки, dynamic workflows для параллельной обработки и auto mode, чтобы цикл не останавливался на каждом разрешении.

Типичный сценарий: обработка входящих баг-репортов. Рутина каждый час проверяет канал обратной связи, триажирует каждую заявку, чинит баг, прогоняет тесты и отвечает пользователю. Для сложных случаев можно параллельно исследовать несколько решений в разных worktrees и поручить «судейскому» агенту выбрать лучшее.

Как не потерять качество кода

Автономность без контроля качества быстро превращается в генерацию мусора. В гайде Anthropic выделяет четыре опоры, на которых держится качество loop:

• Чистая кодовая база. Claude копирует паттерны, которые уже есть в проекте. Если в репозитории хаос, агент будет его множить.
• Проверочные skills. SKILL.md должен содержать конкретные шаги, инструменты и критерии, по которым Claude сам оценивает результат.
• Актуальная документация. Фреймворки и библиотеки меняются, и агенту нужны свежие best practices.
• Второй агент для ревью. Проверяющий со свежим контекстом менее предвзят, чем основной агент. Можно использовать встроенный /code-review или Code Review for GitHub.

Важный совет: когда отдельный результат не дотягивает до стандарта, не исправляйте только конкретный случай — закодируйте правило в skill или CLAUDE.md, чтобы все будущие итерации работали лучше.

Как не сжечь бюджет на токенах

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

• Выбирайте подходящий примитив и модель: мелкие задачи не нуждаются в сложных оркестрациях.
• Формулируйте чёткие критерии завершения: конкретнее цель — меньше лишних итераций.
• Запускайте пилот на малой выборке перед массовым прогоном.
• Используйте скрипты для детерминированной работы: запуск готового скрипта дешевле, чем рассуждение модели.
• Не запускайте рутины чаще, чем меняется объект мониторинга.
• Регулярно смотрите /usage, /goal без аргументов и /workflows, чтобы видеть, куда уходят токены.

С чего начать

Авторы гайда предлагают не начинать с proactive-рутин, а посмотреть на свою повседневную работу и найти одно место, где вы сами являетесь узким звеном. Задайте три вопроса:

• Могу ли я описать проверку результата так, чтобы Claude мог сам её выполнить?
• Достаточно ли чётко я понимаю, что значит «готово»?
• Эта работа приходит по расписанию или в ответ на внешние события?

Если ответ на первый вопрос «да» — начните с turn-based цикла и проверочного skill. Если на второй — попробуйте /goal. Если на третий — /loop или /schedule. Запустите цикл, понаблюдайте, где он застревает или перегибает палку, и дорабатывайте harness, а не только prompt.

Сводка: какой цикл когда использовать

FAQ

Выводы

Гайд Anthropic — не просто описание четырёх команд. Это попытка дать разработчикам общий язык для обсуждения того, как ИИ-агенты переходят из разряда «помощников в чате» в разряд «автономных рабочих процессов». Turn-based, goal-based, time-based и proactive loops — это не конкуренты, а ступени одной эволюции: от ручного управления каждым шагом к проектированию систем, которые управляют сами собой.

Главная метафора, которую стоит уносить с собой: ваш вклад перестаёт измеряться качеством очередного prompt, а начинает измеряться качеством harness — системы проверок, остановок и триггеров. Если вы ещё не пробовали /goal или /loop, начните с одной повторяющейся задачи на этой неделе. Скорее всего, вы удивитесь, как много ручной работы можно отдать циклу.

I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

Источники:

• Getting started with loops — официальный гайд Anthropic
• @ClaudeDevs on X
• Loop Engineering — Addy Osmani

Эта статья объясняет, почему классических CI/CD-ворот недостаточно для production-систем на базе ИИ. Автор делится практическим подходом к release gates для LLM-пайплайнов с помощью baseline-оценок, детектирования дрейфа, shadow-проверок и ограничений по стоимости и латентности. Акцент — на профилактике: отлов тихих AI-регрессий до того, как они достигнут пользователей, на основе реальных уроков платформенной инженерии из production-инфраструктуры.

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

В тот момент я перестал доверять зелёному цвету как сигналу к релизу. У нас не было проблемы с деплоем. У нас была проблема с release gates. Классический CI/CD создавался для детерминированного ПО. LLM — вероятностны. Наши ворота тоже должны быть вероятностными.

Классические CI/CD-ворота работают по принципу pass/fail, но LLM поставляют поведение, а не только код, поэтому нужны ворота, отслеживающие дрейф поведения.

Три режима отказа: eval drift (постепенная деградация оценок), distribution shift (реальные запросы отличаются от тестовых) и context poisoning (изменились извлечённые документы, а тесты спрашивают вчерашнее).

Четыре release gates: baseline eval suite, eval drift detection, shadow traffic validation, cost/latency guardrails.

Ворота должны быть простыми и понятными команде, иначе инженеры начнут их обходить.

Eval-датасеты нужно версионировать так же тщательно, как Terraform state: с бэкапами и параноей.

Почему классический CI/CD не справляется с LLM-пайплайнами

В обычной доставке ПО ворота достаточно просты: unit-тесты прошли, интеграционные тесты прошли, проверки безопасности прошли — деплой. Это бинарно. Сборка зелёная или красная. Эта модель ломается, когда вы поставляете не код, а поведение.

Классический CI/CD создавался для детерминированного ПО. LLM — вероятностны. Наши ворота тоже должны быть вероятностными.

Production-система на базе ИИ может сегодня показывать relevance 0,82, завтра 0,79, а на следующей неделе 0,74. Поскольку ни один запуск не пересекает порог отказа, никого не пейджат, хотя пользователи уже получают худшие ответы.

Я больше 20 лет управлял production-инфраструктурой: приватными облаками OpenStack, миграциями баз данных, CI/CD-пайплайнами и mission-critical системами. В классическом DevOps мы усвоили: сервер, который сообщает о 99,9% аптайма при потере 0,1% финансовых транзакций, — не здоров. Он скрывает баг. Оценки LLM работают так же. Агрегированные метрики маскируют локальные отказы.

Первый режим отказа — eval drift: оценки деградируют постепенно, но недостаточно, чтобы упасть по жёсткому порогу. Второй — distribution shift: реальные пользователи задают короткие, беспорядочные, странные вопросы, о которых ваш чистый eval-датасет и не думал. Третий — context poisoning: ваши извлечённые документы изменились, а тесты всё ещё спрашивают вчерашние вопросы.

Традиционный CI/CD gate спрашивает: «Тест прошёл?» LLM release gate спрашивает: «Поведение осталось в допустимом диапазоне?» Обычный gate сравнивает ожидаемый вывод с фактическим. AI CI/CD gate сравнивает кандидатное поведение с историческим и production-поведением, а также со стоимостью, латентностью и риском. Традиционные ворота быстро отсеивают исключения. LLM release gates внимательно отсекают дрейф.

Традиционные ворота быстро отсеивают исключения. LLM release gates внимательно отсекают дрейф.

Это различие важно, потому что production AI-системы гниют, а не взрываются. Я создал llm-eval-drift-release-gates-AGENT, потому что хотел ворота, которые относятся к AI-релизам как к инфраструктурным релизам: измеримым, повторяемым и, по возможности, скучным. Скука недооценена. Она позволяет инженерам спать.

Анатомия LLM release gate

Первое ворото — baseline eval suite. Он прогоняет фиксированный датасет по кандидатному пайплайну и оценивает relevance, faithfulness, safety, groundedness и любые доменные проверки, которые вам важны. Цель не в том, чтобы доказать, что модель идеальна. Цель — поймать регрессии до того, как они станут историями от клиентов.

Вот упрощённая Python-структура из паттерна, который я использую:

Использование StrEnum сохраняет enum в виде строк без множественного наследования. Это важно в релизном инструментарии, потому что значения статусов часто логируются, сериализуются, сравниваются в CI или передаются в дашборды.

Это ловит очевидные отказы: коллапс relevance, падение faithfulness, небезопасные выходы или искажённые результаты оценщика. Если отказ жёсткий, пайплайн блокируется немедленно; если срабатывает предупреждение, требуется ручное одобрение. Мне не нравятся тихие предупреждения: это будущие инциденты в хорошей рубашке.

Второе ворото: детектирование дрейфа оценок

Второе ворото — детектирование дрейфа оценок. Фиксированного порога недостаточно. Если relevance падает с 0,91 до 0,86, ваш порог 0,80 говорит, что всё в порядке. Ваши пользователи могут не согласиться.

Поэтому я сравниваю текущие оценки с rolling baseline из недавних деплоев:

Eval suite обнаружил 6% падение relevance в 23:00 в четверг. Без него это падение достигло бы 200 пользователей к понедельнику. Ворото не знало бизнес-контекста. Ему это и не нужно. Оно знало, что кандидат хуже последнего известного хорошего релиза.

Третье ворото: shadow traffic validation

Третье ворото — shadow traffic validation. Перед полным раскатом я направляю небольшой процент реального трафика на кандидатный пайплайн. Пользователи всё ещё получают production-ответ, но система записывает кандидатный вывод для сравнения.

Это canary-deployment, применённый к ИИ. Я использовал тот же паттерн в инфраструктурных раскатах, включая идеи из моего репозитория eks-canary-deployment-pipeline. Разница в том, что для LLM вы сравниваете не только HTTP 200. Вы сравниваете качество ответа, извлечённый контекст, латентность и причины, по которым кандидат расходится с production подозрительным образом.

Judge-модель может быть полезна, но я не даю ей быть единственным авторитетом. Она даёт сигнал. Release policy принимает решение.

Четвёртое ворото: стоимость и латентность

Четвёртое ворото — стоимость и латентность. Модель, которая идеально оценивается, но стоит в 3 раза дороже, — не валидный релиз. RAG-пайплайн, который добавляет две секунды латентности, тоже не готов. Эта же логика легла в основу моей работы enterprise-rag-guardrails-costops.

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

Эти четыре ворота не делают деплой LLM идеальным. Они делают сложнее поставку бессмыслицы под зелёным бейджем.

Как встроить это в существующий CI/CD

Release gate не должен быть отдельным научным проектом. Если ваша платформенная команда уже использует GitHub Actions или GitLab CI, LLM-пайплайн деплоя должен вписаться в этот workflow.

Паттерн намеренно скучный:

Такую форму я расширил из своей работы devsecops-pipeline-github-actions. Соберите приложение. Запустите детерминированные тесты. Запустите baseline eval suite. Сравните с rolling baselines. Провалидируйте на shadow-трафике. Проверьте бюджеты стоимости и латентности. Деплойте, только когда все ворота согласны.

Здесь guardrails MLOps становятся полезны платформенным инженерам. Вам не нужна отдельная религия деплоя. Вам нужен один дополнительный набор проверок внутри пайплайна, которому команда уже доверяет.

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

Лучший release gate — тот, которым команда реально пользуется. Если для настройки нужна PhD по ML, это не ворота. Это стена. Я сейчас получаю степень PhD в области безопасности облачных вычислений, и даже я не хочу процесс деплоя, которому каждую пятницу нужна диссертация. Ворота должны быть достаточно простыми, чтобы запускаться в CI, достаточно строгими, чтобы блокировать плохие релизы, и достаточно гибкими, чтобы не стать офисным украшением.

Последняя часть далась мне дольше, чем хотелось бы признать.

Ошибки, которые я совершил, и что бы сделал иначе

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

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

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

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

Оценки выглядели отлично. Production — нет.

Моя третья ошибка — не версионировал eval-датасет. Когда я добавлял новые крайние случаи, я терял возможность сравнивать старые релизы с новыми baselines. Теперь я версионирую eval-наборы так же, как версионирую Terraform state: внимательно, с бэкапами и с лёгкой паранойей.

Строить это из Кочабамбы, Боливия, тоже повлияло на дизайн. У меня не было неограниченных облачных кредитов на огромные eval-прогоны. Это заставило оптимизировать сэмплирование, кешировать вызовы judge-модели и разделять быстрые PR-проверки от более тяжёлых ночных.

Ограничения рождают лучшую инженерию. Раздражает, но правда.

Отправляйте уверенность, а не только код

В классическом ПО мы поставляем код и проверяем поведение. В ИИ мы поставляем поведение и проверяем соответствие. Release gates — это то, как мы закрываем этот разрыв.

LLM release gates не уберут неопределённость из production AI-систем. Ничто не уберёт. Но они дают платформенным командам практический способ поймать eval drift, distribution shift, context poisoning, скачки стоимости и регрессии латентности до пользователей.

Это важно для надёжности агентных workflow. Это важно для AI CI/CD. Это важно, потому что «все тесты прошли» больше не достаточно.

Я создал llm-eval-drift-release-gates-AGENT, потому что устал от зелёных пайплайнов, которые мне лгали. Репозиторий — open-source, offline-first референсная реализация этого паттерна release gates. Он намеренно достаточно мал, чтобы изучить, запустить, сломать и ужесточить в своём CI/CD.

Репозиторий: https://github.com/fdaniel-alvarez-dev/llm-eval-drift-release-gates-AGENT. Форкайте, ломайте, улучшайте. Худший release gate — тот, который вы никогда не построили.

Выводы

Классический CI/CD создавался для детерминированного ПО, а LLM — вероятностны. Поэтому release gates для ИИ должны отслеживать не только прохождение тестов, но и дрейф поведения: baseline-оценки, детектирование дрейфа, shadow-трафик, стоимость и латентность.

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

Что вы скажете о следующем утверждении?

«Будущее разработки ПО — за ИИ-агентами. Нам больше не нужны разработчики, которые тормозят развитие бизнеса»

Если вы сеньор и согласны с этим, я начинаю сомневаться в вашей компетентности (потом объясню почему; тут нет никакой враждебности). Но если вы не сеньор и согласны с этим, то, думаю, вы, скорее всего, правы. Что? Как так? Суть копирайтинга в том, чтобы донести идею до конкретной аудитории. Поэтому для меня, как копирайтера, происходящее очевидно: одно и то же послание всеми воспринимается по-разному.

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

Но минуточку! Многие заслуженные и знаменитые разработчики тоже провозглашают смерть своей профессии. Как же так? Чья интуиция тут права? И в чём причина такого противоречия?

Задача сеньора — избегать проблем

Когда я прихожу в команду, то встречаю два типа сеньоров. Первый обычно говорит что-то в духе:

• «Я тут новый прикольный инструмент нашёл…»
• «А вот в компании <название компании, не имеющей с нашей ничего общего> делают вот так, так что…»
• «Гляньте пост, там пишут, что это — лучшая практика, нам бы тоже стоило…»

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

А есть и другой тип сеньора:

• «Нам это правда нужно?»
• «А что, если этого не делать?»
• «Может, пока так оставим? Вернёмся к этому позже, когда прижмёт?»

О, а вот это мой человек! Эксперт по избеганию, сокращению и повторному использованию. Он хочет как можно меньше заниматься разработкой.

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

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

Бизнес боится неопределённости

Давайте для простоты представим бизнес в виде двух циклов.

Вот первый цикл; здесь живут маркетологи, продажники, продакт-менеджеры, гендиректор:

Главная цель этого цикла — пробовать и учиться. Бизнес стремится выводить продукты на рынок, чтобы получить фидбэк и понять, представляют ли они какую-либо ценность.

Для людей в этом цикле главный монстр — неопределённость. Неопределённость жестока, ведь ни одна стратегия не даёт гарантий. Если добавить сюда фактор времени (зарплаты маркетологов/продажников, фонд оплаты труда основателей или данные для продактов), начинает казаться, что единственный способ победить неопределённость до дедлайна — это выкатывать всё на рынок как можно быстрее. Чем больше ты выводишь на рынок, тем больше получаешь обратной связи, тем сильнее (в теории) снижаешь неопределённость.

Этот цикл (все компании с него начинают) — это про скорость в чистом виде.

Но что происходит, когда у бизнеса появляются клиенты?

Сеньорам крайне важна стабильность

Обратите внимание на второй цикл. Клиенты платят за сервис.

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

Сеньоры переживают за стабильность, потому что на них лежит ответственность за то, чтобы бизнес продолжал обслуживать клиентов.

А что ставит всё это под угрозу? Сложность. Из-за неё система становится менее понятной, её тяжелее отлаживать, чинить и объяснять, и в итоге она становится менее стабильной. Растёт сложность = падает стабильность = сеньор не справляется со своими обязанностями = всем плохо, платежи не проходят, все грустят.

Итак, если цель первого цикла — уменьшить неопределённость, то цель второго — совладать со сложностью.

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

Окей, теперь вы, наверное, догадываетесь, к какому ответу на заглавный вопрос я веду.

В зависимости от того, в каком цикле вы работаете, ваша проблема видится под разными углами (вот почему, на мой взгляд, разработчики так по-разному смотрят на ИИ: одни больше задействованы в первом цикле, другие — во втором).

Вот как выглядит история для людей из первого цикла:

А вот как выглядит история для сеньора из второго цикла:

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

Диагноз копирайтера: нельзя отмахнуться от чужой проблемы, прикрываясь своими.

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

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

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

• Нужно провести опрос? Для этого есть Google Forms.
• Нужно запилить новую фичу, чтобы проверить гипотезу? А что, если просто добавить кнопку в существующий интерфейс и посмотреть, кликают ли на неё?
• Нужен новый сервис аналитики? А для какого такого важного решения эта аналитика нам нужна? Может, начнём с одного решения, одного графика и одной метрики?
• Зачем печь огромный торт? Просто воткни свечку в мой бутерброд!

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

Но как объяснить это, не расписывая целые поэмы? Копирайтеры — мастера упаковывать сложные идеи в лаконичные формы. И вот та самая волшебная фраза, которую стоит выучить каждому сеньору:

Может, попробуем какой-нибудь способ побыстрее?

Слово «побыстрее» показывает, что вы понимаете их главный запрос; «какой-нибудь» намекает, что есть другой путь; «попробуем» предполагает, что решение может быть неидеальным, но вполне рабочим. Эта фраза идеально попадает в потребность бизнеса (скорость для снижения неопределённости) и в то же время оставляет сеньору пространство для манёвра: сократить, переиспользовать, а в лучшем случае — вообще ничего не делать.

Вот и всё. Это и есть мой ответ на вопрос в заголовке: сеньоры мыслят категориями сложности, когда всех вокруг волнует неопределённость.

Но! Есть огромное «но»! Кажется, что с приходом ИИ всё это теряет смысл, верно? Зачем что-то урезать? Зачем переиспользовать? Зачем избегать? Ведь ИИ может написать кучу всего за минимальное время. Однако он пока не умеет делать то, что по-прежнему делают сеньоры. Нести ответственность.

Почему сеньоры — это редакторы, а не писатели

Для сеньора очень важно глубоко понимать систему. Такое понимание даёт возможность чинить её, когда что-то идёт не так, и продуманно расширять по мере роста. Но самое главное — это позволяет стабильно и без сбоев обслуживать клиентов, которые платят за продукт.

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

Так изначально выглядят два бизнес-контура:

А вот как ИИ на них влияет:

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

К счастью, у сеньоров есть пара козырей в рукаве. Один из них — decoupling (разделение). Долгое время только разработчики могли создавать софт. И они отвечали сразу за оба контура.

Одна система на две цели.

А что, если у нас будут две системы, каждая для своей цели?

Аналогия: писатель торопится закончить первый черновик (его ещё называют «черновик потока сознания» — vomit draft), а потом выбирает из него то, что работает, и выбрасывает остальное. После быстрого набрасывания текста идёт редактура. Работа редактора — взять удачные куски и собрать из них что-то цельное.

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

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

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

Фичи создаются в Speed-версии, а затем доводятся до стабильного состояния в Scale-версии.

Как это будет выглядеть на практике, может быть, не до конца ясно, но основная идея состоит в том, чтобы добиться чётко оговорённого разделения (decoupling), которое покажет: одно дело — гнаться за скоростью, и совсем другое — обеспечивать стабильность.

Представьте, что вас просят запилить нечто амбициозное, и вы отвечаете: «Без проблем, Speed-версия будет готова через 3 дня, Scale-версия — недель через 6». Они получают желаемое — скорость и движение вперёд. Вы получаете желаемое — время на изучение и проектирование. Как вам? Что скажете, сеньор-разработчики? Или мне стоит называть вас сеньор-редакторами?

GitLab опубликовала отчёт на основе опроса более чем 1500 разработчиков и технологических лидеров. 60% заявили, что ROI инструментов ИИ-кодирования уже превзошёл ожидания. Однако 80% организаций внедрили ИИ быстрее, чем выработали политики управления, а 82% опасаются, что ИИ-код порождает новый технический долг.

• 60% считают ROI ИИ-кодирования выше ожиданий.
• 78% команд пишут и коммитят код быстрее.
• Только 21% видят продуктивность за пределами генерации кода.
• 85% считают, что следующий этап — управление ИИ-кодом, а не его генерация.
• Agentic infrastructure состоит из четырёх слоёв: исполнение, контекст, управление и оркестрация.

Проблема в том, что современная инфраструктура создана под человеческую скорость и подотчётность. Git-бекенды, CI/CD, системы деплоя и governance-фреймворки не рассчитаны на миллионы сессий агентов. Это ведёт к деградации надёжности платформ, росту уязвимостей и перерасходу токенов.

Четыре слоя agentic infrastructure

1. Исполнение в машинном масштабе

Git-бекенды, пайплайны CI/CD и системы деплоя проектировались под темпы человеческой работы. В эпоху агентов они должны выдерживать миллионы сессий без сбоев. Когда инцидент случается в продакшене, путь от симптома к причине должен занимать минуты, а не дни.

2. Контекст, который путешествует с кодом

Агент полезен ровно настолько, насколько полный контекст ему доступен. Контекстный граф, связывающий код, задачи, пайплайны, security-фидбек и продакшен-сигналы, позволяет агентам действовать осмысленно и снижает риск «искусственной уверенности».

Агент может быть только таким хорошим, какой контекст и семантика ему предоставлены.

3. Управление, встроенное в процесс

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

4. Оркестрация

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

Часто задаваемые вопросы

Выводы

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

Источник: The New Stack — Agentic Infrastructure & AI Governance.

Таковы результаты ежегодного исследования компании Checkmarx — вендора инструментов для анализа безопасности приложений. В опросе участвовали 2350 разработчиков, CISO (Chief Information Security Officer) и AppSec-менеджеров (application security) по всему миру. Выборка выросла на 54% по сравнению с прошлым годом, что делает данные ещё более репрезентативными.

70% разработчиков считают ИИ-код более уязвимым, чем человеческий.

30% всех опрошенных сознательно деплоят уязвимый код в продакшен.

93% компаний пережили хотя бы один инцидент безопасности из-за уязвимых приложений.

Организации, где 81–100% кода генерируется ИИ, деплоят уязвимости в 3,4 раза чаще, чем те, где ИИ-генерация составляет 1–20%.

59% кода в продакшене — open source, который тоже не идеален с точки зрения безопасности.

ИИ пишет половину кода — и это проблема

По данным Checkmarx, сегодня примерно 49% кода в продакшене создаётся с помощью ИИ. Это немного меньше, чем 54% в прошлом году, но всё ещё колоссальная цифра. Почти каждая вторая строка в вашем приложении может быть рождена нейросетью, которая обучалась на публичных репозиториях — со всеми их багами, устаревшими паттернами и скрытыми уязвимостями.

Причина проста: языковые модели обучаются на огромных массивах существующего кода, включая устаревшие практики и известные CVE (Common Vulnerabilities and Exposures). Исследователи из University of Central Florida и Birzeit University в 2025 году провели сравнительный анализ безопасности кода, сгенерированного разными LLM для Java, Python, C и C++. C-код оказался самым дырявым, Python — относительно чистым. Но ключевой вывод исследования шире: модели «недоиспользуют современные языковые и компиляторные возможности, предпочитая устаревшие практики более безопасным альтернативам». Сами исследователи оговаривают: LLM эволюционируют быстро, и их выводы — это «снимок во времени» (time-stamped view), а не вечная истина.

Почему разработчики деплоят то, что не доверяют

Вот в чём парадокс: разработчики видят проблему, но не чувствуют ответственности за её решение. Основные причины, по которым уязвимый код попадает в прод, выглядят так:

• Давление сроков и необходимость быстро деплоить фичи.
• Уязвимости слишком сложно или дорого исправлять постфактум.
• Надежда на то, что «другие инструменты безопасности подхватят» на поздних этапах.
• Нормализация риска: когда все вокруг деплоят с багами, это перестаёт восприниматься как катастрофа.

Checkmarx прямо констатирует: «Risk is normalized» — риск стал нормой. 93% респондентов сообщили о как минимум одной бреши в безопасности, связанном с уязвимыми приложениями. В прошлом году это было 98% — статистика чуть улучшилась, но не кардинально. Когда девять из десяти компаний регулярно взламывают, инцидент перестаёт быть новостью и становится рутиной.

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

Самая тревожная цифра: организации, где 81–100% кода генерируется ИИ, деплоят уязвимый код в 3,4 раза чаще, чем компании с умеренным использованием ИИ (1–20%). Это прямая корреляция: чем выше доля ИИ-генерации, тем чаще в прод попадают уязвимости. Причина не только в самом коде, но и в том, что высокая скорость разработки часто сопровождается слабыми процессами безопасности.

Open source как фундамент — и фундамент трещит

Ещё один слой проблемы — open source. По оценкам респондентов, 59% кода в продакшене приходится на открытые библиотеки. Это самооценки, но они отражают реальность: современный проект без node_modules, requirements.txt или Cargo.toml немыслим. Проблема в том, что мейнтейнеры этих библиотек часто не успевают закрывать уязвимости, а злоумышленники активно внедряют вредоносные пакеты в npm, PyPI и другие репозитории.

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

Например, вот типичная разница между ИИ-сгенерированным кодом и безопасной альтернативой. Copilot или аналогичные инструменты часто предлагают устаревший pickle.load для десериализации данных:

pickle.load выполняет произвольный Python-код при десериализации — классическая уязвимость из списка OWASP Top 10. Аналогичные проблемы часто встречаются в SQL-запросах без параметризации, использовании eval() и устаревших криптографических функциях. Проверяйте каждый snippet перед мержем.

Как не превратить ИИ-ускорение в ИИ-катастрофу

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

1. Проверяйте ИИ-код так же тщательно, как человеческий. Не предполагайте, что нейросеть знает лучше.
2. Автоматизируйте сканирование уязвимостей в CI/CD. SAST (Static Application Security Testing) и DAST (Dynamic Application Security Testing) должны быть обязательным шагом пайплайна, а не опцией.
3. Аудитируйте зависимости. Используйте инструменты вроде npm audit, Snyk или OWASP Dependency-Check.
4. Обучайте команду безопасности. Разработчики должны понимать, какие уязвимости чаще всего генерирует ИИ для вашего стека.
5. Не жертвуйте безопасностью ради скорости. Если уязвимость критична — отложите релиз. Технический долг в безопасности обходится в разы дороже, чем в производительности.

Выводы

ИИ — это не замена разработчику, а ускоритель. Как любой ускоритель, он требует тормозов. Когда 30% всех опрошенных сознательно деплоят код, в котором сами признают уязвимости, проблема не в технологиях — а в отсутствии дисциплины. Не верьте нейросети на слово: проверяйте зависимости, сканируйте код, требуйте ревью. Ускорение без контроля — это не оптимизация, а авария в замедленной съёмке.

Источник: The Register — Devs know AI code is riddled with holes, but ship it anyway

Что такое Agentic SRE

Agentic SRE — это практика, в которой автономные ИИ-агенты помогают наблюдать за системами, анализировать телеметрию (метрики, логи, трейсы) и выполнять ограниченные операционные действия при заданных человеком guardrails (правил безопасности). Агент не заменяет SRE-инженера, а работает как цифровой напарник: собирает контекст, предлагает гипотезы и выполняет только те действия, которые одобрены политикой.

Ключевое отличие от классической автоматизации — способность к рассуждению. Традиционные скрипты реагируют на жёсткие триггеры («если CPU > 90%, то перезапустить»). Агент же может связать всплеск ошибок с недавним развёртыванием, проверить корреляцию по трейсам и предложить конкретный план действий — всё до того, как инженер откроет ноутбук.

Agentic SRE — это ИИ-агенты, которые помогают инженерам наблюдать, диагностировать и реагировать на инциденты.

Основная цель — сократить рутину и ускорить принятие решений, а не заменить человека.

Ключевые сценарии: триаж алертов, инцидент-копилот, автоматический RCA, безопасное исправление, обучение на инцидентах.

Безопасность превыше всего: агенты работают с allowlists, approval gates и полным аудитом.

Российские команды могут строить стек на OpenTelemetry, Prometheus/Grafana, собственных LLM и PagerDuty/Opsgenie.

Почему это важно именно сейчас

Сегодняшние системы стали слишком распределёнными, шумными и динамичными, чтобы человек успевал за ними вручную. Микросервисы, Kubernetes, feature flags и канареечные развёртывания создали ландшафт, где одно изменение может затронуть десятки сервисов, а сигналы о проблемах разбросаны по десяткам дашбордов.

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

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

Из чего строится стек

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

• Телеметрия: OpenTelemetry — стандарт сбора телеметрии — для сбора логов, метрик и трейсов в едином формате.
• Наблюдаемость: Prometheus, Grafana, Datadog, New Relic, Elastic или облачные системы — хранилище и визуализация.
• Оркестрация: MCP-серверы (Model Context Protocol от Anthropic), внутренние API или системы рабочих процессов, которые предоставляют агенту безопасные инструменты.
• Среда выполнения агента: LLM-фреймворки с function calling, планированием и работой с инструментами.
• Рабочий процесс при инцидентах: PagerDuty, Opsgenie, Slack, Jira, ServiceNow — куда агент пишет отчёты и запрашивает подтверждения.
• Safety Layer: RBAC, approval gates, audit logs, allowlists и пути отката — неотъемлемая часть, а не дополнение.

Принцип безопасности:
Агент должен уметь делать только то, что мог бы сделать дежурный инженер после одобрения. Это делает систему практичной и снижает риск случайного ущерба.

Пять сценариев, которые уже работают

1. Триаж алертов: от шума к сути за секунды

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

2. Инцидент-копилот: второй мозг в канале

Агент подключается к каналу реагирования (Slack, Teams) и выполняет роль «второго мозга»: строит таймлайн, подтягивает ссылки на дашборды, отслеживает гипотезы по мере их проверки. Когда в инциденте участвуют несколько инженеров, это предотвращает фрагментацию контекста и дублирование усилий.

3. Автоматический черновик RCA (Root Cause Analysis)

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

4. Безопасное исправление под контролем

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

5. Обучение на инцидентах: от пожаротушения к профилактике

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

Guardrails: почему доверие важнее интеллекта

Главный риск агентного SRE не в том, что агент слишком умен, а в том, что он может быть слишком уверен в себе. LLM способны генерировать правдоподобные, но неверные объяснения. Поэтому каждая рекомендация должна быть прослежена до реальной телеметрии, а каждое действие — ограничено явными правами.

• Action allowlists: агент может делать только то, что в белом списке.
• Approval gates: рискованные изменения требуют подтверждения.
• Полный audit log: каждое действие агента записывается.
• Read-only mode на этапе внедрения: сначала наблюдаем, потом действуем.
• Разграничение прав по сервисам и командам.
• Human override на каждом шаге: человек всегда может взять управление.

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

Выводы

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

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

Источник: Agentic SRE: The Next Frontier of Reliability — DevOps.com (Neel Shah, 2026).

В agile-средах расползание объёма (scope creep) начинается тогда, когда продакт-менеджер теряет из виду цель и аудиторию. В попытке впихнуть в продукт побольше функций «чтобы всем угодить» команда каменеет, как от взгляда Медузы Горгоны: больше никакой гибкости, остаётся либо погибнуть в analysis paralysis, либо вязнуть в болоте.

• Хорошие проектные менеджеры закладывают в план буфер на 15–30% незапланированной работы; скрам-команды планируют только 70–80% мощности спринта.
• Расширять объём стоит, если новая фича повышает удовлетворённость клиента, ускоряется через AI-инструменты или работает как «множитель силы» — открывает возможности с отдачей минимум 10x.
• AI-инструменты вроде Claude Code, Figma Make, Gemini, NotebookLM и ChatGPT помогают доставить больше за то же время — это и превращает scope creep в управляемую гибкость.
• Главный тест: «то же усилие — лучший результат». Если для нового пункта нужно столько же часов, сколько на исходные фичи, это не хорошее расползание, а просто новая работа.
• Guardrails против перегрузки: формальный change management, защита буфера, лимит расширения объёма (например, 20% сверх MVP) и мониторинг выгорания команды.

Я видела, как продакты складывают сотни идей в бэклог без намерения когда-либо до них добраться, наотрез отказываются обсуждать предложения стейкхолдеров (идеи даже не попадают в бэклог) — и тут же говорят «да» очередной задаче, а потом плачут в туалете.

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

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

Зачем продуктовым командам нужен буфер мощности

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

Хорошие проектные менеджеры резервируют около 15–30% общей длительности или мощности проекта под незапланированную работу. Аналогично скрам-команда планирует на спринт только 70–80% своих мощностей, оставляя 20–30% на непредвиденные баги и изменения объёма.

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

Этот буфер позволяет иногда сказать «да» сверх плана. Да тому латте, который варится лишние пять минут во время переключения контекста между фокус-сессиями. Да внеплановому багу, который команда должна закрыть для топ-клиента в этом спринте. Да возможности развить опыт, который клиенты называют «хорошим», но который мог бы стать «отличным».

Когда стоит расширять объём

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

Рост удовлетворённости клиентов

В недавнем проекте мы выкатили 22% post-MVP требований уже на момент сдачи MVP — перенесли вперёд то, что иначе попало бы в следующие релизы.

В другом случае разговор с клиентом обнажил возможность развернуть решение на базе AI и снять рутинную нагрузку с его команды.

Делать это было необязательно, но в обоих случаях расширение объёма имело смысл — оно повышало удовлетворённость клиента.

Чёткие компромиссы в дорожной карте

Сказать «да» одной задаче должно по умолчанию означать «нет» какой-то другой.

Что вы готовы выменять, чтобы взять в работу новый пункт? Как использовать новый объём себе на пользу?

Ускорение разработки через AI-инструменты

Расползание объёма почти не проблема, если у вас неограниченные ресурсы — но это нереалистично.

Вместо того чтобы доводить команду до медленного кипения, используйте AI-инструменты для ускорения выхода на рынок: Claude Code, Figma Make, Gemini, NotebookLM, ChatGPT.

Подключите дизайнеров и продактов к vibe coding (создание прототипов через диалог с AI-инструментом) вместе с разработчиками — и наблюдайте, как растут мораль, увлечённость и пропускная способность команды.

Возможности-множители (force multipliers)

Ищите решения, которые закрывают целую пачку будущих требований за счёт более умной реализации. В таких случаях расширение объёма оправдано.

Например, дождаться API-фида данных вместо ручной синхронизации файлов. Но как общее правило: расширяйте объём только под то, что даёт минимум 10x отдачу.

Давление тайминга на рынке

Вы и конкурент можете запускаться с разницей в две недели, но первый на рынок снимает все сливки. Если выяснилось, что идёт гонка за релиз, имеет смысл добавить немного объёма (например, сжать сроки и увеличить нагрузку), чтобы добежать первым.

Опровергнутые предположения о пользователях

Если вы используете hypothesis-driven development (разработка через проверку гипотез о пользователях) и наблюдаемое поведение или фидбэк опровергают гипотезу, имеет смысл сдвинуть рамки под реальную потребность — а не упрямо продолжать строить не то.

Реальный пример контролируемого расширения объёма

Когда в прошлом году Figma выкатила бета-версию Figma Make, я бросилась подключать команду к раннему доступу. Этот новый инструмент на базе LLM позволял запросить у Figma не просто дизайн, а полноценный концепт: он выдавал прототипы для быстрого тестирования на клиентах и frontend-ready код, ускоряющий работу разработчиков.

До этого мы играли с другими инструментами вроде Firebase и Loveable, но именно Figma Make оказался самым ожидаемым релизом.

Figma анонсировала постепенную раскатку — я проверяла доступ по нескольку раз в день, и наконец — та-дам! Это было как получить волшебную палочку.

Буквально за ночь мы удвоили дизайн-мощность: vibe coding на ходу выдавал нам ассеты, пригодные для быстрых циклов обратной связи.

Единственная проблема? Инструмент оказался слишком хорош. Часть идей из vibe coding-сессий была настолько продвинутой, что с самого начала было понятно: мы не сможем реализовать даже половину видения.

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

Guardrails: ограничители для управления расширением объёма

Хорошее расползание остаётся хорошим только пока вы им не злоупотребляете. Вот несколько ограничителей, которые стоит держать под рукой, чтобы не стать «человеком, который всегда говорит да» за счёт остальных.

Формальный процесс change management

Документируйте каждое дополнение через лёгкий change request. Фиксируйте, что добавляется, как это служит стратегической цели и какие компромиссы вы принимаете. Это предотвращает бессознательный дрейф и создаёт ответственность за решения.

Берегите буфер мощности

Если вы уже выбрали 25% своего буфера, добавление нового объёма становится рискованным. Резерв нужен под реальные форс-мажоры, а не только под возможности. Защищайте буфер!

Тест «то же усилие — лучший результат»

Инструменты-ускорители вроде Claude Code и Figma Make должны позволять выпускать больше ценности без пропорционального роста усилий.

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

Лимит на расширение объёма

Установите максимальный порог (например, не более 20% сверх требований MVP).

Это создаёт принудительную функцию для приоритизации и предотвращает сценарий медленного кипения, когда «всего одна ещё штука» складывается в восприятие провала проекта и накопленное раздражение.

Мониторинг сигналов выгорания

Регулярные one-to-one с командой про нагрузку и моральное состояние — обязательное условие. Если расширенный объём выливается в шестидесятичасовые недели и сессии в туалете со слезами, это уже не контролируемое расширение — это неустойчивая перегрузка.

Хорошее расползание объёма должно заряжать команду, а не выматывать.

Заключение

Продакт-лидер видит сразу три картины: тренды рынка, свою дорожную карту и нужды клиентов. Это уникальный обзор — и именно из него рождаются неочевидные решения.

Самые сильные продуктовые решения — это когда один фикс закрывает сразу несколько проблем клиента, и при этом он не был запланирован изначально. Это и есть хорошее расползание объёма: буфер позволил его принять, guardrails — не сорвать дорожную карту.

С современными AI-инструментами расползание объёма больше не обязано означать сожжённую мощность разработки. Дайте команде правильные опоры — и каждый сможет активно участвовать в доставке. Соблюдайте guardrails — и сможете заменить цинизм оптимизмом: будете знать, что добавление фичи — это умное стратегическое решение, а не компульсивное «лишь бы согласиться».

Читайте также на tproger: пять книг для продакт-менеджера, когда привычные метрики мешают росту.

Оригинал статьи: How to rethink scope creep as strategic flexibility — Кимберли Шу, LogRocket Blog.

Я рассмотрел несколько вариантов редакторов документов — от Яндекс, Р7 и Google — сравнил их по ключевым параметрам, чтобы вы могли выбрать подходящий инструмент, исходя из своих задач и сценариев работы.

Вместо введения: контекст и герои обзора

Долгое время в Яндекс 360 для работы с документами использовались редакторы Р7 офис. Они никуда не делись и по-прежнему работают. Не так давно Яндекс начал развивать и собственные редакторы. Осенью 2025 года они вышли из стадии бета-тестирования и медленно стали обрастать функциями.

Поскольку познакомиться с ними довольно просто — достаточно переключить соответствующий ползунок в разделе «Документы» в Яндекс 360, — я это и сделал. Заодно стало интересно посмотреть, как новые редакторы Яндекса выглядят на фоне Р7 офис и Google Docs, которые для многих давно стали привычной точкой отсчёта.

Сразу оговорюсь: редакторы Яндекса сейчас — это средства работы с текстами и таблицами. Редактора презентаций пока нет: если открыть файл *.pptx, система по-прежнему запускает только Р7 офис.

Доступны новые редакторы пока только через браузер. О десктопных версиях Яндекс говорил ещё в январе, но на момент тестирования они мне не попадались. Совместная работа есть, одновременное редактирование тоже. Но главная особенность новых редакторов — встроенный ИИ. Сначала он появился только в текстовом редакторе, потом добрался и до табличного.

Если же говорить о Р7 офис, как о другом участнике этого сравнения, то его логика иная. Это скорее попытка дать пользователю более классический офисный опыт: с широким набором функций, несколькими вариантами использования и более серьёзной совместимостью с привычными офисными форматами (DOCX, XLSX, ODT и пр.). ИИ-ассистент также имеется в текстовом редакторе. Пользоваться Р7 можно в браузере, в виде приложений для Windows и Linux, на мобильных устройствах, а при желании и развернуть у себя на сервере. Функциональность здесь ощутимо шире, чем у новых редакторов Яндекса.

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

Простота, минимализм и всё, что из этого следует

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

И в этом, надо признать, есть своя логика. Далеко не всем нужны громоздкие редакторы уровня Word, Excel или тем более полноценного офисного пакета. Очень многим нужен именно лёгкий инструмент: быстро открыть документ, набрать текст, чуть-чуть его оформить, вставить таблицу или картинку, поделиться с коллегой. В эту модель Яндекс, похоже, и целится.

Но лёгкость — вещь приятная ровно до того момента, пока не начинаешь искать функции, к которым привык.

Например, меню «Файл» в новых редакторах Яндекса на момент тестирования выглядело очень скромно: фактически там доступны только «Скачать» и «Печать». Документ можно выгрузить в DOCX или XLSX, либо в PDF. И здесь особенно заметно, насколько по-разному устроены конкуренты.

В Р7 офисе список экспортируемых форматов ощутимо шире: можно сохранять в OpenDocument, RTF, EPUB, PDF, JPG и не только.

Google Docs, хотя и хранит документы в собственном формате, тоже позволяет скачать их в DOCX, XLSX, PDF, RTF, EPUB, а в некоторых случаях — и в Markdown.

Что умеют текстовые редакторы — и чего в них пока нет

С текстовым редактором Яндекса история примерно та же. Базовые инструменты форматирования есть: можно выбрать шрифт, выставить выравнивание, интервалы, отступы. Для многих сценариев этого хватит.

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

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

И в Google Docs:

То есть для обычного «написать текст и немного его причесать» яндексовский годится уже сейчас. А вот для сценариев, где текстовый документ начинает тянуть на что-то более сложное, ограничений пока многовато.

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

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

Есть и совсем бытовые детали, которые внезапно оказываются не такими уж бытовыми. Например, кавычки-ёлочки. В русскоязычной практике это не редкость, особенно если текст хоть сколько-то претендует на аккуратное оформление. Ввести их в редакторе Яндекса можно, но не самым очевидным способом — через Alt-коды. Для пользователя с полноразмерной клавиатурой это ещё терпимо, а вот на ноутбуке без цифрового блока удовольствие уже заметно ниже среднего. Впрочем, справедливости ради, в Google Docs с этим тоже не праздник.

Таблицы: базовые и сложные сценарии

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

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

Для проверки я открыл старый тестовый XLSX-файл, который когда-то специально собирал как пример таблицы с непростым форматированием. Так его демонстрирует Р7 офис, вполне корректно.

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

Яндексовский редактор отреагировал иначе: показал предупреждение о том, что сводные таблицы пока доступны только в режиме просмотра, и предложил обратиться к владельцу документа или открыть файл в старом редакторе. То есть фактически — в Р7 офис. И это, пожалуй, довольно честный момент.

После нажатия кнопки “Понятно” редактор визуализирует таблицу следующим образом:

Однако, как я упоминал раннее, в редакторах Яндекса сохранена возможность переключиться на редакторы Р7 офис. Для этого достаточно зайти в настройки Яндекс 360 и в строке «Перейти на новый редактор» сдвинуть бегунок влево, сделав его серым.

Тогда моя тестовая табличка откроется уже в редакторе Р7 офис в изначально задуманном виде.

Собственно, в этом и состоит важная разница между редакторами. Р7 офис хорош как инструмент для сложных корпоративных сценариев, но порой за это расплачивается тяжеловесностью. Яндексовский редактор делает ставку на простоту, современный интерфейс и скорость входа, но сложные документы регулярно выбивают его из колеи. Google Docs остаётся где-то посередине: с одной стороны, он веб-ориентированный и понятный, с другой — за годы разработки и эксплуатации он успел обрасти таким количеством функций и сценариев, что давно воспринимается как полноценный рабочий инструмент, и, своего рода, стандарт индустрии для облачных редакторов. Только купить и использовать его в России нельзя.

Немного спорта: кто и как ведёт себя на больших файлах

Пара слов о скорости работы. Для теста я взял файл с текстом романа «Война и мир» — 1918 страниц. Ничего особенно экзотического в этом документе не было: текст, таблицы, несколько чёрно-белых иллюстраций. Но объём, мягко говоря, не маленький.

Р7 офис открыл его меньше чем за минуту. Причём навигация по документу становилась доступна довольно быстро — примерно секунд через десять-двенадцать после открытия уже можно было начинать с ним работать, пока оставшаяся часть продолжала подгружаться.

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

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

Ещё один тест: как редакторы переживают чужую вёрстку

Чтобы не ограничиваться только «Войной и миром», я решил проверить и более прикладной сценарий: открыть готовый DOCX со сложным расположением элементов. Для этого взял типовой файл технического задания.

Результаты получились показательные. Лучше всего с отображением справился Google Docs: документ выглядел близко к тому, как ожидаешь после Word.

Р7 офис показал все элементы, но порядок местами поплыл: например, часть шапки на первой странице съехала относительно ожидаемой позиции.

Яндексовский текстовый редактор на первой странице отобразил уже заметно меньше.

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

И совсем простой табличный тест

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

Google Docs справился мгновенно. Единственный нюанс — для суммирования диапазон пришлось задать вручную или сначала выделить.

Р7 офис тоже с задачей справился, но работал заметно степеннее: некоторые действия занимали несколько секунд. Это не катастрофа, но ощущается.

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

В итоге считать пришлось в другом месте. Посчиталось — уже хорошо, но осадок, как говорится, остался.

Что по совместной работе?

В Р7 офис доступны режимы комментирования, чтения, редактирования, можно установить пароль и срок действия для внешней ссылки. И есть чат для участников совместного редактирования — чтобы написать коллегам сообщение, даже не нужно выходить из редактора. Такой возможности у редакторов Яндекса, как и у Google, нет.

Яндекс позволяет делиться файлами, редактировать их в реальном времени и настраивать права доступа. Пока роли ограничиваются только двумя вариантами — «только просмотр» и «редактирование». Если у вас есть Яндекс 360, доступны будут некоторые дополнительные настройки безопасности — можно установить пароль, срок действия ссылки и запретить скачивание.

А такие сценарии доступны в Google Docs, всего три и все по делу:

Выводы

У всех трёх решений оказались довольно разные роли.

Google Docs по-прежнему выглядит самым зрелым и предсказуемым веб-редактором из этой троицы. Это тот случай, когда сервис уже давно стал отраслевой нормой: не идеальной во всём, но очень понятной и привычной. Особенно если важна совместная работа, история изменений и в целом проверенный интерфейс.

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

Новые редакторы Яндекса выглядят как попытка пойти в другую сторону и предложить более понятный инструмент для повседневной работы. И в этом есть своя логика. Однако на текущий момент это всё ещё сырой продукт, который пригодится для самых базовых сценариев: простой текст, лёгкая таблица, быстрый доступ в браузере. Но как только речь заходит о сложном форматировании, тяжёлых файлах, сводных таблицах или о проверке орфографии с историей изменений, редакторы Яндекса начинают откровенно "спотыкаться". И пока одним из главных конкурентных преимуществ служит интеграция Алисы AI: для части пользователей она может оказаться полезнее, чем редкие офисные функции.

Поэтому ответ на вопрос «что выбрать» здесь не универсальный. Если важны сложные документы, форматы и более богатый офисный функционал — логичнее смотреть в сторону Р7. Если нужны ИИ-инструменты, простота и современный интерфейс — у Яндекса есть вполне понятный сценарий применения. Если нужен проверенный веб-стандарт совместной работы — редакторы от Google всё ещё остаются ориентиром, хотя, будучи российским пользователем, надеяться на безопасность данных или легально оплачивать их уже не получится.

Пулл-реквесты задумывались как инструмент для совместной работы над кодом. На практике они превратились в бюрократическую процедуру: гигантские диффы, комментарии в разных вкладках, коллапсированные «outdated»-ветки обсуждений. Bernard Kolobara считает, что проблема не в самой идее code review, а в инструментах — и предлагает конкретные решения.

• Comprehension debt (долг понимания) — главная проблема, которую должен решать code review, а не только ловля багов
• Стековые пулл-реквесты: разбиение изменений на мелкие самодостаточные коммиты, которые ревьюятся независимо
• Приоритет файлов: тесты и зависимости показываются первыми в диффе через .gitattributes
• Всё на одной странице: код и обсуждение вместе, без вкладок
• ИИ не убил code review — он обнажил хрупкость инструментов, которые не справляются с растущим объёмом кода

Comprehension debt: долг понимания кода

Addy Osmani описал comprehension debt как разрыв между объёмом кода в проекте и тем, сколько из этого кода команда реально понимает. Чем больше разрыв — тем медленнее работа. Проектировать систему, которую полностью понимаешь, проще, чем ту, которую «примерно знаешь». С появлением ИИ-агентов в рабочих процессах этот разрыв значительно вырос.

Paul Graham в эссе о великой работе пишет, что лучшие идеи приходят вне клавиатуры — на прогулке, в душе, перед сном. Но для этого «фонового процессинга» нужно, чтобы контекст проекта уже был в голове. Сначала нужна осознанная работа с кодом.

Code review — идеальный момент для сокращения этого разрыва. Каждый ревью — возможность узнать, как кодовая база развивается, каковы её границы и ограничения. Не обязательно проверять каждую строку дифа — достаточно понять ключевые части, чтобы обновить ментальную модель. Ловля багов — лишь одна часть ценности ревью.

Как сократить разрыв: конкретные решения

Стековые пулл-реквесты

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

Git заточен под append-only workflow. Вернуться в старый коммит и отредактировать его — мучительно. Даже если вы аккуратно структурировали историю, рано или поздно появляется серия коммитов «fix», «actual fix», «ok now really fix». Когда смотришь на отдельный коммит, не видишь полной картины — правки могут быть размазаны по нескольким коммитам дальше по истории.

Bernard и его коллега Luísa решают эту проблему с помощью Jujutsu — VCS, которая позволяет прыгнуть в любой коммит и отредактировать его на месте, а затем автоматически пропагирует изменения через всю историю. Это позволяет «вылепить» идеальную историю коммитов.

В Lubeno стековые PR детектятся автоматически. Каждый PR показывается как дифф относительно родительского PR — ревью и одобрение идут независимо. Автор не ждёт, пока предыдущий PR смёржат, и может продолжать работу.

Приоритет файлов в диффе

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

Lubeno использует кастомный атрибут priority в .gitattributes (это не стандартный атрибут Git, а расширение Lubeno):

Файлы с высоким приоритетом показываются первыми на странице PR. Простое решение, но оно гарантирует, что самые важные изменения вы увидите сразу.

Всё на одной странице

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

В Lubeno нет вкладок на странице PR. Код и обсуждение живут в одном месте.

Эволюция кода в рамках PR

PR — не статичная сущность. Это место для обсуждения и итераций. Знакомая ситуация: вы оставили комментарий, вернулись — и обнаружили несколько новых коммитов, а все ваши комментарии свёрнуты как «outdated». Непонятно, учтены ли ваши замечания, что изменилось с момента вашего последнего просмотра.

Lubeno отслеживает комментарии к коду и наложение interdiff (разницу между версиями файла в рамках PR): если код был изменён более поздним коммитом (или force push), разница видна прямо в контексте комментария. Не нужно переключаться между вкладками, чтобы понять, что произошло.

Будущее пулл-реквестов

Некоторые называют PR «реликтом прошлого» и призывают от них отказаться. Автор не согласен: процесс ревью кода сегодня ценнее, чем когда-либо. ИИ не убил code review — он обнажил хрупкость инструментов. Больше строк кода просто сделали их непригодными.

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

Выводы

Статья Bernard Kolobara — не абстрактные размышления, а описание конкретных решений, реализованных в Lubeno. Даже если вы не планируете переходить с GitHub — идеи стековых PR, приоритета файлов и unified-страницы ревью стоит примерить к своему workflow.

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

Долг понимания — это растущий разрыв между объёмом кода в системе и долей этого кода, которую живые люди действительно понимают. В отличие от технического долга, который заявляет о себе трением — медленными сборками, запутанными зависимостями, ощущением ужаса при касании «того самого» модуля — долг понимания порождает ложную уверенность. Кодовая база выглядит чистой. Тесты зелёные. Расплата приходит тихо, обычно в самый неподходящий момент.

Маргарет-Энн Стори описывает студенческую команду, которая наткнулась на стену на седьмой неделе: они больше не могли вносить простые изменения, не ломая что-нибудь неожиданное. Проблемой был не грязный код. Проблемой было то, что никто в команде не мог объяснить, почему были приняты те или иные проектные решения и как разные части системы должны работать вместе. Теория системы испарилась.

Недавнее исследование Anthropic подтверждает это количественно. В рандомизированном контролируемом эксперименте с 52 инженерами участники, использовавшие ИИ-ассистента, завершали задачу за то же время, что и контрольная группа, — но на последующем тесте на понимание кода набрали на 17% меньше баллов (50% против 67%). Наибольшее падение — в навыках отладки. Пассивное делегирование («просто сделай это») разрушает формирование навыков значительно сильнее, чем активное использование ИИ для вопросов и изучения компромиссов.

Ключевые выводы

- Долг понимания — это не технический долг. Технический долг виден; долг понимания порождает ложную уверенность.
- ИИ генерирует код быстрее, чем человек способен его проверить. Прежний фильтр качества стал узким местом пропускной способности.
- Тесты необходимы, но недостаточны: нельзя написать тест на поведение, о котором никто не подумал.
- Спецификации тоже не спасают: между спецификацией и работающим кодом лежат сотни неявных решений.
- Ни одна текущая метрика не отражает этот долг. Velocity, DORA, покрытие кода — всё зелёное, пока понимание тихо выгорает.
- Удешевление генерации кода не удешевляет понимание. Работа по пониманию — это и есть работа инженера.

Асимметрия скорости — ИИ генерирует быстрее, чем человек проверяет

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

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

ИИ-сгенерированный код ломает этот цикл обратной связи. Объём слишком велик. Результат синтаксически чистый, хорошо отформатированный, внешне корректный — именно те сигналы, которые исторически вызывали уверенность при мёрже. Но поверхностная корректность — не системная корректность. Кодовая база выглядит здоровой, а понимание тихо выгорает под ней.

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

Тесты — необходимы, но недостаточны

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

Это помогает. Но у этого подхода есть жёсткий потолок.

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

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

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

Данные это подтверждают. Разработчики, делегирующие ИИ генерацию кода, набирают менее 40% на тестах понимания. Разработчики, использующие ИИ для концептуальных вопросов — исследования компромиссов, выяснения «почему» — набирают выше 65%. Инструмент не разрушает понимание. Его разрушает то, как вы этот инструмент используете.

Спецификации — тоже не спасут

Популярное предложение: напишите подробную спецификацию на естественном языке. Включите её в PR. Ревьюьте спецификацию, а не код. Доверьтесь тому, что ИИ точно перевёл намерение в реализацию.

Это привлекательно ровно так же, как когда-то был привлекателен Waterfall. Строго определите проблему, затем исполните. Чистое разделение ответственности.

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

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

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

Учитесь у истории

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

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

Это некомфортное перераспределение, к которому вынуждает долг понимания.

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

Проблема измерения — метрики не видят этот долг

Долг понимания так опасен именно потому, что ничто в текущей системе измерений его не отражает.

Метрики скорости (velocity) выглядят безупречно. DORA-метрики держатся стабильно. Количество PR растёт. Покрытие кода тестами — зелёное.

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

Именно поэтому долг понимания коварнее технического долга. Технический долг — обычно осознанный компромисс: вы выбрали короткий путь, примерно знаете, где он лежит, можете запланировать расплату. Долг понимания накапливается невидимо, часто без осознанного решения кого-либо допустить его. Это совокупный результат сотен ревью, где код выглядел нормально, тесты проходили, а в очереди ждал следующий PR.

Организационное допущение «отревьюенный код = понятый код» больше не работает. Инженеры утверждали код, который они не до конца понимали, — и этот код теперь несёт неявное одобрение. Ответственность распределилась, а заметить это не успел никто.

Регуляторы придут быстрее, чем вы думаете

Каждая индустрия, которая двигалась слишком быстро, в итоге привлекала регулирование. Технологический сектор был необычно защищён от этой динамики — отчасти потому, что сбои в ПО часто обратимы, отчасти потому, что индустрия двигалась быстрее, чем регуляторы успевали реагировать.

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

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

Что на самом деле требует долг понимания

Правильный вопрос сейчас — не «как генерировать больше кода?», а «как понимать больше из того, что мы отгружаем?» — чтобы пользователи получали стабильно качественный продукт.

Этот сдвиг фокуса имеет практические следствия:

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

Удешевление генерации кода не удешевляет понимание. Работа по пониманию — это и есть работа инженера.

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

Вы заплатите за понимание рано или поздно. Проценты по этому долгу растут быстро.

Частые вопросы

Чем долг понимания отличается от технического долга?

Технический долг — обычно осознанный компромисс. Вы знаете, где лежит короткий путь, и можете запланировать рефакторинг. Долг понимания накапливается невидимо: код выглядит чистым, тесты зелёные, но никто в команде не может объяснить, почему система работает именно так. Расплата приходит внезапно — когда простое изменение ломает всё каскадом.

Значит ли это, что ИИ-инструменты для кодинга вредны?

Нет. Исследование Anthropic показало, что инструмент не разрушает понимание — его разрушает способ использования. Пассивное делегирование («сделай за меня») снижает понимание, а активное использование для концептуальных вопросов и исследования компромиссов — нет. Ключ в том, чтобы использовать ИИ как партнёра для мышления, а не как замену мышлению.

Как измерить долг понимания в команде?

Прямых метрик пока нет — в этом и проблема. Косвенные индикаторы: частота каскадных сбоев от «простых» изменений, время на onboarding новых разработчиков, способность членов команды объяснить архитектурные решения без обращения к коду. Если никто не может ответить «почему это сделано именно так» — долг уже высок.

Что делать прямо сейчас?

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

Выводы

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

Оригинал статьи: Comprehension Debt — the hidden cost of AI generated code (Addy Osmani, март 2026).

Инженер отправляет сообщение в Slack, уходит за кофе — и возвращается к готовому пулл-реквесту, который уже прошёл автотесты и ждёт ревью. Пять задач за то время, которое обычно уходит на две. Звучит как фантастика, но за этой продуктивностью стоит не столько модель, сколько инфраструктура, которую Stripe строил годами — задолго до эры LLM.

Разбираемся, как устроена система Minions, какие задачи она решает и чему из опыта Stripe могут научиться другие компании. Статья основана на публичных материалах ByteByteGo и Stripe Engineering Blog.

Ключевые выводы:
— Stripe мержит более 1300 PR в неделю, созданных полностью автономными ИИ-агентами
— Minions — это unattended-агенты: они не требуют наблюдения или пошагового одобрения
— Архитектура построена на «блюпринтах» — гибридах жёсткого пайплайна и агентных циклов
— Главный секрет успеха — не модель, а developer-инфраструктура: изолированные окружения, быстрые тесты и чёткие ограничения
— Если агент не справился за два цикла CI — задача возвращается человеку

Масштаб — цифры и факты

Stripe обрабатывает более триллиона долларов платежей в год. Кодовая база компании — сотни миллионов строк кода, преимущественно на Ruby с типизацией Sorbet. Это относительно редкий стек, с которым LLM практически не сталкивались при обучении.

На этом фоне цифры Minions выглядят особенно впечатляюще:

• 1300+ PR в неделю — полностью автоматические, без единой строки человеческого кода
• Типы задач — миграции кода, обновление зависимостей, исправления безопасности, рефакторинг
• Время запуска агента — менее 10 секунд от запроса до начала работы
• Параллельность — один инженер может запустить 5-6 агентов одновременно

Важно понимать: Stripe не считает каждый PR идеальным. Частично корректный пулл-реквест, который инженер доработает за 20 минут, — это уже серьёзный выигрыш. Система спроектирована с учётом этой реальности.

Архитектура агентов

Изолированные окружения — devbox-ы

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

Stripe уже имел всё это. Их «devbox-ы» — облачные машины, предзагруженные с полной кодовой базой, инструментами и сервисами. Они поднимаются за 10 секунд, потому что Stripe заранее провизионирует и прогревает пул машин — клонирует репозитории, прогревает кеши и запускает фоновые сервисы. Инженеры и раньше использовали по одному devbox-у на задачу, а один инженер мог держать полдюжины одновременно. Агенты просто встроились в этот паттерн.

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

Блюпринты — гибрид workflow и агента

Есть два классических подхода к оркестрации LLM-систем:

• Workflow — фиксированный граф шагов, где каждый шаг делает одну конкретную вещь, а последовательность предопределена
• Agent — цикл, в котором LLM сама решает, что делать дальше, на основе результатов предыдущих действий

Workflow предсказуемы, но негибки. Агенты гибки, но ненадёжны. Stripe построил нечто среднее — «блюпринты» (blueprints).

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

• Шаг «реализуй фичу» или «исправь ошибки CI» — полный агентный цикл с инструментами и свободой действий
• Шаг «запусти линтеры» — захардкожен, всегда выполняется одинаково
• Шаг «запуши ветку» — захардкожен, строго по шаблону PR компании

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

Контекст — как не утонуть в сотнях миллионов строк

У LLM ограниченное контекстное окно. Если загрузить все правила и конвенции глобально, контекст заполнится до того, как агент начнёт работать. Stripe использует глобальные правила «очень осторожно» — вместо этого они привязывают правила к конкретным директориям и паттернам файлов. Когда агент перемещается по файловой системе, он автоматически подхватывает только релевантные правила.

Для информации, которая не живёт в файловой системе, Stripe построил централизованный сервер Toolshed. Он хостит почти 500 инструментов через MCP (Model Context Protocol) — открытый стандарт, который даёт агентам единый способ вызывать внешние сервисы. Через MCP агенты получают доступ к внутренней документации, деталям тикетов, статусам билдов, результатам поиска по коду и многому другому.

Но больше инструментов — не значит лучше. Агенты работают лучше с тщательно подобранным подмножеством, релевантным их задаче. Stripe даёт Minions небольшой набор по умолчанию и позволяет инженерам добавлять дополнительные при необходимости.

Модели и обратная связь

Stripe не раскрывает конкретные модели, которые используют Minions, но архитектура сознательно абстрагирована от конкретной LLM. Ключевое значение имеет не модель, а инфраструктура обратной связи:

1. Локальный линтинг — запускается при каждом push за менее чем 5 секунд. Фоновый демон заранее вычисляет, какие правила линтинга применимы, и кеширует результаты
2. CI — выборочно запускает тесты из батареи в 3+ миллиона тестов. Автофиксы применяются автоматически для известных паттернов ошибок
3. Повторная попытка — если после автофикса ошибки остались, агент получает ещё один шанс исправить и запушить

Затем — стоп. Максимум два цикла CI. Если код не проходит после второго push-а, ветка возвращается инженеру. Это ограничение осознанное: LLM показывают убывающую отдачу при повторных попытках решить ту же проблему. Больше раундов — больше токенов и вычислений без пропорционального улучшения.

Какие задачи решают агенты

Minions лучше всего справляются с задачами, которые хорошо определены, повторяемы и поддаются автоматической проверке:

• Миграции кода — перевод со старых API на новые, обновление паттернов использования библиотек
• Обновление зависимостей — bump версий, адаптация кода к breaking changes
• Исправления безопасности — применение патчей по известным уязвимостям
• Рефакторинг — переименование, перемещение модулей, приведение к единому стилю
• Мелкие баг-фиксы — исправления, которые накапливаются в on-call очереди за ночь

Чего Minions не делают:

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

Это ключевое отличие от «attended» инструментов вроде Cursor или Claude Code, которые работают вместе с разработчиком. Инженеры Stripe используют и те, и другие — для разных типов задач.

Результаты и метрики

Stripe не публикует детальные внутренние метрики, но из публичных материалов и выступлений инженеров можно выделить ключевые результаты:

• 1300+ PR в неделю — объём, эквивалентный работе десятков инженеров
• Сдвиг от написания к ревью — инженеры не исчезли, но их роль изменилась: вместо написания кода они проверяют код, созданный агентами
• Частично корректные PR — даже неидеальные результаты экономят время, потому что доработка занимает 20 минут вместо нескольких часов с нуля
• Масштабирование без найма — рутинные задачи снимаются с инженеров, позволяя команде фокусироваться на сложной архитектурной работе

Четыре уровня системы, которые обеспечивают эти результаты:

1. Изолированные окружения — безопасные параллельные рабочие пространства
2. Гибридная оркестрация — детерминированные гарантии плюс агентная гибкость
3. Курированный контекст — правильная информация без перегрузки
4. Быстрая обратная связь с жёсткими лимитами на итерации

Чему учит опыт Stripe

Главный инсайт Stripe: инвестиции в продуктивность разработчиков, сделанные за годы до появления LLM, дали неожиданные дивиденды, когда агенты появились в рабочем процессе.

Уроки, которые можно вынести:

1. Начинайте не с выбора модели, а с инфраструктуры. Окружения разработчика, тестовая инфраструктура, пайплайны обратной связи — если они хороши, агенты получат от них выгоду. Если нет — никакая модель не спасёт
2. Разделяйте детерминированное и агентное. Линтинг, push, создание PR — это не задачи для LLM. Захардкодьте то, что можно захардкодить
3. Ставьте жёсткие ограничения. Максимум два цикла CI — один из самых важных дизайн-решений Stripe. Знать, когда остановиться, так же важно, как знать, с чего начать
4. Начинайте с рутины. Миграции, обновления зависимостей, патчи безопасности — это идеальные первые кандидаты для автономных агентов
5. Человеческое ревью никуда не уходит. Роль инженера смещается от написания кода к проверке кода. Это не замена людей, а усиление команды

Когда стоит задуматься о внедрении подобного подхода? Если у вас уже есть: надёжная CI/CD-инфраструктура, изолированные окружения для разработки и достаточно рутинных задач, которые поддаются автоматизации.

Часто задаваемые вопросы

Какую LLM используют Minions в Stripe?

Stripe не раскрывает конкретную модель. Архитектура Minions сознательно абстрагирована от конкретной LLM — ключевую роль играет инфраструктура (devbox-ы, блюпринты, MCP-инструменты), а не сама модель. Это позволяет менять или обновлять модель без переписывания всей системы.

Могут ли Minions заменить разработчиков?

Нет. Minions решают рутинные, хорошо определённые задачи — миграции, обновления зависимостей, патчи. Архитектурные решения, продуктовое проектирование и задачи с нетривиальной бизнес-логикой по-прежнему требуют человека. Роль инженера смещается от написания к ревью кода.

Можно ли повторить подход Stripe в небольшой компании?

Принципы масштабируемы: изолированные окружения, гибрид детерминированных и агентных шагов, курированный контекст, жёсткие лимиты на итерации. Но для полноценной реализации нужна зрелая CI/CD-инфраструктура и достаточный объём повторяемых задач. Начните с малого — автоматизируйте один тип рутинной задачи и расширяйте по мере роста доверия к системе.

Что такое MCP и зачем он нужен агентам?

Model Context Protocol (MCP) — это открытый стандарт, который даёт ИИ-агентам единообразный способ вызывать внешние сервисы. Stripe использует MCP для подключения почти 500 внутренних инструментов — от поиска по коду до статусов билдов. Благодаря MCP агенты получают доступ к нужной информации через стандартизированный интерфейс.

Выводы

Опыт Stripe показывает: будущее разработки — это не замена инженеров агентами, а построение инфраструктуры, в которой агенты становятся ещё одним типом участников инженерного процесса. 1300 PR в неделю без единой строчки человеческого кода — это результат не прорыва в ИИ, а многолетних инвестиций в developer experience.

Ключевой вопрос не «какую модель выбрать», а «готова ли наша инфраструктура к агентам». Изолированные окружения, быстрые тесты, чёткие ограничения, курированный контекст — всё это можно и нужно строить уже сейчас, вне зависимости от того, когда именно вы запустите первого агента.

Если тема ИИ-агентов в разработке вам интересна, рекомендуем изучить оригинальные статьи в Stripe Engineering Blog.

Он опубликовал 113 уроков, которые вынес из этого опыта. Мы отобрали самые ценные, сгруппировали по темам и адаптировали для русскоязычной аудитории. Каждый урок — практический: его можно взять и применить в своём проекте уже сегодня.

Ключевые выводы

— Кэширование — последняя мера. Сначала исправьте модель данных, индексы и N+1-запросы.
— E2E-тесты на happy path дают в 10 раз больше отдачи, чем юнит-тесты на отдельные методы.
— Доведите Sentry до inbox zero — это единственный самый мощный шаг для качества продукта.
— Не обвиняйте конкретного разработчика за баг в проде: это всегда каскад из 3+ ошибок системы.
— Деплой за 2 минуты вместо 28 — достижимо, и это меняет культуру принятия решений.

Про архитектуру и масштабирование

Используйте сервисные объекты вместо раздувания моделей

В фреймворках, где модели строятся вокруг существительных (Product, User, Auction), логика неизбежно скапливается в этих классах. Со временем каждый из них превращается в монстра на тысячи строк. Решение — выносить процессы в отдельные сервисные объекты: PlaceAuctionBidService, ProductBillingService. Суть — перестать мыслить существительными и начать мыслить глаголами.

Одна и та же вещь, реализованная дважды — провал технического лидерства

Если в кодовой базе есть два разных клиента к одному платёжному провайдеру, три файла с функциями для работы с датами или дублирующиеся UI-компоненты — это симптом отсутствия ответственного за архитектуру. Создавайте очевидные, легко находимые места для общего кода (common/datetime.py, common/geo.py) и отмечайте переиспользуемый код на ревью.

Полиморфные связи в БД — почти всегда ошибка

ORM-код для полиморфных отношений становится крайне запутанным, и вы теряете защиту через foreign key constraints. Проще добавить nullable FK для каждой связанной модели и написать абстракции на уровне запросов.

Дефолтные фильтры и сортировки в ORM — всегда ошибка

Скрытые дефолты вроде order_by('-id') или filter(is_deleted=False) становятся миной замедленного действия, когда в команде 20+ человек. Новый разработчик не знает про неявное поведение — и получает баг. А скрытый ORDER BY портит аналитические запросы, потому что ORM добавляет ключ сортировки в SELECT.

Вся инфраструктура — в коде

Когда Джек пришёл в MorphMarket, все 27 крон-задач были настроены вручную на продакшн-сервере. Большинство отсутствовали на staging. Перенос в код (а затем конфигурация AWS/Heroku/CloudFlare/Sentry через Terraform) сделал все окружения похожими друг на друга — и, что важно, сделал инфраструктуру доступной для чтения AI-агентам.

Про тестирование

E2E > интеграционные > юнит-тесты

Пользователям важно, чтобы система работала целиком. Один E2E-тест на happy path каждой ключевой фичи (регистрация, покупка, создание листинга) даёт на порядок больше уверенности, чем десятки юнит-тестов. Детали дорабатывайте интеграционными и юнит-тестами — они быстрее и проще в поддержке.

Автоматические тесты для шаблонных фич

В MorphMarket написали систему, которая автоматически тестирует около 300 админ-страниц: парсит имя страницы, находит фабрику, создаёт запись в БД и проверяет, что страница открывается. Тот же подход можно применить к любому CRUD-эндпоинту без выделенного теста.

Изолируйте тесты полностью

Хрупкость тестов убивает мотивацию команды. Основные ловушки:

• Всё, что связано со временем — замораживайте или мокайте
• Фиксируйте seed для всех источников случайности — в каждой библиотеке
• Запретите реальные HTTP-запросы в не-E2E тестах (используйте VCR-подобные библиотеки)
• Отдельный Redis для тестов с автоочисткой перед каждым тестом
• Тестовая среда не должна читать ни одной переменной из вашего .env

Мокайте только внешние объекты

Мок — полезный инструмент, но только для внешних зависимостей. Мокать внутренние методы тестируемого класса — антипаттерн. Если можно переписать тест без мока без потери скорости — так и сделайте.

CI должен проверять не только ошибки, но и раздражающие мелочи

В MorphMarket CI также ловит новые warning-и в тестах, рассинхронизацию SDK с бэкендом и забытые миграции в Django. Чем раньше замечена мелочь, тем дешевле её исправить.

Про отладку и мониторинг

Sentry до inbox zero — самый мощный шаг к качеству

Когда Джек пришёл в компанию, Sentry показывал 1 000 ошибок в час. После агрессивной фильтрации (игнор старых браузеров, расширений, пометка JavaScript-ошибок уникальным идентификатором) и починки реальных багов — меньше 1 ошибки в час. Результат: каждая новая ошибка стала событием, на которое команда реагирует немедленно.

Dead Man Switch — мониторьте то, что должно происходить

Исключения шумят и легко ловятся. А вот отсутствие события — нет. Если крон-система перестала работать или бэкапы БД не снимаются — вы узнаете об этом только через heartbeat-мониторы. Настройте их.

Username в каждой строке лога

По умолчанию в логах — только IP-адрес. Но IP ротируется, создаёт лишнее перенаправление при дебаге и не показывает картину при использовании нескольких устройств. Поместите текущий запрос в thread-local и добавьте username в каждую запись.

Трипвайр-алерты на 20 самых важных эндпоинтов

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

Громко падайте при ошибках

Не глушите исключения except: pass. Паттерн от Джека: крашиться локально, мягко отказывать в проде — но всегда отправлять ошибку в Sentry/логи. Чем раньше заметили — тем меньше ущерб.

Про работу в команде

Не обвиняйте одного человека за баг в проде

Любой инцидент — это каскад минимум трёх провалов: автор не заметил, ревьюер пропустил, QA не покрыло, тесты не проверили, архитектура допустила класс ошибки. Обвинение одного человека мешает команде видеть системные причины.

Все разработчики должны быть немного фулстек

В MorphMarket убрали строгое деление на фронтенд/бэкенд/ops. Переобучение заняло год, но окупилось: фронтендер добавляет поле в БД сам, а не ждёт бэкендера — это сокращает время доставки фич.

Пятницы технического долга

Разумный компромисс между CEO, который хочет фичи, и инженерами, которым нужна чистота кода: с понедельника по четверг приоритеты задаёт продукт, а по пятницам — CTO. Бонус: инженеры отдыхают на глубоких задачах перед выходными.

Запретите длинные PR

В MorphMarket был период, когда PR висели по 3 месяца и накапливали тысячи изменений. Их невозможно ревьюить, они конфликтуют с master и создают огромный деплой-риск. Новое правило: мерж в master каждые 1–2 дня, максимум — раз в неделю. Побочный эффект: старшие разработчики дают фидбэк раньше, и драматические переписывания случаются реже.

Поощряйте общение в удалённых командах

Джек начал с ежедневных постов о прогрессе, потом стал публично задавать вопросы (даже на которые знал ответ), делиться изменениями в коде и просить мнения. Это постепенно снизило барьер и сделало общение нормой, а не исключением.

Про производительность

N+1-запросы — враг номер один в ORM

Проблема проявляется на крупных эндпоинтах, которые постепенно расширяют разные авторы: новые фильтры и параметры создают спорадические N+1, которые возникают только при определённом сочетании фильтров и объёме данных. Настройте APM (например, New Relic) для автоматического обнаружения N+1 и обучите команду ловить их на ревью.

Кэширование — последняя мера

Код кэширования чудовищно сложен в поддержке. Сначала исправьте модель данных, допишите индексы, уберите N+1, оптимизируйте алгоритмы. И только после этого — кэш. Джек рассказывает о случаях, когда наивный кэш работал на малых объёмах, но убивал Redis (он однопоточный!) при росте данных на два порядка.

Таймауты на всех уровнях — иммунная система сервиса

Веб-запрос должен завершиться за 25 секунд — иначе убивается. Да, для длинных задач придётся использовать фоновые задачи, но без таймаутов одна тормозящая внешняя API может съесть все потоки сервера и уронить всё.

Выгружайте работу в фоновые задачи

Отправка email, push-уведомления, обработка вебхуков от платёжных систем — всё это должно уходить в очередь. Веб-процесс обязан оставаться быстрым.

ORDER BY id вместо ORDER BY created

Если поле created неизменяемо и совпадает по порядку с id — сортируйте по id. Индекс на id уже есть бесплатно в каждой таблице.

Удаляйте ненужные данные

В MorphMarket некоторые таблицы копили 10 лет данных — логи IP-адресов, записи push-уведомлений, сообщения девятилетней давности. Скрипт очистки делает эти таблицы компактнее и быстрее.

Про безопасность и надёжность

Начните с модели угроз: что может получить атакующий?

Для MorphMarket основные вектора: захват аккаунтов (фикс — обязательный 2FA), спам-фишинг (капча на регистрации + фильтры сообщений), DDoS (Cloudflare + rate limit на nginx + кэш ключевых эндпоинтов). Универсального подхода нет — каждый сервис должен понимать свою специфику.

CHECK-ограничения в БД — лучше предотвратить, чем чинить

Раньше в MorphMarket крон-задача раз в сутки проверяла целостность данных и слала алерты. Всё заменили на CHECK constraints на уровне БД — некоторые проверяют до 16 операций над разными колонками. Невалидные данные просто не могут быть записаны.

Вебхуки — рассадник race conditions

Действие в коде может вызвать вебхук, который прилетит быстрее, чем данные запишутся в БД. Получатель вебхука прочитает устаревшее состояние и может затереть свежие данные. Решение: откладывайте действия, вызывающие вебхуки, до on_commit в БД.

Логируйте намерение перед побочным эффектом — особенно для платежей

Перед списанием с карты или возвратом пишите в лог: "bill user XYZ $100 for Y". Простой Write-Ahead Log спасал MorphMarket в нескольких инцидентах.

Про деплой

Деплой должен быть быстрым — действительно быстрым

MorphMarket сократил деплой с 28 минут до 2. Как: разделили фронтенд и бэкенд, распараллелили, перешли на Rust-based компиляцию JS, вынесли сборку на мощные машины (MacBook M-series вместо commodity Heroku), убрали из слага всё ненужное, почистили старые ассеты из S3.

Smoke-тест после каждого деплоя в прод

Автоматическая проверка ключевых страниц через Playwright после каждого деплоя. Если последние 150 деплоев были скучными — соблазн перестать проверять вручную огромен. Автоматический smoke-тест не устаёт и не теряет бдительность.

Не деплойте ничего рискованного в пятницу

Баг может проявиться вечером или в субботу, когда никого нет. Мелкие хотфиксы и изменения в админке — можно. Всё остальное — до четверга.

Плейбук для инцидентов при деплое

Короткие инструкции: как убить залипшие соединения к БД, точечно почистить кэш (без flush, который разлогинит всех), форсировать обновление ассетов. Обученная команда сокращает даунтайм в разы.

Про карьерный рост — от тимлида до CTO

Научитесь говорить о производительности сотрудников

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

Документ ожиданий от сотрудника

Если написать "мы ценим, когда вы решаете проблемы в #bug-discussion до того, как они дойдут до CTO", люди действительно начнут так делать. Мотивированный сотрудник хочет ясности. Он не может прочитать ваши мысли.

Одно крупное изменение за раз

Внедряете E2E-тесты? Доведите до стабильности, прежде чем браться за линтеры. Если система сделана плохо — команда не будет ей доверять и не будет использовать. Плюс есть предел того, сколько изменений люди могут усвоить одновременно.

CLI-инструменты + AI = максимальный рычаг

AI отлично работает с текстом. CLI-инструменты тоже. Дайте AI доступ к продакшн-логам, отчётам об ошибках, read-only реплике БД, CI-результатам и REPL — и получите огромный множитель продуктивности. Джек называет это "наблюдаемость через CLI — ваш главный усилитель для AI".

FAQ

Почему монолит, а не микросервисы?

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

С чего начать, если в проекте уже бардак?

С Sentry до inbox zero и таймаутов на веб-запросы. Первое даёт видимость реальных проблем, второе предотвращает каскадные отказы. Дальше — по статье: N+1, изоляция тестов, сервисные объекты.

Насколько эти уроки применимы за пределами Django?

Джек 17 лет работал с Rails, Laravel, Express и другими фреймворками — и подчёркивает, что большинство уроков переносимы. N+1, дефолтные сортировки, race conditions в вебхуках, инфраструктура как код — всё это не привязано к конкретному стеку.

Правда ли, что E2E-тесты лучше юнит-тестов?

Не лучше, а дают больше отдачи на первом этапе. Один E2E-тест на happy path покрывает весь стек. Юнит-тесты нужны для деталей и граничных случаев, но начинать покрытие лучше сверху вниз.

Выводы

113 уроков Джека Кинселлы — это не теория из книг, а выжимка из 7 лет ежедневной работы над монолитом, который обслуживает реальных пользователей. Главные принципы:

• Предотвращайте, а не чините — CHECK constraints, таймауты, линтеры
• Делайте невидимое видимым — логи, мониторинг, Sentry до inbox zero
• Инвестируйте в скорость обратной связи — быстрый деплой, быстрый CI, короткие PR
• Доверяйте людям и системе, а не контролю — fullstack-навыки, плейбуки, документ ожиданий

Оригинальная статья: Scaling a Monolith to 1M LOC: 113 Pragmatic Lessons from Tech Lead to CTO (Semicolon & Sons, Jack Kinsella).

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

В своём докладе на QCon San Francisco в марте 2026 года Форсгрен представила концепцию "AI Productivity Paradox" — парадокса ИИ-продуктивности. Суть проста: если узкое место было не в написании кода, то ускорение написания кода ничего не даст. А если и даст — то лишь создаст ещё большее давление на те части процесса, которые и без того задыхались.

ИИ-ассистенты для программирования — это инструменты, которые используют большие языковые модели для автодополнения кода, генерации функций по описанию на естественном языке, рефакторинга и объяснения кода. Самые известные — GitHub Copilot, Cursor, Codeium и Claude Code. Их общее обещание — кратный рост продуктивности разработчиков. По данным маркетинговых материалов, разработчики пишут код "на 55% быстрее" или "в 2 раза продуктивнее". Но что именно считается продуктивностью?

Ключевые выводы

— ИИ-ассистенты ускоряют написание кода, но не ускоряют доставку программного обеспечения — потому что написание кода занимает лишь малую часть от времени полного цикла разработки
— Настоящие узкие места — CI/CD-пайплайны, код-ревью, ручные согласования, тестирование и деплой — не затрагиваются ИИ-ассистентами
— По метрикам DORA, высокопроизводительные команды деплоят несколько раз в день с lead time менее суток — и это результат системной работы с процессами, а не с инструментами генерации кода
— Фреймворк DevEx (feedback loops, flow state, cognitive load) помогает найти настоящие точки трения
— Вместо покупки нового ИИ-инструмента стоит провести аудит процесса доставки: где теряется время, почему, и как это устранить

Парадокс ИИ-продуктивности

"Мы можем генерировать код за минуты, за секунды, — говорит Форсгрен. — Люди из любых подразделений могут "вайб-кодить" приложение и запушить его. Но деплой по-прежнему занимает дни. Я написала тут "дни" — это я была оптимисткой. Обычно это месяцы".

Парадокс в том, что ИИ не просто не решает проблему доставки — он делает её более заметной и болезненной. Когда код генерируется быстрее, очереди на код-ревью растут. CI-пайплайны захлёбываются. Тестовые наборы не справляются с нагрузкой. Форсгрен формулирует это так: "ИИ усиливает те же проблемы, которые существовали и раньше. Только теперь — быстрее".

Она приводит два показательных примера. В 2012 году в Knight Capital инженер выполнил рутинный деплой. Скрипт развёртывания реактивировал старый feature flag. Деплой был ручным. Автоматических тестов не было. За 45 минут компания потеряла 460 миллионов долларов. А в начале 2026 года разработчик по имени Джейсон использовал ИИ-ассистент Replit для работы с базой данных. Он явно указал: "никаких изменений в live-данных". Установил code freeze. Результат? "Новые инструменты — те же старые проблемы. Только теперь быстрее".

Почему код — не узкое место

Форсгрен разделяет процесс разработки на "внутренний цикл" (inner loop) и "внешний цикл" (outer loop). Внутренний цикл — это то, что происходит на машине разработчика: написание кода, локальная отладка, запуск тестов. Внешний цикл — всё остальное: CI/CD-пайплайны, код-ревью, тестирование, согласования, деплой.

ИИ-инструменты ускоряют внутренний цикл. Но внешний цикл — где на самом деле теряется время — они не затрагивают.

"Написание кода больше не является узким местом, — подчёркивает Форсгрен. — Мы можем генерировать сколько угодно кода. Но это делает остальные точки трения ещё дороже и заставляет их торчать ещё сильнее. Справляются ли наши тестовые наборы с такой нагрузкой? Справляются ли наши CI-пайплайны? Могу ли я ревьюить достаточно пулл-реквестов для всего того шлака, который валится в систему? Не всегда".

Вот из чего складывается "невидимое" время доставки, которое ИИ не трогает:

• Код-ревью — пулл-реквесты висят днями, потому что назначены не тому человеку, застряли в очереди или ревьюер в отпуске
• CI/CD-пайплайны — сборка падает, flaky-тесты, зависимости между сервисами
• Ручные согласования — деплой требует координации нескольких команд, инструментов, групповых решений о рисках
• Тестирование — автоматических тестов недостаточно, а ручное тестирование не масштабируется
• Онбординг — новый сотрудник на третьей неделе всё ещё ждёт доступ к базе данных
• "Не моя зона ответственности" — задачи буксуют на стыках между командами, процессами и системами

Что говорят данные

DORA (DevOps Research and Assessment) — это фреймворк из четырёх метрик, который Форсгрен разработала для измерения эффективности доставки ПО. Две метрики отвечают за скорость, две — за стабильность:

• Deployment frequency — как часто команда деплоит в продакшен
• Lead time for changes — сколько времени проходит от коммита до запуска в продакшене
• Change failure rate — какой процент изменений требует отката или вмешательства
• Mean time to restore (MTTR) — как быстро команда восстанавливает сервис после сбоя

У высокопроизводительных команд показатели выглядят так: деплой несколько раз в день (или по потребности бизнеса, а не из-за технических ограничений), lead time менее суток, change failure rate около 5%, восстановление после сбоя — менее часа.

"Эти команды не просто везучие, — говорит Форсгрен. — Они системно устранили трение". И она отмечает важный нюанс: это работает в компаниях любого размера и любой отрасли. Крупные компании говорят: "Это только для стартапов — у них нет нашего регулирования". Стартапы говорят: "Это только для крупных — у них ресурсы". Данные показывают, что и те, и другие неправы.

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

Отдельно Форсгрен обращает внимание на метрику "строки кода" (lines of code): "Это всегда была бесполезная метрика. ИИ наконец-то сделал это очевидным для всех, потому что теперь кода генерируется слишком много. Он чрезмерно многословный, полон избыточных комментариев. Иногда лучшее, что можно сделать — это удалить код".

Где реально теряется время

Форсгрен приводит конкретные цифры стоимости трения. По данным McKinsey, 40% бюджетов на разработку уходят на устранимый "rework" — переделки, которых можно было избежать. Другое исследование показало, что разработчики ощущают свою продуктивность на уровне 68,5% — а недостающие 31,5% обходятся мировой экономике в 300 миллиардов долларов потерянного ВВП. Ещё одна оценка: 1,52 триллиона долларов теряется ежегодно из-за технического долга.

Форсгрен предлагает простую "расчётку на салфетке": 20 разработчиков, каждый теряет по 30 минут в день на одну точку трения. Это 10 часов в день, 2600 часов в год. При стоимости 100 долларов в час — 260 000 долларов в год. "Мы уже тратим это время, — говорит она. — Просто тратим его на борьбу с трением, а не на его устранение".

Типичные точки потери времени, которые ИИ-инструменты не затрагивают:

1. Медленная сборка — двухчасовой билд означает двухчасовое ожидание обратной связи. Разработчик переключает контекст, начинает параллельную задачу, теряет фокус
2. Процесс код-ревью — отсутствие чётких владельцев, ручное назначение, неравномерная нагрузка между ревьюерами
3. Ручные деплои — координация между командами, согласование рисков, ручные чек-листы
4. Flaky-тесты — нестабильные тесты подрывают доверие к CI-пайплайну и замедляют обратную связь
5. Процессные задержки — согласование с юристами, безопасниками, product-менеджерами, которое "всегда занимает столько времени"

Фреймворк DevEx — как найти настоящие проблемы

Вместо абстрактной "продуктивности" Форсгрен предлагает работать с Developer Experience (DevEx) — опытом разработчика. Фреймворк DevEx состоит из трёх измерений:

• Feedback loops (петли обратной связи) — сколько времени проходит от действия до результата? Сколько ждать, пока сборка завершится? Пока ревьюер ответит? Пока CI/CD-пайплайн отработает?
• Flow state (состояние потока) — может ли разработчик сосредоточиться на сложных задачах? Или его постоянно отвлекают переключения контекста, совещания, ожидание ответов?
• Cognitive load (когнитивная нагрузка) — сколько ментальной ёмкости уходит на "обслуживание" процесса? Исследования Глории Марк показывают, что максимум глубокой работы в день — около 4 часов. На что разработчик тратит эти 4 часа?

Эти три измерения взаимосвязаны. Быстрая обратная связь сохраняет flow state и снижает когнитивную нагрузку. Низкая когнитивная нагрузка позволяет сосредоточиться и принимать решения быстрее. Защищённый flow state ускоряет обучение и накапливает результаты со временем.

ИИ меняет динамику flow state (состояния потока), отмечает Форсгрен: "Раньше мы могли заблокировать часы для глубокой работы над кодом. Теперь мы не просто пишем код — мы промптим, тут же получаем обратную связь, принимаем код, ревьюим, переписываем. Это как Stack Overflow на стероидах".

Как начать: 7 шагов

Форсгрен и Аби Нода (CEO компании DX) выделили семь шагов, которые проходят сотни компаний при улучшении DevEx:

1. Поговорите с людьми — прежде чем собирать метрики, просто спросите разработчиков: "Что вас бесит каждый день?"
2. Начните с малого — выберите одну видимую, достижимую проблему, которую можно решить за недели, а не за кварталы
3. Соберите данные — системная телеметрия, опросы, метрики результатов
4. Приоритизируйте через RICE — Reach (охват) x Impact (влияние) x Confidence (уверенность) / Effort (усилия)
5. Продайте стратегию — переведите технические проблемы на язык долларов и бизнес-результатов
6. Внедряйте изменения — от локальных экспериментов в одной команде до масштабирования на всю организацию
7. Оцените и покажите ценность — документируйте результаты и делитесь ими

Форсгрен подчёркивает: начинать можно с любого шага в зависимости от зрелости организации. Но на любом этапе стоит "просто поговорить с несколькими людьми" — это самый быстрый и дешёвый способ получить достоверные данные.

RICE: как приоритизировать улучшения

Форсгрен рекомендует фреймворк RICE для выбора, какие проблемы решать первыми:

• Reach — сколько людей затронет улучшение?
• Impact — насколько сильно оно улучшит их работу?
• Confidence — насколько мы уверены, что это выполнимо?
• Effort — сколько усилий потребуется? (чем меньше, тем лучше)

Пример из доклада: три кандидата на улучшение — автоматизация flaky-тестов (высокий охват, высокое влияние, но огромные усилия), оптимизация процесса код-ревью (высокий охват, высокое влияние, низкие усилия) и мониторинговые дашборды (средний охват, средние усилия). Выбор очевиден: начать с код-ревью — "широкое влияние, высокая уверенность, быстрые результаты, не слишком много усилий".

FAQ

ИИ-ассистенты для кода совсем бесполезны?

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

Какие метрики использовать вместо "строк кода"?

Форсгрен рекомендует фреймворк SPACE: Satisfaction (удовлетворённость инструментами и процессами), Performance (качество результатов: pass rate тестов, частота сбоев), Activity (количественные метрики: PR, деплои — но не строки кода), Communication and Collaboration (взаимодействие: ревью, API-вызовы, совещания), Efficiency and Flow (время от действия до результата). Дополнительно — четыре метрики DORA для end-to-end доставки.

Как убедить руководство инвестировать в DevEx, а не в новые ИИ-инструменты?

Форсгрен приводит три стратегии. Первая — видимость и подотчётность: пример Дэйва Андерсона из Amazon, который создал ежемесячный отчёт для топ-менеджмента с рейтингом команд по ошибкам. "Через неделю директора бежали к нему в офис, чтобы убрать свою команду из списка". Вторая — простые данные с чёткими действиями: пример LinkedIn, где "Developer Insights Hub" не просто показывал метрики, а позволял детализацию до конкретной причины проблемы. Третья — перевод трения в доллары: пример Block, где посчитали стоимость каждой точки трения и сэкономили миллионы за 12 месяцев.

Что делать прямо сейчас — одно конкретное действие?

Для рядового разработчика — записывать в течение недели все моменты, когда теряется 30+ минут на "ерунду, которой не должно быть". Для тимлида — провести 30-минутную ретроспективу: "Что на этой неделе замедлило нас, но не было собственно работой?". Для руководителя — поговорить минимум с тремя людьми и посчитать стоимость трения "на салфетке".

Выводы

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

Организации, которые выигрывают в эпоху ИИ, не просто выдали всем Copilot или Cursor. Они системно устраняют трение, чтобы разработчики могли доставить код до клиента, провести эксперимент, получить обратную связь. "Все крупные компании, с которыми я работаю, — говорит Форсгрен, — сейчас активно ищут способы убрать это трение".

Вместо того чтобы покупать очередной ИИ-инструмент, стоит задать себе три вопроса: Что на самом деле замедляет доставку? Где разработчики теряют время на борьбу с процессом, а не на решение задач? И какое самое маленькое изменение может убрать самую большую точку трения?

Источник: From Friction to Flow: How Great DevEx Makes Everything Awesome — доклад Николь Форсгрен на QCon San Francisco, март 2026.

Если вы используете Nix, присмотритесь к Garnix — он анализирует ваш flake, определяет, что нужно собрать, и делает это. Никакого YAML. Лучший CI-конфиг — это отсутствие CI-конфига. Но эта статья не для вас. Эта статья — для всех остальных.

Часть I: Нисхождение

Просмотрщик логов, или Куда уходит ваш день

Билд упал. Красный крестик. Вы нажимаете на него и попадаете... нет, не в логи. Вы попадаете на страницу Checks Summary. Оттуда — в Workflow Runs. Оттуда — в Jobs. Каждый шаг свёрнут. Каждая страница — это новый спиннер. Три-четыре клика, чтобы добраться до собственно ошибки. Это не отладка — это квест.

Просмотрщик логов, надо отдать ему должное, стабильно роняет браузер. Не один раз, не случайно — воспроизводимо, надёжно. Откройте лог длинного билда, попробуйте поискать текст — Chrome ляжет. Это не баг, это фича: система предлагает вам отдохнуть от мониторов.

На длинных логах скроллбар становится декоративным. Он есть, он выглядит как скроллбар, но прокрутить до конца вы не сможете. Приходится скачивать raw-логи и открывать в текстовом редакторе, как будто на дворе 2003 год и вы только что поставили Gentoo.

Кнопка «Назад» — это рулетка. Вы ожидаете вернуться на PR, но попадаете на случайную страницу GitHub Actions, которую видите впервые в жизни.

А теперь — отладка. Вы пушите коммит, ждёте, смотрите логи. Что-то падает. Добавляете run: env. Пушите снова. Ждёте. Двадцатиминутный цикл обратной связи ради однострочного изменения. Повторяете четырнадцать раз. Ваш вечер закончился.

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

Ловушка YAML

Любая CI-система рано или поздно сводится к «куче YAML-файлов». Но YAML в GitHub Actions — это нечто особенное. Свой язык выражений, своя объектная модель контекста, свои правила интерполяции строк. Это уже не конфигурация — это программирование. Только без отладчика, без типов и без чувства собственного достоинства.

Синтаксис ${{ }} — это танец. Неправильно поставили кавычку? Ждите четыре минуты, пока раннер запустится, чтобы узнать, что ваша строка была молча проглочена. Этот язык выражений «рос в темноте, без присмотра» — слишком сложный для конфига, слишком ограниченный для настоящего языка программирования.

«А как же маркетплейс!»

GitHub Actions Marketplace — это npm для CI. Комьюнити-экшены разного качества: shell-скрипты с Dockerfile и мечтой.

uses: some-stranger/cool-action@v2 — вы только что дали незнакомцу доступ к вашему репозиторию, секретам и среде сборки. Можно, конечно, пригвоздить версию к SHA. Никто этого не делает.

Энергетика ночного рынка: каждый лоток обещает решить вашу проблему, а некоторые продавцы преследуют совсем другие цели.

Вы не владеете своими вычислениями

Вы арендуете раннеры у Microsoft — медленные, ограниченные в ресурсах, не поддающиеся настройке. Это породило целую индустрию стартапов: Namespace, Blacksmith, Actuated, Runs-on, BuildJet — компании, которые существуют исключительно потому, что штатные раннеры GitHub Actions непригодны для продакшена.

Self-hosted раннеры решают проблему вычислений, но вы по-прежнему пишете YAML для GitHub Actions — это как поставить новый двигатель в машину, которая загорается каждый раз, когда вы включаете радио.

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

Мелочи, которые накапливаются

• actions/cache — ключи кеша непонятные, промахи молчаливые, вытеснение непрозрачное.
• Reusable workflows нельзя вкладывать друг в друга, и у них нет чистого доступа к контексту вызывающего воркфлоу.
• GITHUB_TOKEN permissions — лабиринт. permissions: write-all — это кувалда, а fine-grained permissions — это пазл на 500 деталей без картинки на коробке.
• Concurrency controls — топорные. Отменить текущий запуск? Одна строка. Что-нибудь более тонкое? Нет.
• Секреты нельзя использовать в условиях if: — обоснованное ограничение безопасности, но с точки зрения DX — катастрофа.

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

«Просто напиши баш-скрипты»

Искушение велико: просто засунуть всё в run: и написать большой shell-скрипт.

И это работает! А потом скрипт растёт. Условия, функции, парсинг аргументов, второй скрипт, обработка ошибок, логирование, «ну и чуть-чуть параллелизма».

Проходит три месяца — и вот у вас 800 строк баша, которые переизобретают параллельное выполнение задач при помощи wait и PID-файлов.

Race condition в cleanup-trap только на ядре Linux 6.x, вы в отпуске, телефон звонит.

Вы не избежали CI. Вы построили CI-систему. Просто она хуже.

Bash хорош как клей. Но он не система сборки. Не тестовый фреймворк. Не оркестратор. Каждый раз, когда кто-то говорит «просто напиши баш-скрипт», где-то в мире рождается ещё один 800-строчный ci.sh.

Часть II: Выход

Просмотрщик логов, который не убивает браузер

У Buildkite просмотрщик логов — это веб-страница, которая показывает логи и не падает. Звучит как минимальное требование к продукту, но после GitHub Actions это ощущается как роскошь.

• ANSI-цвета работают — вывод тестового фреймворка приходит в первозданном виде, а не в виде кашицы из escape-последовательностей.
• Аннотации — богатый Markdown-вывод прямо на странице билда.
• Отладка: агент крутится на вашем железе, вы можете зайти на машину по SSH. Как нормальный человек, а не как археолог, расшифровывающий логи по слоям.

YAML, который знает своё место

YAML в Buildkite описывает пайплайн: шаги, команды, плагины. Это структура данных, а не язык программирования. Когда нужна логика — пишите скрипт на нормальном языке. Запускайте локально. Как человек, у которого есть достоинство.

Оркестрацию — в конфиг, логику — в код. Buildkite уважает эту границу.

Вы владеете своими вычислениями

Агент Buildkite — это один бинарник на ваших машинах. Ваш облачный провайдер, ваш дата-центр, ваше странное кастомное железо.

Никакой побочной индустрии «Buildkite, только быстрее» — просто поставьте машины помощнее.

GitHub Actions выдаст вам стандартную Ubuntu-виртуалку с эмоциональной теплотой зала ожидания в районной поликлинике.

Динамические пайплайны

Шаги пайплайна — это данные. Вы можете генерировать их динамически в рантайме.

Скрипт смотрит на монорепо, определяет, что изменилось, и загружает именно те шаги, которые нужны. Никаких захардкоженных матриц, никаких спагетти из if: contains(...).

По поводу плагинов

Честно говоря, структурно плагины Buildkite похожи на маркетплейс GitHub Actions.

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

Маленькие радости

В Buildkite можно поставить кастомные эмодзи рядом с шагами пайплайна — :parrot:, :docker:, что угодно.

Объективно — бесполезная мелочь. Но она рассказывает вам о людях, которые создали этот продукт.

GitHub Actions — это продукт, спроектированный комитетом, который ни разу не задал вопрос: «А пользователю от этого радостно?»

Заключение

GitHub Actions победил не потому, что он хорош, а потому что он стоит по умолчанию. Internet Explorer от мира CI.

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

Но если у вас продакшен-системы, монорепо, билды дольше пяти минут — присмотритесь к Buildkite.

GitHub Actions — это самая простая CI-система для старта. Buildkite — это лучшая CI-система для жизни.

Если ваш CI воюет с вами больше, чем помогает — проблема не в вас. Проблема в инструменте.

Это литературный перевод и адаптация статьи Иэна Данкана (Ian K. Duncan) GitHub Actions is Killing Your Team. Мнение автора оригинала может не совпадать с мнением редакции.

Почему штат стал дорогим

Реальная стоимость штатного разработчика — это зарплата, увеличенная в 2–3 раза. Зависит от компании и включает в себя налоги, страховые взносы, ДМС, HR, офис и административную нагрузку. Backend-разработчик с зарплатой 220 000 ₽ обходится компании примерно в 565 000 ₽ в месяц. Заморозка проекта на два месяца — это 1,1 млн рублей на «пустых» зарплатах, ошибка найма — ещё 3–6 зарплатных циклов на повторный поиск.

В последние пару лет выросла фискальная нагрузка: часть льготных тарифов страховых взносов для МСБ отменяется, ставка поднимается с 15% до 30% в части зарплат выше МРОТ. Каждый следующий разработчик в штате дорожает по регуляторным причинам.

Отдельный вопрос — скорость. Закрытие вакансии middle-разработчика занимает в среднем 58 дней, senior — 73 дня (с учетом отработки на предыдущем месте). При этом каждый третий кандидат отказывается от оффера на этапе согласования: нашел предложение лучше, не сошлись по зарплате или формату работы. Через внешнего партнёра готовый специалист появляется за 24–72 часа, и если не подошёл, заменить его можно без процедур трудового кодекса.

Какие модели пришли на замену

Специалист в аренду. Компания привлекает конкретного разработчика через партнёра. Формально он в штате партнёра, фактически работает под управлением заказчика. Скорость старта — 24–72 часа. Оптимально, когда нужно быстро закрыть нишевую специализацию: 1С, iOS, DevOps. Минус — нет командной синергии, вовлечённость ниже штатной.

Выделенная команда. Партнёр формирует полноценную команду под проект, на нём административная нагрузка, команда работает как штатная. В среднем такое сотрудничество длится около полутора лет. Пример: e-commerce перед праздниками добавил команду на четыре месяца — мобилки, backend, QA, тимлид, — а после сезона сократил до поддержки.

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

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

Гибридная модель. Ядро — штатные специалисты: архитекторы, тимлиды, ключевые разработчики; расширение под пики и проекты за счёт внешней команды. Опять же хорошо подходит для больших компаний, и уже активно реализуется на рынке.

Как строить карьеру с учётом этих моделей

Советы, которые помогут адаптироваться вне зависимости от выбора карьерного пути

Считайте бизнес-ценность, а не технологии. Не «Я знаю React», а «Я сократил время загрузки страниц, что дало +3% конверсии». В штате и в выделенной команде одинаково ценят тех, кто влияет на метрики.

Разберитесь в экономике моделей. Если вы middle или senior — вы можете работать в штате, в выделенной команде, через технологический консалтинг или в гибридной схеме. У каждого формата своя экономика: разная ставка, разные условия, разные переговорные позиции. Изучите партнёров тех компаний, в которые вы хотели бы попасть.

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

Осваивайте то, что пересекается с вашим стеком. Рынок смещается к гибридным ролям: backend-разработчик с пониманием DevOps, аналитик с навыком автоматизации. Чистая специализация уступает пересечению компетенций.

Чего ждать

Объём штатного найма продолжит уменьшаться, этот год принесёт новые реструктуризации и сокращения в IT-отделах. Одновременно провайдеры выделенных команд и специалистов ожидают роста доходов на 19–24% в ближайшие три года.

Есть мнение, что ИИ ускоряет этот сдвиг, и нейросети позволяют на 30–50% сократить бюджет на типовых IT-позициях. Тот же объём задач закрывается меньшим количеством людей более высокого грейда. Спрос смещается туда, где автоматизация пока буксует: архитекторы, DevOps, ML-инженеры, специалисты по безопасности.

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

Мы в Centicore Group выстраиваем выделенные центры компетенций, где специалисты работают как часть продуктовой команды заказчика. Если вы хотите работать над интересными проектами в среде, где ценят экспертизу, — посмотрите наши открытые позиции.

История: золотой век мейнфреймов и становление цифровой инфраструктуры

В 1960-80-е годы, во время «экономического чуда», Япония массово внедряла компьютеры. Стандартом стали мейнфреймы IBM, а COBOL — идеальным языком для них.

На COBOL переписали все ключевые процессы: обработку банковских транзакций, расчёт заработных плат, управление счетами, логистику, оформление страховых полисов. Так, за два десятилетия была создана цифровая ДНК японской экономики — миллиарды строк кода, которые стали критически важны для бизнеса.

Принцип «Работает — не трогай»

Из истории вытекает первая и главная причина живучести COBOL — эффект path dependency (зависимость от предшествующего развития).

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

Из-за этого эффекта инженеры были ограничены в своём выборе. При этом каждый программист знает, что не стоит трогать legacy, которое работает. А чем дольше его не трогать — тем старше и больше оно становится. Чем старше и больше — тем страшнее, дороже и рискованнее его изменять.

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

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

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

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

Экономика: стоимость замены против стоимости поддержки

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

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

Следующий вопрос — экономическая выгода. Руководство компаний справедливо задаётся вопросом: «Какую прибыль принесет нам этот переход?». Чаще всего ответ — «Никакой, мы просто получим систему, которая делает то же самое, но на другом языке». С точки зрения ROI (возврата инвестиций) проекты миграции или модернизации выглядят крайне непривлекательно.

В итоге, инвестиции в поддержку legacy-систем, какими бы большими они ни были, почти всегда оказывались ниже запредельной стоимости и рисков полной замены систем на COBOL.

Культура: японский консерватизм и системный подход

Экономическая рациональность не существует сама по себе. Она подкрепляется и японской культурой, которая символизирует надёжность, стабильность, долговечность и лояльность.

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

Ещё одна особенность — система пожизненного найма.

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

Такая традиция создала уникальную среду: инженеры, начавшие работать с COBOL в 1980-х, оставались в компаниях до пенсии, накапливая и передавая бесценные знания. Это создавало внутреннюю стабильную экосистему экспертизы.

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

Решение кадрового кризиса: не вопреки, а благодаря

Самое большое заблуждение — считать, что Япония столкнулась с кадровым голодом и ничего не делает. Напротив, она выстроила целую индустрию по управлению этим COBOL-наследием.

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

Крупные корпорации передают поддержку COBOL-систем специализированным IT-гигантам, таким как Fujitsu, NEC, NTT Data, IBM Japan. Внутри этих компаний существуют целые департаменты, которые:

1. Целенаправленно нанимают и обучают молодых инженеров работе с COBOL и мейнфреймами.

2. Предлагают им стабильную карьеру с высокой (из-за низкой конкуренции) зарплатой и социальными гарантиями.

3. Разрабатывают инструменты модернизации: транспайлеры (конвертирующие COBOL в Java, в том числе на базе AI), эмуляторы и платформы для запуска legacy-кода в облаке.

Проблема кадров осознана и решается решается разными путями. Но возможно ли и нужно ли поддерживать COBOL бесконечно?

Есть ли у COBOL преимущества сегодня?

Кажется, что у такой старой технологии нет никаких преимуществ. Но давайте найдём одно — стабильность и надёжность. Системы продолжают работать исправно и пока их удаётся поддерживать. Вряд ли новый проект начнут разрабатывать на COBOL, но поддержка всё ещё продолжается.

Безусловный минус — стоимость поддержки. К 2025 году затраты на поддержку COBOL-решений могли составить до 12 триллионов йен в год или 80 миллиардов долларов, что уже превышает некоторый психологический барьер. Этому прогнозу уже несколько лет, так что сегодня компании стоят перед сложным выбором: вкладываться в модернизацию или продолжать поддержку.

В конечном итоге, живучесть COBOL в Японии — это не признак технологической отсталости, а следствие расчёта, уважения к стабильности и долгосрочной стратегии управления legacy. Эти старые системы — всё ещё ядро национальной цифровой инфраструктуры: дорогое в обслуживании, но надёжное.

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

Почему локальные решения теряют актуальность

В традиционной on-prem среде каждый шаг превращается в отдельный мини-проект: нужно утвердить бюджет, приобрести оборудование, настроить VPN, организовать резервирование. Даже простое действие — предоставление доступа новому разработчику — требует цепочки согласований через ИТ-отдел.

Кроме того, локальные решения часто избыточны с точки зрения ресурсов. Организация оплачивает полный набор серверов и лицензий, хотя фактическая загрузка может составлять всего 40-50%. Это создаёт неоправданные финансовые издержки.

Что дает переход в облако

Облачная инфраструктура — это полноценная инфраструктура, в которой команды и процессы разворачиваются за минуты, а не за кварталы. Все элементы находятся в едином управляемом контуре: IDE, пайплайны, базы данных, система контроля версий — всё это доступно по модели «как услуга». Нет привязки к офису, серверной или физической лицензии.

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

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

Как облако экономит ресурсы компании

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

Облачные решения устраняют эту проблему:

● Снижается «порог входа» для новых сотрудников — они подключаются к проекту за часы, а не дни;

● Ресурсы выделяются динамически, по фактическому потреблению, без оплаты простаивающего оборудования;

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

Вопрос безопасности: миф или реальная проблема?

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

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

Гибридные подходы и особые случаи

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

На практике многие команды выбирают гибридные схемы: локальный редактор плюс облачные пайплайны и репозитории. Это приемлемый компромисс, который учитывает и привычки разработчиков, и потребности в гибкой инфраструктуре.

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

Вместо заключения

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

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

Я проанализировала около 50 предложений от ведущих образовательных платформ, чтобы составить рейтинг из топ-10 самых эффективных курсов, а также добавить 12 коротких программ для точечного погружения и 15 бесплатных курсов для старта. Этот обзор поможет вам выбрать идеальное обучение по Agile и Scrum, независимо от вашего уровня и опыта.

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

ТОП-10 лучших курсов Agile и Scrum в 2026 году

1. Управление по Agile: Scrum, Kanban, Lean от Нетологии — полный цикл управления проектами: от создания канбан-досок и применения Lean-подхода до анализа эффективности и оптимизации рабочих процессов.
2. Agile: Scrum и Kanban в работе над продуктом от Skillbox.ru — системное понимание гибкой разработки с разбором архитектуры Scrum, инструментов Kanban и методик проектного управления.
3. Agile: от основ до скрам-мастера от Нетологии — инструменты для старта в роли скрам-мастера с отработкой навыков на Agile, Scrum, Kanban и Lean.
4. Agile: методология проектного управления от MBA — практические навыки проектного планирования и реализации с изучением методов целеполагания и управления ресурсами.
5. Agile, Scrum, Kanban от MBS — подходы к формированию задач для снижения затрат на проекты и инструментарий продуктового анализа.
6. Agile Project Manager от OTUS.ru — перспективы участия в Agile-трансформациях с освоением адаптации методологий под бизнес-задачи.
7. Agile в командах от Контур.Школы — базовые принципы гибких подходов с практическими умениями работы по Scrum и Kanban.
8. AGILE & SCRUM: теория и практика внедрения в бизнес от Знанио — системное изложение Scrum с разбором рабочих стратегий и тактических приемов.
9. Agile-методологии в управлении проектами от City Business School — Agile-подход с акцентом на принципы и практические инструменты управления проектами.
10. Методология Agile от Lectera.com — практическое применение Agile-управления и SCRUM-методик с изучением механизмов проектного управления.

Обучение Scrum и Agile — это маст-хэв не только для управленцев. Разработчики начинают видеть логику процессов, а дизайнеры и маркетологи — наконец-то находить общий язык с командой. Для тех, кто в начале пути или планирует сменить поле деятельности, это знание станет вашим козырем, серьезно повышающим шансы на интересную работу.

Онлайн-курсы Agile и Scrum

1. Управление по Agile: Scrum, Kanban, Lean | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Применить промокод>>>

На этом курсе Kanban и Lean изучаются не как сухая теория, а как практичные инструменты для работы. Слушатели учат выстраивать процессы с помощью канбан-досок, избавляться от лишнего с помощью Lean, а затем анализировать, как сделать всё еще эффективнее. В итоге, вы научитесь вести проекты так, чтобы заказчики были довольны, а команда не страдала от перегрузок и стресса.

• Стоимость: 40 400 рублей
• Длительность: 4 месяца
• Формат обучения: видеолекции, практические задания и вебинары
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• руководителям отделов и подразделений, а также тим-лидам;
• специалистам по управлению проектами и продуктами;
• владельцам компаний и стартапов.

Преимущества:

• помощь в подборе подходящего формата обучения;
• бесплатная вводная консультация с экспертом;
• индивидуальные рекомендации по развитию карьеры;
• удобная мобильная платформа для занятий;
• полный доступ к материалам без интернета;
• персональные напоминания о дедлайнах смен;
• детальная обратная связь по заданиям;
• возможность получить налоговый вычет 13%;
• организация корпоративного обучения для коллектива;
• гарантия возврата средств при несоответствии ожиданий;
• начисление баллов Плюса при оплате через Яндекс Пэй.

Недостатки:

• не обнаружено.

Программа обучения:

• Основы менеджмента и гибких методологий
• Продуктовая разработка и мышление
• Фреймворк Scrum и его практическое применение
• Принципы Lean и Kanban
• Лидерство в Agile-командах
• Комбинация различных методик управления
• Дипломный проект по внедрению Agile

Ознакомиться с полной программой >>>

2. Agile: Scrum и Kanban в работе над продуктом | Skillbox.ru

Используйте промокод kursfinder, чтобы получить скидку 50%

Применить промокод>>>

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

• Стоимость: 44 532 рублей
• Длительность: 1 месяц
• Формат обучения: видеокейсы, практика
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• тем, кто стремится освоить профессию скрам-мастера;
• руководителям проектов;
• начинающим;
• владельцам бизнеса.

Преимущества:

• консультация по выбору профессии с подарком и бесплатными модулями;
• практика с проверкой и комментариями от экспертов;
• постоянный доступ к материалам и будущим обновлениям;
• бесплатная индивидуальная консультация перед стартом;
• дополнительная скидка при полной оплате;
• оперативная техническая поддержка.

Недостатки:

• ограниченное количество мест на курс.

Программа обучения:

• Фреймворки Agile и их особенности
• Артефакты Scrum и их назначение
• Распределение ролей и зон ответственности в Scrum
• Основные события Scrum-процесса
• Практика проведения Product Backlog Refinement
• Организация и проведение ретроспектив
• Компетенции для успешного создания продукта
• Запуск и мониторинг производственных метрик
• Метод Kanban для оптимизации командной работы
• Инструменты для управления распределенными командами
• Итоговый проект по внедрению Scrum или Kanban

Ознакомиться с полной программой >>>

3. Agile: от основ до скрам-мастера | Нетология

Используйте промокод kursfinder, чтобы получить скидку 7%

Применить промокод>>>

Эта программа готовит к роли скрам-мастера, давая инструменты для управления проектами. В основе курса — отработка навыков на методологиях Agile, Scrum, Kanban и Lean. Вы научитесь применять Agile на практике, проводить скрам-ивенты и управлять бэклогом, настраивать процессы через канбан-доски, сокращать издержки Lean-методами, работать в условиях неопределенности, оценивать задачи и выстраивать командное взаимодействие. Финальной частью обучения станет формирование умения ставить продуктовые цели и запускать новые скрам-команды.

• Стоимость: 90 700 рублей
• Длительность: 6 месяцев
• Формат обучения: лекции, вебинары, воркшопы, практика, бизнес-игра
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• начинающим скрам-мастерам;
• менеджерам продукта или проекта;
• тимлидам, руководителям и HR;
• тем, кто ищет работу в IT-компаниях.

Преимущества:

• персональная консультация и скидка;
• поддержка в подготовке к сертификации PSM I;
• доступ к материалам в личном кабинете и мобильном приложении без интернета;
• гибкий график с вечерними занятиями для совмещения с работой;
• возможность корпоративного обучения и адаптации программы;
• поддержка карьерного роста и помощь в трудоустройстве.

Недостатки:

• встречаются сбои в мобильном приложении.

Программа обучения:

• Менеджмент и основы Agile
• Продуктовая разработка и формирование продуктового мышления
• Применение Scrum в управлении продуктом и проектами
• Методологии Lean и Kanban
• Agile-лидерство и управление командой
• Комбинирование различных подходов на практике
• Роль и обязанности скрам-мастера
• Взаимодействие скрам-мастера с командой разработки
• Работа скрам-мастера с владельцем продукта
• Интеграция скрам-мастера в организационную структуру
• Подготовка к сертификации скрам-мастера

Ознакомиться с полной программой >>>

4. Agile: методология проектного управления | MBA

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

• Стоимость: 55 608 рублей
• Длительность: 1 месяц
• Формат обучения: дистанционно, вебинары, практические задания
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• руководителям и менеджерам;
• предпринимателям и бизнесменам.

Преимущества:

• обратная связь от преподавателей по всем заданиям;
• поддержка кураторов на протяжении всего обучения;
• бесплатная консультация по программе перед стартом;
• спикеры-эксперты с опытом в российских и международных компаниях;
• возврат 13% от стоимости обучения через налоговый вычет;
• практическая составляющая: 70% занятий построены на реальных рабочих задачах;
• трудоустройство: 65% выпускников находят работу в течение трех месяцев.

Недостатки:

• задержки ответов технической поддержки.

Программа обучения:

• Планирование проектов: от постановки целей до контроля результатов
• Организация рабочих процессов с применением современных инструментов
• Контроль выполнения проектов на всех этапах жизненного цикла
• Освоение гибких методологий Agile, Scrum и Kanban
• Управление проектами в условиях цифровой трансформации
• Инструменты для эффективной работы в цифровой среде
• Адаптация классических подходов к современным реалиям

Ознакомиться с полной программой >>>

5. Agile, Scrum, Kanban | MBS

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

• Стоимость: 39 510 рублей
• Длительность: 2 дня
• Формат обучения: очно или онлайн, практические задания
• Сертификат: удостоверение о повышении квалификации или Сертификат Moscow Business School

Кому подойдет:

• product-менеджерам;
• руководителям проектных групп;
• внедренческим консультантам;
• топ-менеджерам;
• специалистам в сфере HR, развития бизнеса и стратегического планирования.

Преимущества:

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

Недостатки:

• не подойдет новичкам.

Программа обучения:

• Фреймворки и методологии создания продукта
• Менеджмент стартапов на основе Agile, Scrum и Kanban
• Продуктовая разработка по принципам Agile, Scrum и Kanban
• Практики управления командами и повышения их эффективности
• Инструментарий Lean Startup для развития продуктов в Agile-среде
• Методология Customer Development: путь от идеи до продукта
• Современные методы исследования рынка и пользователей
• Инструменты проверки гипотез и получения практических инсайтов

Ознакомиться с полной программой >>>

6. Agile Project Manager | OTUS.ru

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

• Стоимость: 116 000 рублей
• Длительность: 5 месяцев
• Формат обучения: интерактивные вебинары, практика, домашняя работа, кейс-задания, теоретическая часть
• Сертификат: удостоверение о повышении квалификации

Кому подойдет:

• проект-менеджерам и product-менеджерам из ИТ;
• руководителям команд или департаментов;
• руководителям, проект-менеджерам и другим управленцам не из ИТ;
• программистам, аналитикам, тестировщикам;
• другим заинтересованным специалистам не из ИТ.

Преимущества:

• практический подход с решением реальных рабочих задач;
• преподаватели с опытом реализации проектов в области;
• модули по разным аспектам управления для комплексного взгляда;
• компенсация до 13% стоимости обучения через налоговый вычет;
• доступ к сообществу выпускников для нетворкинга и обмена опытом;
• перспективы трудоустройства в компаниях, применяющих Agile-подход.

Недостатки:

• необходимо ждать начала обучения.

Программа обучения:

• Проектный и продуктовый подход: особенности и ключевые отличия
• Стратегия постепенных улучшений существующих процессов
• Методология радикальных преобразований в бизнес-процессах
• Управление организационными изменениями на разных этапах
• Инструментарий современного руководителя проектов
• Технические аспекты в управлении проектами и продуктами
• Развитие гибких навыков для карьерного роста
• Проектная работа для закрепления полученных знаний

Ознакомиться с полной программой >>>

7. Agile в командах | Контур.Школа

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

• Стоимость: 7 900 рублей
• Длительность: меньше 2 месяцев
• Формат обучения: лонгриды и дополнительные материалы, тестирования
• Сертификат: сертификат установленного образца

Кому подойдет:

• тимлидам в IT;
• разработчикам;
• тестировщикам;
• новичкам.

Преимущества:

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

Недостатки:

• материалы доступны только в течение двух месяцев.

Программа обучения:

• Agile-подход: его суть и бизнес-выгода для компаний
• Роль Scrum-мастера: зона ответственности и влияние на команду
• Влияние Agile на мотивацию и удовольствие от работы
• Антипаттерны Agile-команд: типичные ошибки и их решение

Ознакомиться с полной программой >>>

8. AGILE & SCRUM: теория и практика внедрения в бизнес | Знанио

Курс предлагает системное изложение методологии Scrum с разбором рабочих стратегий и тактических приемов. Автор детализирует ценностную основу Agile, охватывая теоретические аспекты от исторических предпосылок до современных практик. Практический блок включает освоение техник формирования продуктового бэклога, создания рабочих команд и инструментов планирования и контроля разработки.

• Стоимость: 299 рублей
• Длительность: от 1 дня
• Формат обучения: текстовые и видеоматериалы, практика
• Сертификат: сертификат установленного образца

Кому подойдет:

• руководителям;
• новичкам.

Преимущества:

• процесс обучения без посещения учебного центра и почтовой пересылки документов;
• обучение и документы от официальных лицензированных учебных организаций;
• документы установленного образца от котируемых образовательных учреждений;
• теоретические и практические знания от признанных специалистов-практиков;
• старт обучения сразу после оплаты и сжатые сроки освоения программы;
• снижение цены на 10% при нахождении аналогичного курса дешевле;
• возможность рассрочки, корпоративной оплаты или налогового вычета;
• возврат полной стоимости при несоответствии курса ожиданиям.

Недостатки:

• сжатое обучение.

Программа обучения:

• Agile INTRO
• Введение
• Сравнение
• SCRUM
• AGILE
• Внедрение
• Выводы

Ознакомиться с полной программой >>>

9. Agile-методологии в управлении проектами | City Business School

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

• Стоимость: 19 990 рублей
• Длительность: 21 день
• Формат обучения: видеоматериалы, тренажеры, тестирования
• Сертификат: сертификат установленного образца

Кому подойдет:

• менеджерам проектов;
• руководителям любого уровня.

Преимущества:

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

Недостатки:

• редкие проверки заданий куратором.

Программа обучения:

• Введение в основные agile-фреймворки: Scrum, Kanban, XP, Lean
• Базовые понятия и принципы гибкой методологии
• История создания и эволюции agile-подхода
• Сильные и слабые стороны agile для бизнеса
• Scrum-методология: принципы, артефакты и события
• Kanban-метод: визуализация, лимиты и управление потоком
• Сравнение Scrum и Kanban: критерии выбора подхода
• Agile-трансформация: этапы внедрения в проекты

Ознакомиться с полной программой >>>

10. Методология Agile | Lectera.com

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

• Стоимость: 3 650 рублей
• Длительность: 10,6 часов
• Формат обучения: видео, кейсы, практика, тестирования
• Сертификат: сертификат установленного образца

Кому подойдет:

• менеджерам;
• разработчикам;
• тестировщикам;
• новичкам;
• руководителям.

Преимущества:

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

Недостатки:

• программа дает базовые знания, но нет углубления в узкие темы.

Программа обучения:

• Ключевые аспекты управления проектами
• Применение Agile-методов в повседневных задачах
• Внедрение скрам в рабочие процессы команды
• Быстрое тестирование бизнес-идей и гипотез
• Развитие лидерских качеств и навыков
• Анализ продуктивности работы команды
• Основные понятия и термины Agile
• Стратегии эффективного планирования спринта
• Проведение ежедневных скрам-собраний
• Задачи и цели ретроспективы спринта

Ознакомиться с полной программой >>>

Еще 17 дополнительных курсов Agile и Scrum

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

• Интенсив Agile от Академии BELHARD. Участники интенсива освоят гибкие методологии разработки программного обеспечения с акцентом на их базовые принципы и ценностные ориентиры. Они изучат инструменты управления проектами и рисками, а также методы адаптации подходов под специфические условия. По окончании курса слушатели смогут целенаправленно улучшать коммуникационные процессы внутри команды и с заказчиками.
• Product Management: гибкие подходы Agile (Scrum), Lean и DevOps от УЦ Специалист. В рамках программы слушатели осваивают ключевые аспекты продукт-менеджмента и гибких подходов к разработке. Они изучат методы анализа рынка и конкурентной среды, управления продуктными требованиями и функциональностью. Особое внимание уделяется практическому применению Agile, Scrum, Lean и DevOps методологий в управлении продуктом.
• Agile - Scrum Foundation 1 от УЦ Специалист. Обучение построено на практическом применении Scrum через создание нового продукта в команде. Участники получат непосредственный опыт работы по данной методологии и оценят ее преимущества. Под руководством наставника они освоят инновационные подходы к решению проектных задач.
• Agile - Scrum Foundation 2 от УЦ Специалист. Программа знакомит с передовыми мировыми практиками разработки программного обеспечения, доказавшими эффективность. Основной акцент сделан на практических занятиях в формате ролевых игр с активным участием слушателей.
• Professional Scrum Master от Scrum.ru. Курс направлен на освоение принципов и методов эффективного управления проектами в Scrum. Выпускники получат инструменты для повышения результативности команд и достижения проектных целей.
• Agile Fundamentals Certification от ICAgile. Данная программа позволяет не только пройти обучение, но и получить международную сертификацию по основам Agile. Участники курса формируют глубокое понимание принципов гибкой методологии и immediately применяют полученные знания на практике через серию практических упражнений и разбор реальных кейсов.
• Agile и Scrum от ScrumTrek. В рамках этого обучения участники осваивают не только теорию, но и проходят полный цикл сертификации. Курс охватывает практическое применение различных гибких методологий разработки, включая Scrum, Kanban и XP. Особое внимание уделяется развитию навыков управления командой, анализа проектных показателей, а также техникам планирования и организации эффективного рабочего процесса.
• Agile и управление проектами от Mike Pritula. Эта программа предлагает комплексное изучение ключевых концепций и инструментов Agile-подхода. Слушатели детально разбирают такие аспекты как управление проектными рисками, построение эффективной коммуникации, обеспечение качества продукции и адаптацию к изменениям. Все теоретические модули подкрепляются практическими заданиями, которые можно immediately применять в реальной работе.
• Professional Scrum Master I: курс и симулятор от PmClub. Professional Scrum Master (PSM I) — профессиональный сертификат от scrum.org, которым обладают более 360 000 cкрам-мастеров по всему миру. Входных требований у PSM I нет, поэтому сертификат можно получить, даже если нет опыта работы скрам-мастером.
• Управление проектами по Agile от Rocket. Программа фокусируется на практическом применении Agile в управлении проектами. Слушатели учатся выстраивать рабочие процессы, распределять роли в команде, проводить все типы скрам-мероприятий: планирование спринтов, ежедневные стендапы, обзоры результатов и ретроспективы. Каждый модуль содержит практические задания для закрепления навыков.
• SAFe® Release Train Engineering от Agile LAB. Этот курс знакомит с принципами масштабирования Agile в больших организациях через методологию Scaled Agile Framework. Участники осваивают техники планирования и управления выпусками продуктов, а также инструменты эффективного взаимодействия со всеми заинтересованными сторонами проекта. Программа включает множество практических примеров из реальных проектов.
• Agile.Scrum от центра Андрея Плетнева. Практико-ориентированный курс, где участники учатся работать в скрам-команде, распределять задачи, проводить ежедневные встречи, планировать спринты и анализировать их результаты. Отдельные модули посвящены управлению проектными рисками и методам адаптации к изменениям в процессе разработки.
• Базовый Agile от ScrumTrek. Программа предназначена для начинающих и представляет собой первый этап международной сертификации ICAgile. Курс дает фундаментальное понимание Agile-методологии и prepares участников к дальнейшему профессиональному развитию в этом направлении. После завершения выдается сертификат ICAgile ICP.
• Методология Scrum от PM Exspert. Интенсивный трехдневный курс teaches эффективному сочетанию классического проектного управления по PMBOK® с гибкостью Scrum. Участники получают не только теоретические знания, но и практический опыт применения скрам-методологии в симуляции реального проекта.
• Agile и Scrum от Scrum Alliance. Программа Certified Scrum Master позволяет глубоко освоить ключевые концепции скрам-методологии. Обучение помогает улучшить коммуникационные процессы внутри команды и между командами, а также дает инструменты для проведения организационных изменений независимо от текущей роли в компании.
• Применение гибких технологий от Академии Айти. Курс помогает понять важность системного подхода в управлении разработкой IT-решений. Участники знакомятся с методологией Kanban, изучают техники визуализации рабочих процессов и инструменты управления ресурсами. Особое внимание уделяется практическому применению полученных знаний.
• Agile Project Management от Onagile Academy. Программа позволяет сравнить подходы к созданию команд в классическом проектном управлении и Agile-среде. Участники изучают методы подбора участников проекта, формирования эффективных рабочих групп и инструменты управления распределенными командами. Курс содержит множество кейсов из реальной практики.

Бесплатные курсы Agile и Scrum

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

1. Изучаем основы управления проектами по Agile за 3 дня от Skillbox. Если вам проще учиться короткими рывками — этот интенсив идеален. За три дня вы не только разберетесь в основах, но и сразу примените их в реалистичных рабочих ситуациях. Преподаватели-практики будут комментировать ваши решения — как если бы вы работали в настоящей команде.
2. Что такое Agile и зачем он нужен бизнесу от Нетологии. Этот курс — для тех, кто хочет понять саму суть гибких подходов. Вы узнаете, почему компании переходят на Agile, как это меняет работу команд, и какие роли появляются в процессе. Все объясняют на конкретных примерах, без заумных терминов.
3. Гибкое управление: как помочь бизнесу в условиях неопределенности от ScrumTrek. Отличный вариант для тех, кто работает в быстро меняющейся среде. Курс учит не просто следовать методологии, а гибко подстраиваться под обстоятельства — как раз то, что нужно в современном бизнесе.
4. Бесплатный мини-курс: Agile, Scrum, Kanban от Product Lab. Если хотите за один присест разобраться в трех основных подходах — вам сюда. Вс разложено по полочкам: что выбрать для ваших задач, как организовать команду и как управлять процессом от идеи до результата.
5. Agile. Вводный курс от Stepik. Для тех, кто любит учиться в своем темпе. Материалы доступны круглосуточно, можно возвращаться к сложным темам снова и снова. Отлично подходит для знакомства с темой.
6. Agile Product Owner Career Guide от Udemy. Мечтаете о роли владельца продукта? Этот курс покажет вам изнутри, что это за работа. Авторы делятся реальными вопросами с собеседований из крупных компаний — такая информация бесценна для тех, кто планирует карьерный рост.
7. Agile Project Management от Coursera. Для основательных людей, которые хотят разобраться до мелочей. Здесь вы поймете не только как работать по Scrum, но и почему именно так нужно работать. Отлично подходит для будущих скрам-мастеров и тех, кто хочет научиться вести команду через сложные проекты.

Бесплатные видеоуроки Agile и Scrum

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

1. Весь СКРАМ за 14 минут от Dmitry Blinov. Автор обозревает такие темы, как PO, Developers, SM, продукт, Sprint, Backlog, инкремент, Daily, демо, ретро и так далее.
2. Что такое Agile? Scrum VS Kanban ДЛЯ НОВИЧКОВ от GeekBrains. СМ помощью полезного видеоурока вы с автором погрузитесь в историю и узнаете, как создавался Agile. Также вам расскажут про Scrum и Kanban — методы, по которым работают многие компании.
3. Что такое AGILE и SCRUM? от Noukash. В этом видео автор обозревает данные системы. Просмотр будет полезен всем, кто метит на карьеру в IT — специалистам и студентам.
4. Agile и Scrum на пальцах от АйТиБорода. В этом видео автор постарался простыми словами рассказать о гибких методологиях разработки программного обеспечения.
5. Рождение Scrum-команды от ScrumTrek. В своем докладе на AgileDays Елена поделилась несколькими важными выводами, которые помогли выстроить грамотную систему построения успешной Scrum-команды.
6. Agile & Scrum – знакомство и легкое погружение от ITVDN. В видео затрагивается отличие проектов, ориентированных на выпуск четкого объема работ в определенный срок, и реальностью. Выпуск будет полезен разработчикам и тестировщикам, работающим в Agile & Scrum, тимлидам и менеджерам, бизнес-аналитикам и другим специалистам, желающим лучше понять суть Agile подходов.
7. Гибкие методологии. Agile, Scrum, Kanban, Lean, Экстремальное программирование от Аспро Cloud. В некоторых отраслях важно подстраиваться под ситуацию. И в этом видео вы как раз рассмотрите семейство гибких методологий.
8. Кейсы применения Agile от ScrumTrek. Вводный вебинар курса Certified Agile Professional Online, на котором вы разберете кейсы применения Agile.

Что такое Agile и Scrum и в чем их основные отличия

Agile — это, по сути, просто здравый смысл, оформленный в принципы. Представьте, что вы делаете ремонт квартиры. Если вы заранее, на год вперед, распишете, какого цвета будут обои 15 октября, и будете слепо следовать этому плану, это не будет Agile. Скорее всего, за это время ваши предпочтения изменятся, появятся новые материалы, а сосед сверху затопит вас, и часть работы придется переделывать.

Agile — это когда вы решили делать ремонт поэтапно. Сначала — кухня. Сделали, пожили, поняли, что розетки надо было расположить иначе, а вытяжку — посильнее. Внесли изменения, когда приступили к ремонту ванной. Потом — гостиная. Вы постоянно сверяетесь с реальностью, а не с устаревшим планом. Главная идея Agile — признать, что мир меняется, и настаивать на неподобающем плане — это глупо. Вместо этого лучше показывать результат, получать feedback и гибко адаптировать курс. Это не методология, а скорее набор убеждений о том, как лучше работать.

Scrum — это уже конкретная методология, которая помогает воплотить эти убеждения в жизнь. Если Agile — это философия «ремонт лучше делать поэтапно», то Scrum — это конкретный график с чёткими ролями и действиями.

В Scrum работа делится на короткие отрезки, обычно по 1-2 недели, называемые спринтами. В начале каждого спринта команда договаривается: «Что мы можем реально сделать за эти две недели?» Они берут задачи из общего списка пожеланий, называемого бэклогом, и обещают завершить выбранный кусок к установленной дате.

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

В конце спринта происходят два важных события. Сначала команда показывает готовый результат заказчику или пользователям и спрашивает: «Вам то, что получилось? Как двигаться дальше?» Затем команда проводит встречу без начальства, чтобы обсудить: «Как улучшить наш процесс? Что пошло не так? Может, мы взяли на себя слишком много задач или часто отвлекались?» Эта встреча называется ретроспективой и необходима для постоянного улучшения работы команды.

В Scrum есть чёткие роли: Владелец Продукта (отвечает за «что» делать, представляет интересы заказчика), Scrum-мастер (следит за процессом, помогает команде работать по правилам Scrum, устраняет препятствия) и Команда разработки (делает работу).

Как понять, что команде пора пробовать Agile-подходы

Вы наверняка узнаете эту ситуацию: только вы составили красивый, детальный план на полгода вперед, как приходит заказчик или руководство и говорит: «Мы тут подумали, давайте сделаем вот так вместо этого». Или на рынке выходит продукт конкурента, и все приходится переделывать на ходу. Ваша команда тратит кучу времени не на саму работу, а на бесконечные перепланирования и исправления старых документов. Если вы постоянно чувствуете, что догоняете уходящий поезд и работаете по устаревшим вводным, это первый звоночек. Agile как раз построен на идее, что изменения — это нормально, и нужно уметь к ним адаптироваться, а не бороться с ними.

Когда непонятно, что в итоге получится и доволен ли заказчик

Вы несколько месяцев упорно трудились, сдали проект, а заказчик смотрит на результат и говорит: «Ну, это не совсем то, что я хотел»? Или вы сами в процессе понимаете, что создаете что-то бессмысленное, но останавливаться уже поздно. Это классическая ловушка долгосрочного планирования без обратной связи. Agile предлагает показывать результаты работы часто — например, раз в одну-две недели. Это позволяет быстро понять, туда ли вы движетесь, и вовремя скорректировать курс, пока не потратили полгода на не тот продукт.

Когда команда теряет мотивацию и тонет в рутине

Если ваши сотрудники чувствуют себя винтиками в большой машине, не видят цели своей работы и завалены бессмысленными отчетами, пришло время что-то менять. Agile, и в частности Scrum, делают процесс работы прозрачным для всех. Каждый член команды видит общую цель, понимает, какой вклад он вносит, и может напрямую влиять на организацию своей работы. Короткие циклы, четкие цели на каждый спринт и регулярные обсуждения «как нам улучшить наш процесс» (ретроспективы) возвращают людям ощущение осмысленности и контроля, а это — лучший мотиватор.

Когда все идет по плану, но результат никого не радует

Это, пожалуй, самый коварный сценарий. Команда работает как часы, соблюдает все сроки, выполняет KPI, но итоговый продукт оказывается посредственным, неинновационным или не находит отклика у пользователей. Это сигнал, что вы оптимизировали процесс ради процесса, забыв о главном — ценности для конечного потребителя. Agile заставляет постоянно задавать себе вопрос: «Делаем ли мы то, что действительно нужно людям?» Работа короткими циклами с регулярной демонстрацией результатов помогает сверяться с реальностью и не позволяет надолго уходить в «автономное плавание», отрываясь от потребностей рынка.

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

Как вы начали изучать Agile? Какие курсы или материалы стали для вас наиболее полезными? Поделитесь своим опытом в комментариях — это поможет другим сделать правильный выбор и начать обучение с уверенностью.

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

На основе анализа отчётов Gartner, Stack Overflow Developer Survey и открытых данных GitHub мы выделили пять ключевых технологий, которые определят стандарты бэкенд-разработки к 2028 году.

Ключевые тренды в современном бэкенде

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

Другой важный тренд — интенсивное внедрение ИИ в разработку. Stack Overflow Developer Survey 2025 показывает, что 82% разработчиков уже используют GPT-модели OpenAI в своей работе. И это не просто дань моде — AI кардинально меняет процессы создания кода, тестирования и отладки. Например, GitHub Copilot не только предлагает фрагменты кода, но и генерирует unit-тесты, а также исправляет уязвимости прямо в процессе написания программы.

Российский IT-рынок демонстрирует особую динамику. После впечатляющего роста на 46% в прошлом году, он продолжает развиваться, хотя и более умеренными темпами — около 12% в год. Акцент на импортозамещение создаёт уникальную среду для развития отечественных бэкенд-решений, что особенно заметно в сегменте заказной разработки ПО с ежегодным приростом около 14%.

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

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

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

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

Технология 1: AI-ассистенты для разработки и DevOps

Искусственный интеллект теперь — эффективный помощник почти каждого программиста. AI такой же незаменимый инструмент, как IDE или система контроля версий.

Почему это станет стандартом

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

Год назад Gartner прогнозировал, что к 2025 году 50% предприятий будут использовать платформы оркестрации AI для операционализации искусственного интеллекта. В бэкенд-разработке это выразится в интеграции AI-помощников непосредственно в DevOps-процессы — от автоматического написания тестов до оптимизации запросов к базам данных.

Современные ИИ-инструменты уже могут создавать сложные приложения по текстовым описаниям. В 2025 году платформа Replit показала впечатляющий пример: она сгенерировала полноценный клон игры Zelda с боями, ландшафтом и ИИ-противниками всего по одному запросу. При этом инструмент сам тестировал результат через скриншоты, имитируя цикл обратной связи разработчика.

ИИ-системы теперь применяют новые методы тестирования:

• автоматически проверяют код через скриншоты и визуальную верификацию;
• сравнивают результаты с эталонными решениями на сложных эталонных тестах (бенчмарках) вроде SWE-bench;
• используют метаморфное тестирование для поиска скрытых ошибок .

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

Ключевое преимущество современных AI-ассистентов — способность интегрироваться в полный цикл разработки. Например, такие инструменты, как GitHub Copilot, не только генерируют код, но и помогают создавать конфигурации для Infrastructure as Code (IaC), включая YAML-файлы, шаблоны Terraform и конфигурации Ansible. Это значительно снижает ошибки при настройке CI/CD-пайплайнов и ускоряет развёртывание инфраструктуры.

Кроме того, AI-ассистентов всё чаще используют, чтобы автоматического анализировать логи и выявлять аномалии, что позволяет проактивно устранять проблемы заранее.

Практическая польза уже очевидна: разработчики, применяющие AI-инструменты, сообщают о сокращении времени на рутинные задачи на 30-40%. Это подтверждается данными Stack Overflow о том, что профессиональные разработчики всё чаще используют Claude Sonnet от Anthropic.

Технология 2: Cloud-native и отраслевые облачные платформы

Облачные технологии прошли путь от популярного тренда до бизнес-необходимости. Gartner предсказывает, что более 50% предприятий будут использовать отраслевые облачные платформы к 2028 году. Это означает переход от общих cloud-решений к специализированным платформам, созданным для конкретных индустрий.

Ключевые изменения в подходе

Современные cloud-native решения — это не просто перенос приложений в облако, а принципиально иная архитектура. Контейнеризация стала де-факто стандартом: Docker показал рекордный рост +17% за год с 2024 по 2025 — это наибольший показатель среди всех технологий в опросе Stack Overflow.

Важным элементом экосистемы cloud-native становятся инструменты оркестрации вроде Kubernetes и Service mesh (например, Istio), которые автоматически развертываются, масштабируются и управляют контейнеризованными приложениями.

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

В России этот тренд имеет особую специфику. Активный рост облачного рынка (прогнозируемые +18% в год до 2029 года) сочетается с процессами импортозамещения. Российские ИТ-компании, такие как «Группа Астра» (76% рынка ОС), создают собственные облачные решения и уникальные экосистемы для разработчиков.

Преимущества cloud-native подхода очевидны: автоматическое масштабирование, отказоустойчивость, сниженные операционные затраты. По данным Gartner, гиперавтоматизация снижает операционные затраты на 30% при оптимизации процессов. Бэкенд-разработчики теперь сосредотачиваются на бизнес-логике вместо управления инфраструктурой.

Технология 3: Безопасность как код (Security as Code)

Кибербезопасность — уже не отдельная функция, а неотъемлемая часть процесса разработки. Почти 80% руководителей, опрошенных Gartner, уделяют защите данных и процессов максимум внимания. Это напрямую влияет на подходы к бэкенду.

Интеграция безопасности в жизненный цикл разработки

Концепция «Security as Code» (SaC) означает встроенную защиту на всех этапах жизненного цикла разработки и развёртывания программного обеспечения. В рамках этого подхода реализуется автоматизированная проверка на уязвимости, анализ зависимостей, настройка политики доступа и шифрования. Все параметры безопасности определяются декларативными описаниями и сохраняются вместе с исходным кодом..

Ключевой элемент SaC — автоматизация security-проверок на всех этапах разработки. Политики безопасности, описанные в виде кода (например, с использованием языка Rego), интегрируются непосредственно в CI/CD-пайплайны.

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

На российском рынке интерес к решениям в области безопасности стабильно растет. Компания Positive Technologies — один из лидеров на российском рынке кибербезопасности — показывает рост объема заказов на 111% в первом квартале 2025 года. Это свидетельствует о высоком спросе на решения для защиты информации.

Практическая ценность подхода «безопасность как код» — в предотвращении уязвимостей на ранних этапах, а не в их исправлении постфактум. Это сокращает затраты на безопасность на 40-60% согласно уже упомянутому в нашей статье исследованию Gartner. Для разработчиков это означает необходимость осваивать новые инструменты и практики, но результат стоит того — более надёжные и безопасные приложения с меньшими усилиями.

Технология 4: Бессерверные архитектуры (Serverless)

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

Эволюция подходов к архитектуре

Современные бессерверные платформы предлагают не просто Function-as-a-Service (FaaS), а комплексные решения для построения событийно-ориентированных архитектур. Это позволяет создавать системы, которые автоматически масштабируются до тысяч одновременных исполнений и обратно до нуля, когда нагрузки нет.

Особенность современных бессерверных платформ — их глубокая интеграция с экосистемой облачных сервисов. Такие решения, как AWS Lambda, Azure Functions и Yandex Cloud Functions, предоставляют готовые триггеры для обработки событий от баз данных, очередей сообщений, систем хранения и API-шлюзов.

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

Stack Overflow отмечает значительный рост популярности FastAPI (+5 процентных пунктов), что говорит об устойчивом тренде на Python для производительных API. Многие из этих API развёртываются именно в бессерверных средах, что обеспечивает им автоматическое масштабирование и высокую доступность.

Выгоды serverless-архитектур особенно очевидны для стартапов и компаний с переменной нагрузкой. Они экономят до 70% затрат на инфраструктуру по сравнению с традиционными подходами.

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

Технология 5: Платформенная инженерия (Platform Engineering)

Платформенная инженерия возникла как ответ на растущую сложность DevOps-практик в крупных организациях. Суть подхода в том, чтоб создавать внутренние платформы, которые предоставляют разработчикам готовые инструменты и сервисы для самостоятельного развертывания и управления приложениями. Например, платформа Backstage от Spotify объединяет инструменты разработки в единый портал с каталогом сервисов, шаблонами проектов и системой самообслуживания.

Внутренние developer-платформы

Вместо того чтобы каждый раз настраивать CI/CD-пайплайны, системы мониторинга и логирования, разработчики получают доступ к стандартизированной платформе, которая предоставляет все эти возможности через простое API или пользовательский интерфейс.

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

В России необходимость импортозамещения ускорила развитие платформенных решений. Компании типа «Хэдхантер» и «Группа Астра», которые показали рост выручки в первом квартале 2025 года, инвестируют в собственные платформы, чтобы ускорить разработку и повысить надежность сервисов.

Главное преимущество платформенной инженерии — ускоренный вывод продукта на рынок и стандартизация процессов. Разработчики могут самостоятельно запускать сервисы и не ожидать помощи DevOps-инженеров, что сокращает циклы разработки на 30-50% согласно данным Gartner.

Итоги: готовьтесь к новому стандарту

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

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

Ключевой вывод: успех в бэкенд-разработке через три года будет определяться не знанием конкретного фреймворка или языка, а способностью интегрировать AI-инструменты, работать с cloud-платформами, встраивать безопасность в процесс разработки, проектировать бессерверные архитектуры и эффективно использовать внутренние платформы. Начинайте осваивать эти технологии сейчас — и будете на шаг впереди.

Что мы видим в реальности?

• Руководители перегружены задачами, вместо того чтобы стратегически развивать продукт.
• Разработчики работают сверхурочно, потому что никто не знает, кто чем занят.
• Тестировщики ловят ошибки, которые можно было предотвратить на ранних этапах, или пропускают их в релиз.
• Заказчики недовольны сроками, а менеджеры проекта постоянно «тушат пожары».

И всё это — следствие одного и того же: отсутствия системного подхода к управлению процессами.

Я постараюсь рассказать, как внедрение процессов помогает оптимизировать работу, сократить авралы и переработки и вывести бизнес на новый уровень. Можете последовать нашему примеру из Webit.

«Хороший продукт рождается не только из кода, но и из чётко выстроенных процессов»

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

Почему процесс важнее человека?

Представьте: ваш лучший разработчик, тот самый, кто «держит всё в голове», уходит. Или просто выгорает. Что остаётся? Паника, недели (а то и месяцы) простоя; знания, унесенные в никуда. Человек — не железный. Процесс — да. Именно он — ваш истинный страховой полис. Не набор бюрократии, а живая система, которая стандартизирует рутину, позволяет безопасно делегировать, превращает новичка в бойца за дни, а не недели, и наконец-то делает прогнозы не гаданием, а осознанным планом. Клиент перестает дергаться, менеджер — дышать в бумажный пакет. Это ли не мечта?

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

Целевое использование времени: зачем нужен мониторинг?

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

Это типичная ситуация, когда время тратится, но результат остаётся непредсказуемым.

В таких случаях говорят: «Работали много, работали качественно… но почему-то ничего не готово».

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

• Сколько времени ушло на согласование одного экрана?
• Сколько раз задача меняла статус из «готова» в «переделать»?
• Как часто разработчики переключались между задачами?
• Сколько часов ушло на объяснение, что именно нужно заказчику?
• Сколько раз задача возвращалась на доработку после нахождения багов на «проде».

Мониторинг рабочего времени — это не про шпионаж, а про прозрение. Он отвечает на больные вопросы: сколько реально длится интеграция платежной системы? Почему задача трижды возвращалась из тестирования? Кто в команде — скрытый гений верстки, а кому нужна поддержка по сложным API? Это не просто цифры. Это карта компетенций и потерь, ваш компас в океане хаоса.

Процесс позволяет:

• стандартизировать работу,
• делегировать задачи без потери качества,
• обучать новых сотрудников,
• масштабировать команду,
• прогнозировать результаты.

Перегруз сотрудника: симптомы и причины

В рамках мониторинга вы можете выявить такую неприятную штуку как перегруз сотрудника. Разберёмся в признаках перегруза и что делать с этой напастью.

Каждый из нас знает, что такое выгорание. Но не все понимают, как оно начинается. Часто это происходит незаметно — постепенно.

Вот несколько симптомов перегрузки сотрудника:

• Постоянное чувство усталости, даже после выходных.
• Снижение концентрации, забывчивость, рассеянность.
• Раздражительность, конфликты в команде.
• Задачи выполняются медленнее, чем раньше.
• Работа занимает всё больше времени, включая сверхурочные.
• Увеличение количества ошибок и багов.
• Снижение интереса к проекту, отсутствие инициативы.
• Появление фраз вроде: «Мне всё надоело» или «Я не вижу смысла».

Почему горим? Пять смертных грехов процесса (или его отсутствия):

• Культ героя

«Вася один сделает, ему проще!» Знакомо? Вася превращается в незаменимого, а его знания — в риски для всей компании. Уйдет Вася — рухнет всё.

• Документация? Не, не слышали

Расплывчатые ТЗ — это минное поле. Каждая неясность — десятки вопросов, часов уточнений и неизбежных переделок. Нет регламентов? Каждый делает как бог на душу положит — дублирование, трение, ошибки.

• Ад многозадачности

Встречи, срочные запросы, прыжки между задачами каждые полчаса… Фокус размыт, эффективность падает. Мозг не резиновый!

• Бег по кругу

Задача «сделана»? Не спешите радоваться! Вот она вернулась — дизайн перепридумали, бэкенд не стыкуется, ТЗ «немного» изменилось. Нет чёткого «Done» — есть бесконечный марафон.

• Не по Сеньке шапка

Человеку дали задачу не по его скиллам. Он молчит, боится признаться, бьётся как рыба об лед, тратит уйму времени… Результат — стресс, ошибки, ощущение собственной неполноценности.

Как мониторинг помогает понять, кто что может?

Итак, перейдем уже наконец-то к сути. Одним из главных процессов выступает мониторинг. Рассмотрим мониторинг анализа команды.

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

На основе таких данных можно сделать несколько выводов:

• Иван сильнее других в вёрстке.
• Марии нужна поддержка при работе с API.
• Петру стоит пройти обучение по DevOps-процессам.
• Ольга хорошо справляется с автономной работой.

Это уже не просто статистика, а точка роста для всей команды.

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

Советы по интерпретации данных:

• Не сравнивайте людей напрямую: у всех разный уровень подготовки и скорость работы.
• Фокусируйтесь на динамике: например, если задача, которая ранее занимала 12 часов, теперь занимает 7 — это прогресс.
• Смотрите на то, какие задачи решает сотрудник: если он берётся за сложные и новые — это тоже успех.
• Обсуждайте результаты в команде, а не в одностороннем порядке: пусть сам сотрудник объяснит, почему задача заняла столько времени.

В чем соль? Какие могут быть итоги мониторинга

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

• «Мне нужно было подождать ответ от дизайнера».
• «Потом QA вернула на доработку».
• «Заказчик поменял требования».
• «Сначала я делал одно, потом оказалось, что нужно совсем другое».

Все эти ситуации — скрытые потери времени, которые не всегда видны на первый взгляд, но влияют на:

• сроки,
• качество,
• нагрузку сотрудников,
• маржинальность продукта.

Вот самые распространенные «точки утечки»:

Эти проблемы могут существовать годами и съедать время и деньги компании, пока кто-то не начнёт их анализировать и менять.

Рассмотрим более детально каждый кейс

• ТЗ — всему голова (или нет)?

Написано на салфетке без техкоманды — разработчики стартуют в тумане.

Решение: Technical Discovery — священный ритуал перед стартом задачи. Все за столом, все поняли, все согласны.

• Тестирование

Баги ловят уже после релиза, чек-листов нет — стоимость исправлений зашкаливает.

Решение: чёткие критерии приемки в начале задачи. Автотесты — не роскошь, а страховка. Регресс — не наказание, а норма.

• Согласования

Вечный двигатель правок? «Ой, а давайте ещё вот это…», — звучит как приговор сроку.

Решение: жёсткий процесс Change Request. Хочешь изменить? Оцени трудозатраты, согласуй с клиентом цену/сроки. Никакого «ну это же быстро!».

• Деплой

Русская рулетка? Ручные костыли, нет CI/CD — каждый релиз как прыжок с парашютом в неизвестность. Ошибки, откаты, ночные бдения. Решение: автоматизация — ваш друг.

Полезные советы: как выкрутиться из обнаруженных проблем

Не все процессы одинаково полезны. Есть те, которые напрямую влияют на качество продукта.

Code Review

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

Тестирование (manual / automated)

• QA-инженеры проверяют, что функционал работает корректно.
• Автотесты ловят регрессии на раннем этапе.
• Без тестирования сложно понять, что новый функционал не сломал старый.

Чек-лист завершённости задачи

• Например, все поля валидируются? Есть ли обработка ошибок? Проверено ли поведение на разных устройствах?
• Такие списки позволяют стандартизировать проверку и исключить «случайные» проблемы.

Автоматическое тестирование (CI/CD pipeline)

• Запуск тестов перед каждым деплоем.
• Проверка покрытия тестами.
• Линтинг кода, анализ производительности.

User Acceptance Testing (UAT)

• Показывает продукт заказчику до релиза.
• Позволяет найти несоответствия ожиданиям.
• Уменьшает количество доработок после релиза.

Post-release monitoring

• Логирование ошибок в реальном времени.
• Использование инструментов вроде Sentry, LogRocket, Bugsnag.
• Быстрое реагирование на инциденты.

Выгода для бизнеса

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

Когда вы улучшаете процессы, вы:

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

А всё это напрямую влияет на маржинальность — долю выручки, остающуюся после вычета переменных издержек.

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

Время — деньги. Особенно, если вы работаете в конкурентной нише.

Снижение количества багов и их стоимости. Один из ключевых факторов, влияющих на маржинальность — стоимость бага.

И она тем выше, чем позже ошибка обнаружена.

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

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

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

Мы собрали лучшие инструменты для мобильного программирования: от простых редакторов до IDE с компиляторами и отладчиками. Вы узнаете про приложения для фронтенда и бэкенда. Мы затронем тему вайб-кодинга и даже расскажем, как установить Linux-терминал поверх Android или iOS.

Ссылки на приложения опубликовали в комментариях.

CodePen

• Приложение для браузера: ✅
• Приложение для Android: ✅
• Приложение для iOS: ❌

Обзор начнём с онлайн-платформы для фронтендеров CodePen. Песочница работает с HTML, CSS, JS. С её помощью разработчики обмениваются идеями, создают прототипы и обучаются вёрстке. CodePen ценят за простоту – открыл песочницу, написал код, увидел результат.

Проекты называются «пэнами», ими можно делиться с другими пользователями. Ещё есть лента, где публикуют интересные работы с открытым кодом. Проекты можно копировать себе, оценивать и комментировать.

CodePen поддерживает 7 фреймворков, 5 библиотек и 24 набора UI-компонентов. Возможности ограничены только мощностью устройства: превью тяжёлых пэнов на телефоне будет лагать.

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

Code Editor

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ✅

Универсальный редактор Code Editor подсвечивает синтаксис 110+ языков. В приложении есть поиск и замена символов, отображение и скрытие строк, выделение совпадающих скобок, автоматические отступы.

Фронтендеры скачивают Code Editor ради предпросмотра HTML и плагина Emmet. Также через встроенную консоль удобно тестировать и отлаживать JS-скрипты.

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

Code Editor поддерживает FTP, FTPS, SFTP и WebDAV для работы с удалёнными серверами. Ещё в приложение добавили Google Диск, Dropbox и GitHub, чтобы синхронизировать файлы между устройствами.

Acode

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ❌

Редактор Acode охватывает 100+ языков программирования. Приложение оптимизировано для работы с файлами до 50000 строк. Acode выбирают для мобильной разработки, быстрых правок и обучения программированию.

Встроенный просмотр HTML и Emmet ускоряет вёрстку. В JS-консоли можно тестировать код фрагментами без создания отдельных файлов. Веб-сайты запускаются прямо в браузере приложения. Ещё редактор поддерживает GitHub, FTP/SFTP для работы с удалёнными серверами.

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

Pydroid, Cxxdroid, Jvdroid

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ❌

Приложения от одного разработчика не случайно объединили в один раздел – это лучшие мобильные IDE для Python, C/C++ и Java. Каждое заточено под конкретный ЯП, но все построены на одной архитектуре и предлагают схожий функционал.

IDE работают автономно – интернет нужен только для скачивания дополнений. В каждом приложении есть терминал, примеры кода для обучения, система управления пакетами и библиотеками.

Редакторы поддерживают:

• подсветку синтаксиса,
• работу с вкладками,
• расширенную клавиатуру,
• быструю публикацию кода на Pastebin.

Pydroid 3 – самое функциональное приложение из тройки. Это интерпретатор Python 3 с менеджером пакетов pip и готовыми библиотеками для data science:

• numpy,
• scipy,
• matplotlib,
• scikit-learn,
• jupyter.

В премиум-версии доступны OpenCV, TensorFlow и PyTorch.

Есть поддержка GUI-приложений через Tkinter, Kivy с SDL2-бэкендом и PySide 6. Также встроен компилятор C/C++/Fortran для сборки нативных библиотек и Cython.

Отладчик PDB работает с точками останова. Приложение определяет используемые библиотеки и переключается на соответствующий режим выполнения. Ещё редактор автоматически ставит отступы и предлагает навигацию по методам.

Cxxdroid – это компилятор C/C++ на базе Clang с поддержкой ассемблера. В менеджере пакетов есть популярные библиотеки:

• Boost,
• SQLite,
• ncurses,
• libcurl.

Графические библиотеки SDL2, SFML и Allegro доступны в премиум-версии.

Разработчики заморочились над системой кэширования, которая ускоряет сборку в среднем в 3 раза, а при использовании Boost – до 33 раз. Также есть режим интерпретатора (REPL) на основе CERN Cling для интерактивной работы с кодом.

Архитектура приложения исключает падения IDE из-за ошибок в пользовательском коде – анализ и компиляция выполняются одним компилятором.

Jvdroid работает на OpenJDK 11 – редактор поддерживает стандарты Java и jar-библиотек. Интегрирован с Maven для управления проектами и зависимостями. Компилятор оптимизирован с помощью Nailgun.

Приложение включает JShell для интерактивной работы с Java. Есть компиляция программ на Kotlin, Scala и Clojure через Maven. Ещё редактор показывает Javadoc для методов и классов.

Replit

• Веб-приложение: ✅
• Приложение на Android: ✅
• Приложение на iOS: ✅

Replit – облачная IDE с ИИ-агентом. Вы получаете помощника, который создаёт проекты по промпту: описываете идею приложения, агент предлагает функции, генерирует код и деплоит в облако.

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

• Python,
• JavaScript,
• TypeScript,
• C++,
• HTML/CSS,
• Java,
• Ruby и десятки других.

До 100 человек могут одновременно редактировать код. Готовые проекты деплоятся одним кликом. Доступна выделенная VM, автоскейлинг, деплой по запросу.

Встроенные инструменты:

• Автодополнение кода через Ghostwriter.
• Поиск и исправление ошибок в реальном времени.
• Модульное тестирование без настройки.
• Интеграция с GitHub (автосинхронизация).
• Аутентификация пользователей через Repl Auth.

ИИ-агент поддерживает ограниченный набор технологий – Flask и Node.js. С React и другими фронтенд-фреймворками могут быть проблемы. Интеграции доступны только с OpenAI, Google, PostgreSQL и S3.

Официальные приложения для iOS и Android позволяют кодить прямо с телефона. Интерфейс адаптирован под сенсорные экраны, поддерживается голосовой ввод для общения с ассистентом.

Replit подходит для быстрого прототипирования, обучения и создания простых веб-приложений. ИИ-агент понравится тем, кто хочет воплотить идею в код без знаний разработки. Для сложных проектов не подойдет, но для MVP и экспериментов – хороший выбор.

Termux (iSH Shell)

• Веб-приложение: ❌
• Приложение на Android: ✅
• Приложение на iOS: ✅

Termux – это полноценный Linux-терминал для Android. В отличие от редакторов кода, вы получаете ОС со всеми инструментами программиста. Можно работать с любыми языками программирования, компилировать код, устанавливать библиотеки, подключать базы данных, настраивать веб-серверы.

После установки в приложении вы увидите только чёрный экран – это Linux-терминал. Графического интерфейса нет, всё управляется командами.

Перед работой обновите систему:

Первая команда проверяет доступные обновления, вторая их устанавливает. На все вопросы отвечайте «Y».

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

Подведём итоги

Выбор мобильного редактора зависит от ваших задач:

• Для фронтенда подойдут CodePen (веб-разработка и прототипирование), Code Editor и Acode (универсальные редакторы с поддержкой HTML/CSS/JS).
• Для бэкенда есть отдельные IDE: Pydroid для Python, Cxxdroid для C/C++, Jvdroid для Java. Они работают автономно и включают все необходимые инструменты.
• Для экспериментов с ИИ попробуйте Replit – облачную IDE с умным ассистентом, который создаёт приложения по описанию.
• Для профессиональной разработки установите Termux (Android) или iSH Shell (iOS) – это полноценные Linux-терминалы с неограниченными возможностями.

Знаете классное приложение, которое не попало в подборку? Расскажите в комментариях о его плюсах и минусах! Ваши советы помогут коллегам в поисках идеального инструмента для работы с кодом на смартфоне.

Привет, меня зовут Максим Павлов, руководитель направления архитектуры в компании Axenix

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

Руководства и чертежи

BPM (Business Process Management) — это управление бизнес-процессами как системой: постановка, оптимизация, автоматизация. BPMN (Business Process Model and Notation) — язык и нотация для графического описания этих процессов.Иными словами: BPM — это методология, а BPMN — инструмент её визуализации и реализации.

BPM можно сравнить с общим руководством по сборке конструктора, в котором описываются шаги, необходимые для получения нужного результата. А вот BPMN — это как чертёж или схема конструктора, где видно, в какой последовательности соединять детали и кто за что отвечает. Такая схема помогает всем участникам понять процесс одинаково. Приведём пример с кофейней: клиент делает заказ → кассир его принимает → бариста готовит → клиент получает напиток. Всё достаточно просто. Но стоит лишь немного усложнить: добавить доставку, оплату бонусами, акции, возвраты — и без формализации уже не обойтись. Где что начинается, кто за что отвечает, что делать при исключении?

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

Нотация BPMN появилась как ответ на потребность в схеме, одинаково понятной и бизнесу, и техническим специалистам. До BPMN в ходу были либо слишком «технические» языки вроде UML Activity Diagram, понятные только архитекторам, либо простые блок-схемы, которые не годились для автоматизации.

BPMN стал золотой серединой. Это строгая визуальная система: кружки, стрелки, ромбики, прямоугольники — все чётко определено. Каждый элемент имеет однозначную трактовку и может быть интерпретирован машиной. И самое главное — такую схему можно превратить в работающий процесс.

Именно это и делает Camunda — одна из самых популярных open-source платформ для исполнения процессов, описанных в BPMN.

Camunda: движок процессов нового поколения

Camunda — не просто визуальный редактор. Это полноценный исполняющий движок, который «читает» BPMN-схемы и превращает их в действия. Camunda подключается к вашей инфраструктуре и запускает процессы, отслеживает их выполнение, взаимодействует с API, ставит задачи людям и логирует все, что происходит.

На уровне архитектуры Camunda может работать в двух режимах: как отдельный сервер или встраиваемый компонент (embedded mode). Последний особенно удобен для микросервисной архитектуры — процесс запускается прямо внутри сервиса, без внешних зависимостей. При этом возможна тесная интеграция с Kafka, REST, базами данных и другими системами.

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

Два типа процессов: потоковые и пакетные

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

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

Такой подход требует высокой параллельности (до 10–15 RPS), устойчивости к ошибкам, быстрой реакции. Иногда в цепочку попадают ручные этапы — например, дополнительная проверка менеджером (примерно в 5% случаев). Потоковые процессы отлично вписываются в event-driven архитектуру и легко масштабируются, особенно при использовании Kafka в качестве шины событий.

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

Такие процессы могут длиться часами, включать десятки этапов и сложную логику обработки ошибок: от откатов до компенсаций и Dead Letter Queue. При проектировании приходится учитывать параллельную обработку батчей, конфликты доступа к источникам, индивидуальные требования к формированию пакетов.Рис. 3 Суть пакетного процесса

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

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

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

Прозрачность и контроль

Одним из плюсов BPMN-систем является возможность мониторинга. Camunda предлагает встроенные инструменты (например, Cockpit), а также легко интегрируется с Prometheus и Grafana. Это позволяет DevOps-команде видеть текущую картину: сколько процессов активны, где возникли ошибки, какие этапы «висят», сколько времени занимают ключевые шаги.

Для бизнеса доступны BI-дэшборды и email-уведомления — можно получать отчеты о «застрявших» задачах, несанкционированных отклонениях и задержках. Все это повышает управляемость и доверие к автоматизации.

Оркестрация микросервисов и ML-модели

Camunda отлично вписывается в современную микросервисную архитектуру. Каждый микросервис выполняет атомарную задачу, а orchestration layer — в виде процесса BPMN — управляет последовательностью. Это снижает связность, упрощает внесение изменений и повышает надёжность.

Дополнительно, процессы могут вызывать внешние ML-сервисы — например, для скоринга, классификации, предсказаний. Camunda не ограничивает формат интеграции: это может быть REST, gRPC, Kafka: зависит от ваших технических предпочтений. Возможна реализация механизма принятия решений на лету, где модель принимает решение, а BPMN описывает, что с этим решением делать дальше.

При использовании Camunda как оркестратора микросервисов уменьшается объём инфраструктурного кода. Сами сервисы становятся проще, потому что они больше не содержат в себе бизнес-процессы — они отвечают только за конкретные атомарные действия.

Появляется возможность быстро добавлять новые задачи без риска нарушить целостность общего процесса. Отладка упрощается, мониторинг становится прозрачным, а время внесения изменений резко сокращается. Это меняет сам подход к разработке: теперь оркестрация выносится в отдельный слой, а не размазывается по коду приложений.

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

Что будет дальше

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

Дальнейшее развитие BPMN-систем сегодня тесно связано с трансформацией архитектурных подходов в сторону событийной (event-driven) и облачной (cloud-native) парадигмы. Это особенно заметно на примере эволюции Camunda, где новая версия Zeebe уже ориентирована именно на такие сценарии. Если классические BPM-движки предполагали более линейное, централизованное исполнение процессов, то современный подход позволяет строить распределенные, масштабируемые пайплайны, реагирующие на события из множества источников — будь то Kafka, REST-вызовы или внутренние системные сигналы.

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

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

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

По данным, опубликованным в журнале Nature Human Behaviour, трёхдневные выходные без снижения зарплаты:

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

«Мы опасались, что люди будут спешить и только сильнее выматываться», — говорит социолог Вэнь Фань из Бостонского колледжа, ведущий автор исследования. — «Но этого не произошло. Напротив, стресс снизился».

Пандемия как триггер перемен

Исследование стало ответом на кризис морального состояния и рост увольнений после пандемии COVID-19. Массовое выгорание, открытые вакансии и переоценка жизненных приоритетов подтолкнули компании к экспериментам с гибким графиком.

В исследовании участвовали 2896 сотрудников. Им дали 8 недель на перестройку процессов: меньше встреч и рутинных задач, больше смысла. За две недели до старта и через полгода участники заполняли опросники: «Насколько работа вас раздражает?» и «Как вы оцениваете своё психическое здоровье?» Ответы показали заметное улучшение всех метрик.

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

Немного критики

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

«Когда люди лучше отдохнули, они совершают меньше ошибок и работают интенсивнее», — говорит Педро Гомеш, экономист из Лондонского университета Биркбек. Однако Гомеш хотел бы увидеть более глубокий анализ влияния на производительность.

Вэнь Фань отмечает, что более 90% компаний решили сохранить четырёхдневную рабочую неделю после окончания эксперимента, что свидетельствует об отсутствии опасений по поводу падения прибыли.

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

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

А что вы думаете о четырёхдневной рабочей неделе? Успевали бы справляться со своими задачами? Если вы — менеджер, то поделитесь, как бы вы отнеслись к такому решению в отношении вашей команды?

Почему работа должна быть прозрачной

Во-первых, повышение «видимости» работы разработчика позволяет лучше отслеживать этапы выполнения проекта: от постановки задачи до её завершения. В Agile и Scrum, например, прозрачность вовсе считается базой: все члены команды видят прогресс каждого сотрудника, вовремя обнаруживают проблемы и устраняют их в моменте.

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

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

Использование инструментов управления задачами и календарей позволяет структурировать рабочий процесс и делиться информацией с коллегами в реальном времени. Trello, Jira, Asana и другие решения для управления проектом помогают визуализировать этапы выполнения задач, распределять ответственность и устанавливать сроки выполнения задач. Это упрощает контроль над проектом и позволяет всем участникам оставаться в курсе происходящего.

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

А использование единого пространства для хранения документации (например, GitHub или Confluence) также способствует повышению видимости: все изменения фиксируются автоматически, что упрощает отслеживание прогресса по проекту.

Почему важно понимать текущие рабочие процессы

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

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

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

Что выбрать для повышения прозрачности работы

Вопрос здесь не столько к разработчику, сколько к руководителям отделов, CTO и CEO. Нужно выбрать систему для совместной работы, которая будет комфортна каждому сотруднику.

Jira

Jira — один из самых популярных инструментов для управления проектами и отслеживания задач, особенно в разработке. С помощью Jira можно планировать спринты, распределять задачи между участниками команды и отслеживать прогресс. Возможность интеграции с другими сервисами делает его одним из наиболее мощных инструментов для команд, которые работают по методологиям Agile и Scrum.

Trello

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

Slack

Slack — основной инструмент для общения в команде; платформа для обмена мгновенными сообщениями, файлами и поддержки групповых чатов. Slack позволяет создавать каналы по отдельным темам или проектам.

Ещё есть Confluence (для «документирования» процессов), GitHub (для управления версиями кода) и всем известный Zoom (для видеоконференций) или его старший брат Skype.

Выбор подходящих инструментов должен основываться на:

1. Совместимости с текущими процессами. Инструменты должны легко интегрироваться с уже существующими системами и подходами к работе в команде.
2. Удобстве использования и обучении. Интерфейс должен быть интуитивно понятным как для новых пользователей, так и для опытных сотрудников, а время на обучение должно быть минимальным.
3. Возможностях масштабирования. Любой инструмент управления проектами должен поддерживать рост команды или проекта без потери производительности и удобства использования.
4. Возможных интеграциях со сторонними сервисами. Подключение других популярных сервисов с системой управления проектами позволяет создать единую экосистему решений для контроля всех аспектов проекта.
5. Безопасности данных. Это должно быть «закрытое» решение, доступ к которому получат только текущие сотрудники проекта.

Шаги для бесшовной интеграции нескольких систем

1. Первый шаг здесь всё тот же — анализ существующих инструментов и понимание их совместимости друг с другом. Важно учитывать, какие системы уже используются командой: системы управления проектами, платформы для контроля версий и коммуникационные инструменты.
2. Второй шаг — это определение API-возможностей каждого инструмента. Практически все современные платформы имеют API-интерфейсы, которые позволяют настраивать интеграцию с другими системами. Разработка скриптов или использования готовых решений передачи данных между системами может значительно сократить время работы вручную.
3. Третий шаг — обучение команды работе с новыми интегрированными инструментами в виде тренингов и формирования регламентов работы. Всё это поможет сотрудникам быстро адаптироваться к изменениям и использовать новые возможности для повышения своей эффективности.

Например, использование Slack в сочетании с GitHub Actions для автоматизации уведомлений о статусе сборки проекта и результатах тестирования позволяет разработчикам оперативно получать информацию о том, на каком этапе находится проект, какие ошибки требуют внимания и как быстро были устранены проблемы.

Ещё один пример: Jira в сочетании Confluence для создания единой системы управления знаниями. Разработчики могут отслеживать прогресс задач в Jira, а в Confluence делиться документацией и отчётами.

Как улучшить взаимодействие с другими сотрудниками

1. Создание подробной документации по проекту даёт возможность каждому члену команды быстро находить необходимую информацию без необходимости отвлекать коллег;
2. Регулярный обмен обратной связью помогает разработчикам понимать, как их работа воспринимается внутри команды и какие области требуют улучшения;
3. Совместное программирование (с другим разработчиком) способствует не только быстрому решению сложных задач, но и передаче знаний между участниками команды.

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

1. 63% совещаний и онлайн-встреч с командой проводятся без предварительного подготовленного плана. Важно указывать все детали: кто будет на встрече, какие вопросы должны решиться по окончанию встречи, время созвона, темы для обсуждения.
2. Справочные материалы, как и план встречи, нужно отправлять заранее. Все ссылки, доступы, скрины и скринкасты, вопросы — всё это должно быть отправлено до встречи, а не во время.
3. Важно следить за таймингом и не уходить от заданной темы. Нужно обсудить что-то ещё с другим сотрудником? Запланируйте отдельную встречу, чтобы не тратить время всех членов команды одновременно.

Отслеживание прогресса и достижений

Метрики важны для измерения продуктивности и выявления областей для улучшения. Сюда относятся:

• Скорость (Velocity) показывает скорость выполнения задач командой за определённый промежуток времени. Она помогает оценить темп работы и планировать будущие спринты.
• Cycle Time — время от начала работы над задачей до её завершения позволяет понять, насколько быстро команда может адаптироваться к изменениям.
• Метрики кода — сюда относятся такие показатели, как количество ошибок или покрытие кода тестами. Эти показатели помогают отслеживать качество выпускаемого продукта.

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

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

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

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

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

Эта статья пригодится разработчикам, которые, как и мы когда-то, задумываются об ИБ в продуктах и не знают, с чего начать.

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

Как мы проверяли безопасность разработки в компании

Логичен вопрос, зачем вообще внедрять систему разработки безопасного ПО в компании? Регуляторы требуют — это понятно. Но есть ли другие, более насущные предпосылки? Разумеется:

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

Я пришел в Tada в конце 2022 года. На тот момент о безопасной разработке ПО (БРПО) в ней «слышали, но не погружались». Поэтому для начала мне нужно было понять:

1. Какие меры уже реализованы и насколько хорошо?
2. Действительно ли продукт безопасно разработан, и какие уязвимости, недочеты есть в ПО и в инфраструктуре разработки?

Поскольку у меня уже был опыт прохождения сертификационных испытаний по требованиям ФСТЭК России к уровням доверия (одно из требований – наличие у разработчика-изготовителя процедур БРПО и проведение анализа уязвимостей и недекларированных возможностей), я понимал, какие процедуры, меры и инструментальные виды анализа должны быть реализованы.

Кроме того, можно и нужно воспользоваться документами, которые помогают облегчить внедрение процедур разработки безопасного ПО:

• ГОСТ 56939-2016;
• Методика выявления уязвимостей и недекларированных возможностей в ПО ФСТЭК России (чтобы сертифицировать продукт).

И иными источниками: данными с конференций, презентациями компаний, в которых они делятся опытом (ТБ Форум, Kaspersky Certification Day и др.)

Дисклеймер: мы не претендуем на звание гуру MegaNanoExpertDevSecOpsGeneral и цель статьи не пытаться научить, а поделиться нашим опытом, который, возможно, окажется полезен тем, кто находится в начале ИБ-пути.

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

• недостаточная аутентификация и авторизация;
• уязвимости ввода данных;
• утечка конфиденциальных данных;
• недостаточная обработка ошибок и другие.

Что касается оценки безопасности продукта, мы решили провести:

1. Статический анализ исходного кода.
2. Ручное тестирование (что-то типа функционального), чтобы выявить реальные баги в функциях ИБ ПО.
3. Анализ уязвимостей заимствованных компонентов и компонент среды функционирования ПО.
4. Динамический анализ и тестирование на проникновение.

Для этого мы выбрали следующие инструменты:

Результаты анализа оказались довольно интересными и местами даже неожиданными. Мы выявили около 200 critical и major (статический анализ) и 90 critical и high (анализ заимствованных компонент, динамический анализ и пентест).

Уязвимостей было много, и вот несколько наиболее интересных примеров:

1. Неправильная конфигурация turn-сервера

Для обеспечения обмена трафиком (видео/голос) мы используем turn-сервер. В ходе анализа мы выявили реквизиты доступа в открытом виде в файле features.json.

Что могло случиться? Злоумышленник мог построить socks-прокси (из-за неправильной конфигурации turn-сервера). В нашем случае сервер не проверяет, что адрес, по которому нужно подключиться, находится в локальной сети. Таким образом злоумышленник смог бы получить доступ ко внутренним ресурсам.

2. Хранимая XSS

Хранимая XSS (англ. Stored XSS) – это тип атаки на веб-приложение, при котором злоумышленник вводит вредоносный код (обычно JavaScript) на страницу веб-приложения, который сохраняется на сервере и затем отображается на странице для всех пользователей, которые обращаются к этой странице.

Здесь все просто: Cookie защищены флагом httponly от перехвата с помощью XSS. Однако злоумышленник может воспользоваться этой уязвимостью для переадресации пользователей на фейковый домен, чтобы получить учетные данные.

Достаточно вставить следующий payload XSS в некоторые формы ввода ПО, сгенерировать ссылку – приглашение и отправить жертве: \"--><img src=x onerror=alert("XSS")>.

При переходе по ссылке-приглашению устанавливается cookieinvitation_token. Затем ПО проверяет ее на наличие этого cookie. Если оно существует, то переадресовывает пользователя в асинхронном режиме независимо от того, где в веб-приложении находится пользователь. Это позволяет внедрять вредоносный скрипт в любом чате и месте веб-приложения с целью перехвата нажатий клавиш (кейлоггер).

Эти и другие уязвимости дали нам понять, что:

• необходимо внедрять БРПО на раннем этапе разработки;
• важно регулярно анализировать и обновлять уже имеющееся ПО и контролировать заимствованные компоненты.

Чтобы устранить эти уязвимости и обеспечить безопасность нашего ПО, необходимо было принять соответствующие меры: исправить код, обновить зависимые компоненты, изменить архитектуру ПО.

Что мы сделали по итогам проверки

Поиск и устранение недостатков и уязвимостей в ПО – это малая и далеко не самая приоритетная часть на раннем этапе внедрения разработки безопасного ПО.

Главная задача – заинтересовать команду и бизнес в необходимости такой разработки, чтобы все участники двигались в одном направлении и стремились сделать продукт безопаснее. И не появились те, кто пытается плыть против течения.

Как это прошло у нас

Отмечу, что руководство компании изначально было заинтересовано в сертификации продукта. А это возможно только в случае корректно внедренных мер БРПО. Нам оставалось только показать и доказать эту причинно-следственную связь.

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

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

Затем мы провели цикл лекций для всей команды:

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

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

Так у нас появился приоритизированный список уязвимостей и задачи, связанные с устранением этих уязвимостей. Для устранения некоторых из них потребовалось переписать почти половину кодовой базы (это еще один из поводов внедрять безопасную разработку на раннем этапе) — очень много времени ушло на правки, переконфигурирование компонентов среды функционирования.

Что будем делать дальше

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

Обучаемся и внедряем процедуры проведения фаззинг-тестирования

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

Изучаем порядок и способ определения поверхности атаки, включая использование Natch

Natch — полезный инструмент для определения поверхности атаки от наших коллег ИСП РАН.

Поверхности атаки — это интерфейсы и их модули в ПО, при использовании которых могут быть реализованы угрозы безопасности.

Разрабатываем метрики и сценарии реагирования на инциденты ИБ

Гарантировать 100% защищенности нельзя, всегда нужно быть готовым оперативно и правильно реагировать на инциденты ИБ.

Планируем полностью автоматизировать инструментальные виды анализа

Состав используемых инструментов и видов анализа достаточно объемный и нет необходимости руками делать рутинную работу, которую можно автоматизировать и внедрить в процессы жизненного цикла ПО.

Планируем сократить кодовую базу и базу зависимостей

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

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

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

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

Давайте представим, что вы задумались о смене методолигии и перевезти команду с фреймворка Scrum на метод Kanban.

Для начала обсудим, какие есть преимущества у Scrum перед Kanban.

Обе методологии, Scrum и Kanban, имеют свои преимущества и недостатки, и выбор между ними зависит от конкретных потребностей команды и характера проекта. Вот некоторые минусы Kanban по сравнению с Scrum.

Минусы Kanban по сравнению с Scrum

Отсутствие структуры итераций

Одним из основных отличий между Scrum и Kanban является отсутствие фиксированных итераций в Kanban. Это может привести к менее четкому планированию и более сложному прогнозированию времени завершения работ.

Неясность в отношении времени выполнения задач

Поскольку Kanban не имеет фиксированных сроков (как у Scrum-спринтов), предсказание времени выполнения конкретных задач может быть сложным. Это может создавать проблемы при необходимости предоставить оценки сроков.

Большая свобода может привести к недисциплинированности

Отсутствие строгой структуры итераций может привести к тому, что команда столкнется с проблемами в управлении временем и приоритетами. Команде может не хватать дисциплины и структуры, что Scrum обеспечивает.

Менее явное планирование

Scrum предоставляет четкий итеративный процесс с фиксированными спринтами и запланированными моментами обзора. В Kanban планирование менее формализовано, что может вызывать сложности в управлении и предсказании хода проекта.

Ограниченный фокус на улучшении

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

Неясность в отношении приоритетов

Scrum обеспечивает четкую иерархию задач в рамках спринта, где продуктовый владелец определяет приоритеты. В Kanban менее ясно, какие задачи более приоритетны, что может привести к путанице в распределении ресурсов.

Трудности в управлении большими проектами

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

Теперь давайте посмотрим, когда вообще есть смысл перехода на Kanban после работы по Scrum.

Зачем переходить на Kanban после Scrum

Гибкость в управлении задачами

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

Постоянная потребность в поставке продукта

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

Низкая предсказуемость итераций

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

Необходимость визуализации рабочего процесса

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

Работа с техническим долгом

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

Команды поддержки и обслуживания

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

Предпочтение непрерывной оптимизации

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

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

Шаги, которые могут помочь вам перейти от Scrum к Kanban

Понимание основных принципов Kanban

Канбан ориентирован на непрерывное потоковое производство, в отличие от итеративной модели Scrum.

Основной акцент в Kanban делается на визуализации рабочего процесса и ограничении рабочего объема (WIP – Work in Progress).

В отличие от Scrum, в Kanban нет фиксированных итераций (спринтов), и задачи могут быть добавлены или удалены в любое время.

Визуализация рабочего процесса

Создайте доску Kanban, на которой будут отображены все задачи вашей команды.

Разделите доску на столбцы, представляющие различные этапы рабочего процесса (например, “В ожидании”, “В процессе”, “Готово”).

Установка лимитов WIP

Определите максимальное количество задач, которые ваша команда может обрабатывать одновременно на каждом этапе процесса.

Установите лимиты WIP для каждого столбца на доске.

Анализ и оптимизация

Регулярно проводите обзоры и анализируйте процесс работы.

Используйте данные Kanban для выявления узких мест и оптимизации потока работы.

Постепенное внедрение изменений

Переходите постепенно, пошагово, чтобы смягчить процесс адаптации для команды.

Поддерживайте команду и обучайте их новым аспектам Kanban.

Контроль и улучшение

Внедряйте изменения на основе обратной связи и опыта команды.

Контролируйте процесс, чтобы гарантировать его эффективность.

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

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

Давайте на примере прошлой статьи попросим этот AI сделать нам быстрый расчет.

Дальше я привожу пример общения с ChatGPT.

Мой запрос:

Ответ ChatGPT:

Как вы видите, мы не получили ответ. Но ChatGPT сам подсказал, как нужно вычислить результат.

Меняем запрос.

Мой запрос:

Ответ ChatGPT:

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

Дальше приложу скриншоты запросов и ответов:

Наконец-то мы получили точную сумму стандартного отклонения, поменяв формулировки наших запросы.

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

Применяя концепции и методологии, зародившиеся в теории вероятностей и статистическом анализе, давайте попробуем понять, как нормальное распределение (также известное как распределение Гаусса) может быть использовано для моделирования и анализа производительности разработки (velocity) в методологиях Agile и Scrum, а конкретно – предположить результат, который команда сможет получить в будущем. Но так же понять, является ли полученный результат нормой или есть отклонения, на которые команда должна реагировать.

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

Для наших изысканий возьмем реальные данные из одного моего реального проекта и его реальных результатов.

У нас имеется результаты последних спринтов в Story Points:

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

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

Для начала представим наши результаты в таблице и на графике:

1. Спринт 1 – 75.
2. Спринт 2 – 40.
3. Спринт 3 – 68.
4. Спринт 4 – 60.
5. Спринт 5 – 94.
6. Спринт 6 – 71.
7. Спринт 7 – 55.
8. Спринт 8 – 101.
9. Спринт 9 – 74.
10. Спринт 10 – 13.
11. Спринт 11 – 183.

При анализе данных, особенно если они содержат экстремальные значения (как, например, 13 или 183 в вашем наборе данных), важно рассмотреть, не являются ли эти точки выбросами, вызванными необычными обстоятельствами, и не должны ли они быть исключены из анализа.

Для расчета стандартного отклонения без учета экстремальных значений, нам нужно сначала идентифицировать, какие значения можно считать экстремальными. В контексте вашего набора данных, значения, такие как “13” и “183”, кажутся аномально низким и высоким соответственно. Давайте исключим их из наших расчетов.

Далее нам нужно пересчитать среднее значение без учета этих экстремальных значений. У нас есть следующие значения: 75, 40, 68, 60, 94, 71, 55, 101, 74 (исключены “13” и “183”).

Подсчитаем среднее:

Теперь вычислим квадраты отклонений от среднего и найдем их сумму:

Проведем подсчет:

Таким образом, сумма квадратов отклонений для данного набора данных (исключая экстремальные значения) составляет примерно 2801.17.

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

Из предыдущих расчетов у нас есть:

• Сумма квадратов отклонений: 2801.17.
• Количество наблюдений (N): 9 (поскольку мы исключили два экстремальных значения).

Таким образом, дисперсия для данного набора данных составляет примерно 311.24.

Стандартное отклонение является мерой разброса значений относительно среднего значения (математического ожидания) и вычисляется как квадратный корень из дисперсии. Таким образом, стандартное отклонение для вашего набора данных составляет примерно 17.64. Это значит, что в среднем значения отклоняются от среднего (70.89) на 17.64 единицы.

Теперь давайте сделаем наложим тренд (красная линия) на наш график с учетом всех спринтов и попытаемся предсказать результат следующего спринта

Выходит мы можем ожидать результатом следующего спринта примерно 102 SP. Давайте учетом того, что стандартное отклонение для вашего набора данных составляет примерно 17.64 наш нормальный результат, округленный до целых SP, который будет в пределах нормы составит 84-120 SP.

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

Рассмотрим, как метрики Lead Time, Cycle Time, Velocity, Flow Efficiency и Test Coverage могут быть использованы для повышения эффективности вашей команды разработки.

Lead Time и Cycle Time для повышения эффективности команды разработки

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

Cycle Time, или время на доставку, — это метрика, показывающая, сколько времени требуется для прохождения задачи от начала работы над ней и до её завершения.

Внимательное отслеживание и оптимизация Lead Time и Cycle Time может привести к заметному улучшению производительности команды разработки.

1. Выявление проблемных мест

Измеряя Lead Time и Cycle Time, команда может выявить узкие места и задержки в процессе разработки. Например, если задачи часто “зависают” на этапе тестирования или проверки кода, это может указывать на нехватку ресурсов или проблемы в самом процессе.

2. Оптимизация рабочего процесса

Понимание того, каков обычный Lead Time и Cycle Timeдля задач, позволяет командам внедрять изменения в рабочий процесс. Это может включать в себя:

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

3. Приоритизация задач

Если команда знает свой средний Lead Time и Cycle Time, она может лучше управлять ожиданиями стейкхолдеров и более точно прогнозировать сроки выполнения задач.

Это также может помочь в приоритизации задач: срочные задачи могут быть поставлены в начало очереди, чтобы минимизировать общий Lead Time.

4. Улучшение обратной связи

Сокращение Lead Time и Cycle Time часто означает, что пользователи или стейкхолдеры быстрее получают результаты работы команды. Это ускоряет получение обратной связи и позволяет команде быстрее адаптироваться к изменяющимся требованиям или условиям рынка.

5. Мотивация команды

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

Метрика Lead Time и Cycle Time — это не просто показатель времени, которое требуется для выполнения задачи. Это инструмент для анализа и оптимизации рабочего процесса, который, при правильном использовании, может стать ключом к повышению эффективности команды разработки.

Velocity для повышения эффективности команды разработки

Velocity, или скорость, представляет собой метрику, которая показывает, сколько единиц работы (чаще всего “сторипоинтов” или “задач”) команда завершила за определённый временной интервал, например, за спринт в Scrum. Используя метрику Velocity, команды могут не только измерять свою производительность, но и находить способы её оптимизации.

1. Предсказуемость и планирование

Используя исторические данные по Velocity, команды могут лучше прогнозировать, сколько задач они смогут завершить в следующем спринте. Это позволяет более реалистично планировать объём работы и управлять ожиданиями стейкхолдеров.

2. Выявление проблем

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

3. Рефлексия и улучшение

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

4. Оптимизация процессов

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

5. Мотивация

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

6. Управление ресурсами

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

Хотя метрика Velocity является мощным инструментом для мониторинга производительности команды, важно помнить о её ограничениях. Она должна использоваться в сочетании с другими метриками и практиками, чтобы получить полное представление о состоянии проекта и производительности команды.

Flow Efficiency для повышения эффективности команды разработки

Flow Efficiency (эффективность потока) – это метрика, которая показывает, какая часть времени задачи действительно затрачивается на активную работу, в сравнении с общим временем, проведенным в системе. Измеряется как процент активной работы от общего времени Lead Time.

Допустим, задача провела в системе 100 часов, из которых на активную работу ушло 25 часов. Эффективность потока составит 25%.

Рассмотрим, как с помощью этой метрики можно повысить эффективность команды разработки:

1. Выявление "мёртвого времени"

С помощью Flow Efficiency команды могут точно определить, сколько времени задачи “провисают” в ожидании. Это может быть время ожидания ревью, автоматизированного тестирования, утверждения от клиента и т.д. Понимание этого позволяет сосредоточить усилия на устранении простоя.

2. Оптимизация процессов

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

3. Улучшение планирования

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

4. Фокус на узкие места

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

5. Улучшение коммуникации

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

Метрика Flow Efficiency – это мощный инструмент для анализа производительности команды. Она позволяет не только выявить “болевые точки” в процессе разработки, но и предоставляет конкретные данные для оптимизации рабочих процессов. Однако, как и любая метрика, эффективность потока должна рассматриваться в контексте и использоваться совместно с другими метриками для получения полного представления о производительности команды.

Test Coverage для повышения эффективности команды разработки

Test Coverage (покрытие тестами) — это метрика, которая показывает, какая часть кода программы была проверена тестами. Обычно выражается в процентах. Хотя высокий уровень покрытия тестами не гарантирует отсутствия ошибок, он может служить индикатором того, насколько хорошо код проверен.

1. Выявление непроверенных участков кода

Одно из основных преимуществ метрики Test Coverage — возможность быстро определить, какие части кода ещё не покрыты тестами. Это может подсказать команде, где потенциально могут скрываться ошибки, и направить усилия на дополнительное тестирование.

2. Улучшение качества кода

При написании тестов разработчики часто находят и исправляют ошибки ещё до того, как код попадёт в продакшен. Таким образом, улучшая покрытие тестами, команда автоматически повышает качество своего кода.

3. Уверенность в изменениях

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

4. Быстрое выявление ошибок

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

5. Оптимизация усилий по тестированию

Понимание того, какие части кода хорошо покрыты тестами, позволяет команде эффективнее распределять усилия. Вместо написания избыточных тестов на уже покрытые участки, можно сосредоточиться на “слабых местах”.

6. Документация и понимание кода

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

Хотя метрика Test Coverage является полезным инструментом для повышения эффективности команды разработки, важно не увлекаться ею слепо. Стремление к 100% покрытию может быть неоправданно затратным и не всегда целесообразным. Важнее сосредоточиться на покрытии ключевых, критичных и сложных участков кода, а также убедиться, что тесты действительно качественные и проверяют различные сценарии работы программы.

Заключение

Эффективность команды разработки — сложный и многогранный аспект, который зависит от множества факторов. Метрики, такие как Lead Time, Velocity, Flow Efficiency, Test Coverage и другие, предоставляют инструменты для измерения, мониторинга и оптимизации процессов разработки. Каждая из этих метрик дает уникальный взгляд на различные аспекты работы команды:

• Lead Time позволяет понять, как быстро команда откликается на требования и доставляет результаты.
• Velocity отражает производительность команды и помогает в планировании будущих итераций.
• Flow Efficiency акцентирует внимание на “болевых точках” в рабочем процессе, выявляя простои и зоны ожидания.
• Test Coverage показывает, насколько хорошо код проверен тестами, что напрямую влияет на качество продукта.

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

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

Зачем нужны отчёты

Зачем менеджеру составлять какой-то отчёт об ошибке и тратить на него своё время, а не просто написать о проблеме?

Дело в том, что исправление ошибки напрямую зависит от того, кто с ней пришёл, и насколько эффективно он про неё сообщит. Если отчёт описан максимально корректно, то и шансы на исправление ошибки становятся больше, а времени, соответственно, меньше.

Посмотрим на примере: допустим, наш продукт успешно работает, и ничего не предвещало беды, как вдруг вылез баг.

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

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

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

Пример того, как зачастую происходит коммуникация между разработчиками и менеджерами при неотлаженных процессах:

Эй, разработчик, у нас не работает кнопка для формирования отчета!

В таком случае команда разработки выделяет ресурсы на анализ ситуации и действует по алгоритму:

1. Проверяет работу кнопки, пытаясь опытным путём повторить ошибку.
2. Находит ошибку, описывает спецификацию, оценивает сроки.
3. Ошибка берется в работу.

Когда ошибка пойдет в работу, зависит от её сложности, приоритета и того, как она влияет на работу продукта.

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

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

Чтобы избежать никому не нужной затяжки исправлений или хотя бы сократить это время, необходимо выстроить между разработчиками и менеджерами систему отчётности по ошибкам.

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

Рекомендации написания отчёта об ошибке

1. Воспроизведение: прежде чем передать ошибку в разработку, убедиться, что она повторяется, желательно несколько раз. Воспроизвести процесс и описать действия шаг за шагом.
2. Проверка на существование: перед созданием отчёта поищите в бэклоге. Возможно, кто-то уже нашел ошибку, и разработчики уже знают о ней.
3. Краткое описание: минимум слов, только по делу. Одна проблема, один отчёт. По краткому описанию удобно вести навигацию среди большого бэклога.
4. Полное описание: описать ошибку и путь её достижения. Чем подробнее будет описан путь, тем легче будет повторить ошибку, найти и исправить.
5. Окружение: ОС, браузер, устройство, иные технические моменты, которые могли повлиять на баг (VPN, режим Инкогнито, Adblock и прочее).
6. Вместо тысячи слов: приложить к отчёту скриншоты или запись с экрана. Зачастую такая информация содержит больше полезной информации, нежели текстовое описание.
7. Ожидание и результат: описать, как все должно работать, какое поведение и результат были получены, какой ожидаемый результат и путь к нему.
8. Место происшествия: указать источник ошибки. Если это веб-приложение, указать полный url. Если иное, указать окно\вкладку и т.д.
9. Журналы ошибок: любые локальные логи помогут быстрее разобраться в ошибке. Сообщения в консоли браузера, ошибки в системе, любые alert’ы.
10. Приоритет: указать, насколько ошибка влияет на работу продукта. Исходя из приоритета, команда разработки сможет принять решение, как быстро приступить к её исправлению.

Плохой пример:

• Не могу подписаться на тег.
• Нужно срочно починить.

Хороший пример:

• Убедился несколько раз в ошибке, смог повторить.
• В беклоге не нашел ничего похожего, можно создавать.
• Не могу подписаться на тег java.
• Залогинен, открываю любую статью с тегом java, кликаю на тег для подписки, но ничего не происходит. При этом на остальные теги могу подписаться без ошибок.
• ОС linux mint, Google Chrome Версия 112.0.5615.165 (Официальная сборка), (64 бит), Адблок был и включен, и выключен.
• Скриншот или видео.
• Ожидаю, что после клика смогу подписаться на тег java и получать уведомления о выходе новых постов на сайте с этим тегом.
• Статья с тегом java.
• Failed to load resource: the server responded with a status of 404 ()
• Баг очень важный, его нужно сделать вчера.

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

Поделитесь, как вы проводите обработку ошибок в своей команде.

Чтобы пообщаться с 80 сотрудниками, руководителю отдела тестирования нужно 40 часов

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

Раньше, когда в команде тестировщиков было пять человек, на такие встречи уходило 2,5 часа. Но теперь, когда отдел вырос до 80 человек, чтобы поговорить с каждым, руководителю нужно потратить 40 часов. А это целая рабочая неделя.

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

Кто такие кураторы в отделе тестирования и чем они занимаются

Руководитель передаёт часть своих полномочий тестировщикам с лидерскими качествами — они становятся кураторами. Куратор — это старший или ведущий сотрудник отдела, который сопровождает тестировщиков из продуктовых команд:

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

Кураторы у нас, как правило, из смежных продуктовых команд. Мы уже рассказывали об этом подробно.

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

Какие метрики мы собираем

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

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

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

В каждой продуктовой команде стали собирать такие метрики:

• Testing Speed (TS) — отношение количества протестированных задач к количеству задач, переданных в тестирование за один спринт. Считается по формуле:

TS = Count (протестированные задачи) / Count (задачи, переданные в тестирование)

• Tasks Without Testing (TWT) — задачи без тестирования, когда разработчик перетаскивает таск на продакшн в обход тестирования, что повышает риск багов на проде.
• Production Found Defects (PFD) — инциденты на проде, когда пользователи сами находят баги в продуктах и приносят их в техподдержку.
• Integration Found Defects (IFD) — дефекты, которые нашли на этапе приёмочного тестирования релиза автотестами. Тут выделили ещё три дополнительные метрики:

• Test-cases — количество тест-кейсов;
• Autotests — количество автотестов;
• Coverage — отношение Autotests к Test-cases.

• Test Duration (TD) — среднее время тестирования задач. Посчитать его можно по формуле:

Общее время, которое все задачи провели в тестировании / Общее количество задач

Для всех метрик мы сделали цветовую индикацию — светофор.

Значение цветов:

• Зелёный — всё хорошо.
• Жёлтый — скоро всё будет плохо, но пока нормально.
• Красный — уже вчера пора было вмешаться.

Мы определили для себя, что если на тестирование одной фичи уходит меньше двух дней, то это нас устраивает. Если средний показатель метрики Test Duration не выходит за эти рамки, значит, в команде со временем тестирования всё хорошо, Time to Market не страдает и все довольны скоростью.

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

Первые результаты команды тестирования после внедрения светофора

Для каждой продуктовой команды мы сделали такую таблицу:

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

Как мы проработали красные зоны

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

В итоге мы улучшили скорость тестирования в отделе, и метрики позеленели:

Но ещё было над чем работать.

Почему мы пересмотрели метрики: убрали одни и добавили другие

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

Мы убрали метрики, которые не давали нам полезной информации. Это Testing Speed и Tasks Without Testing. Вместо них мы добавили другие, на которые ориентируемся до сих пор:

• Unstable Tests (UT) — количество нестабильных автотестов (тех, у которых Success Rate за две недели был ниже 70%).
• Bad Tests (BT) — «плохие» автотесты, то есть те, которые три раза за месяц требовали ручного вмешательства на этапе приёмочного тестирования релиза автотестами. Такие автотесты сильно снижают Time To Market, за который мы боремся.
• Skipped Autotests (SA) — количество заблокированных автотестов, тех, которые по каким-то причинам не могут пройти приёмочное тестирование релиза из-за отключенных бизнес-процессов, багов в системе, неготовой инфраструктуры или из-за кода самого автотеста.

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

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

• С какой целью мы её добавляем?
• Что планируем делать, если она будет красной?
• Нет ли другой похожей метрики, которая будет дублировать информацию?

И так далее. Также не забывайте собирать обратную связь от пользователей этих метрик.

Метрики подсвечивают проблемы в отделе, но не показывают их причину и не подсказывают решение

Рассмотрим один из кейсов по работе с метриками в тестировании. Вот метрики одной из QA-команд за восемь спринтов. Очерёдность спринтов считаем сверху вниз:

В первом спринте года, с 7 по 20 января, значение метрики зелёное. Это значит, что всё было хорошо — задачи тестировали быстро.

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

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

Как мы автоматизировали процесс сбора метрик

Когда мы запустили метрики в отделе тестирования, кураторы команд вручную собирали их по фильтрам из Jira и TMS и складывали в Confluence в таблицу. Через какое-то время, когда процесс устоялся и все к нему привыкли, мы решили его автоматизировать.

Сначала автоматизация была очень простой: мы подняли бэкенд-сервис и сделали один обработчик. При его вызове сервис шёл в Jira, обрабатывал данные и отдавал их в виде JSON. Куратор каждой команды раз в спринт открывал Postman, вызывал обработчик и перекладывал данные с JSON в Confluence.

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

Казалось бы: всё отлично, метрики собираем автоматически, их можно в любой момент посмотреть. Но была проблема — Confluence не покрывал все наши потребности.

Например, было сложно сравнивать несколько команд друг с другом. А когда данных накапливалось много, страницы долго загружались и тормозили. Мы подумали, что надо сделать свою визуализацию, потому что график в Confluence из коробки выглядел вот так:

У нас уже был опыт написания фронтенда в отделе тестирования, поэтому к готовому бэкенду прикрутили самописный UI, подобрав библиотеку для построения графиков. Новый сервис мы назвали Metric Reporter.

И наши метрики стали выглядеть так:

Через какое-то время мы с дизайнерами переработали внешний вид нового UI и добавили недостающую функциональность.

Мы подумали, что неплохо было бы работать с командой над метриками прямо в интерфейсе, поэтому добавили возможность комментировать отдельные метрики и спринты. Также добавили общие метрики по отделу из различных специализированных команд QA.

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

Почему самописный инструмент

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

• Grafana не покрывала все наши задачи. Например, там нет возможности комментировать.

• Cрок хранения данных в Grafana ограничен по времени, а нам нужно смотреть метрики с учётом длительных сроков.

• Своё решение легко кастомизировать под любые потребности. Особенно когда процессы постоянно развиваются и меняются.

Подведём итоги

Какие возможности дали нам метрики:

• Объективно оценивать, что происходит в командах.
• Своевременно выявлять и решать проблемы внутри отдела.
• Выявлять зависимости. Например, если сравнивать метрики год к году, то видно, как возрастает нагрузка на тестировщиков перед новым годом, когда команды хотят закрыть свои квартальные планы в срок.
• Следить за изменениями и трендами, например за внедрением новых процессов или технологий.
• Находить точки роста. Одни метрики зеленеют после того, как мы над ними поработали, мы пересматриваем их, выделяем другие. Находим новые проблемы и решаем их.
• Распределять ресурс тестирования по командам.

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

• Выполнять задачи.
• Мониторить процесс тестирования и визуально определять тот самый баланс между качеством и количеством.
• Улучшать процессы в отделе QA.

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

Как начать собирать метрики

1. Выявите проблему, которую хотите мониторить.
2. Соберите показатели, которые хотите считать.
3. Разработайте формулу подсчёта и индикаторы для светофора.
4. Поработайте с коллективом, продайте идею, что внедрить метрики — это круто.
5. Получите и проанализируйте результаты.
6. Проработайте красные зоны.
7. Ищите новые точки роста — постоянно актуализируйте метрики.

Чтобы начать собирать метрики, не обязательно создавать сложную автоматизацию или пилить свои сервисы. Можно использовать любой инструмент, который умеет строить графики и таблицы. Начните с элементарного Excel или с Google-таблиц — через какое-то время вы точно заметите, что процесс тестирования улучшился.

Автор статьи — Юрий Недре, ведущий менеджер проектов компании Самокат.

1. Цикл разработки (Lead Time)

Цикл разработки, или Lead Time, представляет собой общее время, которое проходит от момента возникновения идеи или получения требования до момента, когда продукт или функционал готов к использованию конечными пользователями. Данная метрика позволяет понять, насколько быстро команда может реагировать на изменения и реализовывать нововведения.

Как считать Lead Time

Определение начала и конца цикла.

Начало: момент, когда требование или идея была впервые записана или зарегистрирована.

Конец: момент, когда функционал полностью тестирован, документирован и готов к доставке пользователю.

Трекинг времени

Используйте системы учета задач (например, Jira, Trello или другие) для отслеживания времени прохождения задачи по различным стадиям.

Учет всех этапов

Включите в расчет все этапы разработки:

1. Анализ требований;
2. Проектирование;
3. Кодирование;
4. Тестирование;
5. Ревью;
6. Деплой.

Сбор и анализ данных

Соберите данные по множеству задач или функциональных блоков для получения среднего значения Lead Time. Это позволит увидеть общую динамику и исключить аномалии.

Постоянный мониторинг

Цикл разработки может меняться из-за внедрения новых процессов, изменения состава команды и других факторов. Поэтому рекомендуется регулярно контролировать и анализировать Lead Time.

Как использовать Lead Time для повышения эффективности

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

Оптимизация процессов

Сокращение времени на определенные операции или автоматизация рутинных задач может значительно сократить Lead Time.

Lead Time — это важная метрика, которая помогает командам разработки оценить и улучшить свою эффективность. Тем не менее, следует помнить, что качество продукта не должно страдать ради сокращения времени разработки.

2. Время на доставку (Cycle Time)

Cycle Time, или время на доставку, — это метрика, показывающая, сколько времени требуется для прохождения задачи от начала работы над ней и до её завершения. Это время, в течение которого задача активно обрабатывается, исключая время ожидания или простоя. Он очень схожа с Lead Time, но несет другой смысл.

tОпределение: Cycle Time начинает отсчет с момента, когда команда начинает активную работу над задачей, и заканчивается, когда задача завершена.

tЧто измеряет: Эта метрика фокусируется на времени, которое команде действительно требуется для выполнения работы, без учета времени ожидания перед началом работы.

tФормула:

тогда как

Пример: Представьте, что у вас есть задача по разработке нового функционала. Задача была создана 1-го числа, но команда начала работать над ней только 3-го числа и завершила 5-го числа. Тогда Lead Time составит 5 дней (с 1-го по 5-е), а Cycle Time — 3 дня (с 3-го по 5-е).

Используя эти две метрики, организации могут определить, сколько времени требуется для выполнения работы и где возникают задержки или “бутылочные горлышки” в процессе. Например, большой разрыв между Lead Time и Cycle Time может указывать на проблемы с приоритетами или процессами, которые приводят к длительным периодам ожидания перед началом работы над задачами.

3. Производительность (Velocity)

Velocity (или “скорость” на русском) — это ключевая метрика в методологиях Agile и Scrum, которая позволяет оценить производительность команды разработки. Она измеряется в “баллах” или “единицах работы”, и отражает объем работы, выполненной командой за одну итерацию (спринт).

Оценка задач

Перед началом спринта команда оценивает сложность каждой задачи в баллах (Story Point), используя, например, систему Fibonacci (1, 2, 3, 5, 8, 13 и т.д.) или любую другую систему оценки. Эти баллы отражают сложность и объем работы, а не конкретное количество времени.

Реализация задач

В течение спринта команда работает над задачами.

Подсчет выполненных задач

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

Анализ данных

Производительность команды за спринт равна сумме баллов всех завершенных задач. Например, если команда завершила задачи на 5, 8 и 13 баллов, их Velocity для этого спринта составит 26.

Усреднение

Чтобы получить более стабильное и предсказуемое значение Velocity, можно усреднить результаты за последние 3-5 спринтов. Это помогает сгладить возможные выбросы и аномалии.

Прогнозирование

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

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

Улучшение процессов

Регулярный анализ Velocity может помочь выявить потребность в оптимизации рабочих процессов или корректировке практик команды.

Velocity — это полезная метрика для команд, работающих по методологии Scrum или Agile, которая помогает контролировать производительность и планировать будущую работу. Однако важно использовать её с умом и не делать единственным критерием успешности, так как качество продукта и удовлетворенность команды также имеют большое значение.

4. Flow Efficiency

Flow Efficiency — это метрика, которая используется для измерения эффективности рабочего процесса, показывая, какая часть времени рабочего процесса действительно тратится на добавление ценности к задаче (активная работа) по сравнению с тем временем, когда задача просто ждёт обработки (пассивное ожидание).

Чтобы рассчитать Flow Efficiency, следует выполнить следующие шаги.

Соберите данные о времени

1. Время активной работы (W) — общее время, затраченное на фактическое выполнение задачи. Это может включать в себя кодирование, ревью кода, тестирование и так далее.
2. Общее время прохождения (T) — это общее время, за которое задача прошла от начала до конца рабочего процесса, включая время активной работы и время ожидания.

Рассчитайте Flow Efficiency с помощью следующей формулы

Интерпретация

1. Если Flow Efficiency равна 100%, это означает, что задача всё время находилась в активной обработке, и не было времени ожидания. Это идеальный, но практически недостижимый сценарий.
2. Если Flow Efficiency низкая (например, 20%), это может указывать на большие периоды ожидания или простоя в рабочем процессе, что стоит рассмотреть и попробовать оптимизировать.

Пример: Если задача провела в системе 10 дней (240 часов), из которых на активную работу ушло 48 часов, тогда Flow Efficiency составит (48/240)*100 = 20%.

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

5. Test Coverage (покрытие тестами)

Test Coverage — это метрика, которая показывает, какая часть кода приложения покрывается автоматическими тестами. Эта метрика часто используется в разработке программного обеспечения для того, чтобы определить степень “защищенности” кода от регрессии и для выявления областей кода, которые могут нуждаться в дополнительных тестах.

Для расчета Test Coverage следуйте следующим шагам.

Используйте инструменты для измерения покрытия

Большинство современных языков программирования и фреймворков имеют инструменты или библиотеки для измерения покрытия тестами, такие как:

1. Java: JaCoCo, Cobertura;
2. JavaScript: Istanbul, Jest;
3. Python: coverage.py;
4. C#: dotCover, OpenCover;
5. Ruby: SimpleCov;
6. и другие.

Запустите тесты с инструментом покрытия

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

Анализируйте результаты

После выполнения тестов инструмент предоставит отчет о покрытии, который покажет:

1. Общий процент покрытия кода.
2. Покрытие по отдельным файлам или модулям.
3. Покрытие по различным метрикам (например, строки, ветвления, функции и т. д.).

Рассчитайте Test Coverage

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

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

6. Качество кода

Для измерения качества кода с точки зрения количества багов можно использовать многие метрики. Один из плюсов – эти метрики легко можно посчитать и они просто интерпретируются без каких либо подводных камней. К метрикам, которые оценивают качество кода и анализ багов можно отнести:

Общее количество обнаруженных багов

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

Баги на тысячу строк кода (Bugs per KLOC)

Это относительная метрика, которая позволяет сравнивать качество различных проектов или разных версий одного проекта.

Баги по приоритетам

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

Время до обнаружения бага (Time to Discovery)

Среднее время между внедрением бага и его обнаружением. Чем быстрее баги обнаруживаются, тем дешевле их исправление.

Время на исправление бага (Time to Resolution)

Среднее время, необходимое для исправления обнаруженного бага.

Процент повторно открываемых багов

Эта метрика показывает, какой процент багов был “исправлен”, но затем снова открыт из-за неполного или некорректного решения.

Процент не воспроизводимых багов

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

Процент багов, приведших к отказу (Crash Rate)

Процент багов, которые вызвали аварийное завершение программы или системы.

Покрытие кода тестами

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

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

Заключение

Оценка эффективности команды разработки в IT — сложный и многогранный процесс. Необходимо использовать комбинацию метрик, учитывая особенности команды и проекта. Главное — не забывать, что метрики должны нести пользу в виде “подсветки” проблем мест в процессе. Если метрика не несет информативности и ее пользы от нее нет, то от нее надо отказываться. Не надо плодить метрики ради метрик.

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

В статье разберём самые популярные из бесплатных редакторов.

Для чего нужен редактор кода

• Автоматическая расстановка отступов. Правильное выравнивание вложенных элементов — неотъемлемый стандарт программирования. Это делает код более читаемым и помогает избежать ошибок, связанных с неправильными отступами.

• Подсветка синтаксиса. Выделение элементов языка разными цветами и стилями облегчает навигацию, поиск ошибок, чтение и написание кода.

• Автозаполнение. Ускоряет написание кода и снижает вероятность синтаксических ошибок.

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

• Запуск, компиляция и отладка кода. Полный цикл разработки в одной среде. Интегрированный отладчик помогает запускать программу, выявлять и устранять ошибки.

Типы редакторов кода

• Текстовый редактор. Предоставляет базовые функции для редактирования, включая подсветку синтаксиса и базовые операции с кодом как с текстом.

• IDE (Integrated Development Environment). Полноценная среда разработки, объединяющая редактор кода, компилятор, отладчик и другие инструменты. Обеспечивает более углублённую интеграцию для конкретного языка программирования.

Рассмотрим популярные бесплатные IDE и редакторы кода.

1. Visual Studio Code (VS Code)

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

Минусы: неполноценная IDE, нет встроенных интерпретаторов и компиляторов для запуска программ.

Языки программирования: почти все.

Платформы: Windows, macOS, Linux.

2. PyCharm Community Edition

IDE для Python с простым и интуитивным интерфейсом для начинающих. В комьюнити-версии можно учить Python и писать код для небольших проектов.

Минусы: не поддерживает JavaScript, CSS и другие веб-технологии и интеграцию с базами данных (как в профессиональном платном издании PyCharm).

Языки: только Python.

Платформы: Windows, macOS, Linux.

3. Notepad++

Компактный и быстрый текстовый редактор, отлично подходит для редактирования кода. Не тормозит и запускается на любом компьютере.

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

Минусы: ограниченные возможности по сравнению с полноценными IDE — нет компилятора и встроенного файлового менеджера.

Языки: почти все.

Платформы: Windows.

4. Atom

Гибкий и настраиваемый текстовый редактор, созданный GitHub (хотя в 2022-м GitHub сообщил, что отказался от дальнейшей поддержки и развития проекта). Atom до сих пор остается популярным, его хвалят за визуальную ориентированность и поддержку Git.

Минусы: разработчики отмечают, что Atom работает медленнее, чем Notepad++.

Языки: почти все.

Платформы: Windows, macOS, Linux.

5. Eclipse

Гибкая и мощная платформа для разработки. Хорошая интеграция с множеством языков программирования, чаще ценится в Java-комьюнити. Пошаговая сборка кода, удобные рабочие области, набор тем — вот за что её так любят.

Минусы: достаточно запутанный интерфейс, в котором придётся разбираться.

Языки: Java, C и C++, PHP, Perl, Python, Cobol и другие.

Платформы: Windows, macOS, Linux.

6. Brackets

Лёгкий и удобный текстовый редактор. Основные фишки — интеграция с веб-технологиями (HTML, CSS, JavaScript) и встроенный просмотрщик для визуализации изменений в CSS без перезагрузки страницы.

В 2021 году Adobe объявила о прекращении поддержки Brackets и предложила пользователям использовать исходные файлы с GitHub или установить Visual Studio Code, но часть пользователей Brackets продолжают работать в этом редакторе.

Минусы: ориентирован в первую очередь на веб-разработку, не подойдёт для других проектов.

Языки: HTML, CSS, JavaScript.

Платформы: Windows, macOS, Linux.

7. BlueJ

Интегрированная среда разработки, созданная специально для обучения программированию на Java. Простой интерфейс, ориентированный на новичков, удобные инструменты для создания и отладки Java-программ, визуализация объектов и классов — всё это делает BlueJ отличным помощником для джунов.

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

Языки: Java.

Платформы: Windows, macOS, Linux.

8. Xcode

Интегрированная среда разработки от Apple для создания приложений под iOS и macOS. Основные фишки — интеграция с языками программирования Swift и Objective-C и все нужные инструменты для создания и отладки мобильных приложений.

Минусы: доступен только для разработчиков, работающих на macOS.

Языки: Swift, Objective-C.

Платформы: macOS.

9. Spyder

Научная интегрированная среда разработки на Python для анализа данных и научных вычислений. Особенность IDE — интеграция с научными библиотеками, например, NumPy и Pandas.

Минусы: это специализированный инструмент для научных целей.

Языки: Python.

Платформы: Windows, macOS, Linux.

10. IntelliJIDEA Community

Бесплатная версия популярной интегрированной среды разработки от JetBrains. Предоставляет множество функций для разработки: интеллектуальные подсказки, автодополнение кода, интеграция с системами контроля версий.

Минусы: нет встроенного HTTP-клиента, нельзя работать с базами данных, не поддерживается совместная работа и удалённый доступ.

Языки: почти все.

Платформы: Windows, macOS, Linux.

11. Vim

Самый противоречивый редактор текста с 50-летней историей. Основные фишки Vim: быстрая работа с текстом с помощью клавиатурных команд (если сможете выучить правила «игры», конечно), низкое потребление ресурсов и быстрый запуск.

Минусы: сложно освоить из-за особенностей интерфейса (и глобальной концепции Vim в виде отказа от управления мышкой).

Языки: почти все языки.

Платформы: встроен в большинство Unix-подобных систем.

12. Che (Eclipse Che)

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

Минус: требует подключения к интернету для работы.

Языки: почти все.

Платформы: веб-браузер.

13. JupyterNotebook

Что-то между интерактивной средой разработки и «Блокнотом». Используется для визуализации данных в основном в Big Data и Data Science, а также в машинном обучении. Имеет облачную и локальную версии.

Минусы: ограничена в функциональности для разработки полноценных приложений.

Языки: почти все, основные — Python, R.

Платформы: Windows, macOS, Linux.

14. Code::Blocks

Интегрированная среда разработки, ориентированная на языки программирования C и C++. Очень простая и нетребовательная к ресурсам компьютера. Если нужно, можно расширить возможности бесплатными плагинами.

Минусы: устаревший интерфейс.

Языки: C, C++.

Платформы: Windows, macOS, Linux.

Как выбрать редактор кода

• Новичкам на стадии обучения можно посоветовать PyCharm Community Edition (под Python) или BlueJ (под Java).
• Для базовых задач большинству разработчиков достаточно VS Code, Atom и Notepad++.
• Для решения специфических задач и научных целей — обратите внимание на Jupyter Notebook и Spyder.  
• Разработчикам, которые работают над большими проектами, может подойти Eclipse или редакторы Atom и VS Code.  
• Под конкретные языки и задачи стоит попробовать заточенные на это редакторы. Например, Brackets (для веб-разработки), Xcode (для macOS), Code::Blocks (для C, C++).
• Vim — если вам близка концепция, и есть время освоить работу в нём.  

Подведём итоги

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

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

Давайте посмотрим, какие есть подходы к организации кода.

Организация кода в контроллерах

Когда я начал изучать Laravel (до этого еще знакомился с Zend/Yii/Phalcon), то писал всю бизнес логику в контроллерах. Так сделал пару своих пет-проектов (своя LMS, и CRM для HR) и особенно плохого в этом ничего не видел.

Действительно, организация кода в контроллерах является наиболее быстрым решением, но имеет ряд недостатков:

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

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

Использование команд (actions)

Далее познакомился с подходом с использованием команд. Команда — выполнение некоторого ОДНОГО действия. В таком случае бизнес-логика выносится в отдельный класс-команду.

В некоторых проектах сталкивался с тем, что весь код был вынесен из контроллера в команду просто через copy-paste. На входе у такого action объект Request. Считаю, что при использовании команд разработчику следует отвязаться от Request, либо через параметры, либо через DTO (о DTO напишу чуть ниже). Это позволяет использовать action вне контроллера и не зависеть от Request.

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

• AuthAction
• RegisterAction
• StoreCommentAction

Ниже пример использования Action в упрощенном варианте (далее посмотрим, как сделать лучше):

1. Controller обращается к action передавая DTO на вход.
2. Action обрабатывает данные и возвращает ResultDTO, либо ничего.
3. Грубо говоря, мы весь код из контроллера вынесли в action и поделили на методы.

Использование сервисов (services)

Дальнейшее изучение вопроса навело меня на Сервисы. С понятием «сервиса» я познакомился, изучая курс от Povilas Korop «How to Structure Laravel Projects».

Сервис, в отличии от action, может иметь несколько методов и является более крупным строительным блоком. Маттиас Нобак в книге «Объекты. Стильное ООП» приводит такое определение: сервисы — объекты, которые либо выполняют задачу, либо предоставляют информацию. Также автор отмечает, что сервисы не хранят свое состояние, т.к. для повторного использования сервиса придется заново его инициализировать, сбрасывая состояние.

Также сервисы могут реализовывать интерфейсы и внедряться через интерфейс. Сервис также как и команда должен иметь единственную ответственность.

Ниже схема использования сервисов:

1. Controller обращается к Service/Repository передавая DTO на вход (либо просто параметры, если их количество менее 3).
2. Service обрабатывает данные и возвращает ResultDTO, либо ничего.
3. Service может внутри себя использовать другие Services (расчеты и сохранение данных) и Repository (выборка).

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

Использование паттерна репозиторий

С репозиториями также познакомился на курсе от Povilas Korop. Паттерн репозиторий служит цели отделить логику работы с БД от бизнес-логики приложения. Лично для себя выделяю основной плюс в переиспользовании методов выборки. Примерами методов репозитория могут быть такие названия методов как:

• getById()
• getSellers
• getUserList()
• etc

Также репозиторий может использоваться для create/update/delete операций. Я предпочитаю в репозиторий выносить только все операции выборки, а для операций изменяющих БД использую сервисы.

Плюсы паттерна:

• достаточно просто переиспользовать код;
• простота миграции на другие БД (на практике мной не встречалось), т.к. у нас есть дополнительный слой абстракции.

Использование DTO

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

В чем плюсы использования DTO:

• type-hint;
• инкапсуляция;
• разделение слоев приложения;
• модификация данных.

DTO могут создаваться через обычный конструктор, либо через вызова метода который возвращает сам DTO. Примерами может служить вызов:

• UserDTO::fromRequest($request)
• UserDTO::fromArray($data)

Начиная с php 8.0, можно задавать свойства прямо в конструкторе, определяя область видимости. Также для облегчения создания DTO есть пакет от spatie.

Складываем все вместе

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

1. Controller обращается к action передавая DTO на вход.
2. Action обрабатывает данные и возвращает ResultDTO, либо ничего.
3. Action может внутри себя использовать Services (расчеты и сохранение данных) и Repository (выборка), о них подробнее ниже.
4. Может быть вариант не использовать Repository непосредственно внутри Action, а вызывать только из Service, но считаю это излишним усложнением.

Организация структуры проекта

Немного слов о структуре. Поначалу пользовался штатным подходом, как изначально рекомендует нам документация Laravel. Проект разбивается на папки, которым соответствует функционал хранящихся в них классов. Типичная структура Laravel проекта:

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

В идеальном случае, модуль — это независимая часть бизнес-логики. При модульной организации кода структура у нас получается примерно следующей:

Код разбивается, исходя из логики принадлежности к Домену. Есть также упрощенный вариант, когда Controllers не выносится в папку с модулями, а остается в изначальной директории app/Http/Controllers.

Плюсами данного подхода является:

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

Минусы:

• Основным минусом является увеличение количества директорий.
• Возможно допустить ошибку при разделении кода на модули. И в будущем придется рефакторить данный код.

Мой способ организации кода

1. Классы находятся в папке app и разбиты по модулям. Каждый модуль относится к определенной сущности либо бизнес-процессу.
2. Для выборок данных использую паттерн репозиторий.
3. Бизнес-логика и операции создания/изменения моделей выношу в сервис-классы. Сервис классы не хранят свое состояние, что позволяет их переиспользовать без повторной инициализации.
4. Для того чтобы не зависеть от Request в сервисы передаю либо одиночные параметры, либо DTO. Это позволяет переиспользовать код вне контроллеров (например, команда создания нового пользователя и т.д.).
5. Стараюсь, чтобы модели оставались максимально тонкими. В основном содержат в себе связи (relations).
6. Контроллеры остаются на своих местах, но создаю папку согласно наименованию модуля.
7. Для создания объектов на лету использую статическую фабрику (static factory).
8. Если используем сервис, и он выполняет единственное действие.
9. Как именую методы:

• getSomething — получение информации. Важный момент — отсутствие side эффектов.
• isSomething — метод для проверки, должен возвращать.

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

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

Больше тренингов богу тренингов…

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

Но вместо ожидаемого роста и прогресса мы видим все тот же убогий набор любимых граблей. Форумы пестрят однотипными статьями hr-специалистов (на самом деле те же кадровики, но с самомнением) о том как проходить собеседование, понравиться и составлять красивое резюме. Обычно это сопровождается стонами на тему как сложно найти того, кто все сделает на взгляд hr верно, и закроет вакансию.

Занимаясь систематически кейсами по организации отделов компании с нуля, а также опыт обслуживания и консультации по подбору реальных (!) специалистов я сформулировал для себя несколько основных правил подбора и формирования команды. Может кому пригодится. Поехали…

1. Убрать hr из найма, совсем. Да, ваша нагрузка выше, но зато вы не упустите целый пласт ценных кадров.  HR ищет «правильные» резюме, грамотно составленные. Такие составляет тот кто часто и умело ищет работу. Кто хорошо работает — резюме всегда корявое, специалист описывает то, что ему кажется важным. О услуге составления резюме он может вообще не знать. И выбросьте из головы мысли, как он мог бы «правильно» сделать. Сейчас это ваша задача выследить в шелухе зерно драгоценного металла. HR только оформляет документы, в идеале получая их от вас или в вашем присутствии. Всё (!) вмешательство hr в подбор должно пресекаться, хотят «оценивать» — значит берут на себя ответственность за работу отдела. И никак иначе.
2. Оценивайте не скилы, а кейсы. Если настроены серьезно — дав тестовое задание на примере того что сейчас важно компании. Ради всего святого, если ваш ведущий спец берет день на подготовку и изучение, не ждите ответов от соискателя немедленно. Как вариант запросите у него какие сходные задачи он решал. В обязательном порядке задаю вопрос : приведите пример кейса в своей практике, который вы считаете сложным и как вы его решали? Это стоит внимательно разобрать, вы поймёте уровень кандидата и его готовность решать то с чем он не сталкивался. А в IT каждый периодически решает задачи, которых раньше не решал.
3. Участие в собеседовании ведущего специалиста (если это вдруг не вы). Важно, но сложно. Собес всегда превратиться в мерение длиной скиллов, в 90% случаев точно. Ваш ведущий, сеньор, как хотите зовите, будет гонять то тому что он знает и помнит именно сейчас. Тут помните что вы в этот момент собеседуете ещё и своего ведущего. Если он уйдет на рынок, то так же попадет на того, кто сидя на конкретной задаче/технологии знает больше и будет уже о нем невысокого мнения. Тут для вас уже «красный флаг» фраза вашего специалиста: да о чем с ним, говорить если ***. Это говорит о проблеме в вашей команде не меньше, чем о соискателе.
4. Деньги. Не тупите. Если вы ищете хорошего опытного специалиста, умеющего эффективно закрывать кейсы, то он знает сколько это стоит. Начинайте с конкурентной ЗП. Если отрасль/стек в котором вы ищете специалиста конкурентные — сначала вы идете к генеральному и ставите оклад по поиску за рынка +10-15%. Специалист — не вьюнош с взором горящим, ищущий галеру с идейными гребцами. Он денег хочет, и получит, и если вам нужен его продукт, он получит денег от вас. А может от других. Помните об этом. Другая сторона медали — своевременная индексация. Нет это не шутка.
5. Коммуникабельность. Либо забудьте либо в меру. У хорошего специалиста всегда есть свое мнение. И оно нужно в первую очередь вам для контроля соответствующих технологий и развития, иначе получите Франкенштейна. Не сразу, но года за 3-4. Такое часто бывает, когда эти ваши 1Сы бесконтрольно переписываться по запросам пользователей. Если специалист сказал, что так нельзя, значит так делать нельзя.
6. Мнимые недостатки типа частой смены работы. Может ему попадались такие же умники, ценящие вовлеченность и переработки. Не надо недооценивать неадекватов на рынке труда. Человек ищет стабильность. Если у вас ему будет комфортно, он у вас и десять лет проработает. Если брать отдельно непрерывный стаж, то в it человек, просидевший лет 10 на одном месте — это уже затекшие мозги.
7. Место отдела в компании. Это уже должно беспокоить вас и ваше отношение с руководством. Если компания с помощью вас решает свои проблемы, то как технологический менеджер вас в первую очередь должно беспокоить не как их решать, а откуда они взялись. Нельзя быть хорошим пожарным, если здание ежедневно кто-то поджигает. И тут надо выяснить готово ли руководство воздействовать на причины. Можно какое то время быть «виноватым отделом» обычно если платят и вы в это время сами ищете работу не торопясь. Если компания оказывается не готова к изменениям и работать не в режиме пожара, подумайте надо ли вам это? Выгорание штука неприятная и тяжело устраняемая.

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

Если мои набитые жизнью шишки на лбу кому-то помогут — значит текст писал не зря. Очепятки пусть остануться на моей совести…

Всем добра.

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

Что такое Agile-методология

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

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

Роль тестировщика в Agile

Давайте рассмотрим спринт с его артефактами и попробуем определить роль тестировщика в нем.

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

Для многих команд актуально подключение специалистов по тестированию ближе к концу итерации разработки, так называемый TLD-подход — тестирование после разработки (англ. Test Last Development). Такая практика может привести к ряду проблем. Во-первых, недостаток времени для выполнения всех необходимых проверок и выявления потенциальных ошибок. Это может привести к тому, что некоторые дефекты останутся незамеченными и будут обнаружены уже после релиза продукта. Во-вторых, отсутствие планирования и недостаточная коммуникация между членами команды. В этом случае тестировщики не будут в полной мере понимать требования и ожидания заказчика, что приводит к неправильному выполнению тестовых сценариев и некорректной оценке качества продукта. Поэтому следует привлекать QA-специалиста к участию в проекте на всех этапах спринта, начиная с планирования и заканчивая демонстрацией и ретроспективой.

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

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

В течение спринта QA-специалист занимается автоматизацией тестирования компонентов системы. Автоматизация играет ключевую роль в Agile-разработке, позволяя команде быстро и эффективно проверять работоспособность функциональности после каждого изменения в коде. Хорошей практикой считается встраивание автоматизированных тестов в конвейер непрерывной интеграции CI. Это позволяет быстро проверить, не нарушила ли новая функциональность работу уже существующих компонентов системы. Автоматизированные тесты также помогают обнаруживать регрессионные ошибки, которые могут возникнуть при внесении изменений в код.

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

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

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

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

Ссылаясь на вышесказанное, работа тестировщика в спринте может выглядеть так:

Заключение

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

• может передаваться отдельно или быть встроенной в код;
• может содержаться в разных форматах (текст, видео, картинки);
• используется разными специалистами, связанными с одним проектом.

В первую очередь документация необходима команде разработчиков проекта и её руководителю, а уже после менеджменту, клиентам из бизнес-среды, поставщикам, конечным потребителям. Отсутствие документации существенно усложнит процессы расширения штата или продуктовой линейки. Наличие сопроводительных документов позволяет ML-команде:

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

Частые проблемы, связанные с документацией

• В документации содержится слишком мало информации. Приходится часто дергать членов команды для получения нужных данных.
• Информации слишком много, и она разбросана по разным источникам – wiki, Slack, гугл-документы и презентации, бумажные носители.
• Информация неактуальна.
• Информация дублируется в разных источниках.

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

Правила структуры и оформления документации

• Единая точка входа ко всей документации проекта. Это может быть страница в Notion, фрейм в Miro или Markdown-документ, форма не так важна. Главное, чтобы с этой страницы любой человек мог получить доступ к нужной ему информации.
• Единые правила оформления и стиля, наличие шаблонов. Немаловажным фактором для восприятия пользователем документации является наличие и консистентность общего стиля оформления документации.
• Стиль описания и подачи информации в документации соответствует культуре команды. Нет смысла придерживаться ненужного формализма во внутренних документах команды.
• В документах есть ссылки на другие релевантные документы.
• Важные места выделены.
• Используются оптимальные методы передачи информации. В зависимости от задачи документа может использоваться не только текст, но и картинки, графики, диаграммы, видео.

Правила использования и актуализации документации

• Определена целевая аудитория каждого документа – кто, как и зачем будет его использовать.
• Если документация не используется самой командой, то её актуализацию стоит встраивать в процессы в формате “definition of done”. Например, нельзя зарелизить новую модель, не обновив документацию.
• Использование методологии (“docs as code”) там, где это актуально. В данном случае документация является частью кодовой базы, лежит в репозитории и пишется в IDE. Данный подход “из коробки” даёт возможность версионирования, тестирования, ревью изменений документации.
• Производится регулярная ревизия документации. Включает себя в том числе отказ от устаревших или лишних документов.
• Встречи команды должны порождать новые “артефакты” (документы по итогам встречи). Например, дорожная карта реализации или лист договоренностей.
• Инвентаризация технического долга по документации. Да-да, техдолг по документации тоже является техдолгом.

Можно ли как-то измерить качество документации

Если у нас уже есть какая-то документация и процедуры её актуализации, можно ли попробовать померить её качество? Такие показатели действительно есть:

• Покрытие – какая часть кода проекта или DS-пайплайна покрыта документацией
• Доступность – сколько времени или кликов в среднем занимает поиск нужного документа
• Читаемость – насколько легко читать этот документ
• Количество посещений/обновлений документа за период

Мы пока не дошли до того, чтобы регулярно замерять динамику этих показателей, пока это кажется лишним. Но в качестве точки среза – почему нет?

Документация ML-проекта

В первой части статьи я рассказал про документацию процесса разработки. Однако ML-разработка довольно сильно отличается от классической разработки. Есть ли различия в документации?

Если максимально упростить пайплайн ML-разработки, то он будет выглядеть следующим образом:

1. Оценивается осуществимость и значимость проекта
2. Производится сбор, очистка и разметка данных
3. Генерируем гипотезы, тренируем модели
4. Оцениваем качество и устойчивость лучшей модели
5. Деплоим модель
6. Осуществляем мониторинг

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

Что же может быть входной точкой в документацию

В нашем случае это карточка проекта, оформленная в Notion.

В таком случае в рамках проекта по маммографии документы распределены по группам: описание работы системы, код и model cards, эксперименты и идеи, данные и так далее.

Если мы углубимся в какую либо подгруппу, например, описание работы системы, то мы увидим внутри список документов и ссылок, связанных с данной предметной областью. Как мы видим внутри могут содержаться абсолютно разные документы, такие как Miro, Google-таблицы, PDF-файлы.

Начинаем с оценки проекта

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

Примеров, как может выглядеть такой документ, очень много – AI Canvas, Mission Canvas, карточка проекта (design doc, чек-лист требований). В эту же группу можно включить технические задания от заказчиков.

Такие документы могут включать:

1. Описание проблемы и предположения о достижимой ценности продукта
2. Варианты решения с ML и без него
3. Требования к качеству (метрики)
4. Описание источников возможных данных
5. Другие требования (например, к железу и программному обеспечению)
6. Последствия ошибок системы и так далее
7. Этапы проекта
8. Технические риски и заключение по проекту
9. Конкуретная среда
10. Литература, научные статьи, видео по теме

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

Принято положительное решение для реализации ML-проекта

После сбора и анализа такой информации, проведения встречи с бизнес-подразделением принимается решение о реализации или же отмене проекта. Допустим было принято положительное решение и теперь мы переходим к шагу №2 – “сбор, очистка и разметка данных”.

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

Любой источник данных также требуется документировать. Это позволяет быстро получать информацию об источнике и объёме данных, их ограничений и свойств, генерировать новые гипотезы, связанные с данными – например, какие данные нужно доразметить или наоборот выбросить из датасета.

Datasets Cards

Документацию датасетов мы называем dataset cards. В зависимости от специфики данных, частоты их пополнения, типа разметки это может быть как просто статический документ, так и интерактивный дашборд. В идеале датасет-карды обладать следующими свойствами:

• версионирование – мы хотим понимать, какая документ соответствует той или иной версии датасета
• автообновление – если датасет-карт или дашборд подключен к БД с разметкой, то он всегда будет содержать актуальную информацию о датасетах
• интерактивность – должна быть возможность подробно глазами изучить тот или иной слайс данных или конкретный кейс

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

Собрали данные… Начинаем тренировать какие-то модели

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

Среди целей, которые мы ставим перед собой на данном этапе:

• Быстрая генерация, приоритезация и проверка гипотез
• Удобный анализ результатов экспериментов
• Возможность возврата к результатам предыдущих экспериментов
• Удобство разработки

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

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

В данном случае база идей реализована в Notion. Благодаря этому ее можно упорядочивать в необходимом нам формате. Например, по статусам, оценке “легкости реализации” и так далее. Отсюда мы можем попасть в саму карточку нужного нам эксперимента и посмотреть его детали.

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

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

В трекере можно сравнить результаты разных экспериментов, изучить метрики, сформулировать выводы. Всё это по сути тоже является частью документации ML-проекта.

Натренировали. Выбрали лучшую модель. Теперь пора оценить её качество и устойчивость

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

В качестве артефактов документации на этом этапе у нас появляются model card, дашборды с таблицами и метриками, отчёты по анализу ошибок.

Model Card – описание ML-системы, которая включает в себя следующую информацию:

• Изменения в последней версии
• Описание обучающих и тестовых данных
• Описание архитектуры сети, препроцессинга и других компонентов
• Описание требований к входным данным
• Описание аутпутов системы
• Метрики
• Описание известных ограничений и проблем

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

Мы храним такую документацию в формате docs-as-code – в нашем случае, это Markdown-док, который версионируется и прилинкован к конкретным коммитам. По важным же релизам могут быть экспортированы и PDF.

Круто. Теперь мы можем задеплоить модель и подготовить ее в продакшну!

Деплой как и любой другой ML-процесс порождает свой класс специфичных документов. Среди которых :

• Отчеты по тестам (test reports)Автоматизированные тестыРезультаты a/b тестовОтчеты по опросы пользователей
• Автоматизированные тесты
• Результаты a/b тестов
• Отчеты по опросы пользователей
• Дашборды и регулярные автоматические отчёты
• Post-mortem по итогам инцидентов на проде (документация события, несущего негативные последствия с целью анализа и устранения его причин)
• Документация API
• Change Notes
• Прочая документация, связанная с релизами

Ну и куда без общей документации

Конечно, на ML-проекте появляется и всякая общая и процессная документация. Примеры из нашей практики:

• Team Canvas

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

• Доски и скоринговые карты собеседований сотрудников
• Таблица с описанием встреч

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

• Гайдлайны по написанию кода
• База знаний – по коду, инфраструктуре, ML, заметки со встреч с доменными экспертами (врачами)
• Доска онбординга
• Общее Миро со всей информациейСтратегия и цели компании/проектаРоадмапы
• Стратегия и цели компании/проекта
• Роадмапы

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

Отдельно хочу остановиться на таком моменте как автоматизация документации. Во-первых, чем меньше мы в целом делаем руками – тем меньше нужды в ручном написании документации. Например, если мы ставим эксперименты в джупитере или меняем данные руками в эксель-табличках, то и документацию нужно будет написать руками. А работа с эксперимент-трекером или БД с разметкой автоматически создаёт нужные артефакты.

Помимо этого, есть разные инструменты, которые позволяют автоматизировать процесс создания и актуализация документации – Swagger, плагины для IDE, интерактивные датасет-карды (о них можно прочесть выше), DVC-пайплайны, методология docs-as-code.

Заключение и рекомендации

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

Что бы я предложил вам сделать уже сейчас?

• Провести аудит документации и по каждому документу ответить на вопросы из списка (можно найти в первой части статьи), сформировать бэклог техдолга по документации.
• Создать единую точку входа в документации (если её еще нет).
• Оценить, для каких документов подходит методология docs-as-code, актуализацию каких документов можно автоматизировать.
• Собрать обратную связь от разных групп (ML-инженеры, пользователи, разметчики, бизнес и другие команды).
• Тренироваться писать хорошие технические (и не только) тексты.

Если вы хотите узнать ещё больше об организации процессов ML-разработки, подписывайтесь на наш Телеграм-канал Варим ML.

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

Определение целей и задач команды

Определение целей и задач команды – основа успешной работы проекта

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

SMART: Specific (конкретные), Measurable (измеримые), Attainable (достижимые), Relevant (релевантные) и Time-bound (с ограниченным сроком).

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

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

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

Рекрутинг и найм квалифицированных разработчиков

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

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

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

Находить таких специалистов можно на различных ресурсах, таких как:

• hh.ru;

• Работа.ру;

• Кадровые агентства.

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

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

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

Создание привлекательной рабочей среды

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

1. Обеспечениекомфортных условий работы и возможности для творчества

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

Необходимо помнить, что разработчики – это не просто команда, а творческий коллектив. И только предоставив им полную свободу действий, мы сможем достичь максимальной эффективности и результативности в их работе.

2. Вдохновляющееруководство и обратная связь

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

3. Развитиеи обучение разработчиков

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

4. Поощрениеи признание достижений членов команды

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

Так, в компании AurumSoft также ценится и другой подход к мотивации сотрудников – признание коллектива. Вместо простой индивидуальной похвалы, акцент делается на признании и ценности вклада всего коллектива.

5. Установкаэффективных коммуникационных каналов и инструментов

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

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

Управление конфликтами и разрешение проблем

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

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

Контроль и оценка производительности команды

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

1.tУстановка метрик и критериев оценки производительности

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

2.tРегулярное отслеживание и обратная связь

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

3.tВнесение необходимых корректировок и улучшений

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

Заключение

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

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

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

Сегодня я расскажу про то, как я внедрил гибкое тестирование, и что из этого вышло.

В 2021 году я попал на B2C проект, использующий Scrum для построения процессов.

Задачи Kanban доски проходили следующие этапы:

• Запланированные задачи. Здесь задачи ждут своего часа
• Задачи на анализе. Здесь аналитики проектируют систему и формируют требования.
• Задачи в разработке. Этап для разработчиков и дизайнеров.
• Тестирование на тестовом стенде. Здесь тестировщики тестируют задачу и проводят регресс.
• Тестирование на боевом стенде. Здесь тестировщики тестируют задачу и проводят тесты критического пути.
• Закрытие задачи. Закрываем задачи, если все ок.

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

Команду устраивал процесс работы. Задач было немного — работа шла по плану.

Проблемы проявились, когда на проекте поменялся Product Owner, который расчехлил водомет фич. Задач стало больше … Сильно больше.

Это привело к тому, что в колонке QA оказалось 40 задач и один тестировщик — я.

Задачи часто возвращались. Дедлайны воскрешались. Причины были следующие:

• Ожидаемый результат тестировщиков не совпадал с ожидаемым результатом разработчиков. Например, есть список со странами. В этом списке присутствует значение “Весь мир”. В требовании не было правила, описывающего логику работы данного пункта. Итог — можно было выбрать “Весь мир” и другие страны.
• Отсутствие подсказок пользователю. Например, есть валидация поля “Email пользователя” по следующей маске “символы@символы.домен”. Если указать несуществующий домен, то выводилась неинформативная ошибка, не указывающая пользователю причину этой ошибки.

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

Проблема

Наш процесс работы выглядел так:

1. Бизнес поставил задачу.
2. Аналитики и дизайнеры спроектировали систему.
3. Разработчики написали код.
4. Тестировщики проверили.

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

В итоге мы получаем следующие проблемы:

• Неравномерная работа тестировщиков: то задачи отсутствуют, то завал перед релизом.
• Требования, содержащие ошибки.
• Частые возвраты задач на предыдущие этапы.
• Низкое покрытие автотестами.

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

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

Главное — понять, что использование инструментов типа систем контроля воркфлоу, как Jira или TeamCity и проведение ежедневных дейли-митингов не делают нас Agile-командой. Agile-командой является та команда, каждый член которой понимает свою ответственность за качество продукта. Качество продукта определяет не только код. Качество продукта начинается с требований. А как проверить качество требований? Так же как и проверить качество кода — тестировать.

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

Необходимо привлекать тестировщиков на все этапы разработки продукта, начиная с бизнес-требований. Чем раньше найден баг, тем дешевле его устранение, так как время разработки сильно сокращается. Согласно исследованию “Национального института стандартов и технологий США” ситуация следующая:

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

Shift Left Testing предполагает использование автоматизации тестирования, непрерывная интеграция и непрерывное развертывание (CI/CD). С их помощью разработчики могут быстро выявлять дефекты и уязвимости в коде и устранять их до того, как они приведут к серьезным проблемам.

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

Решение

Сначала мы переработали процесс разработки и тестирования. Добавили новые этапы, учитывая наши проблемы:

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

В итоге у нас получился следующий процесс разработки:

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

Запуская автотесты регулярно, можно получить следующие преимущества:

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

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

• Пакет smoke-тестов проверяет критический путь пользователя и проверяет работу всех служб. Эти API-тесты и UI-тесты, которые запускаем при каждом деплое приложения.

• Функциональные пакеты тестов — детальная проверка работы каждого раздела приложения. В связи с тем, что выполнение функциональных тестов требует большего времени, решено перенести их на уровень API. Тестирование на уровне API позволяет проводить тесты быстрее. Данные тесты запускаем в зависимости от задач релиза.

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

Итог

Закончив внедрение нового процесса разработки было обнаружено:

• Требования стали качественными. Споров насчет ожидаемого результата снизились в разы.
• Задачи стали реже возвращаться, что ускорило время доставки фич пользователю.
• Благодаря новой стратегии автотестов, количество багов пропущенных на боевой стенд уменьшилось, что позволило разгрузить команду тех. поддержки. Также ручные тестировщики все меньше тестируют регресс. Надеюсь, скоро вообще перестанут.

Данный опыт позволил мне выделить главные принципы в работе тестировщика в Agile-команде:

• Сотрудничество с другими членами команды: Тестировщик должен активно сотрудничать с другими членами команды. Он должен принимать участие в планировании, обсуждении требований и определении приоритетов.

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

• Тестирование на ранней стадии: Тестировщик должен начинать тестирование на ранних стадиях разработки, чтобы обнаруживать ошибки как можно раньше и сокращать время на их исправление.

• Постоянное улучшение процесса: Тестировщик должен постоянно улучшать процесс тестирования и внедрять новые методы и инструменты для повышения качества продукта и ускорения процесса разработки.

При раннем тестировании необходимо уделить внимание правильному планированию, выбору тестовых сценариев и их автоматизации, а также внедрению средств непрерывной интеграции и непрерывной доставки (CI/CD).

Напоследок, хочу привести цитату из книги “Как тестируют в Google”:

“В итоге качество достигается предотвращением, а не выявлением багов…”

P.S. Кстати о книгах. Вот хорошие книжки для изучения темы:

1. Agile-тестирование. Обучающий курс для всей команды. Авторы: Джаннет Грегори и Лайза Криспин
2. Как тестируют в Google. Авторы: Уиттакер Д., Арбон Д., Каролло Д.
3. Экстремальное программирование. Разработка через тестирование. Автор: Кент Бек

Не судите строго — это мой первый опыт публикации. Спасибо за внимание!

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

Мы в digital-агентствe Air Production строго соблюдаем эффективный способ избежать ненужных затрат и улучшить процесс разработки — это тестирование прототипа сайта.

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

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

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

Существует несколько типов прототипов в зависимости от того, как они создаются и используются.

Наиболее распространенные типы прототипов

1. Бумажные прототипы

Интересным и уникальным аспектом тестирования прототипов является использование методики “бумажного прототипирования”. Это метод, который позволяет быстро создать прототипы на бумаге или карточках, после чего пользователи могут взаимодействовать с ними, как с живым продуктом.

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

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

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

2. Интерактивные прототипы

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

3. Цифровые прототипы

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

4. Функциональные прототипы

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

5. Презентационные прототипы

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

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

Шаги для тестирования прототипа

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

1. Определение целей тестирования прототипа

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

2. Создание тестового плана

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

3. Разработка тестовых сценариев

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

4. Подготовка тестовых данных

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

5. Выполнение тестовых сценариев

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

6. Анализ результатов

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

7. Отчет о тестировании

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

8. Решение проблем

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

9. Повторное тестирование

После внесения изменений в прототип выполняется повторное тестирование, чтобы проверить, что исправления были успешными и что все функциональные проблемы были устранены.

10. Итеративный процесс

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

11. Окончательное подтверждение

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

Почему тестирование прототипов экономит время

Тестирование прототипов экономит время по нескольким причинам:

1. Раннее выявление проблем

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

2. Быстрая итерация

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

3. Улучшение коммуникации

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

4. Раннее обучение пользователей

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

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

Для чего тестируют прототипы

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

1. Расширение функциональности

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

2. Изменение интерфейса

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

3. Изменение дизайна

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

4. Изменение тестовых случаев

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

5. Изменение фокуса тестирования

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

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

Советы для тестирования прототипов

Вот несколько рекомендаций, которые помогут вам с тестирования прототипа:

1. Определите цели и задачи

Перед началом тестирования прототипа сайта четко определите цели и задачи, которые вы хотите достичь. Это может быть проверка навигации, понимание пользователей или оценка визуальной привлекательности. Чем более конкретные цели, тем легче будет оценить результаты тестирования.

2. Определите целевую аудиторию

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

3. Используйте прототипирование с высокой степенью детализации

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

4. Проведите пользовательское тестирование

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

5. Собирайте и анализируйте обратную связь

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

6. Внесите коррективы и повторите тестирование

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

7. Учтите мобильную адаптивность

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

Зачем продолжать тестирование

Продолжайте тестирование на протяжении всего процесса разработки:

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

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

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

Творцы-разработчики и злодеи-тестировщики

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

• Тестировщик получил продукт на проверку со сроком «вчера» вместо положенных 5 дней, потому что разработчики не успели с доработками. И приходит продлевать дедлайн.
• Тестировщика торопили с репортами, и он не успел подробно описать баги. Разработчик не понимает, что править.

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

Как снизить вероятность конфликта

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

Вот несколько полезных советов:

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

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

А что еще сделали мы

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

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

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

При возникновении конфликтной ситуации, тестировщик всегда может обратиться к scrum-мастеру или же к команде стрима.

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

Шаг 1. Определите бизнес-задачу

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

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

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

Шаг 2. Проанализируйте целевую аудиторию и конкурентов

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

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

Успешное мобильное приложение не только решает задачи бизнеса, но и удовлетворяет потребности ваших клиентов или сотрудников:

• На вашем сайте высока доля мобильного трафика — возможно, пора переходить в мобайл.

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

• Клиенты не всегда знают о текущих акциях — проинформируйте их об этом в приложении.

• Боятся, что товар закончится, пока они едут в магазин — предоставьте возможность зарезервировать его в 2 клика прямо с мобильного.

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

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

Шаг 3. Оцените вашу инфраструктуру данных

Любое бизнес-приложение построено на работе с данными клиентов и самого бизнеса (бухгалтерии, склада и пр). Поэтому важно понимать, есть ли у вас необходимая инфраструктура или потребуются дополнительные затраты на ее построение.

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

Если вы не собираете данные или ведете учет в бумажном виде, мобильное приложение обойдется существенно дороже. На построение только архитектуры данных придется выделить от 40% бюджета. Самый недорогой вариант — простой интернет-магазин.

Если речь идет о нейронных сетях и анализе данных, то серверные работы займут существенную часть бюджета.

Шаг 4. Выберите способ и инструмент разработки

Как разрабатывать приложение: самостоятельно или на заказ — зависит от вашего бюджета и желаемого результата. Давайте разберем оба варианта.

Мобильное приложение своими руками

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

Существует три варианта самостоятельной разработки приложения:

Написание кода своими силами

Если вы обладаете навыками программирования или готовы получить их, то вполне можете написать приложение самостоятельно. Технологии можно использовать разные: от натива (Swift или ObjectiveC для iOS, Java или Kotlin для Android) до всевозможных фреймоворков — например, Xamarin (C#), ReactNative (Javascript) или Flutter(Dart).

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

Онлайн-сервисы для создания приложений на основе готового контента

Это наиболее простой способ создания приложений — чтобы им воспользоваться, вам понадобится только сайт, адаптированный под мобильные устройства. Такие сервисы конвертируют браузерную версию в приложение без существенных изменений. Весь процесс может занять несколько минут. Способ подходит для небольших сайтов с качественным адаптивным дизайном или мобильной версией. Быстро, дешево и сердито.

Если вас интересует такой вариант, рекомендую также в качестве альтернативы рассмотреть возможность доработки своего сайта и создания PWA – progressive web app. Эта технология позволяет получить своеобразный гибрид сайта и приложения: в десктопе он будет отображаться как обычный сайт, а в мобильной версии — имитировать приложение. Возможно, вам окажется достаточно этого функционала и не придется делать отдельное приложение.

Конструкторы мобильных приложений

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

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

Затраты на самостоятельную разработку

Во многих сервисах доступны бесплатный базовый функционал и Pro-версии. Стоимость платных тарифов сильно разнится в зависимости от опций, периода оплаты и пр. В среднем для создания стандартного приложения понадобится около 50-150$ в месяц.

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

Профессиональная разработка мобильного приложения

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

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

Разработка отдельного приложения под каждую платформу

Данный подход предполагает написание кода отдельно под Android и под iOS. Целесообразен он в тех случаях, когда требуется уникальный дизайн для каждой платформы с соблюдением всех гайдлайнов, максимальная производительность приложения и полный доступ к функциональности (дактилоскопический сканер, алгоритмы дополненной и виртуальной реальности, тонкие настройки беспроводного соединения, трансляция геолокации и т.д.).

Минусы очевидны: это наиболее затратный способ с точки зрения времени и ресурсов. Каждая операционная система предполагает свой язык программирования (Swift или Objective-C для iOS, Java или Kotlin для Android) и способ описания UI-дизайна. Это обязывает разработчиков реализовывать весь функционал для каждой из платформ по отдельности, практически без возможности переиспользования наработок одной платформы на другой. Если проект сложный или команда не имеет опыта работы с двумя операционными системами, есть вероятность, что потребуется задействовать по отдельной команде на каждую платформу.

Кроссплатформенная разработка

В этом случае мобильные приложения на Android и iOS разрабатываются с использованием общей бизнес-логики и с единым описанием дизайна, что снижает затраты. Наиболее популярные инструменты кроссплатформенной разработки: React Native, Xamarin (Xamarin.Forms) и Flutter. На выходе получается приложение, которое выглядит и работает одинаково на обеих платформах.

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

Комбинация нативного подхода и кроссплатформенного

Для более сложных приложений мы используем этот подход. Его особенность состоит в том, что мы имеем общую бизнес-логику, но дизайн создается отдельно под требования Android и iOS. В этом случае разработчик фактически работает с нативным кодом каждой платформы, но с помощью единого языка программирования C#. Это дает возможность переиспользовать код на обеих платформах.

В DD Planet мы используем фреймворк Xamarin, который позволяет сгладить все различия платформ и написать код на одном языке. Это оптимальный вариант для сложных приложений – он позволяет соответствовать гайдлайнам каждой платформы и решать бизнес-задачи любой сложности.

Затраты на заказную разработку

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

Шаг 5. Протестируйте

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

Что необходимо тестировать:

• Функционал. Оцениваем, соответствует ли приложение ТЗ и потребностям бизнеса, и проверяем работоспособность всех функций.

• Конфигурации. Тестируем на разных устройствах, конфигурациях и версиях операционных систем.

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

• Юзабилити. Анализируем удобство взаимодействия пользователей с приложением при различных сценариях поведения.

• Безопасность. Выявляем уязвимости к сетевым атакам, вирусам и взломам, обеспечиваем безопасность пользовательских данных.

Шаг 6. Регулярно поддерживайте приложение

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

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

Помимо мелких доработок, изредка появляется необходимость в масштабных обновлениях. Обычно это происходит с выходом новых девайсов, на которых приложение работает не так, как ожидалось.

Из наиболее ярких примеров — новые требования Apple к приложениям после выхода iPhone X. На обновления владельцам дали два месяца. Если спустя это время приложения отображались на устройстве некорректно, их удаляли из магазина.

Как правило, гарантийная поддержка на первое время входит в стоимость разработки.

Краткое резюме по созданию эффективного приложения

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

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

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

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

Избежать этого помогает грамотно выбранная методология работы. В данной статье рассмотрим некоторые из них.

MSCW

Впервые этот метод использовали Oracle UK в 1994 году. Он подходит для простых проектов (где есть чёткое понимание от А до Б). Или для очень больших, растянутых по времени и трудозатратам.

Согласные буквы в MSCW обозначают степени приоритетности задач/требований:

• M (или must) – задачи/требования, представляющие основной функционал или ядро задачи. Например, изменение платформы, на которой должно быть представлено решение. Если цель работы — запустить продукт именно на новой платформе, первой задачей будет — установить эту самую платформу.
• S (или should) – задачи/требования второго приоритета, которые ещё обязательны к исполнению и в отсутствии задач категории M становятся главными. Это, например, добавление функционала или обязательных программ для работы.
• C (или could) – задачи/требования, желательные для реализации, но не обязательные для работы продукта. Например, если есть пробный период программы и нужно изучить функционал, чтобы принять решение о её покупке.
• W (или would)– задачи/требования «по возможности», которыми можно пренебречь. Пример такой задачи — изменение цветовой палитры при визуализации приложения.

Преимущество MSCW — в простоте. Задачи делятся только по «критичности», и их не приходится переносить в другой класс с течением времени.

Минусы:

• Субъективность определения приоритетов. Неотъемлемые для заказчика функции могут быть «желательными» для руководителя проекта. И «дополнительными» для разработчика. Так что приоритеты стоит обсудить «на берегу».
• Какой бы, возможно, неприоритетной не стала со временем доработка из первой группы, её придётся доделать. Иначе будет невозможно приступить к задачам следующей категории.

RICE

Эта методология позволяет оценивать каждое требование или задачу по четырём параметрам:

• Reach или охват — количество пользователей/транзакций/задач в измеряемую единицу день, месяц, год;
• Impact или влияние — оценочная субъективная величина влияния на конечного пользователя/потребителя;
• Confidence или достоверность данных при оценке охвата и влияния — количество и структура данных для подтверждения своих выводов;
• Effort или требуемые усилия — оценка усилий для достижения результатов, оценивается в человекомесяцах.

Полученные оценки важно и нужно использовать в системе ранжирования задач/ требований. Это поможет определить, в каком порядке их выполнять, чтобы получить максимальный эффект от реализации. Я рекомендую также перед стартом любого проекта задавать «контрольный вопрос» заказчику: сколько на самом деле стоит проект и есть ли смысл вкладывать в него столько денег.

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

Основное преимущество в том, что это — универсальная методология. Она позволяет почти объективно оценить приоритетность задач (данные никогда не будут точны на 100%, но об этом поговорим ниже).

Минусы:

• Использование RICE, требует знание основ SMART.
• Модель не учитывает зависимости параметров. Например, очень трудозатратную задачу, важную для многих клиентов, откладывают и отдают предпочтение множеству задач, которые будут иметь то же влияние на клиентов по сумме, но могут оказаться потенциально дешевле;
• При оценке трудозатрат приходится просчитывать риски: поведут ли себя систему некорректно, «выпадут» ли разработчики из процесса, как отреагируют на доработку пользователи и так далее. Все оценки будут субъективными, и это — дополнительная сложность.

SMART

SMART позволяет прикинуть будущий результат и определить чёткие шаги к нему, оценить ресурсы и соответствие стратегии компании, сформулировать задачи с точки зрения бизнес-ценности по шести параметрам:

• Specific — точно определённая;
• Measurable — измеримая;
• Achievable — достижимая;
• Relevant — релевантная;
• Time Bound — ограниченная во времени; оптимальный срок выполнения — три, шесть или 12 месяцев.

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

Несколько преимуществ постановки целей с помощью SMART метода:

1. Пять критериев исключают неоднозначные формулировки, помогают оперативно ответить на любые вопросы.
2. Метод не требует времени на изучение.
3. Метод даёт возможность распределять задачи между подразделениями и отдельными сотрудниками.

Основной минус SMART в том, что при постановке цели нельзя точно сказать, достижима она или нет. Мы вводим параметры измеримости, достижимости и релевантности, но они основываются только на наших представлениях о сроках и успешности данной задачи.

Шесть сигм

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

Процесс выглядит так.

Отбираем первую задачу

Первый проект должен решать важную проблему и гарантировать реальную коммерческую результативность. И быть успешным, краткосрочным и «показательным». Его отбирают по нескольким критериям:

• экономическая целесообразность — максимальный доход/экономия;
• реализуемость — наличие необходимых ресурсов;
• вероятность успеха — субъективный критерий для мотивации команды на успешную реализацию;
• охват — вовлечение в процесс небольшого количества бизнес-процесса;
• безопасность — снижение воздействия на соседние бизнес-процессы;
• стоимость реализации.

В зависимости от первоначальных условий количество и значимость критериев могут меняться.

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

Планирование действий

Это даёт следующие преимущества:

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

Планирование действий разбивается на 6 стадий:

1. Определяем меры, необходимые для реализации проекта/задачи.
2. Оцениваем, сколько времени уйдёт на каждую задачу и подзадачу.
3. Считаем, сколько ресурсов уйдёт на каждую задачу. Сделать это до старта проекта особенно важно.
4. Уточняем показатели, по которым будем оценивать успешность работы.
5. Проверяем сроки и корректируем план.

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

Я собрала методологии, которые считаются наиболее успешными. Но признаю, что у каждого руководителя проектов может быть свой взгляд на тему — и любимая методология, которая лучше всего подходит ему/ей и его/её проекту.

Успехов в развитии и совершенствовании навыков. Экспериментируйте для достижения результатов!

1. Состав команды разработки

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

2. Коммуникация

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

3. Лидерство

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

4. Оценка производительности

Необходимо определить критерии оценки производительности, такие как качество кода, сроки выполнения задач и вовлеченность в проект. Оценка производительности позволяет выявлять проблемы в работе команды и принимать меры для улучшения процессов.

5. Процессы (методологии) разработки

Выбор подходящего процесса (методологии) разработки определяет весь ход работ по проекту. Каждый процесс разработки имеет свои преимущества и недостатки, и важно выбрать подходящий процесс разработки, который соответствует требованиям проекта и возможностям команды. Agile, Waterfall, DevOps и Lean – это наиболее популярные процессы разработки, каждый из которых имеет свои уникальные особенности.

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

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

   DevOps – это процесс разработки, который объединяет разработку и операции в один единый процесс. DevOps предоставляет команде возможность автоматизировать процессы разработки и развертывания, что может повысить скорость доставки продукта и снизить риски. DevOps также предоставляет команде возможность более тесно сотрудничать между собой, что может помочь в снижении ошибок и улучшении качества продукта.

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

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

6. Управление изменениями

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

7. Управление рисками

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

8. Обучение и развитие команды

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

9. Конфликты

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

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

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

Релизы — это хороший инструмент для повышения лояльности клиентов. У пользователей складывается ощущение, что продукт постоянно развивается и никуда не пропадёт. Добавление новых фич по просьбе клиента создаёт впечатление, что компания слышит пользователей.

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

Как мы «собираем» релиз: объясняю на кубиках Lego

Наш продукт — облачный сервис деск, который работает на базе платформы. Мы работаем с малым и средним бизнесом и предоставляем два вида тарифов: младший и старший. Для пользователей младшего тарифа доступна базовая конфигурация, а для пользователей старшего дополнительно — возможность подстроить базовые процессы под свои индивидуальные потребности и особенности.

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

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

Из чего состоит релиз

Редко, но метко

В сегменте B2C-продуктов, клиент не сильно зависит от сервиса — не доставляет «Пятёрочка», значит, доставит «Самокат». Это даёт возможность компании обновлять свои приложения часто, прнося минимальные изменения.

При работе в сегменте с B2B-клиентами, это привносит свои особенности:

• Цена некорректных изменений

Для компании B2B-продукт не является просто продуктом, он является инструментом работы. Некорректные обновления могут привести к остановке работы всего предприятия, что может привести к убыткам, достигающим нескольких миллионов.

• Цена остановки работы системы

Во время релиза работа сервиса приостанавливается, следовательно, в компаниях опять встаёт рабочий процесс, что несёт за собой убытки.

• Сложность интерфейса

B2C-приложения просты в использовании: там есть корзина, магазин и окошко для оплаты. Но в B2B-сервисах все гораздо более сложно, поскольку имеется множество различных процессов, подпроцессов и их взаимодействие.

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

С разделением на тарифы

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

Сразу и для всех

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

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

Из каких этапов состоит релиз

Обеспечивать качество релизов нам помогают следующие этапы:

Этап №1. Планирование и распределение задач

Реализация всех запросов пользователей может показаться самым логичным выходом в B2B, где вес клиента большой. Однако, процесс планирования и распределения задач может быть понятен только с одной стороны.

Но на деле всё гораздо сложнее. Как этот процесс проходит у нас, расскажем уже в следующей статье.

Этап №2. Выбор версии платформы

Мы работаем на базе конструктора, он привносит новые инструменты и технологии. Они касаются администрирования сервиса и интерфейса.

Когда мы выбираем версию конструктора, мы учитываем несколько моментов:

• Продуктовая составляющая — ориентируемся на те фичи, которые помогут улучшить нашу систему;
• Инфраструктурная составляющая — DevOps команда убеждается, что сервис будет работать в облаке;
• Сама платформа — мы выступаем потребителями другого продукта. У него есть свои релизные процессы, которые тоже важно учитывать.

Этап №3. Тест версии

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

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

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

Кейс, после которого появился этап теста версии

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

Этапы №4, 5 и 6. Аналитика и реализация и тестирование задач

Обдумывание ценности всего продукта

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

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

Это позволяет нам сделать зум-аут — посмотреть на продукт на расстоянии — создать цельное и масштабируемое решение, которое закроет сразу много потребностей клиента.

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

Круговорот знаний в команде

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

• Во-первых, команда понимает, как пользоваться каждой отдельной фичей и это позволяет не концентрировать все знания в одном человеке. Это особенно важно в период пост-релиза, когда необходимо помочь клиентам разобраться в новых возможностях системы.
• Во-вторых, в работе всегда присутствует «человеческий фактор». Не всегда человек может заметить какие-то ошибки и исправить их на этапе реализации.

Этап №7, 8. Перенос на предэталонный стенд и повторный тест задачи

У нас есть три стенда, которые участвуют в подготовке релиза:

• Develop-стенд — на этом стенде мы тестируем работу продукта на новой версии платформы, проектируем и тестируем изменения в продукте;
• Предэталонный стенд (Prototype) — внутренний стенд с актуальной версией продуктовой конфигурации;
• Эталонный стенд — внешний стенд, с которого и запускаются клиенты. На него мы переносим обновления, только когда релиз полностью готов.

На этом этапе мы тестируем уже не просто разрозненные задачи — как мы делали на Dev стенде, а их взаимодействие между собой. Делаем мы это на предэталонном стенде.

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

Этап №9. Написание инструкций и готовых ответов

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

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

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

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

Этап №10. Повторное тестирование версии

На этом этапе мы имитируем автоматическое обновление платформы, для того чтобы убедиться, что при комплексном обновлении ничего не «полетело».

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

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

Этап №11. Update-стенды

Update-стенды — копии стендов крупных клиентов. Заказчики предпочитают делать пробное тестирование их копий в течение двух недель для нашего и их спокойствия.

Update-стенды позволяют клиентам понять, что процессы работают как надо. Для того, чтобы обновить свои внутренние инструкции или запланировать задачи на доработку личных процессов, можно ознакомиться с изменениями.

Этап №12. Перенос на эталон

Этот перенос уже идёт автоматически, вручную мы ничего не делаем. С этого этапа и поднимаются новые триалы — новая конфигурация идёт новым клиентам, которые приходят уже после этого релиза.

Этап №13. Подготовка вебинара релиза

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

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

Этап №14. Массовое обновление 10% стендов

Мы начинаем обновление всего с 10%, чтобы убедиться, что всё работает корректно.

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

Этап №15. Массовое обновление пользователей на младших тарифах

Через неделю мы обновляем младшую конфигурацию на всех младших тарифах.

Этап №16. Массовое обновление всех стендов

Если обновление на младших тарифах прошло успешно, то мы обновляем все стенды.

Этап №17. Сбор обратной связи

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

Этап №18. Сбор аналитики

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

Этап №19. Отмечаем релиз

… а дальше начинаем всё по новой.

Вывод

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

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