Первая статья про то, почему плохи деньги, вызвала некоторый резонанс. Мне даже наприсылали гневных писем, где объясняют, что сколько программистам (и менеджерам, хе-хе) условий ни улучшай, они все равно в сторону денег смотрят.
Эти разговоры меня давно не удивляют. Я их часто слышу на встречах с владельцами своих компаний. Причем у людей часто совершенно космическая текучка, но они продолжают уповать на деньги как на единственное средство спасения.
Ну хорошо, сегодня мы поговорим про условия работы и почему тратить деньги на них выгодно. С деньгами есть ровно две проблемы.
Проблема №1. К повышению зарплаты люди привыкают. Очень быстро. В моей карьере резкие (>=2 раза) повышения случались трижды, поэтому я знаю о чем говорю. Первый месяц присутствует редкое воодушевление, что блин, какой же я крутой. А потом как-то привыкаешь: ну да, я крутой, поэтому и повысили.
Проблема №2. Повышения случаются редко. Обычно зарплата повышается раз в год, в результате воодушевление человека от денег присутствует максимум один месяц в году. Нельзя повышать зарплату каждый месяц – бюджет не выдержит. Либо повышать придется на 1% каждый раз, что тоже люди не любят.
Теперь посмотрим на условия работы. Улучшения условий можно условно поделить на две группы:
Предположим теперь, что из изначальных $136,000, которые наш ген. директор Сергей Васильевич решил потратить на сотрудников, скажем, 20% он решит потратить на улучшение условий. Заметим, что это довольно большие деньги ($27,000). На эти деньги реально можно, например:
Не будем говорить. что улучшение условий повышает производительность. Просто в силу того, что некоторые вещи перестают людям мешать. Ну, или же мешают меньше.
Но главное. Все эти улучшения можно делать не раз в год, а на протяжении года. Каждый шаг показывает людям, что о них заботятся. В них здесь заинтересованы. Таким образом, изменение условий работы с точки зрения мотивации может иметь гораздо более длительный эффект нежели раздача денег.
Продолжаем цикл статей про то, как стать менеджером. Первая статья – здесь.
Есть такая модель про развитие карьеры – TOP = Talent + Organization + Passion. Ну то есть, когда карьера развивается? Когда есть:
В первой статье мы говорили про Passion – почему хочется быть менеджером, и почему не хочется им быть. Теперь немного поговорим про Talent.
Собственно, Passion и Talent – две основополагающие вещи. Потому что потребность в новых менеджерах обычно случается внезапно. Компания решила расшириться. Или ваш начальник ушел на повышение. Или в соседней компании внезапно потребовались менеджеры.
В подавляющем большинстве случаев на открывшуюся позицию назначают того, кто лучше к ней готов. Поэтому пока открытых позиций нет, как раз самое время заняться Talent’ом.
Talent – это в данном случае не совсем талант. Скорее, это набор менеджерских навыков, таких как:
Поэтому на вопрос “с чего начать?” ответ будет такой:
Без последнего пункта все предыдущие бесполезны, ага. Удач!
I hire people brighter than me and then I get out of their way
В последнее время замечаю, что вокруг много людей пытаются поймать вдохновение. Выглядит это так.
- Петь, ну как послал в контору АБЦ свое резюме?
- Сань, да пока нет. Его там обновить надо. Вот на меня вдохновение накатит и сделаю.
При этом Петя продолжает страдать на текущем месте работы.
Или:
- Серега, ну как посмотрел семинар по public speaking?
- Сань, не, все никак не соберусь.
При этом у Сергея полная %опа с навыками публичных выступлений, и он продолжает мучить ими своих коллег и заказчиков. Ну а пока ждет вдохновения, чтобы посмотреть семинар.
И много таких примеров. Прямо эпидемия какая-то.
Коллеги, с вдохновением все очень просто. Разберем пример с письмом.
Чтобы послать резюме нужно: А. Обновить резюме. Б. Написать письмо в контору. В. Прикрепить резюме к письму. Г. Нажать кнопку Send.
Чтобы обновить резюме нужно: А. Открыть старое резюме в текстовом редакторе. Б. Добавить новые места работы и новые проекты. В. Удалить то, что явно устарело. Г. Закрыть текстовый редактор.
…
Короче, говоря, вдохновение ловится методом слонов и бифштексов. Если есть большая проблема (“слон”), дробим ее на маленькие шаги (“бифштексы”) и начинает жрать бифштексы. (Расшифровка: разбиваем проблему на конкретные шаги и делаем первый шаг.)
В середине первого бифштекса (иногда и после него) захочется все бросить. Продолжаем жрать.
После второго бифштекса придет эйфория, что вы офигенный чувак. Так долго не могли собраться, а тут нате – делаете! Тут и приходит вдохновение. Гарантия 100%. Проверено.
Остальные бифштексы сметаются моментально. И тут приходит настоящий кайф. Что вы сделали! то, что не могли сделать месяц!
А если ждать вдохновение перед нетронутым подносом с бифштексами, или тем паче перед слоном, то вдохновение придет через месяц. Может быть. А может, через полгода. А может, не придет.
Бизнес должен приносить прибыль. По крайней мере, в долгосрочной перспективе.
Как это ни странно, компании по разработке софта являются бизнесом. Соответственно, тоже должны приносить прибыль. Это мысль очевидная.
А поговорить я хотел о той части прибыли, которая тратится на сотрудников. На что она идет? Про затраты на оборудование, подорожание аренды офиса и пр. говорить не будем. Тут все понятно. Но когда деньги тратятся на сотрудников – на что именно они тратятся?
Многочисленные разговоры с собственниками небольших софтварных компаний показывают, что, в основном, деньги тратятся на зарплаты и бонусы.
Немного арифметики. Допустим, есть компания из 20 человек (две группы по 9 программистов и 2 менеджера). Средняя зарплата – $2,000. Компания хорошо закончила год, поэтому ген. директор Сергей Васильевич решает поднять зарплату на 20% и выплатить бонус размером в одну месячную зарплату (старую, т.е. $2,000). Чтобы программисты/менеджеры не ушли к конкурентам и вообще были более довольны жизнью.
Итого за год компания собирается потратить на это $136,000. Деньги немалые, поэтому в течение следующего года Сергей Васильевич крайней нервно реагирует на все попытки выбить дополнительный бюджет на что-то еще:
В результате в середине года два ведущих программиста уходят к конкурентам на зарплату на 10% больше. Сергей Васильевич пытается повысить им зарплату, но безуспешно. Потому что решение уже принято, а в текущей конторе о сотрудниках никто не заботится. “Даже на эспрессо-машину жмутся.”
В итоге люди уходят, приходится срочно тушить пожары в проекте. Сергей Васильевич успокаивает заказчиков, не спит ночами и говорит вслух немало неприятных слов про неблагодарных программистов, на которых он потратил больше 100 штук баксов за последний год. А они его все равно кинули.
И вот он ключевой вопрос. Мог ли Сергей Васильевич лучше распорядиться деньгами?
Да, мог бы. Есть три критичные вещи, на которые можно было бы потратить деньги с большей пользой:
Это не значит, что нужно перестать повышать зарплату и отменить все бонусы. Если перестать платить то даже нанятый на 100 штук баксов волшебник вряд ли сможет удержать программистов на месте. Но упование на деньги как на единственный и главный удерживающий фактор в корне не верно. Почему именно и что делать – поговорим в трех отдельных статьях по каждой из тем.
Часто спрашивают, откуда берутся менеджеры. “Я сейчас работаю инженером, но чувствую, что хочется быть менеджером. Как бы мне туда попасть?”
Спрашивают настолько часто, что я решил, что на эту тему нужно написать несколько мыслей. А, может быть, если будет большой интерес, и семинар сделаем.
Давайте начнем сначала. А почему вы хотите быть менеджером? Варианты я слышал примерно такие:
“У менеджеров больше зарплата.” Это правда, есть еще компании, где единственный шанс реально увеличить зарплату – это стать менеджером. Но в нормальных компаниях обычно есть две карьерные лестницы – менеджерская и техническая. Специально, чтобы инженеры не уходили из-за денег в менеджеры, а занимались тем, что им интересно, и тем, что у них действительно получается. Зарплаты в нормальных компаниях, заметим, обычно значительно выше, чем в ненормальных.
“У меня мозг уже стал старый, за новыми технологиями не поспевает. Поэтому я лучше буду людьми руководить.” Ну что тут скажешь? Обычно “мозг не поспевает” на самом деле означает, что человеку перестало быть интересно программирование. Означает ли это, что ему нужно идти в менеджеры? Совсем нет. Мир большой, возможностей много. Надоело программирование – найди то, что тебе интересно. Не надо мучить себя и других и идти в менеджеры, если тебе это не нравится, а единственным мотивом является закостенение мозга.
Многие инженеры думают, что менеджеры – это люди, получающие большие деньги за то, что они ничего не делают. Ну почти. Ходят там на митинги, читают и пишут много писем, рисуют слайды пачками. Да, еще промывают мозги, знают много аббревиатур, отчеты умеют рисовать. В общем, делают много всякой никому не нужной хрени.
Заглянем немного с менеджерской стороны. Давайте предположим, что вы стали менеджером. Вам дают другую зарплату, пишут новую статусную запись в трудовой. И ко всему этому вы получаете еще массу бонусов (далее рассказывает счастливый менеджер):
Хей, а где подвох? За что это все этим бездельникам менеджерам?!
А подвох вот где:
И вот тут встает ключевой вопрос – а надо ли оно вообще? Может, ну его?
Руководителей невозможно создать. Они делают себя сами.
Обещанное продолжение. Ну хорошо, скажут читатели первой части. Вам в крупных компаниях хорошо. Вы к себе позвали интересного человека, он к вам и приехал. И вообще у вас там конференции, ивенты какие-то. А в нашем Усть-Мухинске индустрией не пахнет. А если пахнет, то не индустрией.
Как нам быть? Может быть, не есть, не пить, деньги копить? На поездку сотрудников в Москву.
Коллеги, как и со многим остальным, дать людям ощущение причастности к индустрии, можно. С деньгами или без денег. В Москве или Пензе. Мы жеж живем в условиях глобализации и прочего космополитизма. Во многом, все зависит от желания и фантазии менеджера и самих сотрудников.
Вот, например, несколько проверенных способов:
Довольно смешно слушать от менеджеров вопросы про то, что “а когда же люди работать будут, если они будут на форумах сидеть?” Мои самые продвинутые инженеры, которые успевают больше остальных, сидят на форумах. Самый продвинутый еще учавствует в опен сорс проектах. Я смутно подозреваю, что они поэтому такие продвинутые, поэтому они больше всех и успевают, что постоянно саморазвиваются. Вместе с индустрией.
Все, наверное, слышали о такой штуке как ретроспектива. Для тех, кто не слышал, вкратце – это вскрытие состоявшегося проекта по его окончании. Когда собираются все участники проекта и высказываются по темам:
Основное правило – говорить конструктивно. Целью ретроспективы не является кого-то загнобить. А наоборот помочь всем в проекте работать еще лучше. Что интересно, обычно получается конструктивно. И вообще проходит достаточно интересно. Особенно, если вскрытие производят не только менеджеры, но действительно все сотрудники. Всем нравится быть хозяевами своей судьбы.
Но поговорить я хотел не об этом, а о немного другой ситуации. Вот, допустим, приходит техлид к менеджеру и говорит:
- Палыч, у нас проблема. Парни из библиотеки мега-утил накосячили и забыли поддержать многопоточность. В связи с чем, наша производительность сейчас в 42 раза ниже, чем у конкурентов. Вася это выяснил сегодня, когда прогнал первый многопоточный тест. Мы с парнями посидели, в общем, есть три потенциальных выхода. А: посадить Васю прикручивать опен сорс библиотеку вместо мега-утила. Б: послать Петю к парням из мега-утил, чтобы они попробовали резко реализовать многопоточность. В: делать планы А и Б одновременно, чтобы снизить риски.
Палыч молча выслышивает, потом вкрадчиво начинает:
- Коля, постой-постой. Объясни мне сначала, как такое произошло, что за месяц до релиза оказывается, что основополагающая библиотека, на которую все завязано, не поддерживает многопоточтость? Может быть, ты не знал, что нам будет нужна многопоточная библиотека? Может быть, ты был не в курсе, что нам нужно быть быстрее, чем конкуренты. Заметим, я говорил это на трех собраниях подряд…
Коля растерянно молчит. Дальше сильный в построении логических цепочек Палыч не оставляет камня на камне от техлида Коли, популярно объясняю ему, что он виноват, насколько именно он виноват, и что если он еще раз будет так виноват, то это будет иметь очень серьезные последствия.
Казалось бы все правильно. Палыча можно понять, до релиза месяц, кастомеры уже на подходе, а тут такое. Но есть несколько но.
Но №1. Палыч не берет на себя ответственности за косяки с проектом в случае провала. В итоге у Коли (и у команды) остается впечатление, что в случае чего, все шишки достанутся им.
Но №2. Коля приносит проблему с горящими глазами. Ему не терпится взять и накинуться на нее по всем планам, чтобы успеть-таки к релизу ее разрешить. После разрыва у Палыча Коля бредет в свой кубик с мыслями “ну на хрена мне это все?”, обновляет резюме и ставит в МоемКруге галочку “ищу работу”.
Но №3. В случае появления следующей проблемы, Коля к Палычу уже не идет, а либо А: Пытается втихаря ее разрешить, либо Б: откладывает ее в сторону, надеясь, что ее найдет и понесет Палычу кто-нибудь другой.
Подводим итог. Обратная связь должна быть своевременной, этого никто не отменял. Но в некоторых случаях, вскрытие лучше все-таки проводить после смерти больного.
Время от времени менеджер пытается в команде/в проекте что-то менять. Ну там, ввести, например, практику ревью кода. Или того больше, формальных инспекций кода. Или пытается всех как-то подбодрить писать юнит тесты.
Обычно происходит как. Менеджер приходит на собрание команды и говорит:
- Граждане, у меня мега-идея. Давайте писать юнит тесты! Это очень круто! Я вот тут даже прикрутил фрэймворк, чтобы тесты писать. Давайте прямо с сегодняшнего дня и начнем.
Что происходит потом. Кто-то начинает писать юнит тесты везде, где можно (это начальника радует). Кто-то иногда пишет, иногда нет. Или сначала пишет, а потом забивает. Кто-то забивает сразу, хотя на собрании коварно молчал и не возражал.
Менеджер вводит контроль. Лично смотрит отчеты о прогоне юнит тестов – сколько тестов добавляется каждый день и в каких компонентах. Через какое-то время обнаруживается, что люди пишут юнит тесты супер-простенькие – чтобы только в отчете появились.
Менеджер начинает измерять покрытие кода юнит тестами. Типа хорошо код покрыт – программист молодец, хорошо тесты пишет. Плохо покрыт – плохо. Через какое-то время, наш супер-менеджер замечает, что люди начинают жаловаться, что у них нет времени писать код – надо все время писать тесты. Еще через какое-то время по очереди приходят два самых толковых инженера и кладут заявления об увольнении.
История архи-типичная. Происходит она из-за того, что люди не любят делать то, что их заставляют делать. И люди обязательно найдут способ, как не делать того, что им не хочется.
На эту тему есть наука Change Management, про которую наш недотепистый менеджер, конечно же, не очень в курсе. Но мы-то с вами в курсе.:) Поэтому вспомним сегодня один работающий метод из этой науки.
В 19 веке в США существовала такая профессия – клакеры. Этих людей нанимали продюсеры спектаклей, опер и прочих перформансов в театрах. Задача клакеров была проста. Нужно было время от времени громко хлопать, кричать “Браво!” и “Бис!”. Остальные клакеры в зале подхватывали и кричали “Гениально!”. Основная же масса зрителей своего мнения не имела, поэтому активно склонялась туда, куда надо. Те, кому спектакль не нравился, думали, что они просто чего-то не понимают. Не может такого быть, чтобы плохому спектаклю все аплодировали! А потом и переубеждали сами себя.
В команде все то же самое, только клакерами становятся члены команды. В Change management’е такие люди называются чемпионами. Естественно, не надо убеждать людей за деньги писать юнит тесты. Но нужно перед тем, как пропагандировать идею на всю команду, найти 2-3 чемпионов, которые реально заразятся идеей.
Короче, подводя итог, не надо быть одиноким клакером. Найдите чемпионов и изменение внедрится само собой.
Последние коментарии