[2/4] Панельная дискуссия про влияние AI на разработку софта (Рубрика #AI)

Продолжая рассказ про вопросы панельной дискуссии поделюсь мыслями про первые два вопроса
1. Что изменилось в разработке из-за AI?
2. Как повышать adoption AI? Сверху или снизу?

1. Реальные изменения в разработке под влиянием ИИ
Я рассказывал примерно про это в своем докладе "Интегрируем AI в процессы разработки в большой компании" на CTO Conf. Но если говорить кратко, то ещё пару лет назад ИИ-инструменты в программировании казались диковинкой, а сегодня ими пользуется подавляющее большинство разработчиков. Согласно отчёту DORA 2025, 90% технологических специалистов теперь ежедневно применяют ИИ при разработке – от программистов до продакт-менеджеров. Что же изменилось на практике? Разработчики ощутили ускорение рутинных задач. Генерация типового кода, шаблонов, тестов и документации теперь зачастую делегируется ИИ. По данным DORA, одни из самх распространённых кейсов
- Написание нового кода
- Модификация существующего (аля миграции кода)
- Генерация тестов
- Написание документации с помощью ИИ

Вместе с тем реальный эффект пока далёк от утопического кратного ускорения - улучшения есть, но пока не революционные. Если в прошлом году в отчете DORA наблюдалось даже замедление из-за внедрения ИИ (команды не успевали адаптироваться), то теперь ситуация выправилась: DORA-2025 впервые зафиксировал рост скорости выпуска софта при увеличении использования ИИ. При этом качество и стабильность выпуска остаются вызовом. DORA отмечает, что хотя throughput вырос, нестабильность и число сбоев по-прежнему повышены. Это ожидаемо: сначала все гнались за скоростью, теперь надо подтянуть качество.

2. Внедрение ИИ: стихийно «снизу» или управляемо «сверху»?
Практика показывает, что инициатива внедрения ИИ часто идёт “снизу” – от самих разработчиков. После появления массовых инструментов типа ChatGPT, Copilot и пр., инженеры начали экспериментировать с ними задолго до официальных указаний. Например, исследование Microsoft показало: 3 из 4 сотрудников уже используют ИИ в работе, причём ~80% делают это через личные, “принесённые из дома” инструменты (BYOAI). И в крупных корпорациях доля тех, кто самовольно внедряет ИИ, достигает 78%. То есть повсеместно возник феномен «Bring Your Own AI»: люди подключают в рабочие процессы сторонние ИИ-сервисы, зачастую без ведома ИТ-отдела и руководства. Так было с личными гаджетами (BYOD) в прошлое десятилетие, теперь то же самое – с ИИ-инструментами. Про это было исследование "The GenAI Divide: State of AI in Business 2025" от MIT, что я уже разбирал.

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

Мне кажется, что лидерам нужно курировать, а не подавлять энтузиазм инженеров. Нужен открытый диалог о целях ИИ, обучение, внутренние «песочницы» для проб и централизованные меры безопасности позволяют превратить разрозненные инициативы в управляемую трансформацию. В конечном счёте, оптимальный подход – гибридный: воспользоваться импульсом “bottom-up”, подкрепив его стратегией и контролем “top-down”. Тогда ИИ внедряется не хаотично, а в русле общих целей, и компания извлекает максимум пользы без лишних сюрпризов. Это похоже на подход предложенный для развития экономики агентов в whitepaper "Virtual Agent Economies" от Google, который я уже разбирал. Там предложено проактивный дизайн правил и инфраструктуры для агентных рынков. Если это переносить на SDLC, то нам нужны понятные правила и дизайн использования внутренних AI инструментов vs внешних моделей/инструментов. Это нужно для пилотирования новых возможностей и понятных правил перехода в продакшен этих наработок

#AI #Engineering #Architecture #ML #Software #Economics #Software

[3/4] Панельная дискуссия про влияние AI на разработку софта (Рубрика #AI)

Продолжая рассказ (1 и 2) про панельную дискуссию поделюсь оставшимися темами и начну с рисков.

3. Возможности vs риски: как балансировать ускорение и угрозы
Преимущества ИИ в разработке очевидны и заманчивы. Главные драйверы, которые называют компании: повышение производительности, ускорение релизов и сокращение издержек. Но это тянет за собой шлейф рисков
- Риски качества и ошибок. ИИ склонен “галлюцинировать” – давать уверенные, но некорректные ответы. Разработчики жалуются, что много времени уходит на отладку кода, который почти рабочий. Здесь стратегией может быть создание дополнительных проверок. Автотесты, статический анализ, линтеры – обязательны даже для сгенерированного кода (особенно для него!). Некоторые компании идут дальше: обязывают помечать или ревьюить весь код, внесённый с помощью ИИ
- Риски для организации и процессов. Без грамотного подхода ИИ может усилить узкие места. Например, DORA предупреждает: если компания страдает от устаревших процессов, технического долга, недостатка автоматизации, то ускорение разработки через ИИ приведёт к лавинообразному росту проблем – больше сырого кода вольётся в те же кривые пайплайны. В итоге, в таком случае помимо внедрения AI-инструментов надо заниматься развитием платформы разработки и инженерных процессов.
- Конфиденциальность и безопасность данных. ИИ-инструменты часто требуют отправки исходного кода или данных на внешние сервисы. Для финансовых компаний это красный флаг. Такие компании разворачивают AI решения локально и дорабатывают их под свои сценарии. Если у вас есть договорные отношения с провайдерами LLM моделей, то вы можете попробовать решить эту проблему на уровне договоров.
- Vendor lock-in. Сейчас рынок ИИ-платформ в основном контролируется несколькими игроками – OpenAI (Microsoft), Google, Anthropic и т.д. Если команда плотно подсаживается, скажем, на GitHub Copilot, возникает зависимость, поэтому крупные фирмы стараются диверсифицировать и держать контроль. Практика больших компаний – развивать внутреннюю экспертизу и/или использовать сервисы разных провайдеров (что умножает косты)
- Компетенции команды и “атрофия навыков”. Ирония: мы хотим, чтобы команда работала быстрее с помощью ИИ, но боимся, что от этого люди перестанут расти как профессионалы. Здесь все завязано на обучение сотрудников и мотивацию их не просто копировать ответы модели, а разбираться с ними и понимать как и почему это работает.

4. Как меняются процессы разработки и состав команд?
Широкое внедрение ИИ уже начинает менять структуру и роли в командах разработки. Есть прогноз, что в ближайшие годы потребность в тестировщиках и аналитиках снизится, а число инженеров-разработчиков в штате вырастет.
- Почему меньше тестировщиков? Традиционное ручное тестирование – один из процессов, наиболее поддающихся автоматизации ИИ. Современные инструменты способны сами генерировать тестовые сценарии, подбирать edge-cases и даже поддерживать тесты актуальными при изменении кода.
- Почему меньше аналитиков? Под словом аналитики здесь можно понимать бизнес-аналитиков, системных аналитиков – тех, кто переводит бизнес-требования в ТЗ, прорабатывает спецификации. ИИ начал постепенно отъедать и эту часть работы.

Уже сегодня влияние ИИ ощущается на командных ролях: разработчики становятся центром процесса, опираясь на ИИ, они берут на себя часть задач тестирования и аналитики; тестировщики и аналитики трансформируются в более технические и совмещённые роли, а еще возникают новые позиции. Для бигтеха и финтеха это шанс оптимизировать структуры команд и повысить эффективность, но успех зависит от переподготовки людей. Роль человека будет смещаться к тому, чтобы решать нестандартные проблемы, принимать продуктовые решения и направлять ИИ, в то время как ИИ возьмёт на себя больше рутины. Команды станут более “умными” и кросс-функциональными, а люди – более универсальными.

Окончание будет в финальном посте.

#AI #Engineering #Architecture #ML #Software #Economics #Software

[4/4] Панельная дискуссия про влияние AI на разработку софта (Рубрика #AI)

Заканчивая рассказ (1, 2 и 3) про панельную дискуссию расскажу про последние две темы

5. Есть ли доверие к возможностям AI или это просто хайп?
Несмотря на все успехи, в индустрии ощущается неоднозначное отношение к ИИ-инструментам. С одной стороны, все публично говорят о стратегиях AI-first и как нейросети влияют на эффективность. С другой – в кулуарах многие инженеры и менеджеры признают, что не до конца доверяют этим решениям и иногда «делают вид, что поддерживают тренд», подстраиваясь под моду. Где же граница между реальной верой в технологию и имитацией энтузиазма?
Объективно уровень доверия снизился по сравнению с ажиотажем первых лет. По данным опросов, доля разработчиков с явным позитивным отношением к AI-инструментам в 2025 снизилась до ~60%, тогда как в 2023 была > 70%. То есть первоначальный восторг поостыл, пришло понимание ограничений. Отчёт DORA говорит о «парадоксе доверия»: хотя 90% используют ИИ, только 4% полностью ему доверяют и лишь 20% доверяют «значительно». Около 30% вообще признают, что доверия мало либо нет. Другими словами, почти все считают ИИ полезным, но почти никто не считает его безошибочным. В итоге, сейчас многие следют поговорке "доверяй, но проверяй" - для высокорисковых операций все еще нужен human in the loop, а вот менее рисковые операции пытаются поручить условным AI-агентам с возможным пост-контролем (на дизайн ревью, на код ревью, на этапе тестирования). В общем, люди все еще неотъемлемая часть процесса

6. Что ждет разработку на горизонте 3х лет? Сингулярность наступит или хайп схлопнется?
Заглядывая на 3 года вперёд, можно с уверенностью сказать: ИИ всё глубже проникнет во все фазы жизненного цикла разработки ПО, хотя степень этой интеграции будет зависеть от зрелости самих организаций. Текущие тренды указывают, что ИИ из разрозненной “полезной приблуды” превращается в неотъемлемую часть инструментов разработчика – подобно тому, как когда-то системы контроля версий или CI/CD стали стандартом.

Уже сейчас ИИ задействован на многих стадиях: планирование и дизайн (ИИ-генерация требований, создание дизайна, наброски архитектуры), кодирование (автодополнение, генерация кода по текстовому описанию(аля агенсткий режим)), тестирование (автогенерация тестов, поиск багов), деплоймент и сопровождение (AIOps – прогнозирование инцидентов, автоскейлинг, анализ логов). Пока эти применения часто точечные – каждая команда сама прикручивает отдельные сервисы. Но в будущем можно ожидать более плотного сквозного встраивания ИИ во все процессы SDLC. DORA прогнозирует, что ИИ трансформирует каждый этап жизненного цикла, от дизайна до поддержки. Это значит, появятся интегрированные решения: скажем, ваш таск-трекер сразу подсказывает с помощью ИИ уточнения к требованию; среда разработки автоматически генерирует не только код, но и тесты (а может еще и тестовый стенд поднимает); AI SRE инженер мониторит системы и сам фиксит инцидент на проде, а потом пишет постмортем с анализом причин аварии.

Важный фактор – развитие самих моделей ИИ. Если за 2023–2025 мы видели скачок от “слегка помогающих” моделей к решениям, которые уже могут решить ~70% стандартных задач по кодированию, то к 2028–2030 можем увидеть еще более умных помощников. Скорее всего возникнет множество специализированных моделей: отдельные для генерации UI, отдельные для оптимизации баз данных, для миграции легаси-кода и т.п. Такие узко заточенные ИИ, работающие в составе единой экосистемы, сделают присутствие AI незаметным, но постоянным на всех стадиях.

А как же стартапы? У молодых компаний своя динамика: они чаще сходу “AI-native” – используют ИИ на всех участках, где можно, чтобы компенсировать малый штат. Им проще интегрировать новейшие технологии без бюрократии. Уже есть примеры стартапов, где значительная часть кода генерится ИИ, тестирование полностью автоматизировано AI-платформами, а люди фокусируются на уникальной логике.

#AI #Engineering #Architecture #ML #Software #Economics #Software

[1/2] AI в SDLC: путь от ассистентов к агентам (Рубрика #AI)

Сегодня с таким докладом я выступал на конференции AI Boost от Surf. В этом посте я тезисно расскажу о самой сути выступления, а также поделюсь всеми материалами для дополнительного изучения. И начать нужно с того, что это выступление продолжает мое предыдущее "Интегрируем AI в процессы разработки в большой компании", которое задавало рамку и неплохо показывало как и куда стоить идти при внедрении AI. Но в этот раз я сделал фокус на агентах. И начал я с того, что вспомнил про GitHub Copilot и Cursor, которые скорее известны как ассистенты инженеров. И принятие этих инструментов уже произошло, но потом появились Claude Code и OpenAI Codex, которые заявили о себе как об агентских системах для инженеров (сам я экспериментировал с OpenAI Codex и мне понравилось). И кажется, что это gamechanger, так как если агентские системы заработают успешно, то им можно будет делегировать часть jobs to be done сценариев, которые раньше делали люди (пока эти системы зачастую работают не достаточно хорошо). Для улучшения работы этих систем Anthropic и Google придумали соотственственно протоколы MCP и A2A, про которые я уже рассказывал, то есть инфраструктура постепенно собирается.

Есть и экономическое предпосылки перехода к агентами
- Инвестиции в AI: с 2023 года в инструменты ИИ-программирования вложены миллиарды долларов, а компании ожидают отдачи
- Давление на эффективность: Компании ищут пути ускорить разработку и снизить издержки
- Провайдеры AI технологий обещают манну небесную: топ-менеджеры в компаниях-потребителях ждут отдачи инвестиций

И даже есть компании, где такие системы выдают топ-левел результаты - это я про Google с их агентской системой AlphaEvolve (см. мой разбор), где были получены ощутимые результаты
- Повышение эффективности дата-центров: AlphaEvolve разработал эвристику для оркестратора Borg, которая непрерывно восстанавливает в среднем 0,7% мировых вычислительных ресурсов Google.
- Оптимизация чипов: система предложила переписать код Verilog для удаления избыточных битов в арифметической схеме умножения матриц, что было интегрировано в новую версию TPU.
- Ускорение обучения LLM моделей: AlphaEvolve ускорил ключевой компонент архитектуры Gemini на 23%, что привело к сокращению времени обучения Gemini на 1%

На фоне этого уважаемые ученые рассматривают вопросы будущего, например
- "Future of Work with AI Agents" от Stanford, где ребята задались вопросом а что можно уже агентизировать, а также что люди хотят передать машинам, а также как поменяется рынок труда в результате (см мой разбор)
- "Virtual Agent Economies" от Google, где ребята размышляли про экономику, где агенты могут выполнять и координировать работу автономно. Ученых интересовала как это повлияет на нашу привычную экономику и как сделать так, чтобы мы могли управлять этими изменениями (см мой разбор)
- "Towards AI-Native Software Engineering (SE 3.0)", где авторы размышляют про изменение индустрии разработки до третьей версии, где первой было стандартное написание кода, второй - написание кода с ассистентами, а третье - это уже агенты во всей красе с intent-first разработкой. Разбор этой статьи у меня на подходе, но пока вы можете почитать оригинал

Как может выглядеть агентский режим в реальности (у нас в Т-Банке) стоит посмотреть на демках, которые есть и в моем докладе и в уже опубликованном докладе Стаса Моисеева, моего коллеги, который рассказывал об этом и не только на Big Tech Night (см мой разбор). Но для получения эффекта от AI просто агентского режима не хватит - надо работать фокусно по jobs to be done сценариям, что выполняют инженеры в рамках своей работы. Подробнее про это, а также про измерение эффекта будет в продолжении.

#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy

[2/2] AI в SDLC: путь от ассистентов к агентам (Рубрика #AI)

Продолжая рассказ о своем докладе, поделюсь своими мыслями о том, как подходить к AI-фикации разработки, которые основаны на whitepaper Measuring Developer Goals. В этой статье авторы рассказывали о том, что понимание и эффективное измерение целей критически важно для улучшения опыта разработчиков и повышения их эффективности. Для ответа на вопросы о продуктивности удобнее привязывать измерения не к конкретным инструментам, а к тем целям, которые разработчики ставят перед собой при использовании инструментов. Это позволяет отвечать на вопросы, похожие на те, что приведены выше, сохраняя метрики ориентированными на пользователя, а не инструмент. Подробный разбор в блоге, а также есть восьмая серия подкаста Research Insights Made Simple, где мы разбирали эту статью с Сашей Кусургашевым, моим коллегой, что руководит разработкой Spirit (наша внутренняя платформа разработки). Вообще, может быть полезна вся серия статей про "Developer Productivity for Humans", которуя я разбирал в двух постах (1 и 2).
Если привязывать эти идеи к внедрению AI в разработку, то ясно, что надо фокусироваться на главных jobs to be done сценариях, которые массовые/проблемные - помогая с ними можно получить максимальный эффект. Причем начинать стоит с AI-assisted вещей, а по мере улучшения ассистирования двигаться в сторону делегирования всего сценария агенту (правда, тут придется поработать с подготовкой контекста, настройкой evaluation, изменениями в процессах работы людей). И по мере изменений надо уметь измерять эффекты от этих улучшений так, чтобы показывать результаты топ-менеджерам (а они любят цифры).

Про измерения продуктивности (как и зачем) я уже рассказывал раньше, но там были классические DORA, SPACE, DevEx. А в последнее время я пристально наблюдаю за платформой для измерения продуктивности DX, которая была основана теми, кто развивал предыдущие подходы. Эти ребята сделали систему с опросами и интеграцией с системами типа Jira, Wiki, git, CI/CD, ... В общем, ребята придумали свой фреймворк DX Core 4 для измерения инженерной продуктивности (см мой текстовый разбор + разбор в моем подкасте с Женей Сергеевым из Flo), а в этом году они же расширили его веткой для измерения эффективности AI ассистентов и агентов (см мой текстовый разбор + разбор в моем подкасте с Женей).
По-факту, эффективность AI ассистентов и агентов можно измерять с точки зрения трех направлений
1) Utilization - отслеживание внедрения и использования AI-инструментов (DAU, MAU, % сгенерированного кода, % PR с AI ассистированием, ...). Обычно с этого начинаются измерения, так как эти показатели измерить проще, чем те, что в следующих пунктах (Impact, Cost)
2) Impact - измерение реального эффекта на производительность (экономия времени разработчиков, PR throughput, percieved rate of delivery, ...)
3) Cost - отслеживание затрат и чистой прибыли
У ребят из DX есть бенчмарки по этим метрикам, которые они предоставляют клиентам DX платформы.

Если говорить про наш подход в Т-Банке, то мы умеем мерить первый уровень Utilization, а также у нас внедрен фреймворк SPACE для оценки developer productivity. Это позволдяет нам двигаться в сторону оценки Impact. Кстати, про наш фреймворк SPACE ребята рассказывали на IT Пикнике и вот разбор этого выступления. Но если у вас не внедрены инструменты для измерения developer productivity в компании, то не стоит грустить. Уровень утилизации можно измерить относительно просто, а большего вам может быть и не надо - сейчас разработка революционно меняется за счет использования AI-ассистентов и AI-агентов, а значит можно не вкладывать кучу сил в измерения старого подхода к делу, а экспериментировать с новым. Условно, не стоит обмерять деревянное колесо диллижанса, если у нас уже его вытесняет металлическое колесо машины:)
Ну а если хочется бенчмарков, то можно поучаствовать в нашем Большом исследовании AI в инженерной культуре России.

#Software #Engineering #Productivity #DevEx #AI #Management #RnD #Leadership #Economy

Podlodka Techlead Crew про архитектурные антипаттерны (Рубрика #Architecture)

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

В программе конференции будут следующие выступления
- От спагетти кода к доменной модели: критерии выбора между Transaction Script, Active Record, DDD и Clean Architecture, практический взгляд Кирилла Ветчинкина (Авито).
- AI для архитектора: валидация требований, поиск зависимостей, возможность ускорения архитектурного ревью с AI в интервью с Тимуром Баюровым (Т-Банк). Кстати, Тимур многое делает для проникновения AI в архитектурные процессы Т-Банка.
- Архитектура хранилища данных для вашего проекта: советы от Евгения Ненахова (МТС Web Services).
- Еда, EDA и C4 — выбери 3 из 3: практический воркшоп по Event-Driven Architecture и отказоустойчивости с разметкой в C4 проведёт Владимир Невзоров (автор канала System Design World).

Конференция пройдет на неделе с 13-17 октября и может принести вам много пользы, если вы связаны с проектированием и разработкой софта. Подробности здесь.

P.S.
Спасибо ребятам за то, что пошарили информацию о нашем исследовании AI в инженерной культуре России.

#Architecture #DistributedSystems #Software #Engineering #Processes #AI

Эволюция метрик и практика применения SPACE (Рубрика #DevEx)

Мои коллеги Саша Кусургашев и Дима Гаевский на IT Пикнике летом рассказывали про то, как мы используем фреймворк SPACE для оценки продуктивности инженеров. Недавно появилась запись выступления Саши (который отдувался за двоих) и я решил поделится кратким саммари этого рассказа.

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

Собственно, первая половина доклада была про сам фреймворк "SPACE", где рассказ строился на статье "The SPACE of Developer Productivity", о которой я уже рассказывал раньше. Сам акроним SPACE расшифровывается как
- Satisfaction & Well being (удовлетворённость)
- Performance (результативность)
- Activity (активность)
- Communication & Collaboration (коммуникация)
- Efficiency (эффективность)
Каждое из этих измерений дополняет остальные, создавая целостную картину. В выступлении отмечалось, что такой многомерный подход родился как реакция на злоупотребления однобокими метриками и нацелена на то, чтобы сделать оценку работы инженеров более справедливой и осмысленной.

Вторая часть доклада была посвящена опыту внедрения SPACE и мне она кажется самой полезной частью выступления. Саша рассказал с чего начать сбор метрик и как интерпретировать.Внедрение многомерной системы измерений оказалось непростой задачей – потребовалось агрегировать данные из разных источников (систем контроля версий, трекеров задач, CI/CD, опросов сотрудников и пр.) и привести их к единой основе для сравнения. Авторы подчеркнули важность нормализации данных и правильных «разрезов» – нужно решать, по каким сечениям анализировать метрики (по командам, по проектам, по временным периодам), чтобы выявлять закономерности и проблемные зоны. Это оказалось нетривиально: разные сегменты показывали разную картину, и неправильный выбор среза мог скрыть проблему или создать иллюзию успеха. Например, сравнение по командам требует учёта специфики проектов; сравнение по времени – учёта сезонности и изменений обстоятельств.

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

Из выступления можно забрать такие мысли
1) Комбинируйте объективные метрики с обратной связью от людей
2) Используйте метрики как инструмент для улучшения, а не для наказания. Стоит выявлять узкие места и точки роста, а не устраивать «соревнование разработчиков» или повышать бюрократию
3) Вводите метрики постепенно и осмысленно. Начать с пилотной команды или направления, выбрать небольшое подмножество SPACE-метрик, относящихся к наиболее болезненной проблеме, и опробовать их в деле
4) Важна роль культуры и поддержки руководства. Внедрение SPACE – это не разовая акция, а изменение подхода к управлению

