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

Ваш бизнес — это Лебедь, Рак и Щука. И как вы устали быть кучером.

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

Это не просто метафора, это диагноз для 9 из 10 компаний:

🗣️ Коммуникационный коллапс: Ваши отделы - это Лебедь, Рак и Щука, которые тянут бизнес в разные стороны. Продажи, производство и финансы говорят на разных языках, а вы разрываетесь между ними, туша пожары.

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

💸 Масштабирование хаоса: Бизнес растет, но радости нет - есть только паника. Вы пытаетесь управлять ростом, нанимая новых людей в сломанную систему, и в итоге «воз» вашего бизнеса просто разваливается на взлете.

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

Готовы перестать быть героем басни Крылова и стать, наконец, главным конструктором своей ракеты?

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

Меня зовут Сергей Кузикян, я руководитель проекта из отдела внедрения информационного моделирования архитектурного направления в ПИК Digital.

Мы в ПИК используем для проектирования объектов технологию информационного моделирования зданий, более известную как BIM. Подробнее о том, как мы с ней работаем, можно почитать в статье «Как BIM помогает оптимизировать процессы?». И в рамках применения технологии BIM архитекторы используют, на мой взгляд, самую удобную программу — Autodesk Revit.

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

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

Для рабочей документации собирают, помимо подготовки планов и разрезов, объемы материалов и изделий, необходимых для строительства объекта. Эти данные в дальнейшем будут уточняться ПТО (производственно-техническим отделом, который отвечает за организацию, планирование и контроль строительных и производственных процессов), но в данных также требуется высокая точность расчетов для корректных закупок. Именно от проектировщиков архитектурного раздела приходит информация о габаритах проемов, рам окон и дверей, о составе полов, потолков и отделки стен. Цена ошибки также высока и может вылиться в крупные затраты для компании.

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

Утром 1 августа 2012 года инженер Knight Capital запускал обычное обновление кода на восьми серверах. На одном сервере обновление сломалось. Там остался кусок legacy-кода 2003 года, который написал уволенный несколько лет назад разработчик.

Через 45 минут компания потеряла $460 миллионов и почти обанкротилась.

«В последнее время все меньше иностранных компаний остаются доступны в России. В связи со сложными внешнеполитическими процессами, внутренний рынок требует все больше отечественных независимых „импортозамещающих“ разработок во всех сферах производства, включая и горную промышленность.»

Примерно с такой формулировкой к нам обратилось одно крупное предприятие из области добывающей промышленности.

---------------------------------------------------

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

Привет! Меня зовут Анна, я маркетолог команды цифровой трансформации Ареал.

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

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

Мы работаем в Figma, но систему можно организовать в любом редакторе.

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

Для упрощения восприятия сократил немного деталей, но с сохранением сути.
Представленные данные на экране СберБанк Онлайн – вымышленные.

Описание постановки задачи

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

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

Всё-таки нашли оптимальный вариант, совместив JWT-токены с обменом запросами между сервисами.

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

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

В условиях высокой конкуренции крупный бизнес активно внедряет процессный подход для повышения эффективности и удовлетворенности клиентов. Но внедрить — полдела. Ключевой вопрос: как организовать хранение и управление моделями этих процессов? 

Меня зовут Евгений Рошковский, я специалист по процессному управлению в ПСБ. Расскажу, как мы выстраиваем работу с процессным репозиторием.

Производственная система «Росатом» (ПСР) – это культура бережливого производства и система непрерывного совершенствования процессов для обеспечения конкурентного преимущества на мировом уровне.

Она была разработана на базе лучших образцов отечественного и зарубежного опыта, в частности, системы научной организации труда, производства и управления (НОТПиУ) Министерства среднего машиностроения СССР и Toyota Production System японской автомобильной компании «Тойота».

Всем привет! Меня зовут Денис Ульянов, и я продолжаю серию статей «От разработчика к руководителю». Сегодня хочу рассказать о том, как мы создавали и адаптировали собственную методологию разработки.

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

Когда мы говорим о гибких методологиях управления — Scrum, Kanban, Lean — мы почти неизбежно ссылаемся на западные источники. Agile-манифест родился в США, Scrum был разработан в Японии и популяризирован в Америке, Lean — из Тойоты. Это всё эффективно, современно, научно. Но встаёт вопрос: а есть ли у нас, в России, свои, родные подходы к управлению людьми и процессами?

