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

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

В предыдущей статье мы рассмотрели общий процесс работы аналитиков. 

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

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

За последние десятилетия у компаний появился внушительный набор управленческих инструментов. Waterfall, Scrum, Kanban, SAFe — каждый описан, стандартизирован, проверен на тысячах внедрений.

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

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

Вообще, я — ПМ с опытом в коде. А еще мы с мужем делаем сами ремонт в новой квартире, и в процессе я случайно обнаружила «золотую жилу» неэффективности.

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

Короче, с B2B-продажами в этой нише всё, мягко говоря, не очень.

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

В общем, вот во что это вылилось...

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

Чтобы подобные задачи решались наиболее эффективно, команда «Нанософт» подготовила практический видеокурс по разработке собственных расширений для nanoCAD BIM Строительство с использованием открытого API.

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

Меня зовут Темченко Сергей, и за последние два года я в разных ролях участвовал во множестве LLM-проектов. Недавно я заметил, что на полях моей тетради накопились значительное количество заметок. Ими я хочу с вами поделиться.

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

В этой статье я хочу поделиться практическим опытом создания архитектурной BIM-модели многоквартирного жилого дома в nanoCAD BIM Строительство на основе уже существующего проекта, выполненного в Archicad.

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

Исходные данные проекта

История проекта началась с обучения одного из наших клиентов работе с программными продуктами линейки Нанософт. В частности, мной проводился курс по nanoCAD BIM Строительство.

В рамках обучения заказчик использовал программу преимущественно для разработки конструктивной части здания. Поскольку объект представлял собой кирпичный жилой дом, средствами nanoCAD BIM Строительства в рамках раздела КР были выполнены: раскладка пустотных плит перекрытий, лестничных маршей и площадок, фундаментных блоков, перемычек над проемами и деревянная стропильная система крыши.

Как мигрировать с Jira и Confluence на российское ПО за одни выходные?

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

В первой части статьи мы пришли к выводу, что само использование ИИ не ускоряет инженерную систему. Можно вырастить MAU LLM, потом MAU API, раздать людям кодинг-агентов и всё равно не увидеть изменений в Lead Time, Throughput и Defect Rate.

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

Девелопмент — это динамичная и меняющаяся среда, несмотря на довольно строгий внешний образ.

Со 2 апреля 2026 года при подаче на согласование архитектурно-градостроительных решений (АГР) объектов капитального строительства в Московскую городскую экспертизу (МГЭ) обязательно предоставление цифровой информационной модели (ЦИМ АГР) в формате IFC, соответствующем машиночитаемым требованиям в формате IDS.

Во многих компаниях строительной отрасли в этом году обсуждают, что BIMы (сотрудники BIM-команд) стали тратить часы на итерации: нужно было выгрузить модель, проверить, исправить и снова выгрузить. В этой статье расскажем, как в ПИК сократили время подготовки и научили систему проверять соответствие требованиям IDS еще на этапе проектирования — без единой выгрузки в IFC. Опытом поделятся Максим Курбатов, руководитель продукта BIM Inspector в ПИК Digital, и Авенир Барышев, координатор по технологиям цифрового моделирования в ПИК.

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

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

Я главный режиссёр и руковожу внутренним продакшеном одного из центральных каналов. Каждый месяц моя команда производит около 400 видеозадач. Это проморолики, фирменные заставки, партнёрский маркетинг и контент для соцсетей канала.

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

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

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

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

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

Зачем мы это делаем? Кому всё это нужно? Как можно попасть на такую встречу в качестве гостя или спикера? Вопросов к нам стало прилетать немало, и я решила ответить на них, так сказать, оптом. Если ты  корпоративный автор и тебе не хватает опыта, знаний о Хабре, мотивации, поддержки и вдохновения – велкам под кат! Я поведаю историю этого проекта, а также расскажу про наше авторское сообщество, которое появилось как логичное продолжение одной из таких творческих встреч и частью которого ты тоже можешь стать.

Пять лет назад завершилась моя работа в одном из самых амбициозных, но не завершившихся IT-проектов в истории пассажирских перевозок. Проект для РЖД, который по масштабу и связности экосистемы должен был встать в один ряд со Сбером и обогнать всё, что существовало у мировых перевозчиков. Его убила не кривая архитектура, а пандемия и тектонические сдвиги подковерной борьбы.

Более 15 лет в b2b-разработке приучили меня держать подобные кейсы за контуром публичности. Но сегодня юридические ограничения сняты, и я готов сорвать покровы.

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

Серия первая: Архитектура маскировки. Жесткий процессуальный хардкор, анатомия схемы взаимодействия и готовая методичка с Карточками компонентов, которые спасали наши задницы от бесконечных правок.

Серия вторая: Продуктовое мясо и хроники интеграционного ада. Детальный разбор самого цифрового космолета, погружение под капот легаси-экосистемы, курьезные истории из жизни нашего «прода» в жанре «пиу-пиу». И в завершение 10 наших железных правил выживания с госами.

Добро пожаловать на борт. Физика процесса изменена, но внешне мы стоим на ногах.

Enterprise Architecture помогает связывать бизнес‑цели, технологии и изменения в компании. Но без правильного подхода она легко превращается в набор диаграмм и бюрократию. Разбираем 10 типовых ошибок внедрения EA и способы их избежать.

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

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

Продолжаем делиться опытом цифровизации торгово-производственной компании Никамед. В первой части рассказали об основной логике решения, основной логике решения, автоматизации документооборота и Service Desk. Сегодня поговорим об управлении оптовой и розничной торговлей.

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

Причина проста. Регламенты, которые должны управлять проектами, на практике почти никто не использует – какие-то правила давно устарели, а какие-то погребены в недрах 200-страничного документа. ИСУП же автоматизирует лишь небольшую часть процессов: управление сроками, иногда деньгами и ресурсами, – оставляя за бортом риски, цели, ответственность, связи между проектами и т.д. 

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

Более 80 реализованных проектов, 582 активных пользователя системы и всего 4 месяца на запуск. Таких эффектов удалось достичь «Кузбассразрезуглю» на проекте внедрения Directum Projects. Как выбирали ИСУП, с какими трудностями столкнулись и какой подход использовали, мы спросили у Дмитрия Сосенкова, начальника управления развития ИТ-сервисов ООО «Скиф» — дочерней компании «Кузбассразрезуголь».