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

Как я потерял несколько лет, делая всё кроме главного — и что с этим сделал

Эта статья про две вещи. Сначала зачем: годы прокрастинации, иллюзия занятости и простая механика, которая это сломала. Потом как: 35-й вайбкодинг-проект за 10 месяцев, событийная архитектура, 39 коммитов за 3 недели, TypeScript, Playwright, LLM и деплой на двухъядерный VDS.

На Хабре вышла [статья Эдуарда Ланчева] — честная история, как один человек за 3 месяца с помощью ИИ собрал полноценный шахматный сервис. У меня похожая. Только не про шахматы, а про предпринимательство. И не 100 тысяч строк, а 9 500 — но с event store, инвариантами и Prometheus на проде.

Часть 1. Медоборудование, прокрастинация и иллюзия занятости

Потерянные годы

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

Казалось бы, что сложного.

Я не продавал.

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

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

Я потерял несколько лет. Единственный вывод: что-то подсознательно избегалось.

Другие проекты — та же история

Прошло время. Новые проекты, другая сфера. И всё повторилось.

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

В очередной раз пытаемся понять: «есть ли место в нашей команде системному аналитику и нужен ли он нам вообще?»

Часть первая.

Я не помню ни дня, когда Azure не работал бы в стрессовых условиях.

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

Весной и летом 2024 года началась масштабная инициатива по увеличению количества VM, которое мог хостить каждый узел. С точки зрения бизнеса всё было понятно: повышение плотности уже имеющихся серверов гораздо дешевле, чем построение новых дата-центров. Развёртывания Azure на мощностях компании всегда были ограничены шестнадцатью VM на узел. До того года собственные коммерческие облака Microsoft работали максимум с 32 VM, и это всё равно крошечная доля от теоретически поддерживаемых гипервизором 1024 VM.

Цель заключалась в увеличении на 50%, до 48 VM на узел, с перспективой увеличения до 64 в будущем. То, что должно было стать задачей по повышению произвольных ограничений ПО, привело к росту вылетов и инцидентов на 50%. Проблемы масштабировались ровно пропорционально плотности.

Ранее, когда я ещё продолжал работать над планом переработки интерфейса гипервизора для нижней части стека узлов Azure, мы провели исследование с командой Core OS, отвечавшей за другую сторону Hypervisor API. Данные трассировки вызовов показывали, что агенты узлов вместе атаковали гипервизор через интерфейс пользовательского режима WMI, в пике достигая 10 тысяч вызовов в секунду. У команды Hyper-V не было информации о том, какие агенты отвечали за это и почему было необходимо столько вызовов. С нашей стороны тоже никто не мог дать определённого ответа. На этом этапе стало понятно, что проект портирования выгрузки Overlake не будет никогда завершён. Не только из-за описанных выше зависимостей, но и из-за самого динамического поведения стека.

Всем привет. Меня зовут Максим, я разработчик в одном из крупных финтехов России. У нас сейчас (наверно, как и у всех) интенсивно вводят ИИ-агенты для написания кода. Плюс необходимое соблюдение метрик по охвату и использованию данных агентов.

Но никто не задумывается о состоянии души разработчика при KPI обязательного использования ИИ.

От вайбкодинга к профессиональной ИИ-разработке на примере LanChess: 3300 промптов, 832 коммита, 100 тыс. строк кода и путь от POC к продакшен-сервису.

Поздний вечер, я смотрю в терминал. Celery worker на восьмиядерном сервере перемалывает 67 партий блица на Lichess одного из пользователей. Через минуту этот человек получит персонализированную аналитику и упражнения от сервиса, аналогов которого в России найти пока не удалось. Я же сижу и думаю, стоит ли выводить этот сервис из закрытого режима по инвайтам.

Менее чем за 3 месяца я написал 100 тыс. строк кода и ни одной — своими руками. Мне пришлось стать оператором персональных данных. РКН порекомендовал мне убрать авторизацию от Google. А ВК не давал мне подключить свою авторизацию, пока я не стал самозанятым.

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

