Прекрасная история про внедрение AI в Oracle. Причем формально — про технологии, а по существу про управление.

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

Но чу! Весной массово внедрили ChatGPT Enterprise и Codex. С корпоративными правилами, безопасностью, все как положено. За три месяца доля пользователей достигла 80%. И разработчики действительно начали быстрее писать код. По словам CIO, в отдельных случаях то, на что раньше у команды уходило два‑три квартала, теперь получается сделать примерно за неделю.

Казалось бы, вот оно, счастье…Но тут выяснилось, что написанный код надо еще протестировать, проверить, развернуть и выпустить. И все эти процессы почему‑то не ускорились вслед за программистами. Поэтому до клиента продукт существенно быстрее пока не доезжает. Раньше перед тестированием лежала небольшие кучки кода, а теперь лежат огромные, — но зато «вы только гляньте, как быстро ее насыпали!» И вот теперь Oracle переделывает и остальные процессы под новую скорость.

Потом пришел счет за AI. Оказалось, что 80% сотрудников, активно использующих модели, — это одновременно и расходы. Причем дорогую модель вполне можно увлеченно гонять на работе за счет работодателя, и неважно, что с задачей справилась бы и дешевая. И теперь сотрудникам показывают, чем именно они пользуются и сколько это стоит. После этапа «давайте уже пользуйтесь» наступил этап «а чем это вы там так пользуетесь, аккуратно там».

И вишенка — поиск уязвимостей. Oracle получила ранний доступ к модели Anthropic Mythos Preview. За две недели та нашла больше потенциальных проблем безопасности, чем компания находила за весь предыдущий год. Тут бы и радоваться, но… примерно 60–70% находок оказались ложными срабатываниями. А разбирать их поручили людям. Теперь инженер должен проверить, действительно ли тут проблема или просто ерунда. Пришлось создавать отдельный процесс проверки «находок», чтобы разработчиков не завалило этой «помощью».

В общем, история замечательная. Код производим быстрее, подозрительные места находим быстрее, деньги расходуем тоже вполне бодро. А чтобы клиент получил результат быстрее, приходится разбираться со всем устройством работы. И в итоге ускорения пока особо и нет…

Источники: Business Insider, есть пересказ тут https://thenextweb.com/news/oracle‑internal‑ai‑rollout‑town‑hall

Как не поделиться свежей историей про ответственность на проектах!.. Причем формально-то совсем не про них, зато ее можно использовать как аргумент «а вот даже у лидеров рынка еще хуже нашего»...

https://arstechnica.com/features/2026/09/the-ai-data-center-boom-is-causing-new-accountability-problems/

Кратко: в Штатах строят Lake Mariner — дата-центр за 3,2 лярда долларов. Интересанты соответствующие: Google и Anthropic.

И там бахнул пожар. Слава богу, без катастроф: никто не погиб, пожар потушили. Но зато выяснилось, насколько объект "готов" к пожару.

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

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

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

Но вот про противопожарную безопасность никто не думал. Часть гидрантов была не подключена, документации по системам тушения не было и т.д. А тут бах - и пожар. И концов нет. И нет планов действий. И некому их выполнять. Все молодцы, всё сделали в зоне своей ответственности и пошли смотреть на пожар как зрители (Ну ладно, кто-то хотя бы вызвал пожарных).

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

А вы говорите, "риски"...

Ассоциация “Проектный Альянс” выпустила книгу “Управление проектами для заинтересованных сторон (стейкхолдеров)" (В.Воропаев, Я.Гельруд, О.Клименко), посвященную стейкхолдерам проекта и тому, как собирать управление сложными проектами вокруг интересов всех ключевых игроков, а не только команды PM.

Я прочитал новинку, и вот тезисно про книгу, ее плюсы и особенности.

Плюсы:

• Нацеленность на сложные крупнобюджетные проекты, вне зависимости от сферы (не столько привычные ИТ-проекты, но и “стройки века” и производственно-добывающие проекты). Сейчас комплексных материалов в этой сфере сильно не хватает, имхо, если знаете - напишите в комментах.

• Здоровая хардкорность. Да, тут не заскучаешь над авторскими эмоциями и отступлениями. Книга на 70% состоит из математического аппарата, формул, которых "гуманитариям не понять" (с), но которые прекрасно впишутся в excel и ИСУП и помогут проекту. Авторы именно считают, а не оценивают эффективность проектного управления.

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

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

  

• Из этого складывается основа (скорее ТЗ) для интегрированной информационной системы управления проектами, которая должна собрать вместе всё: архитектуру, логику взаимодействия сторон, планы финансов/поставок/налогов, функции по всем стадиям жизненного цикла.

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

И есть особенности.

