😨 Не скрамом единым: 10 нетривиальных концепций управления проектом
Серия постов - 1 /5 .
Лайк, коммент, репост, если такой контент норм 😛.

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

Погнали.

1. Возможно, вам вообще не нужен проект: переход от проектов к продуктам (Project to Product)
Начнём с неприличного вопроса: а зачем нам (организации) нужен проект?
Допустим, компания развивает личный кабинет клиента. Сначала появляется «Проект внедрения личного кабинета», через год — «Проект модернизации», потом — «Проект мобильной версии», затем — «Интеграция с CRM», а ещё через какое-то время, конечно, «Личный кабинет 2.0» - типа он повзрослел и возмужал... С точки зрения компании за это время прошло пять проектов, а с точки зрения клиента все эти годы существовал, собственно, один и тот же личный кабинет.
Отсюда и выросла концепция перехода от проектов к продуктам: если работа по своей природе не заканчивается, то, возможно, незачем каждые полгода изображать, что она закончилась. Вместо временной команды, которую собирают под конкретный проект, можно иметь постоянную команду, отвечающую за продукт, часть бизнес-процесса или конкретную ценность, а уже внутри этой постоянной ответственности запускать отдельные инициативы.
Сама идея не новая, её довольно последовательно развивал Мик Керстен в книге «От проекта к продукту» (см ссылку), но сейчас она обсуждается уже как полноценная модель финансирования и управления постоянными командами.
Никто не предлагает отменить проекты вообще. Но если мы восьмой год подряд запускаем «проект развития корпоративного портала», возможно, дело не том, что у нас просто есть портал, который надо постоянно развивать.
Вот и получается, что одна из задач зрелого проектного управления - это вовремя понять, что новый проект вообще не нужен))

2. Хорошая организация должна чаще закрывать проекты: парадокс отмены (Cancellation Paradox)
С начатыми проектами есть один косяк: они очень хотят жить и требуют ресурсы, причём иногда заметно сильнее, чем этого заслуживают.
Представим, что год назад компания решила сделать новую систему, выделила деньги, назначила руководителя, собрала команду, провела стартовое совещание, нарисовала (и даже не в чатгпт, а руками) презентацию и нашла человека, который сходил к генеральному и убедил его, что “без этой системы компания потеряет конкурентоспособность к следующему вторнику”. И вот восемь месяцев спустя выясняется, что система уже не очень нужна: изменился процесс, ушёл ключевой клиент, появился другой продукт, поменялось законодательство… 
Приходит здравый смысл и говорит, что проект надо закрывать. Но тут возникает классическое «мы уже столько вложили, вы чего, э…».
В исследовании Tempo за 2026 год (ссылка выше) пишут про “парадокс отмены”: организации, которые чаще пересматривают приоритеты, заметно чаще закрывают проекты и при этом получают большую долю проектов, которые действительно создают измеримую ценность. Закрытие не обязательно означает, что проект был плохим с самого начала или кто-то всё сделал неправильно; проект мог быть абсолютно разумным год назад, просто мир поменялся, а организация почему-то решила, что после запуска сдавать назад уже неприлично.
Отсюда и идея считать не только долю проектов, успешно доведённых до конца, но и, например, сколько денег компания не потратила, потому что вовремя остановилась. Кстати, заметьте этот тренд в нынешнем медиабизнесе - сколько игр и фильмов отменяются на полпути, а иногда и незадолго до релиза. Как ни странно, это не психопаты у руля, а вот те, кто осознал идею отмены.

😨 Не скрамом единым: 10 нетривиальных концепций управления проектом
Серия постов - 2 /5 .
Лайк, коммент, репост, если такой контент норм 😛.

