Как управлять теми, кто управляет нами? Управление без полномочий для руководителей проектов и ИТ-директоров

Я управляющий партнер компании Wild PR – это маркетинг, PR, Digital. В прошлом, я айтишник – 14 лет занимался автоматизацией, был руководителем ИТ-отдела в компании «МегаФон-Ритейл». Но сегодня я буду говорить, в основном, про управление. Расскажу вам несколько менеджерских историй о том, как управлять без полномочий.

Проблемы, с которыми чаще всего сталкиваются ИТ-команды

Тренинги по управлению проектами я веду с 2008 года. Мы разбираем реальные истории и ситуации, когда что-то не получается, обсуждаем, как избежать проблем при взаимодействии с заказчиком, выясняем, как их можно решить.

На тренинги, в основном, приходят руководители проектов, ИТ-директоры, владельцы ИТ-компаний. Все эти люди – профессионалы в сфере ИТ, они работают с клиентами.

За 5 лет накопилось более 500 интересных кейсов – по автоматизации, по внедрению, по разработке ПО, по интеграции и по ИТ в целом. Эти кейсы касаются довольно больших проектов, стоимостью от 0,5 млн до 40 млн рублей. Есть еще очень много внепроектных кейсов по работе с людьми – при поддержке или при работе с внутренним заказчиком, работе с командой и т.д.

Все эти кейсы можно сгруппировать в условный ТОП-3 проблем, с которыми чаще сталкиваются ИТ-шники при управлении проектами.

Проблема № 1. Границы проекта

Номер 1, самая горячая тема – это проблема управления границами проекта.

На одном из крупных пилотных проектов по 1С, который мы делали для большой группы предприятий, примерно через полгода после старта выяснилось, что заказчик забыл нам сказать, что ему нужна подсистема бюджетирования. И, когда мы уже почти все реализовали, попросил сделать ее по-быстрому, без выделения бюджета. А когда команда попыталась договориться с ним об увеличении сроков и стоимости проекта, сославшись на большой объем работы и отсутствие такого пункта в ТЗ, заказчик возмутился и даже потребовал закрыть проект. Получалось, что нас заставляют делать бесплатно большой объем работы, да еще и в короткий срок.

Мы начали с заказчиком обсуждать, почему ему вдруг срочно потребовалась система бюджетирования, и оказалось, что она нужна была управляющей компании, которая спонсировала весь проект. А поскольку эту подсистему по какой-то причине забыли включить в ТЗ, то фактический заказчик не хотел быть наказанным за ее отсутствие.

Тогда мы договорились, что вместе обратимся в управляющую компанию и объясним, что произошло, чтобы никого не наказывали. В управляющей компании провели экспертизу и согласились, что налаживание процессов бюджетирования – процесс трудоемкий, за пару дней справиться невозможно.

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

Конечно, в большинстве случаев заказчики не так категоричны и не пытаются шантажировать исполнителей. Обычно они действуют мягче, просят что-то добавить, дополнить, после чего, бывает, проект увеличивается в 1,5-2 раза.

Почему вообще возникает проблема управления границами проекта? Казалось бы, имеются инструментальные средства, можно вести учет дополнительных требований. Но дело в том, что заказчик часто не понимает, насколько его проект может быть сложным, сколько он может стоить, как все происходит в реальности. Это понимание приходит только в процессе.

Проблема № 2. Конфликт интересов

Во вторую группу следует отнести проблему конфликта интересов.

Расскажу реальный кейс внедрения системы управленческого учета в производственной компании, где трудится 500 человек.

Там генеральному директору, чтобы быстро принимать решения, было нужно, чтобы все цифры по компании к нему приходили не через месяц, как это сейчас делает бухгалтерия, а намного быстрее – например, в течение 3 дней. Он был очень заинтересован в автоматизации, быстро подписал все бумаги, дал проекту «зеленый свет».

