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

Microsoft уволил 9000 разработчиков. Среди них — создатели ИИ-инструментов, которыми их же и заменили. Это не единичный случай: по всему миру программисты массово игнорируют искусственный интеллект, считая его игрушкой или угрозой. Владимир Крылов — доктор технических наук, лектор на канале Ai4Dev по применению ИИ в разработке ПО — видел рождение первых языков программирования и теперь наблюдает, как индустрия стоит на пороге радикальной трансформации. В интервью он объясняет парадокс: почему ИИ действительно замедляет работу в legacy-проектах, но при этом промпт-инжиниринг уже мертв, а на смену ему пришел контекст-инжиниринг.

Ежегодно я участвую в нескольких конференциях (Let's GoConf, DUMP, PyCon Russia, RustCon, RubyRussia или DUMP Spb) в качестве организатора, и каждый раз задумываюсь, зачем это выступление спикерам. Ведь участие бесплатное, а времени на подготовку уходит немало. 

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

Из разговоров со спикерами выделила несколько пунктов:

Представьте программиста, который мастерски собирает для себя вспомогательные утилиты, а потом равнодушно отмахивается: «Честно? Мне они не нужны». 

Именно так повела себя GPT-5 в ходе теста на умение выстраивать собственный набор инструментов для продуктивности. Модель выдала целый арсенал CLI-утилит в духе Unix, но… отказалась ими пользоваться.

Почему так случилось и что это говорит о будущем кодинг-агентов — разбираем в статье.

Привет, Хабр! (И тебе, отчаянный страдалец, зашедший сюда в перерыве между дебагом очередного if (a == b) { return true; } else { return false; }. Мы знаем, ты не виноват, так вышло).

Каждый разработчик хоть раз в жизни прилаживал к своему коду «костыль». Знакомое чувство, правда?

Привет, Хабр! С вами снова Алина, HR-лид компании SSP SOFT. О чем будет пост сегодня: рынок труда в 2025 стал очень сложный, на каждую вакансию приходят десятки, а то и сотни резюме. Попасть в шортлист и потом дойти до собеса кандидатам помогают не только скилы из резюме, но и более второстепенные вещи. Как говорится в английской пословице, «Каждый пенни важен». Поэтому хочу поделиться нашим мнением о значимости  сопроводительного письма и раздела «хобби» в резюме. Эти факторы весомы далеко не для всех рекрутеров, но и пренебрегать ими не стоит.

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

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

В статье поделюсь опытом, полученным в ходе работы над собственным некст-ген фаерволом «Лаборатории Касперского» — Kaspersky NGFW. Думаю, узнать о пути такого комплексного продукта от идеи до релиза может быть интересно как коллегам по ремеслу, так и ИТ-сообществу в целом. Особенно учитывая, что (как это часто происходит) конечный продукт существенно отличается от изначального концепта.

Привет! Меня зовут Мария Белых, я занимаюсь управлением изменениями более 10 лет.

Последние 5 лет я работаю в SM Lab и в роли методолога продуктового подхода и помогаю ИТ-командам повышать пропускную способность, сокращать время выполнения задач и избавляться от ложной нагрузки. Применяю канбан-метод, фасилитацию и командный коучинг. 

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

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

Это перевод статьи Des Traynor, сооснователя и Chief Strategy Officer в Intercom. Трейнор отвечает за стратегию компании 14 лет с момента её основания и делится опытом, проверенным на практике роста от стартапа до мирового SaaS‑лидера.

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

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

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

В каких таких попугаях я должна считать, насколько эффективно отрисовал дизайнер MES-интерфейс или сгенерировал картинки для сайта?!

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

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

Привет, Хабр! Представьте: ваше приложение зависло на минуту. Если это интернет-магазин — пользователь просто перезагрузит. А если это система учёта, связанная с логистикой зерна, — остановится вся цепочка поставки, или клиент уйдёт в офлайн к привычным бумажным документам. В этом и есть главная разница между B2B и B2C.

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

B2B-системы не работают с толпой — они работают с уникальными процессами каждой компании. У одного клиента простое согласование документа, у другого — 15 подписантов по строгой иерархии. Попробуйте втиснуть это в стандартную B2C-логику — провалитесь. Всё это требует не только высокой надёжности каждой операции, но и умения подстроиться под каждого клиента — предоставить ему кастомизацию.

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

В сентябре 1985 года Джон Бентли опубликовал книгу Programming Pearls — сборник афоризмов об истинах в программной отрасли.

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

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

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

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

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

🚀 Как перестать бояться релизов и начать жить: практический гайд для тимлидов

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

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

Актуальность статьи: в современном мире скорость доставки фич — это не просто модный тренд, а вопрос выживания на рынке. Компании с быстрой доставкой обгоняют конкурентов по доходам на 20–40%.

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

Методология основана на практическом применении DevOps-практик и измерении результатов через метрики DORA. Мы покажем, как:

Trunk-Based Development сокращает время доставки на 30%

Feature Toggles делают релизы безопасными

Left-shifting тестирование снижает время восстановления с 15–20 часов до 1 часа

Kanban превращает хаос в прозрачную систему

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

P.S. Если вы всё ещё релизите раз в квартал — эта статья поможет вам пересмотреть свои подходы к разработке. 🎯

Вы, наверное, слышали, что тесты — это хорошо, что тесты надо писать. И, возможно, даже согласны с этим.

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

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

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

Серия: Чем болен средний бизнес? Статья 5.LLM + ДРАКОН: доступный инструмент процессного управления для МСБ

Классические BPM-проекты дороги, сложны и часто проваливаются в МСБ. Вы получаете схемы, которые никто не понимает, и зависимость от консультантов, а хаос остается.

В этой статье мы разбираем прагматичный подход, доступный уже сегодня:

LLM как аналитик: Используем нейросети для быстрого анализа «цифровых следов» процесса (почта, CRM, логи) и выявления узких мест.

ДРАКОН как интерфейс: Превращаем выводы LLM в наглядные и понятные схемы, которые может прочитать любой сотрудник, а не только IT‑специалист.

Человек как архитектор: Показываем, как на основе этих данных принимать управленческие решения и моделировать улучшения.

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

[Искусственный интеллект*] [Управление процессами*] [Визуализация данных*] [МСБ*]

Выродивщийся аджайл, карты Уордли, метод MOSCOW, канбан‑каденции, НФТ, закон Хофштадтера, топ-10 канбан‑досок, запретные слова для ПМов, рынок вакансий, управление кросс‑функциональной командой и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

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

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

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

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

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

Всем привет! Это спецпроект "Три трюка" от ИнженеркиТех, где мы разговариваем с CTO об их пути и подходах к управлению инженерными командами.

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

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