3. Чтобы лучше прогнозировать сроки, иногда полезно перестать их оценивать: управление без оценок (#NoEstimates)
Статья про подход
Если дождаться созвона с гендиром (или кто у нас главный) и заявить: "Мы решили больше не оценивать сроки", - то после этого разговор, скорее всего, быстро закончится, а у вас как РП появится свободное время для поиска новой работы (наверное).

Концепция “управления без оценок” предлагает различать две вещи, которые мы очень часто смешиваем: оценку и прогноз. Допустим, у команды есть 50 относительно небольших задач. Можно собрать людей и начать выяснять, сколько займет каждая: эта - четыре часа, эта - восемь, эта - двенадцать, хотя похожая в прошлый раз была шесть, но тут интеграция сложнее, а там разраб уже знает код. Через несколько часов у нас появляется таблица с числами, которая выглядит очень научно и вызывает ощущение контроля.

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

Тогда вместо фразы “закончим 19 ноября” можно сказать "с вероятностью 85% закончим до 28 октября". Первое звучит точнее потому, что там одна конкретная дата, но сама эта точность может быть чисто… декоративной. Мы же знаем, что если взятую с потолка хрень написать с двумя знаками после запятой, она внезапно начинает выглядеть гораздо убедительнее.

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

4. Не спрашивайте, сколько времени займет работа. Спросите, сколько времени она заслуживает: фиксированное время и изменяемый объем (Fixed Time, Variable Scope) из Shape Up
Публикация Basecamp (недоступна в рунете)

Эта концепция меняет местами привычный разговор между бизнесом и командой. Обычно все начинается, естественно, с требований. Заказчик приносит список, потом вспоминает еще десять вещей, через день кто-то добавляет мобильную версию / блокчейн / ИИ-фичу, через неделю появляется обязательная выгрузка в эксель, а еще через две недели становится известно, что все это желательно закончить примерно вчера. После этого разработчиков спрашивают, сколько времени займет реализация, разработчики называют неприятную (с кучей буферов) цифру, все расстраиваются и начинается обсуждение того, почему команда снова "завышает оценки".

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

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

Поэтому жадничаем со временем - оно важнее и ценнее, пусть реализация подстраивается под это фундаментальное ограничение, а не наоборот.

Не скрамом единым: 10 нетривиальных концепций управления проектом
Серия постов - 3 /5 .
Лайк, коммент, репост, если такой контент норм 😛.

5. Чтобы закончить быстрее, иногда нужно позже начать: нулевая стадия проекта (Stage Zero), или "замедлиться, чтобы ускориться" (Slow Down to Speed Up)
Фраза "мы быстро запустили проект" звучит ок, а "мы три месяца выясняли, что не надо было его запускать" - уже не ок, хотя второй вариант сэкономил бы N месяцев работы и неплохой бюджетик.

House of PMO в прогнозе на 2026 год (по ссылке выше) называет одним из трендов "нулевую стадию проекта", то есть сознательную работу до официального старта. При этом важно не перепутать эту идею с привычной бюрократией, когда можно три месяца писать концепцию, потом четыре месяца согласовывать концепцию концепции, а затем создать рабочую группу по выбору даты следующего совещания.

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

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

6. Чем больше контроля, тем иногда меньше управляемость: минимально достаточное управление (Minimum Viable Governance)
У корпоративных процедур есть прекрасный естественный механизм размножения. Что-то пошло не так - добавили согласование. Через год случилась другая проблема - добавили еще одно. Потом появился чек-лист, потом человек, который проверяет чек-лист, затем таблица, подтверждающая факт проверки чек-листа, и в какой-то момент простое изменение начинает проходить согласование дольше, чем строился Колизей. При этом никто специально не ставил задачу построить бюрократический ад в отдельно взятом Газмяспроекте 😐. Наоборот, каждое отдельное правило когда-то выглядело вполне разумно и решало конкретную проблему, - ну просто никто потом не пришел и на голубом глазу не спросил, нужна ли эта защита до сих пор.
MIT CISR в 2026 году предложил термин "минимально достаточное управление". Изначально речь шла о генеративном ИИ, но сама логика отлично переносится на проекты: есть нижняя граница контроля, ниже которой начинается бардак и неприемлемый риск, но есть и верхняя, после которой дополнительный контроль уже не столько защищает, сколько создает новую проблему - организация перестает успевать что-либо делать.

Отсюда следует довольно полезный вопрос для любого регламента: "Что конкретно случится, если это согласование убрать прямо вот сейчас?" И возможно, проектный офис должен иногда не создавать очередной процесс, а брать старые процессы и аккуратно выносить их на помойку. Это, в общем-то, тоже управление, просто выглядит не так торжественно и ритуально и хуже подходит для презентации на 40 слайдов.

Не скрамом единым: 10 нетривиальных концепций управления проектом
Серия постов - 4 /5 .
Лайк, коммент, репост, если такой контент норм 😕.

7. Главным тормозом проекта могут быть не исполнители, а руководство: задержка принятия решений (Decision Latency)
А эта идея вообще довольно болезненная, потому что мы привыкли измерять скорость исполнения гораздо охотнее, чем скорость руководства.
Допустим, разработчик выполняет задачу пять дней. Руководитель считает, что это медленно, наезжает и начинает говорить про производительность, эффективность и оптимизацию, в итоге срок удается сократить до четырех дней, и все чувствуют, что поработали не зря.
После этого разработчик задает вопрос руководству и шесть дней ждет ответа. Но почему-то эти шесть дней производительностью уже не считаются.

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

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

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

8. Проект должен не выдерживать неприятности, а получать от них пользу: концепция антихрупкости сложных проектов (Antifragility Hierarchy)
Антихрупкость, как все знают, придумал Нассим Талеб, но в конце 2024 года появилась работа Грега Ашера, Шанталь Кантарелли, Кейт Дэвис, Джеффри Пинто и Нила Тернера именно об антихрупкости сложных проектов (и, кстати, еще раньше - Саша Бындю).

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

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

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

Не скрамом единым: 10 нетривиальных концепций управления проектом
Серия постов - 5 /5 .
Лайк, коммент, репост, если такой контент был норм 👍.

9. План нужно строить не из настоящего в будущее, а из будущего в настоящее: теория действия проекта (Action Theory of the Project)

В 2024 году Грэм Уинч опубликовал работу "Теория действия проекта", где среди прочего развивается идея мышления из завершенного будущего. Мы обычно начинаем планирование с сегодняшнего дня: вот что у нас есть сейчас, вот что надо сделать дальше, потом еще один шаг, затем еще один, и так постепенно… PROFIT.

А можно двигаться в обратную сторону и сначала представить, что желаемое будущее уже наступило. Например: "Через год менеджер видит всю историю работы с клиентом в одном месте, не ведет таблички в экселе и готовит предложение за десять минут".

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

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

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

10. Опытному руководителю проекта иногда нужно учиться забывать: проектное разучивание (Project-Based Unlearning)

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

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

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

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

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

💥Самые интересные статьи про управление проектами за 2 недели. Часть 1.

😷 Чему меня научило управление платформой, которая распределяет 90 000 встреч в день
Лонг Т-Банка о том, что происходит с управлением, когда команда вырастает из двадцати человек в сотню с лишним. Пока людей немного, руководитель действительно может держать почти всю систему в голове и лично разруливать основные вопросы. Дальше эта модель закономерно ломается: изменения одной команды внезапно задевают другую, решения дублируются, а менеджер постепенно превращается в главное узкое место. Поэтому пришлось разделить зоны ответственности, назначить владельцев частей системы и сделать так, чтобы большинство решений вообще не требовало подъема наверх. В целом, главным источником сложности оказались не технологии, а зависимости между четырьмя командами, тринадцатью системами-потребителями и кучей связанных процессов. 

😐 Стоит ли писать ТЗ на разработку в 2026 году и зачем
Автор спорит с тезисом "мы работаем гибко, поэтому ТЗ нам не нужно". Но, слава богу, воскресить трехсотстраничный документ по ГОСТу он тоже не предлагает. Предлагает “минимальный общий образ результата”: термины, роли, основные сценарии, границы первой версии, связи с другими системами, ограничения и критерии приемки. А дальше требования вполне можно уточнять по ходу работы. В целом, норм, потому что гибкость хоть и отменяет попытку заранее описать вообще весь проект, но отнюдь не отменяет необходимость договориться, что именно мы собираемся строить.

😰 Вы выбираете не решение. Вы выбираете его будущие проблемы
Ситуация: нашли несколько норм вариантов для проекта, - и как выбрать правильный? У каждого своя цена, ограничения и будущие проблемы. Автор предлагает сравнивать не только стоимость и сроки внедрения, но и дальнейшее сопровождение, обратимость решения, организационные изменения и последствия возможного отказа от него. Из важных тезисов: 1) таблицы с баллами - да, они полезны, пока помогают увидеть различия, но потом становятся вредны, ибо позволяют сказать "ну вот таблица и выбрала". 2) проблема с разделением ответственности: специалисты должны показать варианты и рекомендовать, а решение должны принимать те, кому потом жить с ним и платить за них. 3) пока крупное решение не принято, не обязательно останавливать весь проект; достаточно не делать работу, которая необратимо заталкивает его в один из вариантов.

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

