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

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

Она о том, как происходит переход, смена парадигмы или мышления у middle-разработчика в сторону senior-разработчика. Автор в частности поясняет, что «цель этой книги — дать вам справочник для работы как с новыми, так и с унаследованными проектами во фронтенде, бэкенде и при развертывании». 

Автор приводит приемы senior-разработчиков, чтобы «работать скорее на уровне системы, чем отдельных строк кода» и находить оптимальные/компромиссные решения.

Стоит ли бизнесу так дорого платить за искусственный интеллект?

По данным отчета McKinsey, 78% компаний внедрили хотя бы пилотные AI-решения. Но есть нюанс: реальную ценность получают далеко не все.

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

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

Занимаясь проектированием систем ПО, идите самым простым путём из возможных.

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

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

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

Привет, Хабр! Меня зовут Роман Изотов. Последние 5 лет я провел по ту сторону баррикад – в роли IT-рекрутера, где отсмотрел более миллиона резюме и провел тысячи собеседований. Сегодня я помогаю IT-специалистам взламывать систему найма, и вот что я вижу: многие по-настоящему сильные Senior-инженеры, тимлиды, архитекторы сталкиваются с одной и той же проблемой – их резюме просто не работает.

«Мой опыт говорит сам за себя!» – Главное заблуждение.

Кажется логичным: если у тебя 7-10 лет опыта, куча проектов, сложные технологии, то резюме должно привлекать. Но в 2025 году это больше не так. Рынок перегрет, конкуренция бешеная. На одну Senior-вакансию приходят десятки, а то и сотни откликов. И вот тут в игру вступают фильтры, о которых вы могли даже не догадываться.

Фильтр №1: Автоматизированные системы отбора (ATS) – ваш первый и самый беспощадный враг.

Забудьте про креативный дизайн и инфографику. Для ATS ваше резюме – это набор ключевых слов. Если вы не используете точную лексику из описания вакансии, не указываете конкретные технологии и метрики – ваша заявка просто не дойдёт до HR. Система не поймёт, что "оптимизировал производительность" означает "сократил время отклика сервиса на 30% на пять миллионов пользователей". А если она не поймёт, то вы в корзине.

Код-ревью убивает вашу команду. И вот доказательства.

Мы измерили. Один пулл-реквест крадет у компании 2.5 рабочих дня и 1.5 часа времени senior-разработчика. 70% комментариев в ревью — бесполезные споры о пробелах и запятых. Хватит это терпеть. Читайте мой разбор, почему код-ревью в Nomium стало главным тормозом разработки и что с этим делать.

(Анонс: Привет. Собираю статистику по инженерным процессам — от enterprise до инди‑команд (форма в конце статьи). Результаты агрегирую и опубликую на хабре в ближайшее время. Анонимно, 5–10 минут. Важен каждый.)

В сети очень много информации о том, как работать в большой и многорукой команде, с кучей выделенных ролей и настроенными процессами. Да я и сам отправляю к девопсам, когда на конференции подходят и спрашивают «а как правильно сделать репликацию базы данных?», потому что они (девопсы) сделают это быстрее и правильнее почти любого бэкендера. Но кроме компаний, в которых работают тысячи инженеров и есть отдел «на любой чих», — есть компании, в которых работают три джуна и один мидл (кстати, они-то и задают этот вопрос). Я и сам когда‑то с такой компании начинал… И эта статья для них.

2025 год должен был стать годом триумфа Искусственного Интеллекта. И если смотреть на заголовки, так оно и есть: 78% организаций по всему миру заявляют, что используют ИИ хотя бы в одной бизнес-функции, а общие корпоративные инвестиции в технологию за 2024 год перевалили за $250 миллиардов. Деньги льются рекой: половина лидеров планирует удвоить бюджеты на ИИ, а средние месячные расходы компаний готовятся вырасти с $63,000 до $85,000. Кажется, что машина хайпа несется на полной скорости.

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

Впервые за два года непрерывного роста крупные компании (250+ сотрудников) внезапно нажали на тормоз: уровень внедрения ИИ в их производственные процессы за лето 2025-го снизился с 14% до 12%. В это же время свежий отчет MIT бьет наотмашь: 95% пилотных проектов по генеративному ИИ проваливаются, не доходя до реального использования.

Что происходит?

Добро пожаловать в эпоху "отрезвления". Период, когда эйфория от первых успехов ChatGPT сменяется жестким похмельем от столкновения с реальностью. Реальностью, в которой 42% лидеров втихую признаются, что громкие заявления их компаний об ИИ - просто раздутый хайп, а 82% людей в целом скептически относятся к технологии. Внутри корпораций назревает настоящий раскол между лагерем "скептиков", которые видят риски и провалы, и лагерем "реалистов", которые продолжают верить в технологию.

Эта статья - глубокое погружение в цифры и настроения сентября 2025-го.

Привет, Хабр!

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

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

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

В этой статье попробуем разобраться, кто же такой Chief Operating Officer, какие задачи он выполняет и какие качества необходимы, чтобы им стать.

«Workslop» - новая чума офисной продуктивности

Представьте: понедельник, утро. Вы открываете почту, а там - отчет от коллеги из соседнего отдела. Называется «Стратегический анализ синергии рыночных векторов на Q4». Звучит солидно. Вы открываете. Тридцать страниц, графики, красивые диаграммы, текст пестрит выражениями вроде «масштабирование инсайтов» и «кросс‑функциональное взаимодействие». Выглядит профессионально. Даже слишком.

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

Поздравляю, вы только что столкнулись с «workslop».

И если вы думаете, что это единичный случай, у меня для вас плохие новости. Это новая чума 2025 года, которая тихо, но уверенно пожирает нашу продуктивность. Исследователи из Стэнфорда и BetterUp Labs недавно взорвали инфополе своей статьей в Harvard Business Review, где привели шокирующие цифры. Оказывается, уже 40% из нас регулярно получают такой «цифровой мусор». И тратят в среднем по два часа на то, чтобы просто его разгрести и понять, что имелось в виду.

Звучит как сюжет для антиутопии? Увы, это наша новая реальность.

«Workslop»- это не просто технологическая проблема. Это симптом болезни. Болезни, имя которой - слепая вера в «магию» ИИ и прогрессирующая атрофия собственного мозга. Это новый, более изощренный вид лени, который научился очень хорошо маскироваться под продуктивность. И он угрожает не только нашим дедлайнам и бюджетам (а потери, по оценкам, достигают $9 миллионов в год на крупную компанию). Он угрожает главному - доверию внутри команд.

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

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‑лидера.

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