Масштабирование – это всегда стресс для компании. То, что работало в небольшой команде, перестает быть эффективным, когда сотрудников становится в разы больше. И чаще всего бизнес спотыкается не о внешние обстоятельства, а о собственную неготовность управлять знаниями и процессами.
Как мы сегодня измеряем работу разработчиков: velocity, story points, lead time, cycle time, число PR и закрытых тасок. Строим красивые дашборды, считаем DORA-метрики, прогнозируем сроки, оцениваем загрузку команд.
А вот измерение инженерных решений на зачаточном уровне. В лучше случае ADR и запись в трекере техдолга. Чаще — вообще ничего.
Существующая оценка качества инженерии субъективна.
Обычно это мнение тимлида с 3–5 годами опыта в одной-двух предметных областях. При этом именно инженерные решения определяют стоимость разработки через год-два: смогут ли десять разработчиков одновременно работать над кодом и можно ли вообще масштабировать продукт без переписывания половины кодовой базы.
Сегодняшняя парадигма проста: чтобы большой проект не развалился, достаточно вытягивать DESIGN + держать выше среднего CODE QUALITY. А 2026 год показал, насколько все забивают на SECURITY, а с перформансом справляются тем, что бигтехи держат под это отдельные перф-команды: как будто уже написание (или проектирование+генерация) эффективного алгоритма больше не влияет на то, кто действительно Senior.
Бизнесу почему-то ценен разработчик, который закрывает пять задач в день (Я слышал, что в Яндексе это даже нужно для подтверждения грейда). Даже если через полгода выясняется, что каждая новая задача требует правок в двадцати файлах, а LLM не хватает контекста, чтобы просто разобраться в архитектуре проекта.
Мы научились измерять скорость разработки. Но почти не измеряем качество инженерии.
Что вообще такое инженерный уровень?
В IT основной капитал руководителя — это люди. И эти люди работают в условиях постоянного давления: меняются требования, горят дедлайны, бизнес хочет большего, неопределённости хватает на всех. В такой среде доверие к руководителю — очень важный ресурс. Его отсутствие влияет не только на атмосферу в команде, но и на её эффективность.
Меня зовут Юлия Аравина, я психолог и коуч IT-руководителей, а также наставник на курсах «Управление командой» и «Технический директор — СТО» в Яндекс Практикуме PRO. В этой статье я хочу разобрать, почему команда перестаёт доверять руководителю, за счёт чего формируется доверие и как его восстановить.
В прошлой статье я поспешил с публикацией и лишь в общих чертах объяснил, что такое Napominator Home. Сегодня, как и обещал, публикую подробное руководство, которое охватывает все этапы: от установки до ежедневного использования.
В этой статье вы узнаете, как установить систему, настроить её компоненты и пользоваться всеми функциями.
Расширенное редактирование и продвинутые ИИ-функции
Редактор изображений — встроенный инструмент, который позволяет создавать и редактировать изображения для карточек товаров прямо внутри админки магазина. Раньше функция была доступна только новым пользователям платформы, но теперь ей могут пользоваться все магазины без исключения. В редакторе можно работать со слоями, добавлять и перемещать элементы, использовать готовые шаблоны и оформлять визуал под требования маркетплейсов или интернет-магазина.
1. Открывается редактор из карточки товара по кнопке «Редактировать» на изображении: продавцу не нужно скачивать фотографии, переносить их в сторонние сервисы и затем загружать обратно.
Есть фраза, от которой у меня до сих пор дёргается глаз: «Да там ничего сложного — просто раскатим Scrum на все команды». Обычно её уверенно произносит человек, который пару недель назад сходил на двухдневный курс, получил красивый сертификат — и теперь искренне считает, что понял, как устроена разработка.
Пятнадцать лет в профессии, путь от инженера до директора разработки, до восьми команд над одним продуктом одновременно — и за это время я видел этот сценарий десятки раз. Приходит свежий «эксперт», и Scrum начинают натягивать на всё подряд: на поддержку, на исследования, на команду из трёх человек, на департамент из ста. По одному лекалу. «Потому что так правильно».
Сразу оговорюсь: проблема не в Scrum. Scrum — хороший инструмент, я сам его люблю и использую. Проблема в том, что его продают и покупают как серебряную пулю — универсальное лекарство от всех болезней доставки. А потом искренне недоумевают, почему на нескольких командах, которые пилят один продукт, всё превращается в хаос из зависимостей, интеграционного ада и созвонов ради созвонов.
Ниже — три вещи, на которых я набил шишки лично: (1) откуда взялся миф о всемогущем Scrum и почему сам Scrum Guide с ним не согласен; (2) почему «голый» Scrum, натянутый на несколько команд с одним продуктом, — это заявка на провал; (3) что реально работает в этом контексте — от LeSS до Team Topologies — и как в эпоху AI выбор смещается в сторону лёгких, потоковых, адаптивных подходов. Без хайпа, с источниками и из практики.
Предыдущие статьи серии:
1) Что спрашивают на собесах в 2025–2026: разбираем данные с 9 247 технических интервью
2) Реальные задачи с собеседований в Яндекс, VK, Ozon и Сбер — Go, Java, Python, React
И снова привет. Последняя статья из серии разбора данных моего пет-проекта. Поэтому сразу с места в карьер.
Восемнадцатая минута собеседования на позицию ведущего бэкенд-разработчика. Кандидат только что бодро рассказал про последний проект, про то, что делал руками, про рабочую неделю с понедельника по пятницу. И тут интервьюер спрашивает:
Ответ: так же быстро как и сейчас, расходимся! А если серьезно, то давайте обсудим, в какой момент классические подходы к управлению проектами стали альтернативными, и зачем в IT до сих пор натягивают скрам на дедлайны, как сову на глобус.
Я Наташа, менеджер проектов в Selectel. Уже дважды я выносила спринты из команд ногами вперед, и хочу поделиться этим опытом с теми, кто ищет предсказуемости и результативности в сложных технических продуктах.
Мы не планировали делать из этого материал. Просто в какой-то момент накопилось достаточно данных по запросам внутри корпоративной библиотеки Alpina Digital, чтобы можно было ответить на вопрос, какие книги читает нага IT-аудитория.
Через библиотеку проходят сотни тысяч сессий чтения от сотрудников крупных компаний. Разработчики, тимлиды, продакты, аналитики. Данные анонимизированные — мы видим агрегированную статистику по ролям, без привязки к конкретным людям. Выборка специфическая: только те компании, у которых есть корпоративная подписка, так что это не срез всего рынка. Но паттерны получились любопытные.
Когда две команды третий день спорят о релизе, а в чат уже добавили нескольких руководителей, проблема часто кроется не в аргументах.
В статье разберём, в какой момент вопрос действительно пора эскалировать, что передавать наверх и как получить решение, не превращая процесс в поиск виноватых.
После хорошей конференции остается одна проблема: полезных материалов много, а времени пересмотреть все очень мало. Доклады сохраняются «на потом», презентации теряются среди вкладок, а темы, к которым хотелось вернуться, постепенно забываются.
Чтобы упростить навигацию по материалам INFOSTART TEAM EVENT 2026, доклады собрали в пять профессиональных маршрутов: для ИТ-директоров, DevOps-инженеров, аналитиков, разработчиков 1С и руководителей проектов.
В каждой подборке - три выступления с видеозаписями и презентациями. Их можно посмотреть последовательно как небольшой учебный маршрут или выбрать отдельный доклад под текущую рабочую задачу...
Мы с братом вдвоём разрабатываем WorkHub. До этого у нас не было профильного образования и опыта создания цифровых продуктов. Мы не работали внутри IT‑команд и не проходили путь от стажёра до разработчика. Возможность начать появилась во многом благодаря ИИ‑инструментам.
Я, в основном, отвечаю за продуктовую документацию, проработку функций и тексты. Код мы пишем вместе. Брат сильнее влияет на общее видение продукта и занимается аналитикой. Жёсткого разделения ролей у нас нет: небольшие UX‑проблемы, разработку и проверку реализации мы часто разбираем совместно.
Парадокс большинства контакт‑центров банковов: требования к операторам растут, а средний срок жизни сотрудника на линии сокращается. Новичку нужно за несколько недель освоить линейку продуктов, регламенты по страшным аббревиатурам ПОД/ФТ (противодействие отмыванию денег / финансированию терроризма) и ЗСК, оно же KYC (знай своего клиента — know your customer), правила работы с персональными данными, системой управления клиентами (CRM) и телефонией — и при этом научиться спокойно разговаривать с клиентом, который приходит не с учебными кейсами, а с реальными проблемами.
В статье — набор показателей, с помощью которых можно быстро понять состояние команды и управлять процессом поставки. Он помог нам увеличить пропускную способность на 39% и сэкономить компании 112 миллионов рублей.
Первый профессиональный навигатор по качественным исследованиям в бизнесе – который увлекает, объясняет сложное на конкретных примерах и помогает увереннее ориентироваться в мире исследований. Авторы – исследователи-практики с профильным образованием: социальный психолог Константин Ефимов и Анастасия Жичкина, кандидат психологических наук.
Полностью книга называется: «Качественные исследования в бизнесе. Практическое руководство для исследователей, дизайнеров, продактов и стратегов». Объем: 392 страницы. Вес – 1 килограмм.
Основная проблема с литературой про исследования – в том, что ее нет. Нет признанных источников, к которым можно адресовать человека, желающего разобраться в теме, если не считать AI. Есть масса статей с описаниями конкретных практик и кейсов, но они касаются каких-то частных случаев: кто-то сделал фишечку, получилось прикольно. До сих пор очень не хватало текста – или текстов – которые объединяли бы эти фишечки в систему и который можно было бы читать как роман – с началом, сюжетом и завершением.
Такого источника нет не только на русском языке, но и на английском – существующие руководства либо слишком академические, либо совсем простые. Не хватало насыщенного описания процесса исследований, со сложностями и подводными камнями. Гладко все бывает только в мануале и в отчете, а в реальности, как правило, происходит непонятно что. Эта книга показывает, как обрабатывать это «непонятно что» - как исследования помогают в принятии решений в бизнесе, со всеми сложностями этого процесса, на конкретных примерах. Масса интересных кейсов разных бизнес-решений, в том числе провальных.
В моём таск-менеджере сейчас больше пятидесяти пунктов, которые начинаются не с «сделать», а с «получить от…».
Документы от заказчиков, результаты от разработчиков, поручения трём личным ассистентам и даже путеводитель от девушки – всё это нужно не выполнять самому, а вовремя проверять и напоминать. Обычная колонка «Ожидаю» перестала справляться, когда ожиданий стало слишком много.
Рассказываю, как я перестроил личную GTD-систему: отделил срок результата от даты следующего контроля, связал Trello с календарями, не стал дублировать GitLab и сохранил одну точку ответственности в иерархии ассистентов.
Есть такой термин Relentless Improvements, который можно перевести как непрерывные/безостановочные/неустанные/непримеримые/безжалостные/ изменения.
Те кто связаны c Agile, скорее всего сразу вспомнят Scaled Agile Framework (SAFe), и будут правы. Потому, что именно этот фрейм сделал термин массовым, особенно востребованным при изменениях, но заложил глубинную бомбу под многие продуктовые, ИТ и близкие к ним трансформации, определяя непрерывные изменения как стандарт организационной жизни.
Причем наш окружающий мир сам стал похож на одно постоянное безостановочное изменение (то ковид, то СВО, то кризисы перепроизводства, то золотуха). Это также заставляет компании постоянно пересматривать способы работы. И эти самые relentless изменения в организациях становятся действительной нормой.
Меняется структура, меняются роли, приоритеты, процессы. Команды пересобираются, инициативы запускаются... И в какой-то момент организация переходит в режим непрерывной перестройки.
Подобные состояние можно рассматривать как хроническое воздействие неопределённости и потерь на человека и рабочие группы, что не может пройти без следа как для отдельных людей, так и для команд/лидеров/результатов бизнеса.
Каждая отдельная перестройка может быть вполне переносимой. Но когда это становятся фоном, психика людей перестаёт воспринимать происходящее как временный этап и начинает жить в режиме постоянной подстройки и адаптации.
За подобную "гибкость" приходится платить
Предлагаю порефлексировать в статье чем платить, почему это происходит и что с этим можно сделать.
Пока я работал над Mini-Bucket, параллельно развивался еще один проект. Именно о нем и пойдет речь в этой статье.
Предыстория: от проблемы к идее Я уже неоднократно сталкивался с одной проблемой. Вернее, даже с кучей мелких, но если их обобщить, получится одна большая. Думаю, родители, читающие эту статью, меня прекрасно поймут.
ДЕТИ… Их вечное: «Забыл!», «Я не слышал!», а в голове — только игры и бесконечное сидение в телефонах.
В очередной раз услышав это «Забыл», у меня просто поднакипело (признаюсь, я и сам порой забываю что-то проверить). Я решил: пусть.....
Для инвесторов «Уоррен» может означать только председателя Berkshire Hathaway; «Джек» — основателя Vanguard Group. А до своей смерти в 2009 году «Питер» означало Питера Бернстайна: экономиста, историка, мыслителя в области инвестиций и одного из самых мудрых и философских людей на Уолл-стрит. Питер видел всё, встречался со всеми, изучал всё и многие даже из великих уверены, что он разобрался в риске лучше всех.
Его биография впечатляет: однокурсник Кеннеди в Гарварде, офицер разведки, исследователь ФРС, профессор экономики, управляющий активами, историк, специалист по риску и автор книг.
Первая из серии статей о самых понравившихся мне курсах Стэнфорда, где я отучился пять лет на факультете компьютерных наук.
Рассматриваем курс MS&E 280: Organizations and Structures с Кэтлин Эйзенхардт.