Но когда ИТ-шники пришли внедрять систему в бухгалтерию, оказалось, что там и не собираются никуда переходить. Они не саботировали проект, но и не помогали, и целых три месяца просто «динамили» по всем вопросам, от которых зависело дальнейшее внедрение системы.

Когда у ИТ-шников лопнуло терпение, они пришли к директору и объяснили, что процесс внедрения тормозится из-за бухгалтерии. Директор вызвал бухгалтера, спросил, почему такое отношение, и получил ответ, что из-за нового проекта компания не сможет сдать отчеты – а это штрафы, деньги, проблемы. В общем, директор сдался, а программистам пришлось терпеть отношение бухгалтера – проект постепенно с большим трудом закончили.

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

Проблема № 3. Изменения чужими руками

Третья группа ситуаций связана с тем, что за счет программистов пытаются провести какие-то организационные изменения, пытаются заставить их заниматься управленческим консалтингом.

Конкретный кейс по этой проблеме – крупная госкомпания хотела собрать все данные из зарплатных программ по всем своим подразделениям в одной базе.

Изначально программисты решили, что этот проект – чисто технический, и попросили доступ к базам по регионам, чтобы их проанализировать. Но оказалось, что у заказчика вообще не было доступа к этим базам, и эта централизация нужна именно для того, чтобы получить контроль над подразделениями. И для этого он позвал ИТ-шников, которые, как «люди из Москвы», разрулили бы всю ситуацию в качестве «команды захвата».

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

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

Сопутствующие проблемы

Получается такая история:

• С одной стороны у ИТ есть формальные полномочия, но с другой – есть рабочая группа, которая должна участвовать в проекте, но эти люди не подчиняются руководителю проекта и не заинтересованы в его результате, поэтому могут в любой момент отказаться сотрудничать. Фактически, часто руководитель ИТ-команды оказывается в ситуации, когда надо управлять людьми, для управления которыми у него нет полномочий.
• Кроме того, часто приходится управлять теми, кто платит деньги – внешним либо внутренним заказчиком, который при этом может быть неправ. Например, его идею невозможно технически претворить в жизнь, это не будет работать, но человек убежден, и получается, что нужно переубедить того, кто главнее.
• И последний момент: хотя айтишники отвечают чисто за техническую сторону проекта, в итоге на них навешивают многие организационные проблемы, которые выходят сильно за рамки ИТ. И доказать это порой бывает невозможно, потому что никто уже не разбирается, где чьи границы. Чаще всего, все считают, что в проекте автоматизации главные – айтишники, они разберутся. Причем, эта ситуация возникает не только с 1С, это тенденция на всех рынках, связанных с высокими технологиями. Подразделение ИТ, несмотря на то, что оно сервисное, фактически является центральным звеном в компании – ИТ-шникам приходится все разруливать и со всеми договариваться.

Как управлять, если нет полномочий?

И каждый раз возникает вопрос – как с этим жить, как управлять без полномочий?

Ответ простой, но технически сложный. Чтобы этого добиться, необходимо освоить комплексный коммуникационный навык влияния без полномочий.

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

Что такое ведущий мотив? Например, сейчас вы читаете этот материал, и можно предположить, что вам интересно. Возможно, кому-то это действительно интересно, а кто-то читает, просто чтобы убедиться, что обо всем этом и так уже знает – тогда мотив связан исключительно с подтверждением экспертности.

Все эти мотивы представляют собой реальность. И когда появляется умение и навык опираться на эти мотивы, на эту реальность, управлять становится намного легче.

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

Например, в чем проблема оценки проектов? В том, что у нас есть ожидания, но когда мы начинаем внедрять, оказывается, что в команде заказчика есть люди, которым проект не важен. Получается, что ожидания рухнули, пошла разница в оценке. А когда вы на автомате учитываете мотивы и заказчика, и его подчиненных – оценки становятся точнее, потому что вы опираетесь на реальность. И, например, если вы видите незаинтересованность со стороны клиента, то вы можете построить соответствующий прогноз, и дальнейшее развитие событий уже не будет для вас сюрпризом.

