По методологии при постановке задачи надо определить следующее.
• Четкую цель. Не «Разберись с этим там, как его», а «Подготовь вместе с юристом претензию». А то может оказаться, что вы имели в виду «удовлетворить клиента», а сотрудник решит разобраться с ним в меру своего понимания. А вам потом прятать тело.
• Измеримость или возможность проверить результат. Главный вопрос — как понять, что задача решена. В случае с мешками — если нет щелей, через которые может протечь вода. Результат — здание не затопило, а измеримость — высота баррикады и ее непрерывность.
• Принципиальную достижимость. Можно, конечно, ставить недостижимые задачи, но, как правило, пару раз. Дальше сотрудники просто не будут их решать. Человек должен чувствовать, что может взять это препятствие.
• Срок. Задача без сроков будет выполнена в ближайшее никогда.
Для неопытного подчиненного задача подробно объясняется и проговаривается. Затем человек должен попытаться рассказать, как он ее будет решать. Это нужно для того, чтобы убедиться, что вы оба одинаково поняли ситуацию, смысл задачи и желаемый результат. Скорее всего, по ходу этого процесса возникнут вопросы — надо будет обдумать будущее, представить каждый этап решения задачи — и понять, какие грабли могут ждать по дороге. Обсудить их и ответить на вопросы. Продумать риски, обговорить, что делать, если что-то из этих рисков сработает.
Кто может решить задачу
Бывает, что решение не выполняется. Или выполняется так феерично, что лучше бы за задачу вообще никто не брался. Так случается в любой компании, и, конечно, такое регулярно бывает у нас.
Почему так случается? Чаще всего потому, что решение выработал человек, который не имел компетенции, полномочий или не получил поддержку тех, кто будет его внедрять. Даже если решение трижды правильное — нужно, чтобы это как минимум поняли исполнители.
Еще случается, что исполнителю (или исполнителям) не хватает каких-то кусков власти или ответственности. Чтобы это пояснить, обратимся к Ицхаку Адизесу[48]. У него в модели это называется CAPI: власть, полномочия и авторитет[49].
Он точно будет у вас как у учредителя. Вы (до уровня среднего бизнеса) еще достаточно хорошо разбираетесь в работе каждого и при этом можете творить что хотите на потребу своей черной душе. И обижаться на вас сотрудникам смысла нет: это же ваши бабки. Если вы хотите их феерично потратить — пожалуйста. Но если решение принимает человек уровнем ниже, то начинаются споры в компании. Особенно в проекте, который затрагивает две команды. Так что все будут бегать наверх с более-менее значимыми вопросами. Второй вопрос связан с повторяющимися процессами. Есть два способа не делать тупую повторяющуюся работу.
1. Написать скрипт и потом его тупым и повторяющимся способом поддерживать.
2. Или перепоручить эту работу тому, кто способен ее сделать и чье время обойдется дешевле.
Скрипт часто стоит дорого, поскольку дорого стоит время людей, которые его пишут. Кроме того, есть много неповторяющихся или неалгоритмизируемых задач, для которых нужен человек. Его надо выбрать. Именно так выглядит модель принятия решений. Поэтично она звучит так: «Решение принимается как можно ближе к клиенту». В терминах экономики — при минимальной стоимости времени участников. Тех, у кого есть минимально достаточные власть, полномочия и компетенции решить задачу.
Процедура выбора выглядит так. Предположим, появилась задача, надо сделать листовку для выставки. Идем к главному — учредителю. Говорим: ты будешь делать листовку или делегируешь? Он: вы чего, упоролись? Конечно, делегирую, у меня вот гендир есть. Спрашиваем того: будешь сам или делегируешь? Он: конечно, делегирую, вот у меня руководитель корпоративного подразделения Аня в подчинении. Та делегирует руководителю команды дизайна Любе. Люба передаст задачу верстальщику. А тот скажет: мне делегировать некому, я буду делать. Я что угодно могу сделать, только дайте техзадание, фотографии и поесть. Человек нашелся. Спрашиваем у него: можешь сам достать? Он говорит — нет. Другими словами, ему надо три компонента, которые он не может произвести сам. По каждому из них поднимаемся к его руководителям и выше в поисках того, кто может дать ресурсы. В итоге выясняется, что сделать листовку может теплая компания из верстальщика, менеджера корпоративного отдела, пиарщика и фотографа. Обратите внимание: в этом примере нигде нет руководителя, который утверждает эту листовку. Потому что раз он решил делегировать свой кусок работы подчиненному, то доверяет результату.
Это довольно необычный момент. Оказалось, что мы еще и неправильно делегировали. Точнее, не было методологии, все делалось интуитивно, а потом расшаталось. Когда вы поручаете кому-то часть работы, то даете ему две вещи:
1) полномочия;
2) ответственность.
Полномочия — это когда человек имеет право принять решение. Ответственность — когда он полностью отвечает за результат. Другими словами, какой бы результат вам ни принес подчиненный, вы с ним заранее согласны. Иначе это не делегирование, а совместная работа. Я не говорю, что это плохо, просто это немного другое. И в нашей цепочке «Кто будет делать листовку» появился бы не ваш подчиненный, а вы лично. И отвечали бы вы лично (хотя все равно вы всегда ответственны за действия подчиненного).
Когда вы делегируете кому-то полномочия, то должны давать возможность говорить не только «нет», но и «да». Точнее, сначала можно делегировать только «нет», а потом, когда человек справляется с работой, — и право на «да». Так вот, если вы даете человеку право принимать решения, то уже любые. Включая очень страшные положительные. Это полномочия.
Еще нужны власть и компетентность. Одно от другого отличается тем, что полномочия — это право что-то делать или не делать, а власть — возможность убеждаться, что результат будет.
Вы обращаетесь к человеку с задачей, а он почему-то вам не отказывает и делает все хорошо. Мы называем это системой двух морковок — спереди и сзади. Например, если контрагент сдал проект за неделю до дедлайна — премия. Если позже срока — неполная оплата. Кстати, отлично работает для ремонта-инженерки и сайтов.
Часть власти — это право наказывать и поощрять за результаты. Вторая — возможность убедить человека помогать без задействования других рычагов, то есть авторитет.
Когда люди объединяются в проектную команду, у них есть формальный руководитель. Он отвечает за результат. Чтобы он стал фактическим руководителем, ему нужна реальная власть. Для этого он должен быть достаточно убедительным, или же иметь для всех премию и дебафф (нечто обратное бонусу, но не штраф) за выполнение либо срыв проекта. Или же оказать поддержку им. Или же придумать что-то еще.
Авторитет гораздо эффективнее материальных стимулов (ведь в компании все хотят примерно одного), поэтому нужна процедура договаривания с проектной группой. Когда люди между собой пообщались и каждый все понял, это лучше, чем каждого заставили. Результат — проектная группа вырабатывает общее решение и назначает диктатором по внедрению руководителя проекта.
Следующая важная вещь — компетентность, то есть знания для принятия решения. Нужно звать в проектную группу кого-то, кто может дать нужные данные ответственному. А потом использовать механику демократуры.
Демократура — это тоталитарная демократия. Бизнес-термин несколько отличается от политического. Решения принимаются демократически одним человеком в дисперсионной структуре, а потом исполняются тоталитарно в иерархической. Есть процедура, где мнение каждого учитывается и вносится в решение. Или человеку внятно объясняется, почему так делать не надо.
Как один человек может принять решение демократически? О, это тоже прекрасное изобретение научной организации труда. Нам очень нравится пример одного строителя, который решил уволить сотрудника за то, что тот появился на проходной пьяный. За провинившегося вступилась вся бригада — все хотели, чтобы начальник его «отмазал» и не применял ТК. Тогда он задал простой вопрос:
— Нужны двое, кто за него поручится. Придет пьяный еще раз — лишу премии.
Как это ни странно, тут же бригада из стадии «начальник — олень» перешла к стадии конструктива. И поняла, что сотрудник напьется, и очень скоро. И вопрос надо решать сейчас.
Руководитель — диктатор. Но голоса всех иногда могут переломить ситуацию.
Ответственность руководителя
В разных компаниях виды ответственности разные. Подходы у каждого свои. Как правило, в самом-самом начале делегирование напоминает «принеси-подай-иди-к-черту-не-мешай», то есть классический микроменеджмент. Со временем становится понятно, что это не проходит и надо приходить к более прогрессивной модели — когда кто-то в компании (кроме вас) все же думает.
Главное здесь — не лезть и не мешать сотрудникам почувствовать себя самостоятельными. Это значит — поддерживать их идеи, не ругать за работу на «четверку с минусом» (наоборот, хвалить, потому что иначе в итоге все делали бы вы) и вообще всячески развивать подход. Задача — найти или вырастить того, кто компетентнее вас в этом вопросе.
Дальше встает вопрос делегирования. Со временем можно дать право на «нет» — разрешать отказываться и не позволять соглашаться. Потом вы делегируете и право на «да».
Если перестраховаться, получится человек, который знает, почему и когда надо отказать в проекте, но не знает, за что нужно цепляться и делать. Потому что страшно. У нас в культуре всегда было право на «да» и на ошибку, но мы передавали их устно, и вот в какой-то момент что-то пошло не так. В книге «Бизнес как игра» даже глава есть про испорченный телефон — «Не “Идите в ж…”, а “Добро пожаловать”». Она о том, как информация искажается при передаче. Эту главу очень любят цитировать журналисты, их эти слова приятно греют. Вот у нас тоже задумывалось «Добро пожаловать», но в ряде случаев получилось другое.