Менеджмент

Привет, Хабр! В этой статье разбираем плюсы и минусы VictoriaLogs как решения для логирования в облачной платформе.

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

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

В статье разбираем три источника скрытых потерь в IT‑разработке: лишние согласования, ожидание между этапами и раздувающиеся расходы на облака и SaaS.

Я всё утро вылизывал план на 1700 строк. Дольше, чем заняла бы сама задача, если бы я сел и написал её руками. И к обеду поймал себя на мысли, что я не написал ни строчки кода, я редактировал документ про то, как код будет написан, и кажется немного поехал 😁

Потом отпустило. Я не поехал. Просто работа переехала, а я не сразу заметил.

Короче. Код стал дешёвым. Любой агент перепишет тебе модуль по запросу, в третий раз, в десятый, на другой язык, ему вообще всё равно. То, за что раньше платили деньги, теперь стоит примерно ничего. А дорого стало то, что по краям от кода. Спереди и сзади. И оба края про одно: сделать правду, которую агент не сможет заболтать.

Потому что заболтать он умеет шикарно. «Готово, всё работает, тесты зелёные». Ага.

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

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

Полгода назад я опубликовал на Хабре статью про «бэклог проблем». Перечитал ее, остался недоволен. В ней я описал симптом и предложил лечить его инструментом, который в моей собственной практике превратился в оружие для защиты от заинтересованных. Главного я тогда не назвал.

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

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

36,4 миллиона рублей в год – столько сэкономила компания QSOFT благодаря использованию искусственного интеллекта: из них  только 7,2 миллиона на оптимизации подбора персонала и почти 13 миллионов за счёт ускорения адаптации сотрудников.

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

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

Снаружи это часто выглядит как вполне нормальная «творческая кухня». Кто-то сообщает инсайт после интервью с пользователем. Кто-то вдохновляется недавним обновлением продукта конкурента. Кто-то предлагает срочно внедрить искусственный интеллект, потому что «тогда можно обходиться без CustDev’а, получать готовые гипотезы за секунды и вообще все уже делают это». Кто-то пересылает обратную связь от продаж, очередной отчёт от клиентского сервиса или поступает новая вводная от топ-менеджмента. Проблема начинается позже, когда становится трудно ответить на простые вопросы: какие следующие идеи брать в работу первыми, какие из них принесут наилучший эффект, какие уже неактуальны, и как ускорить обработку и воплощение идей в продуктах. Если же поток инсайтов и рацпредложений превышает возможности продуктовой команды с ними разбираться, то к списку вопросов добавляются – какие идеи вообще были в работе, какие из них проверяли и какой это дало результат, что было отложено, что отклонено и почему. При этом бэклог разрастается, потому у продактов просто нет времени с этим разбираться – надо успевать закрывать срочные задачи.

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

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

Зацепило, что я сижу ровно в той же яме, только глубже. И гордиться тут нечем.

Я почти не пишу код руками. Вообще. Наговариваю мысли в транскрибатор, кидаю сырой поток в сессию агента и иду дальше. Весь день в терминале Claude Code и Codex: проекты, фриланс, какие‑то побочки, всё туда. Три подписки по $200 в месяц плюс пара китайских по мелочи. Да, я понимаю, как это звучит, но речь не про деньги, к деньгам ещё вернёмся, и не в мою пользу.

И вот на этом фоне история про слепую веру модели читается не как чужая. Это просто моя обычная среда, доведённая до абсурда.

Я долго думал, что вся эта автоматизация освобождает голову. Ну типа нажал, и оно само, а ты отдыхаешь.

Ни фига она не освобождает. Наоборот.

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

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

Привет! Меня зовут Янина. В ИТ у меня 5+ лет коммерческого опыта в Delivery, Discovery, Growth, Data Analytics и я постоянно улучшаю свои харды и смотрю, что делают коллеги из других компаний. Хочу поделиться своим мнением и практическими инсайтами с онлайн-конференции Podlodka Product Crew с теми, у кого не было возможности присоединиться.

В IT-командах есть один устойчивый миф: если продукт хороший, он сам себя продаст.

