#CaseStudy
Иногда людей увольняют после performance review по причине: "ты не справляешься с поставленными задачами". На вопрос какими конкретно, начисляется перечисление. Но очень часто сотрудник слышит об этих задачах впервые.
Как думаете?
Иногда людей увольняют после performance review по причине: "ты не справляешься с поставленными задачами". На вопрос какими конкретно, начисляется перечисление. Но очень часто сотрудник слышит об этих задачах впервые.
Как думаете?
Anonymous Poll
48%
Это надуманный повод выкинуть сотрудника на мороз.
56%
Неумение сформулировать требование к позиции и провести onboarding.
4%
Свой вариант в комментариях.
#CaseStudy
Проект аутсорс-разработки сталкивается с настойчивым требованием одного из менеджеров клиента из США перейти на модель стафог. До этого момента команды работали в режиме почти PES (Professional Engineering Services). О разнице между StaffAug vs PDS vs PES я расскажу в историческом очерке (первая часть про StaffAug). Менеджер проекта на стороне исполнителя базируется в Центральной Европе, в то время как часть команды разработчиков находится в Латинской Америке.
Проблематика:
✏️ Серебряной пули нет: проблему необходимо решать комплексно по нескольким направлениям.
✏️ Низкая маржинальность: стафог наименее прибыльная модель для исполнителя.
✏️ Микроменеджмент: Постоянное вмешательство клиента в процесс разработки может снизить мотивацию команды и увеличить текучесть кадров.
✏️ Технологические ограничения: Избыточный контроль со стороны заказчика может затруднить принятие качественных решений.
✏️ География проекта: заказчик в США, проектный менеджер в Европе, часть команды в Латинской Америке. Эффективной работы 24/7 для ПМ невозможно организовать.
Решения:
🛠 Мы так не работаем. Самый рискованный и простой способ. Прямой отказ от перехода на StaffAug должен быть подкреплён крепкой позицией и высоким уровнем доверия со стороны спонсора проекта (project sponsor). Дипломатичность, уверенность в своих силах и уверенная аргументация – будут вам необходимы.
🛠 Анализ причин. Выяснить, почему менеджер клиента настаивает на StaffAug’е. Помогут регулярные личные встречи с менеджером клиента, выстроенная система репортинга — это приведёт к появлению, а затем и росту доверия со стороны представителя заказчика. Я использую термины «гладить по голове» и «сидеть на коленках» - фривольно описывают, что нужно делать.
🛠 Нанять или вырастить помощника. Закрывать, контролировать все задачи и оставаться эффективным одному ПМу не получится, особенно когда команда находится в 7 часах от вас и команд несколько. Наймите или вырастите себе помощника, который будет находиться рядом с командами, делегируйте часть полномочий и ответственности. И не забудьте договориться о зонах ответственности – это поможет избежать конфликтов в дальнейшем.
Кстати если у вас есть интересные кейсы для разбора – пишите мне в личку tg – @Antonio_Ingegnere
Проект аутсорс-разработки сталкивается с настойчивым требованием одного из менеджеров клиента из США перейти на модель стафог. До этого момента команды работали в режиме почти PES (Professional Engineering Services). О разнице между StaffAug vs PDS vs PES я расскажу в историческом очерке (первая часть про StaffAug). Менеджер проекта на стороне исполнителя базируется в Центральной Европе, в то время как часть команды разработчиков находится в Латинской Америке.
Проблематика:
✏️ Серебряной пули нет: проблему необходимо решать комплексно по нескольким направлениям.
✏️ Низкая маржинальность: стафог наименее прибыльная модель для исполнителя.
✏️ Микроменеджмент: Постоянное вмешательство клиента в процесс разработки может снизить мотивацию команды и увеличить текучесть кадров.
✏️ Технологические ограничения: Избыточный контроль со стороны заказчика может затруднить принятие качественных решений.
✏️ География проекта: заказчик в США, проектный менеджер в Европе, часть команды в Латинской Америке. Эффективной работы 24/7 для ПМ невозможно организовать.
Решения:
🛠 Мы так не работаем. Самый рискованный и простой способ. Прямой отказ от перехода на StaffAug должен быть подкреплён крепкой позицией и высоким уровнем доверия со стороны спонсора проекта (project sponsor). Дипломатичность, уверенность в своих силах и уверенная аргументация – будут вам необходимы.
🛠 Анализ причин. Выяснить, почему менеджер клиента настаивает на StaffAug’е. Помогут регулярные личные встречи с менеджером клиента, выстроенная система репортинга — это приведёт к появлению, а затем и росту доверия со стороны представителя заказчика. Я использую термины «гладить по голове» и «сидеть на коленках» - фривольно описывают, что нужно делать.
🛠 Нанять или вырастить помощника. Закрывать, контролировать все задачи и оставаться эффективным одному ПМу не получится, особенно когда команда находится в 7 часах от вас и команд несколько. Наймите или вырастите себе помощника, который будет находиться рядом с командами, делегируйте часть полномочий и ответственности. И не забудьте договориться о зонах ответственности – это поможет избежать конфликтов в дальнейшем.
Кстати если у вас есть интересные кейсы для разбора – пишите мне в личку tg – @Antonio_Ingegnere
Нет мы так не работаем.
В предыдущем примере я затронул самый рискованный и простой способ отказаться от чего-либо – сказать: «мы так не работаем». Хотят вашу команду засунуть в лютый стафог – мы так не работаем; хотят внедрить непонятные решения – мы так не работаем. Сказали, отказались, всё по красоте за исключением одной маленькой детали – контракт и деньги вы скорее всего потеряете. Но в моём опыте был успешный случай, когда мы сказали, что так не работаем, но контракт с нами не расторгли. И так продолжение предыдущего #CaseStudy.
Ситуация: аутсорс проект делается длительное время (30+ человек), нет сорванных релизов всё вовремя и в рамках бюджета. И словно гром среди ясного небу - уходит руководитель продукта (представитель со стороны заказчика), уведомление за 2 недели и увольнение. Нанимают другого и у проекта и команды начинаются проблемы:
🤦 Новый руководитель продукта упарывается в микроменеджмент – любой чих в бэклоге должен быть с ним согласован. Основное отличие от предыдущего продуктового менеджера – раньше давалось общее направление развития продукта плюс необходимые знания в рамках бизнес домена, описание и реализация были на стороне бизнес-аналитиков и команды разработки.
🤦 Начинается хаотичное изменение продукта – был намечен долгосрочный план развития, который выкидывают на свалку, но нового не предоставляют.
🤦 Требования меняются по несколько раз – формализовали требования, реализовали их в коде и это неправильно, переделывайте.
Промежуточный итог.
🤔 Коммуникация становится неэффективной между бизнес-аналитиками и руководителем продукта – команда в Европе, менеджер продукта в US. Пересечение всего несколько часов в день, но из-за желания микроменеджмента объём создаваемых сторей падает, на ревью затрачивается много времени.
🤔 У меня есть правило – все стори должны быть утверждены руководителем продукта. После нескольких переделок и из-за отсутствия плана развития новые стори не утверждаются и копится большой бэклог, команда в разработку может взять крохи.
🤔 И результатом всего этого стала демотивация команды – всё по классике.
Как решали.
Т.к. я выступаю за сознательный менеджмент мы проанализировали ситуацию и пришли к таким выводам:
💡 Новый руководитель продукта до этого работал в основном с Индией, работа же с сотрудниками из Восточной Европы отличается весьма сильно. Стало понятно его желание микроменеджмента.
💡 Отсутствие плана развития и пустой бэклог – следствие непонимания существующего продукта и как оказалось слабых знаний доменной области.
💡 Неутверждённые стори – нежелание брать на себя ответственность и следовать имеющимся процедурам.
Итак, первый подход:
😎 Было проведено несколько сессий, где ненавязчиво и в деталях рассказали про продукт и план развития. Итогом стало то, что достали предыдущий план из небытия, объявили его новым, новым, совершенным и ура.
😎 Отсутствие знаний доменной области – проблема более сложная, но и она решаема. К сожалению, нет способа быстро обучить доменной области особенно когда нет и особого стремления её изучать. Поэтому мы расширили команду бизнес-аналитиков, добавили менее опытных и для матёрого костяка сместили немного фокус на проработку сторей в рамках доменной области.
🤔 Микроменеджмент попытались решить через укрепление сотрудничества и мягкое обучение о том, как работать с ребятами из Восточной Европы. Не взлетело, слишком въелся подход на основании опыта с Индией.
Стало легче, но проблемы остались: микроменеджмент и неутверждённый бэклог не хотели решаться. И вот дальше настало время сказать: «мы так не работаем». Но сделали мы это правильно:
😎 На еженедельных митингах со спонсором проекта мы отобразили падение скорости работы команды (работа велась по SCRUM, поэтому velocity метрика в помощь).
😎 Провели анализ причин и выяснили (хотя и так об этом знали), что у нас большой объём неутверждённых сторей. Поэтому ввели ещё одну метрику для еженедельных митингов - созданные и утверждённые стори в разрезе недели.
В предыдущем примере я затронул самый рискованный и простой способ отказаться от чего-либо – сказать: «мы так не работаем». Хотят вашу команду засунуть в лютый стафог – мы так не работаем; хотят внедрить непонятные решения – мы так не работаем. Сказали, отказались, всё по красоте за исключением одной маленькой детали – контракт и деньги вы скорее всего потеряете. Но в моём опыте был успешный случай, когда мы сказали, что так не работаем, но контракт с нами не расторгли. И так продолжение предыдущего #CaseStudy.
Ситуация: аутсорс проект делается длительное время (30+ человек), нет сорванных релизов всё вовремя и в рамках бюджета. И словно гром среди ясного небу - уходит руководитель продукта (представитель со стороны заказчика), уведомление за 2 недели и увольнение. Нанимают другого и у проекта и команды начинаются проблемы:
🤦 Новый руководитель продукта упарывается в микроменеджмент – любой чих в бэклоге должен быть с ним согласован. Основное отличие от предыдущего продуктового менеджера – раньше давалось общее направление развития продукта плюс необходимые знания в рамках бизнес домена, описание и реализация были на стороне бизнес-аналитиков и команды разработки.
🤦 Начинается хаотичное изменение продукта – был намечен долгосрочный план развития, который выкидывают на свалку, но нового не предоставляют.
🤦 Требования меняются по несколько раз – формализовали требования, реализовали их в коде и это неправильно, переделывайте.
Промежуточный итог.
🤔 Коммуникация становится неэффективной между бизнес-аналитиками и руководителем продукта – команда в Европе, менеджер продукта в US. Пересечение всего несколько часов в день, но из-за желания микроменеджмента объём создаваемых сторей падает, на ревью затрачивается много времени.
🤔 У меня есть правило – все стори должны быть утверждены руководителем продукта. После нескольких переделок и из-за отсутствия плана развития новые стори не утверждаются и копится большой бэклог, команда в разработку может взять крохи.
🤔 И результатом всего этого стала демотивация команды – всё по классике.
Как решали.
Т.к. я выступаю за сознательный менеджмент мы проанализировали ситуацию и пришли к таким выводам:
💡 Новый руководитель продукта до этого работал в основном с Индией, работа же с сотрудниками из Восточной Европы отличается весьма сильно. Стало понятно его желание микроменеджмента.
💡 Отсутствие плана развития и пустой бэклог – следствие непонимания существующего продукта и как оказалось слабых знаний доменной области.
💡 Неутверждённые стори – нежелание брать на себя ответственность и следовать имеющимся процедурам.
Итак, первый подход:
😎 Было проведено несколько сессий, где ненавязчиво и в деталях рассказали про продукт и план развития. Итогом стало то, что достали предыдущий план из небытия, объявили его новым, новым, совершенным и ура.
😎 Отсутствие знаний доменной области – проблема более сложная, но и она решаема. К сожалению, нет способа быстро обучить доменной области особенно когда нет и особого стремления её изучать. Поэтому мы расширили команду бизнес-аналитиков, добавили менее опытных и для матёрого костяка сместили немного фокус на проработку сторей в рамках доменной области.
🤔 Микроменеджмент попытались решить через укрепление сотрудничества и мягкое обучение о том, как работать с ребятами из Восточной Европы. Не взлетело, слишком въелся подход на основании опыта с Индией.
Стало легче, но проблемы остались: микроменеджмент и неутверждённый бэклог не хотели решаться. И вот дальше настало время сказать: «мы так не работаем». Но сделали мы это правильно:
😎 На еженедельных митингах со спонсором проекта мы отобразили падение скорости работы команды (работа велась по SCRUM, поэтому velocity метрика в помощь).
😎 Провели анализ причин и выяснили (хотя и так об этом знали), что у нас большой объём неутверждённых сторей. Поэтому ввели ещё одну метрику для еженедельных митингов - созданные и утверждённые стори в разрезе недели.