• Монографический стиль. Среди авторов - доктор технических наук, и книга ни разу не лайтовый гайд, к которым многие из нас привыкли, а солидная академическая работа с формальными постановками и алгоритмами. Листается в целом быстро, но ожидает от читателя готовности к моделям и матанализу.

• Математический аппарат - это и достоинство, и порог входа. Но, с другой стороны, есть понятные гуманитариям выводы, и если они ок, то дальше можно погружаться и в расчеты с шарящими коллегами.

• Логика “сверху вниз”, от универсальной модели проектного управления к конкретным календарям, ресурсам и т.д. Если привыкли «от Jira к стратегии», то придётся развернуть взгляд.

Резюме.
Рекомендую книгу, в первую очередь, PMO, руководителям портфелей/программ, менеджерам крупнобюджетных проектов, интеграторам и консультантам, кто “варится” в многосубъектных проектах с конфликтующими интересами.

«Введение в управление проектами внедрения ERP-систем» А. Э. Бобровников (2-е издание) - обзор книги.

Ссылка на книгу на сайте фирмы 1С.

ERP-проектов на базе 1С всё больше, так что упомянуть это свежевышедшее издание книги не будет лишним.

Автор вроде бы опытный методист, теорией не перегружает, говорит на языке бизнеса. В книге по верхам собрано всё: от оценки сроков и бюджета до управления конфликтами и рисками. Акцент сделан на практику внедрения ERP на платформе «1С:ERP».

ЦА книги - это заказчик системы. А поскольку ассоциация 1С с продуктами для регламентированного учета всё ещё актуальнее других, отдельная глава посвящена тому, чем ERP-система отличается от системы для бухучёта (и почему она такая дорогая🌚).

Дальше - про стартовый этап проекта:
про функциональные требования и их сбор, у кого и как собирать, в каком формате
про выбор подрядчика (тендер) и этапы RFI, RFP, RFQ (если кто не знал, что это)
про fit-gap-анализ (в среде 1С это зовут еще выявлением функциональных разрывов)
и об оценке IT-инфраструктуры, включая нагрузочное тестирование, и расчет окупаемости.

Сам процесс внедрения может идти по принятым подходам (PMBOK, ISO, ГОСТ 34, Agile), а может и по фирменным методикам 1С (ТБР и т.д.). Стандартная модель - каскадная: инициация → анализ → проектирование → разработка → тестирование → ввод в эксплуатацию. Акцент на важности реинжиниринга бизнес-процессов (чтобы не автоматизировать хаос).

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

Документация - тут всё очень кратко, в основном про использование бизнес-нотаций (IDEF0, BPMN, EPC) и прототипирование.

Говоря про сроки и бюджет, автор касается методов оценок (аналогия, экспертная, PERT, «сверху вниз» и «снизу вверх») и вспоминает классику - «мифический человеко-час», ошибки планирования, скрытые доработки. Отдельная глава - про управление рисками, про типовые риски (текучка кадров, ошибки ТЗ, сопротивление пользователей), управление|борьбу с ними.

По разработке и вводу в эксплуатацию - акценты на использовании нескольких контуров или баз (тестовая, рабочая и даже “грязевая” для экспериментов), и конечно же, на важности обучения пользователей и сбору обратной связи
Ну и “жизнь после смерти” - собственно, перевод проекта на стадию поддержки и сопровождения, поддержка пользователей и развитие системы.

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

Кому рекомендую: прежде всего, тем, кто готовится на роль ПМа в проектах 1С, особенно идущим на собесы, - идеальный конспект идеального внедрения (пусть его и не существует). Особенно в сочетании с одностраничными планами (приложил пример, который лично мне нравится больше других). Ну и тем, кто хочет слегка систематизировать проектный опыт.

Обзоры и дайджесты по проектному управлению - на нашем канале.

“Правила потока для управления проектами” Эфрат Ашлаг-Голдратт

Прочитал свежий перевод книги дочери Элияху Голдратта, которого вы все знаете по Теории ограничений (ТОС). И внезапно, несмотря на множество “но”, книга очень понравилась.

Кратко - это 160-стр. “бизнес-роман”, аналогичный “Цели”, “Deadline”, “Фениксу”. Сюжет - менеджер мучается с пачкой проектов, куча переделок, заказчики ругаются и грозят судами,ну и в личной жизни проблемы. Но вот на курсах находит умного профессора и единомышленников, вместе с которыми приходит к новому мировоззрению. Да, пожалуй, именно это слово тут уместно. Автор не дает “методологии” и далека от академичности, отказываясь даже от терминологии ТОС в пользу “здравого смысла”.

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