🧣 Первый опыт управления IT-командой: три вывода, которые я сделал
Короткая заметка начинающего руководителя, - и всё по делу). 1) Сообщение в переписке еще не задача: нужно зафиксировать, зачем что-то делаем, что должен получить пользователь и по каким признакам примем результат. 2) Задержка тоже не обязательно находится внутри команды — иногда разработчик уперся в решение другого подразделения, и руководитель нужен именно затем, чтобы эту зависимость разрулить, а не требовать "сделать быстрее". 3) Ну и технически завершенная работа еще не означает готового результата: отдельные части могут работать, а полный сценарий — нет. 

😈 Как за 5 минут аннигилировать завод
Внезапно очень “проектная” история техногенной аварии. На заводе одновременно сошлись сокращение опытных сотрудников (хе-хе), экономия на обслуживании оборудования, увеличенная партия продукции, неопытный химик, отсутствие тренировок и аварийная процедура. По отдельности пофиг, система бы устояла, но тут последовательно отказали вообще все защитные слои. При этом способ остановить реакцию был известен, но он означал потерю продукции и поэтому требовал согласования с гендиром. Пока согласовывали, время ушло. И всё, конец…

🔥 10 самых интересных публикаций по управлению проектами за 5–19 сентября (I)

😭 Когда ведущий аналитик превратился в мини-РП: признаки перегруза и как вернуть роль в норму
Про ловушку сильного онолитега, которая начинается знакомо и невинно. Аналитик лучше всех знает проект — ну пусть заодно уточнит срок. Всё равно идет на встречу — пусть соберет состояние задач. Знает, где зависло согласование, — пусть проконтролирует. Через несколько месяцев именно к нему все ходят за состоянием проекта, он отвечает за сроки, которыми напрямую не управляет, а собственные требования дописывает вечером. Причем снаружи это легко принять за рост и доверие: человеку ведь поручают всё больше важного. Но стоп, а если завтра аналитик перестанет собирать состояния работ, напоминать о сроках и координировать людей, кто вообще должен этим заниматься? И если ответ — руководитель проекта, то где-то незаметно расползлись границы ролей.

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

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

🤫 От хаоса к системе: насколько реально построить AI-first команду за полгода
Кейс Cloud.ru о том, как заставить 300 с лишним человек не просто потыкаться в  ИИ, а прям встроить его в работу. Начали с замера: кто уже применяет ИИ, кто не применяет и почему. Потом собрали больше 40 идей, выбрали восемь проектов, организовали обучение на собственных задачах и через полгода снова всё измерили. По их данным, доля использующих ИИ выросла с 72 до 84%. И если главным препятствием сначала было незнание, то через полгода — уже нехватка времени.

👍 Как выбрать информационную систему управления проектами: возможный методологический подход
Большой разбор того, почему выбирать систему управления проектами с вопроса «а сколько стоит лицензия?» - фигово. Автор предлагает сначала разобраться, чем именно организация собирается этой системой управлять: отдельными задачами, проектами, программами или целым портфелем; какие уже существуют процессы, уровни управления, ограничения безопасности и требования к данным. Потому что система в итоге просто цифровым способом воспроизводит принятую модель управления. Если та противоречива, автоматизация сделает противоречия не меньше, а заметнее и дороже (см поговорку про "автоматизированный бардак")

😉Прекрасная история про внедрение 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

#Внезапное

🔥 10 самых интересных публикаций по управлению проектами за 5–19 сентября (II)

😐 Давайте сначала сделаем один завод
Авторам дали на автоматизацию группу промпредприятий. Логично было идти последовательно - автоматизировать, условно, закупки сначала на одном заводе, потом распространить на остальные. Но выяснилось, что процессы четырех предприятий совпадают всего примерно на 40–60%, и первый завод совершенно не является уменьшенной копией остальных. Получается ловушка с крупной переделкой “готового” решения. Поэтому команда сначала исследовала все четыре предприятия и отделила общее ядро от обязательных различий и местной специфики. И уже после этого начала автоматизацию. 

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

