Вы открыли эту статью потому что от вас уходили программисты, либо вы боитесь, что они от вас могут уйти. В любом случае, думаю всем одинаково интересно сталкиваться с таким явлением как можно меньше.
В данной статье я решил рассказать почему из моих команд уходили ребята и что я теперь делаю по-другому, чтобы этого не происходило. Надеюсь, кому-то этот опыт пригодится.
Для наглядности, давайте представим, что у нас есть некий стартапный стартап, в котором работает супер-программист Степан. И как-то утром, после дейлика приходит Степан к нам и говорит: "Было очень интересно у вас работать, но я устал, я ухожу". Давайте разбираться, почему Степан принял такое решение.
1. Кончились интересные задачи
Степан написал все сложные части сервиса, построил архитектуру, поправил все крупные баги, и новых больших задач уже не так много. Там поправить, тут дополнить и можно в прод. А тем временем IT не стояло на месте, оно развивалось. Степан тоже хочет развиваться и расти профессионально. И если вы не думаете о развитие своей команды - она от вас рано или поздно уйдёт развиваться в другое место.
Решение:
Надо заботиться о развитие своей команды. Пока человек может учиться - он будет работать с вами. Потому что вы - это источник знаний, а знания - это сила. Крутой фишкой может быть покупка корпоративного доступа к обучающим площадкам по типу Udemy.
Лично я раз в месяц приглашал к нам на дейлик какого-нибудь сильного прогера, который пишет на нашем стеке или IT-звезду с YouTube. Мы проводили с ними 1-2 часа, ребята задавали накопившиеся вопросы по технологиям и языкам программирования или просто мило болтали за жизнь. Такие консультации стоят не очень дорого (100-200 долларов в зависимости от уровня гостя), но дают вашей команде сильный рост.
2. Никто меня не любит, никто не приголубит
Степан хоть и программист, но всё же человек. Как и все люди он совершал ошибки, которые приводили к багам в программах. И за них мы ругали Степана. А когда Степан всё исправлял, его уже никто не хвалил за верно работающую программу. А чего его хвалить, он же накосячил первоначально. А пока исправлял одну программу, мы нашли косяк в другой. Но вот в чём проблема, из-за того, что мы вечно Степана ругали - у него развилась депрессия, ему стало казаться, что он плохой программист, упала самооценка, а в месте с ней пропало желание работать у нас.
Решение:
Надо хвалить людей. Всегда есть повод за что похвалить программиста. От вас не убудет, а человеку - приятно. Баги будут случаться не зависимо от того ругаете вы свою команду за них или нет. К тому же, довольные и уверенные в себе программисты работают лучше и совершают меньше ошибок.
3. Дали офер в Сбере
Так получилось, что Степан пришёл к нам совсем молодым. Был так сказать джуном джуна. А потом Степан прокачался, стал уверенным джуном+, почти мидлом. И так получилось, что такой программист понадобился Сберу. Они предложили Степану дмс, зарплату на 50К выше и печеньки в офисе.
Решение:
Ну прежде всего надо обеспечить неиссякаемый источник печенек у вас в офисе... Шучу. В такой ситуации на самом деле сложно что-либо советовать. Всегда есть компания круче вашей, куда мечтают попасть большинство программистов. Однако, можно постараться снизить риски такого исхода.
Придумайте прозрачную систему грейдов, бонусов, чтобы люди внутри компании понимали как они могут увеличить свой доход спустя полгода-год работы у вас. Чтобы "сменить контору" не было единственным способом для этого.
У меня один раз ушёл ключевой бекэндер из команды в этот самый Сбер. И скажу честно, для меня это стало большой проблемой, потому что бек пришлось с этого дня тащить самому, замены в команде не оказалось. Поэтому заботьтесь всегда о том, чтобы в команде было кому заменить ключевого программиста на направлении. Это может быть подрастающий мидл в вашей команде, который уже в курсе всех проектных знаний и сможет подхватить всю работу.
4. Ты за сколько задачу сделаешь?
Степану ставили задачи и просили каждую из них оценить по времени. А когда Степан не укладывался в срок - ему говорили: "Степан, блин, ну ты же обещал!?" В итоге Степан опять впал в депрессию, напился, а когда протрезвел, обнаружил себя заполняющим профиль на HH.ru.
Теме контроля сроков я хочу посвятить отдельную статью. Сейчас же пока скажу, что если в вашей компании разработчики заранее дают оценку сроков разработки отдельных фич, а потом систематически в них не укладываются - это значит что что-то не так в мотивации или менеджменте. Главное поймите - программист в этом точно не виноват.
Решение:
Попробуйте декомпозировать большие задачи на более мелкие так, чтобы их выполнение занимало не более 1-2х дней. Тогда и оценок сроков никаких не потребуется от ваших дорогих и любимых коллег, и программисты будут закрывать много мелких тасок. Это даст высокую динамику работы, сделает ваших программистов счастливыми, а ваш проект быстрорастущим.
Подписывайтесь на мой телеграм канал, чтобы не пропускать новые статьи: