Мотивация и системы мотивирования

Юлия Нестерова, тимлид фронтенд-разработки крупной ИТ-компании, создающей продукт (интерфейс) для маркетплейсов, продолжает мысль Иветты Поче и говорит, что проблем с теми разработчиками, которым 30+ лет, значительно меньше, чем с теми, кому 21–22. Тридцатилетние уже обладают опытом в технологиях и зрелой ответственностью, а 21–22-летние пока только амбициями: запрос на высокий доход есть, а понимания, что такое дедлайн, – нет. И тем не менее запрос от малоопытных ИТ-специалистов на высокий заработок находит удовлетворение на рынке труда: есть компании, которые готовы брать «рабочие руки» за любые деньги. Инвестиционные стартапы, некоторые банки (например, «Сбер») активно приглашают всех, кто способен прочитать их объявление о найме и понять его смысл. Далее многие кандидаты не выдерживают испытательного срока и снова оказываются на рынке труда. Однако повреждение нестойкой юной психики высокой зарплатой уже нанесено – и молодой недоспециалист активно ищет работодателя, который будет платить столько же, а требовать меньше, чем предыдущая богатая компания.

Кадровый голод связан не только с высоким спросом на ИТ-специалистов, но и с тем, что физически сейчас на рынке нет молодых людей, рожденных в 90-е годы прошлого века, – считает генеральный директор компании «Первая Форма» Денис Селезнев. Рождаемость тогда объективно упала, и новые работники просто не успели вырасти и выйти на рынок. Это сложная проблема, но Денис Селезнев полагает, что грамотно выстроенные бизнес-процессы частично помогают ее решить, так как можно обойтись меньшим количеством людей, повысив производительность труда за счет правильных инженерных решений.

Есть общее в развитии специалистов в ИТ и инженерии. В обеих областях требуется знание технологии, конкретной предметной области, а потом уже расширение спектра умений в сторону менеджмента. В ИТ обычно не срабатывает подход «дирижера оркестра», когда менеджер понимает, как управлять движением к цели, но сам, образно говоря, не играет ни на одном инструменте, а лишь обеспечивает слаженность работы команды. В ИТ важно, чтобы руководитель проекта или тимлид не только обладал навыками менеджмента и коммуникаций, но и разбирался в технологии. Из любого правила есть исключения, бывают случаи успешного руководства крупным ИТ-проектом за счет именно менеджерских способностей или назначения руководителем проекта умелого «дирижера» от вышестоящих структур, но чаще успешный проектный ИТ-специалист вырастает «снизу», а не приходит «сверху».

Наличие руководителя, профессионально разбирающегося в сути создаваемого продукта, может быть критичным для ИТ-проекта. Сейчас скорость вывода продукта на рынок нередко считается основным требованием и конкурентным преимуществом в ИТ-отрасли. Это может приводить к сокращению периода оценки написанных разработчиками кодов и тестирования рабочих версий продукта. Давление заказчиков, владельцев бизнеса может быть настолько сильным, что разработка попадает на рынок в полусыром или вовсе не готовом виде. Логика здесь довольно наивная, но нередко срабатывающая: «важно застолбить за собой продукт/нишу, а баги неизбежны, будем исправлять в ходе эксплуатации». Наверное, каждому из читателей этих строк доводилось, ругаясь, непрерывно запускать обновления имеющихся программ, каждое из которых обещало устранить ошибки предыдущих версий, а на самом деле добавляло новые. Кажется, основополагающий принцип ИТ-систем прошлых десятилетий – если работает, то не трогай! – перестал работать в последние годы. Нередко суть обновления – это просто новые дизайнерские «фичи», добавляющие яркости продукту, но снижающие его простоту и пользу для потребителя.

Требования к качественному ИТ-продукту не особо меняются в отличие от подходов к их удовлетворению. Хороший продукт должен обладать следующими свойствами.

• Быть функциональным: решать задачу, для которой создавался; удовлетворять требованиям и ограничениям заказчика; интегрироваться с имеющимися ИТ-решениями; обеспечивать безопасность данных.

• Быть надежным: софт должен быть устойчивым; быть способным функционировать даже при частичном отказе системы; быть способным к самовосстановлению после отказа системы.