с чего начать управление коллективом
Как поставить себя в новом коллективе: 7 советов руководителю
1. Познакомьтесь с командой
«О том, что у нас появился новый начальник, мы узнали по сарафанному радио. Сам он впервые зашел в нашу комнату примерно через неделю после выхода. До этого мы видели его бегло в коридоре: всё время он проводил у высшего руководства. Мы чувствовали себя ненужными и между собой сразу невзлюбили нового босса», — вспоминает Ирина, менеджер по продажам строительной компании.
Официальным знакомством не стоит пренебрегать. В зависимости от традиций вас может представить коллективу топ-менеджер, руководитель HR-службы, или вы сами можете организовать встречу.
Екатерина Заричная, бизнес-тренер компании «Практики управления», отмечает, что представить нового руководителя надо обязательно, даже если он коллективу уже знаком — вырос внутри компании. Так происходит «инициация» руководителя в новой роли.
На первой встрече ваша задача — произвести приятное впечатление. Кратко расскажите о себе, своем опыте и планах.
Александр Савельев, руководитель отдела маркетинга корпоративных клиентов компании Skyeng, вспоминает свой опыт: «Мне достаточно было показать, что я не «назначенец», а вполне понимаю, чем они занимались ранее, и у меня есть план что делать дальше».
Озвучить серьезные изменения с ходу не получится, зато можно обозначить, что в ближайшее время вы войдете в курс дел и встретитесь с каждым сотрудником (или с каждой группой сотрудников либо руководителями отделов в зависимости от масштабов коллектива).
2. Познакомьтесь с другими руководителями
Плохие коммуникации с «соседями» могут создать большие проблемы в работе, а также дать повод для сомнений в вашей компетентности. Бизнес-тренер Людмила Городничева, партнер компании Right Solution, часто сталкивается с тем, что незрелые руководители не умеют выстраивать границы со смежными департаментами и, стараясь понравиться руководству, берут на себя непосильные задачи. Затем эти задачи падают на команду, и люди начинают возмущаться.
Лариса Филатова, руководитель дирекции по работе с персоналом ОЭЗ «Технополис «Москва», дополняет, что поток задач со стороны смежных департаментов может стать вариантом проверки новичка. Коллеги прощупывают навыки взаимодействия и неформальной коммуникации.
Она советует обсудить с непосредственным руководителем круг обязанностей и ответственности. Если от соседей летят задачи, которые кажутся явно не вашими, то спросите прямо, с чем это связано. Вполне возможно, в компании так принято работать или коллегам действительно нужна помощь здесь и сейчас. Если все-таки это попытка создать для вас невыносимые условия работы (что маловероятно) или проверить вас на прочность, то имеет смысл обратиться к вашему руководителю с просьбой помочь разобраться в каналах взаимодействия и правилах игры.
3. Соберите информацию внутри команды
Когда Алексея назначили на должность директора по маркетингу, он был окрылен повышением и увлеченно стал разрабатывать планы. Он хотел запустить новую рекламную кампанию, замахивался на ребрендинг. Мотивированный, он работал сутками: бегал на презентации, назначал встречи с подрядчиками, приводил в офис журналистов.
А команде все это было в новинку: люди не понимали, куда «летит» новый директор, почему всё нужно так срочно и главное, чем плохо было раньше. Алексей старался быть открытым, но на вопросы у него почти никогда не хватало времени. Стоило начать разговор с ним, как ему звонили очередные партнеры, он извинялся и уходил. Коллективу были непонятны как личность начальника, так и «прилетающие» от него поручения. Вскоре ключевые сотрудники департамента начали увольняться один за другим.
В нашем менталитете сильно сопротивление переменам: все знают, что «новая метла по-новому метет», и эта фраза имеет скорее негативную окраску. Проще говоря, от нового руководства хорошего не ждут.
Чтобы снять общую тревожность, больше общайтесь с командой, знакомьтесь с коллегами. На первой неделе стоит организовать общую или индивидуальные встречи, чтобы почувствовать настроение коллектива и узнать, как обстоят дела, какие есть узкие места в работе.
Александр Савельев советует тщательно готовиться к этой встрече: составить список вопросов, изучить последние отчеты и регламенты. На самой встрече предоставьте слово собеседнику, делайте для себя пометки во время общения, чтобы ничего не забыть.
4. Не спешите с критикой
Многие руководители стремятся быстрее проявить себя на новом месте и демонстративно ломают старое. Татьяна Долякова, основатель кадрового агентства ProPersonnel, отмечает, что российские менеджеры любят сразу применять жесткие меры: кого-то увольняют, вводят штрафы, подчеркнуто обесценивают опыт предшественника, пересматривают мотивацию персонала и тем самым, вместо того чтобы обрести в коллективе искренних союзников, демотивируют людей.
Иногда рвением к переменам можно испортить отношения не только с командой, но с руководством.
Карьерный консультант Оксана Дебольская вспоминает кейс из своей практики: к ней обратился молодой человек, получивший долгожданное назначение на позицию начальника отдела. Приняв дела, он начал яростно критиковать работу своего предшественника. При этом он часто употреблял «мы», «нас», имея в виду коллектив отдела. Он не учитывал, что некоторые решения предыдущего руководителя исходили из политики вышестоящего начальства. Получалось, что тем самым он активно критиковал и свое нынешнее руководство. В итоге его быстро заменили более сдержанным руководителям.
5. Не теряйте границы
Безусловно, с командой важно наладить хорошие отношения, но важно и не перейти грань, за которой подчиненные начнут вами манипулировать и относиться к вам панибратски. Это ложная дружба, она не гарантирует того, что коллектив поддержит вас в сложной ситуации. Наоборот, привыкнув к свободе, они могут постоянно манипулировать вами.
Оксана Дебольская рассказала, с какими трудностями столкнулась одна ее клиентка, став начальницей в новом коллективе. Она была ответственной, умной, профессиональной, но слишком демократичной. От нее ожидали стандартных действий руководителя в отношении коллектива — контроля за дисциплиной, качеством работы, организации четкого командного взаимодействия с другими подразделениями. А она действовала слишком мягко, упрашивала, уговаривала, обещала поблажки в виде отгулов и премий там, где не требовалось никаких сверхусилий, а надо было просто хорошо сделать свою работу. В результате ее команда видела в ней «своего парня», а не начальника.
6. Будьте открытыми
Эксперты едины во мнении: чтобы наладить отношения, нужно показать свою открытость, увлеченность и готовность к диалогу — тогда сотрудники ответят взаимностью.
«Сейчас в тренде ответственность, профессионализм, вовлеченность сотрудников. Поэтому и относиться к ним стоит как к профессионалам, любая критика должна быть конструктивной, общение — тактичным», — напоминает Владимир Щербаков, директор по развитию Teachbase.
7. Не спешите увольнять и нанимать
Многие руководители грешат тем, что пытаются на новом месте воссоздать условия своей прежней работы. Речь не об уникальных успешных практиках, а о подходах и способах коммуникации, которые руководителю просто привычны. И о найме своих прежних коллег — не потому, что они лучше нынешних помощников, а потому, что он к ним тоже просто по-человечески привык. Стоит ли говорить, что замена ключевых сотрудников на новом месте «своими людьми» вызывает особенное неудовольствие коллектива?
Не стоит спешить с увольнениями, пока вы недостаточно знаете ситуацию. Даже если вы решились привести в новую компанию старых коллег, оцените, впишутся ли они в новую команду.
«Не стоит делать этого сразу: сначала присмотритесь к компании и ее корпоративной культуре. Бывают ситуации, когда действительно лучше сосредоточиться на развитии имеющейся команды», — заключает Владимир Щербаков, директор по развитию Teachbase.
А если саботаж?
Бывает, как бы руководитель ни старался выстроить конструктивные отношения, коллектив все равно его не принимает. Возможно, они были очень привязаны к предыдущему руководителю или, наоборот, руководители менялись в компании слишком часто.
«Жаловаться своему непосредственному руководителю стоит в последнюю очередь, хотя и скрывать от него свои ваших инициативы по увольнению не нужно», — уточняет Лариса. Подробнее о том, как действовать, если команда бойкотирует нового босса, мы рассказывали здесь.
Татьяна Долякова советует управленцам на новом месте в первую очередь искать союзников из числа наиболее мотивированных и эффективных сотрудников: их надо беречь, потому что выполнять свои задачи вы будете с их помощью.
Как управлять командой на проекте
Чтобы не облажаться перед заказчиком и не разругаться с коллегами
Я пять лет проработала менеджером проектов в креативных агентствах.
Любой проект — результат совместной работы множества специалистов. Например, нужно сделать промосайт для банка. Этим проектом будут заниматься дизайнеры, редакторы, фронтенд- и бэкенд-разработчики.
На таком проекте работают от 8 до 20 человек. Когда мы не можем решить задачу своими силами, нанимаем еще и подрядчиков. А менеджер проектов управляет всей этой ордой: ставит задачи, контролирует выполнение, решает проблемы и делает так, чтобы к назначенному сроку клиент получил качественный продукт. Расскажу, как с этим справиться.
В чем проблема с управлением командой
В идеальном мире не нужно никем управлять: все работают сами. Дизайнер берет задание, рисует прототип и макет сайта, показывает результат заказчику. Тот доволен и хлопает в ладоши — никаких правок. Дизайнер передает макеты разработчику, а потом бац — и сайт готов. Заказчик с самосвала выгружает мешки с деньгами в благодарность за работу и уезжает в закат. Все счастливы.
Но мы не в идеальном мире, поэтому, если не контролировать каждую мелочь, все идет наперекосяк. Вот типичные проблемы, которые сваливаются на менеджера проектов:
За годы работы я научилась не допускать таких проблем, а если уж они случились, то оперативно их решать. Спойлер: мой секрет успеха — грамотная коммуникация в команде и ультимативная ответственность менеджера. Об этом расскажу дальше в статье.
Планируйте проект вместе с командой
Я не сторонник диктаторского подхода, когда руководитель спускает план сверху и ставит сотрудников перед фактом: «Это нужно сделать до вторника, а вот это — уже к завтрашнему дню. Что значит „нереально успеть“? Я вам плачу за работу, а не за рассуждения о том, что реально, а что нет».
Моя команда — это специалисты, которые выполняют задачу руками. Именно от них зависит, в какой срок мы выполним проект, поэтому я всегда привлекаю коллег к планированию. Так я получаю реалистичную оценку задачи. Заказчик может думать, что проект элементарный и его можно сделать за пару дней. Это нормально, ведь он не специалист, а со стороны многие процессы кажутся проще, чем есть. Члены команды, которые уже выполняли похожие проекты, способны точно оценить временные затраты, учесть детали и увидеть сложности там, где я не замечу.
А еще такой подход добавляет команде мотивации и ответственности. Специалисты работают не по моему плану, а по своему: они придерживаются сроков, которые сами предложили.
Представьте ситуацию: начальник установил срок, который сотрудник считает нереальным. Сотрудник попробовал поспорить, но безрезультатно. Он пожимает плечами и как будто бы уходит работать, но на самом деле занимается саботажем: зачем стараться, если все равно не успеешь и получишь нагоняй от шефа. В итоге задача провалена, руководитель в ярости, а сотрудник твердит: «Я же сразу предупреждал, что не успею».
Схема обычно такая:
Вот как я это делаю:
Катя, нам нужно отрисовать четыре адаптивных макета на основе твоей концепции. Задание и концепт — по ссылкам. Прошу тебя оценить срок отрисовки в часах, как обычно. Заказчик очень хочет уложиться в неделю, но это обсуждаемо. Оценку, предложения и вопросы буду ждать сегодня до 19:00. Если нужно созвониться, говори.
Бывает, что оценка специалиста сильно отличается от моих ожиданий или сроков клиента. Но это не повод продавливать исполнителя. Например, заказчик хочет видеть два макета через неделю, а дизайнер говорит: «Нет, так не получится. Мне нужно две недели». Тогда мы можем попробовать:
Обозначайте роли на проекте
Если упростить, то на любом проекте можно выделить три роли:
На разных проектах в разнообразных связках работают разные специалисты, поэтому команды постоянно перемешиваются. Хорошая практика — «знакомить» исполнителей между собой. Когда я начинаю работу с новой командой, то обязательно обозначаю, кто чем занимается и за что отвечает. Выглядит это так:
Иногда клиенты начинают бомбардировать комментариями всех, чьи контакты знают, — это мешает процессу. Поэтому важно установить понятные правила коммуникации: например, что общение с заказчиком ведется только через менеджера проектов и никак иначе.
Планируйте нагрузку специалистов
Один и тот же сотрудник может одновременно участвовать в нескольких проектах. Например, дизайнер два часа в день тратит на разработку идеи посадочной страницы для авиакомпании, а шесть часов — на отрисовку интерфейса личного кабинета для банка. Задача менеджеров разных проектов — договориться друг с другом и поделить рабочее время специалистов так, чтобы те не перерабатывали и не бездельничали.
Еженедельные планерки помогают синхронизироваться. До планерки менеджеры проектов распределяют часы загрузки специалистов в специальной программе Harvest. Это удобно: можно зафиксировать, кто, что и в какой день делает. Чтобы не тыкать пальцем в небо, на этом этапе снова просим специалистов оценить, сколько времени им нужно.
А уже на планерке сверяем расписание. Иногда случаются конфликты интересов: например, двум менеджерам нужен один и тот же разработчик на всю неделю. В таких случаях мы передоговариваемся и корректируем планы.
Мы стараемся делать так, чтобы специалистам не нужно было постоянно переключаться между проектами: это занимает время. Принцип такой: ежедневно не более 2—3 задач из разных проектов. Идеально, когда человек занимается одним и тем же весь день или даже неделю, но так получается не всегда.
Долгосрочное планирование времени всей команды — удобная и полезная вещь. Она позволяет предсказать и предотвратить следующие проектные проблемы:
Убраться самому или позвать уборщицу?
Внятно ставьте задачи
Чтобы человек правильно выполнил задачу, он должен ее понять. Мой совет: не жалейте времени и сил на объяснение задачи. Иначе потеряете гораздо больше, когда специалист сделает не то, что нужно, и придется все переделывать.
Я использую подход SMART, который подразумевает, что задача должна быть:
Пример постановки задачи
Задача | Пример |
---|---|
Даем конкретную задачу | Вася, нужно сделать баннер 3 × 6 м, согласованное ключевое изображение и слоган — во вложении. Верстка макета — на основе гайдлайна, он тоже во вложении |
Ставим критерии выполнения задачи | Сначала делаем концепт — просто джипег и мокап, показываем клиенту. Потом доделываем и готовим к печати |
Определяем ограничения по времени | Концепт нужен завтра до 16:00. Вечером покажем клиенту и послезавтра доработаем |
Определяем, достижима ли задача | Что думаешь по срокам, успеешь? |
Согласуем задачу с исполнителем | Все понятно? Если нет, то жду вопросов. Если да, то отпишись, что взял задачу |
Письменно фиксируйте задачи и договоренности
Когда все договоренности устные, получаются примерно такие диалоги:
— Игорь, сегодня уже десятое. Ты обещал запустить сайт девятого, а он до сих пор не работает. Почему?
— Саша, ты что-то путаешь. Я обещал не девятого, а девятнадцатого. И не октября, а ноября. Наверное, ты меня неправильно поняла.
У нас действует правило: нет письма — нет задачи. Если что-то не записано — значит, не зафиксировано и это можно игнорировать. Раньше для постановки и объяснения задач мы пользовались электронной почтой, но это было неудобно: письма терялись, приходилось часами искать какие-нибудь правки по проекту Х от клиента Y с десятой итерации. Потом перешли на таск-менеджер — программу для обмена задачами и материалами. Теперь у нас все зафиксировано и записано, а каждый специалист понимает, где лежит эта информация.
Есть разные таск-менеджеры — выбирайте тот, что подходит вам по функциям и внешнему виду. Например, для меня важно, чтобы в программе был список задач по проекту с назначенными исполнителями и сроками выполнения. И обязательно нужны шаблоны типовых задач, чтобы быстро разворачивать однотипные проекты.
В последнем агентстве, где я работала, использовали «Эктив-коллаб». В компании, где тружусь сейчас, разработчики, финансисты и юристы пользуются «Джирой», а все остальные — «Асаной».
Как ставить задачу: чек-лист для менеджера
Одной реальной задаче соответствует одна задача в таск-менеджере. Не стоит плодить лишние сущности и путать коллег.
У задачи есть понятное название, которое соответствует ее содержанию. Удобно, когда можно прочитать заголовок и сразу понять, о чем речь.
Неверно: «Правки № 136 от Иван Иваныча».
Верно: «Внести изменения в логотип интернет-магазина игрушек для собак».
Есть описание. Расписывайте задачу максимально подробно, чтобы исполнитель однозначно ее понял.
Есть ссылки на источники материалов. Сделайте так, чтобы специалисту было удобно выполнить задачу. Пусть у него под рукой будет все, что нужно для работы.
Вот так не надо: «Миша, поправь макеты в соответствии с гайдлайном. Макеты я скидывала на файлообменник, ссылка должна быть у тебя на почте, поищи. А сам гайдлайн был где-то на сайте. Если не найдешь, то свяжись с Васей: он вроде говорил, что у него все есть».
Хуже этого описания только то же самое, но в аудиосообщении. Если так поставить задачу, специалист взвоет и постарается подольше не притрагиваться к ней. А когда приступит, потеряет целый день на сбор информации.
Установлен срок выполнения задачи. Важно не только обговорить конечный срок, но и письменно его зафиксировать. Иначе менеджер и исполнитель быстро забудут, о чем договаривались, особенно если задач много.
Есть план работы и промежуточные сроки. Если задача сложная, то стоит разбить ее на части, расписать каждую подзадачу и установить контрольные точки. Тогда, если что-то пойдет не так, менеджер узнает об этом сразу, а не к моменту сдачи проекта.
Специалист может задать вопросы и высказать мнение по задаче. Проблема в том, что некоторые люди стесняются спрашивать и уточнять. Они думают, что профессионал должен схватывать все на лету и не задавать лишних вопросов. Это опасное заблуждение приводит к проблемам в проекте.
Например, специалист столкнется с трудностями, но промолчит об этом, чтобы не показаться некомпетентным. Вместо того чтобы предупредить и попросить о помощи, он начнет решать проблему самостоятельно, не справится и подставит всю команду.
Поэтому всегда оставляйте дверь, в которую исполнитель может постучаться, чтобы обсудить проблемы и вопросы. Уточняйте: «А тебе точно все понятно? А у тебя есть все материалы, чтобы выполнить задачу?»
Есть просьба подтвердить, что задача принята. Нужно получить от исполнителя однозначное свидетельство, что он взял задачу в работу. Молчание — это не знак согласия. Согласие выглядит примерно так: «Все понял, материалов достаточно, вопросов нет, по срокам — ок, задачу забрал». Или в виде плюсика, как договоритесь.
Оберегайте команду от комментариев заказчика
Заказчик не обязан уметь формулировать комментарии так, чтобы они были понятны техническим специалистам. Если ему не нравится цвет, он может сказать: «Этот красный какой-то не такой, давайте что-то повеселее». Дизайнер читает эту правку и думает, что повеселее — это, например, желтый. Но на самом деле заказчик хотел просто сделать красный более ярким.
Чтобы дизайнер мог понять клиента, ему нужен более конкретный комментарий. Он бы предпочел услышать что-то вроде этого: «В файле ads.png используется составной черный цвет. В типографии опасаются, что этот цвет в печати провалится или его поведет в синий. Предлагают заменить его черным пантоном, чтобы все было в цвет».
И задача менеджера проектов — перевести замечания с языка клиента на тот, что будет понятен команде. Когда я получаю правки, то делаю три вещи:
Вместо того чтобы перенаправлять письмо заказчика напрямую исполнителю, я разбираюсь в сути информации. И только когда мне все уже понятно, иду с задачей к специалисту. Так я выступаю защитным фильтром от всяческого мусора, непродуманных задач и правок.
Организовывайте рабочие процессы и общение на проекте
Очень важно, чтобы люди свободно общались друг с другом, несмотря на расстояние и разницу во времени. По моему опыту, большинство проблем на проекте возникает из-за кривой коммуникации: кто-то не сказал, не предупредил, не уточнил информацию, не попросил о помощи.
Представьте, что все члены команды общались бы разными способами. Один сотрудник пишет всем через «Вайбер», другой предпочитает «Телеграм», третий — видеозвонки в «Скайпе». В итоге — полная анархия. Поэтому моя задача — чтобы каждый понимал, какие способы коммуникации есть в компании и как их правильно использовать.
Обычно я организую три пространства для общения: доска проекта в «Эктив-коллабе», канал в «Слаке» и видеоконференции в «Зуме».
«Эктив-коллаб» нужен, чтобы хранить задачи и материалы в одном месте, а также планировать и обсуждать проекты. Благодаря этому сервису нам не приходится общаться по работе в десяти разных мессенджерах, а потом часами искать нужные ссылки и файлы. Все находится в одном месте — на доске проекта в «Эктив-коллабе».
Мы стараемся максимально все стандартизировать, поэтому оформляем проекты по шаблонам: в них заранее созданы списки материалов и план работы. Благодаря такому подходу сотрудникам не приходится ломать голову и угадывать, где лежат нужные файлы.
Канал проекта в корпоративном мессенджере «Слак» — здесь мы обсуждаем текучку и мелкие вопросы. Этот мессенджер не хранит переписку, поэтому все серьезные дискуссии и решения мы переносим из «Слака» в «Эктив-коллаб».
«Зум» используем для созвонов. Здесь есть свои правила: нельзя просто взять и позвонить человеку. Предварительно нужно списаться в «Слаке»: договориться о времени звонка и теме разговора. Это делается, чтобы не застать собеседника врасплох и не отвлечь от других важных дел.
О подобных принципах мы рассказываем сотрудникам с первых недель работы. Если человек их нарушает, мы отдельно встречаемся с ним, напоминаем, кидаем ссылку на внутренние документы компании. Обычно одного-двух напоминаний хватает, чтобы договориться об одинаковых правилах игры.
Контролируйте работу над проектом
Выполнение любых задач нужно контролировать. Без контроля не будет и результата. Либо же вы получите результат, но не тот, что нужен заказчику, или не в те сроки, о каких договаривались.
Контроль важен, даже если в вашей команде одни гении. Особенно если в ней одни гении.
Есть большие задачи: например, разработать мобильное приложение для банка. В таких случаях я делаю подробный план: разбиваю задачу на множество мелких кусочков и прописываю, когда каждый кусочек должен быть готов и кто за это отвечает.
Но важно не перебарщивать с контролем: бюрократизация — это зло. Например, есть мелкие задачи: нарисовать баннер или логотип, написать статью для сайта. Если по подобным задачам я заставлю исполнителя отчитываться мне каждые полчаса, это будет только мешать и тормозить рабочий процесс. Достаточно где-то в середине выполнения задачи спросить, как дела и не нужна ли помощь.
Разрешайте конфликты и проблемы
Если люди работают в команде, то проблемы и ошибки одного участника неизбежно отражаются на других. Например, если дизайнер поздно сделал макет, то разработчику придется работать в ускоренном темпе, чтобы команда успела сдать проект. Либо руководителю придется договариваться с заказчиком об изменении сроков, что совсем не здорово.
Конфликты и проблемы возникают на проектах постоянно: все мы люди и каждый может ошибиться, что-то забыть, не учесть. Иногда все это происходит одновременно.
Конечно, лучше всего не допускать ошибок, а еще — быть здоровым, красивым и богатым. Но мы живем не в идеальном мире, так что проблемы случаются. Считаю, что систему характеризует не ошибка, а реакция на нее, поэтому я стараюсь превращать провалы в опыт.
Задача руководителя — вовремя выявлять и разрешать проблемы и конфликты. Вот как я это делаю.
Решаю проблемы своевременно. Если вопрос возник сегодня, то и обсуждать его нужно сегодня. Бывает, что руководитель внезапно вспоминает о какой-то ситуации, которая произошла полгода назад, и вызывает работника на разговор. Обычно конструктивного диалога не получается, так как сотрудник уже забыл, в чем там было дело, — или делает вид, что забыл.
— Юра, ты задолбал опаздывать, рабочий день начинается в 10:00, пора уже запомнить. С тобой одни проблемы!
— А какие еще проблемы?
— А помнишь, в позапрошлом месяце ты проигнорировал правки заказчика и сдал макеты, которые пришлось переделывать?!
— Да толком-то и не помню. О каком проекте речь? Вроде бы мне никаких правок не присылали.
— Юра, привет. Я хочу обсудить ситуацию на проекте «Ромашка»: вчера ты сдал макет без учета части вводных из задания. Давай обсудим, почему так произошло.
Сначала устраняю последствия, а потом разбираюсь в причинах. Если начался пожар, то нужно тушить пламя, а не выяснять, кто оставил зажженный бычок. Так и здесь: если команда не успевает сдать проект, то сначала надо решить проблему с горящими сроками. А уже потом спокойно разобраться, что именно произошло, и сделать выводы.
— Так, мы не успеваем сдать проект, заказчик в ярости. Я хочу знать, кто в этом виноват. Поэтому до конца дня у меня на почте должны быть объяснительные с отчетами о проделанной работе от каждого сотрудника.
— Кажется, мы не успеваем сдать проект, заказчик очень нервничает. На кону наша репутация и деньги. Потом мы обязательно обсудим, как так получилось и как этого не допустить в будущем, а сейчас нужно спасать положение. Через два часа планерка, прошу всех подготовить предложения, как решить проблему.
Сохраняю спокойствие. В любой спорной ситуации я стараюсь действовать без эмоций. Если положение серьезное, то люди уже и так сильно переживают — незачем их дополнительно накручивать. А если проблема пустяковая, то она просто не стоит нервов.
Любой проект — это клубок конфликтов, споров и проблем. Если руководитель будет реагировать чересчур эмоционально и агрессивно, то команда устанет от бесконечных истерик и перестанет воспринимать его всерьез.
Когда я только стала менеджером и вела свой первый проект, то так разозлилась на дизайнера, что послала его на три русских буквы. Уже через десять минут я поняла, как ужасно поступила, и побежала извиняться.
С дизайнером мы помирились и до сих пор дружим. Детали той ссоры давно забылись: мы даже не можем вспомнить, что меня взбесило и почему я так отреагировала. Осталось только воспоминание об этой некрасивой ситуации.
Думаю, что если бы тогда я не поняла свою ошибку и не извинилась, то у меня не было бы ни проекта, ни работы, ни друга.
Если и критикую, то осторожно. У большинства людей есть фильтр — он автоматически включается, когда приходится слушать то, что не хочется. Этот фильтр превращает гневные высказывания начальника в белый шум: работник вроде бы стоит с виноватым видом и даже кивает в такт словам, но по факту он вас не слышит. Проверено на себе в роли сотрудника.
Чтобы человек воспринимал мою критику, я стараюсь говорить не о том, какой он плохой, а о проблеме. Никогда не критикую специалистов в присутствии других членов команды. В такой ситуации человек думает не о решении проблемы, а о том, как не выглядеть слабаком в глазах коллег. Если и нужно высказать сотруднику что-то не очень приятное, то делаю это лично и без свидетелей.
Если же нас разделяет расстояние, то стараюсь критиковать только на созвоне — никаких мессенджеров и электронной почты. Причина простая: в письме не видны эмоции, поэтому я не понимаю, что чувствует человек и как он реагирует на мои слова. Ну а коллега может не разобраться, что имею в виду я, если не слышит мой голос и интонацию.
— Ваня, бесишь меня! Нельзя было, что ли, нормально сделать?
— Ваня, привет. Я хочу обсудить ситуацию на проекте «Ромашка»: у нас с тобой сорвались сроки. Давай обсудим? У тебя есть минут пятнадцать?
— Пойдем в переговорку тогда.
— Ваня, как ты знаешь, у нас был план проекта. Ты обещал сверстать две страницы до среды. Сегодня четверг, у нас нет ни одной страницы. Клиент немного в ужасе. Расскажи, что случилось? Почему не получилось?
Извлекаю пользу из ошибок. Любая проблемная ситуация — это урок для всей команды. После решения проблемы стоит подумать, как не допустить ее повторения. Например, изменить инструкции или рабочие процессы, пересмотреть подходы к планированию, постановке и контролю задач.
— Ваня, давай вместе разбираться, что именно не вышло. Боюсь, что если такое повторится — клиент от нас сбежит. Расскажи, с какими проблемами ты столкнулся, что непонятно? Покажи прямо на макете.
— Ну смотри, макеты какие-то кривые. Вот тут нет правильного шрифта и сетка странная.
— И правда. А чего ты сразу не спросил об этом меня или дизайнера?
— Думал, что разберусь, но не вышло.
— Ладно, поняла тебя. Давай так: сейчас я позову дизайнера, организуем созвон, обсудим твои вопросы. Потом перепланируем неделю, и я предупрежу клиента об изменении сроков. Договорились?
— Ну да, понял. Стеснялся просто.
Принимайте ответственность за все, что происходит на проекте
Есть простой принцип, которого я придерживаюсь. Он помогает не злиться на людей из-за ошибок и не винить высшие силы, когда все идет не по плану.
Звучит он так: менеджер отвечает за все, что происходит на проекте. Когда я это поняла и приняла, мне стало легче работать с командой, а команде — со мной. Если сотрудник не выполнил задачу или сдал результат с опозданием, отвечает менеджер. Если работа не устроила заказчика, то виноват не «криворукий дизайнер», а менеджер.
Если я уверена, что проблема не во мне, а в ком-то или чем-то еще, то решить ее сложно. Все же мое влияние на других людей и внешние факторы сильно ограничено. А вот если принять идею, что все сложности — на моей совести, тогда только я и могу со всем разобраться. Разумеется, бывают ситуации, когда виноват все же исполнитель, клиент или ретроградный Меркурий. Но разгребать-то все равно мне, поэтому первым делом надо понять, что конкретно я могу сделать для решения проблемы.
Покажу, как это работает. Специалист не выполнил задачу. Вызываю его на приватный разговор и спрашиваю: «А что пошло не так, почему не получилось?»
Опытный работник без труда найдет ответ, но начинающий специалист может и сам до конца не понимать, что пошло не так. Тогда нужно подбодрить и помочь уточняющими вопросами: «Может, не хватило материалов, знаний или ты чего-то не понял? Либо эта задача тебе неинтересна? Давай разберемся. Я хочу помочь тебе, чтобы такая проблема не повторилась».
В итоге работник даст какое-то объяснение. Менеджер должен внимательно выслушать и понять, в чем ошибка и как ее исправить.
Как перевести объяснения сотрудников на менеджерский язык
Почему сотрудник не выполнил задачу | Неправильный подход: виноваты все вокруг | Правильный подход: виноват менеджер | Что делать менеджеру |
---|---|---|---|
Думал, что нужно сделать что-то другое | Специалист тупой и не понял задачу | Я не объяснил задачу по-нормальному | Научиться ставить задачи и проверять, что они поняты |
Не получилось, думал, что разберусь, но не смог | Специалист ничего не умеет, понабирают тут всяких | Я поставил задачу не тому специалисту |
Я не предупредил специалиста, что нужно сообщать о проблемах и просить о помощи
Я не прописал четкий план с контрольными точками
Я не согласовал или не зафиксировал сроки проекта
Я как-то дал понять специалисту, что задача не очень важная, и этим его демотивировал
Поработать над постановкой задач в части договоренностей о сроках
Объяснить работникам, что о возможном опоздании нужно предупреждать как можно раньше — до дедлайна, а не после
Тщательней планировать работу, усилить промежуточный контроль над выполнением задач
Я поставил задачу не тому специалисту
Я не предупредил специалиста, что нужно сообщать о проблемах и просить о помощи
Разобраться с компетенциями своих коллег. Брать в команду тех, кто может решать поставленные задачи
Научиться правильно ставить задачи. Так, чтобы люди знали: в подобных ситуациях нужно не молчать, а бить в колокола и просить о помощи
Я не распланировал нагрузку
Я не прописал четкий план с контрольными точками
Я не согласовал или не зафиксировал сроки проекта
Я как-то дал понять специалисту, что задача не очень важная, и этим его демотивировал
Проанализировать причины опоздания
Поработать над постановкой задач в части договоренностей о сроках
Объяснить работникам, что о возможном опоздании нужно предупреждать как можно раньше — до дедлайна, а не после
Тщательней планировать работу, усилить промежуточный контроль над выполнением задач
Проводите ретроспективу проекта
По завершении проекта я стараюсь собрать команду и обсудить, что было хорошо, а что стоит улучшить. Кажется, что это не так важно, ведь в потоке задач нет времени оглядываться назад: новое будто бы в приоритете перед старым. Но это не совсем так: ретроспектива нужна, чтобы извлечь полезный опыт, который поможет эффективнее работать над следующими проектами. То есть мы оглядываемся в прошлое, чтобы стать лучше в будущем.
На ретроспективе можно узнать впечатления команды от работы и собрать идеи по улучшению процессов.
Например, недавно мы с внутренним заказчиком обсуждали прошедший проект. Заказчик пожаловался, что ему не хватало обратной связи: он не всегда понимал, на каком этапе находится проект и что именно происходит. Тогда мы договорились о новых правилах взаимодействия: с моей стороны — более четкое планирование и отчеты, а с его — более внятная постановка задач. Все договоренности зафиксировали письменно, придерживаемся их уже несколько месяцев — полет нормальный.