Константин Борисов - Как хорошему разработчику не стать плохим менеджером

Любой опытный разработчик не сможет просто игнорировать такую проблему. Как минимум он скажет о проблеме менеджеру и спросит, что делать. Это обычный подход исполнителя и это нормально.

Но некоторые разработчики в такой ситуации делают больше. Они подойдут к тестировщику, назначенному на ту же задачу, и обсудят проблему с ним. Потом они вместе с тестировщиком пойдут к аналитику, вместе всё обговорят и придумают какое-то решение. К менеджеру уже они придут все вместе и не с проблемой, а с решением. А чтобы проблема не повторялась в будущем, разработчик может предложить ввести этап ревью требований командой.

Все эти дополнительные действия делаются с подачи такого инициативного разработчика. Фактически он частично выполняет менеджерские функции, организуя процесс разработки и активно участвуя в процессе принятия решений. Этот подход назовём “тимлидским”, так как такие шебутные разработчики становятся потом тимлидами, а чуть позднее – менеджерами.

Надо заметить, что “исполнительский” подход не хуже и не лучше “тимлидского”. Это скорее вопрос личных предпочтений человека. Конечно, компания тоже должна соответствовать этим предпочтениям. Разработчики, которые не хотят даже минимально лезть в менеджмент, выбирают компании, где процессы установлены, где роли строго распределены, и где накладки являются редкостью. В таких компаниях описанной проблемы с требованиями, скорее всего, не возникнет. А если она и возникнет, то от разработчика самодеятельности ждать не будут.

“Тимлиды” же нормально себя чувствуют в условиях лёгкого бардака и готовы менять процессы и меняться самим. Они оседают в стартапах и других проектах, где ценят их готовность обсуждать и решать проблемы там, где они обнаружились.

Чтобы проявлять такую активность, разработчик должен хорошо понимать процессы, которые уже есть в компании, знать, кто и за что отвечает, понимать, что ему самому нужно для работы. Поэтому чаще разработчик учится быть тимлидом, поработав хотя бы пару лет в компании. А вот после получения навыков тимлидства в какой-то одной компании, он может и в другой компании сразу начать работать на 100%.

Разработчик может не интересоваться изменением процессов, но ему может быть интересно что-то другое из арсенала менеджерских умений. Возможно, ему интересно общаться с заказчиком и разбираться в нуждах бизнеса. Тогда он и будет этим заниматься. Или он чутко реагирует, когда кто-то рядом расстроен, и умеет (или хочет научиться) это исправлять. Тогда он будет прокачивать свой эмоциональный интеллект.

Иногда считается, что такие “тимлиды” обладают меньшей производительностью, чем “исполнители”. Ведь в то время, как “исполнители” пишут код, “тимлиды” занимаются какой-то не относящийся к реальной работе деятельностью: собирают митинги, пишут письма, подготавливают документы для заказчика. На самом же деле “тимлиды” экономят команде и заказчику много времени. Они замечают проблемы на ранних этапах, когда их можно исправить относительно просто. А таких проблем в проектах обычно очень много.

Индустрия разработки программного обеспечения очень нуждается в тимлидах. Конечно, это показатель недостатка опытных менеджеров, причины которого мы уже рассматривали, но кроме того, это отличная возможность для разработчиков получить менеджерские навыки и оказать реальное влияния на проекты.

Мне очень нравится смотреть на то, что происходит не в IT. Некоторые проблемы там выглядят совсем по-другому и решаются оригинально. Очень полезно перенимать такой опыт. Я хочу поделиться одним примером моих наблюдений.

Я много лет слежу за развитием одного математического кружка. Этот кружок полностью коммерческий, то есть родители оплачивают обучение детей там, но он государственный, дочерний для крупного ВУЗа.

Несколько лет назад он был совсем небольшим, пока там не появилась молодой преподаватель, Аня. Аня с душой подошла к делу. Она узнала, как работают конкуренты, она продумала позиционирование кружка на рынке, она общалась с родителями, узнавая что им нравится, а что нет.

Никакой специальной должности Аня не имела, она была просто преподавателем. Но ей удалось убедить руководство кружка, что нужно вложиться в маркетинг. Бюджета на рекламу всё равно не было, но Ане разрешили рекламировать кружок, как она считает нужным. Этого согласия оказалось достаточно. Аня нашла возможность привлечь студентов из шефствующего ВУЗа, уговорила знакомых помочь ей с разработкой материалов, сама проводила многочисленные мероприятия, разработала сайт, развила деятельность в соцсетях. Фактически она выполняла менеджерские функции, хотя формально она была рядовым преподавателем. Она определяла лицо кружка и руководила маркетинговой работой.