#Processes #Management #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SRE

The Software Engineer's Guidebook (Разработчик ПО: Путеводитель по карьерной лестнице для будущих сеньоров, техлидов и стаффов) (Рубрика #Engineering)

Недавно дочитал книгу Гергели Ороша, автора рассылки "The Pragmatic Engineer", бывшего engineering менеджера в Uber и разработчика в Skype/Microsoft и Skyscanner. Я уже рассказывал про эту книгу раньше, когда я только начинал ее читать. Теперь, после прочтения, я могу поделиться кратким саммари.

Книга хорошо подходит для инженеров, которые хотят пройти по всем ступенькам от джуна до стафф+ инженера - часть материалов адресована всем уровням, а дальше блоки для middle → senior → tech lead → staff идут по нарастающей. Автор отдельно замечает, что книга полезна и менеджерам, особенно тем, кто старается оставаться «hands‑on». Книга разбита на отдельные темы + есть бонусные онлайн-главы
- Базовые принципы карьеры - пути развития, «владение» своей карьерой, performance‑review, промо, как работать в разных средах (стартап/BigTech), смена работы.
- Компетентный разработчик - как доводить задачи до результата, написание кода, процесс разработки, инструменты продуктивного инженера.
- Senior инженер - взаимодействие и командная работа, инженерные практики, тестирование, архитектура.
- Техлид (не важно должность это или роль) - проектное управление, выпуск в прод, управление стейкхолдерами, структура и динамика команды.
- Staff/Principal - понимание бизнеса, влияние без полномочий, надёжность и архитектура.
- Заключение + онлайн‑«бонус‑главы» к предыдущим частям
Книгу можно использовать как настольный справочник и читать точечно, в нужном месте.

