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