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

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

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

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

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

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

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

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

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

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

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

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

Как решали

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

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

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

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

Небольшое послесловие

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

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

  • понимание психологии разработчиков;

  • знание IT-рынка;

  • знание различных подходов к разработке;
  • способность нанимать нужных специалистов под конкретные задачи;

  • способность проводить адаптацию новых сотрудников к их новой роли.

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

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

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

Подводя итоги

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

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

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

Двигатель был исправлен!

Через семь дней владельцы получили счет на 100 000 долларов.

«Какого?! Вы почти ничего не сделали. Пришлите нам подробный счет» - сказали владельцы.

В ответ он просто сказал: «Постукивание молотком 2 доллара. Знать, где постучать, 99 998 долларов».

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

И очень важное. Этот самый «опыт» нельзя скопировать за «5 минут», вы можете сколько угодно повторять действия, которые подсмотрели у других, а получаться все равно не будет. Это главная беда с инфоцыганами — попытка применять то, что сам не понимаешь.

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

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

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

0
28 комментариев
Написать комментарий...
What2Sell

"Появилась опция, вместо технического директора взять владельца продукта"

Ответить
Развернуть ветку
Иван Дэвидсон

Выглядит как предложение для военкомата

Ответить
Развернуть ветку
Иван Дэвидсон

Не очень понятны ваши деловые отношения с компанией, про которую история. Вас наняли? В каком качестве? - HR-консультации, ИТ-экспертиза..?

Ответить
Развернуть ветку
Константин Митин
Автор

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

Ответить
Развернуть ветку
Иван Дэвидсон

А почему вариант подхватить все ИТ-системы оказался доя вас менее предпочтительным?

Ответить
Развернуть ветку
Константин Митин
Автор

У нас бизнес-ориентирований подход. Если бы мы взяли все IT-системы на свою поддержку, то нарушился бы баланс взаимных выгод между нами, как подрядчика, и бизнесом, как заказчиком. Это впоследствии убивает долгосрочные отношения. Мы предпочитаем формировать долгосрочные отношения и наращивать бюджеты на наши работы синхронно с ростом бизнеса заказчика.
Плюс, одна из наших ценностей - это безопасность. Ставить заказчика в зависимое положение, это нарушать его безопасность. Мы рассматриваем это, как плохую практику.
Подход может показаться несколько странным, но даёт свои плоды. Например, здесь, если бы мы стали привязывать заказчика к себе, то привязали бы и себя к заказчику. А темпы нашего развития были выше, чем у IT из той компании. Мы бы начали тормозить сами себя.

Ответить
Развернуть ветку
Роботы из зубной пасты

Напишите проще: они столько просто не готовы были платить )

Ответить
Развернуть ветку
Борис Интеграторов

Пиши/сокращай))

Ответить
Развернуть ветку
Константин Митин
Автор

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

Ответить
Развернуть ветку
Роботы из зубной пасты

Если увеличивать стоимость услуг, то можно и не расставаться никогда )

Ответить
Развернуть ветку
Константин Митин
Автор

Неэкологичный подход, который приводит к уничтожению среды обитания. :о)

Ответить
Развернуть ветку
Роботы из зубной пасты

Что есть, то есть )))

Ответить
Развернуть ветку
Mandor Sawall

Хорошая статья, нравится. Спасибо!

Ответить
Развернуть ветку
Борис Интеграторов

Говорят у тех кто покупает большие машины и называет любую свою компанию с приставкой мега ... большая душа!))))

Ответить
Развернуть ветку
Роботы из зубной пасты

А как же продукты с приставкой ЭНТЕРПРАЙЗ? ))

Ответить
Развернуть ветку
Константин Митин
Автор

На момент создания АйТи Мегастар, было только ЮЛ, которое предназначалось для маркетинговой компании. Потом мы просто решили, а почему бы и нет, раз так получилось, то продолжаем. :о))

Ответить
Развернуть ветку
Аргумент Молотова

жду теперь статью от старшего разработчика

Ответить
Развернуть ветку
Константин Митин
Автор

Интересно. А зачем ему её писать? каков его мотив?

Ответить
Развернуть ветку
Alex Chernyshev

Ряд моментов:
1. Должность 'технический директор' есть в государственном списке профессий, а 'владелец продукта' - нет. Это значит что записать в трудовой должность 'владелец продукта' нельзя.
Поэтому с точки зрения кадровой стабилизации заменять понятного ИТ-директора на непонятно кого, с неопределенным кругом обязанностей - идея не очень.
Тем более что ИТ-директор обычно 'материально ответственное лицо', с правом подписи - для оплаты всякой канцелярщины и компьютерного оборудования. Как вы вешали такие обязанности на 'product owner' - ну видимо с трудом )

2. Хватит бояться ухода 'ключевых людей', которые 'только Х понимает в этой системе'. Нет давно этой проблемы - любой проект можно подхватить, разобраться и продолжить. Без разницы абсолютно есть в доступности создатели, есть ли документация и тд.
Практически любая компания, занимающася разработкой ПО вам с этим поможет.

Ответить
Развернуть ветку
Константин Митин
Автор

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