⚡️ Заменили Jira, Slack, Tilda и Confluence своим кодом ради экономии. Экономии не вышло
Компания решила сэкономить на четырех платных системах, написала собственные — и через год посчитала результат. В первый год получилось примерно минус 2 млн руб, а выйти в ноль автор рассчитывает только примерно за три года, если стоимость поддержки не вырастет. Такая вот экономия. Собственную систему нужно не только создать, но и поддерживать, проверять изменения, документировать и держать в голове как еще один свой продукт. Зато вторая цель — возможность быстро менять инструменты под собственный процесс — действительно оказалась полезной. В общем, считать нужно не стоимость создания, а полную цену владения плюс работу, которую команда могла бы в это время делать для клиентов.

✝️ Внутренние стандарты работы аналитиков: какие документы и правила дают эффект, а какие живут только в базе знаний
Про любовь написать 40 страниц “правильного регламента”, положить его в базу знаний и потом удивляться, почему же это все продолжают работать по-своему. Подход автора: стандарт полезен, если помогает принять конкретное решение ровно в тот момент, когда это решение нужно принять. Перед передачей задачи разработчику нужно делать короткую проверку прямо рядом с задачей. После встречи с разрабом фиксируем решения, открытые вопросы, ответственных, сроки и обязательное изменение основного документа. Еще у каждого стандарта должен быть владелец, иначе через год в базе лежит никому не нужный док. 

🧣 От Excel к диалогу: как мы построили ИИ-помощника Эйру для управления портфелем из 100+ проектов
В БКС больше ста проектов, около семидесяти из них активны, и сведения о каждом жили одновременно в плане, системе задач, протоколах, таблицах с рисками и отчетах. На ручную сверку одного проекта у автора однажды ушло около полутора часов. И изменения авторы начали не с ИИ. Сначала два года связывали сами проектные данные — планы, состояния, риски, бюджеты, команды и решения, — и только потом поверх этой основы появился помощник, который ищет противоречия и готовит следующий шаг для человека. За первую неделю он выдал больше 1500 сигналов, но автор специально говорит, что это плохой показатель успеха. Настоящий показатель — сколько рекомендаций человек проверил и превратил в действие. И в целом, если система производит всё больше информации, но от этого не меняются решения и действия, она просто производит более дорогой информационный шум.

🔥 10 самых интересных публикаций по управлению проектами за 19 сентября — 1 октября (1)
😬 Я стала руководителем. А кто-нибудь объяснит, что теперь делать?
Бывает же: вчера ты был хорошим специалистом, а сегодня руководишь теми же людьми, причем никто особенно не объяснил, чем новая работа отличается от старой. И первый соблазн, конечно, продолжить делать то, что умеешь лучше всего: самому лезть в сложные задачи, исправлять за коллегами и быть главным экспертом команды. Автор считает, что это путь к двум проблемам сразу: как рук ты становишься узким местом, а сотрудники перестают расти, потому что самые интересные решения всё равно забирает начальник. Главное - руководитель отвечает уже не за качество собственной работы, а за способность команды выдавать результат без его постоянного личного участия.

😏 Хватит пилить слонов под видом MVP
О том, как «минимальной первой версией» постепенно начинают называть проект на год с сотнями требований - просто потому, что слово удобное. Автор предлагает вернуть первоначальный смысл: первая версия нужна не для того, чтобы выпустить уменьшенную копию будущего большого продукта, а чтобы как можно раньше проверить ключевое предположение на настоящих пользователях. Поэтому вопрос должен звучать не «что из полного списка требований мы успеем сделать?», а «какой минимальный работающий результат уже позволит нам чему-то научиться?». 

 👍 Что ИИ уже умеет делать за проджект-менеджера
Автор из ЮMoney не пытается автоматизировать «работу руководителя проекта» целиком, а разбирает ее на маленькие операции. Улучшить постановку задачи, вытащить итог из длинной переписки, обработать запись встречи, найти просроченные работы, подготовить выборку по проектам - вот здесь ИИ уже вполне помогает. А дальше предлагается довольно здравый порядок: найти операцию, которая регулярно съедает много времени, оценить стоимость этой рутины, сделать небольшой опытный вариант и только после этого решать, стоит ли распространять решение дальше. То есть не «нам нужен ИИ», а «вот конкретная дорогая операция - можно ли убрать из нее ручной труд?».

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

🎹Почему команда не укладывается в сроки, хотя все задачи были оценены
Наверное, самый практически полезный материал недели. Главная мысль: оценка трудоемкости и срок завершения - вообще не одно и то же. Можно насчитать десять дней работы и не закончить ее за квартал, - ну это база. Автор предлагает отдельно учитывать реальную доступную загрузку команды, зависимости, скрытые работы, проверку результата, риски и резервы. Причем не брать из древнего шаблона «15% на встречи», а посмотреть на фактические данные. Особенно хорош пример с работой трех команд, где сама разработка действительно занимала около десяти дней, но последовательные зависимости растянули весь календарный срок за пределы квартала.

🥺 Тем, кто хотел быть оркестратором ИИ-агентов, посвящается!

Мы же тут начали находить себе место в прекрасном будущем? Дескать, хорошо, ИИ будет выполнять работу, а мы, конечно, руководить, ставить задачи, распределять, проверять результаты. Кто-то же должен спрашивать у агентов: "Коллеги (с), а почему это до сих пор не готово?"

И вот некий Итан Моллик пишет, что это ошибочное предположение.
https://www.oneusefulthing.org/p/the-dot-and-the-swarm
Последний год он тоже предполагал, что мы будем управлять командами AI-агентов примерно так же, как управляем людьми. Назначим аналитика, исполнителя, проверяющего, над ними поставим менеджера, определим правила, кто кому передает результат и в каких случаях несёт вопрос наверх. В общем, всё знакомое. Можно даже должностные инструкции почти не переписывать.

Однако Моллика впечатлил эксперимент OpenAI, в котором тысячи агентов работали над математической задачей,обменивались миллионами сообщений, подхватывали идеи друг друга, развивали перспективные направления. Люди задали направление и немного поправляли ход работы.

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

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

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

