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

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

Boston Dynamics 15 лет учил роботов делать сальто. Никому не известный китайский стартап обещает за полгода сделать робота, который застелет кровать и приготовит ужин.

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

ИИ может построить красивый план роста стартапа на 7 лет. Только этот план не будет иметь ничего общего с реальностью.

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

У нас было 120 процессов, 9 областей управления, более 100 авторов из 60 компаний, 3 ветки на каждый репозиторий и ещё по одной на каждую задачу, AI-агент, таск-трекер, толстый клиент редактора и три портала документации. Не то чтобы всё это нам было нужно, чтобы описать методологию управления в ИТ. Но когда однажды начинаешь собирать серьёзную базу знаний — возникает тенденция разогнаться так далеко, как только сможешь.

Единственное, что меня по-настоящему беспокоило — это конфликты слияния. Нет в мире ничего беспомощнее и безответственнее, чем методолог, пытающийся разобраться, что такое конфликт слияния. И я знал, что скоро мы в эту дрянь попадём.

Если вы когда-нибудь пробовали в одиночку причесать чужой Word-документ, в котором двадцать комментариев на полях и три уровня правок разными цветами — вы поймёте, с чего начнётся эта история. Только умножьте на 100 авторов из 60 компаний и 120 процессов. И добавьте ноль бюджета: всё это люди делают по вечерам, потому что им не всё равно, как будет выглядеть управление ИТ в стране.

Это не туториал и не обзор инструмента. Это история о том, как я полтора года уговаривал себя, что Wiki — нормальный выбор, потом ещё полгода уговаривал команду, что пора слезать. И как после переезда на Docs as Code половина того, чего я ждал, не случилась, а половина случилась не так. И почему мне всё равно нравится, что вышло.

Прошла 22 конференция AnalystDays. Я хочу с удовлетворением отменить, что организаторам удалось собрать вау-программу с замечательными выступлениями. Во всяком случае, такими оказались многие из выступлений, которые я слушал. При этом у меня не получилось попасть на мастер-классы Димы Безуглого, Анны Обуховой, которых я знаю как крутых спикеров, и, наверняка были другие качественные выступления, на которые я не попал. Как обычно, было много интересного нетворкинга, и поэтому в отчете – всего 7 выступлений, кроме моего. И, в отличие от других недавних конференций, я практически не был на выступлениях про ИИ – не потому, что их не было, просто я выбирал альтернативы.

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

Я впервые публикую мой конспект с конференции на habr. До этого они были на моем сайте. Хочу посмотреть на реакцию и понять, насколько это уместно здесь делать, так что к читателям – просьба реагировать.

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

АО «ЗЭТА» заменило Trello и Slack на российский сервис, ускорило согласования с 3 дней до 1 часа и уже 5 лет работает без перебоев. Команда из 150 человек внедрила систему своими силами всего за 1,5 недели.

В статье — опыт компании и советы по настройке новых сервисов.

Привет, Хабр! Меня зовут Никита, я работаю в Directum Projects: консультирую заказчиков, помогаю с выбором систем при цифровизации проектной работы. Часто я сталкиваюсь с такой ситуацией: компании не могут определиться, какой класс ИСУП им выбрать — специализированную платформу или экосистему. В статье расскажу о том, чем отличаются такие решения и как найти систему, которая по максимуму закроет ваши задачи и не сломается при масштабировании.

Kodak, Nokia, Boeing — все потеряли из-за слабого критического мышления топ-команды. Что измерять, чтобы не повторить их ошибки. Данные и практика.

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

«70% кода написано с AI» звучит красиво в отчёте. Но почему это не делает продукт быстрее? Разбираем главную подмену понятий в текущем AI-хайпе.

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

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

Я видел множество попыток разработать и внедрить стратегию развития организации, но очень редко я видел, чтобы что-то действительно заработало. В стратегировании очень много проблем: от целеполагания до обеспечения ресурсами. Но самая главная и неочевидная проблема – это соответствие стратегии корпоративной культуре.

А нужна ли стратегия для успеха?

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

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

Эрик Рис написал книгу Lean Startup пятнадцать лет назад — она стала библией для поколения основателей и ее до сих пор можно найти на столе у большинства продуктовых менеджеров. "Lean Startup" учил строить успешную компанию. Новая книга Эрика "Incorruptible \\ Неподкупные: Почему хорошие компании становятся плохими и как великие компании остаются великими" учит защищать то, что вы построили.

Всем привет!

Я Мила, работаю в Positive Technologies администратором проектов экспертного центра безопасности (PT ESC). Занимаюсь организацией процессов, контролем сроков, налаживанием коммуникаций между командами и подрядчиками в кибербезе. По совместительству являюсь профессиональным художником‑традиционалистом (акрил, холст, кисти). Да, во мне прекрасно уживаются две эти сущности. 

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

За годы работы в project и product management  мне  довелось  работать  с  проектами  самых  разных типов: от государственных и образовательных инициатив до сложных IT-продуктов  и создания SaaS-платформ.

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

Waterfall и Agile уже много лет остаются двумя основными методологиями в индустрии. О них написаны сотни книг и статей. 

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

Когда Waterfall действительно работает

Традиционная Waterfall-модель  строится вокруг  последовательных  этапов:  сбор требований → проектирование → разработка → тестирование → внедрение.

Такой подход дает бизнесу несколько важных преимуществ:

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

Для технологического сектора и IT-индустрии, где цена иска часто исчисляется миллионами рублей, а предмет спора включает сложные дефиниции (архитектура ПО, недоработки ТЗ, срыв сроков интеграции ERP), понимание экономики судебного процесса критически важно. В этой статье мы без маркетинговых абстракций разберем, как формируется прайс арбитражных услуг Москва, из каких скрытых издержек складывается реальная стоимость услуг арбитражного адвоката Москва и как правильно читать смету правового защитника, чтобы не переплачивать за базовые процессуальные действия.

«Мусор на входе — мусор на выходе» работает не только с нейросетями. Пять уроков делегирования, которые промпт-инженеры выучили раньше всех

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

В статье — разбор ситуации, знакомой многим IT‑командам: дедлайны не двигаются, найм заморожен, техдолг растёт, инциденты множатся, а люди постепенно выгорают. На примере условного «ФинТеха» автор показывает, почему попытка «ускориться ещё сильнее» обычно только усугубляет кризис и как двухнедельный Stop the Line может вернуть управляемость процессам без расширения штата.

Компании массово внедряют ИИ‑агентов и сокращают штат, ожидая быстрый ROI: меньше людей, больше автоматизации, ниже расходы.

Но свежие данные Gartner показывают неудобный парадокс: увольнения сами по себе не дают отдачи от ИИ.

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

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

Всё, что нужно знать перед настройкой: токены, пакеты, конфиги, нюансы, проблемы и безопасный универсальный сетап для Claude Code CLI, Claude Desktop, Codex CLI, Gemini CLI, Antigravity, Codex, Cursor и прочего.