Марьяна, расскажите, пожалуйста, как добиться от команды выполнения экшн-плана после ретро? Мы проводим ретро, берем небольшой список задач, назначаем ответственных, но потом ничего из обещанного не выполняется.
Часто ретроспектива — это коллективная психотерапия, без экшн-плана и ответственных. Так что ваша ситуация не самая плачевная.
Я вижу несколько причин, почему экшн-план не выполняется:
Причина 1. Ответственных за задачи назначили силой. На вопрос кто готов взять задачу кто-то из команды вместо того, чтобы взять себе — начинает говорить «ну в этом Вася самый большой спец, давайте он возьмет», а остальные поддерживают.
Васе ничего не остается, как взять себе. Я в таких случая торможу этот процесс и обращаюсь к Васе со следующими словами «Вася, ты в праве отказаться и не брать, тут никто не заставляет. Будет хуже, если ты возьмешь и возненавидишь задачу. Мы должны брать только то, во что верим и хотим делать». Тогда каждый берет то, что хочет, а не то, что ему сгрузили.
Когда я так говорю, меня спрашивают «что тогда делать с задачами, которые никому не нравятся»? Если никто их не берет — значит в них никто не видит ценности. Иначе кто-то точно бы взял. У меня много раз такое было на сессиях.
Причина 2. Большинство задач из ретроспективы берет на себя руководитель
Часто руководители команд считают своей ответственностью делать все задачи, которые относятся к процессам, взаимодействию между командами и другими «менеджерскими» задачами. Я считаю это плохой практикой. По модели Эрика Берна руководитель превращается в родителя, а команда в капризного ребенка, которому все не то. Как только команда сама начинает брать ответственность за то, чтобы ей было хорошо — начинаются отношения взрослого-взрослого и отношения в команде и результаты растут.
Причина 3. Руководитель решает, как делать задачу
На ретроспективе член команды берет себе ответственность за задачу. Потом приходит руководитель и начинает рассказывать как ее делать. Прям по шагам, иногда даже микроменеджерит. Человек не чувствует уже своего авторства и ответственности за задачу, начинает динамить. Если решили делегировать — делегируйте и дайте человеку самому решить, как ему делать задачу. Пусть ошибается, это ценнее.
Причина 4. Есть задачи поважнее
Обычно говорят так «задача по описанию этого процесса важная, но к нам пришел клиент и надо срочно сделать это» или «у нас тут важная фича, давай подвинем эту задачу на попозже». После второго такого переноса, ценность и важность остается на словах и в нее никто не верит. Если хотите чтобы задачи из экшн-плана делались — относитесь к ним как не менее важным, чем продуктовые фичи или хотелки клиентов.
Причина 5. Сделаю, когда руки дойдут
Есть важные задачи из бэклога, а задачи из экшн-плана планируются по остаточному принципу. А значит, до них никогда не доходят руки. Чтобы это изменить — включайте эти задачи в спринт или план на неделю всей команды, вносите в беклог, рассказывайте на демо.
#команда, #ретроспектива
Рубрика #ответынавопросы. Новые вопросы принимаю на ip.marianaonysko@gmail.com и отвечаю, когда перегруз мозга и хочется раскачаться.
Часто ретроспектива — это коллективная психотерапия, без экшн-плана и ответственных. Так что ваша ситуация не самая плачевная.
Я вижу несколько причин, почему экшн-план не выполняется:
Причина 1. Ответственных за задачи назначили силой. На вопрос кто готов взять задачу кто-то из команды вместо того, чтобы взять себе — начинает говорить «ну в этом Вася самый большой спец, давайте он возьмет», а остальные поддерживают.
Васе ничего не остается, как взять себе. Я в таких случая торможу этот процесс и обращаюсь к Васе со следующими словами «Вася, ты в праве отказаться и не брать, тут никто не заставляет. Будет хуже, если ты возьмешь и возненавидишь задачу. Мы должны брать только то, во что верим и хотим делать». Тогда каждый берет то, что хочет, а не то, что ему сгрузили.
Когда я так говорю, меня спрашивают «что тогда делать с задачами, которые никому не нравятся»? Если никто их не берет — значит в них никто не видит ценности. Иначе кто-то точно бы взял. У меня много раз такое было на сессиях.
Причина 2. Большинство задач из ретроспективы берет на себя руководитель
Часто руководители команд считают своей ответственностью делать все задачи, которые относятся к процессам, взаимодействию между командами и другими «менеджерскими» задачами. Я считаю это плохой практикой. По модели Эрика Берна руководитель превращается в родителя, а команда в капризного ребенка, которому все не то. Как только команда сама начинает брать ответственность за то, чтобы ей было хорошо — начинаются отношения взрослого-взрослого и отношения в команде и результаты растут.
Причина 3. Руководитель решает, как делать задачу
На ретроспективе член команды берет себе ответственность за задачу. Потом приходит руководитель и начинает рассказывать как ее делать. Прям по шагам, иногда даже микроменеджерит. Человек не чувствует уже своего авторства и ответственности за задачу, начинает динамить. Если решили делегировать — делегируйте и дайте человеку самому решить, как ему делать задачу. Пусть ошибается, это ценнее.
Причина 4. Есть задачи поважнее
Обычно говорят так «задача по описанию этого процесса важная, но к нам пришел клиент и надо срочно сделать это» или «у нас тут важная фича, давай подвинем эту задачу на попозже». После второго такого переноса, ценность и важность остается на словах и в нее никто не верит. Если хотите чтобы задачи из экшн-плана делались — относитесь к ним как не менее важным, чем продуктовые фичи или хотелки клиентов.
Причина 5. Сделаю, когда руки дойдут
Есть важные задачи из бэклога, а задачи из экшн-плана планируются по остаточному принципу. А значит, до них никогда не доходят руки. Чтобы это изменить — включайте эти задачи в спринт или план на неделю всей команды, вносите в беклог, рассказывайте на демо.
#команда, #ретроспектива
Рубрика #ответынавопросы. Новые вопросы принимаю на ip.marianaonysko@gmail.com и отвечаю, когда перегруз мозга и хочется раскачаться.
В октябре ко мне пришли ребята из Островка, чтобы провести ретро для их команд: одну для команды аналитической разработки, вторую для команды аналитиков
Задача была сложной:
— Ретро за год. Мы не помним, что было неделю две назад, не то что бы за год вспомнить. Нужно много времени и энергии, чтобы вытащить все это
— Скепсис команды. Ребята уже проводили сами и инструмент не зашел. Некоторые прямо отказывались участвовать, особенно, когда я сказала, что понадобится часов 7. Слишком жирно ведь для эксперимента.
— Большая команда (16 чел, несколько в онлайне, остальные оффлайн). Кто проводит сессии поймет, как тяжело удерживать фокус и там и там.
Вишенка на торте — вдохновить ребят и наметить план на следующий год, хотя бы на первый квартал. Помним про скепсис 😉
И у нас все получилось. Уже в первом перерыве я видела горящие глаза людей и желание включаться. В этом заслуга с двух сторон, я расскажу об этом в отдельном посте.
Сегодня хочу поделиться отзывом заказчика. Я попросила Романа Богатова, руководителя команды аналитической разработки, рассказать почему он захотел дать еще один шанс ретроспективе и что получил на выходе. Но он кроме этого, решил меня похвалить) А кто я такая, чтобы это скрывать и не похвастаться 😂
Ниже его ответ:
«У нас небольшая команда и работаем вместе уже довольно давно, что способствовало расслаблению процессов, и так мы потеряли качественное ретро на несколько лет. Все свелось к еженедельному обсуждению интересных фактов или больных вопросов после планирования.
Но все это время не покидала мысль, что ретро должно быть другим, помогать видеть какие мы хорошие, сколько всего сделали — мотивировать. Показывать проблемные места в процессах, коммуникациях и других аспектах работы. И самое главное — итеративно влиять на проблемы, делая небольшие улучшения, привлекая всех участников команды.
Это и стало нашей основной целью для проведения ретро за целый год, хотели вернуть ретро в правильном, работающем формате и показать лучший вариант его проведения. Для этого хотелось найти эксперта, который проводил множество ретро в разных компаниях, имел представление о работе команд как вне так и изнутри, видел в стикерах на доске не таски, а людей и команду.
Так мы пришли к Марьяне, как к опытному менеджеру, искренне верящему в полезность ретро. Да, это была самая долгая встреча команды, мы сидели 6 часов в переговорке, конечно с перерывами, вспоминали, обсуждали, рефлекировали, слушали друг друга, видели себя с другой стороны, придумывали.
В итоге, почти все участники отметили, что ретро действительно полезная практика, и ее обязательно стоит вернуть именно в таком виде.
Отдельно хотелось бы отметить, что Марьяна, как совершенно внешний для команды человек с незамыленным взглядом, смогла создать атмосферу доверия, что помогло ей вытащить инсайты, которые сами участники никогда бы не увидели.
В целом, если вы потеряли надежду, не верите в ретро, или только хотите его внедрить, то Марьяна — это человек, к которому безусловно стоит обратиться за консультацией»
#ретроспектива, #команда
Задача была сложной:
— Ретро за год. Мы не помним, что было неделю две назад, не то что бы за год вспомнить. Нужно много времени и энергии, чтобы вытащить все это
— Скепсис команды. Ребята уже проводили сами и инструмент не зашел. Некоторые прямо отказывались участвовать, особенно, когда я сказала, что понадобится часов 7. Слишком жирно ведь для эксперимента.
— Большая команда (16 чел, несколько в онлайне, остальные оффлайн). Кто проводит сессии поймет, как тяжело удерживать фокус и там и там.
Вишенка на торте — вдохновить ребят и наметить план на следующий год, хотя бы на первый квартал. Помним про скепсис 😉
И у нас все получилось. Уже в первом перерыве я видела горящие глаза людей и желание включаться. В этом заслуга с двух сторон, я расскажу об этом в отдельном посте.
Сегодня хочу поделиться отзывом заказчика. Я попросила Романа Богатова, руководителя команды аналитической разработки, рассказать почему он захотел дать еще один шанс ретроспективе и что получил на выходе. Но он кроме этого, решил меня похвалить) А кто я такая, чтобы это скрывать и не похвастаться 😂
Ниже его ответ:
«У нас небольшая команда и работаем вместе уже довольно давно, что способствовало расслаблению процессов, и так мы потеряли качественное ретро на несколько лет. Все свелось к еженедельному обсуждению интересных фактов или больных вопросов после планирования.
Но все это время не покидала мысль, что ретро должно быть другим, помогать видеть какие мы хорошие, сколько всего сделали — мотивировать. Показывать проблемные места в процессах, коммуникациях и других аспектах работы. И самое главное — итеративно влиять на проблемы, делая небольшие улучшения, привлекая всех участников команды.
Это и стало нашей основной целью для проведения ретро за целый год, хотели вернуть ретро в правильном, работающем формате и показать лучший вариант его проведения. Для этого хотелось найти эксперта, который проводил множество ретро в разных компаниях, имел представление о работе команд как вне так и изнутри, видел в стикерах на доске не таски, а людей и команду.
Так мы пришли к Марьяне, как к опытному менеджеру, искренне верящему в полезность ретро. Да, это была самая долгая встреча команды, мы сидели 6 часов в переговорке, конечно с перерывами, вспоминали, обсуждали, рефлекировали, слушали друг друга, видели себя с другой стороны, придумывали.
В итоге, почти все участники отметили, что ретро действительно полезная практика, и ее обязательно стоит вернуть именно в таком виде.
Отдельно хотелось бы отметить, что Марьяна, как совершенно внешний для команды человек с незамыленным взглядом, смогла создать атмосферу доверия, что помогло ей вытащить инсайты, которые сами участники никогда бы не увидели.
В целом, если вы потеряли надежду, не верите в ретро, или только хотите его внедрить, то Марьяна — это человек, к которому безусловно стоит обратиться за консультацией»
#ретроспектива, #команда
Микроменеджерит = не доверяет
У нас уже несколько недель идет обучение на «Стать тимлидом» и Change Basics. Хоть темы разные, есть общие вопросы. Например, про микроменеджмент. Кто-то спрашивает, что делать, если твой руководитель миркоменеджерит. Кто-то — что делать, чтобы команда работала слажено, и не приходилось ее микроменеджерить.
Корень этой проблемы в доверии, точнее в его отсутствии. Если вас микроменеджерят — скорее всего вы для этого руководителя либо «черный ящик»: он не понимает, чем вы занимаетесь (нет прозрачности), не знает чего от вас ждать, где вы споткнётесь и постоянно старается все контролировать. Либо постоянно факапите сроки, не работаете с рисками и ему приходится страховать.
Если вы не знаете, что из этого про вас — я бы прямо пришла к руководителю и сказала, что вижу, что меня микроменеджерят и хочу его/ее избавить от этой проблемы. Потому что страдают две стороны. И в зависимости от того, какая проблема — наметила бы экнш-план.
Но если это не сработает — проблема в способности доверять другим работу. Фактически с делегированием. Что делать, если ваш руководитель не доверяет и не идет на контакт — наверное бежать или подсунуть практику на доверие, которую мы даем в курсе «Самому не проще» . Нужно в столбец выписать имена людей своей команды, а дальше напротив каждого расписывать его сильные и слабые стороны и в каких задачах ты ему доверяешь. По итогу есть понятный список задач и людей, в которых ты доверяешь и перестаешь микроменеджерить. И второй список — с тем, с чем предстоит разобраться еще.
#команда, #самому_не_проще
У нас уже несколько недель идет обучение на «Стать тимлидом» и Change Basics. Хоть темы разные, есть общие вопросы. Например, про микроменеджмент. Кто-то спрашивает, что делать, если твой руководитель миркоменеджерит. Кто-то — что делать, чтобы команда работала слажено, и не приходилось ее микроменеджерить.
Корень этой проблемы в доверии, точнее в его отсутствии. Если вас микроменеджерят — скорее всего вы для этого руководителя либо «черный ящик»: он не понимает, чем вы занимаетесь (нет прозрачности), не знает чего от вас ждать, где вы споткнётесь и постоянно старается все контролировать. Либо постоянно факапите сроки, не работаете с рисками и ему приходится страховать.
Если вы не знаете, что из этого про вас — я бы прямо пришла к руководителю и сказала, что вижу, что меня микроменеджерят и хочу его/ее избавить от этой проблемы. Потому что страдают две стороны. И в зависимости от того, какая проблема — наметила бы экнш-план.
Но если это не сработает — проблема в способности доверять другим работу. Фактически с делегированием. Что делать, если ваш руководитель не доверяет и не идет на контакт — наверное бежать или подсунуть практику на доверие, которую мы даем в курсе «Самому не проще» . Нужно в столбец выписать имена людей своей команды, а дальше напротив каждого расписывать его сильные и слабые стороны и в каких задачах ты ему доверяешь. По итогу есть понятный список задач и людей, в которых ты доверяешь и перестаешь микроменеджерить. И второй список — с тем, с чем предстоит разобраться еще.
#команда, #самому_не_проще
Что из этого может сделать не человек
У нас в Школе сильных программистов совсем небольшая команда. Пару человек в штате и еще несколько работают по проектно. Если сравнить с объёмами продуктов, которые мы делаем — это крайне маленькая команда. Когда я рассказываю это коллегам по рынку — мне не верят. Типа такое возможно, не уронив качество или не выгорев.
Весь секрет в том, что мы с Федей не любим встречи и менеджмент людей. А потому сфокусированы на оптимизации процессов. Грубо говоря, мы постоянно ищем места того, где может справиться машина, а не человек. Логика такая: если что-то будет делать машина — людей в команде будет меньше.
В итоге, мы наблюдаем за процессом и постоянно что-то изобретаем там, где другие школы делают задачи, используя ручной труд.
Например, из больших автоматизиций — отчетность: связка нашей админки с финологом и метабейсом. Я могу посмотреть совершенно разные разрезы, начиная с текущих или прогноза расходов школы, заканчивая оборотом и P&L конкретного курса всего в несколько кликов. На основные сценарии у нас дашборды, а наши эксперты получают каждый день статистику продаж курса.
А из последних маленьких — бот, который затирает сообщения о добавлении новых учеников в чаты курсов, чтобы не было ненужной информации. Мы увидели, что Зоя, наш проджект, затирает эти сообщения вручную и нашли бота, который будет экономить ей время.
В ближайших планах у нас автоматизация процесса оформления закрывающих документов для юриков. Чтобы когда к нам приходил юрик — при оформлении заявки, ему сразу приходили приглашение в диадок на обмен документами, а по завершению курса автоматически формировался пакет закрывашек. Это будет прям большая экономия ресурса. Удобство для Зои и наших клиентов.
Я решила рассказать об этом не для того, чтобы похвалиться, а для того, чтобы если вы тоже думаете, что быть большим начальником с кучей сотрудников — это не ваше, есть варианты. Я сама долго сопротивлялась и отказывалась от роста, потому что выбирала делать все руками, лишь бы не набирать сотрудников. Теперь у меня есть и команда, которую я могу осилить и время для того, чтобы делать руками. То и то мне в кайф.
Можно маленькой душевной командой творить большие дела. Одним из вариантов решения этой задачи — направить свой взор на автоматизацию труда, который может сделать «нечеловек».
#принципы_работы, #команда
У нас в Школе сильных программистов совсем небольшая команда. Пару человек в штате и еще несколько работают по проектно. Если сравнить с объёмами продуктов, которые мы делаем — это крайне маленькая команда. Когда я рассказываю это коллегам по рынку — мне не верят. Типа такое возможно, не уронив качество или не выгорев.
Весь секрет в том, что мы с Федей не любим встречи и менеджмент людей. А потому сфокусированы на оптимизации процессов. Грубо говоря, мы постоянно ищем места того, где может справиться машина, а не человек. Логика такая: если что-то будет делать машина — людей в команде будет меньше.
В итоге, мы наблюдаем за процессом и постоянно что-то изобретаем там, где другие школы делают задачи, используя ручной труд.
Например, из больших автоматизиций — отчетность: связка нашей админки с финологом и метабейсом. Я могу посмотреть совершенно разные разрезы, начиная с текущих или прогноза расходов школы, заканчивая оборотом и P&L конкретного курса всего в несколько кликов. На основные сценарии у нас дашборды, а наши эксперты получают каждый день статистику продаж курса.
А из последних маленьких — бот, который затирает сообщения о добавлении новых учеников в чаты курсов, чтобы не было ненужной информации. Мы увидели, что Зоя, наш проджект, затирает эти сообщения вручную и нашли бота, который будет экономить ей время.
В ближайших планах у нас автоматизация процесса оформления закрывающих документов для юриков. Чтобы когда к нам приходил юрик — при оформлении заявки, ему сразу приходили приглашение в диадок на обмен документами, а по завершению курса автоматически формировался пакет закрывашек. Это будет прям большая экономия ресурса. Удобство для Зои и наших клиентов.
Я решила рассказать об этом не для того, чтобы похвалиться, а для того, чтобы если вы тоже думаете, что быть большим начальником с кучей сотрудников — это не ваше, есть варианты. Я сама долго сопротивлялась и отказывалась от роста, потому что выбирала делать все руками, лишь бы не набирать сотрудников. Теперь у меня есть и команда, которую я могу осилить и время для того, чтобы делать руками. То и то мне в кайф.
Можно маленькой душевной командой творить большие дела. Одним из вариантов решения этой задачи — направить свой взор на автоматизацию труда, который может сделать «нечеловек».
#принципы_работы, #команда
4-дневная рабочая неделя: результаты исследования
В книге «Не сходите с ума на работе» основателей Basecamp, есть глава, в которой они рассказывают о том, что давно практикуют 4-дневную рабочую неделю. Полгода в году сотрудник получает 100% своего оклада, но работает только 4 дня в неделю. Один день он тратит на отдых.
По их словам это делает дает преимущество для двух сторон: сотрудник больше отдыхает и лучше работает, компания становится более устойчивой и не то что не теряет прибыль, а наоборот растит.
Когда я работала в МИФе, мы проводили эксперимент с 4-дневной неделей в течении месяца-двух два года подряд. И эта практика прижилась, насколько мне известно. Как проходил первый, я рассказывала когда-то на канале. В компании Феди и Самата эта практика кажется тоже прижилась.
Но кроме этих трех бизнесов, я больше не встречала компании, которые решились на эту практику. Но недавно узнала, что в прошлом году в Британии 60 компаний стартовали эксперимент с 4-дневной рабочей неделей. Они в течении полугода не работали по пятницам.
Недавно они подвели итоги и оказалочь, что 39% сотрудников испытывает меньше стресса, а 65% сотрудников меньше берут больничный. Прибыль осталась на том же уровне или увеличилась. На качественном уровне: уровень счастья возрос, усталость снизилась, люди начали заниматься больше спортом и своими хобби.
Если я правильно поняла, большинство после сохранили эту практику на постоянной основе, а авторы исследования хотят лоббировать ее правительству, чтобы 4-дневная рабочей неделе была урегулирована на законодательном уровне, а не только на усмотрения работодателя.
Я решила рассказать об этом в канале, потому что верю, что за 4-дневной рабочей неделе будущее, а компании с которыми общаюсь — вроде хотят, но сомневаются, и боятся уйти в минус по прибыли. Может с результатами исследования вам станет проще принять решение.
Для дотошных: ссылка на само исследование
#команда
В книге «Не сходите с ума на работе» основателей Basecamp, есть глава, в которой они рассказывают о том, что давно практикуют 4-дневную рабочую неделю. Полгода в году сотрудник получает 100% своего оклада, но работает только 4 дня в неделю. Один день он тратит на отдых.
По их словам это делает дает преимущество для двух сторон: сотрудник больше отдыхает и лучше работает, компания становится более устойчивой и не то что не теряет прибыль, а наоборот растит.
Когда я работала в МИФе, мы проводили эксперимент с 4-дневной неделей в течении месяца-двух два года подряд. И эта практика прижилась, насколько мне известно. Как проходил первый, я рассказывала когда-то на канале. В компании Феди и Самата эта практика кажется тоже прижилась.
Но кроме этих трех бизнесов, я больше не встречала компании, которые решились на эту практику. Но недавно узнала, что в прошлом году в Британии 60 компаний стартовали эксперимент с 4-дневной рабочей неделей. Они в течении полугода не работали по пятницам.
Недавно они подвели итоги и оказалочь, что 39% сотрудников испытывает меньше стресса, а 65% сотрудников меньше берут больничный. Прибыль осталась на том же уровне или увеличилась. На качественном уровне: уровень счастья возрос, усталость снизилась, люди начали заниматься больше спортом и своими хобби.
Если я правильно поняла, большинство после сохранили эту практику на постоянной основе, а авторы исследования хотят лоббировать ее правительству, чтобы 4-дневная рабочей неделе была урегулирована на законодательном уровне, а не только на усмотрения работодателя.
Я решила рассказать об этом в канале, потому что верю, что за 4-дневной рабочей неделе будущее, а компании с которыми общаюсь — вроде хотят, но сомневаются, и боятся уйти в минус по прибыли. Может с результатами исследования вам станет проще принять решение.
Для дотошных: ссылка на само исследование
#команда
«Нам не доверяет топ-менеджмент»
В комментариях к посту Феди задали вопрос, на который мне очень хочется ответить отдельным постом. Звучит так: «Есть способ бороться с недоверием к людям со стороны топ-менеджмента? В компании куча системных проблем из-за этого.»
Эту ситуацию я наблюдала много раз: когда сама работала в найме и от своих клиентов. В моем кейсе чаще всего это связь IT-отдела и бизнеса. Выглядит это так: бизнес постоянно дрючит разработку о сроках, пихает кучу фичей, а разработка не хочет делать эти фичи, не может адекватно оценивать сроки, потому что это сложно и вообще куча техдолга, который надо рефакторить. Получается замкнутый круг.
На самом деле, корень этой проблемы в том, что команда разработки и топ-менеджмент находятся на разных уровнях зрелости, если опираться на Maturity model. Разработка на начальном — она изолируется и хочет просто писать код, экспериментировать с технологиями и чтобы ее не трогали. Тем более не донимали всякими разговорами о деньгах. Топ-менеджмент где-то повыше — на третьем или четвертом уровне, где оперируют терминами синергии, коллаборации и единства.
Пока IT-команда не поднимется хотя бы на уровень выше, а топ-менеджмент не спустится пониже — разговор будет сложно вести. И никакие дни открытых дверей в IT-отделе в надежде показать прозрачность, как я видела в некоторых команда, к сожалению не помогут. Потому что разговор происходит на разных уровнях: топ-менеджмент по прежнему считает IT дорогим отделом, который остается для него черным ящиком, а IT страдает, что им постоянно нужно что-то доказывать.
Что делать? Начать говорить о том, что непонятно и что важно. Например, бизнесу обычно важна предсказуемость и стабильность. Чтобы фичи выходили в срок, а сайт не падал каждый день. И разбирать почему так не происходит, например потому что накопился техдолг и поэтому мы не можем нормально оценить задачу, слишком много неизвестности.
А потом приходить к решениям, которые устроят две стороны. Стараться прорабатывать соблазны в духе «давайте остановим разработку новых фичей на полгода и будем чинить техдолг». Нет, это утопия. Во-первых не почините, во-вторых — бизнес может умереть за это время. Важно чтобы эти решения были в итоге реализованы, иначе еще и доверие потеряется.
#коммуникации, #команда
В комментариях к посту Феди задали вопрос, на который мне очень хочется ответить отдельным постом. Звучит так: «Есть способ бороться с недоверием к людям со стороны топ-менеджмента? В компании куча системных проблем из-за этого.»
Эту ситуацию я наблюдала много раз: когда сама работала в найме и от своих клиентов. В моем кейсе чаще всего это связь IT-отдела и бизнеса. Выглядит это так: бизнес постоянно дрючит разработку о сроках, пихает кучу фичей, а разработка не хочет делать эти фичи, не может адекватно оценивать сроки, потому что это сложно и вообще куча техдолга, который надо рефакторить. Получается замкнутый круг.
На самом деле, корень этой проблемы в том, что команда разработки и топ-менеджмент находятся на разных уровнях зрелости, если опираться на Maturity model. Разработка на начальном — она изолируется и хочет просто писать код, экспериментировать с технологиями и чтобы ее не трогали. Тем более не донимали всякими разговорами о деньгах. Топ-менеджмент где-то повыше — на третьем или четвертом уровне, где оперируют терминами синергии, коллаборации и единства.
Пока IT-команда не поднимется хотя бы на уровень выше, а топ-менеджмент не спустится пониже — разговор будет сложно вести. И никакие дни открытых дверей в IT-отделе в надежде показать прозрачность, как я видела в некоторых команда, к сожалению не помогут. Потому что разговор происходит на разных уровнях: топ-менеджмент по прежнему считает IT дорогим отделом, который остается для него черным ящиком, а IT страдает, что им постоянно нужно что-то доказывать.
Что делать? Начать говорить о том, что непонятно и что важно. Например, бизнесу обычно важна предсказуемость и стабильность. Чтобы фичи выходили в срок, а сайт не падал каждый день. И разбирать почему так не происходит, например потому что накопился техдолг и поэтому мы не можем нормально оценить задачу, слишком много неизвестности.
А потом приходить к решениям, которые устроят две стороны. Стараться прорабатывать соблазны в духе «давайте остановим разработку новых фичей на полгода и будем чинить техдолг». Нет, это утопия. Во-первых не почините, во-вторых — бизнес может умереть за это время. Важно чтобы эти решения были в итоге реализованы, иначе еще и доверие потеряется.
#коммуникации, #команда
Проговорить ожидания и дать власть
Мы сейчас готовим новый курс с Антоном Давыдовым. Уроки запланировали в формате лонгридов. Курс хардовый, писать его очень тяжело.
Обычно мы с Федей редактируем все тексты, но в этот раз решили привлечь профессионального редактора, потому что знаем, что с его помощью тексты станут круче и понятнее. Это стало особенно важным в этом курсе из-за сложности и объема информации, которую нужно переварить. Редактором выступил Тимур Зарудный.
Тимур с Антоном начали работать. У них случился хороший тандем, но результатом мы с Федей были недовольны. Вроде тексты ок, но прочитать их было сложно. Ты начинаешь читать и мозги закипают. Как будто бы Тимур меньше вникает в смыслы и больше работает с формой того, что есть. Антон же как будто попадает в ловушку, когда эксперт хочет в один курс засунуть все что он знает (что в общем-то нормально).
В итоге у нас получаются портянки по 80-90 тыс знаков, которые сложно воспринимать. И даже мы с Федей, заинтересованные и с высокой мотивацией, не можем осилить. Как тогда осилят ученики?!
Я в какой-то момент подумала, что может надо сделать в формате видео, мол смотреть проще. Но потом поняла, что это одно и тоже — работа с формой, а надо со смыслами. Еще мы думали, что может дело в том, что редактирует не Федя, а Тимур — у него же нет знаний в предметной области. Типа надо либо самому, либо получится фигня.
Но у меня было четкое убеждение, что редактор способен влезать в смыслы и делать классные тексты. Тем более, что Тимур талантливый редактор, я обожаю его тексты и знаю, что он может говорить понятно на разные темы.
Тогда я задумалась, как мы ставили задачу и наделили ли редактора властью. Оказалось, что сказали «редачь тексты, чтобы хорошо читалось».
Вроде понятно, а вроде не очень то и прозрачно. Мы даже не проговорили кейсы в духе «А можно ли спорить с экспертом?», «А мне только тексты причесывать, или в смыслы влезать?» Вот он и редачил и считал автора главным. Если автор уходил в сторону — значит так и должно быть. Хотя автор может это делать неосознанно.
Так мы решили собрать встречу, чтобы разобраться. Вот что выяснилось:
1/ Плохо поставили задачу. Тимуру было непонятно, во что ему можно влезать, а куда нельзя. Да и тупо чего мы ждем, какой продукт хотим, что должен испытывать ученик, читая материалы курса. Регулярно проскакивали фразы «ну я не совсем понимаю что можно отрезать, а что нет», «есть места где мне понятно, а есть где нет».
2/ Не дали Тимуру власть. Я знаю, что Тимур офигенно во всем может разобраться и у него есть преимущество перед Антоном, у которого замылен глаз из-за того, что много внутри контента. Тимур смотрит на все глазами ученика, если он поймет материал — любой поймет. И я сказала «Тимур, ты можешь задавать вопросы, если тебе непонятно. Писать когда чувствуешь, что мысль оборвалась или ушла куда-то в сторону. И это тебя сбило». Я дала Тимуру власть.
3/ Убрали сомнения по поводу смыслов. Мы договорились о том, что Федя с Антоном будут проверять смыслы, чтобы случайно не потерять важное. Это увеличит время, но зато тексты можно будет намазывать на хлеб и наслаждаться.
Мы разошлись и через неделю получили лонгрид совершенно другого качества. Теперь мы довольны.
А могли бы просто посчитать это неудачным экспериментом:
— отказаться от коллаба с Тимуром и делать все самому;
— закрыть проект и не создать новый курс с Антоном, который ждут наши ученики;
— перейти в формат видео или сохранить текущий вид, через который не продрется наш ученик.
А надо было всего лишь обсудить задачу, проговорить ожидания и дать людям власть делать свою работу. Но главное, что вовремя все починили и курсу быть в ближайшее время.
#управление_проектами, #команда
Мы сейчас готовим новый курс с Антоном Давыдовым. Уроки запланировали в формате лонгридов. Курс хардовый, писать его очень тяжело.
Обычно мы с Федей редактируем все тексты, но в этот раз решили привлечь профессионального редактора, потому что знаем, что с его помощью тексты станут круче и понятнее. Это стало особенно важным в этом курсе из-за сложности и объема информации, которую нужно переварить. Редактором выступил Тимур Зарудный.
Тимур с Антоном начали работать. У них случился хороший тандем, но результатом мы с Федей были недовольны. Вроде тексты ок, но прочитать их было сложно. Ты начинаешь читать и мозги закипают. Как будто бы Тимур меньше вникает в смыслы и больше работает с формой того, что есть. Антон же как будто попадает в ловушку, когда эксперт хочет в один курс засунуть все что он знает (что в общем-то нормально).
В итоге у нас получаются портянки по 80-90 тыс знаков, которые сложно воспринимать. И даже мы с Федей, заинтересованные и с высокой мотивацией, не можем осилить. Как тогда осилят ученики?!
Я в какой-то момент подумала, что может надо сделать в формате видео, мол смотреть проще. Но потом поняла, что это одно и тоже — работа с формой, а надо со смыслами. Еще мы думали, что может дело в том, что редактирует не Федя, а Тимур — у него же нет знаний в предметной области. Типа надо либо самому, либо получится фигня.
Но у меня было четкое убеждение, что редактор способен влезать в смыслы и делать классные тексты. Тем более, что Тимур талантливый редактор, я обожаю его тексты и знаю, что он может говорить понятно на разные темы.
Тогда я задумалась, как мы ставили задачу и наделили ли редактора властью. Оказалось, что сказали «редачь тексты, чтобы хорошо читалось».
Вроде понятно, а вроде не очень то и прозрачно. Мы даже не проговорили кейсы в духе «А можно ли спорить с экспертом?», «А мне только тексты причесывать, или в смыслы влезать?» Вот он и редачил и считал автора главным. Если автор уходил в сторону — значит так и должно быть. Хотя автор может это делать неосознанно.
Так мы решили собрать встречу, чтобы разобраться. Вот что выяснилось:
1/ Плохо поставили задачу. Тимуру было непонятно, во что ему можно влезать, а куда нельзя. Да и тупо чего мы ждем, какой продукт хотим, что должен испытывать ученик, читая материалы курса. Регулярно проскакивали фразы «ну я не совсем понимаю что можно отрезать, а что нет», «есть места где мне понятно, а есть где нет».
2/ Не дали Тимуру власть. Я знаю, что Тимур офигенно во всем может разобраться и у него есть преимущество перед Антоном, у которого замылен глаз из-за того, что много внутри контента. Тимур смотрит на все глазами ученика, если он поймет материал — любой поймет. И я сказала «Тимур, ты можешь задавать вопросы, если тебе непонятно. Писать когда чувствуешь, что мысль оборвалась или ушла куда-то в сторону. И это тебя сбило». Я дала Тимуру власть.
3/ Убрали сомнения по поводу смыслов. Мы договорились о том, что Федя с Антоном будут проверять смыслы, чтобы случайно не потерять важное. Это увеличит время, но зато тексты можно будет намазывать на хлеб и наслаждаться.
Мы разошлись и через неделю получили лонгрид совершенно другого качества. Теперь мы довольны.
А могли бы просто посчитать это неудачным экспериментом:
— отказаться от коллаба с Тимуром и делать все самому;
— закрыть проект и не создать новый курс с Антоном, который ждут наши ученики;
— перейти в формат видео или сохранить текущий вид, через который не продрется наш ученик.
А надо было всего лишь обсудить задачу, проговорить ожидания и дать людям власть делать свою работу. Но главное, что вовремя все починили и курсу быть в ближайшее время.
#управление_проектами, #команда
Убирать препятствия вместо того, чтобы пинать
Много лет назад в Бюро Горбунова заговорили о том, что менеджеры не нужны. Я помню, что искренне не понимала, почему так хейтят менеджеров проектов, они же помогают команде, зачем их убирать.
Но потом я поняла, в чем ловушка и что делать, если вы менеджер и вас хейтят или к вашей команде прикрепили менеджера, от которого вы мечтаете избавиться.
По классике ключевая задача менеджера проектов — привести команду к цели (выполненный проект) в срок, в достаточном качестве. Многие воспринимают это буквально и начинают пинать: «у нас дедлайн, когда задеплоиете фичу», «сроки горят, а у нас ещё не написан текст» и т.д. Как будто мы дети, которые не ориентируются в сроках. Это не только не помогает, а еще и создает дополнительное напряжение. Обычно задержка со сроками возникает из-за какой-то сложности, а не потому что забыл. Обычно так, если это команда взрослых людей, которые не только ради зарплаты работают. Вишенкой на торте будет еще микроменеджмент «ты чем занимался? Задача до сих пор не готова»
Но, представьте, что менеджер вместо того, чтобы ныть «сроки, сроки» скажет: «Слушай, я вижу что ты не успеваешь со сроками, расскажи в чем сложность. Вдруг я смогу кого-то привлечь на помощь?». Чувствуется поддержка? Задавая этот вопрос, я часто помогала человеку выйти из тупика и получить задачу в срок.
Или еще может быть так: «Слушай, вижу тебе надо текст для промостраницы написать, и ты не успеваешь. Я накидала рыбу страницы, как вижу структуру и ключевые мысли в тексте. Вдруг тебе поможет». В этом случае, я просто сделала какую-то говняшку, и тем самым помогла коллеге побороть страх чистого листа. Потому что всегда начатое переделать сильно проще, чем с нуля. Или как минимум завела документ и что-то начала, тем самым создала среду для работы и сэкономила коллеге время.
Вообщем, ключевая задача менеджера проектов — не пинать, а убирать препятствия. Только в этом случае он помогает, а не мешает команде двигаться вперед. Если вы менеджер — посмотрите в эту сторону, если у вас в команде пинатель — дайте обратную связь, и если не сработает — гоните. Такой товарищ в долгосрочной перспективе скорее тащит назад, чем двигает вперед.
#управление_проектами, #команда
Много лет назад в Бюро Горбунова заговорили о том, что менеджеры не нужны. Я помню, что искренне не понимала, почему так хейтят менеджеров проектов, они же помогают команде, зачем их убирать.
Но потом я поняла, в чем ловушка и что делать, если вы менеджер и вас хейтят или к вашей команде прикрепили менеджера, от которого вы мечтаете избавиться.
По классике ключевая задача менеджера проектов — привести команду к цели (выполненный проект) в срок, в достаточном качестве. Многие воспринимают это буквально и начинают пинать: «у нас дедлайн, когда задеплоиете фичу», «сроки горят, а у нас ещё не написан текст» и т.д. Как будто мы дети, которые не ориентируются в сроках. Это не только не помогает, а еще и создает дополнительное напряжение. Обычно задержка со сроками возникает из-за какой-то сложности, а не потому что забыл. Обычно так, если это команда взрослых людей, которые не только ради зарплаты работают. Вишенкой на торте будет еще микроменеджмент «ты чем занимался? Задача до сих пор не готова»
Но, представьте, что менеджер вместо того, чтобы ныть «сроки, сроки» скажет: «Слушай, я вижу что ты не успеваешь со сроками, расскажи в чем сложность. Вдруг я смогу кого-то привлечь на помощь?». Чувствуется поддержка? Задавая этот вопрос, я часто помогала человеку выйти из тупика и получить задачу в срок.
Или еще может быть так: «Слушай, вижу тебе надо текст для промостраницы написать, и ты не успеваешь. Я накидала рыбу страницы, как вижу структуру и ключевые мысли в тексте. Вдруг тебе поможет». В этом случае, я просто сделала какую-то говняшку, и тем самым помогла коллеге побороть страх чистого листа. Потому что всегда начатое переделать сильно проще, чем с нуля. Или как минимум завела документ и что-то начала, тем самым создала среду для работы и сэкономила коллеге время.
Вообщем, ключевая задача менеджера проектов — не пинать, а убирать препятствия. Только в этом случае он помогает, а не мешает команде двигаться вперед. Если вы менеджер — посмотрите в эту сторону, если у вас в команде пинатель — дайте обратную связь, и если не сработает — гоните. Такой товарищ в долгосрочной перспективе скорее тащит назад, чем двигает вперед.
#управление_проектами, #команда
Проекты-жвачки и ритм
Есть такие проекты, которые никак не запустятся, потому что у них много тягомотины. О них говорят обычно так: «мы вроде все делаем, но чет так долго. Уже 10 раз концепцию поменяли и кажется ненавидим этот проект». Я называю их проектами — жвачками.
Главный признак жвачки — отсутствие ритма. Но ритм — это не о том, есть ли у нас ежедневные стендапы или еженедельные регулярные встречи по проекту. Потому что эти встречи не панацея, можно запускать много всего и без них.
Ключевое в ритме — это то, как команда щелкает задачки. Есть ли чувство тыц-тыц. Когда я думаю об этом — у меня возникает образ того, как работает гоночная команда на пит-стопе. Гонщик подъезжает и есть несколько минут, чтобы привести машину и водителя в порядок. Один колеса меняет, второй масло заливает, третий болты закручивает. За несколько минут творится магия. Если никогда не видели — очень советую посмотреть.
В проектах-жвачках все ровно наоборот: каждый делает свою задачу, но не передает на следующий этап. Никто не думает о том, что будет дальше и как эффективнее сделать. В лучшем случае, менеджер проекта ходит как нянька за всеми и служит этим связующим звеном.
Какие-то части постоянно выпадают и все сыпется из рук. Потому что начинает что-то быть срочным, возникают ошибки и т.д. Или начинается тягомотина из-за того, что команда постоянно отодвигает сроки, потому что не укладывается в обещанные, а менеджера-пинателя никто не слушает.
Иногда жвачка возникает из-за того, что никто не готов принять решение: «давайте сделаем так», начинается обсуждения решения, перемываются ему косточки по 10 раз, но так и не принимается решение. Начинает теряться энергия, появляется скука. И как следствие, хочется закрыть проект или что чаще поменять концепцию. И это топтание на одном месте может длится месяцами, а иногда и годами (я и такие случаи видела).
Когда-то я писала, что ритм в проекте — как пульс в теле. Если следите за ним, не будет ни жвачки, ни выгорания.
#управление_проектами, #команда
Есть такие проекты, которые никак не запустятся, потому что у них много тягомотины. О них говорят обычно так: «мы вроде все делаем, но чет так долго. Уже 10 раз концепцию поменяли и кажется ненавидим этот проект». Я называю их проектами — жвачками.
Главный признак жвачки — отсутствие ритма. Но ритм — это не о том, есть ли у нас ежедневные стендапы или еженедельные регулярные встречи по проекту. Потому что эти встречи не панацея, можно запускать много всего и без них.
Ключевое в ритме — это то, как команда щелкает задачки. Есть ли чувство тыц-тыц. Когда я думаю об этом — у меня возникает образ того, как работает гоночная команда на пит-стопе. Гонщик подъезжает и есть несколько минут, чтобы привести машину и водителя в порядок. Один колеса меняет, второй масло заливает, третий болты закручивает. За несколько минут творится магия. Если никогда не видели — очень советую посмотреть.
В проектах-жвачках все ровно наоборот: каждый делает свою задачу, но не передает на следующий этап. Никто не думает о том, что будет дальше и как эффективнее сделать. В лучшем случае, менеджер проекта ходит как нянька за всеми и служит этим связующим звеном.
Какие-то части постоянно выпадают и все сыпется из рук. Потому что начинает что-то быть срочным, возникают ошибки и т.д. Или начинается тягомотина из-за того, что команда постоянно отодвигает сроки, потому что не укладывается в обещанные, а менеджера-пинателя никто не слушает.
Иногда жвачка возникает из-за того, что никто не готов принять решение: «давайте сделаем так», начинается обсуждения решения, перемываются ему косточки по 10 раз, но так и не принимается решение. Начинает теряться энергия, появляется скука. И как следствие, хочется закрыть проект или что чаще поменять концепцию. И это топтание на одном месте может длится месяцами, а иногда и годами (я и такие случаи видела).
Когда-то я писала, что ритм в проекте — как пульс в теле. Если следите за ним, не будет ни жвачки, ни выгорания.
#управление_проектами, #команда
Сшивка целей
За последние недели мой канал сильно вырос (новые подписчики, добро пожаловать!). Если вы подписались на меня из папки и пока не заглядывали, вот гид по каналу.
Когда-то я мечтала о 10К, но не верила, что это возможно. Оказывается очень даже. Пока у меня ощущение, что я вышла из дома по делам, а когда вернулась — в моем доме случилась большая вечеринка. Вроде домой пришла, а как будто и не к себе. Вообщем, тоже осваиваюсь.
На фоне этих ощущений, захотелось поделиться с вами «сшивкой целей», о которой я узнала от Филиппа Гузенюка лет 5 назад и до сих пор пользуюсь и всем рекомендую.
Сшивка целей — это процедура, которая проводится раз в год и помогает решить следующие кейсы:
1/ Руководителя: команда не вовлечена в задачи/проект или не думает об общих целях компании и, например, хочет пилить свои какие-то фановые задачи, в которых нет денег.
2/ Сотрудника: не понимает как себя применить в компании, или у есть к чему-то интерес к чему-то, но он четко понимает, что это не нужно компании. Например, веб-дизайнер, которому надоело пилить лендосы хочет пойти в моушен-дизайн и развиваться в анимации. Но в текущей роли у него нет такой возможности.
Как происходит сшивка целей?
1/ Каждый сотрудник раз в год пишет свои соображения о том, что у него получилось за этот год и каким он видит следующий, чем конкретно хотел бы заниматься. По классике это сочинение, но я всегда даю выбор: кто-то пишет списком, кто-то делает презу, кто-то рисует майндкарту. На этом этапе очень важно опираться на реальные свои желания и фиксировать их.
2/ Потом назначается встреча, тет-а-тет или командная (в зависимости от отношений в вашей команде), где каждый озвучивает, что написал.
3/ Далее руководитель рассказывает вектор движения компании: куда она пойдет, что в фокусе, какой финансовый план и т.д.
4/ И последний шаг: соединить эти две картинки — вектор компании с вектором сотрудника. Например, дизайнер говорит «хочу моушен-дизайн. При этом вообще не понимаю, как это использовать, ведь у нас нет такой роли». А руководитель знает, что сейчас у компании ставка на соцсети и моушин-дизайн сильно пригодится для создания сторис или рилз. Они могут договориться что часть времени он может помогать соседнему отделу и назначить встречу с его руководителем. И так по каждому пункту. И все фиксируется.
Как итог, появляется вовлеченность, потому что человек делает то, что на самом деле хотел. И никто не увольняется, а работа делается с удовольствием, а не «потому что должен, мне за это заплатили». Плюс в команде появляются новые компетенции.
Дисклеймер. Не всегда сшивка приводит к переходу в другой отдел, это скорее исключение. И не всегда получается соединить две картинки: иногда и правда ничего общего нет, но зато появляется прозрачность и понимание, как мы действуем дальше. Вместо внезапного работал работал, а потом выгорел и ушел.
Если вам эта тема интересна, у Филиппа есть целый бесплатный вебинар с кучей нюансов.
#команда
За последние недели мой канал сильно вырос (новые подписчики, добро пожаловать!). Если вы подписались на меня из папки и пока не заглядывали, вот гид по каналу.
Когда-то я мечтала о 10К, но не верила, что это возможно. Оказывается очень даже. Пока у меня ощущение, что я вышла из дома по делам, а когда вернулась — в моем доме случилась большая вечеринка. Вроде домой пришла, а как будто и не к себе. Вообщем, тоже осваиваюсь.
На фоне этих ощущений, захотелось поделиться с вами «сшивкой целей», о которой я узнала от Филиппа Гузенюка лет 5 назад и до сих пор пользуюсь и всем рекомендую.
Сшивка целей — это процедура, которая проводится раз в год и помогает решить следующие кейсы:
1/ Руководителя: команда не вовлечена в задачи/проект или не думает об общих целях компании и, например, хочет пилить свои какие-то фановые задачи, в которых нет денег.
2/ Сотрудника: не понимает как себя применить в компании, или у есть к чему-то интерес к чему-то, но он четко понимает, что это не нужно компании. Например, веб-дизайнер, которому надоело пилить лендосы хочет пойти в моушен-дизайн и развиваться в анимации. Но в текущей роли у него нет такой возможности.
Как происходит сшивка целей?
1/ Каждый сотрудник раз в год пишет свои соображения о том, что у него получилось за этот год и каким он видит следующий, чем конкретно хотел бы заниматься. По классике это сочинение, но я всегда даю выбор: кто-то пишет списком, кто-то делает презу, кто-то рисует майндкарту. На этом этапе очень важно опираться на реальные свои желания и фиксировать их.
2/ Потом назначается встреча, тет-а-тет или командная (в зависимости от отношений в вашей команде), где каждый озвучивает, что написал.
3/ Далее руководитель рассказывает вектор движения компании: куда она пойдет, что в фокусе, какой финансовый план и т.д.
4/ И последний шаг: соединить эти две картинки — вектор компании с вектором сотрудника. Например, дизайнер говорит «хочу моушен-дизайн. При этом вообще не понимаю, как это использовать, ведь у нас нет такой роли». А руководитель знает, что сейчас у компании ставка на соцсети и моушин-дизайн сильно пригодится для создания сторис или рилз. Они могут договориться что часть времени он может помогать соседнему отделу и назначить встречу с его руководителем. И так по каждому пункту. И все фиксируется.
Как итог, появляется вовлеченность, потому что человек делает то, что на самом деле хотел. И никто не увольняется, а работа делается с удовольствием, а не «потому что должен, мне за это заплатили». Плюс в команде появляются новые компетенции.
Дисклеймер. Не всегда сшивка приводит к переходу в другой отдел, это скорее исключение. И не всегда получается соединить две картинки: иногда и правда ничего общего нет, но зато появляется прозрачность и понимание, как мы действуем дальше. Вместо внезапного работал работал, а потом выгорел и ушел.
Если вам эта тема интересна, у Филиппа есть целый бесплатный вебинар с кучей нюансов.
#команда
Вы не мама и не папа своей команде
Ко мне часто на консультации приходят руководители, которые очень устали от руководства своей командой. Некоторые настолько, что решают вообще уходить из этой роли.
Когда мы начинаем разбирать эту историю, оказывается типичная ситуация: руководитель хочет быть хорошим для команды и всячески ее оберегает от плохого руководителя сверху:
— «Ребята, не перерабатывайте, возьмите выходной»
— «Давай мы разберем твои задачи, а то я вижу, что ты очень много работаешь, может я что-то себе возьму или отдам другому»
—«Ой-ой, как мне жаль, что вам эти мудацкие отчеты приходится заполнять. Давайте может я их буду делать, вам же не хочется».
А с другой стороны, несет ответственность за команду перед этим же руководителем выше. Ведь, планы, цели никто не отменял. Получается между двух огней: хочется оберегать команду, но и люли только на себя получать не хочется постоянно.
Я в этой ситуации рассказываю о треугольнике Карпама/Берна, в котором есть Преследователь, Спасатель и Жертва. Ваша команда это Жертва, которой хочется пилить фановые фичи, а не чинить все эти баги и заполнять тупые отчеты. Вы Спасатель, который пытается уберечь вас от этого всего, а ваш руководитель — Преследователь.
Суть треугольника состоит в том, что Жертва не может существовать без Спасателя и Преследователя. Как и другая роль не может без других двух. Вообщем, чтобы вы не делали — это будет продолжаться.
Чтобы выйти из этого круга — перестаньте Спасать. Люди, которые подписали договор найма, подписались под эти мудацкие отчеты в конце концов. Они сами взрослые люди и могут справляться с нагрузкой и не надо перерабатывать вместо них.
Они не ваши дети, вы можете подсветить перегрузки, но не решать что делать этим людям. Люди могут сами. Они совершеннолетние и вы вы им не мама и не папа.
#команда
—-
Другие посты о спасательстве:
— Спасательство в чате, о том, как не стоит брать задачу, которая только поступила
— Типы руководителей: преследователи, спасатели, жертвы
— Тренд на собственный фокус: роль спасательства
Ко мне часто на консультации приходят руководители, которые очень устали от руководства своей командой. Некоторые настолько, что решают вообще уходить из этой роли.
Когда мы начинаем разбирать эту историю, оказывается типичная ситуация: руководитель хочет быть хорошим для команды и всячески ее оберегает от плохого руководителя сверху:
— «Ребята, не перерабатывайте, возьмите выходной»
— «Давай мы разберем твои задачи, а то я вижу, что ты очень много работаешь, может я что-то себе возьму или отдам другому»
—«Ой-ой, как мне жаль, что вам эти мудацкие отчеты приходится заполнять. Давайте может я их буду делать, вам же не хочется».
А с другой стороны, несет ответственность за команду перед этим же руководителем выше. Ведь, планы, цели никто не отменял. Получается между двух огней: хочется оберегать команду, но и люли только на себя получать не хочется постоянно.
Я в этой ситуации рассказываю о треугольнике Карпама/Берна, в котором есть Преследователь, Спасатель и Жертва. Ваша команда это Жертва, которой хочется пилить фановые фичи, а не чинить все эти баги и заполнять тупые отчеты. Вы Спасатель, который пытается уберечь вас от этого всего, а ваш руководитель — Преследователь.
Суть треугольника состоит в том, что Жертва не может существовать без Спасателя и Преследователя. Как и другая роль не может без других двух. Вообщем, чтобы вы не делали — это будет продолжаться.
Чтобы выйти из этого круга — перестаньте Спасать. Люди, которые подписали договор найма, подписались под эти мудацкие отчеты в конце концов. Они сами взрослые люди и могут справляться с нагрузкой и не надо перерабатывать вместо них.
Они не ваши дети, вы можете подсветить перегрузки, но не решать что делать этим людям. Люди могут сами. Они совершеннолетние и вы вы им не мама и не папа.
#команда
—-
Другие посты о спасательстве:
— Спасательство в чате, о том, как не стоит брать задачу, которая только поступила
— Типы руководителей: преследователи, спасатели, жертвы
— Тренд на собственный фокус: роль спасательства
Самоуправление это не коллективная ответственность
Когда-то я рассказывала о методе «закрыть сделку», который подсмотрела у б2б-продавцов. Суть его заключается в следующем: вы обсуждаете с командой какие-то варианты решений, но в конце так и не приходите к никакому, встреча заканчивается и вы уходите. И чтобы в следующий раз не выходить на новый круг обсуждения — нужно подтолкнуть команду к принятию решения.
Но в этом посте я не рассказываю о случае, когда вы вроде подталкиваете команду к принятию решения, а решение так и не принимается. По кругу обсуждаете разные варианты и вроде как уже понятное решение, но никто его не озвучивает. А вы, как руководитель, хотите самостоятельную команду и не хотите за нее принимать решение.
Особенно часто такие кейсы встречаются, когда команда еще не сработалась или когда непонятны роли и зоны ответственности. Вроде как принимают решения все, но на самом деле, каждый ждет что кто-то другой примет решение. И вот каждый так думает и решение не принимается. Ответственность размывается. Вообщем, захотели поиграть в самоуправление, но в итоге взяли только вкусную часть из него: типа будем все вместе советоваться и принимать решения.
Но самоуправление — это не коллективная ответственность, как многие считают. Если вы так считаете, я советую почитать книгу «Человек решающий». Там на наглядном примере показывается, что советуются все, но решение в итоге принимает то, кто готов брать на себя ответственность за все последствия. Т.е избранный человек, выслушивает всех, а потом принимает решение.
По прежнему работает самоуправления, т.к у команды может и не быть главного. Но у каждого решения есть главный. Он его принимает и несет ответственность, а остальные ему доверяют.
Вообщем, если видите что начинается подобная жвачка — подсветите этот момент, иначе будете множить коммуникацию. А если никто не готов взять на себя ответственность и принять решение, значит вы зря тратили время на обсуждение задачи. Она не нужна. И это тоже важно осознать и подсветить. Коллеги вам спасибо еще за это скажут.
#коммуникации, #команда, #книги
Когда-то я рассказывала о методе «закрыть сделку», который подсмотрела у б2б-продавцов. Суть его заключается в следующем: вы обсуждаете с командой какие-то варианты решений, но в конце так и не приходите к никакому, встреча заканчивается и вы уходите. И чтобы в следующий раз не выходить на новый круг обсуждения — нужно подтолкнуть команду к принятию решения.
Но в этом посте я не рассказываю о случае, когда вы вроде подталкиваете команду к принятию решения, а решение так и не принимается. По кругу обсуждаете разные варианты и вроде как уже понятное решение, но никто его не озвучивает. А вы, как руководитель, хотите самостоятельную команду и не хотите за нее принимать решение.
Особенно часто такие кейсы встречаются, когда команда еще не сработалась или когда непонятны роли и зоны ответственности. Вроде как принимают решения все, но на самом деле, каждый ждет что кто-то другой примет решение. И вот каждый так думает и решение не принимается. Ответственность размывается. Вообщем, захотели поиграть в самоуправление, но в итоге взяли только вкусную часть из него: типа будем все вместе советоваться и принимать решения.
Но самоуправление — это не коллективная ответственность, как многие считают. Если вы так считаете, я советую почитать книгу «Человек решающий». Там на наглядном примере показывается, что советуются все, но решение в итоге принимает то, кто готов брать на себя ответственность за все последствия. Т.е избранный человек, выслушивает всех, а потом принимает решение.
По прежнему работает самоуправления, т.к у команды может и не быть главного. Но у каждого решения есть главный. Он его принимает и несет ответственность, а остальные ему доверяют.
Вообщем, если видите что начинается подобная жвачка — подсветите этот момент, иначе будете множить коммуникацию. А если никто не готов взять на себя ответственность и принять решение, значит вы зря тратили время на обсуждение задачи. Она не нужна. И это тоже важно осознать и подсветить. Коллеги вам спасибо еще за это скажут.
#коммуникации, #команда, #книги
Зал славы: хвалим себя и других
Кажется, это лучшее, что я придумала для возврата энергии за последние полгода. Сейчас расскажу.
Когда появились функция тредов в телеге, мы решили перевести в них наше комьюнити Сильных программистов. Чтобы был порядок. И одну из веток я назвала «флуд, нытье и что-то еще». Идея была в том, что если создать пространство для всякого нытья, то ребята больше сплотятся. Опиралась на метод «вонючей рыбы», который постоянно практикую и всем советую.
Это работало. А спустя наверное год, я подумала что нытье у нас есть, а радости нет. Но это тоже важная часть, которая сплочает и дает энергию. И тогда я вспомнила о своем «сундучке похвалы», который мне посоветовала моя психолог несколько лет назад, когда я не могла совладать с синдромом самозванца.
«Сундук похвалы» — пространство, куда я должна была складывать все упоминания, когда меня хвалят или когда я чувствую, что горжусь собой. Так у меня появилась сначала папка на компе, а потом закрытый канал в телеге. Я должна была заходить в него каждый раз, когда голос внутреннего самозванца становился настолько громким, что я не могла с ним совладать. Кстати, пользуюсь до сих пор, потому что еще ни разу не подвел.
Вообщем, вспомнив эту идею я добавила в комьюнити ветку «Зал славы: хвалим себя и других». Сначала там молчали, но с каждым появлением нового поста (начинала я с себя: хвалила и себя и других, говорила спасибо), лед потихоньку таял и я видела, что в этой истории большой потенциал. Со временем мы начали добавлять ее в чат каждого курса.
И вот спустя полгода могу сказать, что эта ветка — охренное место возврата энергии. Люди хвалят и благодарят друг друга, нас и что для меня самое важное — себя! И не только за победы, но и за провалы. Как по заветам Dragon Dreaming, в который я очень верю.
К чему я это все: добавляйте эту практику в свои обучательные чаты (если вы создаете обучение) и в рабочие чатики тоже — чтобы каждый день получать больше кайфа от того, что делаешь. И не бойтесь там хвалить себя, а если сложно — начните хотя бы с благодарности или похвалы коллеге. Потому что кого-то хвалить и благодарить чаще проще, чем себя.
#команда, #коммуникации, #фичи_курсов
Кажется, это лучшее, что я придумала для возврата энергии за последние полгода. Сейчас расскажу.
Когда появились функция тредов в телеге, мы решили перевести в них наше комьюнити Сильных программистов. Чтобы был порядок. И одну из веток я назвала «флуд, нытье и что-то еще». Идея была в том, что если создать пространство для всякого нытья, то ребята больше сплотятся. Опиралась на метод «вонючей рыбы», который постоянно практикую и всем советую.
Это работало. А спустя наверное год, я подумала что нытье у нас есть, а радости нет. Но это тоже важная часть, которая сплочает и дает энергию. И тогда я вспомнила о своем «сундучке похвалы», который мне посоветовала моя психолог несколько лет назад, когда я не могла совладать с синдромом самозванца.
«Сундук похвалы» — пространство, куда я должна была складывать все упоминания, когда меня хвалят или когда я чувствую, что горжусь собой. Так у меня появилась сначала папка на компе, а потом закрытый канал в телеге. Я должна была заходить в него каждый раз, когда голос внутреннего самозванца становился настолько громким, что я не могла с ним совладать. Кстати, пользуюсь до сих пор, потому что еще ни разу не подвел.
Вообщем, вспомнив эту идею я добавила в комьюнити ветку «Зал славы: хвалим себя и других». Сначала там молчали, но с каждым появлением нового поста (начинала я с себя: хвалила и себя и других, говорила спасибо), лед потихоньку таял и я видела, что в этой истории большой потенциал. Со временем мы начали добавлять ее в чат каждого курса.
И вот спустя полгода могу сказать, что эта ветка — охренное место возврата энергии. Люди хвалят и благодарят друг друга, нас и что для меня самое важное — себя! И не только за победы, но и за провалы. Как по заветам Dragon Dreaming, в который я очень верю.
К чему я это все: добавляйте эту практику в свои обучательные чаты (если вы создаете обучение) и в рабочие чатики тоже — чтобы каждый день получать больше кайфа от того, что делаешь. И не бойтесь там хвалить себя, а если сложно — начните хотя бы с благодарности или похвалы коллеге. Потому что кого-то хвалить и благодарить чаще проще, чем себя.
#команда, #коммуникации, #фичи_курсов
Не доделывать в ночь перед запуском и не трястись в процессе
Недавно начала смотреть сериал The Bear и в 7-м эпизоде первого сезона я увидела себя. Точнее то, как раньше я запускала проекты. И что считала нормой.
Прежде чем рассказать почему, расскажу немного контекста из сериала, чтобы вы понимали о чем я. Без спойлеров, если в друг решите посмотреть целиком (очень рекомендую).
В общем главный герой, именитый шеф возвращается в ресторан своего брата и пытается наладить его дела, потому что они годами идут не очень. У него появляется талантливый су-шеф, который постоянно предлагает классные идеи. Одна из них — запустить предзаказ блюд через интернет.
И вот они запускают, им начинает падать очень много заказов, к которым они совсем не готовы. Я нашла в ютубе 2-мин отрывок. Обязательно посмотрите, чтобы прочувствовать все.
Часть сотрудников даже не в курсе, что у них планировалась фича. Все начинают жестко орать на друг друга и пытаться что-то делать, как-то спасать ситуацию. Заказы перемешиваются, блюда роняются на пол, творится полный хаос. Чем все закончилось, не буду говорить, чтобы не спойлерить.
Когда я смотрела этот кусок, казалось, что это про меня 7-10 лет назад. Так у меня происходил каждый запуск. Я всегда была центром информации в проекте, ко мне всегда все ходили чтобы что-то узнать или согласовать. Никто лучше меня не знает. И рассказывать всем некогда, по ходу дела разберемся — надо работу делать. Это все еще приправлялось хаосом внутри, какими-то моими набегами «давай все переделаем» или «я хотела по-другому», что способствовало переработке по ночам и напряжению в команде.
Я думала, что это нормально, это ведь запуск. И все делаю правильно: во имя качества продукта и счастья клиента. Ничего, что мы тут все страдаем.
А потом узнала о существовании Walnut Model, которая описывала групповую динамику. На ней четко показывалось, насколько важны процессы, согласованность в команде, понимание ролей.
Модель противоречила ключевому моему паттерну: каждый раз, когда мы начинали проект, я скипала обсуждения ролей, процессов, хотя люди каждый раз задавали все эти вопросы. Я либо сливалась либо делала это для галочки искренне считая ерундой. Ведь главное надо работу делать, «нам некогда».
На иллюстрации было четко видно, что такой паттерн закапывает проекты или заставляет тащить их на зубах. Я сильно вдохновилась и начала пробовать.
В итоге, стала затаскивать проекты с большей сложностью и непредсказуемостью. И не по ночам и в напряге. А с чувством поддержки команды. Все стало слаженым и стало не страшно ходить в отпуск.
Если у вас такой же паттерн, как был у меня:
1/ Знайте, что может быть по-другому. Страдать необязательно.
2/ Почитайте статью про Walnut Model, а если не сможете применить — почитайте краш-курс. Там в 6 письме, кейс Антохи, которому я по костям разбираю эту задачу и помогаю все настроить. И кроме модели там еще куча всего полезного. Не пожалеете
#управление_проектами, #команда
Недавно начала смотреть сериал The Bear и в 7-м эпизоде первого сезона я увидела себя. Точнее то, как раньше я запускала проекты. И что считала нормой.
Прежде чем рассказать почему, расскажу немного контекста из сериала, чтобы вы понимали о чем я. Без спойлеров, если в друг решите посмотреть целиком (очень рекомендую).
В общем главный герой, именитый шеф возвращается в ресторан своего брата и пытается наладить его дела, потому что они годами идут не очень. У него появляется талантливый су-шеф, который постоянно предлагает классные идеи. Одна из них — запустить предзаказ блюд через интернет.
И вот они запускают, им начинает падать очень много заказов, к которым они совсем не готовы. Я нашла в ютубе 2-мин отрывок. Обязательно посмотрите, чтобы прочувствовать все.
Часть сотрудников даже не в курсе, что у них планировалась фича. Все начинают жестко орать на друг друга и пытаться что-то делать, как-то спасать ситуацию. Заказы перемешиваются, блюда роняются на пол, творится полный хаос. Чем все закончилось, не буду говорить, чтобы не спойлерить.
Когда я смотрела этот кусок, казалось, что это про меня 7-10 лет назад. Так у меня происходил каждый запуск. Я всегда была центром информации в проекте, ко мне всегда все ходили чтобы что-то узнать или согласовать. Никто лучше меня не знает. И рассказывать всем некогда, по ходу дела разберемся — надо работу делать. Это все еще приправлялось хаосом внутри, какими-то моими набегами «давай все переделаем» или «я хотела по-другому», что способствовало переработке по ночам и напряжению в команде.
Я думала, что это нормально, это ведь запуск. И все делаю правильно: во имя качества продукта и счастья клиента. Ничего, что мы тут все страдаем.
А потом узнала о существовании Walnut Model, которая описывала групповую динамику. На ней четко показывалось, насколько важны процессы, согласованность в команде, понимание ролей.
Модель противоречила ключевому моему паттерну: каждый раз, когда мы начинали проект, я скипала обсуждения ролей, процессов, хотя люди каждый раз задавали все эти вопросы. Я либо сливалась либо делала это для галочки искренне считая ерундой. Ведь главное надо работу делать, «нам некогда».
На иллюстрации было четко видно, что такой паттерн закапывает проекты или заставляет тащить их на зубах. Я сильно вдохновилась и начала пробовать.
В итоге, стала затаскивать проекты с большей сложностью и непредсказуемостью. И не по ночам и в напряге. А с чувством поддержки команды. Все стало слаженым и стало не страшно ходить в отпуск.
Если у вас такой же паттерн, как был у меня:
1/ Знайте, что может быть по-другому. Страдать необязательно.
2/ Почитайте статью про Walnut Model, а если не сможете применить — почитайте краш-курс. Там в 6 письме, кейс Антохи, которому я по костям разбираю эту задачу и помогаю все настроить. И кроме модели там еще куча всего полезного. Не пожалеете
#управление_проектами, #команда
Сдерживать обещания или не обещать совсем
Недавно мне нужно было привезти из Еревана лекарство, потому что в Тбилиси его не найти, а в Ереване есть. Я попросила друга его купить и передать через человека, которого нашла в местном чатике. Этот человек оказался водителем автобуса, поэтому нужно было прийти в указанное место вовремя, иначе он не сможет ждать из-за графика поездок.
Сказал он об этом ночью, я увидела утром, отменила планы все и поехала на встречу. Прихожу в условленное место и пишу ему, что на месте. Он не отвечает, я звоню — он мне говорит «да, мы только границу прошли, буду через 1,5-2 часа». Думаю, ну ладно, это дорога. Пойду в кафе поработаю хоть с телефона. Говорю ему «как будете подъезжать предупредите меня за полчаса, чтобы я вовремя была на месте». Он соглашается, но спустя 2 часа от него ни слуху, ни духу. Звоню еще раз, он говорит «буду через 10 минут».
Я уже злая, давай бежать на точку, чтобы успеть, а то уедет мое лекарство. Прибегаю, его нет. Жду еще полчаса, его нет. Думаю, вдруг уехал, звоню. Он отвечает снова «буду через 10 минут», но и через 10 его снова нет. Дальше он мне говорит, что его задержал патруль, потом не приезжает. Спустя 3,5 часа мы таки встречаемся (я почти все это время простояла на улице), отдает мне лекарство, забирает деньги за доставку и без извинений уезжает.
То, что я к нему больше никогда не вернусь и так понятно (ситуация совершенно другая чем с доставкой суши), но эта история меня напомнила классический конфликт бизнеса и разработки. Когда разработка обещает бизнесу фичу, а потом кормит обещаниями «будет в этом релизе», «не успели, но в понедельник будет готово», а потом «ой, что-то сломалось». В этот момент бизнес бежит на точку встречи и перекраивает свои планы (маркетинг фичи, обещания клиентам и т.д) и напряжение между вами только растет. И когда вы таки выполняете обещанное — нет никакой радости и спасибо. Только злость, разочарование и обида.
Плохая оценка часто возникает из-за давления бизнеса, но вы всегда можете сказать «мне нужно время на ресерч или подумать». И я не видела ни одного заказчика, который не давал это время, а вот разработчиков, которые брали время на подумать вижу не всегда. Вторая проблема — оценка рисков: о них принято не думать, а потом «ой, кто бы мог подумать, что так случится». Потому что недостаточно времени было выделено на то, чтобы покрутить задачу с разных сторон, заложить время на риски и т.д. Третья проблема — поздное начало работы над задаче. Иногда кажется, что задача понятная, а значит можно потом ее сделать, а пока поковыряю другое. А потом начинаешь делать, а там хоп и нежданчик, но времени уже нет. И ты такой «ой, не успеваю».
Выводы:
1/ если у вас проблемы в коммуникации с бизнесом, скрытый конфликт, посмотрите как вы выполняете обещания. Как водила автобуса или бизнес может на вас положиться.
2/ Лучше не обещать совсем, чем кормить «завтраками». Но не просто сказать «не могу обещать», а обьяснить почему.
_
Полезные посты по теме:
Обратное планирование — о том, как точнее спланировать проект или задачу
Последняя миля — о том, какие из задач важнее закончить в первую очередь
Думать о рисках не равно их навлечь — о том, почему важно работать с рисками
#принципы_работы, #команда
Недавно мне нужно было привезти из Еревана лекарство, потому что в Тбилиси его не найти, а в Ереване есть. Я попросила друга его купить и передать через человека, которого нашла в местном чатике. Этот человек оказался водителем автобуса, поэтому нужно было прийти в указанное место вовремя, иначе он не сможет ждать из-за графика поездок.
Сказал он об этом ночью, я увидела утром, отменила планы все и поехала на встречу. Прихожу в условленное место и пишу ему, что на месте. Он не отвечает, я звоню — он мне говорит «да, мы только границу прошли, буду через 1,5-2 часа». Думаю, ну ладно, это дорога. Пойду в кафе поработаю хоть с телефона. Говорю ему «как будете подъезжать предупредите меня за полчаса, чтобы я вовремя была на месте». Он соглашается, но спустя 2 часа от него ни слуху, ни духу. Звоню еще раз, он говорит «буду через 10 минут».
Я уже злая, давай бежать на точку, чтобы успеть, а то уедет мое лекарство. Прибегаю, его нет. Жду еще полчаса, его нет. Думаю, вдруг уехал, звоню. Он отвечает снова «буду через 10 минут», но и через 10 его снова нет. Дальше он мне говорит, что его задержал патруль, потом не приезжает. Спустя 3,5 часа мы таки встречаемся (я почти все это время простояла на улице), отдает мне лекарство, забирает деньги за доставку и без извинений уезжает.
То, что я к нему больше никогда не вернусь и так понятно (ситуация совершенно другая чем с доставкой суши), но эта история меня напомнила классический конфликт бизнеса и разработки. Когда разработка обещает бизнесу фичу, а потом кормит обещаниями «будет в этом релизе», «не успели, но в понедельник будет готово», а потом «ой, что-то сломалось». В этот момент бизнес бежит на точку встречи и перекраивает свои планы (маркетинг фичи, обещания клиентам и т.д) и напряжение между вами только растет. И когда вы таки выполняете обещанное — нет никакой радости и спасибо. Только злость, разочарование и обида.
Плохая оценка часто возникает из-за давления бизнеса, но вы всегда можете сказать «мне нужно время на ресерч или подумать». И я не видела ни одного заказчика, который не давал это время, а вот разработчиков, которые брали время на подумать вижу не всегда. Вторая проблема — оценка рисков: о них принято не думать, а потом «ой, кто бы мог подумать, что так случится». Потому что недостаточно времени было выделено на то, чтобы покрутить задачу с разных сторон, заложить время на риски и т.д. Третья проблема — поздное начало работы над задаче. Иногда кажется, что задача понятная, а значит можно потом ее сделать, а пока поковыряю другое. А потом начинаешь делать, а там хоп и нежданчик, но времени уже нет. И ты такой «ой, не успеваю».
Выводы:
1/ если у вас проблемы в коммуникации с бизнесом, скрытый конфликт, посмотрите как вы выполняете обещания. Как водила автобуса или бизнес может на вас положиться.
2/ Лучше не обещать совсем, чем кормить «завтраками». Но не просто сказать «не могу обещать», а обьяснить почему.
_
Полезные посты по теме:
Обратное планирование — о том, как точнее спланировать проект или задачу
Последняя миля — о том, какие из задач важнее закончить в первую очередь
Думать о рисках не равно их навлечь — о том, почему важно работать с рисками
#принципы_работы, #команда
Поговорим о зарплате
На днях разговаривала с клиенткой о повышении зарплаты. Мне клиентка говорит «мой руководитель сам мне повышает каждый раз зарплату, я просто хорошо делаю свою работу». Для меня это было как бальзам на душу, потому что мы с Федей топим за этот подход. Но так же это большая редкость в моем окружении.
Ни у меня никогда не было руководителя, который бы сам мне повышал зарплату, ни у людей, которые меня окружают.
Чаще надо либо добиваться самой, продавать себя, что всегда супер не прозрачно. И это беда.
Либо есть стандартная система грейдов или план развития, выполняя условия которого ты повышаешь себе зарплату. Здесь беда в том, что если у тебя нестандартная роль и ты не вписываешься в эти грейды, то повышение тебе сложно получить.
Сейчас я пишу 4-й лонгрид для «Стать тимлидом 2.0» и там будет кусок о зарплате. И вот я подумала, что хочется расширить свой пузырь и спросить какой сценарий у вас. Сделаю опрос в следующем посте. И жду ваши истории в комментариях, интересно обсудить.
#команда
На днях разговаривала с клиенткой о повышении зарплаты. Мне клиентка говорит «мой руководитель сам мне повышает каждый раз зарплату, я просто хорошо делаю свою работу». Для меня это было как бальзам на душу, потому что мы с Федей топим за этот подход. Но так же это большая редкость в моем окружении.
Ни у меня никогда не было руководителя, который бы сам мне повышал зарплату, ни у людей, которые меня окружают.
Чаще надо либо добиваться самой, продавать себя, что всегда супер не прозрачно. И это беда.
Либо есть стандартная система грейдов или план развития, выполняя условия которого ты повышаешь себе зарплату. Здесь беда в том, что если у тебя нестандартная роль и ты не вписываешься в эти грейды, то повышение тебе сложно получить.
Сейчас я пишу 4-й лонгрид для «Стать тимлидом 2.0» и там будет кусок о зарплате. И вот я подумала, что хочется расширить свой пузырь и спросить какой сценарий у вас. Сделаю опрос в следующем посте. И жду ваши истории в комментариях, интересно обсудить.
#команда
Паук ответственности
Часто ко мне в консалтинг приходят руководители, которые жалуются на то, что не получается достичь результата, на которое рассчитывает их бизнес. Часто это случается из-за неправильно поставленных целей, плохого планирования или конфигурации команды. Когда мы добираемся до команды, я даю домашку: прошу руководителя совместно с каждым сотрудником сделать паука ответственности.
Паук ответственности — это майндкарта, где каждая ветка соответствует роли или типу задач, которые выполняет сотрудник. Визуальный слепок того, чем человек занят каждый день. Мы как-то в МИФе назвали его пауком из-за того, что когда рисуешь — эти ножки похожи на паучьи. Паука я использую для того, чтобы увидеть нестыковки. Сейчас объясню, чтобы понятнее было.
Например, у CMM-менеджера там будет написание постов и публикация в соцсети, возможно разработка стратегии коммуникации в каждой из сетей. А еще чаще всего будет то, о чем руководитель и не думал.
Например, он будет половину времени тратить на создание отчетов, которые нафиг никому не нужны. И делать он будет это очень плохо, но так сложилось исторически и еще некому передать. Или он рисует картинки для постов, тратит на это тучу времени, а можно было бы делегировать фрилансеру задешево и сразу повысить качество.
А еще там может быть какая-то работа, которая давно ему оверквалифайд и руководитель получается, неэффективно использует ресурс. Ведь мог нанять подавана, а этому дать задачу например, рост числа подписчиков, вместо того же рисования картинок. Ни разу еще не видела паука, в котором не было никаких новостей и выводов. Такое бывает только в пауке на новую вакансию, на которую не пришел еще кандидат (так я тоже использую паука).
Паук ответственности можно использовать не только для аудита ролей и их эффективности для каждого сотрудника, но и для того, чтобы смотреть прогресс его развития, обсуждать куда бы хотелось двигаться дальше, от чего отказываться, а какие новые ответственности брать.
Это и хороший артефакт, чтобы обсуждать зарплату, если у вас нет формализованного процесса ревью: раз в полгода встретился — посмотрел на паука и сразу понятно, что изменилось и в какую сторону. В общем, советую попробовать сделать себе и предложить коллегам, а потом это все обсудить и прийти к каким-то действиям.
#команда
Часто ко мне в консалтинг приходят руководители, которые жалуются на то, что не получается достичь результата, на которое рассчитывает их бизнес. Часто это случается из-за неправильно поставленных целей, плохого планирования или конфигурации команды. Когда мы добираемся до команды, я даю домашку: прошу руководителя совместно с каждым сотрудником сделать паука ответственности.
Паук ответственности — это майндкарта, где каждая ветка соответствует роли или типу задач, которые выполняет сотрудник. Визуальный слепок того, чем человек занят каждый день. Мы как-то в МИФе назвали его пауком из-за того, что когда рисуешь — эти ножки похожи на паучьи. Паука я использую для того, чтобы увидеть нестыковки. Сейчас объясню, чтобы понятнее было.
Например, у CMM-менеджера там будет написание постов и публикация в соцсети, возможно разработка стратегии коммуникации в каждой из сетей. А еще чаще всего будет то, о чем руководитель и не думал.
Например, он будет половину времени тратить на создание отчетов, которые нафиг никому не нужны. И делать он будет это очень плохо, но так сложилось исторически и еще некому передать. Или он рисует картинки для постов, тратит на это тучу времени, а можно было бы делегировать фрилансеру задешево и сразу повысить качество.
А еще там может быть какая-то работа, которая давно ему оверквалифайд и руководитель получается, неэффективно использует ресурс. Ведь мог нанять подавана, а этому дать задачу например, рост числа подписчиков, вместо того же рисования картинок. Ни разу еще не видела паука, в котором не было никаких новостей и выводов. Такое бывает только в пауке на новую вакансию, на которую не пришел еще кандидат (так я тоже использую паука).
Паук ответственности можно использовать не только для аудита ролей и их эффективности для каждого сотрудника, но и для того, чтобы смотреть прогресс его развития, обсуждать куда бы хотелось двигаться дальше, от чего отказываться, а какие новые ответственности брать.
Это и хороший артефакт, чтобы обсуждать зарплату, если у вас нет формализованного процесса ревью: раз в полгода встретился — посмотрел на паука и сразу понятно, что изменилось и в какую сторону. В общем, советую попробовать сделать себе и предложить коллегам, а потом это все обсудить и прийти к каким-то действиям.
#команда
Выкладываю запись воркшопа по разбору ролей и подвожу итоги
В пятницу был экспериментальный воркшоп по разбору ролей. Я разобрала 2 совершенно разных набора ролей. Смотреть запись.
Первый — Марии, HR-менеджер с кучей ролей, от погружения новичков до разработки бота. Мы прошлись по каждой: выяснили зачем эта роль, что за ней скрывается; убрали ненужное, нашли точку роста и места, которых Маша избегает. Что у нас получилось можно посмотреть на доске. Маша сказала, что появилась ясность в голове и понимание, куда двигаться дальше.
Второй — Александра, тимлида с аналитическим прошлым. Здесь больше говорили о будущем: о том, что делегировать, где может выстрелить в ногу и какие векторы развития могут быть. Доска Александра. Отзыв на скрине.
Ребятам, которых я разбирала и тем, кто просто наблюдал оказалось полезным. Многие захотели после встречи попробовать и себе сделать паука, и своей команде. А потом обсудить. Это как раз то, к чему я стремилась.
Мне тоже понравилось, так что считаю, что эксперимент удался. Может однажды еще раз повторю. Тимлидские пауки мы с Федей разбираем на первой недели курса.
#команда
В пятницу был экспериментальный воркшоп по разбору ролей. Я разобрала 2 совершенно разных набора ролей. Смотреть запись.
Первый — Марии, HR-менеджер с кучей ролей, от погружения новичков до разработки бота. Мы прошлись по каждой: выяснили зачем эта роль, что за ней скрывается; убрали ненужное, нашли точку роста и места, которых Маша избегает. Что у нас получилось можно посмотреть на доске. Маша сказала, что появилась ясность в голове и понимание, куда двигаться дальше.
Второй — Александра, тимлида с аналитическим прошлым. Здесь больше говорили о будущем: о том, что делегировать, где может выстрелить в ногу и какие векторы развития могут быть. Доска Александра. Отзыв на скрине.
Ребятам, которых я разбирала и тем, кто просто наблюдал оказалось полезным. Многие захотели после встречи попробовать и себе сделать паука, и своей команде. А потом обсудить. Это как раз то, к чему я стремилась.
Мне тоже понравилось, так что считаю, что эксперимент удался. Может однажды еще раз повторю. Тимлидские пауки мы с Федей разбираем на первой недели курса.
#команда
Проджектам: на что обратить внимание при поиске работы
Недавно искала проджекта в команду. Неожиданно, быстро нашли подходящую кандидатку и, надеюсь, что все сложится. Удивительно и то, что на вакансию откликнулось очень много людей, поэтому была возможность выбирать лучших из лучших. Это приятно.
Однако некоторые не прошли базовый фильтр, на мой взгляд, по небрежности или глупости. Для меня это важный показатель того, как человек будет работать на этой позиции. Обсудила этот вопрос с коллегами на рынке, и все сошлись в том, что штуки, которые опишу далее важны.
Итак, топ-3:
1/ Резюме без выполнения тестового задания, если в условиях было указано другое. В условиях вакансии было указано сделать тестовое задание, однако некоторые кандидаты отправляли только резюме, видимо, не вникая в требования.
2/ Прислали тестовое задание, но не настроили видимость, так что я не могла открыть. Запрашивала доступ только у тех, кто указал на возможность таких трудностей в сопроводительном письме потому что видно, что человек старался, но что-то в процессе пошло не так.
3/ Несоблюдение условий тестового задания. Человек старался, но в итоге результат не соответствовал требованиям.
4/ Факап дедлайнов. Дедлайн давно прошел, а я до сих пор получаю тестовые с пометкой «посмотрите, может вам подойду». Не понимаю зачем люди тратят время, если дедлайн прошел. Так же с осторожностью смотрела на тех, кто присылал в последнюю минуту. Это тоже звоночек плохой привычки, а для меня это не ок.
Вроде мелочи, но для роли проджекта, на мой взгляд, критичны: человек может прочитать задачу и выполнить наполовину, сделать по-своему или не сделать совсем, прислав что-то другое. Каждый раз придется запрашивать доступ к файлу, что усложнит коммуникацию.
Если бы не было других вариантов, я бы дала шанс исправить такие ошибки. Но когда на другой чаше весов кандидаты, которые не только справляются с тестовым, но и внимательно относятся к форматированию и пишут понятное сопроводительное письмо — таким кандидатам хочется уделять внимание.
Марьяна, в следующий раз когда придут на консультацию по этому вопросу — напомни, что эти мелочи важны. Чтобы люди не наступали на те же грабли и могли пройти базовый фильтр и претендовать на работу.
Если вы нанимаете проджектов, на что обращаете внимание при первом фильтре? Напишите в комментариях — сделаю подборку.
#команда, #управление_проектами
Недавно искала проджекта в команду. Неожиданно, быстро нашли подходящую кандидатку и, надеюсь, что все сложится. Удивительно и то, что на вакансию откликнулось очень много людей, поэтому была возможность выбирать лучших из лучших. Это приятно.
Однако некоторые не прошли базовый фильтр, на мой взгляд, по небрежности или глупости. Для меня это важный показатель того, как человек будет работать на этой позиции. Обсудила этот вопрос с коллегами на рынке, и все сошлись в том, что штуки, которые опишу далее важны.
Итак, топ-3:
1/ Резюме без выполнения тестового задания, если в условиях было указано другое. В условиях вакансии было указано сделать тестовое задание, однако некоторые кандидаты отправляли только резюме, видимо, не вникая в требования.
2/ Прислали тестовое задание, но не настроили видимость, так что я не могла открыть. Запрашивала доступ только у тех, кто указал на возможность таких трудностей в сопроводительном письме потому что видно, что человек старался, но что-то в процессе пошло не так.
3/ Несоблюдение условий тестового задания. Человек старался, но в итоге результат не соответствовал требованиям.
4/ Факап дедлайнов. Дедлайн давно прошел, а я до сих пор получаю тестовые с пометкой «посмотрите, может вам подойду». Не понимаю зачем люди тратят время, если дедлайн прошел. Так же с осторожностью смотрела на тех, кто присылал в последнюю минуту. Это тоже звоночек плохой привычки, а для меня это не ок.
Вроде мелочи, но для роли проджекта, на мой взгляд, критичны: человек может прочитать задачу и выполнить наполовину, сделать по-своему или не сделать совсем, прислав что-то другое. Каждый раз придется запрашивать доступ к файлу, что усложнит коммуникацию.
Если бы не было других вариантов, я бы дала шанс исправить такие ошибки. Но когда на другой чаше весов кандидаты, которые не только справляются с тестовым, но и внимательно относятся к форматированию и пишут понятное сопроводительное письмо — таким кандидатам хочется уделять внимание.
Марьяна, в следующий раз когда придут на консультацию по этому вопросу — напомни, что эти мелочи важны. Чтобы люди не наступали на те же грабли и могли пройти базовый фильтр и претендовать на работу.
Если вы нанимаете проджектов, на что обращаете внимание при первом фильтре? Напишите в комментариях — сделаю подборку.
#команда, #управление_проектами