Разработчики ПО становятся активом более ценным, чем деньги. Упустить их или потерять над ними контроль (и ещё непонятно, что хуже) легко как никогда. Мы решили рассказать о том, как можно снизить эти риски.
Как показывает исследование Stripe & Harris Poll, 61% топ-менеджеров (из выборки более чем в 1 тыс. управленцев) сочли главным фактором, способным определить успех их бизнеса, возможность заполучить в команду сильных разработчиков. По оценке Forrester, организации, для которых инженерные таланты критически важны и которым таковых недостаёт, в 2018 столкнулись с необходимостью платить специалистам в среднем на 20% больше рынка.
Но даже имея в своём распоряжении достойных профи, и корпорации, и стартапы могут упускать прибыль — просто из-за системных ошибок в работе с айтишниками. В частности, многие программисты вынуждены поддерживать устаревшие системы либо софт откровенно низкого качества. Компании по всему миру из-за такого подхода теряют порядка $300 млрд в год.
Да и вообще привлекать и удерживать квалифицированных программистов в нынешних условиях — задачка не из лёгких. В «экономику свободного заработка» (the gig economy), с гибкими нестандартными моделями занятости, вовлечено всё больше трудоспособных взрослых: по оценке McKinsey, по состоянию на 2017 год только в Европе и США таковых насчитывалось до 162 млн человек. Сегодня разработчик располагает всё большим числом разноплановых возможностей получать приемлемое для него денежное вознаграждение, не сковывая себя рамками трудового договора с одним работодателем.
Чтобы набрать в команду инженеров и создать им среду, из которой не захочется уходить, стоит придерживаться нескольких правил. Ими рецепт успеха в технологическом talent management не исчерпывается, но они точно работают, если применять их без фанатизма.
С осторожностью нанимайте «IT-звёзд»
Иногда наём «селебритиз от кодинга» — именитых ИБ-специалистов или гениев хайлоада и т. д. — приводит к тому, что они в какой-то момент становятся неприкосновенными, де-факто приобретая рычаги такие влияния на команду, которые вообще-то полагаются только менеджменту. Подобное случается, если ради развития нового технологического направления или проекта фирма хочет собрать команду мечты и начинает «пылесосить» рынок, выхватывая с него самых опытных профессионалов без учёта того, как они будут работать вместе.
Зачастую в крупных компаниях с долгой историей «IT-звёзды» претерпевают малоприятные личностные метаморфозы из-за того, что лишь они знают, как поддерживать огромные массивы legacy code. При непрозрачной структуре технологического управления такие сотрудники уже с неохотой делятся соответствующими знаниями с новичками и начинают саботировать инициативы, гипотетически способные пошатнуть их статус в компании или отделе.
В известной степени эти риски устраняет или смягчает честное, последовательное внедрение принципов Scrum и Agile в работу организации (см. дальше), но даже в отдельно взятой IT-компании, где восторжествовали гибкие методологии, такие «технопримы» способны усложнить работу IT-департамента.
Впрочем, «звезда» — это не приговор. Просто таких сотрудников не нужно пытаться «оторвать с руками», равно как нет необходимости их избегать. При собеседованиях с самыми опытными разработчиками следует обращать повышенное внимание на их soft skills, включая навыки командной работы (в большинстве своём массовое ПО не делается силами одного-единственного человека) и отзывы от предыдущих работодателей.
Это не значит, что ради «хеджирования рисков» надо брать в команду множество специалистов с дублирующимися функциями или предпочитать середнячков профессионалам классом выше. Но «звёздность» разработчика — уж точно не абсолютная ценность.
Давайте специалистам возможность получать новые навыки
Для большинства разработчиков, системных архитекторов, тимлидов главным мотиватором — деньги пока оставим за скобками — является профессиональное самосовершенствование. Им попросту нравится писать код и создавать системы, которые умеют делать что-то полезное. Также им нравится, когда у них есть возможность учиться и делать свою работу лучше, чем прочие.
Более того, в профессиональном сообществе эта тяга имеет свойство принимать характер невроза: разработчики боятся чего-то не знать, оказаться недостаточно компетентными даже в тех сферах, где трудятся годами. Ими владеет FOMO (fear of missing out, или «синдром упущенной выгоды»). Никто не мешает работодателю, понимающему эти нюансы, давать программистам под своим началом возможности форсированного развития.
Таких возможностей, к счастью, много. Во-первых, это (как ни банально) интересная работа, благодаря которой senior developer укрепит свой профессионализм, а junior developer волей-неволей подтянет свои навыки до «миддловских». При условии, что климат в команде благоприятный для старательных новичков.
Одно дело — клепать один за другим шаблонные интернет-магазины, другое — делать сложный, нетипичный продукт. В случае с действительно осмысленными проектами вопросы сугубо технологические, находящиеся в компетенции IT-департамента, обретают реальное измерение. Рутинные споры вокруг выбора той или иной технологии удаётся перевести в конструктивное русло — в русло той пользы, которую конкретный выбор даст аудитории сервиса.
Для компании, которая заботится о квалификации своих разработчиков, в порядке вещей создавать собственные технологические базы знаний, оплачивать полностью или частично учебные и сертификационные курсы, покупать профессиональную литературу по запросам разработчиков, проводить внутренние хакатоны.
Умный работодатель со спокойной душой отпустит инженера выступить на профильной конференции, так как понимает, что тот своим докладом косвенно продвигает не только себя как специалиста, но и компанию. Опасаться, что на конференции специалиста переманят в другое место, не стоит: если сам сотрудник колеблется, сманить его смогут и онлайн прямо из офиса.
Справедливо оплачивайте труд разработчиков
Когда говорят о том, что деньги — не главный мотивирующий фактор для разработчика, отчего-то на них часто вообще закрывают глаза. Между тем как раз в силу того, что IT-специалисты привержены принципам рационального мышления, им особенно важно понимать, на какое вознаграждение они могут рассчитывать в обозримом будущем и при каких условиях. Будь программисты равнодушны к деньгам, им бы столько не платили.
Также важно, чтобы модель формирования вознаграждения была понятной и сохраняла привязку к тому, какую пользу специалист приносит компании. Случается, это правило нарушают в отношении «звёздных» разработчиков (см. выше) и переплачивают им «за статус».
Конечно, работодатели не поощряют разглашение информации о зарплатах своих сотрудников, но в итоге всё равно все знают, кто сколько получает, и очевидная «несправедливость» в начислениях кому-либо из соседей по офису запросто демотивирует программистов.
Для стартапа имеет смысл также просчитать опционную программу для ведущих разработчиков и держать эти обещания, что бы ни происходило с бизнесом. Однако нельзя и переусердствовать — сулить больше, чем вы будете в состоянии дать. Нередко основатели инновационных проектов пренебрегают этим правилом и обещают долю в компании чуть ли не стажёрам. Следует знать меру — например, в Buffer по опционной программе команде (за вычетом сооснователей) в общей сложности выделили 17% акций, а ведущим консультантам — около 3%.
Вовремя предлагайте подходящие варианты развития карьеры
Руководитель компании или CTO — в зависимости от размаха и структуры бизнеса — должен понимать, какова базовая мотивация инженеров, тестировщиков, проджектов под его началом. Во многих случаях разработчики и другие технические специалисты разочаровываются в компании и уходят из неё потому, что не видят, куда им двигаться в ней дальше.
Разумеется, единого пути для всех и каждого нет, разработчики бывают очень разные. Отталкиваться нужно от потребностей каждого сотрудника в отдельности. Скажем, для многих разработчиков отличный путь развития — стать тимлидом: не оторвавшись от программирования, начать в большей степени отвечать за продукт, иметь право голоса при изменении технологического стека.
Но отнюдь не все инженеры хотят брать на себя что-то кроме задач по разработке. Попытка «выдрессировать» из такого специалиста технического руководителя даже начального уровня приведёт, скорее всего, к тому, что он попросту уволится. К счастью, разработка ПО — сфера, где возможен безграничный горизонтальный рост, если в компании есть проекты, которые будут ставить перед старшими разработчиками достойные (в их глазах) вызовы.
Так что говорите с разработчиками: и на старте, во время собеседований, и когда они уже у вас в штате. Если вы менеджер высшего эшелона, то понять профессиональные и карьерные потребности рядовых программистов вам помогут их непосредственные руководители (начальники отделов, тимлиды и т. д.).
Создайте культуру, в которой первичен разработчик
Эта рекомендация применима в первую очередь к IT-компаниям, для которых ценность инженеров ещё выше, чем в среднем по рынку. Операционный директор Stack Overflow Джефф Щепански рекомендует пестовать внутри компании культуру, которую он окрестил developer-first, то есть такую, где программист с его потребностями поставлен во главу угла.
Некоторые обстоятельства и ситуации, демотивирующие программистов, могут быть непонятны менеджеру, который раньше плотно с ними не работал. Допустим, если пятую часть своего рабочего времени квалифицированный разработчик ПО вынужден строчить отчёты для человека, который сам не написал ни строчки кода, велик риск, что рано или поздно (причём скорее рано) он махнёт рукой и уволится, даже несмотря на зарплату выше средней по рынку.
Поэтому в компаниях, чей успех опирается в первую очередь на труд разработчиков, важно выстроить правильную оргструктуру, где между программистами и классическими управленцами находятся промежуточные звенья — низовой и средний менеджмент, который прекрасно разбирается в работе инженеров.
Важно и, не упуская контроля над разработчиками, избегать микроменеджмента, способного убить их продуктивность. Таким гиперконтролем часто грешат либо менеджеры без айтишного прошлого, которые тем самым пытаются справиться с собственным чувством беспомощности, либо, наоборот, те руководители начального уровня, которые сами ещё недавно кодили и теперь боятся, что не справятся с новыми обязанностями.
Наконец, одна из типичных причин, по которым разработчики чаще всего покидают крупные компании, — это недостаток автономии в принятии важных решений, а также чрезмерная ограниченность в выборе инструментов, подчас не обусловленная ничем, кроме корпоративных соображений.
Забота — точнее, «забота здорового человека» — о разработчиках выражается на самых разных уровнях: от понимания текущих реалий проекта (может быть, проект позволяет «технарям» работать из дома 1-2 дня в неделю?) до эргономики пространства, в котором находятся работники (не всем IT-специалистам, к примеру, нравятся опен спейсы).
Свяжите IT-разработку с целями компании
Часто предприниматели и менеджеры упрекают разработчиков в том, что те «не видят картины в целом» и упускают из вида бизнес-цели компании. Совершенно напрасно. Системные архитекторы, инженеры и кодеры и не обязаны рассуждать в финансовых и рыночных категориях. Да, «продуктовое мышление» — это здорово, но воспитывается оно в правильной, располагающей к тому среде.
Чтобы разработчики делали то, что будет полезно для бизнеса, нужно поместить их в подходящие условия. Цель — убить двух зайцев. С другой стороны сделать так, чтобы у разработчиков не возникало вопросов вида «Зачем мы это делаем?», с другой — следить, чтобы менеджмент не требовал от технических руководителей результатов, которые айтишникам непонятны в корне. И цель эта достижима.
За последние 20–25 лет в мире было выработано и продолжает совершенствоваться множество фреймворков, сводов лучших практик информационных технологий. Среди них, например, — ITIL и COBIT. Первый был создан для того, чтобы минимизировать бюрократию и создать понятные воспроизводимые правила для выполнения рутинных процессов в IT. А второй, в свою очередь, изначально разрабатывался, чтобы соединить и синхронизировать потребности бизнеса с принципами разработки ПО.
Кроме того, построить здоровую среду для создания и обеспечения работоспособности IT-продуктов помогает внедрение методологий гибкой разработки, в первую очередь Scrum. Чтобы понять, насколько ваша компания соответствует принципам Scrum, есть отличный тест Scrum Open. Механизмы, которые приняты в гибких методологиях, помогают нивелировать многие из вышеописанных рисков.
Скажем, человек со специальной ролью — «Scrum-мастер» — концентрируется, в частности, на том, чтобы осуществить в коллективе переход к подлинно командной работе. В том числе, с одной стороны, снимает опасения старожилов команды, которые боятся стать ненужными, с другой — настраивает новичков на уважительное отношение к локальным «IT-звёздам».
Мы понимаем ценность разработчиков и стараемся сделать так, чтобы им было комфортно работать в 1cloud. А прямо сейчас мы расширяем нашу команду и будем рады пригласить вас на роль ведущего бэкенд-разработчика. Помимо координации работы коллег вы займетесь архитектурой и механизмами взаимодействия наших решений с другими системами.
В качестве базовых требований: опыт промышленной разработки на C# и платформе .NET; хорошее знание SQL, T-SQL и опыт работы с MS SQL Server; опыт работы с Git, опыт построения CI/CD процессов. Мы рассматриваем кандидатов на полную занятость. Наш офис расположен в центре Санкт-Петербурга (м.Чернышевская).
