Непрямое управление чужой командой, которая должна работать с вашей
Нас часто зовут внедрить железо, смигрировать систему, построить резервный ЦОД или сделать что-то ещё, что компания не хочет или не может делать сама своими силами по разным причинам. Теперь представьте эмоции людей в банке, которые 15 лет работали на своей системе, установленной на физическом сервере, и тут появляются люди, которые просят их дать время на даунтайм и согласовать план работ для остановки системы и вообще дать возможность миграции в какое-то там облако в какой-то там контейнер.
Эмоции могут быть любыми: от желания отмахнуться, откровенного страха (за себя, за систему или из-за непонимания), нелюбви или восприятия нас как помехи (потому что горят другие задачи).
В этот момент начинается управление командами заказчика. Не в том плане, что мы приходим и говорим им, что делать, а в том плане, что можно сделать какие-то вещи заранее и тогда процесс пойдёт легче и безболезненнее. А можно не делать, и тогда всем будет плохо.
Вот это и называется управлением чужой командой — когда вы со своей стороны делаете всё, чтобы они шли вам навстречу.
В обычной практике это тоже нужно, потому что вам даже в продуктовой команде всё равно надо хоть немного, но управлять инфраструктурой или своим руководителем подразделения. Но у нас это вообще принцип выживания. На недавнем проекте мы переносили несколько сотен систем и, соответственно, общались с несколькими десятками команд заказчика.
Что такое непрямое управление чужой командой
Грубо говоря, это достаточно простой цикл действий в теории:
- Своевременное информирование. Хорошо, когда все понимают, что происходит, когда можно ответить на любой вопрос, когда каждый знает, что от него ждут. Предсказуемость и совпадение ожиданий — это то, что все любят. Когда все всё понимают одинаково, проект почти всегда будет успешным. Соответственно, вам нужно создать такую среду, где информация всегда есть в достаточном количестве и просто доносится до всех заинтересованных.
- Предвидение следующих шагов. По мере реализации проекта часто будут нужны вещи, которые нужно делать долго. Некоторые из них лучше начать сейчас. О некоторых лучше предупредить людей заранее. Где-то надо договориться с соседним подразделением — и тоже хорошо бы делать это не в день, когда люди оттуда будут нужны. Можно сказать, это правильное планирование.
- Тактическая помощь. Всегда нужно уметь пойти навстречу команде заказчика и сделать что-то, что может им облегчить задачу, которую вы от них хотите. Это не «делать всё за них», а именно облегчить. Например, если вы хотите от них получить документ с требованиями, можно показать образцы таких требований, дать советы по практике, что туда лучше включить, посоветовать кого-то, с кем это можно проговорить, дать опросники, которые надо просто заполнить, и так далее. Или, например, если вы работаете с нетехническим подразделением, помочь им что-то сделать, не дожидаясь, пока они будут безуспешно пытаться сделать это своими силами.
- Эскалация. Если всё плохо и вам откровенно не хотят помогать — вовремя распознать ситуацию и сообщить об этом выше (в посте будут примеры). То есть не пытаться стегать дохлую лошадь и тратить ресурсы на работу с незамотивированными людьми, которые вообще не видят смысла в сотрудничестве с вами, а привнести этот смысл (обычно в форме того, что приходит их руководитель и что-то меняет) и затем пробовать выстроить отношения ещё раз.
Теперь давайте посмотрим на критические моменты проекта в плане того, что нужно делать, чтобы у вас всё сложилось.
Старт проекта
Самая частая ошибка начинающего проект-менеджера — это ничего не делать на старте. Лет десять назад я на эти грабли тоже наступал. Очень легко внутренне сказать себе: «Я не буду пока этим заниматься», но очень тяжело потом разрешать последствия.
Старт проекта — самое важное время, чтобы объяснить всё и всем и начать хотя бы контролировать происходящее.
На стадии знакомства в нашей практике обычно начинается с некоторого недоверия. Мы новые люди, мы не из компании, мы что-то хотим поменять. Обычно нам доверяет какой-то из верхнеуровневых руководителей со стороны заказчика, но не руководитель команды, с которой нужно работать. Его доверие нужно заслужить. Команда со стороны заказчика нас не знает, не уверена в наших компетенциях и просто не хочет, чтобы их беспокоили какие-то ненужные им люди. Конечно, не всегда так бывает, но исходить стоит из того, что это базовый сценарий.
В этот момент нужно постараться снять все эти барьеры. И чем эффективнее вы это сделаете, тем легче дальше пойдёт проект. Надо показать себя, свою компетентность, компетентность своей команды, показать, откуда вырос этот проект, зачем он нужен, рассказать и показать план проекта. Всё это желательно на очной встрече. То есть мысль в том, что мы не «непонятная организация со стороны», а эксперты в своём деле и уверенно знаем, куда идём. Итог — важны коммуникация и взаимодействие (не просто письменное и официальное, но и неформальное).
На том проекте, где мы мигрировали системы, заказчик наши встречи видел так: здрасьте, мы пришли из ниоткуда, планируем потормошить вашу систему и унести в другое место. Команды не понимали, кто мы, зачем пришли. Более того, некоторые получали отказы систем при прошлых миграциях и не хотели этого больше никогда.
На установочных встречах мы знакомились, потом объясняли задачу как таковую (зачем это всё делается, почему это важно), очень подробно рассказывали про ход проекта и все шаги, объясняли каждый этап. Показывали, кто в нашей команде и какой у него опыт в таких проектах. Затем объясняли, что нужно от команды заказчика на каком этапе, на что это влияет. Обычно если это проговорить не за пять минут, а очень подробно и понятно всем, этого хватает. Часто очень важно второй команде понять две базовые вещи:
- Что проект действительно нужный (для этого обычно есть какая-то стратегия со стороны руководства этой команды, по которой мы работаем).
- Что мы люди с опытом и понимаем, что делаем. И из всех возможных вариантов наш наиболее продуманный и доставит меньше всего проблем команде.
Есть плохой вариант — когда команда покивает, скажет: «Да-да-да, очень важная задача, обращайтесь» и уйдёт в закат. Дальше нужно получить от них что-то —, а они не будут отвечать на письма и звонки, не представят никакой информации и просто отморозятся от проекта.
Это может случиться по трём основным причинам:
- Команда слишком занята своими задачами и не считает ваши задачи важными. В этой ситуации обычно достаточно объяснить приоритизацию — с этим справляется руководитель чужой команды, как только понимает, в чём дело. Нужно это мягко до него донести. Я обычно обращаюсь к аккаунт-менеджеру, он в курилке ловит этого руководителя, говорит про проблемы. Если курилка не помогла, то уже эскалируется до его руководителя. Но мы никогда не эскалируем высоко сразу, потому что потом с обиженным руководителем ещё работать целый проект. Лучше постараться максимально полюбовно, без руководящего пенделя.
- Вас не воспринимают всерьёз. Просто вы не убедили, что вы не клоуны, а интегратор. Особенно часто такое случается на производствах, где отношение ко всем тем, кто не стоял в цеху, презрительное. Решение практически аналогичное, но лучше всё же проработать старт и знакомство так, чтобы вас как минимум воспринимали как партнёров, а не помеху.
- По каким-то политическим внутрикорпоративным причинам ваш проект хотят слить. Это может быть что угодно, и не всегда вы узнаете причину — например, один руководитель женился на бывшей девушке другого, а пострадает ваш проект. С этим по большому счёту ничего, кроме эскалации, сделать нельзя.
Есть ещё варианты, смеси вариантов и так далее, но базовые сценарии примерно такие.
Хуже всего на этой стадии не вникать в задачи проектной команды заказчика и не понимать, что их беспокоит и почему. Если пропускать всё мимо ушей, будет плохо вам.
Неполное сотрудничество в середине проекта
В ходе проекта может возникнуть похожая ситуация: вы пишете письмо, а оно уходит в тину. Например, вам надо что-то согласовать даже не с самой проектной командой заказчика, а с их бухгалтерией. Или получить доступ на объект, где руководит другая команда.
Причины те же: либо вам не доверяют, либо не понимают, что и зачем вы хотите.
Лечение похожее: нужно собирать встречи (очные или в конференц-связи) и всё разжёвывать (работа над расположением к себе, как на старте).
Если команда действительно под высокой нагрузкой, дёргать их не надо, надо попросить реальный срок. Пускай он будет дольше желаемого, но обязательно реалистичный. Не сработало — приходите ещё раз, фиксируете новый срок и выясняете, в чём проблема, чтобы решать её уже предметно.
Когда вы в ходе проекта сталкиваетесь с проблемой, возможна ещё одна причина остановки: команда всё понимает, готова помочь, но не знает как.
То есть буквально не знает, как такое делается. Это может быть недостаточная компетентность с технической точки зрения. Это может быть незнание каких-то процессов внутри компании и так далее.
Пример. Порядок работ следующий: мы собираем исходные данные, проектируем решение, пишем документацию, передаём всё это на согласование заказчику, заказчик по согласованной документации выполняет подготовку к миграции или саму миграцию.
Проблемы возникли, когда мы всё собрали, спроектировали, выдали и согласовали документы. Это были предсказуемые части процесса. А дальше выяснилось, что команды-исполнители на стороне заказчика не знали внутренние процессы. На старте они не знали, что нужно будет взаимодействовать с ИБ, инфраструктурщиками, админами, другими командами. Каждая система тянула за собой шлейф зависимостей, и некоторые команды просто не знали, как с этим быть. В этой ситуации мы могли ждать, пока они разберутся сами, а могли разобраться, как какая задача решается, — и провести исполнителей за руку оптимальным путём. Мы узнали, какой департамент какую часть задач делает, как правильно писать заявки в каждый, кто за что отвечает по фамилиям, — и сделали набор стандартных форм для проекта. Исполнители просто заполняли эти формы и действовали по пошаговым гайдам, которые мы тоже написали. Потратили на это несколько дней, но зато это окупилось просто огромной экономией в масштабах всего проекта.
Это частая история на многих внедрениях. На одном проекте было, что заказчик не понимал, как согласовать документы, которые мы спроектируем, — хотя бы кто за что отвечает. Не было и понимания схемы. Мы об этом узнали, зафиксировали всё, задокументировали и использовали в сводном файле. Понятно, что это процесс заказчика и управлять им тяжело. Но мы были первые, кто его задокументировал, и это внесло понимание и предсказуемость.
В целом для того, чтобы ничего не забыть и понимать, часто нужно систематизировать работу команд со стороны заказчика. Это может быть построение сводных таблиц, отметки статусов за них, еженедельный контроль исполнителей на стороне заказчика письмами и звонками и так далее.
Лучшее лекарство на стадии, когда команда тормозит, — спросить, есть ли что-то, чем мы можем помочь. Чаще всего есть, дальше вопрос стоимости этой помощи в проекте: что проще — сделать дополнительную работу или подождать и рисковать сроками и качеством.
Конфликт в середине проекта
Такое случается из-за политического бойкота проекта, из-за того, что кто-то уходит и просто не хочет делать свою работу (зачем ему новый проект перед увольнением?), и по другим причинам. В такой ситуации причинами вы управлять не можете, но можете эскалировать ситуацию.
Чем реально нужно управлять, чтобы конфликта не было, так это информированностью. Очень частая причина конфликтов — это когда одна сторона думала, что мы сделаем это одним образом, а мы хотели другим. И в тот момент, когда становится понятно, что сейчас всё пойдёт не по их представлениям, начинаются проблемы на проекте.
Для этого нужно показывать все этапы работ и что на них будет происходить заранее, а не преподносить их сюрпризами. Для этого нужно обсуждать каждый этап подробно и проговаривать, кто и что делает. После каждой встречи надо фиксировать все договорённости и убеждаться, что их читают — чтобы ничего не оставалось в устных беседах, обязательно нужны артефакты, к которым можно вернуться и посмотреть, кто же и что имел в виду. Обязательно уточнять термины, формулировки и понимать, что такое «сделайте хорошо» или «нормально подготовим, не волнуйтесь».
Очень важно, например, заранее проговорить согласования всех документов: сколько человек будут их смотреть, кто эти люди, сколько итераций максимум, сколько времени на каждую итерацию. У меня был когда-то давно проект, где я упустил этот момент из фокуса внимания. На стороне заказчика пришёл новый ИТ-руководитель, он отвечал за часть работ на проекте. Мы с ним встретились, пообщались, узнали друг друга, я понял, что он профи в своём деле. Решил так, что контролировать процесс его действий на проекте я не буду. Мне не было важно, как он сделает, главное — что будет результат к оговоренному сроку, и он его обещал. В итоге он решил поменять схемы взаимодействия внутри с исполнителем, сам придумал новую схему согласования, поменял планы контроля всех процессов — и наш проект поплыл, сроки сдвинулись.
На начальном уровне много таких случаев, когда вы вынуждены кому-то доверять, потому что ничего не делаете как менеджер. Вы боитесь, что не знаете чего-то, считаете, что вас неправильно поймут, увидят не с профессиональной точки зрения и решат, что вы какой-то залётный дурачок. Это эмоции. Либо вы учитесь корректно и вежливо вносить ясность и контролировать происходящее, либо получаете проблемы на весь проект.
Общее про проектное управление
Один из моих бывших руководителей получил очень ценный жизненный урок, когда заказчик посреди проекта попросил его заменить и не сказал, почему именно. Коллега месяцами шаг за шагом переживал каждый момент проекта и пытался понять, где и что он сделал не так. И на него это очень сильно подействовало. Сделал внутренную работу над ошибками. Уже на следующем проекте он был намного более спокоен, сфокусирован и профессионален. Насколько я знаю, провальных проектов после этого у него не было ни одного.
Кстати, провальные проекты важны. Если вы никогда не видели, как это изнутри, и не корили себя потом, это рождает чувство ложной уверенности, что всё будет хорошо. Поэтому из двух проект-менеджеров с опытом обычно выбирают такого, кто уже проваливался с чем-то подобным. Это повышает шансы на успех.
Очень важно завоевать доверие заказчика. Оно обычно достигается из того, что вы не творите дичь, знаете ответы на все вопросы, понимаете, что, где, когда и кто будет делать, плюс заранее думаете, как облегчить тот или иной этап работ. Очень хорошо, когда вы подумали о чём-то, о чём команда заказчика не думала, например заранее сняли какой-то риск.
Потерять доверие заказчика можно очень просто — достаточно вести себя непрофессионально. Последние два примера. Мой бывший коллега джун на первой же встрече переходил на «ты» и рассказывал какие-то неуместные вещи из личной жизни. На часть команд это работало нормально, а часть бесило. Люди на другой стороне разные бывают. И пример, когда менеджер не прочитал типовой, казалось бы, договор. Представьте, взаимодействуете вы с заказчиком, вся информация есть, всё протоколируете — в общем, работа идёт правильно. А потом вам звонит заказчик и говорит: здрасьте, 15 сентября, а где акты и комплект документов, который вы должны дать сегодня? А оказывается, это не совсем типовой договор, проект поделён на этапы и в конце этапов надо сдавать документы. И ладно бы вы просто потеряли время, но вы теряете на этом очень много доверия заказчика.
Ещё часто бывает нужно узнавать вещи про руководителей и исполнителей чужих команд. Кто-то обидчив. Кому-то нельзя напоминать про аналогичный проект внедрения, потому что именно он его провалил. Кто-то не любит утренние или вечерние встречи и старается их быстрее закончить. Кто-то любит очень долго обсуждать каждую задачу — и вместо 15 минут лучше закладывать час, а не обрывать рассуждения. Это тоже важно.
Косвенно управлять чужой командой можно, и это почти всегда приходится делать. В каких-то проектах реже, в каких-то — почти постоянно. Основа такого управления — всё то же самое, что в обычной проектной работе, плюс много коммуникаций с каждым, кто недоинформирован. Ничего сверхсложного нет, и применять всё это можно хоть сейчас. Но очень многие вещи в конкретной имплементации приходят с опытом.
