Под конец книги логично поговорить о том, как менеджер начинается. Путь от специалиста к менеджеру у каждого разный, но если достаточно долго наблюдать за разными путями, то можно увидеть много похожего. Давайте посмотрим на эти похожести вместе.
Менеджмент: начало
Неправильно относиться к понятию “менеджер” как к названию должности. В IT, в отличие от многих других областей человеческой деятельности, человек может не иметь никакой руководящей должности и даже категорически отказываться от позиции менеджера, но вполне себе заниматься руководством и фактически быть руководителем. Менеджер – это человек, который хочет и может управлять, а должность приходит гораздо позднее.
Давайте рассмотрим, как проявляется склонность к менеджменту у разработчиков. Пока разработчик просто сидит и пишет код, он проявляет только свои технические навыки. Но реальные проекты всегда подкидывают какие-то проблемы. Вот, например, прилетает на разработку новая задача и разработчик, читая требования, видит, что с требованиями беда: есть противоречия, есть не покрытые описанием ситуации, есть неконсистентность интерфейса между разными частями системы.
Любой опытный разработчик не сможет просто игнорировать такую проблему. Как минимум он скажет о проблеме менеджеру и спросит, что делать. Это обычный подход исполнителя и это нормально.
Но некоторые разработчики в такой ситуации делают больше. Они подойдут к тестировщику, назначенному на ту же задачу, и обсудят проблему с ним. Потом они вместе с тестировщиком пойдут к аналитику, вместе всё обговорят и придумают какое-то решение. К менеджеру уже они придут все вместе и не с проблемой, а с решением. А чтобы проблема не повторялась в будущем, разработчик может предложить ввести этап ревью требований командой.
Все эти дополнительные действия делаются с подачи такого инициативного разработчика. Фактически он частично выполняет менеджерские функции, организуя процесс разработки и активно участвуя в процессе принятия решений. Этот подход назовём “тимлидским”, так как такие шебутные разработчики становятся потом тимлидами, а чуть позднее – менеджерами.
Надо заметить, что “исполнительский” подход не хуже и не лучше “тимлидского”. Это скорее вопрос личных предпочтений человека. Конечно, компания тоже должна соответствовать этим предпочтениям. Разработчики, которые не хотят даже минимально лезть в менеджмент, выбирают компании, где процессы установлены, где роли строго распределены, и где накладки являются редкостью. В таких компаниях описанной проблемы с требованиями, скорее всего, не возникнет. А если она и возникнет, то от разработчика самодеятельности ждать не будут.
“Тимлиды” же нормально себя чувствуют в условиях лёгкого бардака и готовы менять процессы и меняться самим. Они оседают в стартапах и других проектах, где ценят их готовность обсуждать и решать проблемы там, где они обнаружились.
Чтобы проявлять такую активность, разработчик должен хорошо понимать процессы, которые уже есть в компании, знать, кто и за что отвечает, понимать, что ему самому нужно для работы. Поэтому чаще разработчик учится быть тимлидом, поработав хотя бы пару лет в компании. А вот после получения навыков тимлидства в какой-то одной компании, он может и в другой компании сразу начать работать на 100%.
Разработчик может не интересоваться изменением процессов, но ему может быть интересно что-то другое из арсенала менеджерских умений. Возможно, ему интересно общаться с заказчиком и разбираться в нуждах бизнеса. Тогда он и будет этим заниматься. Или он чутко реагирует, когда кто-то рядом расстроен, и умеет (или хочет научиться) это исправлять. Тогда он будет прокачивать свой эмоциональный интеллект.
Иногда считается, что такие “тимлиды” обладают меньшей производительностью, чем “исполнители”. Ведь в то время, как “исполнители” пишут код, “тимлиды” занимаются какой-то не относящийся к реальной работе деятельностью: собирают митинги, пишут письма, подготавливают документы для заказчика. На самом же деле “тимлиды” экономят команде и заказчику много времени. Они замечают проблемы на ранних этапах, когда их можно исправить относительно просто. А таких проблем в проектах обычно очень много.
Индустрия разработки программного обеспечения очень нуждается в тимлидах. Конечно, это показатель недостатка опытных менеджеров, причины которого мы уже рассматривали, но кроме того, это отличная возможность для разработчиков получить менеджерские навыки и оказать реальное влияния на проекты.
