Менеджмент

Привет, Хабр! На связи Наталья Воронько из РТЛабс. Я RTE Аналитической Платформы и ЕЛК, а в прошлом — руководитель проектов и функциональный руководитель. Сегодня хочу поделиться своим взглядом на новую редакцию PMBOK® Guide от Project Management Institute (PMI).

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

Официального русского перевода PMBOK® Guide 8^th edition у меня нет. Я читала английскую версию, поэтому некоторые термины могут отличаться от будущего официального перевода. Для точности буду указывать в скобках оригинальные названия и термины.

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

Привет! Меня зовут Евгений, я работаю в БКС Мир инвестиций владельцем сервиса «Портфель».

Если объяснять просто, «Портфель» — это раздел, где клиент смотрит свои активы: деньги, ценные бумаги, валюту, фонды, облигации, фьючерсы, финансовый результат и общую картину по инвестициям.

Для клиента это обычный экран в приложении или личном кабинете. Открыл, посмотрел, что происходит с деньгами, принял какое‑то решение.

Но внутри компании за этим экраном стоит много всего. Backend‑сервисы, frontend, интеграции, биржевые данные, банковские продукты, сетевой путь, мониторинги, SLA, обращения клиентов в контактный центр, поддержка, аналитика, релизы и ожидания бизнеса.

На стыке всего этого и появляется роль Service Owner.

Под моей прошлой статьей про КТЗ – коэффициент токсичности задачи (вот она) – был комментарий, на который я сначала не обратил особого внимания. Смысл такой: все, что вы описываете – это результат некачественной работы аналитика и руководителя. Их работу свалили на программиста и назвали методом.

Неприятнее всего, что человек прав. Фиксируй договоренности, проверяй готовность задачи, не отменяй проработку требований, возвращай сырое заказчику – это азбука ремесла. Этому учат на любом курсе по управлению. Любой аналитик с опытом прочитает и скажет: спасибо, кэп.

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

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

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

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

Эта статья — для собственника или руководителя компании (в том числе ИТ), который доверил ведение учета штатному главбуху или подрядчику на аутсорсинге и хочет понимать, что там происходит. Знаний бухгалтерии для этого не нужно. Нужно знать, куда смотреть и какие три экрана открыть, чтобы оценить работу бухгалтера и состояние финансов компании. Разберем по порядку: почему за учет отвечаете вы, с чего начать, как за пятнадцать минут проверить работу главбуха, какие звоночки нельзя пропускать, что считать нормой, как бухгалтер может воровать, за что вы по Кодексу не отвечаете и что делать при сомнениях.

EAM — это цифровая нервная система производства: она связывает гайку в цеху с бухгалтерским балансом. Ещё несколько лет назад этот рынок в России держали SAP, IBM Maximo и Infor EAM — на них строились процессы крупнейших заводов и энергохолдингов. Когда вендоры ушли, выяснилось, что «просто заменить» такую систему невозможно.

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

Пользователи облачных версий — Jira Cloud, Confluence Cloud, Trello — получили уведомления об отключении аккаунтов ещё в августе 2023 года. Серверные инсталляции оказались в другом положении: систему снаружи не заблокируешь, но глобальная поддержка Server-продуктов прекратилась 15 февраля 2024 года — система осталась без обновлений, патчей безопасности и технической помощи. Часть компаний успела зафиксировать лицензию до дедлайна и продолжила работать именно в таком режиме. Другие перешли на серые ключи — физически встречались с людьми, которые передавали активационные коды, лишь бы не останавливать сотни проектов в Jira. Ещё часть просто перестала платить и работает как есть.

Отдельную группу давления создаёт глобальный EOL для Data Center: с марта 2026 года Atlassian прекратил продажу новых лицензий Data Center, в 2028 году закроет продление существующих, а полная поддержка завершится в 2029-м. Для российских компаний, которые после ухода вендора перешли именно на Data Center как на «безопасную» замену Server, это означает, что мигрировать всё таки придётся.

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

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

У разработчиков есть крепкое убеждение: стать тимлидом значит навсегда потеряться в созвонах, потерять хард-скилы и оказаться в ловушке из которой не выбраться. В конце 2024 года на Хабре набрала больше 200 плюсов статья с говорящим названием «Не надо быть тимлидом». Она начала просачиваться в чатики, каналы и умы людей. И закрепила страх: тимлидство карьерный тупик.

Евгений Антонов, ведущий технический менеджер в Yandex Infrastructure и автор телеграм-канала «Тимлид Очевидность», с этим категорически не согласен. 18 лет в IT, последние 10 в менеджменте, плюс 5 лет консалтинга с десятками тимлидов в клиентах. Достаточно, чтобы смотреть на карьерные страхи без паники. Доклад на Saint TeamLead Conf 2025 в Петербурге он посвятил разбору этого популярного тезиса.

Спойлер: тимлид это не тупик. Это развилка.

Почему пустяковая строчка способна занять весь вечер — и чем она отличается от тяжёлого, но понятного разговора

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

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

