Портал №1 по управлению цифровыми
и информационными технологиями

Трудности перевода

Сегодня был любопытный случай. У меня состоялась 1,5-часовая беседа с директором по ИТ одной компании. Он является гражданином другой страны и по-русски говорит не очень. Соответственно, встреча проходила на английском языке. Во встрече также участвовали другие сотрудники ИТ, "наши". Любопытно то, что найти общий язык с директором по ИТ мне оказалось проще, чем с соотечественниками. Несмотря на разницу "общечеловеческого" языка, наш с ним "профессиональный" язык (в области управления ИТ) оказался ближе. Это выяснилось по показательной дискуссии про портал самообслуживания для конечных пользователей. Он понимал с полуслова то, что нашим пришлось объяснять.

Вспомнился еще случай с нашей летней игры "Аполлон-13" с четырьмя командами параллельно, три из которых играли на английском, так как ими руководили иностранные граждане. Так вот главный координатор всех команд (американка), получив задание сразу стала задавать очень четкие вопросы: "Где мои KPI?", "Что они значат?", "Где SLA? Давайте скорее, мне же нужно довести его до всех участников.", "Что это за показатели в SLA и на что они влияют?". Осознав эту часть (по-существу базовые вопросы оперативного контроля и оценки), она сразу же направилась к подчиненным ставить задачу.

Вспоминая другие "акты взаимодействия" с зарубежными гражданами по предметной области (а их за последние годы набралось), я пришел к выводу, что все-таки базовая культура управления "у них" в среднем гораздо более развита, чем "у нас". То ли школа, то ли институт, то ли "приходишь работать в компанию, а там уже все есть" – не знаю. Но факт налицо.

Вспомнил еще интервью с Сергеем Петровым, основателем компании Рольф (см. журнал "Бизнес и время", №3 (37) 2008). Интересно, что он говорит:

— начало цитаты —

Экспаты в целом более инициативны. … Российский менеджер говорит: «Я не могу это сделать, потому что <…>». Экспат говорит: «Да, я это сделаю, но для этого надо <…>». Перечисляют они одни и те же вещи, но эффект совершенно разный.

— конец цитаты —

Вот такие вот трудности перевода.

