На Хабре любят хейтить менеджеров, которые «забыли, как кодить». Мол, оторвались от реальности, не понимают сроков, не чувствуют боль разработчика. Я раньше тоже так думал. А потом попал в команду к человеку, который три года не открывал IDE, и за полгода понял, что был неправ.
Вы все это видели.
Стартап на три человека. Идея простая - агрегатор скидок в районных парикмахерских. Бэкенд еще не написан, но архитектура уже утверждена.
Конечно же, микросервисы. Конечно же, Kubernetes. Обязательно кафка для обмена сообщениями, потому что "нам нужна асинхронность". И база данных - непременно NoSQL, желательно шардированная, ведь мы готовимся к миллионам пользователей. Сразу. В первый день.
Проходит полгода.
Продукт не запущен. Деньги инвесторов (или личные сбережения фаундера) сгорают на оплату кластеров в облаке. Два сеньора, которых наняли за большие деньги, целыми днями настраивают CI/CD пайплайны и спорят о правильной гранулярности сервисов.
А бизнес-задача? Она потерялась. Мы не решаем проблему пользователя, мы решаем проблемы, которые сами себе создали, выбрав инструменты не по размеру.
Есть паттерн, который видит каждый, кто работает с агентами: первые 5–15 минут уходят не на задачу, а на "ориентацию". Где точка входа? Откуда растут зависимости? Почему эта библиотека, а не другая? Кто считает это публичным API? В маленьком проекте раздражает. В большом — превращается в постоянный налог на токены и внимание.
DSP (Data Structure Protocol) "выносит карту проекта наружу" — в простой, версионируемый, языковой граф, который живёт рядом с кодом и доступен агенту как постоянная память.
k-kolomeitsev/data-structure-protocol
Цель в архитектуре сформулирована так:
1) Цель и границы
Цель DSP — хранить минимальный, но достаточный контекст о репозитории/системе артефактов в виде графа «сущности → зависимости/публичный API», чтобы LLM могла:
- быстро находить нужные фрагменты по UID,
- понимать «зачем» сущности существуют и «как» они связаны,
- не требовать загрузки исходников целиком в контекстное окно.
DSP — это долговременная память и индекс проекта для LLM. Агент может в любой момент выполнить поиск (grep) по проекту, найти нужные сущности по описаниям/ключевым словам и от найденного UID раскрутить весь граф связей: входящие зависимости, исходящие импорты, реципиентов через exports. Это заменяет необходимость «помнить» структуру проекта или загружать его целиком — вся карта проекта всегда доступна через .dsp.
Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC.
За годы в ИТ я видел десятки команд, которые буквально тонут в техническом долге, но даже не осознают этого. Они продолжают героически вкатывать хотфиксы, год за годом пересобирать один и тот же код и удивляться: почему скорость упала, а пользователи ноют?
Самое коварное — технический долг маскируется под обычную занятость. Вам кажется, что работа кипит, но на деле вы просто раз за разом наступаете на одни и те же грабли.
В этой статье делюсь опытом, как перестать ходить по кругу и превратить беспорядок повторяющихся проблем в управляемый, прозрачный процесс.
Без магии, зато с метриками, ролями и реальными кейсами.
Всем привет! Меня зовут Юлия Новикова, и мае 2025 года я стала Team Lead группы фронтенд-разработки в Ozon. В моей команде сейчас 5 разработчиков и 2 тестировщика, и мы создаём фронтенд для админок, которые управляют работой складов, РЦ (распределительный центр) и дарксторов. Но путь мой сюда был не самым тривиальным — до этого я была QA Lead, а не разработчиком.
А началось всё с того, что я начала думать: а что дальше? Кем я могу стать, если ещё вырасту? Вакансий руководителей тестирования, а особенно руководителей отделов тестирования, не так много, а хотелось больше влияния, больше развития. И я решила прыгнуть вбок и сменить профессию: стать тимлидом разработки. Расскажу, как это было и чего стоит ожидать тем, кто задумывается о таком же повороте.
Вы проводите daily stand-ups? Делаете ретроспективы каждые две недели? Следите за velocity? Поздравляю, вы делаете Scrum. Но понимаете ли вы философию? Или ваш Scrum превратился в набор встреч, которые все ненавидят, но ходят, потому что «так надо»?
Большинство методик управления проектами отвечают на вопрос «что делать», но значительно хуже — на вопрос «в каком состоянии находится проект прямо сейчас». Мы измеряем сроки, бюджеты, проценты готовности, количество выполненных задач — и при этом нередко упускаем момент, когда проект перестаёт быть управляемым, хотя формально всё ещё «идёт по плану».
Проблема в том, что управление обычно рассматривается как последовательность действий: поставить задачу, выполнить, проверить, скорректировать. Такой взгляд удобен, но он скрывает главное — проект развивается не по шагам, а по состояниям. Между «всё под контролем» и «проект провален» лежит широкий спектр промежуточных состояний. Именно в них и накапливается риск.
В этой статье предлагается посмотреть на управление задачами под другим углом — не как на контроль выполнения, а как на работу с пространством возможных состояний, в которых может находиться задача. В таком подходе неопределённость становится не побочным эффектом, а центральной характеристикой процесса, а управление — способом перераспределять её так, чтобы цель оставалась достижимой.
Представьте совещание в условном зуме. В комнате - инженеры данных, парочка разрабов, парочка аналитиков, парочка менеджеров, парочка еще кого-нибудь, неважно. Обсуждают новый отчёт.
Всем привет! Меня зовут Евгений Федосеев, я инженер-программист в компании iSpring.
В рамках развития платформы дистанционного обучения iSpring Learn перед нами стояла задача реализовать систему уведомлений для модуля «Планы развития». Нам нужна была система, которая группирует сообщения для разных видов уведомлений и при этом обспечить надежность и расширяемость
В этой статье я расскажу, как мы проектировали эту систему, какие архитектурные решения приняли для обеспечения гарантии доставки и наблюдаемости, и как этот механизм успешно работает в продакшене.
В 2026 продакт-менеджеру важнее всего скорость: из заметок, созвонов или исследований быстро получать PRD и понятный план работ.
В статье как раз практический гайд по Claude Code: зачем он Product-менеджеру, как настроить CLAUDE.md, как автоматизировать конкурентный анализ, использовать параллельных агентов и skills, плюс роадмэп - карта обучения Claude Code для Product-менеджеров и разбор типовых ошибок.
Это статья не сеньора, очередной раз пишущего про управление персоналом. Я - Junior Golang-разработчик! У меня нет ответов на все вопросы, но есть путь. Вот что работает, когда ты ещё сам учишься писать код, а уже отвечаешь за команду.
Корпоративный архитектор редко начинает с чистого листа: в разных отраслях уже существуют референсные модели процессов, сервисов и данных, которые помогают быстрее выстроить целостную картину организации. В этой статье разберём, какие модели доступны сегодня — от TM Forum и BIAN до IT4IT, SCOR и APQC PCF — и как их использовать при описании деятельности и ИТ-ландшафта компании.
Conductor, Crystal, Auto-Claude, Claude Squad, CCManager и Cursor 2.0 — честное сравнение с плюсами, минусами и рекомендациями по сценариям.
Начало этапа имплементации подразумевает переход от согласованного проектного решения и планов-графиков его воплощения, к практической реализации посредством разработки, настройки инфраструктуры и поэтапного создания функциональности продукта. Обычно для команды на данном этапе стоят следующие вызовы:
Я много лет работаю на стыке технологий и операционного управления. И почти в каждой компании вижу один и тот же парадокс. Команда сильная, процессы выстроены, релизы регулярные.
Но в P&L (Profit and Loss) нет заметного роста. И в какой-то момент возникает вопрос, который неприятно задавать: Если команда хорошая, почему бизнес не чувствует этого в прибыли?
Сегодня хочу поговорить с вами о доверии к IT-специалистам, а именно о том, что с ним стало и к каким последствиям в найме это привело. Мы посмотрим на наши честные кейсы и факапы с кандидатами, работниками и посчитаем экономику убытков.
Всем привет!
Обычный вайб-кодинг: кидаем промпт → генерим → баг → фиксим → баг → повторить N раз.
AI Factory меняет правила: самообучающаяся система патчей, где AI запоминает каждую ошибку и больше её не повторяет. Spec-driven воркфлоу, автогенерация рутины (Docker, CI, docs, Make), поддержка 14+ агентов, параллельная разработка через Git worktree. Это не "ещё один AI-помощник", а эффективный инструмент управления вайб-кодингом.
В статье подробно разбираю технические вопросы: как работает самообучение, почему токены расходуются рациональнее чем кажется, и что нового в версиях AI Factory 1.3-1.8.
Привет, Хабр.
Немного контекста, потому что я уже успел наступить на грабли: написал технический пост, получил пару «вежливых» комментариев, пару очень невежливых, и карма улетела туда, где зимой холодно.
Нюанс какой: я зашёл «с места в карьер», как будто все уже знают, кто я, откуда и почему я так пишу и так думаю. А по факту — нет, конечно. Поэтому этот пост — «паспорт»: кто я, откуда выросла идея, почему я вообще полез в код, почему у меня агенты, почему «завод», и что я могу обсуждать с инженерами предметно (а что — не могу и не буду, потому что там секреты/безопасность/коммерческое ядро).
Сразу честно: я не классический инженер. Я могу где‑то не знать «ритуальную формулировку» термина или перепутать модное слово. Но я фанат причинности: если система говорит «работает» — она должна уметь это доказать. Всё остальное — разговоры.
Вот уже пять месяцев наша команда проводит эксперимент: мы создаем и выпускаем внутреннюю бета-версию программного продукта, не написав ни строчки кода вручную.
У продукта есть и внутренние пользователи, которые пользуются им каждый день, и внешние альфа-тестеры. Он выпускается, разворачивается, ломается и чинится. Отличие в том, что весь код — логика приложения, тесты, конфигурация CI, документация, observability, внутренние инструменты — написан Codex. По нашей оценке, мы сделали это примерно в десять раз быстрее, чем если бы писали код вручную.
Люди задают направление. Агенты выполняют.
Мы специально ввели это ограничение, чтобы построить то, что было нужно для роста темпа разработки на порядки. У нас были недели, чтобы выпустить то, что в итоге оказалось миллионом строк кода. А чтобы это сделать, нам понадобилось понять, что меняется, когда основная задача команды разработки ПО — уже не писать код, а проектировать окружения, формулировать намерение и строить петли обратной связи, которые позволяют агентам Codex работать надежно.
Этот пост о том, чему мы научились, создавая совершенно новый продукт с командой агентов: что ломалось, что накапливалось и как максимально использовать наш единственный по-настоящему дефицитный ресурс — человеческое время и внимание.
Проблема: никто не знает, кто кого вызывает
В 2012 году биржевой брокер Knight Capital потерял $460 миллионов за 45 минут.
Причина — активация устаревшего модуля, который начал массово размещать ордера.
Отчёт SEC указал на ключевую ошибку:
