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

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

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

Сегодня я проверю, можно ли с помощью MWS Tables полностью синхронизировать форму заявок, таблицу их хранения/контроля и таск-трекер в едином сервисе (спойлер: можно). 

Так закончился очередной разговор о возвращении к управлению разработкой. Большинство откликов заканчиваются раньше — игнором или шаблонным отказом.

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

Каждый следующий опыт делал меня как менеджера сильнее. Заодно делал мой управленческий опыт всё менее «актуальным» — по крайней мере, для тех, кто читает резюме.

После внедрения трех проектных офисов, смысловая нагрузка одного из принципов управления от PMI - синергия, для меня, обрела еще более прикладной формат. Далее пойдет моя трактовка, с ориентиром на практики и стандарты от PMI: PMO: Практическое руководство и стандарты управления проектом\программой\портфелем.

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

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

Меня часто спрашивают:

— Почему к вам, а не к гигантам?

Ответ простой:

— Мы не охреневшие.

Сначала я хотел рассказать про нашу сеть хранения, которая быстрее, чем скорость записи на RAID 0, про удивительное конкурентное преимущество «Трезвая поддержка», про 400G-линки на каждом хосте, про изоляцию сетей и топологию Dragonfly+ с full mesh на уровне зон доступности. Но всё-таки я решил: самое главное, что мы не охреневшие.

Это главная штука, которую мы решили для себя со старта.

А теперь расскажу, что же мы последовательно делали и что запускаем.

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

Привет, жители Хабра! Я Ольга Жучкова, один из главных администраторов данных MWS. Я отвечаю за внедрение практик DG в кластере и выступаю амбассадором направления: помогаю продуктовым командам внедрять практики работы с данными и показываю, как эта работа улучшает продукт. В моем кластере работают более тысячи сотрудников. В каждом из этих продуктов, где есть БД, хранятся уникальные или критичные данные. А значит, есть свой администратор данных продукта, с которым я взаимодействую. На примере МТС Premium расскажу, как мы выстроили систему проверок качества распределенных данных — от локальных ошибок в базе до сквозных процессов и бизнес-метрик.

23 сентября 1999 года аппарат NASA Mars Climate Orbiter подошёл к Марсу после девяти месяцев полёта, вошёл в атмосферу слишком низко и разрушился.

Комиссия по расследованию назвала причину: в одном из наземных программных файлов не использовались метрические единицы. Одна программа выдавала данные об импульсе двигателей в фунт-секундах, а принимающая её навигационная система ожидала ньютон-секунды. Расхождение в 4,45 раза – ровно во столько раз недооценили влияние работы двигателей на траекторию. Этого хватило, чтобы аппарат пошёл не по той траектории.

Самое важное в этой истории: никто не ошибся в расчётах. Обе команды считали правильно. Просто каждая – в своих единицах.

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

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

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

Основное, что сейчас с рынком:
— У многих коллег по рынку моментально и некисло выросли ценники
— Мы не планируем повышать цены из-за текущей ситуации всвязи с повышенным спросом
— Мы вывезли почти всё оборудование из IXcellerate (крупные ЦОДы) и разместили на своих площадках
— Площадки снаружи не выглядят как ЦОД, инфраструктура внутри распределена шире, чем в обычном машзале
— Многие намеренно раскидывают оборудование на десяток разных площадок по чуть-чуть, возрождают старые серверны и админов в свитерах.
— Все переписывают Disaster Recovery-планы, потому что такого ещё не было, и главная проблема уже не в экскаваторах.

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

Теперь подробнее.

Привет, Хабр! Меня зовут Георгий, руковожу продажами и маркетингом в Аспро.Cloud. За плечами больше пятнадцати лет в B2B-продажах — TELE2, Samsung, Whirlpool, команды до полусотни человек.

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

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

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

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

Генерацию гипотез ускорили, а проверка осталась такой же, как в 2020-м. Попробуй скажи вслух «давайте сначала проверим» — станешь тормозом, человеком из прошлого, луддитом.

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

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

Искусственный интеллект обещал изменить мировую экономику. Но пока компании рассказывают о революции производительности, инвесторы начинают задавать значительно более приземлённый вопрос:

Кто заплатит за сотни миллиардов долларов, уже потраченных на эту революцию? История Oracle показывает, что проблема может возникнуть задолго до того, как закончится спрос на ИИ.

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

Более двух с половиной миллионов квадратных метров в год — под тотальным цифровым контролем. Не выборочные замеры и не акты «на глазок», а лазерное сканирование с миллиметровой точностью. Setl Group прошла этот путь за шесть лет: от первого в России наземного сканера Leica до собственной системы строительного контроля, которая сегодня встроена в каждый этап стройки. О том, как технология превратилась из эксперимента в конкурентное преимущество, — из первых рук.

Риски, которые «съедают» бюджет застройщика

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

Риски, которые несёт застройщик:

Задержки сроков и вопросы к качеству...

Привет! Кажется, что не так давно мы впервые рассказывали о нашей работе с платформой BPMSoft в департаменте корпоративных систем ЛАНИТ, где я выполняю задачи аналитика. Но год прошел, календарь перевернут и пришло время добавить новые главы к описанию нашего взаимодействия с этой low-code системой.

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

до форума «СИЛА ПЛАТФОРМЫ» осталось 4 дня!

15 октября 2026 года в Москве (кластер «Ломоносов») и в онлайн-формате пройдет масштабный форум о цифровизации, российском инженерном ПО и технологиях искусственного интеллекта в строительстве. Будут представлены десятки кейсов от ведущих проектных организаций страны и прикладные сценарии применения ИИ. Состоится стратегический диалог о будущем инженерного образования — участие в дискуссии примут представители Министерства цифрового развития, связи и массовых коммуникаций, Министерства транспорта, Министерства науки и высшего образования и Комитета Совета Федерации по экономической политике.

Есть профессии, ценность которых определяется не только тем, что человек умеет делать, но и тем, насколько редким остается ресурс, которым он управляет.

В IT таким ресурсом много лет была разработка. Хороших инженеров не хватало, бэклог почти всегда был длиннее возможностей команды, а любое заметное изменение продукта стоило времени и денег. Поэтому вместе с хорошей идеей возникал вопрос: хватит ли у разработки людей, времени и бюджета?

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

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

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

Что же изменилось на самом деле?

Самое простое объяснение обычно звучит так: AI теперь пишет код вместо людей.

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

Меняется другое. Само производство кода ускоряется, а весь путь от идеи до работающего продукта сокращается куда медленнее.

JetBrains весной 2026 года сформулировала это довольно приземленно: генерация кода становится дешевой и перестает быть главным бутылочным горлышком. Главная сложность смещается к вопросу, соответствует ли результат замыслу, и сколько вся система в итоге стоит.

От вечно «почти готового» проекта и поиска идеальной РРМ до правил реагирования на правки и «ленивого» саппорта — всё самое интересное, что писали за последнюю неделю про управление проектами. Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!

Если спросить тимлида «сколько story points команда сделает в следующем спринте?», чаще всего ответ будет такой: «Ну, в прошлый раз было около 300, давай возьмём столько же». Потом выясняется, что двое уходят в отпуск, один новичок ещё не разогнался, а треть времени съедят баги. Спринт заканчивается авралом, задачи доделывают в последние два дня, и этот аврал попадает в статистику как «нормальная скорость команды». Следующий план строится уже на нём.

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