Управление проектами *

Дисклеймер. Данная статья не претендует на туториал, руководство к действию или повторение. В ней я пытаюсь ответить на давно дискутируемый вопрос: может ли вайбкодинг использоваться для нужд реального бизнеса? И кажется, ответ положительный — по крайней мере, в рамках осени 2026 года. Статья написана с согласия моего уже бывшего коллеги @smolyakov. В ней намеренно не указаны названия или торговые марки компании.

Резюме: авторы, не обладающие значительным ИТ-бэкграундом, за короткое время навайбкодили несколько реально работающих сервисов для компании, в которой трудились.

Подведены итоги ежегодного студенческого конкурса «САПР‑Перспектива — 2026». Экспертная комиссия рассмотрела 80 проектов из 20 образовательных организаций в 20 городах России и определила 14 лучших работ, отметив качество их исполнения и проработанность инженерных решений.

Конкурс, который был организован уже в пятый раз, предоставляет студентам возможность продемонстрировать навыки работы в nanoCAD, пополнить портфолио, заявить о себе будущим работодателям и выиграть денежные призы. Среди отмеченных выпускных квалификационных/дипломных и курсовых работ — проекты зданий и инженерных сетей, генеральные планы, машиностроительные чертежи и программные разработки. Знакомим с победителями и показываем, как они реализовали свои идеи.

Командный трек

В командном треке победили Виктория Селиванова, Анастасия Гунько, Софья Базимирова и Арина Ягодина из Новосибирского государственного архитектурно‑строительного университета (Сибстрин). Под руководством Юлии Эдуардовны Чмир и Марии Сергеевны Тырышкиной они создали проект «Комплексная подготовка территории земельного участка, ограниченной ул. Амурской, ул. Расковой, ул. Титова и Широким переулком, г. Новосибирск».

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

Хотелось отдельно рассказать о структуре КП, которую мы используем, но в целом мы придерживаемся вечной классики — написанная давным-давно Андреем Тереховым, текст можно найти на Хабре. В целом мы придерживаемся этой структуры, пытаемся отказаться от PDF и перейти на цифровые носители. Туда можно и видео прикрутить и интерактив, но пока королями здесь остаются PDF и Эксель. 

Но сегодня не об этом. 

Элементом любого КП является смета. В целом они есть практически везде, без разницы, работает вы в продукте, агентстве, веб-студии и т.д.

У кого-то смета занимает одну страницу, у кого-то Excel растягивается на несколько десятков вкладок. Где-то заказчику показывают только итоговую сумму, а где-то можно найти часы аналитика, ставку программиста, загрузку дизайнера и чуть ли не количество созвонов.

У каждого подхода есть свои причины.

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

Допустим, у одного подрядчика проект стоит 7 млн, у другого — 10 млн. Кажется, что выбор очевиден. Но если в первой смете нет части интеграций и тестирования, то сравнивать 7 и 10 млн бессмысленно. Поэтому я бы смотрел сначала на состав работ.

Привет, Хабр!

С виду даже самый простой проект, который можно «запромптить» в пару подходов, содержит десятки подводных камней, из-за которых его нельзя назвать production-ready. В этой статье я расскажу, с какими проблемами столкнулась моя команда при разработке сервиса «Запомни это» с помощью нейросетей, почему «два вечера» превратились в полгода и как мы закрывали пробелы, которые ИИ закрыть не смог.

Был конец квартала, и я сидел в пустом офисе, глядя на три открытых окна на двух мониторах.

Слева — презентация с планом проекта. Диаграмма Ганта, красивые вехи, зелёные галочки. Посередине — Jira с фактическим выполнением задач. Часть задач просрочена, часть в работе дольше, чем планировалось. Справа — Confluence, где в протоколе последней встречи менеджер написал: «Обсудили риски по поставщику, нужно зарегистрировать». Я открыл реестр рисков. Риск не зарегистрирован.

Три источника. Три версии реальности. И ни одной, которой можно доверять без сверки с остальными.

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

Я закрыл ноутбук и подумал: дело не только в скорости. Пока сведения о проекте живут в разных системах и не связаны между собой, каждая сверка требует ручной работы, а важный сигнал может затеряться между источниками. Этот эпизод хорошо объясняет путь, который за два года привёл нас к Эйре.

В компании может быть сильная команда, десятки идей и стабильный бизнес — но при этом не быть единого ответа на вопрос: куда двигаться дальше?

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

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

Для этого и проводят стратегические сессии.

В мае 1999 года еженедельная деловая газета Barron’s вышла с печально известной обложкой «Amazon.bomb». На ней лицо Джеффа Безоса было изображено на мультяшной бомбе, готовой взорваться. «Мысль о том, что генеральный директор Amazon Джефф Безос создал новую бизнес-парадигму, нелепа, — говорилось в статье. — Он всего лишь очередной посредник, и фондовый рынок начинает это понимать».

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

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

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

