Зарисовка из жизни IT~BP: Маленькая спасательная операция

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

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

Я не пишу продающие тексты и не являюсь копирайтером, в конце статьи не будет коммерческого предложения и призыва к действию. Мне более интересно делиться знаниями и опытом. Некоторым людям мои статьи кажутся слишком длинными, если вам более привычен формат небольших сообщений, то обратите внимание на telegram-канал Записки ITBP.

В АйТи Мегастар обратилась новосибирская компания с достаточно сложной и развитой внутренней информационной системой с просьбой помочь им справиться с последствиями от грядущего увольнения технического директора. Нужно было понять, с какими настроениями уходит человек, как это отразиться на команде и сможет ли развиваться продукт дальше без него. Кроме этого, нас просили подготовить своих людей, чтобы в негативном случае подхватить продукт и повести его в формате заказной разработки.

В компании был небольшой ИТ-отдел: технический директор, 4 разработчика, системный администратор. Техническая команды как раз заканчивала переписывать старую информационную систему, написанную на PHP, на облачный стек технологий Microsoft и C#. Системный администратор от команды был обособлен, ему на все происходящие было безразлично. А вот с разработчиками были проблемы.

Команда разработки состояла из самого технического директора, старшего разработчика и трёх студентов-джунов. Что, как и почему устроенно в системе знали только технический директор и старший разработчик.

С одной стороны, выглядело не так страшно, все же команда заранее позаботилась о дублировании знаний. С другой стороны были нюансы.

У трех младших разработчиков зарплаты были заметно ниже рынка. Мы даже удивились, как получилось нанять людей за такие небольшие деньги. Старший разработчик работал из небольшого города из соседней области, его зарплата была небольшой. Пока он жил в родном городе, это не было большой проблемой. Беда в том, что он собирался переехать в Новосибирск.

Сложилась рискованная ситуация, когда за техническим директором мог уйти и старший разработчик, а продукт лишиться всех носителей знаний. Команда из трех младших разработчиков с продуктом заведомо не справилась бы.

При своих консультациях мы обычно говорим, что приходим вдумчиво созидать, а не разрушать. Поэтому мы разговариваем и с технической командой, чтобы иметь ещё одну точку зрения, а не опираться только на вводные от бизнеса.

В целом, технический директор оказался нормальным и уравновешенным человеком, который проработал в компании больше 10 лет. Уходил он потому, что достиг своего потолка по развитию в компании. Плюс бизнес отказался повышать зарплату. Вредить человек не собирался, наоборот он же первым обозначил риски со старшим разработчиком. И рассказал, что он хочет переехать в Новосибирск, и что его текущая зарплата была явно неконкурентоспособной в Новосибирске.

Покрутив ситуацию, мы пришли к выводу, что данной команде технический директор не нужен. Новый человек не будет столь лоялен к компании, как старый технический директор, и быстро уйдёт. Нет задач нужного масштаба, нет нормальной зарплаты. Вместо технического директора хватило бы и владельца продукта, который мог бы общаться с бизнесом и ставить задачи разработчикам.

Появилась опция, вместо технического директора взять владельца продукта и добавить денег в оклад старшего разработчика, не меняя при этом ФОТ. Причём, старшему разработчику сказали, что раз ты переезжаешь в Новосибирск и будешь ходить в офис, то тебе повысят зарплату (чтобы быстро не нашёл себе новое место в Новосибирске).

Наш HRD пообщалась с основателем компании и операционным директором, поняла, какой человек в их команду подходит и смогла оперативно найти им владельца продукта. Которого потом мы сопровождали и подстраховывали силами своей команды до момента прохождения испытательного срока. Не без накладок, конечно, пришлось несколько раз помогать и корректировать работу человека. Тем не менее, кризис был успешно преодолён.

Самое интересное, конструкция оказалась очень устойчивой и работает по сей день, а все участники сохранили хорошие отношения друг с другом более 5 лет.

Когда оглядываешься назад, уже зная решение ситуации, выглядит не так страшно. Когда ситуация только происходит, то для бизнеса это выглядит, как большой стресс, так как они не понимают, как работать с IT-шниками, а их ключевой человек уходит. При этом они не знают, продолжит ли все работать без него, и не знают, как нанять такого же.

С одной стороны, был нанят правильный человек и приняты правильные кадровые решения, после чего система заработала сама. Вот только для этого понадобилось:

Мы IT-компанией, которая специализируется в том числе на заказной разработке. У нас есть эти компетенции, это наш рынок, мы на нём работаем давно. Рынок нашего заказчика был в другом, он был экспертом там, а не в IT. Нанять «правильного технического директора» для них могло бы стать долгим и неприятным приключением.

Когда вам говорят: «...просто наймите хороших людей и они все сделают за вас...», спросите, а как не являясь экспертом в нужной области отличить «хорошего» специалиста от «плохого». Большинство не сможет вам внятно ответить на этот вопрос. Кто-то скажет: «А вот у меня есть чек-лист, что должен знать такой-то человек...». Юмор ситуации в том, что под «техническим директором» в разных компаниях понимают разное. То есть ещё не известно, подойдёт ли вашей компании чек-лист от другой (так ещё и абстрактной) компании.

Иногда, мы сами бываем в похожих ситуациях, особенно когда нужно нанять кого-то на лидерские позиции в области, где у нас ещё нет экспертизы. Начинается рискованный путь ошибок. Либо мы просто прибегаем к помощи партнёров, которые являются реальными экспертами в нужной нам области рынка. Иногда мы даже организуем совместные предприятия.

Честно говоря, описанный «кейс» не является типичным для АйТи Мегастар, компания такой услуги не предлагает и никогда не предлагала. Здесь мы согласились помочь по знакомству. Он скорее нужен для того, чтобы задуматься.

Здесь ведь, как в старом анекдоте, просто не будет...

Никогда не стоит недооценивать опыт.

Однако сам случай тоже весьма показательный. Прежде всего тем, что не пришлось решать технические проблемы либо проблемы с IT-процессами. Вместо этого было необходимо решать организационные проблемы и применять свою экспертизу на рынке труда.

При этом стоит отметить, что потребовалось лишь краткосрочное вмешательство, через три месяца мы полностью отпустили ситуацию. И техническая команда успешно работают уже почти пять лет.

Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.