Можно ли найти в отечественной истории не просто аналоги, а полноценные альтернативы — не для отрицания западного, а для понимания своей специфики?

И вот тут на сцену выходит человек, которого вряд ли ожидаешь увидеть в статье про Scrum.

Антон Семёнович Макаренко — советский педагог, воспитатель беспризорников, автор системы коллективного воспитания.

Да, вы не ослышались. Scrum-мастер Антон Макаренко.

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

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

Меня зовут Антон Мунгалов, я директор практики инфраструктурных решений в Лиге Цифровой Экономики. В начале 2025 года исполнилось 10 лет, как я работаю в компании. И так вышло, что 90% моих сотрудников работают удаленно — в других регионах. Я управляю командами уже 15 лет, а уровень вовлеченности персонала в моей практике за последние 5 лет стабильно держится в районе 90%.

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

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

Почему ваша BPMN-стратегия - это путь в никуда. Научный взгляд на управленческий тупик.

Мы привыкли доверять стандартам. Но что если главный стандарт описания бизнес-процессов - BPMN - фундаментально порочен?

Это не просто мнение, это факты из когнитивной психологии и исследований IT-проектов:
🧠 Когнитивная перегрузка: Человеческий мозг не способен эффективно работать с сотней визуальных символов. BPMN нарушает базовые принципы эргономики.
🌉 Коммуникационный разрыв: BPMN так и не стал единым языком для бизнеса и IT, порождая бесконечные ошибки "перевода".
🏢 Архитектурный тупик: Даже в связке с мощными ERP-системами, BPMN лишь автоматизирует "функциональные колодцы", а не создает целостную систему.

В своей новой статье я провожу параллель между провалом советского проекта ОГАС и современными проблемами "цифровизации". И показываю, как наследие той самой инженерной школы в виде языка ДРАКОН и современных платформ (АСис) позволяет построить то, о чем все говорят, но никто не умеет - настоящую, работающую холакратию.

Готовы посмотреть на управление процессами под другим углом? Читайте полную версию.

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

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

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

Одно недопонимание на встрече может стоить вам недель переделок. В этой статье рассказываем, какие визуальные нотации помогут бизнес-аналитикам и командам понимать друг друга без лишних ошибок. Простые схемы и диаграммы, которые ускорят работу и сделают процессы понятнее для всех: от заказчика до разработчика. Узнайте, как выбирать и применять BPMN, ERD, Sequence Diagram и User Story Mapping в реальных проектах.

Карта стейкхолдеров, карта эмпатии, agile чаще проваливается, мотивация по Герчикову, эффект Черномырдина, цезари, запрещенные фразы и всё интересное, что писали за последние 2 недели про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

В недавнем материале о становлении отраслей в Китае я проводил параллели между мегапроектами КНР и СССР, где ключевую роль играли партийное администрирование, номенклатура и идеология. Это классическая модель «сверху» — когда государственная воля создает индустрию на пустом месте.

Но возникает вопрос: а возможен ли обратный путь? Может ли новая отрасль родиться «снизу» — не по указу, а благодаря энергии и энтузиазму лидеров, фанатов своего дела? Были ли в России подобные прецеденты?

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

А теперь — прыжок на 30 лет вперед. Картина радикально меняется: игроки богатеют, товарооборот растет как на дрожжах, бюджет получает солидные отчисления.
Но самое удивительное — появляется и активно работает отраслевая наука: научные школы, исследовательские центры, конструкторские бюро. Фантастика? В России?

Поверьте, это не вымысел. Это реальная история успеха, в которой замешаны Николай Верещагин, Дмитрий Менделеев и… российское маслоделие.
Как это было? Причем тут экосистемы в ИТ? Расскажу прямо сейчас.

Здесь приведен перевод критической статьи из блога "John Farrier for software engineers" об "исследовании" о том, что "Agile-проекты проваливаются на 268% чаще".

Привет! Меня зовут Ваня Тришкин, я тестировщик в KTS.

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

Сегодня я не просто опишу панель DevTools, а приведу примеры сценариев, в которых она может понадобиться менеджеру. Заодно для каждого инструмента я дам небольшие упражнения, которые помогут закрепить материал и увереннее пользоваться тулзами на практике.