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

Многие компании в процессе своего развития успешно осваивают начальные этапы TOGAF ADM: формируют видение, разрабатывают целевые модели, создают планы переходов. Но настоящая ценность архитектуры рождается не на слайдах, а в ежедневной работе ИТ-команд. Именно здесь возникает критический разрыв: хорошие архитектурные артефакты остаются невостребованными, потому что непонятно, как их применять в реальных процессах разработки, тестирования и эксплуатации. Стратегические архитектурные решения (принципы, стандарты, целевые состояния) формализованы, но не оказывают реального влияния на операционную деятельность команд. Причина — отсутствие четких механизмов внедрения этих решений в рабочие процессы.

Этот разрыв преодолевается там, где архитектурное мышление интегрируется с методологией управления ИТ-процессами. Агрегация компетенций корпоративного архитектора и ИТ-методолога превращает ADM из теоретического цикла в работающий механизм трансформации.

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

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

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

Меня зовут Стас Иванкевич, я техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. В управляющий слой входят установщик кластера, консоль, API, другие компоненты и самое релевантное для этой статьи — наши многообразные операторы.

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

Всем привет, меня зовут Алекс Гусев. В этой публикации я продолжаю формализовать свой личный опыт взаимодействия с агентом OpenAI Codex при разработке программного обеспечения. Речь пойдёт о практическом использовании файлов AGENTS.md как инструмента организации контекста проекта в долгоживущих и структурно сложных системах.

Привет, Хабр! Меня зовут Таисия Брезгина, я Enterprise Agile coach в МТС Web Services. У нас в компании выстроена система поддержки команд, и ее важная часть — регулярная диагностика. Мы используем много разных инструментов, для того чтобы выявлять слабые места и дисфункции и за счет их решения растить эффективность команд. Хочу поделиться инсайтами в работе своей небольшой команды скрам-мастеров и аджайл-коучей. Какие инструменты у нас действительно работают и почему важен комплексный и кастомизированный подход, а не бездумное внедрение инструментов и методов. 

На программах ТОП ИТ Московского авиационного института с 2025 года учатся будущие middle-разработчики. Что же делает нашу программу особенной и как мы погружаем студентов с первого семестра в ИТ-индустрию, об этом и расскажем от лица студента ТОП ИТ в этом кратком обзоре уже практически прошедшего семестра обучения…

Структура дорожной карты, гайд по скрамбану, аналоги джиры, диаграмма Венна, убивающий таск-трекер, работа с синдромом самозванца, как понять, что хочет заказчик, и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

В прошлом квартале я внедрил Microsoft Copilot для 4000 сотрудников.

$30 за место в месяц.

$1,4 миллиона в год.

Я назвал это "цифровой трансформацией".

Совету директоров понравилась эта формулировка.

Они одобрили за одиннадцать минут.

Никто не спросил, что это вообще будет делать.

Включая меня.

Я всем говорил, что это "увеличит продуктивность в 10 раз".

Это не реальная цифра.

Но звучит как реальная.

HR спросил, как мы будем измерять это увеличение в 10 раз.

Я сказал, что мы "задействуем аналитические дашборды".

Вопросы прекратились.

Три месяца спустя я проверил отчёты по использованию.

47 человек открывали его.

12 использовали больше одного раза.

Один из них — это я.

Я использовал его, чтобы пересказать письмо, которое мог прочитать за 30 секунд.

Это заняло 45 секунд.

Плюс время на исправление галлюцинаций.

Но я назвал это "успешным пилотом".

Успех означает, что пилот не провалился явно.

Финдир спросил про ROI.

Я показал ему график.

График шёл вверх и вправо.

Он измерял "AI-enablement".

Я эту метрику придумал.

Он одобрительно кивнул.

Теперь мы "AI-enabled".

Я не знаю, что это значит.

Но это есть в нашей инвесторской презентации.

Старший разработчик спросил, почему мы не используем Claude или ChatGPT.

