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

Компания выбирает не только преимущества решения. Она одновременно выбирает его цену, ограничения и будущие проблемы.

Поэтому хорошее решение – не то, у которого нет недостатков, а то, чьи последствия увидели, обсудили и сознательно приняли те, у кого есть полномочия за них отвечать.

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

Коротко итоги за год:

— Пустили ИИ в прод.
— Уволили отдел продаж.
— Чуть не положили дата-центр.
— Ещё раз пустили ИИ в прод.
— Сейчас ещё один раунд халявы на 4000 рублей в облаке для новых пользователей.

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

А потом на год пропали. Вышли из беты и пропали.

Нас сгубили корпоративные заказы. Они оказались намного более жирными, чем коммерческое облако. И ещё их стало ОЧЕНЬ МНОГО.

Самый простой ответ на вопрос, почему мы ничего не писали: нам было тупо некогда. 

Но облако тоже развивалось. За этот год мы прошли путь от стартапа до нормального IaaS-провайдера. 

Официальный старт состоялся 26 декабря 2025, под самый Новый Год. И пока вся страна просыпалась и лечила похмелье, я сидел и отвечал на тикеты в саппорт. Я смотрел в монитор и думал: «Кто вообще эти люди, которые 1 января лезут настраивать виртуалки и писать в поддержку?» 

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

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

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

В этой части я проведу вас через наш интеграционный лабиринт. Расскажу, как мы собирали команду, выстраивали процессы, договаривались со стороной интегратора и проектировали идеальное API. Какой путь мы успели пробежать за 8 месяцев хардкора. И как я впервые столкнулся с «обстоятельствами непреодолимой силы». В финале я дам вам 10 правил работы с госами, которые мы вынесли из этого опыта и могут оказаться полезными, если вы окажетесь в подобной ситуации.

Если вы не читали первую часть — рекомендую вернуться. Там о том, как мы выстраивали юридическую защиту и внедряли практически полноценный Agile под маской Waterfall. Это не просто «история», это набор инструментов, который помогал нам не сойти с ума. Но если вам ближе продуктовое мясо и детали реализации — добро пожаловать прямо сюда. Читать мою историю можно в любом порядке.

Приготовьтесь, отправляемся. Следующая станция — «прод».

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

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

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

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

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

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

Начну с одной из них.

Привет, Хабр! На связи Лена, аналитик Directum Projects. Сегодняшние экономические условия тихо (или уже громко) шепчут: «Пора сокращать расходы». И вот уже финансовый директор режет бюджеты на подписки, корпоративные сервисы, командировки и обучение. Пересматриваются закупки и оптимизируется штат.

Проходит полгода, и издержки снова начинают расти.

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

Здравствуй, Хабр!

Давно хотел поделиться своими мыслями и изысканиями на тему: «Чем внедрение ИИ‑агентов в бизнесс‑процессы организаций отличается от всего, что мы привыкли делать раньше, внедряя информационные системы».

И вот, когда индекс ИИ‑хайпа от @anti_agi вышел на плато, а Билл Гейтс сообщает нам, что мы не готовы к эпохе ИИ — по‑моему, самое время это сделать!

Привет, Хабр! (И тебе, случайный читатель, который открыл эту статью в перерыве между двадцатой правкой того, что ты ещё месяц назад гордо назвал финальной версией).

Сегодня давайте без кода и без нытья пофилософствуем на тему:

Когда же продукт готов? И будет ли готов когда-нибудь...?

Девять месяцев назад я начал запускать таймер каждый раз, когда сажусь за конкретную задачу. За это время одна категория “студия” превратилась в систему проектов, ролей и описаний, а тайм-трекинг стал способом оценивать работу не по ощущениям. Рассказываю, как я веду Toggl Track, почему отдельно считаю управление, разработку и созвоны, что помогает не забывать про таймер

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

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

Как это обычно бывает, инициатива похоронила инициатора, а простой список с пометками «что | откуда | пригодится в...» перерос в чуть ли не исследование.

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

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

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

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

Кто на самом деле пишет ваш проект

Что происходит, когда разработку незаметно передают по цепочке — и почему проблема не в самом субподряде, а в потере контекста и ответственности.

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

ИИ-агент может не только писать код, но и сам забирать задачи из YouGile, выполнять их и обновлять статусы. Рассказываю, как я связал Codex и Claude Code с таск-трекером, почему обычный retry после timeout однажды создал дубли и зачем между LLM и API нужен отдельный детерминированный слой.

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

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

Как идут продажи?
Выполняем ли план?
Что изменилось по сравнению с прошлым периодом?
Есть ли просроченная задолженность?
Сколько сотрудников сейчас на местах?

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

Допустим, утром мне достаточно такой информации:

Привет, Хабр! Меня зовут Василий, я директор SaaS-направления в Аспро — мы разрабатываем систему управления проектами Аспро.Cloud.

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

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

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

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

Этим вопросам посвятят секцию «Soft skills, управление командой проекта» на INFOSTART A&PM EVENT 2026.

В центре внимания — практические ситуации, с которыми сталкиваются проектные команды...