Это материал по мотивам выпуска подкаста Podcast++ от Онтико и Ви.Tech. В центре разговора - Ольга Ортега, директор по данным и аналитике в Ви.Tech - IT-дочке ВсеИнструменты.ру, и Иван Лукьянов, коуч и ментор директоров и фаундеров крупных компаний. Говорили о жизнестойкости лидера: не как о красивом слове из популярной психологии, а как о практическом навыке, который проверяется не на конференциях, а в моменты, когда все идет не так.

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

Проектный шестиугольник, документация проектов, внутрянка проектных команд, фреймворки обратной связи, система обучения в проектной команде и всё самое интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Из этой серии статей вы узнаете о, вероятно, самой глупом, легко предотвратимом и дорогом провале 21-го века, из-за которого Microsoft чуть не потеряла своего самого крупного клиента (OpenAI) и доверие правительства США.

Скучным утром понедельника 1 мая 2023 я впервые вышёл на работу в Azure Core в качестве сениор-сотрудника команды Overlake R&D, разработавшей карту выгрузки и сетевой ускоритель Azure Boost.

Azure не был для меня чем-то новым: наверно, это самая длительная моя подписка на облачный сервис, который был запущен в феврале 2010 года под названием Windows Azure.

Не был я и новичком в Microsoft: с 1 января 2013 года я был частью команды разработчиков Windows, а позже помогал выполнять миграцию SharePoint Online в Azure; в дальнейшем я присоединился к команде Core OS в качестве разработчика ядра. В ней я помогал совершенствовать ядро, участвовал в разработке и реализации платформы Container, поддерживающей Docker, Azure Kubernetes, Azure Container Instances, Azure App Services и Windows Sandbox. Выпуск всех этих технологий привёл к получению множества патентов.

Кроме того, я участвовал в мозговом штурме при создании прототипов карт Overlake в 2020-2021 годах, в составлении драфта предложения коммуникационного протокола и сетевого стека Host OS <-> Accelerator Card ещё на том этапе, когда у нас было лишь последовательное соединение отладчика. Также меня привлекали в качестве специалиста по Core OS, и я помогал разработчикам Azure Core диагностировать глубокие проблемы операционной системы.

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

Так как я был вернувшимся сотрудником, то пропустил обучение для новичков и получил приглашение Global Security на полдень для получения своего бейджа, но мой будущий менеджер спросил, смогу ли я прийти раньше, потому что тем утром у команды должно было состояться ежемесячное совещание по планированию.

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

Если вы помните первую статью, я рассказывал про небольшое macOS‑приложение для фоновой записи таун‑холлов и других «скучных» встреч. Оно работает локально, без облака, транскрибирует прямо на Mac и не требует подписки — это просто инструмент для одной задачи, а не продукт‑мессия.

Скачиваний и отзывов у приложения было немного, но я сам продолжаю им пользоваться почти каждый день. В результате накопилось несколько мелких, но неприятных «щелчков» в UX: не хватает языков, неудобен плеер, нет понятного индикатора записи и тому подобное. Решил: раз я использую этот инструмент сам, почему бы не довести его до того вида, который будет удобен именно для меня. Тем более некоторые мои друзья так же начали его использовать и стали делиться обратной связью.

Меня зовут Андрей Трегубов, я руковожу группой DevOps в Ви.Tech, IT‑дочке ВсеИнструменты.ру. Недавно мы записали подкаст с Александром Крыловым, директором по развитию продукта «Штурвал», и обсудили, где у DevOps заканчивается роль «ребят, которые иногда помогают разработке» и начинается сервисная модель с понятным входом, приоритетами и правилами игры. В этой статье я собрал из нашего разговора самое практичное: когда DevOps уже пора выстраивать как сервис, почему на росте перестает работать героизм, как не утонуть в поддержке, что делать с зоопарком технологий и где в этой истории нужны Enabling Team, безопасность и ИИ.

