В поисках ответа на вопрос, как сделать людей более ответственными…

Довольно частый запрос от коллег-менеджеров, который приходится слышать: как повысить ответственность человека?

Казалось бы, человечество за тысячи лет своего существования должно было прийти к какому-то алгоритму повышения ответственности. И вот он, твой тренерский шанс — изложи этот алгоритм и измени навсегда жизнь отдельно взятого менеджера!

Однако, в жизни все сложнее… Приходится заниматься занудными уточнениями: а сейчас люди как работают? — Ну… безответственно.

Хм, яснее не становится. Хочется ехидно уточнить: “в смысле, бросают жен и детей?”, но в реальности, начинаешь разбираться.

Вроде бы все должно быть просто. Информационный спонсор всех хабрастатей Википедия дает достаточно четкое определение ответственности:

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


Однако, боюсь, я стал вторым человеком после автора этой статьи в Википедии, который ее прочел — а зачем это читать, если и так “интуитивно понятно”, что такое ответственность, скажут мне многие менеджеры?

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

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

1. Человек не сообщает о проблемах, о которых должен был бы сообщать. (Либо проходит мимо, либо пытается решать сам то, что не надо решать самому.)

2. Человек обещает что-то сделать, но потом не успевает и пять раз переносит срок: “тут осталось совсем чуть-чуть, завтра должно быть готово”.

Это более четкие запросы и здесь как раз можно кое-что порекомендовать.

Ситуация №1. Человек не сообщает о проблемах, о которых должен был бы сообщать. (Либо проходит мимо, либо пытается решать сам то, что не надо решать самому.)

Как мы уже обсуждали, если человек чего-то не делает, для этого может быть одна из 4 причин:

  • Нечеткая цель (не понимает зачем)
  • Не умеет
  • Не может
  • Не хочет

В обсуждении с человеком хорошо бы пройтись по этим причинам и понять, что происходит:

Нечеткая цель:
Понимает ли человек, что мимо проблем не нужно проходить? Или он добросовестно считает, что это не является частью его работы?

Не умеет:
Умеет ли человек понимать, какие проблемы он должен решать сам, на какие не нужно обращать внимания, а какие нужно эскалировать? Есть ли у человека все необходимые знания, чтобы сделать правильный выбор?

Собственно говоря. был ли в работе такой момент, когда человек работал так, как вы хотите? Если был, значит, умеет — тогда что изменилось?

Не может:
Как у него с нагрузкой? Если на него повешена сейчас работа трех человек, то довольно наивно полагать. что он еще будет отрывать два часа от сна на решение дополнительных задач.

Не хочет:
Если предыдущие три причины закрыты, то здесь мы приходим к тому, чего он вообще хочет как человек и подбору аргументов для его убеждения.

Ситуация №2. Человек обещает что-то сделать, но потом не успевает и пять раз переносит срок: “тут осталось совсем чуть-чуть, завтра должно быть готово”.

Не вдаваясь сейчас в техники планирования проекта и оценки задач, про которые мы как-то уже говорили, нарисуем очередную матрицу 2 на 2:
1
По одной шкале у нас отложена критичность задач, по другой — понятность. (Отдельный вопрос — как измерять понятность задачи, мы его вынесем за рамки этой статьи.)

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

То есть, общая рекомендация — идти контр-интуитивным порядком:
3
Начиная с самых непонятных, но критичных задач. Начав с них в начале проекта, у нас остается еще большой временной буффер для реакции на изменения.

Пример не из IT. Какое-то время назад мы со SlavaPankratov запускали параллельно 20 онлайн программ обучения по самым разным направлениям. Это происходило 3 раза в год. Работала команда из 20 экспертов, Наша задача помимо всего прочего была — собрать с них информацию и создать 20 анонсов.

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

Не с первого раза, но мы пришли к тому, что начали начинать с самых непонятных анонсов. Это категорически неприятно, потому что противоречит нашей природе (вначале надо съесть вкусное пироженое, а потом невкусную печеночную котлету — можно, я ее вообще не буду есть?) Но в том случае у нас оставалось несколько дней, чтобы задать все вопросы нашим экспертам. И о чудо, к последней ночи перед релизом все уже было давно готово.

Второй часто встречаемый момент — неправильный тип контроля. Для контроля таких задач мы выбираем случайный (когда вспоминаем) или же предварительный тип контроля вместо периодического или поэтапного. В двух словах, не сильно углубляясь во все типы контроля:

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

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

В случае же непонятных задач мы применяем:

  • Периодический тип контроля (контроль через равные промежутки времени). Типичный пример: скрам митинги или ежедневные планерки. Или:
  • Поэтапный тип контроля, когда работа разбивается на смысловые этапы. И мы проверяем, что получилось на каждом из смысловых этапов. Пример: 1-й этап: прототип, 2-й: реализация базовой функциональности и т.д.

 

Пример. Например, через 2 недели к вам приезжает технический директор, для которого вам нужно сделать презентацию архитектуры вашего проекта. Эту задачу вы поручаете архитектору вашего проекта. Он как обычно на “менеджерские задачи” говрит: “Так чего там делать-то? Не вопрос!” и уходит.

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

Но если вы когда-нибудь видели, как технические люди могут рисовать презентации (и самое главное — вы не видели, как презентации рисует ваш архитектор) вы выберете другой тип контроля:

Периодический: “Смотри, задача критичная, по ней нас будут оценивать. И мы с тобой такие задачи раньше не делали. Поэтому давай встречаться каждые пару дней, смотреть, что там происходит?”

или

Поэтапный: “Смотри, задача критичная, по ней нас будут оценивать. И мы с тобой такие задачи раньше не делали. Давай ее побьем на этапы, например структура презентации, потом диаграммы, картинки, потом уже сами слайды?”

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

Подводя короткий итог — проблема с недостатком ответственности у инженеров всегда требует конкретизации. (Ваш К.О.) И как только они конкретизированы — дальше решение приходит само.

 

Права на данную статью принадлежат

   footer_logo


Вы можете пропустить чтение записи и оставить комментарий. Размещение ссылок запрещено.