Как сплотить команду: много всего перепробовал, но ничего не получается? Каждый тянет одеяло на себя, доверия нет, никто не горит общим результатом.
Я в такой ситуации была много раз. Особенно, когда собирала команду из сотрудников разных отделов. Мой проект для них был последним по приоритету, спущенным сверху и у меня не было прямого влияния, так как я не была их руководителем.
Я пробовала закрывать глаза на то, что происходит, мотивировала интересом и классным результатом, но это не всегда срабатывала.
Потом узнала о методе «вонючей рыбы» и теперь пользуюсь.
Цель метода — в безопасной среде поделиться любыми проблемами и страхами, поговорить о том, что беспокоит и создать открытость в команде.
Это может быть что угодно. Например: «Мне спустили этот проект и даже не спросили», «я в него не верю», «мне некогда его делать, я ребенка не вижу» и т.д.
Вонючая рыба — это метафора для того, что мы носим с собой, и о чем не любим говорить. Чем дольше мы ее скрываем, тем вонючее она становится.
Положив вонючую рыбу на стол — мы начинаем понимать контекст каждого и либо сопереживать (уже легче становится) или решать проблемы, которые возникли. Внутри создается открытость, доверие и чувство, что мы в одной лодке.
Иногда я люблю даже на 1:1 говорить «доставай свою вонючую рыбу» или использовать как фреймворк для ретроспектив.
Когда гуглила нормальную инструкцию, как команду провести через метод — случайно увидела, что Hyper Island сделали доску с вонючей рыбой на Miro. Там и инструкция и шаблон. Рекомендую.
#коммуникации, #команда
Я в такой ситуации была много раз. Особенно, когда собирала команду из сотрудников разных отделов. Мой проект для них был последним по приоритету, спущенным сверху и у меня не было прямого влияния, так как я не была их руководителем.
Я пробовала закрывать глаза на то, что происходит, мотивировала интересом и классным результатом, но это не всегда срабатывала.
Потом узнала о методе «вонючей рыбы» и теперь пользуюсь.
Цель метода — в безопасной среде поделиться любыми проблемами и страхами, поговорить о том, что беспокоит и создать открытость в команде.
Это может быть что угодно. Например: «Мне спустили этот проект и даже не спросили», «я в него не верю», «мне некогда его делать, я ребенка не вижу» и т.д.
Вонючая рыба — это метафора для того, что мы носим с собой, и о чем не любим говорить. Чем дольше мы ее скрываем, тем вонючее она становится.
Положив вонючую рыбу на стол — мы начинаем понимать контекст каждого и либо сопереживать (уже легче становится) или решать проблемы, которые возникли. Внутри создается открытость, доверие и чувство, что мы в одной лодке.
Иногда я люблю даже на 1:1 говорить «доставай свою вонючую рыбу» или использовать как фреймворк для ретроспектив.
Когда гуглила нормальную инструкцию, как команду провести через метод — случайно увидела, что Hyper Island сделали доску с вонючей рыбой на Miro. Там и инструкция и шаблон. Рекомендую.
#коммуникации, #команда
Я написала несколько постов о том, как давать обратную связь. Для тех, кто не читал — продублирую ссылки в конце поста.
Сегодня хочу рассказать кейс, когда я ученик и мне дают обратная связь. Начну с контекста.
Сейчас я учусь на курсе, где нужно делать домашку. Ее проверяют и если хорошо сделана — ставят отметку «сдана» или возвращают на доработку.
Когда я сдавала первую домашку — моя цель была, чтобы ее приняли. Больше ни о чем я не думала. Но когда получила отметку «принято» и коммент проверяющего «молодец, так держать!» сильно расстроилась.
Те, кому я проверяла домашку знают, что я никогда не
даю односложное «принято», а стараюсь дать пользу человеку, даже если все идеально.
Но в предыдущих постах я писала, что ответственность за наличие качественной обратной связи лежит на двух парах плеч: со стороны того, кто дает и со стороны того, кто ее получает.
Поэтому я начала думать, что мне делать в этой ситуации.
Можно было бы попросить другого проверяющего, но не факт, что он не окажется таким же. Я еще и время потеряю.
Я начала анализировать и поняла, что вообще-то когда делала домашку — у меня было много вариантов того, как я могу ее сделать. В процессе я сомневалась и принимала конкретные решения. Если бы я о них рассказала — мне бы что-то ответили и это точно было бы полезно. Это номер раз.
В следующие разы, я начала рассказывать не только о своих сомнениях, но и объяснять логику своих размышлений и почему приняла решения. Один в один, как при продажи идеи бизнесу. Польза выросла в разы. Это два.
Потом я поймала себя на том, что иногда выбираю конкретное решение, потому что не знаю как можно по-другому. И сформулировать запрос «делаю так, но как еще бывает» — мне тоже ответит. Это три.
Итого за счет нескольких итераций у меня из было «принято, так держать!» стало «принято, так держать и простыня объяснений, что мне делать».
Далее старые посты об обратной связи👇
Как давать обратную связь — о формуле и принципах, которыми я пользуюсь
Перетерпи и не ленись давать обратную связь — о том, когда уместно давать обратную связь
Не нужно ждать, пока тебе дадут обратную связь, чтобы ее получить — о разделении ответственности в появлении обратной связи между руководителем и подчинённым
#команда, #коммуникации
Сегодня хочу рассказать кейс, когда я ученик и мне дают обратная связь. Начну с контекста.
Сейчас я учусь на курсе, где нужно делать домашку. Ее проверяют и если хорошо сделана — ставят отметку «сдана» или возвращают на доработку.
Когда я сдавала первую домашку — моя цель была, чтобы ее приняли. Больше ни о чем я не думала. Но когда получила отметку «принято» и коммент проверяющего «молодец, так держать!» сильно расстроилась.
Те, кому я проверяла домашку знают, что я никогда не
даю односложное «принято», а стараюсь дать пользу человеку, даже если все идеально.
Но в предыдущих постах я писала, что ответственность за наличие качественной обратной связи лежит на двух парах плеч: со стороны того, кто дает и со стороны того, кто ее получает.
Поэтому я начала думать, что мне делать в этой ситуации.
Можно было бы попросить другого проверяющего, но не факт, что он не окажется таким же. Я еще и время потеряю.
Я начала анализировать и поняла, что вообще-то когда делала домашку — у меня было много вариантов того, как я могу ее сделать. В процессе я сомневалась и принимала конкретные решения. Если бы я о них рассказала — мне бы что-то ответили и это точно было бы полезно. Это номер раз.
В следующие разы, я начала рассказывать не только о своих сомнениях, но и объяснять логику своих размышлений и почему приняла решения. Один в один, как при продажи идеи бизнесу. Польза выросла в разы. Это два.
Потом я поймала себя на том, что иногда выбираю конкретное решение, потому что не знаю как можно по-другому. И сформулировать запрос «делаю так, но как еще бывает» — мне тоже ответит. Это три.
Итого за счет нескольких итераций у меня из было «принято, так держать!» стало «принято, так держать и простыня объяснений, что мне делать».
Далее старые посты об обратной связи👇
Как давать обратную связь — о формуле и принципах, которыми я пользуюсь
Перетерпи и не ленись давать обратную связь — о том, когда уместно давать обратную связь
Не нужно ждать, пока тебе дадут обратную связь, чтобы ее получить — о разделении ответственности в появлении обратной связи между руководителем и подчинённым
#команда, #коммуникации
Сегодня необычный пост. И его автор не я, а мои коллеги из IVI: Маша Князева и Алевтина Щекотурова.
Девушки зажгли своим рассказом о процессах в команде на ланче с учениками нашего курса «Стать тимлидом». И так понравились ребятам, что я попросила сделать гостевой пост для вас.
Далее их текст о том, как не тащить все процессы на себе, а вовлечь в них команду. На примере тимлида, но подойдет всем, кто лидирует проекты. Пост большой, но полезный 👇
«Основная задача тимлида — растить сотрудников и масштабироваться. У тебя всего ±40 рабочих часов в неделе — больше не будет. Ты не можешь добавить часов в сутках, но можешь вырастить сильную команду, и тогда твои 40 часов превратятся в 200, 400 или даже 800.
Сильный лидер — тот, который вырастил команду, передал ей “run” и, не утонув в операционке, занимается стратегически значимыми вещами и инновациями; делает “change”, повышая ценность продукта, совершенствуя технологии, оптимизируя процессы и развивая людей.
Именно поэтому мы в команде делегируем всё и всем: это решает проблему bus factor-а, развивает самоорганизацию и растит людей. Проведение командных встреч не стало исключением: планирование, “груминг”, дейлики, ретро — ребята проводят по очереди.
Пара лайфхаков, как мы это организовали.
1/ Мы поняли, что одновременно фасилитировать встречу и дополнять описание задачи, уточняющееся в ходе обсуждения/записывать договоренности — сложно. Поэтому разделили роль ведущего и роль того, кто всё фиксирует. Благодаря этому, ведущий может сфокусироваться на фасилитации, а записывающий внимательно слушает все, о чем говорят и сразу записывает — так мы не упускаем ни одной мелочи.
2/ Для того, чтобы легко решать, кто будет ведущим, а кто — записывающим, мы сделали простую программку-выборщик, определяющую ребят на роли рандомно, но с учетом весов. Если ты недавно проводил планирование — второй раз подряд тебя не выберут.
3/ В момент проведения встречи ведущий отказывается от обычной роли (разработчик, тестировщик и т.д.), не участвует в обсуждении проблем или оценке задач, а полностью концентрируется на фасилитации. Совмещать 2 шляпы — и ведущего, и своей роли — оказалось тяжело, поэтому такой шаг упростил ребятам жизнь и помог повысить качество проведения встреч. Ведущий смотрит на ситуацию как бы сверху и может, например, вовремя остановить спор, а не вовлекаться в него.
4/ Чтобы ребятам было максимально просто проводить встречи и не тратить много времени на подготовку, мы сделали супер-подробную “памятку скрам-мастера”. В ней пошагово описано всё, что нужно выполнить до, во время и после встречи. Теперь на подготовку к планированию уходит не больше 10 минут, а к ретроспективе — получаса.
Чего мы добились?
1/ Процессы в команде не завязаны на ком-то одном. Команда абсолютно автономна: кто бы ни ушел в отпуск или ни уволился — процессы сохранятся.
2/ Ребята стали гораздо больше вовлечены во встречи. По словам ребят, после того, как ты побывал ведущим, смысл встреч становится более понятен и даже ощущается по-другому. А еще теперь сложнее, например, сидеть и тупить на встрече в телефончик, зная, что в следующий раз встречу вести тебе, а такое поведение участников не очень-то и приятно.
3/ Ребята почувствовали себя полноправными хозяевами процессов: как их улучшить, сделать более удобными и эффективными теперь думают все, а не только руководитель.
4/ Ребята стали более самостоятельными и проактивными — не только в проведении встреч, но и в других вопросах. Проведение встреч оказалось только началом: проявлять инициативу, брать на себя ответственность, предлагать решения — вошло в культуру команды.»
С моей подачи, девчонки запустили свой канал в телеге, так заходите, если хочется почитать больше.
#команда #ретроспектива
Девушки зажгли своим рассказом о процессах в команде на ланче с учениками нашего курса «Стать тимлидом». И так понравились ребятам, что я попросила сделать гостевой пост для вас.
Далее их текст о том, как не тащить все процессы на себе, а вовлечь в них команду. На примере тимлида, но подойдет всем, кто лидирует проекты. Пост большой, но полезный 👇
«Основная задача тимлида — растить сотрудников и масштабироваться. У тебя всего ±40 рабочих часов в неделе — больше не будет. Ты не можешь добавить часов в сутках, но можешь вырастить сильную команду, и тогда твои 40 часов превратятся в 200, 400 или даже 800.
Сильный лидер — тот, который вырастил команду, передал ей “run” и, не утонув в операционке, занимается стратегически значимыми вещами и инновациями; делает “change”, повышая ценность продукта, совершенствуя технологии, оптимизируя процессы и развивая людей.
Именно поэтому мы в команде делегируем всё и всем: это решает проблему bus factor-а, развивает самоорганизацию и растит людей. Проведение командных встреч не стало исключением: планирование, “груминг”, дейлики, ретро — ребята проводят по очереди.
Пара лайфхаков, как мы это организовали.
1/ Мы поняли, что одновременно фасилитировать встречу и дополнять описание задачи, уточняющееся в ходе обсуждения/записывать договоренности — сложно. Поэтому разделили роль ведущего и роль того, кто всё фиксирует. Благодаря этому, ведущий может сфокусироваться на фасилитации, а записывающий внимательно слушает все, о чем говорят и сразу записывает — так мы не упускаем ни одной мелочи.
2/ Для того, чтобы легко решать, кто будет ведущим, а кто — записывающим, мы сделали простую программку-выборщик, определяющую ребят на роли рандомно, но с учетом весов. Если ты недавно проводил планирование — второй раз подряд тебя не выберут.
3/ В момент проведения встречи ведущий отказывается от обычной роли (разработчик, тестировщик и т.д.), не участвует в обсуждении проблем или оценке задач, а полностью концентрируется на фасилитации. Совмещать 2 шляпы — и ведущего, и своей роли — оказалось тяжело, поэтому такой шаг упростил ребятам жизнь и помог повысить качество проведения встреч. Ведущий смотрит на ситуацию как бы сверху и может, например, вовремя остановить спор, а не вовлекаться в него.
4/ Чтобы ребятам было максимально просто проводить встречи и не тратить много времени на подготовку, мы сделали супер-подробную “памятку скрам-мастера”. В ней пошагово описано всё, что нужно выполнить до, во время и после встречи. Теперь на подготовку к планированию уходит не больше 10 минут, а к ретроспективе — получаса.
Чего мы добились?
1/ Процессы в команде не завязаны на ком-то одном. Команда абсолютно автономна: кто бы ни ушел в отпуск или ни уволился — процессы сохранятся.
2/ Ребята стали гораздо больше вовлечены во встречи. По словам ребят, после того, как ты побывал ведущим, смысл встреч становится более понятен и даже ощущается по-другому. А еще теперь сложнее, например, сидеть и тупить на встрече в телефончик, зная, что в следующий раз встречу вести тебе, а такое поведение участников не очень-то и приятно.
3/ Ребята почувствовали себя полноправными хозяевами процессов: как их улучшить, сделать более удобными и эффективными теперь думают все, а не только руководитель.
4/ Ребята стали более самостоятельными и проактивными — не только в проведении встреч, но и в других вопросах. Проведение встреч оказалось только началом: проявлять инициативу, брать на себя ответственность, предлагать решения — вошло в культуру команды.»
С моей подачи, девчонки запустили свой канал в телеге, так заходите, если хочется почитать больше.
#команда #ретроспектива
Марьяна, расскажите, пожалуйста, как вы проводите ретро? У меня в команде все заканчивается на том, что никто ничего не помнит, не знает о чем рассказать и что обсудить. Получается будто бы ретро ради ретро(
Вы можете собрать встречу на 4 часа, закрыться в переговорке и залепить стикерами все стены, а потом выйти из нее и не вспомнить, чем занималась. А можете собрать всех в зуме на час, открыть табличку или карту миро и ответить на вопросы: что было хорошо, а что хочется улучшить, наметить план и двигаться к нему.
Если вы искали формат ретро, после которого команда берет ответственность за то, чтобы ей стало лучше — такого формата не существует.
Чаще всего после ретроспективы ничего не происходит потому что:
1/ Экшн-плана в конце встречи либо не появилось, либо он очень большой. А значит сложно поверить, что кто-то будет это делать.
2/ У задач из экшн-плана нет ответственных. Все поговорили и разошлись. Ретро выполнило функцию коллективной психотерапии.
3/ Много задач в экшн-плане вне зоны влияния их исполнителей. Например, команда разработки на ретро понимает, что всему виной государство, поэтому задачи запишем, но в реальности они невыполнимы.
4/ Большинство задач падает на инициатора ретро. Команда не берет ответственности за изменения, инициатор сам потянуть не может, разочаруется в инструменте и больше не пробует.
5/ Экшн-план не внедрен в ежедневные процессы. С задачами и ответственными все ок, но они не включаются в спринты, их не обсуждают на регулярных планингах, грумингах и так далее. Как будто это задачи низшего сорта.
Ответить на этот вопрос меня вдохновили моих два заказчики, которые написали мне на этой неделе. У них разные кейсы и они из разных компании, но у них есть общее — негативный опыт проведения ретро. Они вернулись ко мне с большой радостью — команда начала выполнять экшн-план.
Если у вас тоже был негативный опыт — пройдитесь по этому списку и попробуйте еще раз. И своим клиентам я всегда советую не ставить новое ретро, пока не сделали большинство пунктов из предыдущего экшн-плана. Зачем тратить время, если ничего не меняется.
#команда #ретроспектива
Рубрика #ответынавопросы. Новые вопросы принимаю на [email protected] и отвечаю, когда перегруз мозга и хочется раскачаться.
Вы можете собрать встречу на 4 часа, закрыться в переговорке и залепить стикерами все стены, а потом выйти из нее и не вспомнить, чем занималась. А можете собрать всех в зуме на час, открыть табличку или карту миро и ответить на вопросы: что было хорошо, а что хочется улучшить, наметить план и двигаться к нему.
Если вы искали формат ретро, после которого команда берет ответственность за то, чтобы ей стало лучше — такого формата не существует.
Чаще всего после ретроспективы ничего не происходит потому что:
1/ Экшн-плана в конце встречи либо не появилось, либо он очень большой. А значит сложно поверить, что кто-то будет это делать.
2/ У задач из экшн-плана нет ответственных. Все поговорили и разошлись. Ретро выполнило функцию коллективной психотерапии.
3/ Много задач в экшн-плане вне зоны влияния их исполнителей. Например, команда разработки на ретро понимает, что всему виной государство, поэтому задачи запишем, но в реальности они невыполнимы.
4/ Большинство задач падает на инициатора ретро. Команда не берет ответственности за изменения, инициатор сам потянуть не может, разочаруется в инструменте и больше не пробует.
5/ Экшн-план не внедрен в ежедневные процессы. С задачами и ответственными все ок, но они не включаются в спринты, их не обсуждают на регулярных планингах, грумингах и так далее. Как будто это задачи низшего сорта.
Ответить на этот вопрос меня вдохновили моих два заказчики, которые написали мне на этой неделе. У них разные кейсы и они из разных компании, но у них есть общее — негативный опыт проведения ретро. Они вернулись ко мне с большой радостью — команда начала выполнять экшн-план.
Если у вас тоже был негативный опыт — пройдитесь по этому списку и попробуйте еще раз. И своим клиентам я всегда советую не ставить новое ретро, пока не сделали большинство пунктов из предыдущего экшн-плана. Зачем тратить время, если ничего не меняется.
#команда #ретроспектива
Рубрика #ответынавопросы. Новые вопросы принимаю на [email protected] и отвечаю, когда перегруз мозга и хочется раскачаться.
Марьяна, расскажите, пожалуйста, как добиться от команды выполнения экшн-плана после ретро? Мы проводим ретро, берем небольшой список задач, назначаем ответственных, но потом ничего из обещанного не выполняется.
Часто ретроспектива — это коллективная психотерапия, без экшн-плана и ответственных. Так что ваша ситуация не самая плачевная.
Я вижу несколько причин, почему экшн-план не выполняется:
Причина 1. Ответственных за задачи назначили силой. На вопрос кто готов взять задачу кто-то из команды вместо того, чтобы взять себе — начинает говорить «ну в этом Вася самый большой спец, давайте он возьмет», а остальные поддерживают.
Васе ничего не остается, как взять себе. Я в таких случая торможу этот процесс и обращаюсь к Васе со следующими словами «Вася, ты в праве отказаться и не брать, тут никто не заставляет. Будет хуже, если ты возьмешь и возненавидишь задачу. Мы должны брать только то, во что верим и хотим делать». Тогда каждый берет то, что хочет, а не то, что ему сгрузили.
Когда я так говорю, меня спрашивают «что тогда делать с задачами, которые никому не нравятся»? Если никто их не берет — значит в них никто не видит ценности. Иначе кто-то точно бы взял. У меня много раз такое было на сессиях.
Причина 2. Большинство задач из ретроспективы берет на себя руководитель
Часто руководители команд считают своей ответственностью делать все задачи, которые относятся к процессам, взаимодействию между командами и другими «менеджерскими» задачами. Я считаю это плохой практикой. По модели Эрика Берна руководитель превращается в родителя, а команда в капризного ребенка, которому все не то. Как только команда сама начинает брать ответственность за то, чтобы ей было хорошо — начинаются отношения взрослого-взрослого и отношения в команде и результаты растут.
Причина 3. Руководитель решает, как делать задачу
На ретроспективе член команды берет себе ответственность за задачу. Потом приходит руководитель и начинает рассказывать как ее делать. Прям по шагам, иногда даже микроменеджерит. Человек не чувствует уже своего авторства и ответственности за задачу, начинает динамить. Если решили делегировать — делегируйте и дайте человеку самому решить, как ему делать задачу. Пусть ошибается, это ценнее.
Причина 4. Есть задачи поважнее
Обычно говорят так «задача по описанию этого процесса важная, но к нам пришел клиент и надо срочно сделать это» или «у нас тут важная фича, давай подвинем эту задачу на попозже». После второго такого переноса, ценность и важность остается на словах и в нее никто не верит. Если хотите чтобы задачи из экшн-плана делались — относитесь к ним как не менее важным, чем продуктовые фичи или хотелки клиентов.
Причина 5. Сделаю, когда руки дойдут
Есть важные задачи из бэклога, а задачи из экшн-плана планируются по остаточному принципу. А значит, до них никогда не доходят руки. Чтобы это изменить — включайте эти задачи в спринт или план на неделю всей команды, вносите в беклог, рассказывайте на демо.
#команда, #ретроспектива
Рубрика #ответынавопросы. Новые вопросы принимаю на [email protected] и отвечаю, когда перегруз мозга и хочется раскачаться.
Часто ретроспектива — это коллективная психотерапия, без экшн-плана и ответственных. Так что ваша ситуация не самая плачевная.
Я вижу несколько причин, почему экшн-план не выполняется:
Причина 1. Ответственных за задачи назначили силой. На вопрос кто готов взять задачу кто-то из команды вместо того, чтобы взять себе — начинает говорить «ну в этом Вася самый большой спец, давайте он возьмет», а остальные поддерживают.
Васе ничего не остается, как взять себе. Я в таких случая торможу этот процесс и обращаюсь к Васе со следующими словами «Вася, ты в праве отказаться и не брать, тут никто не заставляет. Будет хуже, если ты возьмешь и возненавидишь задачу. Мы должны брать только то, во что верим и хотим делать». Тогда каждый берет то, что хочет, а не то, что ему сгрузили.
Когда я так говорю, меня спрашивают «что тогда делать с задачами, которые никому не нравятся»? Если никто их не берет — значит в них никто не видит ценности. Иначе кто-то точно бы взял. У меня много раз такое было на сессиях.
Причина 2. Большинство задач из ретроспективы берет на себя руководитель
Часто руководители команд считают своей ответственностью делать все задачи, которые относятся к процессам, взаимодействию между командами и другими «менеджерскими» задачами. Я считаю это плохой практикой. По модели Эрика Берна руководитель превращается в родителя, а команда в капризного ребенка, которому все не то. Как только команда сама начинает брать ответственность за то, чтобы ей было хорошо — начинаются отношения взрослого-взрослого и отношения в команде и результаты растут.
Причина 3. Руководитель решает, как делать задачу
На ретроспективе член команды берет себе ответственность за задачу. Потом приходит руководитель и начинает рассказывать как ее делать. Прям по шагам, иногда даже микроменеджерит. Человек не чувствует уже своего авторства и ответственности за задачу, начинает динамить. Если решили делегировать — делегируйте и дайте человеку самому решить, как ему делать задачу. Пусть ошибается, это ценнее.
Причина 4. Есть задачи поважнее
Обычно говорят так «задача по описанию этого процесса важная, но к нам пришел клиент и надо срочно сделать это» или «у нас тут важная фича, давай подвинем эту задачу на попозже». После второго такого переноса, ценность и важность остается на словах и в нее никто не верит. Если хотите чтобы задачи из экшн-плана делались — относитесь к ним как не менее важным, чем продуктовые фичи или хотелки клиентов.
Причина 5. Сделаю, когда руки дойдут
Есть важные задачи из бэклога, а задачи из экшн-плана планируются по остаточному принципу. А значит, до них никогда не доходят руки. Чтобы это изменить — включайте эти задачи в спринт или план на неделю всей команды, вносите в беклог, рассказывайте на демо.
#команда, #ретроспектива
Рубрика #ответынавопросы. Новые вопросы принимаю на [email protected] и отвечаю, когда перегруз мозга и хочется раскачаться.
В октябре ко мне пришли ребята из Островка, чтобы провести ретро для их команд: одну для команды аналитической разработки, вторую для команды аналитиков
Задача была сложной:
— Ретро за год. Мы не помним, что было неделю две назад, не то что бы за год вспомнить. Нужно много времени и энергии, чтобы вытащить все это
— Скепсис команды. Ребята уже проводили сами и инструмент не зашел. Некоторые прямо отказывались участвовать, особенно, когда я сказала, что понадобится часов 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» и там будет кусок о зарплате. И вот я подумала, что хочется расширить свой пузырь и спросить какой сценарий у вас. Сделаю опрос в следующем посте. И жду ваши истории в комментариях, интересно обсудить.
#команда