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