Можно долго спорить о терминах, но на практике все очень приземленно. Есть команда, к ней приходят с запросами, она что‑то делает, где‑то автоматизирует, где‑то чинит, где‑то вытаскивает всех из пожара. И какое‑то время это даже выглядит нормально. Проблема в том, что «нормально» и «масштабируется» далеко не одно и то же.

На днях прислали в рабочую почту очередное ТЗ в Word на разработку, для комментирования и оценки реализации. При том что у нас есть корпоративный Confluence - мощнейшая система, как раз предназначенная для коллективной работы.

Почему многие до сих пор продолжают изначально использовать Word как основу для обмена информацией?

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

Но давайте сразу расставим точки. Claude не заменяет мне голову. Он — напарник. Second brain. Тот, кто собирает информацию, готовит черновик, вытаскивает контекст из прошлых переписок. А решения принимаю я. Всегда. Это не «AI сделал за меня работу» — это «AI подготовил мне почву, чтобы я работал быстрее и не тратил мозг на рутину».

Большинство статей про AI-автоматизацию подают это иначе: «подключил ChatGPT к Zapier — теперь у меня автоматические письма!» На практике это шаблон с пятью переменными, который ломается на шестом письме, потому что AI не помнит контекста и каждый диалог начинает с чистого листа.

Я решил собрать 10 задач, которые раньше делал руками, а теперь — нет. В каждой из них Claude работает как copilot: предлагает, готовит, собирает. А финальное слово — за мной. На примере Claude Cowork — агентного десктоп-приложения от Anthropic, которое вышло в январе 2026.

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

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

Один AI-агент на базе Claude Sonnet закрывает 100% моих DevSecOps-задач. Без фреймворков, без оркестраторов, без векторных баз. Только LLM, операционная система и markdown-файлы. Рассказываю архитектуру, которая за этим стоит.

Даже опытные руководители пасуют перед сложными разговорами. Мы молчим, когда сотрудник делает что-то не так. Терпим, надеемся, что «само рассосётся». А потом удивляемся, почему команда живёт в стрессе, а люди уходят, так и не узнав, что от них хотели.

В этой статье — только практика:

▫️ Почему отсутствие обратной связи хуже, чем критика.
▫️ Как работают фреймворки SBI, COIN и радикальная откровенность на реальных примерах.
▫️ Пошаговый алгоритм подготовки к разговору, который не испортит отношения.

Статья будет полезна начинающим и практикующим тимлидам, а также разработчикам, которые планируют переход на руководящую позицию.

Когда смотришь на рынок AI-агентов, создаётся впечатление, что все соревнуются в одном и том же: кто даст модели больше инструментов, больше доступа и больше свободы. Мы попробовали зайти с другой стороны. Что будет, если не наваливать возможностей без разбора, а думать в первую очередь о безопасности и предсказуемости? Так и появился «Союз».

Сегодня мы с товарищем открываем его исходники, а я расскажу, как мы к этому пришли и почему такой подход вообще сработал.

Обзор и ссылки на исходники в конце статьи.

Привет, Хабр! С вами Валерия Батон, руководитель направления рекрутмента Flowwow.

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

AI уже ускоряет создание кода, ADR и документации, но одновременно повышает нагрузку на ревью, проверку и контроль стабильности. Поэтому следующий шаг для инженерных команд - не просто встроить AI в текущий SDLC, а пересобрать сам процесс поставки вокруг контекста, harness, quality gates и learning loop.

За 6 лет работы продакт-менеджером в разных решениях для автоматизации проектов я видел одно и то же много раз: выбирают систему по чек-листу — «есть Гант? есть ресурсы? есть бюджеты? берем!». Через n месяцев оказывается, что не так уж и важен сам факт наличия функций. Невозможность адаптировать продукт под реальные процессы — вот что заслоняет собой все остальное.

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

В статье вы найдете:

— еще одну неприятную историю о ведении проектов — с подсчетом денег в чужих карманах; 

— 4 проблемы жестких систем и их решения из моей собственной практики;

— разбор трансформации low-code Waterfall инструмента в Agile всего за неделю неспешной работы.