Ну хорошо, не совсем сам. Ему помогут Product Manager, разработчики, пара постов в Telegram, лендинг, где написано «инновационное решение для оптимизации бизнес-процессов», и релиз-ноутс на языке, который без подготовки читают только автор задачи, техлид и человек, который слишком долго сидел в Jira.

А потом происходит странное.

Фича есть. Код работает. Продакт не спал три недели. Разработчики сделали сложную штуку, которую реально было непросто сделать. Внутри команды все понимают: «Вот оно. Это важно. Это должно выстрелить».

Но рынок почему-то не падает на колени. Пользователи не понимают, что изменилось. Продажи не понимают, как это объяснять. Маркетинг пытается собрать коммуникацию из того, что есть: технического описания, пары комментариев в задаче и общего ощущения команды, что «это важная штука». Клиент смотрит на всё это и думает: «Очень интересно, но мне-то что с этого?»

И вот где-то в этот момент в комнате появляется Product Marketing Manager.

Не чтобы рассказать разработчикам, как писать код. Не чтобы заменить Product Manager. И не чтобы «добавить маркетингового глянца» поверх инженерной мысли.

PMM нужен, чтобы сложная техническая ценность стала понятной рынку.

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

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

Несколько человек отписались: «Если говорить о нашем отделе — результат высокий. Но если выйти за пределы отдела — там для меня начинается настоящий ад».

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

У «Здоровье-Ресурс» всё как у многих производств: технологические карты лежат в папках у технологов, инструкции по безопасности — на отдельном общем диске, коммерческие предложения теряются в почте, а регламенты работы магазинов знает только старший продавец. Новичок в цехе тратит час, чтобы найти актуальную инструкцию, логист сверяет остатки с Excel-файлом трёхмесячной давности, а руководитель узнаёт про ошибку в рецептуре уже по итогам списаний и претензий клиентов.

Как-то я прочитала морально-этический кодекс самураев и где-то к середине поняла, что речь в нём идёт про мою работу — управление проектами и продуктами в IT.

Привет! Меня зовут Карина Хабибуллина, я продакт-менеджер в диджитал-агентстве Атвинта. Веду два проекта в экосистеме крупного промышленного холдинга — фабрику идей и корпоративный таск-трекер.

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

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

В конце 2025 года в нашей региональной девелоперской компании мы запустили Кайдзен‑офис.

Это такой формат, когда любой сотрудник может предложить идею, как улучшить работу. От «давайте перестанем дублировать отчёты в Excel и Power BI» до «давайте перестроим маршрут согласования заявок». Уже за сам факт того, что сотрудник озвучил потенциально полезную идею (то есть экспертная группа её положительно оценила), мы платим небольшое, но приятное денежное вознаграждение. А уж если идея доходит до внедрения и начинает приносить измеримый эффект, цифры уже другого, ещё более приятного порядка.

По моему мнению, Кайдзен сам по себе — просто потрясающая вещь для развития кадров, вовлечения сотрудников в процессное управление и тому подобное. Но это не основная тема данной истории. Эта история о том, как оценить все эти идеи не субъективно, а по‑настоящему. Что действительно является оптимизацией, которая принесёт деньги, а что — просто галлюцинация, с которой согласились эксперты.

К моменту запуска Кайдзен‑офиса компания за пару лет выросла с 50 до 300+ человек. Это девелопер, который занимается региональной экспансией: новые объекты, новые регионы, новые команды от месяца к месяцу. Процессы выстраивались на ходу и при этом обязаны были масштабироваться. Что‑то закреплялось в регламентах, что‑то существовало в режиме «у нас принято так». Процессный офис — это я и трое моих коллег‑аналитиков.

Идеи пошли на удивление быстро, по 10–15 в месяц. Часть из них вообще не про процессы: «нужно меньше совещаний», «давайте сделаем меньше урн для мусора в офисах». Часть про автоматизацию: «эту задачу можно полностью забрать в RPA». А часть, как мы и хотели, про реальную перестройку процессов: маршруты согласования, разделение зон ответственности, временные окна обработки заявок.

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

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