Но для тех, кто занимается проектами и автоматизацией, вопрос уже вполне практический: “А не собираем ли мы сложный процесс там, где скоро будет достаточно поручить задачу целиком?” Сначала шаг А, потом Б, затем согласование, потом проверка. Мы долго выясняли порядок действий, аккуратно и с муками его описали в куче инструкций, автоматизировали. А через какое-то время агенту можно будет просто сказать, какой результат нужен, и дать доступ к необходимым данным.
Вы скажете: "Ну уж управлять-то всё равно придётся человеку". Вполне возможно. Только придется заново разбираться, в чём именно состоит эта работа.
#внезапное

🔥 10 самых интересных публикаций по управлению проектами за 19 сентября — 1 октября (2)

🏖 «Я думал, вы уже начали» — почему задачи зависают между «готово» и «взял»
Очень узнаваемая мелочь, из которой потом почему-то складываются большие задержки. Разработчик написал «готово, можно смотреть», руководитель решил, что проверка уже идет, а тестировщик просто увидел сообщение и не понял, что работу нужно брать прямо сейчас. Все всё видели, никто формально ничего не нарушил — задача два часа лежала между людьми. Автор предлагает считать передачу состоявшейся только тогда, когда следующий участник явно принял следующий шаг: «возьму через час», «вернусь с результатом до 16:00» или даже «не могу взять, потому что нет доступа». Статус показывает состояние работы, но совсем не обязательно показывает, кто прямо сейчас обязан сделать следующий ход.

🤯Налог на координацию: почему ИИ ускоряет сотрудников, но почти не влияет на прибыль компании
Интересная попытка объяснить, почему сотрудники с ИИ вроде стали работать быстрее, а финансового чуда у компании что-то не видно. Приводятся результаты исследования: многие видят рост личной производительности, но заметно меньше организаций видят влияние на прибыль. Объяснение такое: мы ускоряем отдельные операции внутри старого процесса, тогда как огромная часть потерь сидит между операциями (передача информации, ожидание решения, согласование, поиск владельца и повторный ввод одних и тех же данных). Если аналитик теперь готовит документ за двадцать минут вместо двух часов, а затем документ три дня ждет согласования, экономический эффект получается довольно скромный.

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

😬 Разработка с нуля: как выстроить команду и оценивать ее КПД
Материал хорош применительно к проектам 1С. Авторы предлагают отдельно видеть работу и самое главное - не превращать коэффициенты эффективности в рейтинг сотрудников. Если задача вместо восьми часов заняла двадцать, интереснее разобраться, почему: плохая оценка, изменившиеся требования, переделка, недостаток исходных данных или техническая проблема. Тогда учет времени становится не средством доказать, кто работает плохо, а источником для улучшения следующих оценок и самого процесса. Отдельно разбирается распределение ответственности между руководителем проекта, архитекторами и исполнителями. 

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

🦢Чёрный лебедь в дата-центре и реестры рисков

Недавно я писал о пожаре в американском дата-центре Lake Mariner. Там всё оказалось весьма топорно: проблемы с пожарной безопасностью и размазанная ответственность. И кончилось безобидно вроде.

А сегодня пожар произошел в дата-центре Яндекса в Сасово. Причина совсем другая — атака беспилотников. Площадка остановлена, проблемы возникли у сторонних сервисов (ну вы наверняка ощутили).

Перед нами почти классический "чёрный лебедь". Ещё несколько лет назад вероятность поражения ЦОД беспилотником вряд ли всерьёз рассматривалась в большинстве проектов. Однако важно различать причину форсмажора и её последствия. Потому что предсказать конкретную угрозу сложно, а вот сценарий полной потери ДЦ — вполне стандартная задача. 

Вот вы сегодня работаете руководителем проекта или аналитиком. Проектируете систему, согласовываете требования, организуете разработку, внедряете. А завтра дата-центр, на котором всё работает, — фьюить! 😞 И результаты нескольких месяцев работы недоступны. Разумеется, вы не можете предотвратить пожар или вражескую атаку. Но можете ещё на этапе проектирования задать несколько вопросов - как минимум себе.

• Что произойдет, если завтра исчезнет вся площадка? 
• Сколько времени бизнес готов прожить без системы? 
• Сколько данных допустимо потерять? 
• Есть ли резервный сценарий? 
• Кто и как будет восстанавливать работу? 

И ответы (если их получите...) превратить в конкретные нефункциональные требования: восстановление за четыре часа (RTO), потеря не более 15 минут данных (RPO), сохранение документов при недоступности внешнего сервиса. Цифры условные)

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

Ну и подборочка, где почитать подробнее — про такие вот риски и их проработку:

Как составить план аварийного восстановления — вполне доступное объяснение RTO, RPO, анализа влияния на бизнес и планирования восстановления. С примерами.
Проектирование отказоустойчивости ИТ-систем — о том, как учитывать отказы компонентов и внешних зависимостей при проектировании.
ГОСТ Р ИСО 31000-2019 — общая методология управления рисками: выявление, оценка, обработка и пересмотр.
ГОСТ Р ИСО 22301-2021 — управление непрерывностью деятельности организации, подготовка к сбоям и восстановлению.
ГОСТ Р ИСО/МЭК 25010-2015 — модель качества программных систем, в том числе надёжность, отказоустойчивость и восстанавливаемость.

🔥 Управление проектами: топ публикаций за 1–11 октября (1)

💻 Проект готов на 90%. Уже полгода
Про те магические 90%, на которых проект способен находиться…очень долго. Причины: РП может сознательно приукрашивать положение дел, исходный объем работ мог быть недооценен, процент готовности мог быть неправильно рассчитан. Но даже и с процентами на руках - никто не знает, "когда закончим?". Процент говорит о прошлом (сколько уже сделано), а срок зависит от того, сколько неопределенности еще маячит впереди: непроверенные интеграции, новые требования, замечания, зависимости от других команд. Поэтому радостные 90% вполне могут соседствовать с еще тремя месяцами работы. Лучше задавать вопрос “а что мы до сих пор не знаем про оставшуюся часть проекта?”.