Легко решить, что дело в тревоге или в неопределённости вообще. Но неопределённости вокруг сколько угодно, и почти вся она нас так не удерживает, не мучает. Я не знаю, какая завтра будет погода, чем закончится сериал, сколько простою в пробке по дороге домой, — и спокойно живу с этим незнанием. Значит, дело не в самой по себе неизвестности. Что-то отличает эти несколько строчек от обычного незнания, с которым мы уживаемся без труда.

Готовы рискнуть вашими... проектами?

Привет, Хабр! Я Лена, аналитик Directum Projects. Риск — не мое второе имя, но в работе мне приходится сталкиваться с ним каждый день. Чего еще я хотела на ИТ-проектах :) Главное здесь — грамотный менеджмент, чтобы процесс не превратился в вождение на велосипеде без тормозов: едет быстро, падает громко.

И вот, когда мы в очередной раз летим с обрыва с оптимистичной записью «Проблем на проекте не предвидится», нам предлагают парашют — ГОСТ Р 72160-2025. Это первый в России стандарт, который на государственном уровне закрепляет количественный подход к управлению рисками.

О том, как система управления проектами поможет соответствовать новому стандарту и что делать, если риски проекта — это все еще три строки в Excel, поговорим в статье.

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

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

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

В 2019 году антрополог Madeleine Clare Elish из Data & Society взяла эту метафору и вывернула её наизнанку. Она ввела термин «moral crumple zone»: человек в сложной автоматизированной системе может стать таким же компонентом-поглотителем — только в отличие от автомобиля, здесь сминаемая зона защищает не человека, а систему. Ценой человека.

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

Sonar опросил 1100+ разработчиков в январе 2026-го. Результат: 96% не уверены в функциональной корректности кода, который написал AI. Но вот в чём штука — проверяют его перед каждым коммитом меньше половины. AWS CTO Вернер Фогельс назвал это «verification debt»: AI ускоряет написание кода и одновременно замедляет его понимание, потому что генерировать стало проще, чем разбираться, что именно нагенерировали.

Один из участников свежего исследования (Baltes et al., март 2026) сформулировал это без дипломатии: «они буквально используют тебя, чтобы ты критически оценил их AI-слоп и дал ему следующий промпт».

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

Меня зовут Александр Козуб, в симптомах вижу систему, об этом и пишу. Ранее я уже разбирал, как лучшие практики сужают рамку продакта, и собирал методики оценки пользователя в одну систему. Сегодня про метрики.

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

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

Опытные разработчики с ИИ‑ассистентом нередко работают медленнее, а не быстрее. В рандомизированном эксперименте METR (июль 2025) опытные разработчики выполняли реальные задачи на 19% дольше с ИИ — и при этом были уверены, что ускорились примерно на 20%. Разрыв между ощущением и фактом — около 40 пунктов.

Это не значит, что ИИ бесполезен. Это значит, что выгода не появляется сама по себе от факта покупки инструмента. Данные по компаниям говорят о том же: в отчёте MIT (Project NANDA, «The GenAI Divide», июль 2025) при 30–40 млрд долларов вложений около 95% компаний не получили измеримой отдачи. Авторы связывают это не с моделями, а с разрывом в освоении — между «инструмент купили» и «процессы перестроили».

По моему опыту работы с командами картина повторяется: лицензии Copilot, Cursor, DeepSeek, Qwen раздают, а дальше каждый разбирается сам. Ниже — что при этом ломается и что с этим делать на уровне процесса, а не лозунгов.

Когда у вас в компании 50 ИТ-активов, таблица Excel с выпадающими списками, условным форматированием и парой макросов для автоматического подсчета вполне справляется с учетом. Но если их 500+ и они распределены по 10 филиалам, Excel превращается из инструмента контроля в генератор хаоса. В этой статье я разберу подводные камни управления ИТ-активами в табличных редакторах: от мутации данных до невозможности отследить реальную конфигурацию виртуальных машин.

Я задумал амбициозный проект, который, уверен, решит проблему взаимодействия клиентов с разработчиками, — систему управления проектами «Черный ящик» для веб-студий и разработчиков.

Суть идеи кратко: Это онлайн-система с задачами и встроенным чатом под каждый проект. Мы уходим от зоопарка из Trello, Telegram и Google Диска. Всё в одном месте. Представители заказчика приглашаются в проект бесплатно, разработчики — как свои, так и внешние — подключаются под конкретные задачи.

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

Пятница, 17:40

В серверной мигает amber LED на втором юните стойки. Мониторинг молчит — сервер вывели из наблюдения три месяца назад. Бухгалтерия считает его рабочим активом стоимостью 480 тысяч рублей. Склад уверен, что его списали в прошлом квартале. А инженер, который единственный знал, что на нём крутится внутренний DNS для трёх филиалов, уволился в марте. Если узнали свою компанию — добро пожаловать в реальность учёта ИТ-активов, где техническая правда и бухгалтерская годами живут в параллельных вселенных.

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

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

В ИТ намного важнее компетентность людей, чем наличие дцатого регламента. С работы над компетентностью и стоит начинать.

Об этом сегодня и поговорим 🙂