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