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