🤵🏾♂ Тренажер для менеджеров и не только 996-869
Вы — менеджер проектов в ИТ. Ваша компания пишет софт и внедряет его у крупных клиентов, помогает им автоматизировать разные процессы. Как раз недавно закончился длинный и сложный пресейл с одним из таких клиентов, компанией из индустрии моды. Вы готовитесь к старту проекта, согласуете договор и другие документы.
Вчера была встреча, на нее даже пришел их гендиректор. За время пресейла вы успели познакомиться с командой клиента, поэтому с удивлением отметили, что знаете не всех участников встречи — появился новый человек. Вам его представили как Рафи, он из Израиля. Гендиректор так объяснил его появление: “Мы занимаемся модой и не очень разбираемся в ИТ. Рафи же — эксперт в вашей сфере. Мы давно с ним знакомы, и пригласили его, чтобы быть уверенными, что вы все делаете хорошо. Рафи теперь член нашей команды.”
Вы — менеджер проектов в ИТ. Ваша компания пишет софт и внедряет его у крупных клиентов, помогает им автоматизировать разные процессы. Как раз недавно закончился длинный и сложный пресейл с одним из таких клиентов, компанией из индустрии моды. Вы готовитесь к старту проекта, согласуете договор и другие документы.
Вчера была встреча, на нее даже пришел их гендиректор. За время пресейла вы успели познакомиться с командой клиента, поэтому с удивлением отметили, что знаете не всех участников встречи — появился новый человек. Вам его представили как Рафи, он из Израиля. Гендиректор так объяснил его появление: “Мы занимаемся модой и не очень разбираемся в ИТ. Рафи же — эксперт в вашей сфере. Мы давно с ним знакомы, и пригласили его, чтобы быть уверенными, что вы все делаете хорошо. Рафи теперь член нашей команды.”
Комментарии к задачке, как обычно, послезавтра)
⚔ Комментарии к задачке 996-869
Вариант А никуда не годится — вы как менеджер не можете, не имеете права игнорировать попытку внести изменения в правила игры. Появление нового человека в команде, да еще и такого человека, к мнению которого прислушивается гендиректор, — это существенно. Только неопытный или безалаберный менеджер может этого не понимать. Так что следить за подобными изменениями и реагировать на них точно надо.
Вариант В, когда мы требуем убрать Рафи из проекта, прекрасен. Прекрасен, но абсолютно не выполним. Рафи уже в проекте, его участие согласовал гендиректор. Не исключено, что именно он Рафи туда и пригласил. Придется встречать новый вызов. А если вы будете скандалить и упорствовать, то проекта вообще может не быть — клиент решит, что дело тут нечисто, и вы пытаетесь что-то от него скрыть.
Радостный вариант С — попривествовать Рафи и надеяться на конструктивное сотрудничество, да еще и на обмен опытом, — выбирают обычно менеджеры, начитавшиеся вдохновляющих бизнес-книжек про розовых пони. Нет, друзья мои, не будет сотрудничества. Рафи — представитель клиента. Он не находится на вашей стороне с самого начала. Что еще хуже, в отличие от сотрудников клиента, Рафи абсолютно не заинтересован в том, чтобы проект состоялся. Рафи все равно, внедрите вы свой продукт или нет. Рафи ведь не работает в компании, ему не придется им пользоваться. Зато Рафи польщен, что его пригласили как эксперта. Не исключено, что он с гендиректором в близких отношениях. И уж точно Рафи неплохо на этой истории заработает. Все это будет мотивировать Рафи быть хорошим охранником — он будет стараться оправдать деньги и доверие. Он будет защищать компанию так, как ему кажется правильным. Баги в продукте? Нет, пусть исправят все, даже мелкие. Задержали очередную поставку на два дня? Штрафы пусть платят. И вообще, очень сомнительный продукт: архитектура не кажется оптимальной, да и на рынке наверняка есть лучше.
Все это вы поймаете по полной программе, так что дорога от розовых пони к кровавым слезам будет не слишком долгой. Вы же не этому хотели научиться?
Потому плох и вариант Е — не надо надеяться, что Рафи будет использовать свою экспертизу во благо проекта. Он будет использовать ее для своего блага и блага того, кто ему платит. А его воздействие на клиента может принести чудовищные последствия. И Рафи не виноват: он просто нахоится в такой роли. Если внедрят плохой продукт, его репутация эксперта будет запятнана. Допустит ли он это? Нет, он прератится в настоящего Цербера, не пропускающего даже малейшие недочеты в продукте, в вашей управленческой работе и в работе вашей команды.
Так что единственный способ хоть как-то работать с этим риском — выбрать вариант D и на уровне договора ограничить полномочия Рафи, четко обозначить его зону ответственности. Должно быть зафиксировано, что Рафи имеет право делать, а что нет. И где его полномочия заканчиваются. В противном случае вы будете выдавать результаты работы, а Рафи, как неубиваемый компьютерный монстр, будет находить в них все новые и новые ошибки, ставить под сомнение архитектуру продукта, используемые в нем технологии. Ну и вашу квалификацию. )
Если у вас в проекте появился такой Рафи, готовьтесь. Проект будет очень тяжелым и нервным. Очень.
Вариант А никуда не годится — вы как менеджер не можете, не имеете права игнорировать попытку внести изменения в правила игры. Появление нового человека в команде, да еще и такого человека, к мнению которого прислушивается гендиректор, — это существенно. Только неопытный или безалаберный менеджер может этого не понимать. Так что следить за подобными изменениями и реагировать на них точно надо.
Вариант В, когда мы требуем убрать Рафи из проекта, прекрасен. Прекрасен, но абсолютно не выполним. Рафи уже в проекте, его участие согласовал гендиректор. Не исключено, что именно он Рафи туда и пригласил. Придется встречать новый вызов. А если вы будете скандалить и упорствовать, то проекта вообще может не быть — клиент решит, что дело тут нечисто, и вы пытаетесь что-то от него скрыть.
Радостный вариант С — попривествовать Рафи и надеяться на конструктивное сотрудничество, да еще и на обмен опытом, — выбирают обычно менеджеры, начитавшиеся вдохновляющих бизнес-книжек про розовых пони. Нет, друзья мои, не будет сотрудничества. Рафи — представитель клиента. Он не находится на вашей стороне с самого начала. Что еще хуже, в отличие от сотрудников клиента, Рафи абсолютно не заинтересован в том, чтобы проект состоялся. Рафи все равно, внедрите вы свой продукт или нет. Рафи ведь не работает в компании, ему не придется им пользоваться. Зато Рафи польщен, что его пригласили как эксперта. Не исключено, что он с гендиректором в близких отношениях. И уж точно Рафи неплохо на этой истории заработает. Все это будет мотивировать Рафи быть хорошим охранником — он будет стараться оправдать деньги и доверие. Он будет защищать компанию так, как ему кажется правильным. Баги в продукте? Нет, пусть исправят все, даже мелкие. Задержали очередную поставку на два дня? Штрафы пусть платят. И вообще, очень сомнительный продукт: архитектура не кажется оптимальной, да и на рынке наверняка есть лучше.
Все это вы поймаете по полной программе, так что дорога от розовых пони к кровавым слезам будет не слишком долгой. Вы же не этому хотели научиться?
Потому плох и вариант Е — не надо надеяться, что Рафи будет использовать свою экспертизу во благо проекта. Он будет использовать ее для своего блага и блага того, кто ему платит. А его воздействие на клиента может принести чудовищные последствия. И Рафи не виноват: он просто нахоится в такой роли. Если внедрят плохой продукт, его репутация эксперта будет запятнана. Допустит ли он это? Нет, он прератится в настоящего Цербера, не пропускающего даже малейшие недочеты в продукте, в вашей управленческой работе и в работе вашей команды.
Так что единственный способ хоть как-то работать с этим риском — выбрать вариант D и на уровне договора ограничить полномочия Рафи, четко обозначить его зону ответственности. Должно быть зафиксировано, что Рафи имеет право делать, а что нет. И где его полномочия заканчиваются. В противном случае вы будете выдавать результаты работы, а Рафи, как неубиваемый компьютерный монстр, будет находить в них все новые и новые ошибки, ставить под сомнение архитектуру продукта, используемые в нем технологии. Ну и вашу квалификацию. )
Если у вас в проекте появился такой Рафи, готовьтесь. Проект будет очень тяжелым и нервным. Очень.
🏆 Лучше других
Философ Шарль де Монтескье говорил: “Если бы мы просто хотели быть счастливыми, достичь этого было бы легко; но мы хотим быть счастливее других людей, а это почти невозможно, поскольку нам всегда кажется, что другие счастливее нас”.
Не это ли суть рыночной борьбы, где каждой компании, пусть даже и создающей замечательный продукт, кажется, что у конкурентов он лучше? Не это ли основная проблема рабочей среды, где каждому сотруднику кажется, что у коллеги все лучше, а начальство эту уверенность подогревает? И можно ли в такой среде просто работать и просто делать хорошие продукты? Не стремясь превзойти кого-то, а делая свое дело качественно и с удовольствием.
И, главное, не должны ли менеджеры стараться такую среду создавать?
Если что, это был риторический вопрос. ) Но от этого только жальче.
Философ Шарль де Монтескье говорил: “Если бы мы просто хотели быть счастливыми, достичь этого было бы легко; но мы хотим быть счастливее других людей, а это почти невозможно, поскольку нам всегда кажется, что другие счастливее нас”.
Не это ли суть рыночной борьбы, где каждой компании, пусть даже и создающей замечательный продукт, кажется, что у конкурентов он лучше? Не это ли основная проблема рабочей среды, где каждому сотруднику кажется, что у коллеги все лучше, а начальство эту уверенность подогревает? И можно ли в такой среде просто работать и просто делать хорошие продукты? Не стремясь превзойти кого-то, а делая свое дело качественно и с удовольствием.
И, главное, не должны ли менеджеры стараться такую среду создавать?
Если что, это был риторический вопрос. ) Но от этого только жальче.
🏋🏾♀ Не совсем менеджеры
Одна из самых больших ошибок, которую может совершить менеджер проектов, особенно начинающий, — устроиться на работу, где он будет считаться менеджером, но выполнять будет и другие функции.
"Ты менеджер, но еще надо иногда программировать, ок?"
"Нам нужен РМ, который хорошо в бухгалтерии разбирается, чтобы бухгалтерам помогал. Им часто помощь нужна".
"Мы ищем играющего тренера! У нас не бывает иначе! Все должны работать на результат!"
Наемный менеджер или занимается управлением, или он не менеджер. Даже если его задачи управленческие на 99%, он не менеджер.
Если управленец хочет развиваться, придется избавиться от исполнительских задач.
Чтобы управлять какой-то системой, сначала надо перестать быть ее частью.
Одна из самых больших ошибок, которую может совершить менеджер проектов, особенно начинающий, — устроиться на работу, где он будет считаться менеджером, но выполнять будет и другие функции.
"Ты менеджер, но еще надо иногда программировать, ок?"
"Нам нужен РМ, который хорошо в бухгалтерии разбирается, чтобы бухгалтерам помогал. Им часто помощь нужна".
"Мы ищем играющего тренера! У нас не бывает иначе! Все должны работать на результат!"
Наемный менеджер или занимается управлением, или он не менеджер. Даже если его задачи управленческие на 99%, он не менеджер.
Если управленец хочет развиваться, придется избавиться от исполнительских задач.
Чтобы управлять какой-то системой, сначала надо перестать быть ее частью.
🧔🏼♀ Тренажер для менеджеров и не только 997-870
Вы — менеджер команды, которая создает хороший ИТ-продукт, востребованный отечественным рынком. Команда классная: профессиональная, сплоченная, мотивированная. Случайных людей в ней нет. Конфликты возникают редко, и вы хорошо умеете их разруливать.
Бизнес растет, продукт развивается, должна расти и команда. Сегодня у вас собеседование с кандидатом на позицию разработчика. Его зовут Ян, он неплохо справился с тестовым заданием. Ян уже ждет вас в переговорке.
“Перед началом собеседования я хочу вас проинформировать, что я гендерквир”, — говорит Ян. Вы просите уточнить, о чем речь. “Все просто, — поясняет Ян, — у меня небинарная гендерная идентичность. Это влияет, помимо всего прочего, на коммуникации. В третьем лице я прошу обращаться ко мне не “он” или “она”, а “они”. Это не значит, что обращаться ко мне нужно на “вы”, наверняка в команде так не принято. Но при обращении на “ты” все равно нужно использовать множественное число. Например: “Ян, ты уже сделали задачу? Да, я уже сделали и установили новую версию на тестовую среду”.
Вы в легком замешательстве: у вас нет подобного опыта. Вы аккуратно проводите интервью, обращаясь к Яну на “вы”. Ян неплох как специалист.
Вы — менеджер команды, которая создает хороший ИТ-продукт, востребованный отечественным рынком. Команда классная: профессиональная, сплоченная, мотивированная. Случайных людей в ней нет. Конфликты возникают редко, и вы хорошо умеете их разруливать.
Бизнес растет, продукт развивается, должна расти и команда. Сегодня у вас собеседование с кандидатом на позицию разработчика. Его зовут Ян, он неплохо справился с тестовым заданием. Ян уже ждет вас в переговорке.
“Перед началом собеседования я хочу вас проинформировать, что я гендерквир”, — говорит Ян. Вы просите уточнить, о чем речь. “Все просто, — поясняет Ян, — у меня небинарная гендерная идентичность. Это влияет, помимо всего прочего, на коммуникации. В третьем лице я прошу обращаться ко мне не “он” или “она”, а “они”. Это не значит, что обращаться ко мне нужно на “вы”, наверняка в команде так не принято. Но при обращении на “ты” все равно нужно использовать множественное число. Например: “Ян, ты уже сделали задачу? Да, я уже сделали и установили новую версию на тестовую среду”.
Вы в легком замешательстве: у вас нет подобного опыта. Вы аккуратно проводите интервью, обращаясь к Яну на “вы”. Ян неплох как специалист.
Комментарии к задачке, как обычно, послезавтра)
🛡 Комментарии к задачке 997-870
Вариант Е, когда вы пытаетесь принудить Яна быть как все, заведомо нерабочий. Может быть, у Яна есть основания считать себя тем, кем он представился. Может, у него таких оснований нет, а все это какая-то блажь. Но раз взрослый неглупый человек считает нужным начать собеседование с заявления о своих особенностях, вряд ли получится на них забить и потребовать у Яна не выделяться. Давить на людей можно, но зачем это делать в этом случае?
Вариант А, когда вы просто берете Яна в команду и принимаете новые для себя правила игры, плох. И не собственно решением, а тем, как и почему вы его приняли. Действительно, профессиональные качества человека важнее его расы, пола, политических и сексуальных предпочтений. Но важнее они ровно до того момента, пока не становятся препятствием в работе. И это всегда тонкий момент: где находится граница, за которой особенность человека перестает быть только его особенностью и становится проблемой для окружающих? “Согласны” Ян к вам пойти или нет, а о команде и продукте надо думать в первую очередь. )
Плох и вариант D — взять Яна ради интересного опыта и приоткрыть дверь ломящемуся в нее новому порядку. Задача менеджера — защищать свою команду, оберегать ее от потрясений, ведь их и так хваетет в динамичной и непредсказуемой проектной среде. Возможно, вас действительно позабавит этот эксперимент над командой, но укладывается ли он в понятие “защищать и оберегать”? Нет уж, пусть новый мир ломится в чью-то еще дверь.
Вариант С с жестким, даже грубым, отказом — не самый хороший. У вас может быть какой угодно взгляд на так любимые сегодня гендерные игры: вы можете принимать этих волшебных людей с рапростертыми объятиями, можете шипеть от злости и плевать им на ботинки, а можете быть к их проблемам совершенно равнодушны. Но вы точно не должны принимать управленческие решения на эмоциях, без анализа фактов и оценки рисков. И первый вопрос, который менеджер себе должен задать: “А что с этого будут иметь моя команда, мой продукт и лично я?”
Плох и вариант F: передать команде право решать. Мнение людей всегда интересно, но решение должны принимать вы и только вы. Представьте, что люди согласятся, что среди них появится Ян. А потом выяснится, что команда ошиблась, не хочет она подстраиваться под Яна. И вообще, смешно и нелепо это выглядит. А Ян-то уже работает. И кто со всем этим разбираться теперь будет? Команда? Нет конечно, вы будете. Что ж, пусть и решения будут вашими, а не чьими-то еще — вы же отвечаете за продукт и за людей перед руководством компании.
Так что наилучший вариант из предложенных — В. Не берем Яна, понимая, что риски ухудшения атмосферы в команде выше, чем выигрыш от найма. У вас уже есть сплоченная команда профи, которая работает хорошо. Берегите ее, защищайте от всего, что может эту хорошую работу разрушить. Неоднородность команды — это здорово и правильно, но у всего есть пределы: если неоднородность слишком высока, то она станет силой, которая разорвет вашу команду в клочья. Не допустите этого.
Вариант Е, когда вы пытаетесь принудить Яна быть как все, заведомо нерабочий. Может быть, у Яна есть основания считать себя тем, кем он представился. Может, у него таких оснований нет, а все это какая-то блажь. Но раз взрослый неглупый человек считает нужным начать собеседование с заявления о своих особенностях, вряд ли получится на них забить и потребовать у Яна не выделяться. Давить на людей можно, но зачем это делать в этом случае?
Вариант А, когда вы просто берете Яна в команду и принимаете новые для себя правила игры, плох. И не собственно решением, а тем, как и почему вы его приняли. Действительно, профессиональные качества человека важнее его расы, пола, политических и сексуальных предпочтений. Но важнее они ровно до того момента, пока не становятся препятствием в работе. И это всегда тонкий момент: где находится граница, за которой особенность человека перестает быть только его особенностью и становится проблемой для окружающих? “Согласны” Ян к вам пойти или нет, а о команде и продукте надо думать в первую очередь. )
Плох и вариант D — взять Яна ради интересного опыта и приоткрыть дверь ломящемуся в нее новому порядку. Задача менеджера — защищать свою команду, оберегать ее от потрясений, ведь их и так хваетет в динамичной и непредсказуемой проектной среде. Возможно, вас действительно позабавит этот эксперимент над командой, но укладывается ли он в понятие “защищать и оберегать”? Нет уж, пусть новый мир ломится в чью-то еще дверь.
Вариант С с жестким, даже грубым, отказом — не самый хороший. У вас может быть какой угодно взгляд на так любимые сегодня гендерные игры: вы можете принимать этих волшебных людей с рапростертыми объятиями, можете шипеть от злости и плевать им на ботинки, а можете быть к их проблемам совершенно равнодушны. Но вы точно не должны принимать управленческие решения на эмоциях, без анализа фактов и оценки рисков. И первый вопрос, который менеджер себе должен задать: “А что с этого будут иметь моя команда, мой продукт и лично я?”
Плох и вариант F: передать команде право решать. Мнение людей всегда интересно, но решение должны принимать вы и только вы. Представьте, что люди согласятся, что среди них появится Ян. А потом выяснится, что команда ошиблась, не хочет она подстраиваться под Яна. И вообще, смешно и нелепо это выглядит. А Ян-то уже работает. И кто со всем этим разбираться теперь будет? Команда? Нет конечно, вы будете. Что ж, пусть и решения будут вашими, а не чьими-то еще — вы же отвечаете за продукт и за людей перед руководством компании.
Так что наилучший вариант из предложенных — В. Не берем Яна, понимая, что риски ухудшения атмосферы в команде выше, чем выигрыш от найма. У вас уже есть сплоченная команда профи, которая работает хорошо. Берегите ее, защищайте от всего, что может эту хорошую работу разрушить. Неоднородность команды — это здорово и правильно, но у всего есть пределы: если неоднородность слишком высока, то она станет силой, которая разорвет вашу команду в клочья. Не допустите этого.
🖋 Сила поэзии
Один менеджер, большой любитель поэзии, придумал такую штуку: каждый понедельник он рассылал своей команде стихотворение. Он выбирал что-то необычное, малоизвестного автора, интересное. И, конечно, не слишком длинное, серьезное и занудное.
Сначала команда встретила эту инициативу равнодушно. Кто-то крутил пальцем у виска. Но прошло несколько недель, и люди уже с удовольствием ждали очередной порции высокой литературы в почтовых ящиках. Радовались даже те, кто был уверен, что терпеть не может стихи.
Помните, в одной из книг ДеМарко описан проект, в котором команда тестирования стала носить черные футболки, чтобы подчеркнуть свою уникальность? Примерно то же произошло со стихами — они стали фишкой команды. Их обсуждали за обедом, цитаты из них вспоминали на совещаниях. С такой вот интонацией и улыбкой, дескать, это только свои поймут.
И после завершения проекта люди просили не исключать их из поэтической рассылки. А хитрый менеджер говорил: "Я подумаю... Это ведь не для всех, понимаешь... Но у меня скоро стартует проект, а ты на прошлом хорошо поработал, может, пойдешь ко мне опять?"
Другие менеджеры пытались повторить этот успешный опыт, но не преуспели. Ни музыкальные видеоклипы, ни репродукции картин, ни мемы из интернета у сотрудников интереса не вызвали.
Видимо, в стихах есть своя магия. )
Один менеджер, большой любитель поэзии, придумал такую штуку: каждый понедельник он рассылал своей команде стихотворение. Он выбирал что-то необычное, малоизвестного автора, интересное. И, конечно, не слишком длинное, серьезное и занудное.
Сначала команда встретила эту инициативу равнодушно. Кто-то крутил пальцем у виска. Но прошло несколько недель, и люди уже с удовольствием ждали очередной порции высокой литературы в почтовых ящиках. Радовались даже те, кто был уверен, что терпеть не может стихи.
Помните, в одной из книг ДеМарко описан проект, в котором команда тестирования стала носить черные футболки, чтобы подчеркнуть свою уникальность? Примерно то же произошло со стихами — они стали фишкой команды. Их обсуждали за обедом, цитаты из них вспоминали на совещаниях. С такой вот интонацией и улыбкой, дескать, это только свои поймут.
И после завершения проекта люди просили не исключать их из поэтической рассылки. А хитрый менеджер говорил: "Я подумаю... Это ведь не для всех, понимаешь... Но у меня скоро стартует проект, а ты на прошлом хорошо поработал, может, пойдешь ко мне опять?"
Другие менеджеры пытались повторить этот успешный опыт, но не преуспели. Ни музыкальные видеоклипы, ни репродукции картин, ни мемы из интернета у сотрудников интереса не вызвали.
Видимо, в стихах есть своя магия. )
🥅 Командный результат
Представьте: вы — нападающий хоккейной команды. Идет важнейший матч, на кону судьба главного приза сезона. Вот вы получаете шайбу от партнера, прорываетесь в чужую зону, выходите один на один с вратарем и... гол! А через три минуты забиваете второй! А через пять минут — третий!
Но в итоге ваша команда проигрывает со счетом 7:3. Все, кубок упущен, соперник празднует победу.
Теперь представьте, что вы — тренер проигравшей команды. Что вы чувствуете? Да, у вас есть классный игрок, который умудрился забить целых три гола. Игрок-звезда, мегаталантливый и ультрамотивированный. И что? Кому интересны эти голы, когда командный результат не оправдывает ожиданий владельцев команды и ее болельщиков? При этом к талантливому нападающему какие претензии? Он-то свою часть работы делает прекрасно.
Но этого мало. Нужен не индивидуальный результат, а командный. Точно так же, как при работе проектной команды, при создании продукта. Командный результат — всегда на первом месте. И только на втором — оценка вклада сотрудника в этот общий результат. И бонусы должны быть устроены так, чтобы премия за командное достижение была огромной, а за индивидуальное — смехотворно малой. И тогда будет больше шансов сделать сообща хороший продукт. И будет гораздо меньше ситуаций, когда каждый сотрудник вроде неплох, а все вместе они — негодная команда.
Это и есть настоящий тимбилдинг. Ну, или смотрите, как соперник поднимает над головой ваш кубок.
Представьте: вы — нападающий хоккейной команды. Идет важнейший матч, на кону судьба главного приза сезона. Вот вы получаете шайбу от партнера, прорываетесь в чужую зону, выходите один на один с вратарем и... гол! А через три минуты забиваете второй! А через пять минут — третий!
Но в итоге ваша команда проигрывает со счетом 7:3. Все, кубок упущен, соперник празднует победу.
Теперь представьте, что вы — тренер проигравшей команды. Что вы чувствуете? Да, у вас есть классный игрок, который умудрился забить целых три гола. Игрок-звезда, мегаталантливый и ультрамотивированный. И что? Кому интересны эти голы, когда командный результат не оправдывает ожиданий владельцев команды и ее болельщиков? При этом к талантливому нападающему какие претензии? Он-то свою часть работы делает прекрасно.
Но этого мало. Нужен не индивидуальный результат, а командный. Точно так же, как при работе проектной команды, при создании продукта. Командный результат — всегда на первом месте. И только на втором — оценка вклада сотрудника в этот общий результат. И бонусы должны быть устроены так, чтобы премия за командное достижение была огромной, а за индивидуальное — смехотворно малой. И тогда будет больше шансов сделать сообща хороший продукт. И будет гораздо меньше ситуаций, когда каждый сотрудник вроде неплох, а все вместе они — негодная команда.
Это и есть настоящий тимбилдинг. Ну, или смотрите, как соперник поднимает над головой ваш кубок.
🧪 Люди без фантазии
Услышал в лифте большого бизнес-центра:
— Все эти стартаперы — люди без фантазии. Им непременно надо сделать руками, а потом и потрогать то, что другие могут просто вообразить. Именно это их и мотивирует!
Что ж, поменьше нам фантазеров и побольше таких вот менеджеров без фантазии. Чтобы не успокаивались, пока результат работы не потрогают. И лишь для того, чтобы понять, как сделать еще лучше. )
Услышал в лифте большого бизнес-центра:
— Все эти стартаперы — люди без фантазии. Им непременно надо сделать руками, а потом и потрогать то, что другие могут просто вообразить. Именно это их и мотивирует!
Что ж, поменьше нам фантазеров и побольше таких вот менеджеров без фантазии. Чтобы не успокаивались, пока результат работы не потрогают. И лишь для того, чтобы понять, как сделать еще лучше. )
🏜 Удаленка навсегда
Времена нынче турбулентные, но хоть пандемия закончилась (вроде бы). И сразу в разных ИТ-компаниях зазвучал один и тот же уверенный глас эйчаров: “Пора возвращаться в офис!”
Призыв этот несколько удивляет. Как возвращаться-то? Как будто люди отошли на минутку покурить. Но это же не так. Прошло больше двух лет. Изменилось решительно все: распределение задач в течение дня, способы общения сотрудников, подходы к контролю со стороны менеджеров, быт.
И ошибкой будет думать, что люди просто вернутся в офис, и все пойдет по-старому.
Компания, если она хочет не просто выживать, должна изменить подход к работе: быстро обучать новых сотрудников, сокращая до минимума время адаптации. Чем хорош Макдоналдс? Тем, что он собаку на этом съел. Было ли когда-нибудь, чтобы вы подошли к кассе, а вам сказали: “Сорри, это стажер, он пока учится, поэтому картошка будет не жареной, а вареной”? Макдоналдс умеет, и ИТ-компании должны учиться. Если менеджеры, особенно в среднем управленческом слое, не уделяют этому внимания, это хреновые менеджеры. Каждая компания должна придумать и развить удобную для себя систему адаптации — на всех уровнях, для всех сотрудников. И тогда в офис можно не возвращаться.
Будущее не за офисами. Стол для пинг-понга, туманная цитата из Джобса на стене и яркие пуфики? Да кому это сейчас нужно.
Времена нынче турбулентные, но хоть пандемия закончилась (вроде бы). И сразу в разных ИТ-компаниях зазвучал один и тот же уверенный глас эйчаров: “Пора возвращаться в офис!”
Призыв этот несколько удивляет. Как возвращаться-то? Как будто люди отошли на минутку покурить. Но это же не так. Прошло больше двух лет. Изменилось решительно все: распределение задач в течение дня, способы общения сотрудников, подходы к контролю со стороны менеджеров, быт.
И ошибкой будет думать, что люди просто вернутся в офис, и все пойдет по-старому.
Компания, если она хочет не просто выживать, должна изменить подход к работе: быстро обучать новых сотрудников, сокращая до минимума время адаптации. Чем хорош Макдоналдс? Тем, что он собаку на этом съел. Было ли когда-нибудь, чтобы вы подошли к кассе, а вам сказали: “Сорри, это стажер, он пока учится, поэтому картошка будет не жареной, а вареной”? Макдоналдс умеет, и ИТ-компании должны учиться. Если менеджеры, особенно в среднем управленческом слое, не уделяют этому внимания, это хреновые менеджеры. Каждая компания должна придумать и развить удобную для себя систему адаптации — на всех уровнях, для всех сотрудников. И тогда в офис можно не возвращаться.
Будущее не за офисами. Стол для пинг-понга, туманная цитата из Джобса на стене и яркие пуфики? Да кому это сейчас нужно.
📅 Тренажер для менеджеров и не только 998-871
Вы — менеджер внутреннего проекта в большой организации. Вы создаете систему “Ю-1”, которая поможет юристам компании быстро и удобно работать с электронными документами.
В компании есть еще один важный внутренний проект, которым управляет менеджер Лида. Она со своей командой внедряет систему “Б-1” — для автоматизации каких-то процессов у бухгалтеров. С Лидой у вас прекрасные отношения и полное взаимоуважение.
В обеих системах встречаются похожие функции. Вы с Лидой договорились, какие из них будут сделаны в системе “Ю-1”, а какие в “Б-1”. Это поможет сэкономить на работах — не придется делать функцию, если она уже сделана в другой системе.
До плановой даты завершения вашего проекта осталось 3 дня. Проект Лиды должен завершиться через 8 дней.
Сегодня было совещание, на котором выяснилось, что Лида забыла отдать в разработку одну функцию. Для вашей системы эта функция не очень важна. А вот система Лиды без этой функции бесполезна.
Чтобы сделать эту функцию в вашей системе, нужно 3 дня. В Лидиной системе на эту функцию придется потратить 12 дней. Лида умоляет вас сделать эту функцию в вашей системе, ведь так быстрее.
Вы — менеджер внутреннего проекта в большой организации. Вы создаете систему “Ю-1”, которая поможет юристам компании быстро и удобно работать с электронными документами.
В компании есть еще один важный внутренний проект, которым управляет менеджер Лида. Она со своей командой внедряет систему “Б-1” — для автоматизации каких-то процессов у бухгалтеров. С Лидой у вас прекрасные отношения и полное взаимоуважение.
В обеих системах встречаются похожие функции. Вы с Лидой договорились, какие из них будут сделаны в системе “Ю-1”, а какие в “Б-1”. Это поможет сэкономить на работах — не придется делать функцию, если она уже сделана в другой системе.
До плановой даты завершения вашего проекта осталось 3 дня. Проект Лиды должен завершиться через 8 дней.
Сегодня было совещание, на котором выяснилось, что Лида забыла отдать в разработку одну функцию. Для вашей системы эта функция не очень важна. А вот система Лиды без этой функции бесполезна.
Чтобы сделать эту функцию в вашей системе, нужно 3 дня. В Лидиной системе на эту функцию придется потратить 12 дней. Лида умоляет вас сделать эту функцию в вашей системе, ведь так быстрее.
Комментарии к задачке, как обычно, послезавтра)
📽 Падение Токио
Рекомендую всем менеджерам кинцо “Tokyo Shaking”, название которого у нас почему-то перевели как "Падение Токио". Его художественные достоинства измеряются отрицательными величинами, но это компенсируется любопытным кейсом.
Главная героиня, эксперт по управлению рисками, оказывается в ситуации, когда ее навыки могут пригодиться. То, как она думает и действует, как раз и есть причина этот фильм посмотреть.
Там еще есть про корпоративную культуру и этику, но стратегия главной героини это все затмевает. )
Рекомендую всем менеджерам кинцо “Tokyo Shaking”, название которого у нас почему-то перевели как "Падение Токио". Его художественные достоинства измеряются отрицательными величинами, но это компенсируется любопытным кейсом.
Главная героиня, эксперт по управлению рисками, оказывается в ситуации, когда ее навыки могут пригодиться. То, как она думает и действует, как раз и есть причина этот фильм посмотреть.
Там еще есть про корпоративную культуру и этику, но стратегия главной героини это все затмевает. )
🦸🏽♂ Комментарии к задачке 998-871
Вариант С плох. Конечно, Лида сама виновата, что забыла про важную функцию. Но отказывать ей с формулировкой “теперь страдай” не по-людски. У вас же нет цели воспитывать Лиду и учить ее быть внимательной. Можете помочь — помогите, не можете или не хотите — не помогайте. Но устраивать из этого воспитательный акт? Все ошибаются, и в следующий раз вы с Лидой можете поменяться местами.
Вариант В плох. Да, с Лидой вам еще работать, и отношения с ней поддерживать тоже нужно. Но не следует принимать решение о выделении ресурсов для задачи только лишь на основании того, что кто-то человек хороший. Хороших людей, которым можно помочь, всегда больше, чем ресурсов. Точно вам говорю.
Плох и вариант А — взять задачу только потому, что вы с Лидой “делаете общее дело” и работаете на благо компании. Это обычно одно из самых шокирующих открытий для человека, попадающего в большую компанию: оказывается, внутри нее существует конкуренция за ресурсы, политика, борьба подразделений, а иногда и открытая вражда. И даже если до противостояния дело не дошло, урвать себе ресурсов каждый хочет. Так всегда было, есть и будет. Поэтому не забывайте: есть ваш проект, а есть Лидин. У каждого из этих проектов есть цели, состав работ, сроки и бюджет. Очень классно, если вы с Лидой сумели договориться о чем-то и поработать вместе. Но ответственность за проекты ни с вас, ни с Лиды это не снимает. Вы менеджер, вам доверили важный для компании участок работ. Рисковать сроками своего проекта никак нельзя. Вообразите ситуацию: у вас что-то пошло не так, функцию вы сделали не за ожидаемые три дня, а за пять. А у компании были планы, завязанные на ваш проект. Вам плохо, компании плохо. А Лида еще на ближайшем совещании с высоким начальством говорит: “Ну, мой проект в хорошей форме, я все успеваю. А что там в другом проекте, и почему они затягивают с этой функцией — ума не приложу.” И что вы скажете в ответ? Вы ж сами за эту функцию взялись. Зачем вам так рисковать?
Потому плох и вариант Е, когда вы соглашаетесь делать функцию в обмен на какую-то услугу от Лиды в будущем. Может, Лида человека слова, и однажды вы эту мифическую услугу получите, а, может, и нет. А вдруг случая не представиться? Вдруг Лида через месяц уйдет в другую компанию? Она сейчас в отчаянном положении, готова согласиться на все. Когда задачу сделают, тучи на головой Лиды рассеются, будет ли она так же сговорчива? Такие договоренности хорошо работают между героями сериала Suits, но не слишком надежны реальной проектной жизни. Да и ваши риски загубить свой проект крайне высоки.
Так что не раздумывайте в этой ситуации долго, всегда выбирайте вариант D. Да, придется Лиде отказать. Но, если она действительно хороший менеджер и человек, то должна знать, что не всегда удается получить желаемое. А для вас как для менеджера важнее не побыть хорошим в этой истории, а вовремя завершить свой проект.
Правило простое: есть возможность помочь коллеге, не подвергая рискам свои задачи, — нужно помочь. Но не ставьте свой проект под угрозу, даже если с Лидой приятно поболтать за чашкой кофе. Сначала вы заботитесь о своем результате, о своем проекте, о себе, и только потом обо всем остальном. Не наоборот.
Вариант С плох. Конечно, Лида сама виновата, что забыла про важную функцию. Но отказывать ей с формулировкой “теперь страдай” не по-людски. У вас же нет цели воспитывать Лиду и учить ее быть внимательной. Можете помочь — помогите, не можете или не хотите — не помогайте. Но устраивать из этого воспитательный акт? Все ошибаются, и в следующий раз вы с Лидой можете поменяться местами.
Вариант В плох. Да, с Лидой вам еще работать, и отношения с ней поддерживать тоже нужно. Но не следует принимать решение о выделении ресурсов для задачи только лишь на основании того, что кто-то человек хороший. Хороших людей, которым можно помочь, всегда больше, чем ресурсов. Точно вам говорю.
Плох и вариант А — взять задачу только потому, что вы с Лидой “делаете общее дело” и работаете на благо компании. Это обычно одно из самых шокирующих открытий для человека, попадающего в большую компанию: оказывается, внутри нее существует конкуренция за ресурсы, политика, борьба подразделений, а иногда и открытая вражда. И даже если до противостояния дело не дошло, урвать себе ресурсов каждый хочет. Так всегда было, есть и будет. Поэтому не забывайте: есть ваш проект, а есть Лидин. У каждого из этих проектов есть цели, состав работ, сроки и бюджет. Очень классно, если вы с Лидой сумели договориться о чем-то и поработать вместе. Но ответственность за проекты ни с вас, ни с Лиды это не снимает. Вы менеджер, вам доверили важный для компании участок работ. Рисковать сроками своего проекта никак нельзя. Вообразите ситуацию: у вас что-то пошло не так, функцию вы сделали не за ожидаемые три дня, а за пять. А у компании были планы, завязанные на ваш проект. Вам плохо, компании плохо. А Лида еще на ближайшем совещании с высоким начальством говорит: “Ну, мой проект в хорошей форме, я все успеваю. А что там в другом проекте, и почему они затягивают с этой функцией — ума не приложу.” И что вы скажете в ответ? Вы ж сами за эту функцию взялись. Зачем вам так рисковать?
Потому плох и вариант Е, когда вы соглашаетесь делать функцию в обмен на какую-то услугу от Лиды в будущем. Может, Лида человека слова, и однажды вы эту мифическую услугу получите, а, может, и нет. А вдруг случая не представиться? Вдруг Лида через месяц уйдет в другую компанию? Она сейчас в отчаянном положении, готова согласиться на все. Когда задачу сделают, тучи на головой Лиды рассеются, будет ли она так же сговорчива? Такие договоренности хорошо работают между героями сериала Suits, но не слишком надежны реальной проектной жизни. Да и ваши риски загубить свой проект крайне высоки.
Так что не раздумывайте в этой ситуации долго, всегда выбирайте вариант D. Да, придется Лиде отказать. Но, если она действительно хороший менеджер и человек, то должна знать, что не всегда удается получить желаемое. А для вас как для менеджера важнее не побыть хорошим в этой истории, а вовремя завершить свой проект.
Правило простое: есть возможность помочь коллеге, не подвергая рискам свои задачи, — нужно помочь. Но не ставьте свой проект под угрозу, даже если с Лидой приятно поболтать за чашкой кофе. Сначала вы заботитесь о своем результате, о своем проекте, о себе, и только потом обо всем остальном. Не наоборот.
🤖 Техническая вменяемость
Придумал термин: “техническая вменяемость”. Это когда для старта работы нужно не техническое образование и не технический опыт. И даже не техническая грамотность.
Это когда человек может вообще не иметь представления о технической сущности, но при этом способен осознанно с ней взаимодействовать, понимать последствия своих действий и управлять ими.
Очень важное качество для всех начинающих спецов. Почти в любой айтишной профессии.
В наш век каждый должен быть технически вменяем.
Придумал термин: “техническая вменяемость”. Это когда для старта работы нужно не техническое образование и не технический опыт. И даже не техническая грамотность.
Это когда человек может вообще не иметь представления о технической сущности, но при этом способен осознанно с ней взаимодействовать, понимать последствия своих действий и управлять ими.
Очень важное качество для всех начинающих спецов. Почти в любой айтишной профессии.
В наш век каждый должен быть технически вменяем.
