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

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

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

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

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

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

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

История про менеджмент не в IT

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

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

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

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

Вывод 1: Менеджеру не нужны ни должность, ни дополнительная зарплата, ни даже особые ресурсы. Менеджер делает свою работу, потому что она ему нравится.

Чего удалось добиться Ане? За несколько лет кружок вырос в 10(!) раз. Далеко не все желающие могли поступить на обучение, появился конкурс. Аня помогала привлечь хороших преподавателей и перспективных учеников. Конкурентов у этого кружка в городе не осталось. Из явных аутсайдеров кружок стал абсолютным лидером. Коммерческий успех был несомненным.

Вывод 2: Всего один человек может изменить очень многое и привести компанию к успеху, просто если ему не мешать.

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

Что это прежнее руководство начало делать в первую очередь? Сокращать количество учащихся. Причём они не просто повысили сумму за обучение, чтобы сохранить прибыль. Они стали делать условия оплаты более трудными для родителей, объявляли непонятные условия обучения, делали хуже условия для преподавателей. Устно обоснование было простым: “У нас очередь на обучение, так что если кто-то не хочет у нас учиться, то только лучше станет”.

Мне казалось, что руководство просто проф.непригодно. Так планомерно разрушать созданное другими могут только ужасно недальновидные люди, ведь так? Но когда я поузнавал получше, выяснилось, что зарплата у руководства не зависит от числа учащихся и от величины прибыли. То есть обучать 300 человек им нисколько не выгодней, чем обучать 30. Но ведь работы объективно больше!

То есть это с моей точки зрения Аня делала хорошее дело, позволяя большому числу детей получить дополнительное образование. А с точки зрения аниного руководства она скорее создавала лишнюю работу.

Вывод 3: Если вам действия какого-то менеджера кажутся ошибочными, то возможно, он просто руководствуется совсем другими целями, принципами и мотивами. Он может быть очень эффективным, просто не в том, что вам кажется важным.

Ну и общий вывод: Менеджеру нужно найти такое место работы, где то, что он делает, будут ценить и поддерживать. Только так можно быть уверенным, что результаты вашей работы будут сохранены.

Первое задание менеджера

Хотя менеджер – это скорее состояние души, чем роль или, тем более, должность, но формальное присвоение должности “менеджер” всё-таки важно. Официально признанный менеджер имеет доступ к дополнительным ресурсам. Очень часто бывает так, что разработчик очень быстро вырастает до тимлида и проявляет задатки будущего менеджера проектов, и сам он не против стать менеджером, но всё как-то не срастается. Так вот первое задание такого начинающего менеджера – это добиться менеджерской позиции!