Страница 34 из 66
Лучший способ скорректировать ожидания других в отношении вашей работы — стабильно выполнять обещанное, а не постоянно объяснять, что и как вы делаете. Приобретите репутацию сотрудника, который никогда не подводит, а не того, кто только и думает о собственной продуктивности. Если вам поступает запрос — неважно как, по электронной почте или в личной беседе, — обязательно его обработайте. Не допускайте того, чтобы что-то ускользало от вашего внимания. Если обязались выполнить работу к определенному сроку, сдержите обещание или объясните, почему вам нужно больше времени. Если люди доверяют вам самостоятельно выполнять порученную работу, значит, их устраивает та ситуация, что вы не реагируете на их сообщения немедленно. Напротив, если вы не держите обещаний, окружающие будут настаивать на быстром ответе. Они считают, что должны контролировать вас, чтобы работа была выполнена. Профессор и автор деловой литературы Адам Грант для описания этого явления использует понятие «идиосинкразический кредит»[132]. Он объясняет, что чем лучше вы выполняете свою работу, тем охотнее вам разрешают отличаться от остальных в том, что касается применяемых методов, без каких-либо объяснений.
Еще один момент, который возникает в связи с изменением ваших рабочих процессов, связан с системными интерфейсами. Если вы захотите внедрить передовые системы управления процессами, речь о которых пойдет в следующих главах, вам придется решить, каким именно образом остальные сотрудники, которые привыкли привлекать ваше внимание с помощью кратких сообщений, должны взаимодействовать с этими более структурированными альтернативными вариантами.
Проводников в этой сфере мы можем найти среди сотрудников IT-отдела. Как я уже отмечал, пару десятилетий назад именно они начали организовывать процесс решения технологических проблем, внедрив так называемые системы обработки заявок. Каждый поступающий запрос оформляется как заявка. Все обсуждения и комментарии, связанные с конкретной проблемой, прикрепляются к заявке, и их легко найти.
Технические специалисты быстро поняли, что тщетно просить сотрудников, поддержку которых они осуществляют, пользоваться непосредственно интерфейсом системы обработки заявок (например, когда нужно зайти на специальный сайт, создать заявку и отслеживать ее статус). В принципе, это, наверное, наиболее эффективная система решения технических проблем. Но реальность такова, что большинство сотрудников не готовы мириться с дополнительной нагрузкой. Решением стал цельнокроеный интерфейс. В большинстве организаций сотрудники теперь заявляют о проблеме наиболее естественным образом: отправляют электронное письмо на многофункциональный адрес, например [email protected] Большинство систем обработки заявок настроены таким образом, что автоматически собирают такие письма, преобразуют их в заявки и помещают в виртуальный почтовый ящик для ожидания обработки. Во время работы IT-специалиста над проблемой система может посылать автоматические уведомления об обновлении статуса заявки. Они приходят сотруднику, который обозначил проблему, в виде электронных сообщений. Людям, общающимся с IT-специалистом, совсем не обязательно разбираться в системе обработки заявок. Они просто отправляют письмо и получают ответ с информацией о текущем статусе. Но за этим фасадом протекает внутренний структурированный процесс.
То же самое относится и к системам, которые вы внедряете для организации личного рабочего процесса. Не требуйте от тех, с кем вы работаете, чтобы они разбирались в ваших новых процедурах или меняли свои способы взаимодействия с вами. Вместо этого используйте цельнокроеный интерфейс, если это возможно. Чтобы вы поняли, как это работает, обратимся к моему опыту преподавательской деятельности. В тот год, когда я написал большую часть этой книги, я стал заведующим аспирантурой факультета информатики в Джорджтауне. Эта должность предполагала, что я буду возглавлять комиссию, которая контролирует программу подготовки аспирантов, в том числе одобрять преобразования и отвечать на вопросы о программе.
Как вы понимаете, в результате мне начало поступать много запросов, которые я должен был обрабатывать. Я взял за основу руководство Девеша и создал доску в Trello для внутреннего пользования, чтобы упорядочить запросы. В моей доске были следующие колонки:
• Ожидает ответа.
• Ожидает ответа (не срочно).
• Обсудить во время следующего заседания комиссии.
• Обсудить во время следующего заседания комиссии с участием заведующего кафедрой.
• Ожидает ответа от третьего лица.
• В работе на этой неделе.
Когда кто-то присылал мне электронное послание или задавал вопросы о программе подготовки аспирантов, проходя мимо моего кабинета, я тут же записывал информацию на карточку и помещал ее в соответствующую колонку в Trello.
В начале каждой недели я заходил на доску и перемещал карточки: решал, над чем буду работать и какие вопросы стоит обсудить на предстоящих встречах. С помощью системы я мог следить за прогрессом по тем делам, где требовалась обратная связь от других сотрудников. У меня было главное правило: когда я перемещал карточку в другую колонку, то отправлял электронное письмо об изменениях тому сотруднику, который поднял соответствующий вопрос. Например, если я перемещал карточку из колонки «Ожидает ответа» в колонку «Обсудить во время следующего заседания комиссии», я отправлял письмо автору проблемы и сообщал, что скоро мы будем обсуждать поднятый им вопрос. Если я убирал карточку с доски, потому что задача была выполнена, то информировал соответствующих сотрудников об окончательном решении. И так далее.
Главная особенность этой системы состоит в том, что преподаватели и аспиранты моего факультета ничего о ней не знают. Думаю, я мог бы заставить всех их подключиться к системе, размещать на досках Trello новые задачи и отслеживать статус старых. Теоретически мне бы тогда пришлось отправлять чуть меньше писем. Но реальность такова, что никто не будет этим заниматься. И я не могу винить их! Я трачу примерно тридцать минут раз в неделю, чтобы проанализировать информацию на доске и отправить сообщения об изменениях, и получаю огромное преимущество благодаря тому, что смог четко структурировать информацию. А поскольку я трачу еще немного времени на создание цельнокроеного интерфейса, мои коллеги тоже могут пользоваться преимуществами этой системы.
На первый взгляд кажется, что мой совет применять принцип бережного распределения внимания по отношению к группам противоречит применению того же принципа для отдельно взятых сотрудников. Работа с группой подразумевает, что система коммуникации, пришедшая на смену гиперактивному коллективному разуму, должна быть максимально четкой. Тогда как в отношении отдельно взятых сотрудников принцип бережного распределения внимания не предполагает огласку. Но если мы присмотримся повнимательнее, то обнаружим, что оба подхода основываются на одном и том же: людям не нравятся изменения, которые они не могут контролировать.
Если вы хотите изменить работу всей организации или отдельной команды, можно вовлечь в этот процесс сотрудников и дать им возможность его оптимизировать. Как мы уже отмечали раньше, такой шаг сохранит внутренний локус контроля и будет мотивировать людей поддерживать изменения. И обратная ситуация складывается, если вы решили изменить свой личный стиль работы. Точка зрения ваших коллег не имеет отношения к принятым вами решениям. И если в результате они столкнутся с новой системой, которая повлияет на их работу, локус контроля станет внешним, сотрудники будут раздражаться и откажутся принимать ситуацию, пытаясь восстановить контроль над ней. Они не станут аплодировать вашему новому умному автоответчику, а попробуют обойти те ограничения, которые возникнут с его появлением.
132
Например, см. статью: Adam Grant, “In the Company of Givers and Takers,” Harvard Business Review, April 2013, https://hbr.org/2013/04/in-the-company-of-givers-and-takers.