Нет мы так не работаем.
В предыдущем примере я затронул самый рискованный и простой способ отказаться от чего-либо – сказать: «мы так не работаем». Хотят вашу команду засунуть в лютый стафог – мы так не работаем; хотят внедрить непонятные решения – мы так не работаем. Сказали, отказались, всё по красоте за исключением одной маленькой детали – контракт и деньги вы скорее всего потеряете. Но в моём опыте был успешный случай, когда мы сказали, что так не работаем, но контракт с нами не расторгли. И так продолжение предыдущего #CaseStudy.
Ситуация: аутсорс проект делается длительное время (30+ человек), нет сорванных релизов всё вовремя и в рамках бюджета. И словно гром среди ясного небу - уходит руководитель продукта (представитель со стороны заказчика), уведомление за 2 недели и увольнение. Нанимают другого и у проекта и команды начинаются проблемы:
🤦 Новый руководитель продукта упарывается в микроменеджмент – любой чих в бэклоге должен быть с ним согласован. Основное отличие от предыдущего продуктового менеджера – раньше давалось общее направление развития продукта плюс необходимые знания в рамках бизнес домена, описание и реализация были на стороне бизнес-аналитиков и команды разработки.
🤦 Начинается хаотичное изменение продукта – был намечен долгосрочный план развития, который выкидывают на свалку, но нового не предоставляют.
🤦 Требования меняются по несколько раз – формализовали требования, реализовали их в коде и это неправильно, переделывайте.
Промежуточный итог.
🤔 Коммуникация становится неэффективной между бизнес-аналитиками и руководителем продукта – команда в Европе, менеджер продукта в US. Пересечение всего несколько часов в день, но из-за желания микроменеджмента объём создаваемых сторей падает, на ревью затрачивается много времени.
🤔 У меня есть правило – все стори должны быть утверждены руководителем продукта. После нескольких переделок и из-за отсутствия плана развития новые стори не утверждаются и копится большой бэклог, команда в разработку может взять крохи.
🤔 И результатом всего этого стала демотивация команды – всё по классике.
Как решали.
Т.к. я выступаю за сознательный менеджмент мы проанализировали ситуацию и пришли к таким выводам:
💡 Новый руководитель продукта до этого работал в основном с Индией, работа же с сотрудниками из Восточной Европы отличается весьма сильно. Стало понятно его желание микроменеджмента.
💡 Отсутствие плана развития и пустой бэклог – следствие непонимания существующего продукта и как оказалось слабых знаний доменной области.
💡 Неутверждённые стори – нежелание брать на себя ответственность и следовать имеющимся процедурам.
Итак, первый подход:
😎 Было проведено несколько сессий, где ненавязчиво и в деталях рассказали про продукт и план развития. Итогом стало то, что достали предыдущий план из небытия, объявили его новым, новым, совершенным и ура.
😎 Отсутствие знаний доменной области – проблема более сложная, но и она решаема. К сожалению, нет способа быстро обучить доменной области особенно когда нет и особого стремления её изучать. Поэтому мы расширили команду бизнес-аналитиков, добавили менее опытных и для матёрого костяка сместили немного фокус на проработку сторей в рамках доменной области.
🤔 Микроменеджмент попытались решить через укрепление сотрудничества и мягкое обучение о том, как работать с ребятами из Восточной Европы. Не взлетело, слишком въелся подход на основании опыта с Индией.
Стало легче, но проблемы остались: микроменеджмент и неутверждённый бэклог не хотели решаться. И вот дальше настало время сказать: «мы так не работаем». Но сделали мы это правильно:
😎 На еженедельных митингах со спонсором проекта мы отобразили падение скорости работы команды (работа велась по SCRUM, поэтому velocity метрика в помощь).
😎 Провели анализ причин и выяснили (хотя и так об этом знали), что у нас большой объём неутверждённых сторей. Поэтому ввели ещё одну метрику для еженедельных митингов - созданные и утверждённые стори в разрезе недели.
В предыдущем примере я затронул самый рискованный и простой способ отказаться от чего-либо – сказать: «мы так не работаем». Хотят вашу команду засунуть в лютый стафог – мы так не работаем; хотят внедрить непонятные решения – мы так не работаем. Сказали, отказались, всё по красоте за исключением одной маленькой детали – контракт и деньги вы скорее всего потеряете. Но в моём опыте был успешный случай, когда мы сказали, что так не работаем, но контракт с нами не расторгли. И так продолжение предыдущего #CaseStudy.
Ситуация: аутсорс проект делается длительное время (30+ человек), нет сорванных релизов всё вовремя и в рамках бюджета. И словно гром среди ясного небу - уходит руководитель продукта (представитель со стороны заказчика), уведомление за 2 недели и увольнение. Нанимают другого и у проекта и команды начинаются проблемы:
🤦 Новый руководитель продукта упарывается в микроменеджмент – любой чих в бэклоге должен быть с ним согласован. Основное отличие от предыдущего продуктового менеджера – раньше давалось общее направление развития продукта плюс необходимые знания в рамках бизнес домена, описание и реализация были на стороне бизнес-аналитиков и команды разработки.
🤦 Начинается хаотичное изменение продукта – был намечен долгосрочный план развития, который выкидывают на свалку, но нового не предоставляют.
🤦 Требования меняются по несколько раз – формализовали требования, реализовали их в коде и это неправильно, переделывайте.
Промежуточный итог.
🤔 Коммуникация становится неэффективной между бизнес-аналитиками и руководителем продукта – команда в Европе, менеджер продукта в US. Пересечение всего несколько часов в день, но из-за желания микроменеджмента объём создаваемых сторей падает, на ревью затрачивается много времени.
🤔 У меня есть правило – все стори должны быть утверждены руководителем продукта. После нескольких переделок и из-за отсутствия плана развития новые стори не утверждаются и копится большой бэклог, команда в разработку может взять крохи.
🤔 И результатом всего этого стала демотивация команды – всё по классике.
Как решали.
Т.к. я выступаю за сознательный менеджмент мы проанализировали ситуацию и пришли к таким выводам:
💡 Новый руководитель продукта до этого работал в основном с Индией, работа же с сотрудниками из Восточной Европы отличается весьма сильно. Стало понятно его желание микроменеджмента.
💡 Отсутствие плана развития и пустой бэклог – следствие непонимания существующего продукта и как оказалось слабых знаний доменной области.
💡 Неутверждённые стори – нежелание брать на себя ответственность и следовать имеющимся процедурам.
Итак, первый подход:
😎 Было проведено несколько сессий, где ненавязчиво и в деталях рассказали про продукт и план развития. Итогом стало то, что достали предыдущий план из небытия, объявили его новым, новым, совершенным и ура.
😎 Отсутствие знаний доменной области – проблема более сложная, но и она решаема. К сожалению, нет способа быстро обучить доменной области особенно когда нет и особого стремления её изучать. Поэтому мы расширили команду бизнес-аналитиков, добавили менее опытных и для матёрого костяка сместили немного фокус на проработку сторей в рамках доменной области.
🤔 Микроменеджмент попытались решить через укрепление сотрудничества и мягкое обучение о том, как работать с ребятами из Восточной Европы. Не взлетело, слишком въелся подход на основании опыта с Индией.
Стало легче, но проблемы остались: микроменеджмент и неутверждённый бэклог не хотели решаться. И вот дальше настало время сказать: «мы так не работаем». Но сделали мы это правильно:
😎 На еженедельных митингах со спонсором проекта мы отобразили падение скорости работы команды (работа велась по SCRUM, поэтому velocity метрика в помощь).
😎 Провели анализ причин и выяснили (хотя и так об этом знали), что у нас большой объём неутверждённых сторей. Поэтому ввели ещё одну метрику для еженедельных митингов - созданные и утверждённые стори в разрезе недели.
👍4❤🔥1
Итогом стало то, что спонсор проекта вместе с руководителем продукта просмотрели совместно все стори и утверждали их, и так происходило до тех пор, пока состояние бэклога не стабилизировалось. Рецидива не было по одной простой причине – метрика, о которой я говорил, выше показывалась каждую неделю.
Как мы решили проблему микроменеджмента? А никак. 😆 Она рассосалась сама, на нас просто обиделся менеджер продукта и сократил общение до необходимого минимума.
Но всё описанное выше было возможно по ряду причин:
🤘 У нашей команды был огромный кредит доверия со стороны спонсора проекта: выше я указал про успешное долгосрочное сотрудничество.
🤘 Спонсор проекта действительно был заинтересован в развитии продукта, успех продукта позволил ему построить головокружительную карьеру.
🤘 Мы не сказали нет напрямую, мы сказали это через спонсора проекта.
И самый-самый итог руководителя продукта уволили через год. На мой вопрос почему не раньше я получил ответ – контракт, до истечения срока его нельзя было уволить. Первый квартал он адаптировался, полгода показывал, что умеет и ещё квартал подводили итоги.
Как мы решили проблему микроменеджмента? А никак. 😆 Она рассосалась сама, на нас просто обиделся менеджер продукта и сократил общение до необходимого минимума.
Но всё описанное выше было возможно по ряду причин:
🤘 У нашей команды был огромный кредит доверия со стороны спонсора проекта: выше я указал про успешное долгосрочное сотрудничество.
🤘 Спонсор проекта действительно был заинтересован в развитии продукта, успех продукта позволил ему построить головокружительную карьеру.
🤘 Мы не сказали нет напрямую, мы сказали это через спонсора проекта.
И самый-самый итог руководителя продукта уволили через год. На мой вопрос почему не раньше я получил ответ – контракт, до истечения срока его нельзя было уволить. Первый квартал он адаптировался, полгода показывал, что умеет и ещё квартал подводили итоги.
👍5
Микроменеджмент
В комментариях к моей заметке «Нет, мы так не работаем» на хабре затронули интересную тему микроменеджмента. Хорошо или плохо прибегать к микроменеджменту – отдельная тема. В этой заметке я хочу обсудить причины его возникновения.
Выделяют несколько причин:
🤒 Предыдущий опыт – он может быть положительным и отрицательным, например работа с какой-то локацией\командой, где без микроменеджмента никак или же героически было сделано пятьдесят проектов, потому что иначе менеджер не умет и этот проект станет пятьдесят первым героическим.
🤒 Недостаток доверия – просто менеджер не доверяет по различным причинам.
🤒 Страх неудачи – если менеджер боится последствий неудачи, которая негативно скажется на нём (его карьере\компенсации) поэтому он может прибегать к микроменеджменту в попытке получить идеальный результат.
🤒 Необходимость контроля – у некоторых просто от природы есть необходимость вникать во всё – в каждой бочке затычка.
🤒 Плохие менеджерские навыки – неумение в делегацию и слабые лидерские навыки.
🤒 Культура в компании – бывают компании, чрезмерно ориентированные на детали поэтому менеджеры могут прибегать к микроменеджменту, чтобы обеспечить дополнительное давление на сотрудников для достижения значимого результата.
🤒 Чувство личной незащищённости – если управленец чувствует, что кресло под ним шатается, то через микроменеджмент он может пытаться показать свою значимость и важность.
🤒 Проблемы с коммуникацией – моё любимое и классика жанра, если не выстроена правильно коммуникация, менеджер может попробовать восполнить пробел через микроменеджмент.
🤒 Проблемы с производительностью – возникает если у команды исторически была плохая производительность, менеджер может попробовать через микроменеджмент улучшить её.
И тот самый коммент благодаря которому появился этот пост:
Поэтому всё вышеописанное можно суммировать в 2 пункта если смотреть через призму управления персоналом (people management):
👻 Ошибка при найме менеджера.
👻 Ошибка при найме\формировании команды.
Оба этих пункта лечатся через рестафинг (от англ. restaffing – переукомплектование команды) или через обучение.
В комментариях к моей заметке «Нет, мы так не работаем» на хабре затронули интересную тему микроменеджмента. Хорошо или плохо прибегать к микроменеджменту – отдельная тема. В этой заметке я хочу обсудить причины его возникновения.
Выделяют несколько причин:
🤒 Предыдущий опыт – он может быть положительным и отрицательным, например работа с какой-то локацией\командой, где без микроменеджмента никак или же героически было сделано пятьдесят проектов, потому что иначе менеджер не умет и этот проект станет пятьдесят первым героическим.
🤒 Недостаток доверия – просто менеджер не доверяет по различным причинам.
🤒 Страх неудачи – если менеджер боится последствий неудачи, которая негативно скажется на нём (его карьере\компенсации) поэтому он может прибегать к микроменеджменту в попытке получить идеальный результат.
🤒 Необходимость контроля – у некоторых просто от природы есть необходимость вникать во всё – в каждой бочке затычка.
🤒 Плохие менеджерские навыки – неумение в делегацию и слабые лидерские навыки.
🤒 Культура в компании – бывают компании, чрезмерно ориентированные на детали поэтому менеджеры могут прибегать к микроменеджменту, чтобы обеспечить дополнительное давление на сотрудников для достижения значимого результата.
🤒 Чувство личной незащищённости – если управленец чувствует, что кресло под ним шатается, то через микроменеджмент он может пытаться показать свою значимость и важность.
🤒 Проблемы с коммуникацией – моё любимое и классика жанра, если не выстроена правильно коммуникация, менеджер может попробовать восполнить пробел через микроменеджмент.
🤒 Проблемы с производительностью – возникает если у команды исторически была плохая производительность, менеджер может попробовать через микроменеджмент улучшить её.
И тот самый коммент благодаря которому появился этот пост:
AlexunKo:
Микроменеджмент - симптом или внутренней безвыходности (личностной) или внешней (коллективной). Хоть это и плохая практика, иногда только на ней и висят результаты, которых иначе в конкретном раскладе не добьешься. А еще - мало кто занимает честную рефлексивную позицию, позволяющую выйти на хоть какое-то развитие ситуации к лучшему. Мой опыт подсказывает, что критические ошибки найма или формирования команды не исправляются никакими инструментами. А ошибки в процессе работы поддаются исправлению только с теми, для кого этот процесс важен. У Вас остались такие люди?..
Поэтому всё вышеописанное можно суммировать в 2 пункта если смотреть через призму управления персоналом (people management):
👻 Ошибка при найме менеджера.
👻 Ошибка при найме\формировании команды.
Оба этих пункта лечатся через рестафинг (от англ. restaffing – переукомплектование команды) или через обучение.
👍6❤🔥1❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Нам не нужен проектный менеджер. (с)
#минуткаЮмора
#минуткаЮмора
😁4👍1
#мысли_в_слух про необходимость читать контракт
На недавнем собеседовании рекрутер попросила меня рассказать про мою самую большую профессиональную неудачу и какие уроки я извлёк из этого.
Меня позабавила реакция рекрутера на полученный опыт – удивление вперемешку с непониманием, типа реально чел — вот эта вот фигня?
Самый крупный прокол был лет 12–13 назад в начале моей карьеры ПМа. Про сам кейс я расскажу отдельно (на мой блог в телеге подписаны люди, которые знают ситуацию и если буду привирать, накидают мне в панамку). Но выученные уроки я запомнил на всю жизнь и звучат они просто до прозаичности:
Со временем добавилось ещё одно правило:
Почему? Всё просто – в контракте содержится информация о том, что вы должны заказчику и, что не должны, и о том, как глубоко могут наклонить если не сделать то, что должны.
Не раз и не два я отлавливал ситуации, когда заказчики приходили и говорили, что хотят другой космический корабль большего размера или же хотят, чтобы он бороздил не большой театр, а оперу в Париже, но менять сроки и бюджеты не хотят. 🤔 Как раз для таких ситуаций есть change request management (управление запросами на изменение) и если иногда и можно подвинуться при высокой доходности, то при fixed price – зачастую нет. Про кривые коммерческие предложения я вообще молчу:
- У вас в списке предположений (assumptions) есть пометка о том, что мы отвечаем за инфраструктуру – где девопсы?
- Ой ну мы подразумевали, что они должны быть.
- Где они в ресурсном плане?
- 😐
- Где они в бюджете?
- 😐
Как раз менеджерский пофигизм и невнимательность вместе с непониманием как работают те или иные аспекты менеджмента и приводит к сорванным срокам, ночным бдениям, крикам на команду и прочим «радостям» менеджмента, но зато можно рассказать героическую историю «как превозмогли», ведь о том, что не допустили из-за внимательного чтения бумажек никому слушать неинтересно.
На недавнем собеседовании рекрутер попросила меня рассказать про мою самую большую профессиональную неудачу и какие уроки я извлёк из этого.
Меня позабавила реакция рекрутера на полученный опыт – удивление вперемешку с непониманием, типа реально чел — вот эта вот фигня?
Самый крупный прокол был лет 12–13 назад в начале моей карьеры ПМа. Про сам кейс я расскажу отдельно (на мой блог в телеге подписаны люди, которые знают ситуацию и если буду привирать, накидают мне в панамку). Но выученные уроки я запомнил на всю жизнь и звучат они просто до прозаичности:
всегда внимательно читайте контракты и сопутствующие юридические документы.
Со временем добавилось ещё одно правило:
заходя на проект первое, что ты должен попросить – контракт (
сова от англ. SoW – Statement of Work
) и знать его от первой до последней буквы.
Почему? Всё просто – в контракте содержится информация о том, что вы должны заказчику и, что не должны, и о том, как глубоко могут наклонить если не сделать то, что должны.
Не раз и не два я отлавливал ситуации, когда заказчики приходили и говорили, что хотят другой космический корабль большего размера или же хотят, чтобы он бороздил не большой театр, а оперу в Париже, но менять сроки и бюджеты не хотят. 🤔 Как раз для таких ситуаций есть change request management (управление запросами на изменение) и если иногда и можно подвинуться при высокой доходности, то при fixed price – зачастую нет. Про кривые коммерческие предложения я вообще молчу:
- У вас в списке предположений (assumptions) есть пометка о том, что мы отвечаем за инфраструктуру – где девопсы?
- Ой ну мы подразумевали, что они должны быть.
- Где они в ресурсном плане?
- 😐
- Где они в бюджете?
- 😐
Как раз менеджерский пофигизм и невнимательность вместе с непониманием как работают те или иные аспекты менеджмента и приводит к сорванным срокам, ночным бдениям, крикам на команду и прочим «радостям» менеджмента, но зато можно рассказать героическую историю «как превозмогли», ведь о том, что не допустили из-за внимательного чтения бумажек никому слушать неинтересно.
👍8
Нефинансовая мотивация - бэджики
У нас в компании есть специальный портал для выдачи бэджиков сотрудникам - обычный цифровой бэджик: дизайнерская красивая картинка, можно прикрепить небольшой текст и виден отправитель, а так же можно уведомить коллег и прямого менеджера о том, что выдан бэджик, есть страница где отображаются все бэджи сотрудника.
Так вот, если вы думаете, что получить бэджик - детские игры в песочнице и не имеет ничего общего с мотивацией, то вы глубоко ошибаетесь.
Однажды я выдал бэджик своему прямому менеджеру потому, что он сидел со мной пару часов и помогал настраивать отчёты, которые потом мы использовали для улучшения процессов стафинга и найма персонала. Он помог сэкономить моё время и объяснил как работает наш репортинг тул - человек заслужил, чтобы его похвалили. Я зашёл в портал, написал пару строк и нажал кнопку выдать бэдж. Потом во время одного из личных разговоров: “знаешь я получил бэдж от тебя и чёрт возьми это было приятно, я даже не ожидал”, и это директор у которого в подчинении несколько сот человек.
Ещё один случай. Делаем ревью присейла и надо проверить стоимость для индийской и польской локации. Из-за условий сделки мы не можем использовать рейт карту, а только себестоимость. Все финансовые расчёты делались коллегами в США, где на момент событий глубокая ночь. А ревью должно быть закончено срочно и результаты нужны к раннему утру в Америке. Что делать? Просим о помощи коллективный разум - у нас есть чат для экстренных вопросов - где собраны менеджеры из разных стран. Откликается главный ПМ всея Индии, 15 минут и цифры проверены. Выдал вице-президенту бэджик. Получаю сообщение в личку: “спасибо, приятно”.
И казалось бы - это люди на высоких должностях, они высоко забрались по карьерной лестнице и не первый год в бизнесе, но даже им приятно получать такую казалось бы мелочь, знак внимания. Это подтверждает ещё раз - простейшая похвала работает не только с джунами.
Поэтому когда есть возможность и когда заслуженно, похвалите подчинённых, коллег или начальство и сделайте это публично.
Хорошее слово и кошке приятно. (с)
Но это не отменяет финансовую мотивацию, а лишь дополняет её. 😉
У нас в компании есть специальный портал для выдачи бэджиков сотрудникам - обычный цифровой бэджик: дизайнерская красивая картинка, можно прикрепить небольшой текст и виден отправитель, а так же можно уведомить коллег и прямого менеджера о том, что выдан бэджик, есть страница где отображаются все бэджи сотрудника.
Так вот, если вы думаете, что получить бэджик - детские игры в песочнице и не имеет ничего общего с мотивацией, то вы глубоко ошибаетесь.
Однажды я выдал бэджик своему прямому менеджеру потому, что он сидел со мной пару часов и помогал настраивать отчёты, которые потом мы использовали для улучшения процессов стафинга и найма персонала. Он помог сэкономить моё время и объяснил как работает наш репортинг тул - человек заслужил, чтобы его похвалили. Я зашёл в портал, написал пару строк и нажал кнопку выдать бэдж. Потом во время одного из личных разговоров: “знаешь я получил бэдж от тебя и чёрт возьми это было приятно, я даже не ожидал”, и это директор у которого в подчинении несколько сот человек.
Ещё один случай. Делаем ревью присейла и надо проверить стоимость для индийской и польской локации. Из-за условий сделки мы не можем использовать рейт карту, а только себестоимость. Все финансовые расчёты делались коллегами в США, где на момент событий глубокая ночь. А ревью должно быть закончено срочно и результаты нужны к раннему утру в Америке. Что делать? Просим о помощи коллективный разум - у нас есть чат для экстренных вопросов - где собраны менеджеры из разных стран. Откликается главный ПМ всея Индии, 15 минут и цифры проверены. Выдал вице-президенту бэджик. Получаю сообщение в личку: “спасибо, приятно”.
И казалось бы - это люди на высоких должностях, они высоко забрались по карьерной лестнице и не первый год в бизнесе, но даже им приятно получать такую казалось бы мелочь, знак внимания. Это подтверждает ещё раз - простейшая похвала работает не только с джунами.
Поэтому когда есть возможность и когда заслуженно, похвалите подчинённых, коллег или начальство и сделайте это публично.
Хорошее слово и кошке приятно. (с)
Но это не отменяет финансовую мотивацию, а лишь дополняет её. 😉
❤🔥5👍4❤1
Сегодня на собеседовании впервые столкнулся с адекватным объяснением раскраски статуса проекта в зелёный, жёлтый или красный. Зачастую это делается холистически – то есть пальцем в небо и каждый дальтоник красит как хочет, по итогу смотришь в дашборд и пытаешься понять – это зелёный проект или немного сильно розовый.
Использовалось 3 метрики:
🚦маржинальность(доходность\выручка) с пороговым значением 25%
🚦таймлайн (график работ) – отклонение по эпикам в 10%
🚦скоуп (объём работ) – изменение объёма более чем на 5%
Про сами метрики можно долго спорить – нужные ли это метрики или стоит взять что-то другое, как и про трэшхолды (пороговые значения). Но что мне понравилось – это принцип работы данного светофора:
Т.е. они в рамках компании смогли договориться и стандартизировать проектный статус с точки зрения метрик и принципа их использования. Я считаю, что это круто.
А как вы обозначаете статус проекта и понимаете, что он выставлен правильно?
Использовалось 3 метрики:
🚦маржинальность(доходность\выручка) с пороговым значением 25%
🚦таймлайн (график работ) – отклонение по эпикам в 10%
🚦скоуп (объём работ) – изменение объёма более чем на 5%
Про сами метрики можно долго спорить – нужные ли это метрики или стоит взять что-то другое, как и про трэшхолды (пороговые значения). Но что мне понравилось – это принцип работы данного светофора:
если одна из 3-х метрик нарушена, проект красится в жёлтый, если все три ушли прогуляться – в красный и если все три в рамках запланированного показателя – зелёный.
Т.е. они в рамках компании смогли договориться и стандартизировать проектный статус с точки зрения метрик и принципа их использования. Я считаю, что это круто.
А как вы обозначаете статус проекта и понимаете, что он выставлен правильно?
👍5❤🔥2💩1