• Два в одном: разбор кейса

    Posted on September 24th, 2009 Александр Орлов No comments

    Чужие ошибки искать всегда интересно. Я так понимаю, именно поэтому получилось столько ответов на кейс  ”Два в одном”. :)

    Ну, в самом деле, суммируя то, что было сказано участниками:

    • Были ошибки в проведении совещаний (выпали за регламент и пр.)
    • Была критика коллег-начальников перед лицом подчиненного
    • Было противопоставление “нас умных” “им дуракам”
    • Было предложено “объективно” оценить результаты своей работы исполнителям
    • Было принято компромиссное решение о сращивании скриптов

    Многие фактически так или иначе подчеркнули все эти ошибки. Мне, честно говоря, очень понравилось решение pbear51 – довольно точно угадана подоплека событий из ситуации, имевшей место в реальности:

    1. Cудя по первым 3-м абзацам кейса была и повестка совещания, и понимание проблемы у Ивана.
    Об этом говорят слишком короткие фразы между участниками (Димой, Алексеем, Иваном).

    Вот если бы Дима сказал что-то вроде: “На этом совещании я предполагал обсудить вопрос текстовых скриптов, которые …. Но сейчас не успеваем, поэтому перенесем этот вопрос.” Тогда можно было бы предположить, что повестки совещания не было. К тому же Иван понял Алексея с полуслова. А это значит, что вопрос ранее поднимался и обсуждался.

    Предполагаю, что на совещании Дима планировал принять решение кто конкретно будет заниматься скриптами, но не успел.

    2. Лично я не считаю затягивание совещания ошибкой. Все эти регламенты, слежение за временем хороши в теории, но на практике не всегда работают. Что хорошо работает на практике – так это предварительная повестка совещания. Не забывайте, что люди общаются по телефону. И скажем, задача нарисовать элементарную схему, показать что-то на бумажке превращается в большую проблему. А это один из факторов затягивания времени.

    3. Дальше с Ваней в кейсе есть “скользкий” момент. С Ваней может быть 2 варианта: либо сотруднику действительно нравится его работа и он готов решать любые поставленные задачи, либо сотрудник специально сделал больше, чем ему поручено (аттестации из прошлого кейса никто не отменял). Я предполагаю, что имеет место нечто среднее между 2-мя озвученными вариантами.

    4. А дальше Алексей делает всё ПРАВИЛЬНО :-) Только надо понимать, что цели у Алексея – закрепить за своей командой эту задачу и выполненный объем работ. Тот факт, что московская команда делала тоже самое говорит о том, что есть СКРЫТАЯ КОНКУРЕНЦИЯ между командами!

    bpgz совершенно прав. Всё зависит от целей (см. у bpgz п. 13). А цели у Алексея совершенно не соответствуют общим целям и целям Димы.

    В таких случаях (управленческой борьбы) важно предоставить ГОТОВЫЙ и ПРОВЕРЕННЫЙ продукт, поэтому он всё досконально проверяет. Если Алексей на совещании скажет: “А вот мы написали скрипты, сейчас тестируем.” Я почти уверен, что в ответ прозвучит от московской команды: “А у нас скрипты написаны и проверены”. ДАЖЕ если это неправда. (ложь должна быть правдоподобной и труднопроверяемой). И тогда будет ожидаемое решение Димы: “Так, у москвы всё уже сделано, поэтому не тратьте время на тестирование, берем московский вариант”.

    5. Я думаю, что скрытая конкуренция обусловлена системой оценки работы команд/сотрудников с помощью KPI.

    Здесь нужно сделать небольшое отступление и рассказать об одном большом недостатке системы BSC (ССП) и KPI (КПЭ). Заключается он вот в чём. Как только вводится оценка работы сотрудника по KPI, сотрудник перестает работать на цели компании, непосредственного начальника и т.д. Он начинает работать только на свои показатели и каждое задание будет оценивать только с точки зрения улучшения СВОИХ показателей.

    В клинических случаях народ начинает работать так, что KPI остаются в норме, но реальных результатов нет. Именно поэтому инженерам не говорится методика оценки их работы (см. ответы Александра Орлова на предыдущий кейс).

    НО! менеджер команды знает об методике оценки!

    Алексей, зная о методике оценки, и, имея готовые скрипты, готовится их продемонстрировать их на совещании. Не забудьте, что если москвичи найдут ошибки в скриптах, то это будет поводом сказать: “А вот он предоставил непроверенное решение, у нас возникли проблемы и т.д. и т.п.”

    Таким образом при наличии ошибок работа команды Алексея будет дискредитирована в глазах главного менеджера Димы. В случае успеха команда Алексея и сам Алексей получили бы “плюсик” в репутацию. И возможность предоставить на следующей аттестации “железный” аргумент подтверждающий, что его команда работала больше московской. Успешная аттестация -> повышение зарплаты.

    Подчеркиваю, именно из-за совершенно других целей и условий, действия Алексея ПРАВИЛЬНЫЕ.

    Да, был риск, что его опередят. Но это другой этап борьбы :-)

    6. А вот Диме пришлось столкнуться с описанным выше недостатком системы BSC, точнее с её следствием. Его поставили перед фактом, что 2 команды сделали одно и тоже.

    Дальше, нужно разруливать ситуацию. Конфликта ещё нет. Есть противоречия (это скажем более мягкая форма конфликта. Некоторые источники выделяют до 5 уровней противоречий, разделяя их по напряженности).

    В ситуацих с противоречиям, конфликтами между Вашими подчиненными нужно помнить одно правило: “НИКОГДА, никогда не выступать третейским судьей для Ваших подчиненных. Либо они договорятся САМИ между собой, либо обоим будет плохо.”

    Зная это правило, становится понятным, что Дима в целом выбрал правильное направление своих действий. Он стал ЗАСТАВЛЯТЬ команды ДОГОВАРИВАТЬСЯ между собой. Мало того, ему необходимо принять ОБОСНОВАННОЕ решение.

    Поэтому он и слушает спор в течение получаса, и заставляет их провести сравнения.
    И вот здесь он сделал ОДНУ небольшую ОШИБКУ (я считаю это единственной ошибкой за весь кейс).

    Вместо: “Попрошу вас обоих составить список метрик, по которым вы будете их сравнивать и провести сравнение”.

    Ему надо было сказать: “Попрошу обоих составить список метрик, провести сравнение и предоставить ОДИН, СОГЛАСОВАННЫЙ вариант сравнения”.

    Из мирового опыта известно, что результат исследования всегда тянется к заказчику :-) Поэтому команды воспользовались возможностью провести отдельное свое исследование и сделать выводы в свою пользу.

    Следует отметить, что несмотря на сделанную ошибку в дальнейшем он всё равно придерживался правильной линии поведения. Фразу “сращивайте скрипты между собой” нужно понимать как: “Я не собираюсь погружаться в технические детали и решать чьи скрипты лучше. Не можете договориться сразу, значит трахайтесь как хотите, но в результате должно быть ОДНО решение”. Т.е. командам в любом случае придется договориться.

    7. В дальнейшем Диме, конечно же нужно провести воспитательную беседу со всеми его подчиненными и сказать, что в случае если какие-то вопросы не решены и не определены ответственные, то запрещается заниматься самодеятельностью и без указаний решать задачи.

    Это будет профилактической мерой, позволяющей предотвратить подобные ситуации.

    Подводя итог: ошибка и решение указаны в п. 6 , профилактические действия указаны в п. 7

    Я не вполне согласен с выводами (об этом ниже), но ситуация угадана на 90%. pbear51, мои поздравления! :)

    Мне бы хотелось подчеркнуть две вещи.

    Вещь №1. Если кто-то думает, что чтобы не попасть в эту ситуацию, достаточно будет не совершать ошибок, которые перечислены участниками кейса, то это тоже ошибка.

    Во-первых, если вы сами не совершаете ошибок, будьте уверены, это сделает кто-то другой. Если же даже в вашей команде все идеально, то вполне может так оказаться, что “скрипты” сделают в соседнем подразделении, а потом решат внедрить на уровне компании как стандарт. Вы не можете быть в курсе того, что происходит во всей компании (если она достаточна большая).

    Во-вторых, и тут сто раз прав pbear51, вступает в игру KPI. Во многих компаниях, в него включается impact вашей деятельности на деятельность подразделения и компании. Внедрили ваши скрипты в соседней команде – вы получаете плюшку. Внедрили чужие скрипты у вас – плюшку получаете не вы.

    И вот тут тонкий момент. Вам нужно постоянно увеличивать мощность своих радаров. Нужно постоянно смотреть вокруг, в соседние команды и проекты, чтобы а) понять, что из ваших best practices вы можете внедрить другим и б) что вы можете взять у других и внедрить у себя. Если вы станете человеком, который предложит какое-то улучшение, то вы всем сделаете лучше, и плюшку заодно получите.

    Вещь №2. Я не вполне согласен, что не надо быть третейским судьей при споре подчиненных. Опять же, даже если вы сами не совершаете каких-либо ошибок, эти ошибки наверняка совершат ваши подчиненные. И рано или поздно принесут вам на сравнение свои “скрипты”.

    И тут я очень сильно на стороне товарища Роберта Таунсенда, который в своей книге “Сломай систему!” сказал следующее:

    Компромисс всегда бывает вынужденным. Он должен быть последним средством. Если два отдела или подразделения не могут решить проблему и приходят с ней к вам, выслушайте обе стороны и, не уподобляясь Соломону, выберите одну или другую. На победившего это накладывает огромную ответственность за выполнение работы.

    Суммируя все вышесказанное, коллеги, не совершайте ошибок, расширяйте свое информационное поле и свою область влияния. И не уподобляйтесь царю Соломону. :)

    Leave a reply

    You must be logged in to post a comment.