На тот момент я уже работал с Power BI и DataLens, а рабочую версию управленческой аналитики мы развернули на сервере в Visiology. Прототип показали руководству и получили согласование на дальнейшее развитие. То есть на уровне первой демонстрации всё получилось: данные загрузились, дашборды открылись, показатели можно было обсуждать уже не на словах.

Если смотреть только на этот момент, систему можно считать выбранной успешно.

Ретро умирают одинаково: жалобная книга вместо разговора, сорок минут на один спор, экшен-айтемы в никуда. Разбираю тайминг на 45 минут, четыре формата (Start Stop Continue, Mad Sad Glad, 4L, Sailboat) — что писать в каждую колонку и когда какой брать, — и правила, которые держат ретро живым. Во второй части — как устроена моя бесплатная доска для ретро: стек, где хостится, шифрование карточек и что происходит с данными.

Привет! Меня зовут Анастасия и я проектный менеджер и scrum-мастер в Окко. Проектным менеджментом я занимаюсь около семи лет: успела поработать с hardware проектами, CRM-системами, мобильной разработкой, ритейлом.

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

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

В этой статье расскажу, что изменилось в моей работе после появления роли Scrum Master, что оказалось самым неожиданным открытием и почему из всех Scrum-ритуалов именно ретроспектива стала самым ценным инструментом?

Во время выпуска стали из конвертера в сталеразливочный ковш температура — 1600–1650°C. В зоне слива жара такая, что металл светится ярко-белым, и любое незащищённое оборудование обгорает мгновенно. Первые попытки сделать систему визуализации контроля наполнения стальковша в прямом смысле сгорели. А задача внести присадки ферросплавов вовремя, чтобы получить нужную марку стали, — никуда не делась.

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

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

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

Вы знаете, что игры бывают очень архитектурно «грязными» внутри? Но это не помешало им продаваться миллионами копий, или быть написаннами одним человеком на фреймворке для браузерок, или на Lua поверх библиотеки для геймджемов, или вообще ребенком в бесплатной версии юнити. При этом мощный кастомный движок с ECS, job‑системой, своим рендером и рефлексией повсюду вы тоже знаете, но игра на нем, скорее всего лежит третий год у вас в беклоге, так и не сыграная даже пару часов.

Попросили меня по старой дружбе, где‑то с полгода назад, помочь с разработкой и выводом игры в Steam. Ребята до этого занимались нефтью, и накопив деньжат, решили, что называется оставить след в индустрии. Если честно, я несколько отвык от такого «детского» кода и простых решений, что меня несколько удивило, хотя и вернуло на грешную землю из объятий ентрепрайза. Но я сразу оговорюсь, что простая архитектура это не оправдание плохого кода, а способ выбрать, где именно вы позволяете себе быть сложным. Бюджет сложности конечен... прежде всего размером вашей натуральной оперативкой, и тратить его надо туда, где игрок это увидит.

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

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

Miro продали в 13 раз дешевле оценки 2021 года, и я пошёл считать, что вышло из нашей попытки уйти от подписок. За год мы заменили Tilda, Confluence, Jira и Slack своим кодом, целей было две: экономия и гибкость. Экономии не получилось: по полной ставке сеньора и с учётом владения первый год ушёл в минус около 2 млн. Гибкость, кажется, получилась, и выяснилось, что трекер до рабочего состояния доводит не разработчик, а скрам-мастер. В статье цифры по четырём заменам, инцидент с уязвимостью в авторизации, который заставил поставить ревью второй нейронкой, и критерий из трёх вопросов, что переписывать не стоит.

31 августа прод моего приложения пролежал около часа.

Причина была обидно простой. Агент добавил в коммит все файлы из общей рабочей папки, вместе с чужой недоделанной работой. Потом сделал это еще раз. Во второй раз уже после того, как сам записал в правила, что так делать нельзя.

Дальше он начал чинить. Ошибка, правка, следующая ошибка, еще правка. Каждая починка тянула за собой новую поломку. Я посмотрел на это и написал: «верни просто старую версию» То есть откатись к последнему состоянию, про которое точно известно, что оно работало.

И тут поймал себя на странном ощущении. Я только что провел разбор инцидента. Ровно так, как годами делал это на работе с живыми командами. Мысль, которая крутилась у меня с июня, в тот вечер наконец сложилась: я не пишу приложение с ИИ. Я управляю департаментом.

Почти три года назад, когда я начал митапы Verilog Mettup в Hacker Dojo, на них пришел Владимир Чурюкин и когда посмотрел на мою инфраструктуру Basic‑Graphics‑Music, где баш‑скрипты по имени платы строят проект, сразу сказал «А давайте перепишем все на питон». И переписал! С оговоркой что это PoC, то бишь Proof of Concept, то есть он это проверил только на 5-ти платах, а не на всех 45-ти, как мой исходный репозиторий.

А теперь посмотрим, что из этого получилось.

Я больше десяти лет делаю рекламные платформы. Команды за это время были разные — по размеру, по составу, по зрелости. Но почти всегда был один загон — всем почему‑то было очень важно работать по спринтам.

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

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

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