Я сказал, что нам нужна "энтерпрайз-безопасность".

Он спросил, что это значит.

Я сказал "комплаенс".

Он спросил, какой именно комплаенс.

Я сказал "все виды".

Он выглядел скептически.

Я назначил ему "встречу по развитию карьеры".

Вопросы прекратились.

Microsoft прислала команду для кейс-стади.

Они хотели представить нас как историю успеха.

Большие компании нацелены на Процесс и совершенно не работают на Результат, это их и губит.

1.Специфика больших компаний.

Всем известна фраза: «Слишком большие, чтобы разориться». Но слишком быстрые изменения мира и рынка могут свести на нет те преимущества, что казались раньше абсолютными.

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

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

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

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

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

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

Привет, Хабр! Я Артём Клещев, технический писатель в СберТехе. Я пишу документацию к продукту Platform V DropApp — решению для управления контейнерными приложениями. Наша команда работает в парадигме Docs-as-Code.

Мы столкнулись с проблемой: при каждом изменении продукта нам нужно было менять документацию сразу в нескольких репозиториях — для каждого исполнения продукта. Но мы нашли решение, как оптимизировать процесс. И хотим поделиться рекомендациями по ведению единого источника в Docs-as-Code — будет полезно тем, кто хочет шаблонизировать документацию и сэкономить время для творческих задач.

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

Я программист 1С с 18 летним опытом работы с 1С:Предприятие и общим опытом коммерческого программирования 22 года.

С начала января 2025 года я перешел на парадигму работы "AI first" с полным созданием всего необходимого посредством ИИ кодинга.

Мне понадобилось более полугода, чтобы разработать и протестировать на реальных рабочих задачах пайплайн работы с нейросетями, учитывающий особенности разработки под 1С. После чего я начал делиться накопленным опытом с коллегами, и собирать от них обратную связь о их нейросетевом опыте работы с 1С.

Эта статья - текущее подведение итогов от меня и порядка пятидесяти коллег.

Итак, что на сегодня, 12 декабря 2025 года, нейросети делают полезного для 1Сников (программистов и аналитиков)?

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

Тысячи команд одновременно столкнулись с необходимостью искать альтернативу, причём желательно не методом научного тыка.

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

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

Бэкенд-разработка — устойчивое и востребованное направление в IT. Но с ростом в карьере растут и требования к разработчику — нужно знать языки и API до проектирования архитектуры, понимать распределённые системы, облака, DevOps-подходы и иметь софт-скиллы. 

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

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

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

В статье будет рассмотрена большая часть современных агентских IDE которые хоть кто то из знакомых и подписчиков использовал, а именно: Cursor, Kiro, Claude Code (Расширение), Roo Code, Kilo Code, Antigraviry, Cline, WindSurf, Continue, TRAE, Qode, Warp ADE, Zed

Для тех кто не любит читать итоговая табличка конечно же в начале:

В последнее время я читаю эссе Шона Гёдеке о том, что значит быть Staff+ engineer. Его статьи (в частности, Software engineering under the spotlight и It’s Not Your Codebase) абсолютно точны и кажутся до боли знакомым опытом для всех людей из «Big Tech».

Теоретически, я соответствую тем реалиям, которые он описывает: я Senior Staff engineer в Google. Тем не менее, его работы вызывают у меня тягостное чувство беспокойства. Сначала я списывал это на цинизм, однако, поразмыслив, я осознал, что проблема заключалась не в написанном Шоном, а моей интерпретации.

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

Вместо этого я пошёл по другому пути, на котором упор делается не на внимание руководства, а на систему, и где ты не винтик, а несёшь ответственность.

Пока вы смотрите сериал, инженеры Иви обновляют код и готовят релизы. А DevRel-менеджер помогает им рассказывать об этой работе громко и интересно.

В статье рассказываем, почему его задача — не охота за кандидатами, а построение мостов между разработчиками и IT-сообществом.