🏃‍♂️Пять оттенков PPM: почему идеальной системы для проектного офиса не существует
Автору надоело каждый месяц вручную сводить часы, ставки, замены сотрудников и оставшуюся работу в таблицах, и он пошел смотреть 5 СУП. Но ценен материал, пр.вс., способом сравнения. Берется реальная ситуация: несколько проектов делят специалистов, человек заменяется на более дорогого, объем оставшейся работы меняется, и нужно понять новую загрузку, себестоимость и прогноз завершения. И вот выясняется, что СУПы поддерживают эту цепочку очень по-разному: где-то нужные связи есть изначально, где-то их придется отдельно настраивать. Если близкая тема - почитайте.

😠 Процесс работает, пока руководитель на месте. Ошибки управления через ручное вмешательство
РП уехал на пару дней - и всё стопнулось) Причем люди знают свою работу, задачи заведены, доступы есть. Просто никто кроме рука не знает, какую заявку поставить первой,что допустимо самостоятельно пообещать клиенту и т.п. Пока рук рядом, эта дыра незаметна, т.к.он закрывает ее короткими сообщениями в чате (к примеру). И вот автор показывает, что это на самом деле недоописанная система принятия решений. Лечение - отнюдь не в том, чтобы назначить заместителя, который будет отвечать на те же вопросы. Надо вытащить правила из головы руководителя и формализовать (ну и научить их  использовать): кто управляет очередью, какие решения сотрудники принимают сами и в каких случаях действ.

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

💻 Как проверить реалистичность квартального плана на примере AI-ассистента
Очень практический разбор, как проверить красивый квартальный план до того, как он превратится в красивый, но проваленный квартальный план)) Дано: 5 сотрудников, 6 двухнедельных периодов и набор работ по ИИ-помощнику. Автор отдельно считает доступное время серверных разработчиков, специалиста по интерфейсу и тестировщика и обнаруживает, что общий объем трудозатрат вроде выглядит терпимо, но вот по конкретным ролям он не помещается. Поэтому из первой версии убираются менее важные части, проверяются зависимости и промежуточные результаты. В итоге рисуется норм план - и норм пример планирования.

🔥 Управление проектами: топ публикаций за 1–11 октября (2)

😯 Заказчик изменил требование посреди разработки. Как понять, что придётся переделывать
Практическая инструкция на случай классической ситуации “тут небольшое изменение”. Пример: команда уже реализует согласование заявок, а заказчик внезапно добавляет новый уровень согласования и возможность возвращать отклоненную заявку на повторный круг. Автор предлагает не переписывать старое требование задним числом и не называть новый срок с ходу. Сначала изменение фиксируется отдельно, затем сравнивается старое и новое поведение, выясняется причина изменения и проходятся все зависимости: данные, правила, интерфейсы, проверки, уже сделанная работа. Важный момент: сообщение заказчика о новом пожелании еще не означает автоматического принятия командой нового объема. Только после оценки можно решать - включать изменение сейчас, переносить дальше или менять срок. 

🎃 Вклад системного аналитика оценивают не по качеству постановки задач разработчикам. А как тогда?
Контур предлагает расширить представление о работе аналитика. Стартовый тезис такой: можно написать прекрасное задание, после которого у разработчиков не останется ни одного вопроса, и потратить несколько месяцев на то, что пользователю вообще не нужно. Поэтому качество работы предлагается оценивать по четырем вещам: понял ли аналитик настоящую проблему, рассмотрел ли несколько вариантов решения, синхронизировал ли участников и появился ли в итоге нужный бизнес-результат. Документ (ТЗ) здесь - средство, а не произведенный результат. И это вообще легко переносится за пределы аналитиков: руководителя проекта тоже негоже оценивать по красоте плана, а продуктового специалиста - по количеству придуманных возможностей. Начинать надо с проверки, правильную ли проблему мы собрались решать.

🕺 Как разработать уникальное тиражируемое решение для отрасли? Опыт Integer в создании TMS для фармацевтики
Хороший материал на границе проекта и продукта. Компания когда-то делала довольно специализированное решение для фармацевтики, а затем стала вытаскивать из отдельных внедрений общую основу, которую можно использовать у следующих заказчиков. Создается устойчивое ядро плюс возможности быстро адаптировать его под специфику клиента. Каждый следующий проект при этом должен отвечать на два вопроса: что здесь действительно уникально, а что пора перенести в общую часть продукта? По данным автора, такой подход сократил средний срок сложного внедрения примерно с восьми месяцев до трех–пяти. 

🙂 Почему дежурные не эскалируют
Допустим (а что допускать-то, такое сейчас каждый день), что сервис уже частично прилег, и дежурный на ТП понимает, что сам может не справиться. И тем не менее всё равно пробует еще что-нибудь вместо того, чтобы позвать коллег. Автор выяснил, что проблема часто вовсе не в незнании инструкции. Разбудить человека ночью психологически неприятно, а признать инцидент достаточно серьезным - значит лично принять решение и ответственность. Решение оказалось неожиданно простым: перенести выбор из аварии в спокойное время. Заранее определить уровни инцидентов, для каждого записать, когда и кого нужно привлекать, а спорные случаи потом использовать для уточнения правил. Коротко, если человек должен в стрессовой ситуации принять важное и неприятное решение, часть этого решения стоит принять заранее, пока ничего не горит.

