Управление разработкой *

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

Добро пожаловать в 50% IT-компаний во вторую статью цикла про онбординг в сложную систему!

В этой статье превратим плоский список репозиториев в рабочую onboarding-map: сначала определить роли, потом соберем dependency matrix, а затем получим relationship diagram.

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

Почему Agile‑команды скатываются в неконтролируемый хаос, а проекты на Waterfall годами пилят никому не нужный продукт? Спойлер: проблема не в методологиях, а в нас самих. Вы узнаете, как сильные команды совмещают лучшие практики обоих миров, почему Contract‑First и Trunk‑based Development спасают даже в Agile.

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

Меня зовут Сергей Павлов. Я разработчик, тимлид и CTO. Сейчас отвечаю за разработку продуктов в ИТ-экосистеме Лукоморье. В этой статье я хочу помочь как разработчикам, так и начинающим руководителям увидеть обратную сторону управления.

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

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

P.S. После прочтения есть высокий риск перестать быть «своим парнем» и начать работать на результат. Вы предупреждены.

Меня зовут Игорь, я тимлид в e-commerce. Когда у меня появилась вторая команда, стало понятно, что вручную следить за двумя Jira, двумя GitLab и метриками одновременно — нереально. В итоге сделал инструмент, который собирает всё в одном месте

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

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

Рассказали мне историю. Поучительную, спешу поучить.

По АйАйному нетелеграму пронёсся хайптрейн про СУПЕРСИЛЫ, которые дадут вам СУПЕРСИЛЫ. Открывается вращением. Обещается набор скилов для вашего Клода, который поднимет культуру разработки на недосягаемую высоту, внедрит полный фарш передовых опытов SDL прямо в контекст агентов и сформирует вам персональную инжиниринговую армию из бренштормов, продактов, фасилитаторов, SDD, TDD, ИТД.

Знакомец повёлся.

Красиво загрузил. Красиво запустил. Красиво поговорил с продактом и архитектором, получил миллион страниц красивых букв и красиво сказал — выпекай. Seven Agent Army ушла в глубокий red-green-refactor с элементами пурпура, написала доков, тестов и кода ещё на миллионы токенов, кряхтела, шуршала два дня — но так и не выдала ничего, что просто работало бы и отдалённо напоминало задумку или хотя бы документ. Тесты при этом моргали зелёным. Архитектура была в полном SVG.

Не работало.

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

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

Для меня — ожидаемо. Знакомец, как оказалось, не сталкивался с модными блестящими бадишопами, которые в соответствии с передовыми практиками жгут человеко-часы тайма и матирьяла передового опыта, не выдавая почти ничего. С этой точки зрения СУПЕРСИЛЫ отработали отлично. Хотел как у людей — получил как у людей.

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

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

ИИ не устранил необходимость в менеджменте. Он устранил часть оправданий.

OpenAI выпустил Codex CLI 0.128.0 с командой /goal — автономным режимом, в котором агент сам пишет код, тестирует, рефлексирует и долбит цель часами. На практике первое, что замечаешь — счётчик токенов скачет в 3-5 раз непредсказуемо. Не вдвое — в пять. Месяц использования в команде. Главные находки: исследователи подхватили первыми (а не разработчики). При упирании в quota wall MCP-вызовы молча отваливаются. Соседняя команда /side неожиданно стала использоваться для расшифровки англицизмов GPT-5.5. В статье: разбор архитектуры /goal (5 слоёв, инжекция системного промпта против proxy signals), реальный публичный кейс — +25% fps за час в GPT-5.5 xhigh, грабли с непредсказуемыми токенами и quota walls, когда /goal стабильно ломается. Антипафос. Никакого AI-евангелизма.

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

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

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

Если склонности (модель HEXACO) отвечают на вопрос «как вы работаете?» - быстро или вдумчиво, индивидуально или в команде, с готовностью к риску или по инструкции, - то ценности дают ответ на вопрос «зачем?». Ради чего специалист встаёт утром и открывает пул-реквест.

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

