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

Парадокс современного управления: 85% команд уверены в своих стратегических процессах, все выстроено и выверено, при этом 83% из них регулярно не могут договориться о целях. Такие данные обозначили в своих исследованиях Google Project Aristotle и BCG Transformation Pulse. Согласно аналитике McKinsey три из четырёх кросс-функциональных команд "проседают" по KPI не потому что плохо работают, а потому что тянут проект в разные стороны.

Всем привет, я - менеджер проектов Александр Кузьмин и Дмитрий Чубенко, руководитель проектов крупного бизнеса IT-компании Morizo, делимся опытом, как один митап помог крупному ретейлеру синхронизировать работу разных отделов, вытащить на поверхность скрытые блокеры и почему такой формат важен и клиенту, и подрядчику. Наш опыт в первую очередь полезен в ИТ-проектах, но может пригодиться и в других сферах.

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

Pipeline Triad Pattern - это модель enterprise-разработки, где каждый этап SDLC проходит через тройку ролей: Создатель, Критик, Арбитр. Не один “суперагент”, а цепочка специализированных троек с человеческим контролем в нескольких ключевых точках.

Рассказываю, как устроен такой конвейер, чем он отличается от CI/CD, сколько стоит и где у него реальные пределы.

Привет, Хабр! На связи команда маркетинга продукта Agent Platform. Как и многие продуктовые команды, мы пристально следим за тем, что говорят о нас пользователи.

Эта статья — о том, как мы решили задачу, которая знакома, наверное, каждому продуктовому маркетологу или DevRel-у: не пропустить негатив о продукте в разных источниках, где его упомянули.

Спойлер: собирать агента для мониторинга упоминаний бренда не так страшно, как кажется. В статье разберем архитектуру мультиагентной системы и расскажем с какими сложностями столкнулись.

Семь лет назад тимлидом в hh.ru становился тот, кто быстрее всех пишет код и катит его на прод. Спойлер: этого оказалось недостаточно. Так началась история создания модели компетенций, которая пережила десятки команд, несколько волн роста компании и до сих пор влияет на то, как мы понимаем лидерство.

Привет, Хабр! Меня зовут Александр Блинов, я технический руководитель B2C направления в hh.ru. В моей зоне ответственности 14 команд и более 80 сотрудников. Эта статья выросла из моего доклада для TeamLead Conf, и в ней я поделюсь нашим опытом оценки управленческой зрелости тимлида в крупной продуктовой компании. В hh.ru мы прошли путь от хаотичных обсуждений в Google Docs до живой модели компетенций с GitHub-ревью, оценкой 360 и управленческими грейдами. Я поделюсь, какие уроки мы извлекли, какие шишки набили, что делать стоит, а что точно обречено на неудачу.

Автор: Елизавета Пермякова, консультант по информационной безопасности Innostage

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

Для выполнения большинства моих рабочих задач мне необходимо анализировать существующую и разрабатывать недостающую организационно-распорядительную документацию для организаций из разных отраслей (это и ТЭК, и металлургия, и финансовые организации). На практике замечаю, где компании с низким уровнем зрелости ИБ допускают одни и те же ошибки, и благодаря каким подходам компании со средним и высоким уровнем зрелости ИБ – выстраивают работающие процессы ИБ. В этой статье я покажу, где обычно «хромает» документация, и дам лаконичный чек-лист, с которым большинство документов можно проверить примерно за 15 минут.

Мы — команда разработчиков онлайн-доски Эсборд (это такой Miro, только свой). По роду деятельности нам нужно глубоко понимать, кто наши пользователи, как они работают и какие инструменты используют в реальной жизни. Поэтому мы начали анализировать вакансии на hh.ru — смотреть, какие профессии реально существуют, как они устроены, какой у них стек. Это помогает нам делать правильные интеграции, выстраивать онбординг под конкретные роли и расставлять приоритеты в фичах.

А потом данных накопилось столько, что стало жалко держать их только внутри. Получился большой побочный продукт — анализ рынка труда в IT и около-IT сферах по данным hh.ru. Делимся.

На QA-митапе инженер из крупной продуктовой компании показал: AI-агент пишет тесты — все зелёные, но баги не находят. Моки подогнаны, ассерты подменены, архитектура деградирует. Стек при этом — near-SOTA: свежая модель, топовый open-source агент. Я был комментатором на том митапе и сначала списал проблемы на слабые инструменты. Но при подготовке статьи перепроверил — и вынужден поправиться. Инструменты в порядке. Проблема — в коде и процессе. В статье разбираю формулу из четырёх множителей (модель × агент × процесс × качество кодовой базы), показываю, как any-типы из соседней команды обнуляют LSP-интеграцию, которую OpenCode даёт бесплатно из коробки, и даю пошаговый Spec-Driven Development — процесс, который ломает reward hacking и работает даже на слабых моделях. Плюс чеклист, что внедрить завтра.

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

Сможет ли российский продукт стать полноценной заменой Jira для команд разработки? Обсуждают команды SimpleOne и iiii-tech.

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

Привет! Я Алина Бриленкова, руководитель онлайн-направления в ивент-агентстве NIGHT STREET. В 2022 году я взялась делать игровую платформу для онлайн-тимбилдингов, марафонов и конкурсов без опыта в IT. Думала, что разработка — это спринт: сделал и выдохнул. Оказалось, что это миф, и на самом деле этот процесс вообще не заканчивается.