Мне показались интересным советы о карьере, которые повышают осознанность и успешность движения по карьерной лестнице
- "Владейте своей карьерой" - ведите журнал выполненных задач, регулярно просите обратную связь и делайте менеджера союзником — это прямая инвестиция в промо.
- Готовьтесь к performance‑review готовятся заранее - начинайте собирать контекст и артефакты за месяцы до ревью, помогая менеджеру и калибровке.
- Промо ≠ просто "побольше сделать" - эффект конечно важен, но также нужно демонстрировать компетенции следующего уровня и координировать сложные инициативы.
- Среда имеет значение - BigTech и стартапы требуют разных стратегий; выбирайте то, что лучше под ваши цели и этап

В принципе, есть и другие похожие книги для IC и engineering managers, о которых я уже рассказывал
- Will Larson "Staff Engineer: Leadership Beyond the Management Track" - про то, как расти и работать на staff‑ветке без ухода в менеджмент (см. мой обзор)
- Tanya Reilly "The Staff Engineer’s Path" - подробное руководство по роли staff‑инженера: стратегия, влияние, стандарты качества (см. мой обзор)
- Camille Fournier "The Manager’s Path" - путь инженера в engineering менеджеры (см. мой обзор)
- Will Larson "An Elegant Puzzle" - системный взгляд на инженерный менеджмент и организационные решения (см. мой обзор)

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

#Engineering #Management #Leadership #Processes #Software #Career #Staff #Career #Architecture

У наших аналитиков в Т есть подкаст InSAйт, куда они зовут гостей обсуждать интересные темы. Второй сезон заканчивался темой "У системных аналитиков нет комьюнити: миф или реальность", куда ребята позвали гостем Анастасию Кабищеву, Head of project management office компании Ekleft, консультанта по психологической безопасности команд, а также мою жену. В итоге, я не мог ни рассказать об этом подкасте - рекомендую его к прослушиванию всем, кто занимался темой построения коммьюнити.