«У нас было два пакета findings SAST’а, семьдесят пять CVE с критичностью — Critical, пять дублей одной и той же CVE в разных сервисах, пол солонки false positive и целая россыпь уязвимостей всех сортов и расцветок: SQLi, XSS, SSRF, RCE, IDOR, утекшие секреты, misconfigs в Kubernetes, написанные человеком, который явно не планировал дожить до аудита.

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

Не то чтобы это был необходимый запас для управления безопасностью приложений, но если уж ты решил строить ASPM через агрегацию всего подряд, рано или поздно ты оказываешься именно в такой машине — на полной скорости, без карты, с разработчиками на заднем сидении, которые только и спрашивают: “Что из этого реально надо исправлять?”». 

Всем привет! Меня зовут Артем Пузанков, я руководитель отдела консалтинга безопасной разработки в Бастионе. Сегодня хотелось бы порефлексировать с вами про управление состоянием безопасности приложений, ASPM, AI-generated код и AppSec.

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

Всем привет! Меня зовут Илья Григорьев, я старший бэкенд-разработчик в команде Телемоста. В этой статье я разберу наш опыт разработки двух фич последнего года — ИИ-конспект с Алисой Про и облачной записи на Диск. Покажу, как мы проектировали их архитектуру, почему не всё получилось с первого раза, с какими системными и техническими ограничениями столкнулись при работе с медиаданными и как в итоге выстроили пайплайн их обработки и анализа.

В боевых искусствах есть понятие боевой добродетели У‑Дэ. 

武德 (У‑Дэ) — два иероглифа: 武 (у) — боевой, воинский; 德 (дэ) — мораль, добродетель. Буквально: воинская добродетель.

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

У‑Дэ опирается на конфуцианский фундамент, ядро которого — пять добродетелей:
仁 (жэнь) — человечность,
义 (и) — справедливость,
礼 (ли) — благопристойность,
智 (чжи) — мудрость,
信 (синь) — честность.

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

У боевого мастера есть готовый кодекс, который он впитывает. У руководителя такого нет, но есть управленческая традиция — книги, наставники, ошибки. За 7 лет руководства у меня сформировались свои принципы работы. Они зрели годами — через опыт и через ситуации, в которых приходилось принимать сложные решения. Сейчас я в той точке, когда захотелось их зафиксировать, а не держать в голове. Зачем? Чтобы видеть самой и показывать лидам. Передача культуры руководителя так же важна, как и передача мастерства в боевых искусствах. 

Если вам обещают, что ИИ ускорит разработку в 5 раз — скорее всего, вам пытаются что‑то продать. Особенно если «волшебство» сводится к установке плагина в IDE.

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

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

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

Фраза «нам надо поговорить» и в жизни редко предвещает что‑то приятное. А на работе — чаще всего значит «сейчас тебя покритикуют, соберись».

Руководители используют обратную связь как инструмент давления. Или наоборот — смягчают до бессмысленности. Некоторые считают, что обратная связь вообще не нужна: «взрослые люди сами поймут».

Привет, меня зовут Николай, я 23 года в DevOps, последние пару-тройку месяцев копаюсь в архитектуре AI-агента (Hermes Agent)

В предыдущих двух статьях я разбирал, почему AI-агенты сходят с ума на длинных сессиях (сжатие контекста) и почему Chain-of-Thought это пост-хок нарратив, а не трассировка мышления. Статьи неплохо зашли, но в комментариях меня справедливо пропесочили: "нейрослоп с характерными эпитетами, очередной набор запросов к ИИ". Ну и по делу в принципе. Пишем руками, нудное это дело если честно, все равно вычитку в агента отдал в итоге.

И сегодня я расскажу про два инструмента, которые использую постоянно: Premortem и Prism. Не в теории, а на моём собственном опыте.

Prism это не моё изобретение. Это форк из Cranot/super-hermes, доработанный под мои задачи. В оригинале — пять независимых скилов структурного анализа. Premortem — вообще классика, из книги Klein «The Power of Intuition» и военной аналитики. Но я их доработал так, что это не просто "очередная методология для митапов", а работающий pipeline, который находит баги архитектуры.

Привет, Хабр. Меня зовут Кирилл Комиссаров, я работаю в IT с 2013 года, последние несколько лет — тимлидом. Сейчас руковожу командой разработки в юните саппорта в Авито.

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

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

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