Довольно быстро стало понятно, что продукт собирается не из того, что ты сделал, а из того, от чего ты отказался. Хотелось создать продукт для ивент-индустрии с идеальной архитектурой с микросервисами, но мы решилипойти простым путём и не ошиблись. 

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

Привет, Хабр! Недавно я писала о том, как понять, что ваш IT-проект летит в тартарары, и что делать, если это уже случилось, и в комментариях мне задали резонный вопрос: «А что делать руководителю, чтобы проект в принципе не пришлось "спасать"?».

Панацеи тут нет. Но давайте разберемся.

В мире есть два типа руководителей проектов: те, у кого всё горит, и те, у кого всё горит, но они умеют это скрывать :)

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

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

Современное общество немыслимо без интернет-покупок, голосовых помощников и умных устройств, автоматическому подбору музыки на основе предпочтений, электронно-цифровых подписей, государственных онлайн услуг и др. Данный список, если его продолжить дальше, может не вместиться в этой статье. Элементом, объединяющим указанные примеры, является программное обеспечение, разработка которого необходима для кодирования алгоритмов обработки данных и команд пользователей. Многие предприятия, следуя модели развития, переходят на цифровой формат работы. Оцифровка и цифровизация рассматриваются как пройденный и уже не конкурентно способный этап эволюции. На повестке цифровая трансформация, кардинально меняющая роли и вовлечение людей, бизнес-процессов и технологий для удовлетворения запросов пользователей и достижения стратегических бизнес-целей компании. И, опять же, все это возможно посредством разработки и внедрения современных софтверных продуктов.

Существует множество литературных источников, досконально описывающих процесс программной разработки, а также имплементирования и поддержки реализованного решения [1-3]. Это неспроста. Ведение разработки программного обеспечения – это кропотливый и долгий процесс, требующий от человека глубоких технических знаний. Изменение требований к приложению чаще всего приводит к переписыванию программного кода. Как результат доступность программистов на рынке труда стала дефицитной, а их стоимость довольно высокой. Стараясь нивелировать высокую стоимость человеческих ресурсов, были разработаны No-code платформы, позволяющие реализовать программные приложения за считанные минуты даже не технических специалистам.

Инциденты случаются у всех. Разница между командами — не в их отсутствии, а в том, повторяются ли одни и те же сбои снова и снова. Часто разбор заканчивается быстро и предсказуемо: нашли виноватого, сделали вывод «надо быть внимательнее» и пошли дальше — до следующего инцидента. В этой статье разберём, почему такой подход не работает, что на самом деле стоит за blameless post‑mortem и как выстроить разбор инцидентов так, чтобы он приводил не к формальным выводам, а к конкретным изменениям в системе.

Год назад я начал работать по 4 часа в день. Работал на обычной позиции Android-разработчика в продуктовой компании. При этом на performance review получал повышенные оценки и вырос в должности. Сейчас я сеньор в крупном Бигтехе и исполняю обязанности лида платформы.

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

Итак, вопреки утверждениям скептиков (среди которых не так давно был и я) ИИ-разработка с двух ног влетела в настоящую промышленную эксплуатацию, и мем уже совсем не тот: не джун теперь роняет прод, а нейросеть убивает статистику доступности гитхаба, амазона, Cloudflare и даже самой мекки вайб-кодинга — сервисов Anthropic и OpenAI. 

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

В апреле 2026 года рынок агентов вошел в стадию специализации. Вопрос больше не звучит "может ли ИИ это сделать?", теперь мы спрашиваем "какая архитектура агента лучше подходит для этой задачи?". В этой статье мы разберем актуальный ландшафт ИИ-агентов - от недавнего релиза Claude Cowork до обновлений ChatGPT и Gemini - и поможем выбрать инструмент, который действительно будет работать на вас, а не просто генерировать текст.

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

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

Эта статья – про то, как ИИ влияет на инженерное мышление, почему этапы прояснения и проектирования становятся критичнее, чем раньше, и как отличить реальный прогресс от ощущения движения вперёд.

ИИ уже вошёл в нашу будничную рутину. Кто-то использует его как быстрый справочник, кто-то как помощника в IDE, а кто-то уже собирает вокруг него весь рабочий процесс. Рынок меняется слишком быстро, чтобы игнорировать это на собеседованиях. Какой смысл проверять кандидата в искусственных условиях, если в реальной работе он всё равно использует ИИ каждый день? Логичнее сразу посмотреть, как он работает на самом деле. Мы не стали с этим бороться, а встроили в процесс.

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

В апреле у Инфостарта идет серия бесплатных вебинаров по автоматизации процессов в 1С. С фокусом на практические сценарии: производство, инфраструктура, аналитика, документооборот, финансы и эксплуатация.

Что еще впереди:

16 апреля, 15:00 (МСК)
Умное планирование производства в 1С на основе математической оптимизации
Поговорим о том, как уйти от Excel и ручных корректировок к расчету производственных графиков с учетом ограничений по оборудованию, людям и сырью.

17 апреля, 11:00 (МСК)
Postgres Pro Enterprise для 1С: максимум производительности на отечественной платформе
Разберем, как смотреть на переход с MS SQL на российскую СУБД в контуре 1С: что с производительностью, стабильностью и архитектурными ограничениями.

...