Комментарии к задачке, как обычно, послезавтра)
🦧 Комментарии к задачке 953-826
Выбирать вариант G и затевать диалог с Маратом бессмысленно. Он уже показал себя беспомощным менеджером и недалеким человеком. Зачем еще что-то обсуждать? Поэтому и искать ошибки в работе Евгении столь же бесполезно, вариант Е не годится. Общение с Маратом теряет смысл после балагана, в который он превратил не самую сложную проблему.
Плох и вариант B. Разговаривать с Евгенией — играть по правилам Марата. Если же она сама к вам придет на переговоры, вести их не стоит.
Вариант С — странный. Получить поддержку коллег так не получится, всем на вас плевать, если только они сами не участвуют в битве за железный трон. Да и в чем бы эта поддержка выражалась?
Вариант F не соответствует условию — вам хочется эту должность, вы не готовы подарить ее сопернику.
В варианте D, на первый взгляд, смысл есть. Но чего мы можем добиться, эскалируя проблему высокому начальству? Оно же терпит Марата в компании. В лучшем случае, вы окажетесь в ситуации “мое слово против слова Марата”, и победу вам никто не гарантирует.
Вариант H — это какая-то утопия. У вас нет полномочий для проведения выборов, да и где вы видели, чтобы руководителя выбирали? Игры в демократию в компании обычно заканчиваются анархией и массовыми сокращениями.
Так что правильный выбор — вариант А. Можно работать в компании, где люди делают ошибки. Но нельзя работать там, где управленческие ошибки совершаются на таком высоком уровне и в таких вопросах. Это уже сбой в системе, и ваше сотрудничество с ней ничего хорошего не сулит. Валить, однозначно.
В реальности менеджер выбрал странный вариант С — распустил слух, что именно он теперь начальник отдела и решил, что предъявит этот аргумент Марату. Марат вернулся из отпуска и... передумал вообще кого-то назначать. Нет начальника — и ладно. Евгения забила на работу и через полтора месяца уволилась. Через три с небольшим уволился менеджер. У отдела не было начальника около года, и обсуждать даже мелкие проблемы сотрудникам пришлось с Маратом лично. Когда люди вкусили этого общения, они тоже потихоньку стали уходить.
Когда обсуждают управленческие проблемы, часто говорят о важности найма хороших исполнителей. Но подобрать хороших управленцев не менее важно. Нельзя об этом забывать.
Менеджеры должны устранять конфликты, а не создавать их.
Выбирать вариант G и затевать диалог с Маратом бессмысленно. Он уже показал себя беспомощным менеджером и недалеким человеком. Зачем еще что-то обсуждать? Поэтому и искать ошибки в работе Евгении столь же бесполезно, вариант Е не годится. Общение с Маратом теряет смысл после балагана, в который он превратил не самую сложную проблему.
Плох и вариант B. Разговаривать с Евгенией — играть по правилам Марата. Если же она сама к вам придет на переговоры, вести их не стоит.
Вариант С — странный. Получить поддержку коллег так не получится, всем на вас плевать, если только они сами не участвуют в битве за железный трон. Да и в чем бы эта поддержка выражалась?
Вариант F не соответствует условию — вам хочется эту должность, вы не готовы подарить ее сопернику.
В варианте D, на первый взгляд, смысл есть. Но чего мы можем добиться, эскалируя проблему высокому начальству? Оно же терпит Марата в компании. В лучшем случае, вы окажетесь в ситуации “мое слово против слова Марата”, и победу вам никто не гарантирует.
Вариант H — это какая-то утопия. У вас нет полномочий для проведения выборов, да и где вы видели, чтобы руководителя выбирали? Игры в демократию в компании обычно заканчиваются анархией и массовыми сокращениями.
Так что правильный выбор — вариант А. Можно работать в компании, где люди делают ошибки. Но нельзя работать там, где управленческие ошибки совершаются на таком высоком уровне и в таких вопросах. Это уже сбой в системе, и ваше сотрудничество с ней ничего хорошего не сулит. Валить, однозначно.
В реальности менеджер выбрал странный вариант С — распустил слух, что именно он теперь начальник отдела и решил, что предъявит этот аргумент Марату. Марат вернулся из отпуска и... передумал вообще кого-то назначать. Нет начальника — и ладно. Евгения забила на работу и через полтора месяца уволилась. Через три с небольшим уволился менеджер. У отдела не было начальника около года, и обсуждать даже мелкие проблемы сотрудникам пришлось с Маратом лично. Когда люди вкусили этого общения, они тоже потихоньку стали уходить.
Когда обсуждают управленческие проблемы, часто говорят о важности найма хороших исполнителей. Но подобрать хороших управленцев не менее важно. Нельзя об этом забывать.
Менеджеры должны устранять конфликты, а не создавать их.
🦸🏾♀ Спрашивали — отвечаем 23
“Сергей, вы много говорите об управлении исполнителями. А какие рекомендации вы могли бы дать по управлению менеджерами?”
Управлять менеджерами очень просто. Есть прекрасный алгоритм:
1. Наймите нормального менеджера. Нормальный менеджер — умный, умеет решать проблемы, достигать результата и работать с людьми. И при этом он не чудак на букву “м”.
2. Сформулируйте цель. Желательно крупную, менеджеры любят большие цели.
3. Договоритесь с ним о критериях достижения цели и об основных вехах на пути к ней.
4. Спросите, какие ресурсы нужны менеджеру для достижения цели. Выделите ему эти ресурсы или скажите, где взять.
5. Скажите, что готовы помочь, если менеджер попросит.
6. Оставьте его с задачей один на один. И не лезьте, даже если очень хочется.
Если он не готов работать по этому алгоритму, то это не слишком хороший менеджер. Надо ему еще подучиться.
Если вы не готовы работать по этому алгоритму, то вам тем более надо учиться.
“Сергей, вы много говорите об управлении исполнителями. А какие рекомендации вы могли бы дать по управлению менеджерами?”
Управлять менеджерами очень просто. Есть прекрасный алгоритм:
1. Наймите нормального менеджера. Нормальный менеджер — умный, умеет решать проблемы, достигать результата и работать с людьми. И при этом он не чудак на букву “м”.
2. Сформулируйте цель. Желательно крупную, менеджеры любят большие цели.
3. Договоритесь с ним о критериях достижения цели и об основных вехах на пути к ней.
4. Спросите, какие ресурсы нужны менеджеру для достижения цели. Выделите ему эти ресурсы или скажите, где взять.
5. Скажите, что готовы помочь, если менеджер попросит.
6. Оставьте его с задачей один на один. И не лезьте, даже если очень хочется.
Если он не готов работать по этому алгоритму, то это не слишком хороший менеджер. Надо ему еще подучиться.
Если вы не готовы работать по этому алгоритму, то вам тем более надо учиться.
🏋🏽♀ Тренажер для менеджеров и не только 14-217
Вы — руководитель отдела из девяти человек в небольшой компании. Компания работает с крупными торговыми сетями, и ваш отдел — ключевое звено всех процессов.
Работая в компании четыре года, вы как менеджер добились многого: отдел хорошо справляется с задачами, клиенты очень довольны. У вас тут далеко не Гугл — нет ни гениев, ни высоких зарплат, ни космических задач. В отделе работают довольно средние люди. Но вы потратили много сил на их обучение и не прекращаете это делать: следите за развитием, регулярно проводите для них тренинги, вовремя даете обратную связь.
Вы — образец дисциплинированного человека. Важность этого качества вы усвоили еще в школе, когда серьезно занимались спортом. Вы уверены, что дисциплина и ответственность — ключ к успеху. Так что в отделе царит культ дисциплины. И это очень ценят клиенты.
Нет-нет, вы не зверствуете, всегда готовы пойти сотруднику навстречу. Вас, наверное, можно сравнить с учительницей советской закалки, «строгой, но справедливой». В отделе царит спокойная и доброжелательная рабочая атмосфера, текучки нет. Бизнес идет неплохо, и вы нанимаете еще одну сотрудницу.
Ее зовут Саша, она недавно переехала с семьей в ваш город. На интервью Саша продемонстрировала отличные знания, а в разговоре показалась вам приятным и доброжелательным человеком. Она приступила к работе, и вы быстро поняли, что вам достался настоящий клад — Саша решает поставленные задачи быстрее и качественнее любого вашего сотрудника, да и в коллективе она быстро адаптировалась.
Проблема пришла оттуда, откуда вы ее не ждали.
Саша никогда не приходит в офис вовремя, а уходит тогда, когда ей вздумается. Сначала вы списывали это на адаптацию. Но, спустя несколько недель, понимаете, что адаптация тут ни при чем. Удивительно, но Саша, несмотря на сокращенное время работы, выполняет примерно на 25% задач больше, чем самый лучший сотрудник отдела.
Видя, что Саше сходят с рук нарушения, остальные сотрудники начали думать, что тоже могут вести себя, как она. Но они-то не так умны и эффективны!
Вы разговариваете с Сашей, хвалите ее за отличную работу. А потом мягко сообщаете, что дисциплина и соблюдение графика — важная составляющая корпоративной культуры отдела. И просите Сашу соблюдать эти правила. Но она как будто вас не понимает. Саша интересуется, есть ли претензии к скорости и качеству ее работы. Вы честно отвечаете, что ей все довольны. «Тогда в чем вопрос-то?», — недоумевает Саша. Вы говорите о работе отдела в целом, но опять не встречаете понимания. Аргументы исчерпаны.
Но проблема-то осталась. Вы стараетесь ее решить: даете Саше больше задач. Она спокойно со всем справляется. А когда число ее проектов становится близким к десяти, при том что у остальных сотрудников их не больше трех, вы понимаете, что это не метод.
Вы готовы дать Саше полномочия руководителя и своего заместителя, раз она такая талантливая. Но она отвечает, что ей это неинтересно, ей нравится решать задачи. Ее все устраивает: и отдел, и вы как руководитель, и задачи, и город, и компания.
Вы нервничаете. Производительность отдела падает, рабочая атмосфера рушится.
Вы — руководитель отдела из девяти человек в небольшой компании. Компания работает с крупными торговыми сетями, и ваш отдел — ключевое звено всех процессов.
Работая в компании четыре года, вы как менеджер добились многого: отдел хорошо справляется с задачами, клиенты очень довольны. У вас тут далеко не Гугл — нет ни гениев, ни высоких зарплат, ни космических задач. В отделе работают довольно средние люди. Но вы потратили много сил на их обучение и не прекращаете это делать: следите за развитием, регулярно проводите для них тренинги, вовремя даете обратную связь.
Вы — образец дисциплинированного человека. Важность этого качества вы усвоили еще в школе, когда серьезно занимались спортом. Вы уверены, что дисциплина и ответственность — ключ к успеху. Так что в отделе царит культ дисциплины. И это очень ценят клиенты.
Нет-нет, вы не зверствуете, всегда готовы пойти сотруднику навстречу. Вас, наверное, можно сравнить с учительницей советской закалки, «строгой, но справедливой». В отделе царит спокойная и доброжелательная рабочая атмосфера, текучки нет. Бизнес идет неплохо, и вы нанимаете еще одну сотрудницу.
Ее зовут Саша, она недавно переехала с семьей в ваш город. На интервью Саша продемонстрировала отличные знания, а в разговоре показалась вам приятным и доброжелательным человеком. Она приступила к работе, и вы быстро поняли, что вам достался настоящий клад — Саша решает поставленные задачи быстрее и качественнее любого вашего сотрудника, да и в коллективе она быстро адаптировалась.
Проблема пришла оттуда, откуда вы ее не ждали.
Саша никогда не приходит в офис вовремя, а уходит тогда, когда ей вздумается. Сначала вы списывали это на адаптацию. Но, спустя несколько недель, понимаете, что адаптация тут ни при чем. Удивительно, но Саша, несмотря на сокращенное время работы, выполняет примерно на 25% задач больше, чем самый лучший сотрудник отдела.
Видя, что Саше сходят с рук нарушения, остальные сотрудники начали думать, что тоже могут вести себя, как она. Но они-то не так умны и эффективны!
Вы разговариваете с Сашей, хвалите ее за отличную работу. А потом мягко сообщаете, что дисциплина и соблюдение графика — важная составляющая корпоративной культуры отдела. И просите Сашу соблюдать эти правила. Но она как будто вас не понимает. Саша интересуется, есть ли претензии к скорости и качеству ее работы. Вы честно отвечаете, что ей все довольны. «Тогда в чем вопрос-то?», — недоумевает Саша. Вы говорите о работе отдела в целом, но опять не встречаете понимания. Аргументы исчерпаны.
Но проблема-то осталась. Вы стараетесь ее решить: даете Саше больше задач. Она спокойно со всем справляется. А когда число ее проектов становится близким к десяти, при том что у остальных сотрудников их не больше трех, вы понимаете, что это не метод.
Вы готовы дать Саше полномочия руководителя и своего заместителя, раз она такая талантливая. Но она отвечает, что ей это неинтересно, ей нравится решать задачи. Ее все устраивает: и отдел, и вы как руководитель, и задачи, и город, и компания.
Вы нервничаете. Производительность отдела падает, рабочая атмосфера рушится.
Комментарии к задачке, как обычно, послезавтра)
👩🏽💻 Комментарии к задачке 14-217
Вариант А плох для всех: и Саша страдает, и у вас проблема с отделом осталась. Да и разве по-менеджерски это — ничего не делать?
Вариант D — путь в никуда. Подавляя и демотивируя Сашу, мы добьемся того, что она станет как все, но раздраженной и с тоскою в сердце. Зачем она нам такая?
Вариант Е тоже не подходит. В эскалации есть смысл, если вы не можете решить проблему на своем уровне. Но здесь у вас и полномочий хватает, и инструменты нужные есть. Не отвлекайте руководство от стратегических задач по таким пустякам.
Вариант В — для тех, кто не хочет заморачиваться с менеджерской работой, а хочет быть роботом-администратором. Это не здорово, хотя в компаниях определенного типа может и прокатить. Не вписалась Саша в вашу схему — ну и нафиг ее. Но хорошие менеджеры так не делают. Уволить всегда успеете, сначала надо подумать, как развернуть ситуацию в свою пользу.
Вариант С выбирают те, кто привык работать в динамичных стартапах или компаниях с гибкими процессами. И никогда не видел таких, как в задачке. А они есть, и меняться не собираются. Да и не должны. Тем более, из-за случайного человека в своих рядах.
Классно, когда ты Гугл, и можешь выбирать себе сотрудников по вкусу. Классно, когда ты строишь Гугл. А если нет? Компания работает, долю рынка занимает, зарабатывает деньги, клиенты рады. Для изменений нужны реальные причины, а не демарш какой-то барышни.
Наилучший вариант — F. Рабочие процессы отдела сохраняются, Саша получает дополнительную свободу и мотивацию, а мы наслаждаемся ее высокой производительностью.
В реальной жизни менеджер собирался Сашу уволить, но удалось уговорить его на вариант F. Он долго не мог с этой идеей свыкнуться, но в итоге справился. Они проработали в таком режиме несколько лет.
Я верю, что производительность свободных и творческих людей выше, чем зажатых в дисциплинарные рамки. Но надо быть реалистом — это не тот случай. У нас средние люди, с ними нам и работать.
Да, не всем выпадает трудиться в Гугле.
Вариант А плох для всех: и Саша страдает, и у вас проблема с отделом осталась. Да и разве по-менеджерски это — ничего не делать?
Вариант D — путь в никуда. Подавляя и демотивируя Сашу, мы добьемся того, что она станет как все, но раздраженной и с тоскою в сердце. Зачем она нам такая?
Вариант Е тоже не подходит. В эскалации есть смысл, если вы не можете решить проблему на своем уровне. Но здесь у вас и полномочий хватает, и инструменты нужные есть. Не отвлекайте руководство от стратегических задач по таким пустякам.
Вариант В — для тех, кто не хочет заморачиваться с менеджерской работой, а хочет быть роботом-администратором. Это не здорово, хотя в компаниях определенного типа может и прокатить. Не вписалась Саша в вашу схему — ну и нафиг ее. Но хорошие менеджеры так не делают. Уволить всегда успеете, сначала надо подумать, как развернуть ситуацию в свою пользу.
Вариант С выбирают те, кто привык работать в динамичных стартапах или компаниях с гибкими процессами. И никогда не видел таких, как в задачке. А они есть, и меняться не собираются. Да и не должны. Тем более, из-за случайного человека в своих рядах.
Классно, когда ты Гугл, и можешь выбирать себе сотрудников по вкусу. Классно, когда ты строишь Гугл. А если нет? Компания работает, долю рынка занимает, зарабатывает деньги, клиенты рады. Для изменений нужны реальные причины, а не демарш какой-то барышни.
Наилучший вариант — F. Рабочие процессы отдела сохраняются, Саша получает дополнительную свободу и мотивацию, а мы наслаждаемся ее высокой производительностью.
В реальной жизни менеджер собирался Сашу уволить, но удалось уговорить его на вариант F. Он долго не мог с этой идеей свыкнуться, но в итоге справился. Они проработали в таком режиме несколько лет.
Я верю, что производительность свободных и творческих людей выше, чем зажатых в дисциплинарные рамки. Но надо быть реалистом — это не тот случай. У нас средние люди, с ними нам и работать.
Да, не всем выпадает трудиться в Гугле.
💴 История о премиях
В одной компании платили квартальные премии сотрудникам. Делали это так. Сначала надо было, чтобы все подразделения компании за квартал показали позитивные результаты. Это был крупный холдинг, в него входили семь компаний, работающих на разных рынках. Поэтому изначально премия любого сотрудника состояла из семи частей. Какая-то компания холдинга провалила квартал? Тогда эта доля в премии сотрудника обнуляется, и неважно, в какой из структур он работает.
Любопытно был устроен и процесс выплат. Предположим, отработали все хорошо в первом квартале. Ждете денег? Не торопитесь. Во втором квартале премию не дадут — весь квартал ее “анализируют и начисляют”. В начале третьего квартала вы узнаете, какая сумма вам причитается. Наступает середина третьего квартала, за окном жаркий август. И вот она, долгожданная премия, падает на карточку!
Но не спешите заказывать черную икру: выплатят вам только 60% от обещанного. А 40% уходят в “годовой премиальный фонд”. Туда добавляют деньги от каждой квартальной премии, и в конце года набегает изрядная сумма. Но выплатят ее не в конце года, а только... в апреле следующего.
Получается, целиком премию за первый квартал нужно ждать дольше года. С остальными кварталами такая же история.
Разумеется, если вы уволитесь хотя бы накануне выплаты, то вам шиш.
Руководство было уверено, что это прекрасно мотивирует сотрудников работать в компании подольше: отложенный бонус держит их на месте. На деле же, это всех дико злило. Все ждали апреля, чтобы свалить. Апрель был месяцем массового исхода. Задолго до него куча людей просто забивала на работу: сразу ведь не уволят, а к апрелю и место новое найти можно, и денег дождаться. Да и в течение года текучка была просто ужасающей. Не все были готовы ждать апреля.
Такая схема, разумеется, не работает: теряется всякая связь между достижениями в квартале и получением денег через год. Люди воспринимали это все не как логическую связь “достижение — поощрение”, а как игру в рулетку. Прикольно выиграть, но сильно надеяться на это не нужно. Еще и проиграть можно.
Лояльность тоже не повышалась — как можно быть лояльным казино?
Вроде бы премия — удобный инструмент мотивации и повышения уровня лояльности сотрудников. Но как же просто даже такую хорошую идею сделать плохой, если за дело берутся людоеды.
В одной компании платили квартальные премии сотрудникам. Делали это так. Сначала надо было, чтобы все подразделения компании за квартал показали позитивные результаты. Это был крупный холдинг, в него входили семь компаний, работающих на разных рынках. Поэтому изначально премия любого сотрудника состояла из семи частей. Какая-то компания холдинга провалила квартал? Тогда эта доля в премии сотрудника обнуляется, и неважно, в какой из структур он работает.
Любопытно был устроен и процесс выплат. Предположим, отработали все хорошо в первом квартале. Ждете денег? Не торопитесь. Во втором квартале премию не дадут — весь квартал ее “анализируют и начисляют”. В начале третьего квартала вы узнаете, какая сумма вам причитается. Наступает середина третьего квартала, за окном жаркий август. И вот она, долгожданная премия, падает на карточку!
Но не спешите заказывать черную икру: выплатят вам только 60% от обещанного. А 40% уходят в “годовой премиальный фонд”. Туда добавляют деньги от каждой квартальной премии, и в конце года набегает изрядная сумма. Но выплатят ее не в конце года, а только... в апреле следующего.
Получается, целиком премию за первый квартал нужно ждать дольше года. С остальными кварталами такая же история.
Разумеется, если вы уволитесь хотя бы накануне выплаты, то вам шиш.
Руководство было уверено, что это прекрасно мотивирует сотрудников работать в компании подольше: отложенный бонус держит их на месте. На деле же, это всех дико злило. Все ждали апреля, чтобы свалить. Апрель был месяцем массового исхода. Задолго до него куча людей просто забивала на работу: сразу ведь не уволят, а к апрелю и место новое найти можно, и денег дождаться. Да и в течение года текучка была просто ужасающей. Не все были готовы ждать апреля.
Такая схема, разумеется, не работает: теряется всякая связь между достижениями в квартале и получением денег через год. Люди воспринимали это все не как логическую связь “достижение — поощрение”, а как игру в рулетку. Прикольно выиграть, но сильно надеяться на это не нужно. Еще и проиграть можно.
Лояльность тоже не повышалась — как можно быть лояльным казино?
Вроде бы премия — удобный инструмент мотивации и повышения уровня лояльности сотрудников. Но как же просто даже такую хорошую идею сделать плохой, если за дело берутся людоеды.
🥷 Тренажер для менеджеров и не только 954-827
Есть крупный проект по созданию ключевого для компании продукта. Руководит им менеджер Амир, в команду входят люди из разных отделов. Команда работает хорошо, сроки соблюдаются, с качеством и бюджетом порядок. Заказчики продукта — собственники компании, они тоже довольны текущими результатами.
А вот с отношениями в команде не все гладко. Амир конфликтует с Лерой, главным финансистом. Лера — профессионал высокого уровня, но постоянно ставит под сомнения управленческие решения, которые принимает Амир. Конфликт длится давно, и начинает негативно влиять на проект.
У нашей истории есть еще один герой — Олег. В проекте он управляет работами в ИТ и подчиняется Амиру. Олег давно в компании, знаком с собственниками, может общаться с ними напрямую.
Олег — хороший менеджер и неплохой коммуникатор. Из разговоров с начальником ему становится ясно, что Амиру очень мешает конфликт с Лерой. Но по какой-то причине Амир не хочет эскалировать этот конфликт на уровень собственников. Амир говорит, что "устал от всех этих интриг и дрязг". И планирует искать другую работу.
Олег считает, что уход Амира не пойдет на пользу проекту. Да и к Лере нежных чувств не питает. Зато Олегу очень нравятся и задачи, которые приходится решать, и проект, и продукт.
Есть крупный проект по созданию ключевого для компании продукта. Руководит им менеджер Амир, в команду входят люди из разных отделов. Команда работает хорошо, сроки соблюдаются, с качеством и бюджетом порядок. Заказчики продукта — собственники компании, они тоже довольны текущими результатами.
А вот с отношениями в команде не все гладко. Амир конфликтует с Лерой, главным финансистом. Лера — профессионал высокого уровня, но постоянно ставит под сомнения управленческие решения, которые принимает Амир. Конфликт длится давно, и начинает негативно влиять на проект.
У нашей истории есть еще один герой — Олег. В проекте он управляет работами в ИТ и подчиняется Амиру. Олег давно в компании, знаком с собственниками, может общаться с ними напрямую.
Олег — хороший менеджер и неплохой коммуникатор. Из разговоров с начальником ему становится ясно, что Амиру очень мешает конфликт с Лерой. Но по какой-то причине Амир не хочет эскалировать этот конфликт на уровень собственников. Амир говорит, что "устал от всех этих интриг и дрязг". И планирует искать другую работу.
Олег считает, что уход Амира не пойдет на пользу проекту. Да и к Лере нежных чувств не питает. Зато Олегу очень нравятся и задачи, которые приходится решать, и проект, и продукт.
Как поступить Олегу в этой ситуации?
Anonymous Poll
34%
А. Никак. Пусть сами разбираются. Разруливать конфликт Амир должен сам, это вообще не дело Олега.
19%
В. Рассказать собственнику о конфликте и возможных последствиях для проекта. И попросить вмешаться.
45%
C. Предложить Амиру помощь, сказав, что Олег может приватно обсудить конфликт с собственниками.
2%
D. Как можно скорее уволиться из компании, где даже в хорошем проекте есть интриги и конфликты.
Комментарии к задачке, как обычно, послезавтра)
Прочитал несколько книжек про сторителлинг.
К. Лоуренс "Сторителлинг" и Ч. Вендиг "250 дерзких советов писателю" — отстой.
Л. Сарычева "Уступите место драме" — прекрасно, рекомендую всем менеджерам.
К. Лоуренс "Сторителлинг" и Ч. Вендиг "250 дерзких советов писателю" — отстой.
Л. Сарычева "Уступите место драме" — прекрасно, рекомендую всем менеджерам.
🍿 Комментарии к задачке 954-827
Удивительно, но кто-то выбрал даже вариант D. Друзья, проектов без конфликтов не бывает. Проекты делают люди в условиях неопределенности и ограниченных ресурсов, в условиях сжатых сроков и давления со стороны клиентов и начальства. Как тут не быть конфликтам? Хотите уволиться из проекта с конфликтами — проще вообще не заниматься проектной работой.
Вариант В тоже плох. Я бы не рекомендовал Олегу вмешиваться. Совершенно не вижу причин решать проблемы Амира в ситуации, когда самому Амиру это не очень важно: он же терпит, ничего не предпринимает. Амир — большой мальчик, должен сам разруливать конфликты. А если не может, так ли он хорош как менеджер, и стоит ли его удерживать в компании?
Мы не знаем, почему Амир уклоняется от решения проблемы. Бывают ситуации, когда даже огласка конфликта нежелательна. Так что не нужно Олегу помогать начальнику без запроса, да еще и сразу с выходом на собственников. Это вполне может оказаться медвежьей услугой, и вместо спасения проекта Олег получит врага в лице Амира.
Или же Олегу и дальше придется решать проблемы Амира, причем делать это из позиции подчиненного. Амиру-то будет хорошо, а Олегу?
Так что выбирать нужно из вариантов А и С. Первый — для жестких прагматиков, второй — для сердобольных менеджеров. ) Вариант С предполагает, что Олег предлагает Амиру помощь. Но это не означает, что Олег предлагает решение проблемы, он готов только предоставить инструмент. Это важно: Амир в любом случае должен сам решать свои проблемы как менеджер.
Но самое лучшее — выбрать вариант А и не вмешиваться в чужие конфликты.
Конфликты в командах могут длиться годами. Более того, иногда конфликты между топами стимулируют собственники или гендиректор. Делается это для того, чтобы не возникало ненужных коалиций и всяких заговоров против высокого начальства. Это плохо, но люди как-то умудряются с этим работать.
В реальности Олег предложил Амиру помощь, но встретил жесткий отказ. На том все и закончилось. Амир покинул компанию, на его место наняли нового человека. С проектом ничего плохого не случилось.
Часто мы склонны преувеличивать важность отдельных людей для проектов.
Удивительно, но кто-то выбрал даже вариант D. Друзья, проектов без конфликтов не бывает. Проекты делают люди в условиях неопределенности и ограниченных ресурсов, в условиях сжатых сроков и давления со стороны клиентов и начальства. Как тут не быть конфликтам? Хотите уволиться из проекта с конфликтами — проще вообще не заниматься проектной работой.
Вариант В тоже плох. Я бы не рекомендовал Олегу вмешиваться. Совершенно не вижу причин решать проблемы Амира в ситуации, когда самому Амиру это не очень важно: он же терпит, ничего не предпринимает. Амир — большой мальчик, должен сам разруливать конфликты. А если не может, так ли он хорош как менеджер, и стоит ли его удерживать в компании?
Мы не знаем, почему Амир уклоняется от решения проблемы. Бывают ситуации, когда даже огласка конфликта нежелательна. Так что не нужно Олегу помогать начальнику без запроса, да еще и сразу с выходом на собственников. Это вполне может оказаться медвежьей услугой, и вместо спасения проекта Олег получит врага в лице Амира.
Или же Олегу и дальше придется решать проблемы Амира, причем делать это из позиции подчиненного. Амиру-то будет хорошо, а Олегу?
Так что выбирать нужно из вариантов А и С. Первый — для жестких прагматиков, второй — для сердобольных менеджеров. ) Вариант С предполагает, что Олег предлагает Амиру помощь. Но это не означает, что Олег предлагает решение проблемы, он готов только предоставить инструмент. Это важно: Амир в любом случае должен сам решать свои проблемы как менеджер.
Но самое лучшее — выбрать вариант А и не вмешиваться в чужие конфликты.
Конфликты в командах могут длиться годами. Более того, иногда конфликты между топами стимулируют собственники или гендиректор. Делается это для того, чтобы не возникало ненужных коалиций и всяких заговоров против высокого начальства. Это плохо, но люди как-то умудряются с этим работать.
В реальности Олег предложил Амиру помощь, но встретил жесткий отказ. На том все и закончилось. Амир покинул компанию, на его место наняли нового человека. С проектом ничего плохого не случилось.
Часто мы склонны преувеличивать важность отдельных людей для проектов.
🧽 Важные уроки в школьной столовой
Когда я учился в первом классе советской школы, приключилась со мной такая история.
Закончились уроки. Учительница попросила задержаться. И сказала: “Дети! У нас сейчас проблемы с уборщицами. На некоторое время мы вынуждены просить кого-то из ваших родителей помогать с уборкой в столовой: помыть столы, полы. Пара человек в день, потом другие. Есть ли добровольцы на завтра?” Я зачем-то поднял руку и сказал, что придет моя бабушка.
Дома я описал ситуацию и сообщил, что завтра бабушке надо убирать школьную столовую. В комнате повисла тишина. Бабушка (два высших образования, ученая степень) вежливо поинтересовалась, с какой стати ей убирать столовую, в которую ее внук даже не ходит, потому что уже успел там отравиться пельменями? Дедушка (три высших образования, два иностранных языка) надрываясь от смеха и вытирая слезы, заметил, что очень хорошо, что внук начал с бабушки, а не отправил и его, скажем, чинить школьную крышу или красить стены.
Бабушка сказала: “Хорошо. Я не буду подставлять тебя и отказываться от этой почетной задачи. Но раз ты, не обсудив ничего со мной, принял решение, тебе тоже придется завтра в этом участвовать. Будем мыть столовую вместе”.
Так я помыл школьную столовую. Надо сказать, столовая после завтрака и обеда полутора тысяч учеников была весьма грязная.
Какие выводы я сделал?
Во-первых, если у тебя нет полномочий принимать решение, не надо этого делать. И тебе будет хуже, и окружающим. Сначала полномочия, а только потом — менеджмент. Не наоборот.
Во-вторых, если ты принял решение, надо быть готовым разделить и его последствия. Такова участь всех управленцев.
В-третьих, стоит обсуждать задачи с исполнителями. Это не всегда возможно, но почти всегда полезно.
Ну и, в-четвертых, уровень задачи должен соответствовать уровню сотрудника.
Человек высокого уровня не должен работать над слишком простыми проблемами: это его демотивирует. Он, конечно, их сделает раз, другой, третий. Но потом терпение кончится.
Хорошо, если это ваш подчиненный, — он просто уволится.
Гораздо хуже, если это бабушка. Тут уже и огрести можно.
Когда я учился в первом классе советской школы, приключилась со мной такая история.
Закончились уроки. Учительница попросила задержаться. И сказала: “Дети! У нас сейчас проблемы с уборщицами. На некоторое время мы вынуждены просить кого-то из ваших родителей помогать с уборкой в столовой: помыть столы, полы. Пара человек в день, потом другие. Есть ли добровольцы на завтра?” Я зачем-то поднял руку и сказал, что придет моя бабушка.
Дома я описал ситуацию и сообщил, что завтра бабушке надо убирать школьную столовую. В комнате повисла тишина. Бабушка (два высших образования, ученая степень) вежливо поинтересовалась, с какой стати ей убирать столовую, в которую ее внук даже не ходит, потому что уже успел там отравиться пельменями? Дедушка (три высших образования, два иностранных языка) надрываясь от смеха и вытирая слезы, заметил, что очень хорошо, что внук начал с бабушки, а не отправил и его, скажем, чинить школьную крышу или красить стены.
Бабушка сказала: “Хорошо. Я не буду подставлять тебя и отказываться от этой почетной задачи. Но раз ты, не обсудив ничего со мной, принял решение, тебе тоже придется завтра в этом участвовать. Будем мыть столовую вместе”.
Так я помыл школьную столовую. Надо сказать, столовая после завтрака и обеда полутора тысяч учеников была весьма грязная.
Какие выводы я сделал?
Во-первых, если у тебя нет полномочий принимать решение, не надо этого делать. И тебе будет хуже, и окружающим. Сначала полномочия, а только потом — менеджмент. Не наоборот.
Во-вторых, если ты принял решение, надо быть готовым разделить и его последствия. Такова участь всех управленцев.
В-третьих, стоит обсуждать задачи с исполнителями. Это не всегда возможно, но почти всегда полезно.
Ну и, в-четвертых, уровень задачи должен соответствовать уровню сотрудника.
Человек высокого уровня не должен работать над слишком простыми проблемами: это его демотивирует. Он, конечно, их сделает раз, другой, третий. Но потом терпение кончится.
Хорошо, если это ваш подчиненный, — он просто уволится.
Гораздо хуже, если это бабушка. Тут уже и огрести можно.
🎨 Спрашивали — отвечаем 24
“Я дизайнер по образованию, а с недавних пор стал арт-директором в небольшой компании. И у меня есть вопрос, касающийся управления рисками.
Давайте представим себе такую ситуацию: проджект-менеджер давно работает со своей командой, и процесс идёт хорошо. Но однажды кто-то из спецов срывает сроки.
— Что случилось? — спрашивает менеджер.
— Мы взялись за задачу как обычно, — отвечают дизайнеры / программисты / маркетологи, — но потом нам не понравилось то, что получается, и мы стали переделывать. Всех предупредили, что не укладываемся к дедлайну, но сейчас не готовы назвать дату окончания наших творческих поисков.
Что в этом случае должен сделать ПМ? Через месяц релиз, а ещё нужно всё собрать и протестировать”.
На всякий случай: арт-директор и РМ — разные роли. Первый отвечает за дизайн продукта. Второй — за сроки, бюджет и скоуп проекта. Совмещать эти роли в одном человеке — зло. Уж очень разные у них цели.
РМу нужно:
1. Спросить себя, а точно ли он РМ? В проекте с жестким дедлайном исполнители позволяют себе делать какие-то задачи без его одобрения, меняют скоуп, да еще и нарушают сроки, а он об этом узнает последним. Серьезно? Друг мой, соберись и начни уже быть менеджером.
2. Запретить навсегда критерий “дизайн не нравится”. Это слишком субъективно, а мы тут проект делаем и деньги хотим заработать. Должны быть критерии “дизайн решает задачу клиента” и “дизайн соответствует требованиям”. Дизайн — не искусство. Это такая же обычная работа, как любая другая. Печь пирожки, создавать код, проводить маркетинговое исследование, писать текст, делать дизайн. Хотите искусства — идите в художники. Дизайнер не творит абстрактную красоту и не делает то, что ему вздумается, а решает задачу клиента. Так же и с любой другой профессией. Разраб, которому вдруг не нравится код, просто не подумал хорошенько, когда его писал. Это не про искусство, это про профессионализм. Не нравится? Делай так, чтобы нравилось.
3. Ввести короткие итерации. Прошло три дня — покажите, что вы сделали. Все гибкие проектные подходы существуют ровно для того, чтобы менять продукт на лету и не обнаружить через месяц, что “результат не нравится”. Спринты, приоритизация беклога, танцы у белой доски. Вот это вот все.
4. Управлять рисками. Это уже менеджмент по-взрослому. Вести реестр рисков, оценивать их регулярно, составить план по управлению каждым. Придется многому научиться, но в долгосрочной перспективе оно окупится.
5. В описанной ситуации — остановить все работы по переделке того, что “не нравится”. Проверить, можно ли использовать уже созданное, чтобы успеть к дедлайну. Ставить задачи на ближайшие три дня, с ежедневным контролем прогресса. Ввалить исполнителям за несогласованные с РМом работы.
Творческий поиск — это очень классно, когда он происходит за счет кого-то другого. Но стоит задержать дизайнеру зарплату из-за того, что бухгалтер ушел в творческий поиск и ищет новые смыслы в квартальной отчетности, — сразу дизайнер начинает понимать что-то о жизни и делает меньше глупостей.
“Я дизайнер по образованию, а с недавних пор стал арт-директором в небольшой компании. И у меня есть вопрос, касающийся управления рисками.
Давайте представим себе такую ситуацию: проджект-менеджер давно работает со своей командой, и процесс идёт хорошо. Но однажды кто-то из спецов срывает сроки.
— Что случилось? — спрашивает менеджер.
— Мы взялись за задачу как обычно, — отвечают дизайнеры / программисты / маркетологи, — но потом нам не понравилось то, что получается, и мы стали переделывать. Всех предупредили, что не укладываемся к дедлайну, но сейчас не готовы назвать дату окончания наших творческих поисков.
Что в этом случае должен сделать ПМ? Через месяц релиз, а ещё нужно всё собрать и протестировать”.
На всякий случай: арт-директор и РМ — разные роли. Первый отвечает за дизайн продукта. Второй — за сроки, бюджет и скоуп проекта. Совмещать эти роли в одном человеке — зло. Уж очень разные у них цели.
РМу нужно:
1. Спросить себя, а точно ли он РМ? В проекте с жестким дедлайном исполнители позволяют себе делать какие-то задачи без его одобрения, меняют скоуп, да еще и нарушают сроки, а он об этом узнает последним. Серьезно? Друг мой, соберись и начни уже быть менеджером.
2. Запретить навсегда критерий “дизайн не нравится”. Это слишком субъективно, а мы тут проект делаем и деньги хотим заработать. Должны быть критерии “дизайн решает задачу клиента” и “дизайн соответствует требованиям”. Дизайн — не искусство. Это такая же обычная работа, как любая другая. Печь пирожки, создавать код, проводить маркетинговое исследование, писать текст, делать дизайн. Хотите искусства — идите в художники. Дизайнер не творит абстрактную красоту и не делает то, что ему вздумается, а решает задачу клиента. Так же и с любой другой профессией. Разраб, которому вдруг не нравится код, просто не подумал хорошенько, когда его писал. Это не про искусство, это про профессионализм. Не нравится? Делай так, чтобы нравилось.
3. Ввести короткие итерации. Прошло три дня — покажите, что вы сделали. Все гибкие проектные подходы существуют ровно для того, чтобы менять продукт на лету и не обнаружить через месяц, что “результат не нравится”. Спринты, приоритизация беклога, танцы у белой доски. Вот это вот все.
4. Управлять рисками. Это уже менеджмент по-взрослому. Вести реестр рисков, оценивать их регулярно, составить план по управлению каждым. Придется многому научиться, но в долгосрочной перспективе оно окупится.
5. В описанной ситуации — остановить все работы по переделке того, что “не нравится”. Проверить, можно ли использовать уже созданное, чтобы успеть к дедлайну. Ставить задачи на ближайшие три дня, с ежедневным контролем прогресса. Ввалить исполнителям за несогласованные с РМом работы.
Творческий поиск — это очень классно, когда он происходит за счет кого-то другого. Но стоит задержать дизайнеру зарплату из-за того, что бухгалтер ушел в творческий поиск и ищет новые смыслы в квартальной отчетности, — сразу дизайнер начинает понимать что-то о жизни и делает меньше глупостей.
🧬 Тренажер для менеджеров и не только 1-118
Вы управляете проектом длиной восемь месяцев по созданию системы для государственного заказчика. Четыре месяца уже позади.
Вы соблюдаете почти все внутренние плановые сроки: одну веху прошли с недельным опозданием, но знаете, как догнать. Управление рисками у вас в проекте на высоте.
С заказчиком у вас отличные отношения, он доверяет вам, что в подобных проектах встречается не так уж и часто. “Побольше бы таких вендоров!”, — любит говорить он.
Однажды утром к вам пришел один из ведущих разработчиков и предложил интересное решение: если использовать в проекте современную продвинутую технологию ABCD, то можно сократить время разработки на месяц.
Вы не первый год знаете этого разраба, он настоящий профессионал, и обычно все его предложения технически хороши.
Вы управляете проектом длиной восемь месяцев по созданию системы для государственного заказчика. Четыре месяца уже позади.
Вы соблюдаете почти все внутренние плановые сроки: одну веху прошли с недельным опозданием, но знаете, как догнать. Управление рисками у вас в проекте на высоте.
С заказчиком у вас отличные отношения, он доверяет вам, что в подобных проектах встречается не так уж и часто. “Побольше бы таких вендоров!”, — любит говорить он.
Однажды утром к вам пришел один из ведущих разработчиков и предложил интересное решение: если использовать в проекте современную продвинутую технологию ABCD, то можно сократить время разработки на месяц.
Вы не первый год знаете этого разраба, он настоящий профессионал, и обычно все его предложения технически хороши.
Комментарии к задачке, как обычно, послезавтра)
🦈 Комментарии к задачке 1-118
Вариант А плох. Согласиться на предложение разраба и добавить новую технологию в середине проекта — огромный риск. Но даже если представить, что сроки удалось сократить, нормальный менеджер должен спросить себя: “А что произойдет с бюджетом? Качеством? Составом задач?” Менеджер управляет всеми этими параметрами, не только сроками.
Вариант В — не менеджерский. Посоветоваться с руководителем, воспринимая его как более опытного человека, можно. Но не нужно перегружать его проблемами, за решение которых платят вам. Бегать с каждой задачей наверх — плохая практика.
Вариант С не лишен смысла: вы отказываетесь, не желая рисковать и стараясь сохранить гладкий график выполнения проекта. Но вы упускаете возможность завершить работы раньше и выглядеть еще лучше в глазах стейкхолдеров. Годится как вариант для не очень опытного РМа, но не подходит профи.
Выбирать вариант D и советоваться с заказчиком нельзя ни при каких обстоятельствах. Клиенты добрые, пока все идет хорошо. Как только начинаются проблемы, клиенты демонстрируют волчий оскал и кроют вас матом на всех встречах. Клиенты — негодные советчики.
Так же обстоит дело и с командой. Команда нужна чтобы делать проектные задачи, искать красивые решения технических проблем. Но команда не рулит проектом и не принимает управленческих решений. Отвечает за проект менеджер, и никто другой.
Так что верный вариант — Е. Сначала анализируем последствия внедрения технологии, а только потом принимаем решение. Тем более, у вас в проекте управление рисками на высоте. )
В реальной проектной жизни подобные истории встречаются сплошь и рядом. Я видел много ситуаций, когда менеджер загорался идеей разраба и навлекал беду на свой проект.
Не принимайте необдуманных решений. Тот факт, что разработчик до сих пор не ошибался, означает, что его идея заслуживает внимания и ваших дальнейших усилий. Не более того.
Вариант А плох. Согласиться на предложение разраба и добавить новую технологию в середине проекта — огромный риск. Но даже если представить, что сроки удалось сократить, нормальный менеджер должен спросить себя: “А что произойдет с бюджетом? Качеством? Составом задач?” Менеджер управляет всеми этими параметрами, не только сроками.
Вариант В — не менеджерский. Посоветоваться с руководителем, воспринимая его как более опытного человека, можно. Но не нужно перегружать его проблемами, за решение которых платят вам. Бегать с каждой задачей наверх — плохая практика.
Вариант С не лишен смысла: вы отказываетесь, не желая рисковать и стараясь сохранить гладкий график выполнения проекта. Но вы упускаете возможность завершить работы раньше и выглядеть еще лучше в глазах стейкхолдеров. Годится как вариант для не очень опытного РМа, но не подходит профи.
Выбирать вариант D и советоваться с заказчиком нельзя ни при каких обстоятельствах. Клиенты добрые, пока все идет хорошо. Как только начинаются проблемы, клиенты демонстрируют волчий оскал и кроют вас матом на всех встречах. Клиенты — негодные советчики.
Так же обстоит дело и с командой. Команда нужна чтобы делать проектные задачи, искать красивые решения технических проблем. Но команда не рулит проектом и не принимает управленческих решений. Отвечает за проект менеджер, и никто другой.
Так что верный вариант — Е. Сначала анализируем последствия внедрения технологии, а только потом принимаем решение. Тем более, у вас в проекте управление рисками на высоте. )
В реальной проектной жизни подобные истории встречаются сплошь и рядом. Я видел много ситуаций, когда менеджер загорался идеей разраба и навлекал беду на свой проект.
Не принимайте необдуманных решений. Тот факт, что разработчик до сих пор не ошибался, означает, что его идея заслуживает внимания и ваших дальнейших усилий. Не более того.
🎡 Спрашивали — отвечаем 25
“Сергей, привет!
Регулярно читаю ваш канал об управлении проектами, очень нравится, спасибо за него большое!
В работе у меня сейчас возник новый для меня кейс: делаем важный продукт для B2C, в команде 3 разработчика, один из которых аутстафер. До сдачи осталось около месяца, разрабы загружены полностью, но впритык-впритык с небольшим запасом успеваем. Аутстафер на удалёнке, работает из другого города. Неделю назад у него родился ребёнок и, несмотря на его заверения, что он всё будет успевать, видим регресс в его производительности. (Заранее о том, что у него будет ребёнок, нас никто не предупредил). Часть задач дольше обозначенного срока находятся в работе, джиру почти перестал актуализировать. По хорошему, надо было бы его заменить на другого (аутстаф же, и это же предложил его аутстаф-руководитель), но реальность нашей компании такова, что новому аутстаферу будут около месяца делать все необходимые доступы + время на погружение в проект. Над проектом навис риск срыва сроков.
Что делать в такой ситуации?”
Для начала стоит разобраться, это минутная слабость аутстаффера, или он поплыл основательно. Спокойно и дружелюбно поговорите с ним, укажите на косяки в работе, подробно разберите каждый. Ваша цель — успешно завершить проект, а не доказать, что человек плохой.
Дайте ему задачу на пару дней, остальные уберите. Через день спросите, как идет. Как сделает эту, дайте следующую. Требуйте соблюдения правил и следования процессам. Должен в jira что-то заполнить — проверяйте каждый день, что заполнил. Если ситуация наладилась, то увеличивайте паузы между точками контроля. Если нет — ничего уже не сделать на такой короткой дистанции, отпустите ситуацию. Пусть человек работает так, как может.
Параллельно сделайте все, чтобы его задачи были не на критическом пути. Передайте самые болезненные темы другим людям. Режьте скоуп. Начинайте разговаривать с клиентом, чтобы морально подготовить его к возможному срыву сроков.
На будущее: надо управлять рисками. Когда работаешь с внешними исполнителями, риск того, что они внезапно перестанут нормально работать, один из главных. А теперь он материализовался и стал уже не риском, а проблемой. С проблемами иметь дело сложнее, чем с рисками.
Если бы у вас был реестр рисков, вы бы его просто открыли и прочитали, что делать, когда аутстаффер отваливается.
Но готов спорить, что открывать вам нечего. )
“Сергей, привет!
Регулярно читаю ваш канал об управлении проектами, очень нравится, спасибо за него большое!
В работе у меня сейчас возник новый для меня кейс: делаем важный продукт для B2C, в команде 3 разработчика, один из которых аутстафер. До сдачи осталось около месяца, разрабы загружены полностью, но впритык-впритык с небольшим запасом успеваем. Аутстафер на удалёнке, работает из другого города. Неделю назад у него родился ребёнок и, несмотря на его заверения, что он всё будет успевать, видим регресс в его производительности. (Заранее о том, что у него будет ребёнок, нас никто не предупредил). Часть задач дольше обозначенного срока находятся в работе, джиру почти перестал актуализировать. По хорошему, надо было бы его заменить на другого (аутстаф же, и это же предложил его аутстаф-руководитель), но реальность нашей компании такова, что новому аутстаферу будут около месяца делать все необходимые доступы + время на погружение в проект. Над проектом навис риск срыва сроков.
Что делать в такой ситуации?”
Для начала стоит разобраться, это минутная слабость аутстаффера, или он поплыл основательно. Спокойно и дружелюбно поговорите с ним, укажите на косяки в работе, подробно разберите каждый. Ваша цель — успешно завершить проект, а не доказать, что человек плохой.
Дайте ему задачу на пару дней, остальные уберите. Через день спросите, как идет. Как сделает эту, дайте следующую. Требуйте соблюдения правил и следования процессам. Должен в jira что-то заполнить — проверяйте каждый день, что заполнил. Если ситуация наладилась, то увеличивайте паузы между точками контроля. Если нет — ничего уже не сделать на такой короткой дистанции, отпустите ситуацию. Пусть человек работает так, как может.
Параллельно сделайте все, чтобы его задачи были не на критическом пути. Передайте самые болезненные темы другим людям. Режьте скоуп. Начинайте разговаривать с клиентом, чтобы морально подготовить его к возможному срыву сроков.
На будущее: надо управлять рисками. Когда работаешь с внешними исполнителями, риск того, что они внезапно перестанут нормально работать, один из главных. А теперь он материализовался и стал уже не риском, а проблемой. С проблемами иметь дело сложнее, чем с рисками.
Если бы у вас был реестр рисков, вы бы его просто открыли и прочитали, что делать, когда аутстаффер отваливается.
Но готов спорить, что открывать вам нечего. )