Комментариев: 11

  • Очень интересные наблюдения.
    То, что наши менеджеры (в среднем) отличаются от “ихних” менеджеров (в среднем) – полностью согласен. И пример с Дженнифер, которая сразу потребовала себе KPI – очень яркий. Мы к тому моменту провели уже кучу игр (несколько десятков?), но это первый случай, когда руководитель пришёл и сам сказал: дайте мне наши KPI. Объясните их. Покажите SLA. На что влияет? Как выполнять?

    Очень наглядно.

    • У нас есть такое мнение: спарашиваешь, значит сам не соображаешь, значит дурак.
      Вот все и пытаются глупым не показаться, сначала помучаться, попотеть, но самому до всего допереть.

      • “Не показаться глупым”, наверное, имеет под собой прочную основу.

        Во-первых, это айтишное. Мы же умные, мы не можем не разобраться.

        Во-вторых, это мужское. Мы же добытчики, охотники, всё должны делать сами.

        Но есть помимо “показаться глупым” ещё элементарная безответственность. Зачем брать на себя работу? Зачем вести собственный список задач? Есть начальник, он напомнит. “Не откладывай на завтра то, что можно отложить на послезавтра”.

        В лучшем случае – есть область, за которую я явно отвечаю, и никто другой, и все это знают. Значит, косяки в этой области будут однозначно ассоциированы со мной, поэтому я буду ей заниматься. Чтобы не получить по шее, или не выглядеть неудобно перед коллегами, или не получить плохих рекомендаций при поиске следующей работы – неважно.

        А есть пограничные области. За них или не отвечает никто (а такое бывает сплошь и рядом), или отвечают другие люди, но эти другие люди почему-то постоянно чего-то от меня хотят. ЭТО НЕ МОЯ ПРОБЛЕМА. Пусть хотят. Пусть придумывают новые правила, регламенты, пусть меня мотивируют по-всякому. До денег мотивация редко доходит, а взывания к совести я переживу как-нибудь. Я же не бездельник.

        Чтобы заставить человека, в т.ч. российского менеджера, работать, и работать на результат, нужно этот результат (требуемый) определить. После чего – придумать градусник. После этого – связать градусник с оплатой труда. Это, плюс создание комфортных условий работы, – необходимое (на мой взгляд) условие, чтобы трудностей перевода было меньше.

        Мы же до такой простой цепочки доросли далеко не везде.

        • Мне кажется, это не очень простая цепочка. Во всяком случае во многих известных мне вполне конкретных ситуациях – непростая.

          И еще мне кажется в ней пропущено самое главное звено – подбор персонала на работу. Брать надо таких, кто умеет и хочет работать (таких меньше), а не тех, кто умеет и хочет подстраиваться под градусники (таких больше). Хороший руководитель не допускает в команду случайных людей (или редко ошибается, допуская) и строит работу так, чтобы “помогать” своим сотрудникам хотеть работать, а не мешать им, отбивая руки корявыми градусниками.

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

          • Я не говорил, что эта цепочка – достаточное условие. Считаю, что оно необходимое.

            Если в конкретной ситуации у менеджера есть право и возможность менять людей – прекрасно. Об этом можно подумать и эту возможность использовать. Нет – получаем ограничение, с которым придётся какое-то время мириться.

        • чтобы двигать инициативу, надо понимать как твоя инициатива аукнется. У нас часто с этим беда, либо инициатива вообще не воспринемается а ложится под сукно или вообще в мусорную корзину, либо другая ситуация “ты предложил, ты и делай” (что подразумевает “нам оно не надо, ты парься сам, а если выгорит дело, мы с тобой успех разделим”.
          Это вобщем-то сильно охлаждает желание инициативу толкать.
          Не знаю как в западных компаниях, возможно таже проблема имеется.

    • Вспоминается на эту тему еще один проект, в котором менеджером проекта со стороны Заказчика был чех, он прошел три стадии работы с отечественными специалистами: удивление, осознание и управление. Сначала он удивлялся как это может быть, что про выданное задание забывают. Потом он понял, что это неизбежность и нашел рычаги управления. Затем получал удовольствие от управления 🙂 При том, что у него за плечами не один проект, правда не в России…

      • Если я правильно помню, этот чех был очень рад вернуться к работе ЗА пределами нашей страны 🙂

  • Максим Зубаха

    Князь Рюрик, Франц Лефорт, Дик Адвокат – Россия всегда была сильна западным менеджментом!

    Дмитрий – спасибо за заметку. Я тоже задумывался на эту тему и нашел для себя такое объяснение.

    Большинству людей удобнее играть по устоявшимся правилам, а не превращать каждый следующий ход в фейерверк креатиффа и буйство фантазии. Почему же в реальной жизни получается наоборот? Возможно потому, что УСТОЯВШИМИСЯ правила становятся только если они долго не меняются. Многие современный российские организации могут похвастаться длительным стабильным периодом, когда их корпоративная культура развивалась эволюционным путем? Не уверен, что такие есть в природе. В результате, культурные слои правил и политик, возникших в периоды затишья между многочисленными революциями, становятся скорее пищей для аудитора или способом защиты своей сферы ответственности, но уж точно не средством управления. Отсюда и недоверие в народе к правилам, соглашениям и методам измерения их исполнения.

    А язык с “ними“ общий находить проще потому, что это “их“ язык (SLA, ITIL, Apollo 13 etс);-)

    • “А язык с “ними“ общий находить проще потому, что это “их“ язык (SLA, ITIL, Apollo 13 etс) ;-)”

      Да. Наверно так и есть.

    • Максим, согласен с этой мыслью. По сути мы говорим про управление релизами, только не для софта, а для правил работы (процессов). Хорошее управление релизами обеспечивает баланс между гибкостью (давайте менять версии каждую ночь, чтобы успеть за великими целями бизнеса) и стабильностью (давайте как можно дольше ничего не трогать, чтобы хотя бы это работало).

      Получается, что с персоналом и правилами его работы ситуация аналогична.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM