Вчера у нас состоялось собрание трудового коллектива с участием самого высшего руководства – генерального директора и одного из акционеров-владельцев компании. Для меня (боюсь, что не только для меня) вопрос о принципах начисления зарплаты и выплаты премий остался без четкого ответа. При этом, к сожалению, сложилось впечатление о том, что начальство не очень понимает, что ценность сотрудника возрастает не только с ростом его профессионального мастерства. Но гораздо больше она увеличивается с увеличением срока работы человека в компании. И как раз об будет нижеследующий поток сознания.
Не знаю, как обстоят дела в аутсорсинговых компаниях, которые зарабатывают продажей жопочасов и активно перепродают пересаживают своих сотрудников с одного заказа на другой. Но у нас своя специфика – мы пишем софт, который сами же и эксплуатируем. В частности, один из основных моих проектов работает уже девять лет. За это время было выпущено его три мажорных версии (т.е. фактически полная переработка) + несметное количество разнообразных мелких и не очень доработок. Есть еще несколько проектов “помоложе”, над которыми, тем не менее люди работают по 5-6 лет. Подозреваю, что в компаниях, которые живут за счет разработки линеек собственных продуктов (взять ту же 1C) ситуация аналогичная.
Так в чем состоит реальная ценность человека, который долгое время трудится над “долгоиграющим” проектом? В том, что этот человек является чрезвычайно ценной базой знаний по множеству связанных с проектом вопросов.
С одной стороны, это знания внутреннего устройства компонентов. Мало того, что такой человек гораздо лучше ориентируется в коде и способен быстрее, а главное, качественнее, вносить изменения в программу. Так он еще и помнит (способен вспомнить) причины принятия тех или иных проектных решений. Поэтому на вопросы “А почему здесь сделано через задницу?” находятся конкретные ответы. Зачастую полностью объясняющие ситуацию. Ну и плюс к тому, у старых кадров меньше желания “переписать все нафиг с нуля!” :)
Но эта сторона очевидна. По крайней мере должна быть очевидна для имеющих к разработке софта людей (полагаю не только к разработке, но и к любой конструкторской, а то и просто производственной деятельности). А вот менее очевидная сторона – это знание туевой хучи связанных с софтом инцидентов, их причин, решений и последствий. И когда такого программиста дергают из техподдержки с вопросом “Мы делаем вот это, а оно не работает, почему?” он зачастую может с ходу назвать причину проблемы и дать ссылку на раздел документации, в которой уже несколько лет как расписана правильная последовательность действий для этого случая.
В сумме эти две составляющие в наших условиях ведут к тому, что есть ряд разработчиков, которых с полным основанием можно назвать ключевыми. Выпадение кого-либо из них способно полностью парализовать сопровождение или развитие проекта на длительный срок.
Не буду сейчас сильно заострять внимание на том, хороша ли такая ситуация или нет. AFIAK, всякие CMM как раз направлены на то, чтобы снизить риски компании от ухода ключевых разработчиков. Скажу лишь, что здесь все упирается в две вещи – деньги и время. Деньги тупо нужны для того, чтобы над одной проблемой работало больше людей. Тогда знания оказываются “реплицированными”. Т.е. если какой-то проект может сделать один человек, то для страховки нужно будет поручать этот проект двум людям. Соответственно, увеличение количества разработчиков затрудняет и замедляет разработку – за счет увеличения необходимых коммуникаций и пр. организационной лабуды.
Кроме удлинения сроков разработки за счет подключения дополнительных людей, будет требоваться еще много времени на то, чтобы тщательно фиксировать в разного рода документации всю более-менее полезную для проекта информацию. Соответственно, больше писанины – дольше разработка, больше денег нужно на проект. Ну и разработка будет не такая гибкая.
Очевидно, что в ряде случаев (стартап, слишком короткие сроки на доработки) все это утопично и недостижимо. А мы как раз в таком режиме и развивались – маленькая амбициозная компания хваталась за серьезные проекты малыми силами, терпеливо выполняя капризы VIP-заказчиков. Так что вопрос не в том, хороша ли сложившаяся ситуация или нет. А в том, что она вот такая. И отталкивая от объективной реальности нужно подходить к размерам зарплат сотрудникам, в особенности ключевым.
Из всего вышеизложенного должно быть понятно, что я считаю обязательной наличие в зарплате разработчиков такой составляющая, как “за выслугу лет”. И не только у разработчиков, но и у всех остальных причастных к выпуску и эксплуатации продукта. Просто как программист я говорю в первую очередь о программистах. Соответственно, чем дольше разработчик работает в компании, тем выше должна быть эта составляющая.
В завершение своего потока сознания хочу показать еще одну важную составляющую ценности “старых кадров”, о которой пока еще речь не шла. Это мысли, прожекты и идеи, которые существуют в голове разработчика и пока еще не воплотились в что-то конкретное. Программирование – это такая работа, которую просто так на работе не оставишь. Если ты погрузился в задачу, то она все равно будет жить у тебя где-то в глубине (под)сознания, даже если ты вернулся вечером домой и занялся домашними делами. А потом может дать о себе знать какой-то неожиданной, путь утопической, но идеей.
Кроме того, очень многие программисты весьма серьезно относятся к результатам своего труда. И чувство неудовлетворенности от не очень хорошего решения нас преследует. Иногда заставляя постоянно оглядываться назад и думать о том, как можно было бы сделать лучше. Бывает, что в условиях цейтнота или из-за недостатка знаний сделаешь что-то грубо, наспех – актуальность принципа “если сомневаешься, используй brute force” пока еще не снизилась. А потом на ум приходит более элегантное и эффективное решение. Но ты не имеешь возможности внедрить его – программа работает, клиент пока не хочет ничего менять, ты сейчас занят другими важными проектами и т.д. Тем не менее, ты знаешь, как можно сделать лучше.
Так вот, все это множество невысказанных, а иногда и не готовых еще к высказыванию, идей будет безвозвратно потеряно с уходом разработчика из компании. Как оценить их ценность? Насколько она сопоставима, например, с повышением программисту зарплаты раз в год на 5%?
Уверен, что успешной фирме, проекты которой приносят прибыль, выгоднее выплачивать прибавку “за выслугу лет”. Намного выгоднее, чем рисковать потерей ключевых разработчиков. Не только разработчиков.
PS. Да, я сейчас выступил в роли “Капитана Очевидность”. Но складывается впечатление, что даже очевидные вещи не грех время от времени озвучивать вслух.
4 комментария:
Ну, ок, продолжим перечислять очевидные вещи.
Ценность и цена никак не связаны. Цена - это за сколько тебя (товар) готовы купить.
//К.О.
А теперь не очень очевидные вещи.
1. Тот кто ближе всего к клиенту (покупателю) тот больше всего и получает. Т.е. менеджер по продажам легко может получить 50% суммы заказа (иначе он этот заказ отдаст другому исполнителю). Выполнять просто - сложнее найти заказ. Но даже у менеджера по работе с существующими клиентами (т.е. клиента нашел не он) зарплата будет выше, чем у исполнителя.
2. Тот кто выше по должности, получает больше. Независимо от того, что он делает и сколько вносит прибавочной стоимости к основному продукту компании. Это может быть твой начальник, который просто передает задачу сверху вниз, а может быть человек, который нашел заказ, обговорил с заказчиком детали, составил ТЗ, нашел исполнителей, подробно объяснил каждому его часть задачи, контролирует выполнение задачи, любого исполнителя подменяет, если тот косячит, согласовывает с заказчиком необходимые изменения, которые надо внести в сделанную работу... Неважно, какова ценность человека выше тебя по должности - его зарплата будет выше твоей.
Если хочешь оставаться исполнителем - твой выход учиться себя продвигать. Т.е. осваивать новый навык (никак не связанный с кодированием, построением архитектуры и вообще с техническими навыками). Нужно учиться находить того работодателя, который тебе больше подходит и преподнести себя, как нужного ему человека. Один из способов - это постоянно ходить на собеседования. Регулярно, раз в неделю. Но это лишь малая часть. Нужно убедить этого человека, что ты не очередной неизвестный со стандартным резюме, в котором перечислены стандартные термины, а человек, который будет решать нужные задачи. При этом нужно понимать, что на наемной работе для каждой должности есть фиксированный набор обязанностей, задача, которые работник должен решать, и, поэтому, есть свой потолок по зарплате (т.е. если ты читаешь мысли начальника и все что он хочет делаешь в минимально доступный человеку период времени, предоставляя результаты работы в наиболее удобном виде - ты сможешь получать максимум, доступный на данной должности).
Сейчас работодатель на тебя реагирует просто. Работает, временами мычит, но делает что надо. Совсем другое дело, если ты придешь к нему и скажешь, что нашел другое место. Поиск замены для специалиста - нетривиальная задача. Насколько я знаю, кадровые агентства берут за нахождение специалиста 3 месячных зарплаты (+ еще месяца 3 потребуется, чтобы человек вник в свои обязанности, правила компании и начал уверенно работать). К тому же на поиск замены потребуется время.
Кроме того, есть еще такая особенность, что топ менеджеру совсем ничего неизвестно про твои потребности и особенности работы (скорее всего он сразу начинал как управленец, т.е. менеджер, а если и был исполнителем, то цели у него были иные - быстрый рост, а следовательно и отношение к работе другое, не обязательно наплевательское, просто другое). Твоего же непосредственного начальника гораздо больше интересует своя зарплата и свой карьерный рост, чем твои трудности (я говорю про начальника-управленца, он не пишет код). Поэтому, твои трудности никого не интересуют (о них просто никто не знает и не задумывается, по-крайней мере так как ты). Чтобы о них задумались, систему нужно сильно тряхнуть, или внезапно должна возникнуть текучка кадров (тогда через пол года, когда в производстве возникнут серьзные трудности, это дойдет до топ-менеджеров). Вот только тогда топы задумаются, что бы такое предпринять. Но опять же, большую часть руководства будет интересовать своя зарплата, а не твои потребности. И эти люди будут принимать решения, что предпринять в такой ситуации.
Так что выход простой. Либо учиться продавать себя как исполнителя, либо сменить нафиг сферу деятельности, но все равно учиться продавать себя (уже как руководителя или кого-то другого). Либо живи как есть.
@Леша Сырников:
Спасибо за развернутый комментарий!
Ты пишешь интересные, хотя и не бесспорные вещи. Но ты говоришь о том, как программисту увеличить свое благосостояние. Т.е. рассматриваешь тему с точки зрения программиста.
Я же хотел объяснить суть вопроса работадателям. Т.е. трата совсем небольшой дополнительной суммы на оплату позволит им уменьшить свои риски и приобрести лояльность своих сотрудников.
Если провести аналогию с владельцем магазинчика, то я попытался объяснить ему, почему скидки для постоянных покупателей или продажа двух бутылок Coca-Cola по цене одной могут быть выгодны.
Ценность определенных знаний очевидна тому у кого они есть и ... субьективна. Я вот был в стартапе с местным инвестором. Инвестор кто определяет сумму вообще ничего не знает. Управленцы которые решают что делать сами ничего не знают как, и про риски с инвестором говорить боятся. Те у кого знания могут прыгать на ушах с криками "вы теряете деньги" но никто их не услышит.
Я думаю все дело в том что в традиционных индустриях медленный естественный отбор уже сделал свое дело, а информационное хозяйство это одна сплошная революция и факторы типа естественного отбора не успевают её очищать.
Так что работаем с теми кто есть и не стоит ожидать от других способностей, которые есть у вас.
@Miroslav:
Вынужден согласиться с вашими словами.
Отправить комментарий