Что же ему мешает?
Незавершенка. Точнее, “мультипроектность”, много одновременно взятых командой и специалистом незавершенных проектов и задач. Многозадачность и мультизагруженность - зло. Идеал - это одна задача / один проект, на которых нужно держать фокус. Но как минимум, провести "триаж" - приоритезацию проектов и задач с результатом в виде полной (!) заморозки тех, которые менее критичны. Контролировать кол-во задач и проектов в работе (WIP-лимит). Не запускать сразу много, а запустить один-два, но зато с полной подготовкой.

Полная подготовка (full-kit) - вторая ключевая идея книги. Увы, мы принимаем как данное то, что в проектах много неопределенности, и позволяем себе не до конца собирать требования и нужную информацию. А зря. Неполнота данных, выросшая из поверхностной подготовки, - путь к 1) переделкам (“ой, а тут еще такое пожелание выявилось”) и 2) накоплению препятствий для потока.

Еще негативный фактор - дозирование. Многозадачность приводит к тому, что на выполнение задачи специалист выделяет минимально необходимое время (низкое дозирование), не вникая достаточно глубоко и широко… А это приводит к тому, что задача может скоро вернуться в переделку из-за непродуманности решения. Поэтому дозирование нужно увеличивать.

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

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

Рекомендую к прочтению менеджерам и не-менеджерам: понятно, кратко и человечно о важном на любом проекте!

Всем привет!

Встречайте https://pro-digest.ru/ - база знаний рубрики "Проектный дайджест".

Проектный дайджест существует уже пару лет и для многих стал привычным форматом) И я как автор этому очень рад 🥰

Но у формата есть ограничения, например:

• искать и делать подборки по телеге и по дайджестам на хабре/vc тяжко;

• часть материалов снимается с публикации или недоступна для каких-то регионов "по разным причинам"...

Поэтому я сделал простенький сайт (https://pro-digest.ru/), на котором любой желающий может:
а) увидеть сразу все материалы, участвовавшие в моих обзорах;
б) почитать микро-рецензии;
в) сделать подборки по ключевым словам (просто вводя текст);
г) сделать подборки по тегам (самые частые темы);
д) и даже скачать сохраненный pdf статьи (вроде работает).

Старожилы помнят, что раньше такое я делал в Notion, но, увы, работа с сервисом "усложнилась" 😒

Пока сайтик в бета-тесте: загружены статьи за последний год с чем-то (свыше 1000, и еще столько же на подходе), теги тоже размечены не везде, нагрузочные возможности непонятны etc.

В планах - сортировка, рейтинги статей и прочие приятные мелочи.

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

“Практическое руководство ИТ лидера” Раду Спатару - коротко о книге.

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

О книге:

Достоинства:
🟢Книга кратко (193 стр.) рассказывает о комплексе задач и процессов, с которыми может столкнуться IT-менеджер/лидер/директор/руководитель, от знакомства с текущим ИТ-ландшафтом в организации и до управления проектами и использования AI.
🟢Большое количество “примеров из жизни”
🟢 Много чек-листов и других инструментов самопроверки.

Недостатки:
🚫 Минималистичный объем для такого предмета - это “галопом по Европам”. Увы, ни одна из тем не получает нужного освещения, и получается “карманный справочник”, к которому вряд ли захочется вернуться. Весь текст выглядит как реферат, набор общеизвестных принципов, собранных в одном месте.
🚫 Ужасный перевод, в худших традициях “промпта”: множество опечаток и ошибок, корявый синтаксис, суконный язык.
🚫 Часть терминов, диаграмм и таблиц осталась без перевода с английского.

В целом, не рекомендую эту книгу никому - разве что вы захотите найти негативный ("как-не-надо") пример профессиональной литературы. Если тема “ИТ-менеджмента” вам интересна, лучше почитайте “Карьера Software Engineering Manager”.

Подробнее - в канале "Проектный дайджест".

“Death march” Эда Йордана: коротко о книге.

Книга написана в 1997 г., и может показаться, что автор, начавший карьеру в 1960-ые, писал про мир, совсем далекий от привычного нам IT. Но это не так.

Эта книга про высокорисковые проекты, параметры которых (бюджет, срок, команда, требования/”скоуп” и т.д.) отклоняются от нормальных на > 50%. Причем такие проекты - не какое-то исключительное, а вполне себе распространенное явление. 

Хотя в названии акцент сделан на “разработчике”, роль менеджера проекта - едва ли не главная в модели Йордана. Проджект - связующий элемент, балансир между стейкхолдерами, командой и результатом проекта.

Один из основных принципов в модели - triage, приоритезация. Спасение “безнадежного” проекта напрямую зависит от того, на чем команда сфокусируется. Это компенсирует нехватку ресурсов и лавинообразный рост требований. 

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

И раз уж высокорисковые проекты становятся нормой, разумно формировать в компании культуру работы с ними. Учиться оценивать проекты, управлять манипуляциями “акционеров”, набирать и управлять командой, которая готова к таким проектам, вводить и поддерживать инфраструктуру, которые не подведет в горячий период.

