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

Я руководитель проектов, работаю с крупными корпоратами и банками первой пятёрки.

Самый ад — это когда проект на стыке двух таких банков. У меня есть живой пример )

На этом проекте:

На этом проекте:

— Юристы и безопасники из двух банков 4 месяца гоняли договор по кругу. Надо было как-то их договорить и всё-таки начать работать.

— Договор был рассчитан до 2026 года, а бюджет в системе был заложен только на 2025-й. Бухгалтерия возвращала ошибку Not defined и предлагала запланировать бюджет на 2026 год прямо сейчас.

— Уволился ключевой подписант.

— Это был ИТ-директор!

Так что у нас есть все виды бюрократии: комплаенс, Департамент кибербезопасности (ДКБ), риск-чемпионы и, конечно, юристы.

Как я уже говорила, это ад.

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

Что бывает, когда такое не выполняется, мы отлично знаем по взломам доставки еды, например, когда стандарт был, но его не применили.

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

На одной из конференций для руководителей я встретил Артема (имя изменено), талантливого, как многим казалось, тим-лида. Формально — звезда: он обладал хорошей экспертизой и круто смотрелся во время выступлений. Неформально — его ненавидела вся команда и коллеги из других отделов (компания была и есть большая, поэтому на том мероприятия было много её сотрудников). 

Стоило кому-то начать говорить, как Артем мрачнел и тут же перехватывал инициативу, переводя разговор на свои достижения. Он мастерски игнорировал чужие успехи, выставляя на показ лишь свои. Коллеги в курилке шутили, что соответствовать его «стандартам» не может никто, включая, пожалуй, Илона Маска. Естественно, с ним старались не работать, а проекты, куда его назначали, зачастую начинали буксовать из-за кадрового сопротивления. Да, KPI выполнялись. Но работать с Артемом почти никто не хотел, несмотря на его экспертизу и опыт. 

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

Привет, Хабр! Я — Таня Дудо, уже очень много лет помогаю людям и командам обмениваться знаниями. Сейчас занимаюсь в VK развитием внутренних профессиональных сообществ, а также обучением, развитием экспертов и культурой HiPro.

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

Современные инструменты успешно превращают текстовое описание в наглядные диаграммы, включая профессиональные нотации, например, BPMN.

Такие инструменты, как Miro AI, Whimsical и Eraser.io, превращают текстовое ТЗ в аккуратные и настраиваемые схемы за считанные секунды. ChatGPT выступает в роли универсального аналитика, который может и написать код для диаграммы, и детально её описать. А для задач профессионального моделирования уже существуют специализированные решения вроде Bonita AI BPMN Generator.

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

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

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

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

Хоть стой, хоть падай — так встретил российский бизнес налоговые нововведения 2026 года. Во-первых, «взрослый» НДС, державшийся до этого 6 лет на уровне 20%, увеличивается до 22%. Во-вторых, порог применения НДС для фирм на упрощенке (УСН) снижается до 20-15-10 млн рублей. Чем это чревато для бизнеса?

Аська, Skype, первые групповые чаты — всё это было частью нашей цифровой молодости. Я собрал ностальгическую историю о том, как менялись технологии и наши привычки интернет-общения за 30 лет.

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

Этот текст для компаний, занимающихся аутсорсом и аутстаффингом. Продвигая статический анализ кода в целом и инструмент PVS-Studio в частности, мы отдельно не выделяем компании этой направленности. Сейчас, в связи с вступлением в силу 1 марта 2026 года приказа №117, всё немного по-другому.

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

Привет, Хабр! Меня зовут Артур Ишмаев, я — руководитель отдела внедрения и развития нейросетей в девелопере ПИК. 

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

Вводная часть

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

Задача генерации плана дома

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

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

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

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

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

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

Хочу рассказать о магии построения Dream Team: как у меня получилось это сделать на текущем проекте.

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

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

Собрал обзор 10 планировщиков задач — для командной работы и для личной продуктивности. Кратко объясняю, как устроено планирование в каждом сервисе, какие фичи действительно полезны и кому что подойдёт.

Я часто вижу ситуацию, когда менеджмент во всем винит руководителей проектов. Уволили одного, поставили другого, «более опытного». А он тоже почему-то не справился. Опять накормил завтраками, обещая, что вот-вот и все будет. Тем временем, проект, на который постоянно назначают новых РП, уже в настолько глубокой Ж, что… все, включая заказчика, хотят его закрыть. Списать десятки миллионов в убытки и снова всех уволить. Нанять нормальных, ответственных людей!

Сегодня поделюсь своим кейсом, как много лет назад я видел похожую ситуацию при реализации проекта по запуску системы в крупном банке. Менеджмент сменил уже ТРЕХ руководителей проекта, но «завтраки» продолжались. Сроки и бюджет росли каждый день как на дрожжах.

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

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

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

Есть такое мнение, что ретроспективы — пустая трата времени и бесполезное передвигание карточек. Сегодня я попробую доказать вам, что это мнение в корне неверно и из ретроспектив можно (и нужно!) извлекать огромную пользу. Припас для вас несколько не попавших под NDA кейсов и приемов, которые мы сами применяем в командах разработки. Поехали!

Привет, Хабр. Я старший android-разработчик и скрам-мастер. За годы работы я видел десятки команд, которые относились к ретро как к обязаловке, и столько же тех, которые превратили их в мощный инструмент развития. Разница между ними была не в размере команды или сложности проектов, а в понимании одного простого принципа.

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

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

Это не теория и не маркетинговая сказка. Это реальный проект, с реальными цифрами, диалогами и сложными решениями. Меня зовут Владимир Финк, я генеральный директор компании INTEKEY, и эта история началась несколько лет назад, когда мы только выводили на рынок нашу WMS-систему. Мы тогда были молодыми и голодными, но уже тогда в нашем ДНК было заложено правило: сначала думаем, потом — делаем. И, как оказалось, это был наш главный козырь.