Бизнес на свои

Ну, и еще один урок мотивации преподнес товарищ майор, который однажды вечером пришел в офис с тетрадками. Раздал их сотрудникам и сказал: несмотря на то, что у нас офис, случиться может всякое. В военное время потери среди персонала допустимы, а в мирное — возможны. Вот вчера один яркий дебил со стремянки упал и сломал себе ногу, например. Он верит, что в каждом из нас тоже есть что-то яркое. И поэтому надо каждый день последние десять минут рабочего времени тратить на то, чтобы записать все, что мы узнали за день и что вообще случилось. Чтобы, если бойца убьют, другой мог продолжить его работу. Мы писали и понимали, что он все это будет читать. И поэтому каждый день хотелось сделать что-то значимое. Не будешь же писать «Весь день тупил и смотрел на обои», правильно?

В компании стоит ввести небольшие ежедневные или еженедельные отчеты. Отчеты — это не только способ мониторинга прогресса по задачам. Еще они помогают видеть движение на стратегическом уровне. Другими словами, они заставят задуматься о более крупных задачах, чем изучение рисунка обоев.

Как ставить задачу

Поставить задачу подчиненному — отдельный важный навык. Самый простой способ — рассказать, что и как делать, на уровне детализации по алгоритму выполнения. Например: «Бери мешки с песком с грузовика и укладывай вокруг здания». Как правило, такой подход характерен для неопытного руководителя.

Опытный скажет следующее: «Миша, смотри, тут метеорологи говорят, что ожидается сильный дождь. Два года назад у нас после сильных дождей начало подтапливать здание. Если мы не хотим потом откачивать воду с первого этажа и ремонтировать тут все — а мы не хотим, — то надо построить вокруг здания баррикаду из мешков. Тогда вода к нам не зайдет. Вот водитель подвез сами мешки. Я могу быть уверен, что к вечеру тут будет правильная баррикада и ночью нас не затопит?»

Задача из описания процесса превращается в описание смысла, цели и результата. И уже после того, как дело сделано. Чем сложнее задача, тем больше нужно смысла и цели и меньше процесса. Сотрудник сам с удовольствием разобьет это на алгоритм и попробует сделать. Если он не очень опытный, стоит прямо при постановке спросить его, как он будет решать задачу и в какие сроки какой кусок сделает. Получится план-график, который будет не очень точным поначалу, но позволит контролировать исполнение не в конце, а в процессе.

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

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

• Четкую цель. Не «Разберись с этим там, как его», а «Подготовь вместе с юристом претензию». А то может оказаться, что вы имели в виду «удовлетворить клиента», а сотрудник решит разобраться с ним в меру своего понимания. А вам потом прятать тело.

• Измеримость или возможность проверить результат. Главный вопрос — как понять, что задача решена. В случае с мешками — если нет щелей, через которые может протечь вода. Результат — здание не затопило, а измеримость — высота баррикады и ее непрерывность.

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

• Срок. Задача без сроков будет выполнена в ближайшее никогда.

Для неопытного подчиненного задача подробно объясняется и проговаривается. Затем человек должен попытаться рассказать, как он ее будет решать. Это нужно для того, чтобы убедиться, что вы оба одинаково поняли ситуацию, смысл задачи и желаемый результат. Скорее всего, по ходу этого процесса возникнут вопросы — надо будет обдумать будущее, представить каждый этап решения задачи — и понять, какие грабли могут ждать по дороге. Обсудить их и ответить на вопросы. Продумать риски, обговорить, что делать, если что-то из этих рисков сработает.

Кто может решить задачу

Бывает, что решение не выполняется. Или выполняется так феерично, что лучше бы за задачу вообще никто не брался. Так случается в любой компании, и, конечно, такое регулярно бывает у нас.

Почему так случается? Чаще всего потому, что решение выработал человек, который не имел компетенции, полномочий или не получил поддержку тех, кто будет его внедрять. Даже если решение трижды правильное — нужно, чтобы это как минимум поняли исполнители.

Еще случается, что исполнителю (или исполнителям) не хватает каких-то кусков власти или ответственности. Чтобы это пояснить, обратимся к Ицхаку Адизесу[48]. У него в модели это называется CAPI: власть, полномочия и авторитет[49].