👨‍🍳 "Сколько я на этом заработаю?" Неправильный вопрос для двух внедрений из трёх
Автор предлагает делить изменения на три типа. 1) дают самостоятельный эффект, их действительно можно оценить отдельно. 2) являются инфраструктурой: сами денег почти не приносят, но без них не работают другие части. 3) звенья цепочки, которые становятся полезными только вместе с соседними изменениями. И вот пытаться для каждого такого звена отдельно посчитать "сколько заработаем" довольно бессмысленно. В одном из примеров автоматизировали продажу билетов, но оставили человеку необходимость вручную подтверждать каждую оплату. Формально почти всё было автоматизировано, а практически без толку, тк организатор всё равно должен постоянно сидеть у экрана и в итоге возвращается к старому способу.

🔥 Самые интересные (ну или просто норм) публикации по управлению проектами за 11–18 октября (1)

🤵 10 лет растил команды — и не прохожу фильтр на управленческий опыт
Формально это история карьеры руководителя, но внутри получился разбор нескольких управленческих ловушек. Автор строил межфункциональные команды, выращивал руководителей, занимался требованиями, продуктом и поставкой и несколько раз попадал в ситуацию “ответственность за результат есть, а возможности изменить процессы, от которых результат зависит, нет”. Показывает разницу между локально успешным опытом и устойчивым изменением организации: можно собрать отличную команду и доказать, что новый способ работы эффективнее, но если он существует только благодаря договоренности с конкретными руководителями, смена руководства спокойно отменит всё обратно.Важно: изменить процесс и изменить культуру — разные задачи. Если сама организация не хочет обсуждать проблемы, хороший метод и сильный руководитель сами по себе не спасут.

🍻 Ни зарплат, ни отпусков, ни больничных. Зато есть User Story и Merge Request: как AI-агенты работают у меня в Jira
Что происходит, когда цифровых исполнителей не просто держат в отдельном чате, а встраивают в обычный рабочий процесс команды. Автор создал для них роли аналитика и разработчиков и назначает им задачи в Jira так же, как людям. “Аналитик” читает документацию, задает уточняющие вопросы и готовит требования; “разработчики” меняют код, запускают проверки и передают результат человеку на просмотр. Если раньше команда получала один результат на проверку в день, а теперь машина способна принести тридцать, так что узким местом становится уже не разработка, а способность людей проверить сделанное. 

😭 Почему тимлид не может сказать, сколько команда сделает в следующем спринте, и как я это посчитал
Очень практический материал про то, почему план “в прошлый раз сделали 300 баллов — значит, и сейчас сделаем 300” почти бессмыслен. В одном цикле кто-то был в отпуске, в другом появился новичок, в третьем треть времени ушла на ошибки и поддержку. Автор предлагает считать не результат команды за период, а результат на эффективный человеко-день, с учетом отсутствий, загрузки на поддержку и реальной готовности новых сотрудников. Но самая интересная мысль — переработки нельзя записывать в нормальную производительность. Если команда три дня сидела допоздна и благодаря этому выполнила план, а мы используем этот результат для следующего планирования, то просто узакониваем аврал.

🤐 Разработка перестает быть главным дефицитом. За что теперь будут платить в IT?
Десятилетиями одной из главных проблем ИТ было то, что хороших идей больше, чем возможностей разработчиков. А теперь производство программ постепенно ускоряется, и внезапно выясняется, что очередь действительно ценных идей вовсе не бесконечна. Значит, узкое место переезжает: уже недостаточно хорошо распределять ограниченный ресурс разработки, всё важнее правильно выбирать, что вообще стоит делать. Причем плохую идею теперь тоже можно реализовать быстрее — и потом столь же бодро тратить деньги на ее поддержку. Хороший текст о том, как удешевление одной части работы меняет ценность всех соседних ролей.

⚠️ Полигон гипотез: как понять, что я не сделаю бесполезную фичу?
Три красивые продуктовые гипотезы прошли исследование, выглядели убедительно, затем съели  работу нескольких команд и бюджет на продвижение - и не подтвердились. После этого автор собрал систему, которая еще до запуска ищет слабые места в исходных предположениях: на чем держится гипотеза,
можно ли полученными данными вообще ответить на нужный вопрос,
не опираются ли несколько предположений друг на друга.

🔥 Самые интересные (ну или просто норм) публикации по управлению проектами за 11–18 октября (2)

⭐️ Сколько разработчиков может вести тимлид: 7 ошибок при росте команды
Команда выросла с 6 человек до 12, а руководитель продолжает работать так, будто ничего не изменилось (пишет код, проверяет изменения, принимает финальные решения и остается главным носителем знаний). В итоге очередь растет уже не у разработчиков, а у самого начальника. Автор не пытается вывести магическое число типа “руководитель может управлять ровно семью людьми”, ибо всё зависит от зрелости сотрудников, сложности работы и тд. Но после определенного размера команды прежняя модель действительно перестает работать. Главная мысль: при росте команды нужно проектировать заново не только структуру команды, но и собственную должность. То, что было сильной стороной начальника на шести людях, на двенадцати легко становится главным ограничением всей системы.

💪 Самый дорогой источник потерь в проектах, о котором никто не говорит
Автор начинает с Mars Climate Orbiter, который NASA потеряла из-за того, что две команды использовали разные единицы измерения. Причем обе считали правильно. Ошибка возникла не внутри работы специалистов, а на стыке между ними. Дальше эта история переносится на обычные проекты: требования передали, но не сверили понимание; проблема обнаружилась, но осталась в переписке; у результата передачи между подразделениями вообще нет владельца. Всё это выглядит как работа, люди заняты, отчеты идут — поэтому потери почти невидимы. А потом появляются ожидание, повторная работа, выгорание, незапланированные подрядчики и сдвиг экономического эффекта. В управлении проектами почти никто системно не считает стоимость плохой координации, хотя именно она регулярно съедает больше всего времени.

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

