Комментарии 8
"Lean-подходы начали внедряться на наших предприятиях в 2016 году, а в 2017..."
До 2016 года на чём развивались?
"Мощный пинок для изменений придавал рост числа проектов – в 2021 году их стало уже 140, в 2 раза больше."
У исполнителей стало в 2 раза больше работы, но их количество в 2 раза не увеличили и зарплату в 2 раза прежнему числу персонала не подняли?
"Например, к 2023 году нам предстояло решить проблему, которая всё это время маячила на фоне: управление ресурсами команд "
Об исполнителях в итоге начали думать в самую последнюю очередь и лишь потому, что неожиданно оказывалось, что один и тот же исполнитель нужен сразу в 2-х важных и срочных проектах.
У исполнителей стало в 2 раза больше работы, но их количество в 2 раза не увеличили и зарплату в 2 раза прежнему числу персонала не подняли?
Не очень понятен вывод, про то, что у исполнителей стало в 2 раза больше работы. Увеличилось количество проектов - увеличились и команды, часть проектов отдали поставщикам. Про зарплату тоже не до конца понял - ведь это вопрос индивидуальный и его нельзя решать на основании количества проектов в компании.
Об исполнителях в итоге начали думать в самую последнюю очередь и лишь потому, что неожиданно оказывалось, что один и тот же исполнитель нужен сразу в 2-х важных и срочных проектах
Не совсем так. При модели, когда есть централизованный пул разработчиков и они выделяются на проекты определенно возникнут сложности с распределением разработчиков при росте количества проектов. Условно говоря, когда есть 10 проектов и 30 разработчиков их поделить сравнительно легко и можно сделать даже в Excel. Когда проектов 300 и разработчиков под 1000, задача уже на порядки сложнее. И мы ее решили выделением постоянных команд под функциональные области, то есть как в Lean Portfolio Management из SAFe , не разработчик назначается на проект, а проект на готовую команду разработки.
Но к 2022 году число проектов снова выросло, а ещё всплыл неожиданно накопленный с годами бэклог из 2500 чендж-реквестов от пользователей по разным системам. Нам пришлось переработать весь процесс этих реквестов и отказаться от них в пользу организационных проектов с подтвержденными эффектами, ограниченными сроками и бюджетом.
А вот это было сделано зря. Чендж-реквесты - это обычные рутинные действия, которые должны постоянно выполняться, т.е. это обычная работа для исполнителей. Чендж-реквесты мелкие, не особо сложные, выполняются 1-2 исполнителями и не требуют бюджета.
Вместо этого вы решили всё усложнить и сделать из них проекты, а это куча согласований, поиски коммерческой выгоды, встраивание в конвейер выполнения с другими проектами, поиски бюджета и куча потерянного впустую времени.
Чендж-реквесты - это обычные рутинные действия, которые должны постоянно выполняться, т.е. это обычная работа для исполнителей. Чендж-реквесты мелкие, не особо сложные, выполняются 1-2 исполнителями и не требуют бюджета.
Как это может быть 1-2 исполнителя и не требуют бюджета? Эти исполнители не за бесплатно же работают.
А отменили мы их именно потому, что это рутинные действия и не всегда понятно зачем они нужны продукту целиком (то есть конкретный пользователь то конечно объяснит, что без нового отчета или кнопки он жить не может - но нужно ли это действительно продукту?) .
Введя заградительные меры и отправляя пользователей к владельцам процессов мы по факту и внедрили роль полноценно Владельца Продукта - который действительно решает, что будет его продукт делать и как, а не администрует бэклог хотелок от сотен пользователей.
мы должны измерять ценность, которую проект приносит бизнесу. Но у нас есть и проекты, которые не приносят прямых количественных эффектов
Бизнес-ценность необязательно связана с количественными эффектами, они могут быть и качественными, и косвенными, главное - измеримыми. Иначе резонно встанет вопрос cui bono, лат. "нахрен такое делать" :)
Мне описание вашей комбинированной методики/фреймворка напомнило SAFe, который отлично подходит для управления программами/портфолио/проектами энтерпрайзов. Почему сразу не переняли?
Как вы понимаете что для проектов, аналогов которым в истории не было (и сравнить данные не с чем) PM не завышает сроки, чтобы в них попасть?
Ощущение, что следующий логичный шаг высчитывать не только попадание в сроки, но и business value ÷ effort = roi
Ваш бизнес пока не начал спрашивать за деньги/эффективность?
Александр, спасибо за статью, успехов!
Бизнес-ценность необязательно связана с количественными эффектами, они могут быть и качественными, и косвенными, главное - измеримыми. Иначе резонно встанет вопрос cui bono, лат. "нахрен такое делать" :)
Если я правильно понял, речь идет про то, что не все эффекты должны быть денежными (иначе не очень понятно как могут быть измеримыми качественные эффекты). Так и есть - для группы проектов у нас эффекты не привязаны к деньгами - например внутренняя соц сеть или вообще сервисы для сотрудников. Их измеряем через косвенные метрики - DAU/MAU итд.
Мне описание вашей комбинированной методики/фреймворка напомнило SAFe, который отлично подходит для управления программами/портфолио/проектами энтерпрайзов. Почему сразу не переняли?
Действительно, мы многое взяли из SAFe , но не объявляли, что внедряем SAFe, а шли к этому итерационно. Статья собственно об этом: если не получается сдвинуть огромную корпорацию целиком и сразу (а при внедрении SAFe именно так и нужно делать (ведь придется провести множество орг изменений - начиная от команд и должностей и заканчивая регулярными встречами типа PI планирования). Мы пошли шаг за шагом и получили почти тоже самое, не производя революций - каждое изменение логично вытекало из предыдущего
Как вы понимаете что для проектов, аналогов которым в истории не было (и сравнить данные не с чем) PM не завышает сроки, чтобы в них попасть?
Есть руководитель PM'a, есть арх совет (гуру с большим опытом) - они увидят, что сроки завышаются.
Ваш бизнес пока не начал спрашивать за деньги/эффективность?
Начал, это наш приоритет на 2024г. В конце года поделимся выученными уроками, если таковые будут )
Одна модель, чтобы править IT-проектами, и наш долгий путь к ней