У исполнителей стало в 2 раза больше работы, но их количество в 2 раза не увеличили и зарплату в 2 раза прежнему числу персонала не подняли?
Не очень понятен вывод, про то, что у исполнителей стало в 2 раза больше работы. Увеличилось количество проектов - увеличились и команды, часть проектов отдали поставщикам. Про зарплату тоже не до конца понял - ведь это вопрос индивидуальный и его нельзя решать на основании количества проектов в компании.
Об исполнителях в итоге начали думать в самую последнюю очередь и лишь потому, что неожиданно оказывалось, что один и тот же исполнитель нужен сразу в 2-х важных и срочных проектах
Не совсем так. При модели, когда есть централизованный пул разработчиков и они выделяются на проекты определенно возникнут сложности с распределением разработчиков при росте количества проектов. Условно говоря, когда есть 10 проектов и 30 разработчиков их поделить сравнительно легко и можно сделать даже в Excel. Когда проектов 300 и разработчиков под 1000, задача уже на порядки сложнее. И мы ее решили выделением постоянных команд под функциональные области, то есть как в Lean Portfolio Management из SAFe , не разработчик назначается на проект, а проект на готовую команду разработки.
Чендж-реквесты - это обычные рутинные действия, которые должны постоянно выполняться, т.е. это обычная работа для исполнителей. Чендж-реквесты мелкие, не особо сложные, выполняются 1-2 исполнителями и не требуют бюджета.
Как это может быть 1-2 исполнителя и не требуют бюджета? Эти исполнители не за бесплатно же работают.
А отменили мы их именно потому, что это рутинные действия и не всегда понятно зачем они нужны продукту целиком (то есть конкретный пользователь то конечно объяснит, что без нового отчета или кнопки он жить не может - но нужно ли это действительно продукту?) .
Введя заградительные меры и отправляя пользователей к владельцам процессов мы по факту и внедрили роль полноценно Владельца Продукта - который действительно решает, что будет его продукт делать и как, а не администрует бэклог хотелок от сотен пользователей.
Бизнес-ценность необязательно связана с количественными эффектами, они могут быть и качественными, и косвенными, главное - измеримыми. Иначе резонно встанет вопрос cui bono, лат. "нахрен такое делать" :)
Если я правильно понял, речь идет про то, что не все эффекты должны быть денежными (иначе не очень понятно как могут быть измеримыми качественные эффекты). Так и есть - для группы проектов у нас эффекты не привязаны к деньгами - например внутренняя соц сеть или вообще сервисы для сотрудников. Их измеряем через косвенные метрики - DAU/MAU итд.
Мне описание вашей комбинированной методики/фреймворка напомнило SAFe, который отлично подходит для управления программами/портфолио/проектами энтерпрайзов. Почему сразу не переняли?
Действительно, мы многое взяли из SAFe , но не объявляли, что внедряем SAFe, а шли к этому итерационно. Статья собственно об этом: если не получается сдвинуть огромную корпорацию целиком и сразу (а при внедрении SAFe именно так и нужно делать (ведь придется провести множество орг изменений - начиная от команд и должностей и заканчивая регулярными встречами типа PI планирования). Мы пошли шаг за шагом и получили почти тоже самое, не производя революций - каждое изменение логично вытекало из предыдущего
Как вы понимаете что для проектов, аналогов которым в истории не было (и сравнить данные не с чем) PM не завышает сроки, чтобы в них попасть?
Есть руководитель PM'a, есть арх совет (гуру с большим опытом) - они увидят, что сроки завышаются.
Ваш бизнес пока не начал спрашивать за деньги/эффективность?
Начал, это наш приоритет на 2024г. В конце года поделимся выученными уроками, если таковые будут )
Точно сказать не могу, до этого в компании не было фокуса на цифровизацию. Вероятнее всего стандартные практики ИТ - ITIL/ITSM и всякое в таком духе
Не очень понятен вывод, про то, что у исполнителей стало в 2 раза больше работы. Увеличилось количество проектов - увеличились и команды, часть проектов отдали поставщикам. Про зарплату тоже не до конца понял - ведь это вопрос индивидуальный и его нельзя решать на основании количества проектов в компании.
Не совсем так. При модели, когда есть централизованный пул разработчиков и они выделяются на проекты определенно возникнут сложности с распределением разработчиков при росте количества проектов. Условно говоря, когда есть 10 проектов и 30 разработчиков их поделить сравнительно легко и можно сделать даже в Excel. Когда проектов 300 и разработчиков под 1000, задача уже на порядки сложнее. И мы ее решили выделением постоянных команд под функциональные области, то есть как в Lean Portfolio Management из SAFe , не разработчик назначается на проект, а проект на готовую команду разработки.
Как это может быть 1-2 исполнителя и не требуют бюджета? Эти исполнители не за бесплатно же работают.
А отменили мы их именно потому, что это рутинные действия и не всегда понятно зачем они нужны продукту целиком (то есть конкретный пользователь то конечно объяснит, что без нового отчета или кнопки он жить не может - но нужно ли это действительно продукту?) .
Введя заградительные меры и отправляя пользователей к владельцам процессов мы по факту и внедрили роль полноценно Владельца Продукта - который действительно решает, что будет его продукт делать и как, а не администрует бэклог хотелок от сотен пользователей.
Если я правильно понял, речь идет про то, что не все эффекты должны быть денежными (иначе не очень понятно как могут быть измеримыми качественные эффекты). Так и есть - для группы проектов у нас эффекты не привязаны к деньгами - например внутренняя соц сеть или вообще сервисы для сотрудников. Их измеряем через косвенные метрики - DAU/MAU итд.
Действительно, мы многое взяли из SAFe , но не объявляли, что внедряем SAFe, а шли к этому итерационно. Статья собственно об этом: если не получается сдвинуть огромную корпорацию целиком и сразу (а при внедрении SAFe именно так и нужно делать (ведь придется провести множество орг изменений - начиная от команд и должностей и заканчивая регулярными встречами типа PI планирования). Мы пошли шаг за шагом и получили почти тоже самое, не производя революций - каждое изменение логично вытекало из предыдущего
Есть руководитель PM'a, есть арх совет (гуру с большим опытом) - они увидят, что сроки завышаются.
Начал, это наш приоритет на 2024г. В конце года поделимся выученными уроками, если таковые будут )