Ответить
Развернуть ветку
Alex Chernyshev

'у которых вместо генерального директора был «владыка»'
А у меня были подрядчики с юрлицом из серии ООО 'Вектор', тоже шутники еще те. Жалко налоговая не оценила.

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

'На самом деле должности в штатном расписании можно называть очень гибко'

А в вакансии что вы напишете? Кандидату что скажете?
Ну и речь же не про название, речь про круг обязанностей, которые судя по вами описанному - не очень стандартные.

'Причем, во многих компаниях технический директор это не материально ответственное лицо,'

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

'Да, за 10 лет работы команды из 100 человек и не такое возможно.'

Вы же сами написали что разработкой занималось 4 человека, из которых только один был опытным. Тут достаточно просто прикинуть и возможный масштаб работ и всю возможную сложность.

Опытный интегратор вам даже примерное количество строк кода подскажет, исходя просто из количества человек в команде и времени разработки.

', что у вас просто очень мало опыта в вопросах, которые вы пробуете обсуждать.'

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

Ответить
Развернуть ветку
Константин Митин
Автор

А теперь представим, что ваш заказчик это какая-нибудь Лавра. И руководит у них действительно Владыка, а роль финансового директора выполняет Казначей. На полном серьезе. И проблем с кандидатами не возникает. Все кандидаты понимают, что за должность у Владыки и чем занимается Казначей.
Дальше, не везде в должностные обязанности технического директора входят закупки чего либо. Особенно расходники. Даже в малых компаниях этим офис-менеджеры занимаются, как бы.
К слову, «опытные интеграторы» очень не любят самостоятельно заниматься заказной разработкой, они любят внедрять коробки, вендорами которых они являются. А за заказной разработкой они приходят в иные компании, и там им количество строк называть не будут.
У вас пример на уровне того, что подрядчик по внедрению 1С с ходу подскажет количество строк кода в драйвере какого-нибудь IoT устройства.
И попробуйте не додумывать за противоположенную сторону. Упрощает жизнь.

Ответить
Развернуть ветку
Alex Chernyshev

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

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

Вообщем Константин, разумного диалога с вами очевидно не будет а перекидываться говном мне не интересно - возраст не тот.
Поэтому предлагаю на этом закончить, чтобы не портить друг другу новогоднее настроение.

Ответить
Развернуть ветку
Константин Митин
Автор

Если мы возьмем «банковского клерка», то его будет волновать не название должности, а «Единоличный исполнительный орган», то есть устав, протоколы, договор управления и т.д.
Мы работает с интеграторами и через интеграторов, поэтому видим, что у них происходит внутри.

Ответить
Развернуть ветку
Рустам

А стучал мастер молотком или кувалдой? и почему это называется операция? это же ремонт не?

Ответить
Развернуть ветку
Константин Митин
Автор

Мастер стучал «небольшим молоточком». Бывает, что пути сотрудников и компаний расходятся. Старый технический директор засиделся на месте и понимал это. Перспектив для развития у него не было.
Какого-то слишком недобросовестного поведения ни от одной стороны ожидать не приходилось. Мы лишь несколько смодерировали диалог технической команды с бизнесом и подсказали возможные варианты. Плюс помогли найти нужного человека.
В целом все по итогу лишь выиграли. Технический директор ушел на новое место и получил новые возможности, старшему программисту подняли зарплату, бизнес не увеличил ФОТ, все продолжило работать.

Ответить
Развернуть ветку
Eozvarit

Так, объясню потенциальным заказчикам смысл этого "непродающего" текста.
Это был не технический директор и ИТ департамент, а синьор, мидл и три стажера, даже не джуна. Но консультанты не стали это объяснять заказчику, а вместо синьора ввели своего человека с задачей покупать услуг у консультантов, на бедного мидла повесили еще и обязанности синьора, бесполезных стажеров не тронули - все, чтобы мидл как манны небесной ждал помощи от консалтеров.
А надо было синьора (техдира) подписать на полгода как консультанта на парт тайм, чтобы он менторил поднятого до синьора мидла, нанять нового крепкого мидла ему в помощь, стажеров разогнать, взять нормальных 1-2 джунов. Консультантам ничего платить.
С вас 100к грина, я знаю куда стучать молотком

Ответить
Развернуть ветку
Константин Митин
Автор

А что и у кого вы по этому тексту-то собираетесь купить? :о)
Я понимаю, что вы как раз из тех, у кого все просто, поэтому вы не учитываете массу важных деталей. Например, у нас был всего один договор с фиксированной ценой, никаких дополнительных соглашений не заключалось. Старший разработчик был вполне самостоятельным человеком и не нуждался в помощи консультантов. А попытка заменить сеньора на владельца продукта выходит уже за рамки здравого смысла. Сеньор - пишет код, а вот владелец продукта - нет.
Что до того, как надо было... Ну, бизнес уже со старым техническим директором не договорился, вряд ли удалось бы кого-то на что-то подписать. По остальным предложениям, видите ли, мы предпочитаем оставлять после себя что-то работающее, а не привычные вам обгоревшие развалины.

Ответить
Развернуть ветку
Читать все 28 комментариев
null