Как научиться понимать мотивы и поведение людей?

Навык понимания поведения людей можно натренировать на любом тренинге по продажам, по переговорам, по лидерству – там, где есть работа с мотивами людей. Единственная сложность – чтобы такой навык выработать, нужно примерно полгода.

Базовые подходы при обучении такие:

• Типологический подход – это как «типы данных» в программировании. Грубо говоря, люди делятся на типы – есть много шкал. Например:
  • DISC – 4 шкалы;
  • MBTI – 16 шкал;
  • КСЗ – 3 шкалы, деление людей на «красных», «синих» и «зеленых». За 2-3 недели можно научиться отличать «красного» от «синего». Проблема только в том, что это почти никогда однозначно не попадает. Человек может быть «красный», чуть-чуть «синий», а в конкретный момент ведет себя как «зеленый» – типы могут меняться динамически;

Есть еще НЛП, соционика, транзактный анализ. Это не типы, а поведение, не транзакции, а скрипты. Эти знания дают понимание, почему человек ведет себя в конкретный момент именно так, а не иначе. Но здесь есть такая же проблема, как с языком программирования: ты его учишь-учишь, учишь-учишь, начал что-то понимать, в чем-то разбираться, а потом все равно приходишь к тому, что тебя эта парадигма ограничивает – например, в НЛП все равно не все укладывается.

Самое хорошее, что я нашел, это – «чтение» мотивов, понимание, кому и что нужно. Оно позволяет воспринимать поступки людей без однозначных оценок по типам, при этом восприятие идет в два потока.

Мы оцениваем ситуацию, в которой человек говорит, и пытаемся понять, зачем он это говорит.

Имея навык понимания поведения людей, управлять становится намного легче.

Я заметил, что этот навык автоматически, естественным образом формируется у всех, кто работает в активных продажах, за 3-5 лет. Также он есть у руководителей высшего звена, тех, кто постоянно решает какие-то вопросы, участвует в переговорах, а не сидит в кабинете. Естественно, он имеется у психологов, тренеров, коучей, потому что этому их просто учат. 

Это – то же самое, что научиться водить машину, на это нужно время.

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

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

Реальный пример, когда «чтение» мотивов было выгодно всем

Расскажу небольшой кейс о том, как может пригодиться понимание мотивов и поведения людей на практике.

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

А когда проект почти закончили, из управляющей компании прислали ИТ-директора, который, посмотрев на первоначальный договор, начал требовать реализовать отчет. Ему объяснили, что была письменная договоренность, что отчет поменяли на доработки валютного учета – все можно подтвердить и т.д. На что ИТ-директор сказал, что деньги без отчета он заплатить не сможет.

Команда обратилась за поддержкой к финансовому менеджеру, чтобы он подтвердил договоренность, но тот отказался помочь.

Когда начали анализировать мотивы, разбираться, почему ни новый ИТ-директор, ни финансовый менеджер не хотят идти на уступки, выяснили следующее:

• ИТ-директору нужен был отчет, потому что именно ради него этот проект был нужен руководству управляющей компании. ИТ-директору в этой ситуации было важно проявить себя героем – его прислали из Москвы, чтобы он навел порядок, он не мог вернуться, пока не совершит какой-то «подвиг». И получалось, что этот «подвиг» он собирался совершить за наш счет.
• что касается финансового менеджера, то ему просто не хотелось терять свое место, потому что скоро пенсия. Тут мотив – быть в безопасности, не потерять работу.

Что было решено сделать? Было решено: первое – обеспечить финансовому менеджеру безопасность, второе – сделать ИТ-директора героем.

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

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

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

Как видите, когда навык понимания поведения людей есть, это упрощает работу.

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.