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

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

Если смотреть на «Колобка» с высоты жизненного опыта и системной архитектуры, то перед взором эпично раскинется поле Spaghetti-кода, написанного на коленке под палящим дедлайном. Знаете это чувство, когда менеджер вбегает в опенспейс с криком «Заказчик голоден, релиз нужен вчера!»? Это не работа. Это агония.

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

Я все чаще ловлю себя на мысли, что рынок IT-аутстаффинга в России заметно деградировал. Причем это не абстрактное ощущение из серии «раньше было лучше», а вполне конкретные наблюдения из проектов. Компании продолжают платить за senior-разработчиков, но чаще получают команды уровня middle или даже junior. Иногда это становится понятно почти сразу, а иногда только спустя пару месяцев. Но результат в итоге один - ожидания не совпадают с реальностью.

Всем привет! Меня зовут Александр Барыков, я руковожу платформенной командой DevOps и являюсь лидером DevOps-комьюнити в нашей компании.

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

Почему рост IT — это не про новые команды и инструменты, а про структуру, ответственность и управление сложностью

Меня зовут Александр Чистилин, я руководитель отдела автоматизации продаж в Ви.Tech, IT-дочке ВсеИнструменты.ру. Недавно я записал подкаст с Артемом Пулявиным, ex CTO Ситидрайв, и мы много говорили о карьерных разворотах, которые на бумаге выглядят как шаг назад, а на практике становятся точкой ускорения. Хочу разобрать эту тему без мотивационных мантр и героизации: когда даунгрейд действительно помогает расти, а когда это просто красивая упаковка для усталости, растерянности или бегства от текущих проблем.

Знаете, что общего между щенком лабрадора и корпоративным AI-проектом? Оба сначала кажутся милыми и недорогими, а через полгода жрут столько, что хочется плакать. Только щенок хотя бы ласкается, а нейронка просто молча выставляет счет за GPU. В этой статье мы вместе с Александром Меркушевым (AI-консультант, архитектор облачных и AI решений, руководитель экспертной группы по внедрению ИИ в Яндексе) разбираемся, как AI меняет структуру инфраструктурных затрат, что с этим делать уже сейчас и, главное, поможет ли тут FinOps.

Присоединяйтесь к нашему сообществу «Практики FinOps» в Telegram.

Привет, Хабр! Platform V DataSpace Community Edition — это open source-инструмент для быстрой разработки бизнес-приложений. В статье мы познакомимся с созданием решений с DataSpace на практическом примере банковского приложения, разберёмся, как работает платформа и почему она может стать вашим секретным оружием для создания MVP.

Представьте, что вы выкидываете около 10 миллионов рублей в год просто на то, чтобы ваш Kubernetes-кластер вертелся, а логи не съедали всё свободное место. Пока инженеры строят распределенные системы ради красивой строчки в резюме, каждый лишний сетевой запрос срезает вам конверсию, а облачная инфраструктура обходится втрое дороже своего железа. Давайте посчитаем реальный TCO микросервисов и разберемся, почему даже гиганты вроде Amazon Prime Video возвращаются к монолитам, сокращая траты на 90%.

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

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

Я коуч, специализирующийся на выгорании и нейроотличиях в IT. И я сильно злюсь. Злюсь, как живой человек, который регулярно разгребает последствия того, о чём на Хабре пишут как об успешном кейсе.

Недавно вышла статья про то, как избавляться от незаменимых сотрудников. Там bus factor, ротация, работа вслух, и финальный аккорд – «в сложный период ушло 40% команды, но мы не сорвали ни одного релиза». Подаётся как успех менеджера. Я хочу поговорить про другое: про тех, кто такие статьи поддерживает и несёт их в мир и презентации. Не лично про людей – про тип мышления, который производит такие тексты, такие команды и моих будущих клиентов.

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

У нас в конфигураторе Macroscop камеры организованы в виде «дерева».

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

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

Я работаю в Claude Code каждый день. Не «попробовал пару раз и написал статью» — а реально каждый день, минимум 8 часов, иногда значительно больше. Больше года. Если грубо посчитать — это 3000+ часов в терминале. За это время я успел построить собственную систему оркестрации из 39 агентов, опубликовать её как open-source, набрать звёзды на GitHub — и эволюционировать дальше.

Сейчас весь мой опыт сконцентрирован в трёх плагинах.

Полгода назад я написал на Хабре про Claude Code Orchestrator Kit — 39 агентов, 38 скиллов, 25 слеш-команд. Серьёзная система, реально работавшая. И я ей горжусь — это был важный этап.

Но когда сидишь в инструменте по 8 часов в день — быстро видишь, что можно сделать лучше. Экосистема Claude Code развивается быстрее, чем один человек способен обновлять свой кит. Каждые две-три недели Anthropic что-то меняет — новые API для плагинов, новые возможности агентов, новые паттерны. И каждый раз нужно лезть в 39 файлов агентов, проверять, не сломалось ли что-то, не устарел ли паттерн.

В какой-то момент я понял: пора эволюционировать. При моём объёме работы с Claude Code часы в неделю уходили не на продукт, а на починку инфраструктуры. Значит, нужен другой подход.

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

Привет! Это снова Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Наши операторы продолжают бороздить просторы K8s, а инсталляторы — разворачивать новые кластеры, и мы готовы поделиться с вами новыми полезностями.

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

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

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

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

Пользователь спросил ChatGPT про бизнес-идею «говно на палке». Ответ: «It’s not just smart - it’s genius». Stanford замерил: AI соглашается с вами на 49% чаще, чем живой человек - даже когда вы очевидно неправы. Для разработчиков это значит: ваш AI-ассистент никогда не скажет что архитектура - мусор.

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

В ИТ много неугасающих дискуссий: микросервисы или монолит, доступный или открытый код. Еще один спор из этой же категории: должен ли руководитель разработки писать код? Мы в Beeline Cloud решили обсудить различные мнения по этому поводу: программировать и тем самым поддерживать авторитет среди коллег или сосредоточиться на развитии команды? Разобрались, какие аргументы приводят сторонники и противники «управленцев-кодеров», а также сделали подборку книг для начинающих путь в роли руководителя разработки.

Любители вайбкодинга и агентного программирования говорят, что работают в 2, 10, а то и в 100 раз продуктивнее! Один даже разработал с нуля целый браузер. Невероятно!

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

В их поиске мы заглянем в PyPi, главный репозиторий пакетов Python. Он большой, публичный и регулярно измеряется, так что в нём должен быть заметен хоть какой-то эффект от появления ИИ.