Death March - полезный и актуальный гайд по управлению “проблемными” проектами, и я рекомендую ее абсолютно всем, кто работает в ИТ.

Архив обзоров и дайджестов по проектам.

📕 Илья  Отькало.  «Автоматизация бизнес-процессов», 2024 

Кратко: добротная ознакомительная экскурсия по 1С-автоматизации предприятий

Если вы неглубоко касались внедрения 1С или подумываете над карьерой в сфере 1С в качестве аналитика, архитектора или РП, то эта книга для вас. Её целевая аудитория - те, кто знакомится с индустрией автоматизации бизнеса в России. А эту нишу в России прочно (хоть и не без конкурентов) заняла 1С.

Структурно книга делится на следующие части:

▶️ знакомство с понятием “бизнес-процессов”, с их автоматизацией, моделированием, способами и инструментами описания

▶️ виды учета, типовые и отраслевые решения 1С, подходящие для их автоматизации,

▶️ корпоративная архитектура

▶️ основы интеграции и обмена данными в решениях 1С

▶️ проекты внедрения ПО: основы проектных технологий 

😊 Плюсы:

🔹 идеальная книга для курса молодого бойца при онбординге и введении в профессию аналитиков и РП в 1С: Франчайзи

🔹дает хорошее представление о подходах  к внедрению и проектам 1С для тех, кто из другой сферы

🔹здоровая и, в целом, удачная попытка интегрировать аналитику 1С в современный IT-ландшафт

😐 Особенности:

🔹неглубокое погружение в предмет (скорее всего, не подойдет для профессионалов)

🔹немотивированные акценты на отдельно взятых инструментах и методологиях (в ущерб другим)

🔹недостаток примеров артефактов и документации (можно было бы вынести их в приложение или комплект для скачивания)

Более подробный обзор - в "Проектном дайджесте".

“Проектное управление. Как правильно делать правильные вещи” - тезисно о новой книге Павла Алферова.

Плюсы:

⭕Небольшая (400 страниц, втч около 50 - приложения). Читается легко, быстро, никакой сложной для восприятия информации нет.

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

⭕Много практических примеров, изложенных очень понятным языком.Изложение понятно и логично структурировано.

⭕Подход позиционируется как универсальный, применимый в ИТ, стройке, инфраструктуре и даже (!) создании новых продуктов.

Особенности:

🔘Раскрыта только одна методология управления проектом, и она принадлежит автору. Это “Российская инструментальная трехуровневая модель управления
проектами”, или РИМ-III. В его основе - "Пентабазис" (5 ключевых вопросов, которые нужно проработать при реализации проекта - “Зачем и для кого”, “Что”, “Как”, “Кто”, “Чем”).

🔘Деятельность руководителя проектов формирует “проектный Ромб”: он должен правильно проработать проект, правильно приживить проект, правильно думать о проекте, правильно делать проект.

🔘Книга подчеркнуто обращается к “российскому” управлению проектами.

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

Подробный отзыв - в канале Проектный дайджест.

Практика оргпроектирования (организационный дизайн) - коротко о курсе

Образовательные курсы Никиты Сергеева импонируют своей содержательностью, высокой детализированностью, демократичным стилем изложения и стоимостью. Уже делился впечатлениями от курса по PMBOK 7 - великолепный материал.

В конце 2023 г. Никита выпустил новый курс - по организационному дизайну: про то, как моделировать и корректировать организационную структуру компании - структура, подразделения, отделы, функции и т.д.
Курс небольшой (~5-6 часов), в нем много дополнительных материалов и очень много практической работы по моделированию организационной структуры компаний и корпораций.

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

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

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

Прочитал книгу "Шум. Несовершенство человеческих суждений" Канемана, Сибони, Санстейна (вроде спин-оффа к "Думай медленно, решай быстро"), посвященную теме нежелательной вариативности экспертных суждений.

Местами книга требует вникать в мат. статистику и немного экзотические предметные области, но in nuce она довольно простая: есть феномен "шума", когда по одному вопросу разные эксперты (или даже один и тот же) высказывают разные суждения, дают сильно дифференцирующие прогнозы.

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

Цель - добиться как можно большей точности и соответствия статистическим данным (а не обманчивому сторителлингу), исключить "интуитивные" допущения, которые могут быть вызваны как объективной неосведомленностью, так и предвзятостью эксперта ("встал не с той ноги") или его излишней харизматичностью.

Помимо общих "ментальных" рекомендаций ("гигиена шума" - что-то вроде само) есть и методички - по ревизии шума в команде, чек-лист проверки эксперта на подверженность шуму и т.д.

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