🚬 Карта автономии AI: как решить, что агенту можно делать без человека
Текст предлагает обсуждать не «насколько умна модель», а каждое конкретное действие: прочитать данные, подготовить предложение, изменить запись, отправить сообщение, удалить и тд. Потому что цена ошибки и возможность ее отменить у них совершенно разные. Получается несколько уровней самостоятельности: от простого совета человеку до действия в заранее установленных границах. 90% точности ничего не говорит о допустимости автоматизации, пока мы не знаем цену остальных 10%. До передачи действия машине нужно определить худший реалистичный исход, владельца риска, способ остановки и восстановления. 

❓ Внедрение проектного офиса: проектный, управленческий и продуктовый подходы
Про создание проектного офиса - с 3 сторон. 1) это обычный проект: есть сроки, ресурсы и конкретный первый результат. 2) новая управленческая функция, а значит, офис должен иметь реальные полномочия влиять на правила принятия решений, иначе получится просто фабрика отчетов. И, наконец, 3) это внутренний продукт для руководителей и команд: его шаблоны, правила и услуги должны кому-то реально помогать, а не существовать потому, что «так положено». Отсюда подход к запуску: не пытаться сразу внедрить идеальную систему из всех возможных процессов и документов, а начать с минимального набора, который решает конкретную проблему бизнеса.

Вайб-проекты от Сбера 😉

Что ж, Сбер в концепции Vibe PPM предлагает передать ИИ-агентам значительную часть управления проектами: от составления планов до контроля исполнения.

Кратко:
✅Руководитель задаёт нужный результат и ограничения, а агенты определяют, как организовать работу, и обращаются к человеку, когда требуется его решение.

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

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

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

😮 Целевой ориентир — 15–25 (!!!) проектов на сотрудника проектного офиса вместо 3–5. При этом ответственность остаётся у людей — даже если со временем они разучатся самостоятельно выполнять работу, которую передали ИИ.
—
Пока главный вопрос для меня - сколько же проблем в проектах возникает из-за медленной обработки информации, а сколько из-за того, что так называемые люди не могут договориться или проходят бюрократические круги ада. С инфой-то агенты вполне могут помочь, а вот со вторым всё сложнее... А если проектов всё-таки станет в несколько раз больше, хотелось бы увидеть такую же смелость в пересмотре зарплат.💰

Или это Сбер так намекает, что, чтобы выжить, перформить теперь придется по-жесткому?..

#внезапное

🔥 Интересные публикации по управлению проектами за 23-31 октября (1)

🍑 Черный октябрь "Яндекса": анатомия архитектурной и управленческой катастрофы, которую списали на форс-мажор
Да, куда же без этого. За четверо суток в октябре из строя вышли три дата-центра "Яндекса", облако легло, финтех-подразделение провело 11 дней в ручной сверке балансов. Удобно списать всё на форс-мажор, мол, ни одна архитектура такого не выдержит. Но вот автор препарирует поминутную хронику и показывает: между потерей первой и второй зоны доступности прошло 74,5 часа, то есть время на спасение системы было, но им не воспользовались. Физическое поражение площадок стало лишь триггером, а масштаб катастрофы- следствием просчётов в управлении мощностями и оценке рисков на уровне высшего руководства. В общем, если у вас есть план на случай аварии, который никто не репетировал и не проверял на реальном сценарии,- это ерунда, а не план.

👀 Метрики команды врут поодиночке или почему теперь я смотрю их парами
Автор начинает с прекрасного результата: время до первой проверки изменений сократилось с 6 часов до 36 минут. Только потом выяснилось, что дефектов после выпуска- в 2,6 раза больше. Отсюда идея: почти любой показатель команды опасно читать отдельно. Скорость проверки нужно смотреть вместе с размером изменений и качеством, время выполнения- с количеством одновременно начатой работы, процент успешных выпусков- с самим числом выпусков. Хороший пример, когда рост ошибок на 65% сначала хотелось лечить ужесточением проверки кода, а настоящая причина оказалась... ну конечно же, в плохо подготовленных требованиях и нереалистичном планировании.

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

😐 Первый проект Process Mining: как выбрать процесс для оптимизации, собрать команду и не застрять на этапе пилота
Инструкция по первому проекту процессной аналитики. До старта предлагается определить несколько конкретных вопросов к процессу и выбрать участок, где есть и доступные данные, и измеримый эффект, и владелец, готовый потом что-то изменить. Потому что построить красивую картинку as is- еще не результат. Один из показателей успешности опытного запуска у авторов прямо так и сформулирован: принято ли хотя бы по одной найденной проблеме решение об изменении процесса. Если нет, команда просто произвела еще одну презентацию. Еще есть рекомендация заранее проверить качество истории в исходных системах: есть ли даты смены состояний, сквозные идентификаторы и достаточная глубина данных и прочие нужные штуки.

😊 Куда уходит зарплата разработчика: как мы приоритизируем бэклог и связываем задачи с бизнесом
Или о том, как перестать выделять место в плане тому, кто громче всех попросил об этом. Коллеги из Аспро сначала сравнивали задачи по единому правилу, но довольно быстро поняли, что это не поможет им куда-то двигаться. Поэтому задачи связывают с направлениями и конкретными показателями, а после выпуска проверяют, произошло ли ожидаемое изменение. Еще хорош кусок про срочные работы. Они выглядят бесплатными (“ну добавили небольшую задачу, всего-то”). На деле она прерывает постановщика, разработчика, проверяющего и вытесняет что-то уже запланированное. Поэтому под такие работы заранее выделяется часть мощности команды, а на очередную срочную просьбу задается прекрасный вопрос: "Хорошо. А какую уже запланированную задачу мы ради этого не сделаем?". По словам автора, после него половина срочного внезапно перестает быть срочной.